RC 2017/10 – Getting started

Ok, I finally found some time to get the project started. Better late than never! Not much to report, though. Just the usual tasks before real work can take place:

  • create space on the workbench
  • rake PET and breadboard up
  • find documentation (if available at all)
  • connect everything
  • download/install/configure toolchain
  • cupato (cheer up, pray and turn on)
  • REPEAT pull_a_long_face UNTIL all_bugs_fixed == true

I was pressed for time (aka lazy) last RetroChallenge, so I failed to realize that it would have been a fantastic idea to clean not only the 6520 socket but every chip and socket on the contaminated PET mainboard. The PET refused to start the BASIC interpreter and soft-landed in TIM. Tough luck! Fortunately a retro computing nerd agreed to do the cleaning – grumpily…

The PET seems to be ok now but the breadboard lives up to it’s name – not a single pixel is displayed on the VGA monitor. Monitor is ok when connected to a PC. Maybe the firmware version does not fit the last modifications of the circuit? To be honest, I probably missed to document the last steps as I hoped to continue the project on the next day. Apparently, it took about five month – and memory fades away…

In case you’re new to this project (or your memory is teasing you as mine does in this case), please consider (re)reading the archived blog entries of RC 2017/04 where I discussed some project basics. Otherwise it might be difficult to follow this ongoing development. Anyway, please feel free to put your questions into the comments. Moderated comments are used to prevent spamming, so it’ll take some time before your comment gets published.

RC 2017/10 – PET/CBM Color Graphic again

At the beginning of RC 2017/04 I promised my dearly beloved PET 2001 that it will be transformed into a Color-PET this year. I stand by my promise.

Spring-RetroChallenge lead to a color graphic system on a breadboard. It was capable of displaying 320 by 240 pixels at 256 colors on a VGA monitor. Besides a few quirks it worked quite reliable but was not connected to the PET at all.

During this RetroChallenge I plan to get rid of the remaining bugs, integrate the graphic system into the PET and write a BASIC extension that supports graphic primitives like DrawPixel, DrawLine, ClearScreen, etc.

RC 2017/04 – After-Show Party

What caused the toasted port on the microcontroller? I’m working always on a electrostatic dissipative mat, so the only possible reason is a conflicting situation on the data bus. I found a sequence in my source code where Port C of the controller and the external SRAM were both set to output. Shit happens!

I modified the circuit so that the output enable pins of the SRAM and the DAC-latch are connected, hence now the SRAM is driving the data bus only during the active periods of a frame. That limits my chances of spoiling the circuit again as there is simply no time to fool around when every cycle counts.

Today I replaced the defective ATmega1284 by a new one, adjusted some fuses, burned the last development version of the firmware aaaand look what we’ve got:

Yeah! Now we are talking!  🙂

It’s far from being perfect, but it’s doing much better than I expected. Only a few unplanned pixels due to EMI are visible (see below: the small red dot on the left).

There is a discontinuity in the sine wave at x = 256 and if you look closely you’ll notice a slightly greater distance between the red pixel and the green pixel above that gap than between the other pixels. This might be an off-by-one error in the pixel drawing routine or the result of two more clock cycles when switching to the next memory page (256 bytes). The sine wave ends in a flat line, which most likely means the shut-off of the DAC is late. I have currently no clue where the blue-grey vertical lines in the leftmost / rightmost positions come from, though.

I must admit that the desperate hurry during the last few days of RetroChallenge left me with a suboptimal wiring scheme.  My decision to use a single port for the low byte and high byte (via a latch) of the address wasn’t particularly favorable. Every pixel has to be drawn within two clock cycles. That works fine until the address counter of a line reaches 255. Now we need to increment the high byte of the address and set the low byte to zero:

– increment address high byte register (1 cycle)
– set transparent mode (1 cycle)
– output address high byte register (1 cycle)
– set latched mode (1 cycle)
– clear address low byte register (1 cycle)
– output address low byte register (1 cycle)

Obviously that does not fit. Here is my workaround:

– set address pin A16 to high (2 cycles)

It works, but the resulting memory scheme is weird:

0, 1, 2, 3, … 255, 65791, 65536, 65537, 65538, … 65598

Ok, it’s not as bad as it looks like at first glance. Every memory scheme is just a human conception/idea. The memory chip doesn’t care about the address sequence at all. As long as we use the same address when reading or writing a specific byte everything is honky-dory. However, we waste 192 bytes per line this way. Version 2.0 of CHRE will take care of this issue…

In fact, the gap we’ve seen in the sine wave was caused by an off-by-one bug and wasted cycles. And the DAC-latch timing was wrong. Both issues could be fixed easily. In addition the vertical resolution has been reduced from 480 to 240.

So, now we have 320 by 240 at 256 colors! That was one of my goals for RetroChallenge. Accomplished. But way too late. 🙁

Anyway, playing with this graphics board is fun:

Unfortunately we see some spooky vertical lines now…

                    To be continued…

RC 2017/04 – Inspection Report

Despite good progress made by shoving bits in my software development tool of choice, finally the CHRE firmware resisted the plan to show at least some real color graphics before the end of RetroChallenge. So, I waved the white flag, took some sleep and got back to the issues today.

When sending video data from the MCU straight to the DAC it was possible to produce some nice looking pictures:

A closer look to the color gradient…

Ok, that’s boring, but nice. This graphic shows a resolution of 320 by 480 at 16 out of 256 colors. Apparently, we have a rock-solid timing. Edges are well defined and no distortions are visible.

Unfortunately as soon as I try the same out of the video memory nothing works as expected anymore. To make a long story short, it turned out that I somehow managed to fry Port C of the ATmega1284. Its output drivers are still working, but it draws about 6 mA on each pin in high impedance state. That pulls every bit of data down that the SRAM tries to send to the DAC.

I will continue to work on this project as time permits. Please follow me on Twitter or check back regularly.

By the way, if you are interested in some other PET 2001 work regarding graphics, make sure to visit the awesome RetroChallenge 2017/04 project of Norbert Landsteiner, who implemented a “Space Commander” clone based on character graphics! Hats off to Norbert!

RC 2017/04 – Alternative Schematics

Time is short so let’s skip the part where we draw schematics. I thought it would be more fun to show you how the circuit develops and explain it along the way.

A golden rule in (high speed) digital circuit layout is to keep wires/traces as short as possible and to increase the spacing between adjacent wires/traces. That helps to reduce electromagnetic interference, e.g. cross talk. Therefore the previously used test circuit has been rearranged to get the oscillator out of the way. The grey wire between the silvery can on the left and the biggest chip on the board is our clock line feeding a square wave of 25 Mhz @ 5 Vpp into the ATmega1284.

Blue wires are  signal ground,
red wires are  supply voltage,
grey wires are  address lines and clock lines,
white wires are data lines ,
yellow wires are control lines,
(SCNR, read: ‘data lines’ and ‘control lines’)
beige drops are  decoupling caps,
beige or blue cylinders with colored stripes are  pull-up resistors,
unless otherwise noted.

First exception: A bunch of colorful wires is leading to a connector and a flat flex cable at the top left. These are used to program the microcontroller (MCU).

There’s an address latch (74ALS573) below the MCU. Yes, I know. The ALS type is too fast for the task and may cause additional EMI issues. Unfortunately I don’t have (or can’t find) the HC type. Living countryside doesn’t help when trying to buy electronic parts on a weekend either.

The external SRAM (BS62LV4006) is situated on the right. Nineteen address lines are required to access the full 512KB. Add eight data lines, eight lines for communication to the user port of  the PET 2001, three control lines, two video sync lines and you’ll get  ERROR! OUT OF I/O PINS!  The solution is a buffer store aka latch:

Port D of the ATmega is connected to the SRAM via the address latch. Thus it can output the first byte of an 19-bit-address while in transparent mode, then switch to latch mode. The address latch keeps this bit pattern on its output pins, regardless of any state changes on its inputs until it is switched back to transparent mode. Now Port D can output the second address byte.

Additional eight wires are routed from Port D to address pins on the other side of the SRAM.

Avoiding long wires means implementing a second layer. This is a small, easy project on a breadboard.

Now we connect Port C to the data bus…

… and add a simple R-2R resistor ladder network as Digital Analog Converter (DAC):


Please note that there is a second latch! It will separate the data bus from the DAC while data is written to the SRAM, because otherwise we would get flicker at least. Most likely the horizontal and/or vertical synchronisation would fail.

The last picture shows the complete CHRE circuit including a third layer of address lines, five control lines (latches, SRAM Read/Write, Hsync, Vsync) connected to Port A and some spacers on the second layer.

Now on to firmware development. Hurry up!!! Only 1.5 days to go…

RC 2017/04 – Breadboard Time

It’s a matter of common knowledge that a breadboard isn’t suitable for high frequency circuits. But 0.025175 GHz is almost DC, right? Not at all! In particular, one will find fast edges, even in most digital circuits that are clocked really slow. It’s not only the system clock we have to worry about when prototyping on a breadboard. These fast edges may contain high frequency components up to several hundred MHz.

Nevertheless I’ll start on a breadboard. Why? To test a few things before going any further. Okay, maybe there is also a tiny bit of curiosity involved. 😉

But before we go to the breadboard we need to do some math. Please stay with me! It’s basic arithmetics only. Promise!

The PET displays 40 x 25 characters using an 8 x 8 pixel monospaced font. The corresponding screen resolution is
40 * 8 = 320 pixels horizontal,
25 * 8 = 200 pixels vertical.
Having this resolution for color graphics would be great, as we could print text in the original PET font side by side to color graphis at the exact same pixel size.

As mentioned before a horizontal resolution of 640 pixels equals to a Dot Clock of about 25 MHz in the VGA universe. For a resolution of 320 pixels the Dot Clock is halved, too (25 Mhz / 2 = 12.5 MHz). The plan is to store the color of a pixel in a single byte, so 2 * 2 * 2 * 2 * 2 * 2 * 2 * 2 = 256 colors are possible (Sorry, but I had to keep a promise. For really advanced mathematicians out there that is 2^8).  Thus the circuit will have to spit out a byte per pixel – that is 12.5 megabytes per second!

All video data resides in external RAM. Transfering a byte (pixel) from external RAM to the DAC (Digital Analog Converter that converts pixel data into VGA compatible voltages) requires four steps:

Precondition: RAM is in read mode

1) calculate RAM address
2) feed address to RAM
3) read color byte from RAM
4) send color byte to DAC

Assuming that each of these steps takes a single clock cycle, a system clock of 4 * 12.5 MHz = 50 MHz is needed. The ATmega1284 is rated for a maximum clock frequency of 20 MHz. Oops.

Fortunately two of these steps are unnecessary. We can avoid steps 3 and 4 by connecting the external RAM data bus straight to the DAC. The microcontroller will act merely as a counter then. Wouldn’t it be easier and cheaper to perform this task with a standard resettable counter chip? Well, it’s possible for sure (PET 2001 video circuit consists of 74xxx logic only), but in my view it’s more convenient and flexible to substitute a microcontroller for a bunch of logic chips here. Anyway, in both cases we end up with dealing with two logical steps. The question is if the above assumption is true: How many clock cycles does the ATmega really take to perform these steps? Ooookay, the party is over! We’re talking assembler and count cycles from now on…

Come on! Stop crying! Real programmers do talk assembler and do count clock cycles. End of story.

The ATmega1284 datasheet (in fact it’s more of a databook), chapter 29, Instruction Set Summary, is our friend: It takes one cycle to increment or decrement a register and it takes one cycle to output a register value to an I/O port. Therefore a pixel can be addressed in two clock cycles. That’s great news! Assumption verified! We need a system clock of only 2 * 12.5 MHz = 25 MHz. …
Only? That’s still 5 MHz more than the 20 MHz the ATmega is specified for.

Guess what? First task on the breadboard will be pushing the ATmega1284 to its speed limits. I’ve done overclocking on other AVR chips before. A stable external oscillator is key to maximum speed. The test circuit is pretty simple:

Just the controller, an external crystal oscillator, a bunch of capacitors, a programming header and two oscilloscope probes. All tests will be done at 5 volts. We start at 20 MHz to make sure everything is working correctly when the clock is within specification.

The program is quite simple as well. It’s the setup of Timer2 to toggle PD7 on compare match and an endless loop doing nothing:

According to the datasheet this configuration is specified for a maximum toggle frequency of SysClk / 2. A quick look at the scope verifies that the frequency at PD7 is about 10 MHz. So far so good.

Now we’ll raise the frequency until the circuit stops working correctly. My junk box offers 25, 28.322, 32, 33, 36, 40, 48 and 50 MHz…

Tataaa!!! Aaand the winner is:

33 MHz!!!

Wow! That will give us a reasonable safety margin when running at 25 MHz!

Only three days left and counting…

RC 2017/04 – Real Deal

Although I enjoyed to see the PET 2001 being safe and sound again, it was no big deal as most of the work had been done before this RC. The real challenge will be to build a color high resolution graphics extension board for the Commodore PET 2001 and some later models of the PET/CBM series. I’ll name that board ‘CHRE’ for ‘Color High Resolution Extension’ to illustrate it’s affinity to my RC 2015/7 project (HRE) which was monochrome only.

In contrast to the Commodore C64 the PET/CBM 2000, 3000, 4000 and 8000 models were not equipped with pixel graphics or color at all. Therefore we cannot enhance any internal system, we’ll have to start from scratch. What kind of screen should we use? TV-set? 4k curved OLED? The latter isn’t really a retro thingy, so no. A telly would fit to the 40 characters per line of a PET 2000, 3000 and 4000 model but I’d like to support an 80 column text mode (monochrome) for the 8000 models some day. While it’s possible to display 80 columns on a TV-set, the readability won’t be great. Thus we’ll cancel the telly and stick with a more modern standard called VGA. VGA monitors are still available at stores and The Bay. You may find a VGA input connector even on some present-day display systems.

VGA supports multiple resolutions and color modes. There are two limiting factors when it comes to graphic modes:
1) Dot Clock (frequency with which pixels are illuminated on the screen)
2) Video RAM (memory where pixel data is stored).

For a very common VGA mode of 640 by 480 pixels by 256 colors we would have to deal with a Dot Clock of 25.175 MHz and would need 307200 bytes of Video RAM (for you youngsters out there: that is 0.025175 GHz and 0.0003072 GB). Our PET/CBM CPU is an 8 bit processor running at about 1 MHz. Its max. address space is 64 KB. Even 160 by 120 pixels would require a Dot Clock of more than 1 MHz. Magic aside, how can we support any useful VGA mode? Well, we’ll need some kind of GPU and external RAM.

I’ve choosen the Atmel megaAVR series of 8 bit microcontrollers for the GPU. The biggest (in terms of I/O pins and features) and fastest (in terms of instructions per second) controller of this series is the ATmega1284. That’s not exactly true as its little brother ATmega644 needs a cycle less at jump instructions. It remains to be seen if these few cycles are relevant when calculating any time-critical parts of the firmware (aka cycle counting). The external VRAM will be a BSI BS62LV4006PCP55. That’s a 512K x 8 bit 55ns CMOS SRAM in a PDIP-32 package. The first homecomputers with color graphics used weird memory layouts to cope with memory and speed constraints. Our blisteringly fast GPU and nearly infinite VRAM will hopefully allow for a nice memory layout…

So the plan is to head for the following goals:

– color graphics mode with 160 x 200 pixel resolution at 16 colors or better
– color text mode with 40 x 25 characters at 16 colors or better
– minimally invasive connection to the PET 2001
– implement simple graphic functions in GPU firmware
– implement PET control software as a BASIC extension

Only 8 days left. Oops!

RC 2017/04 – PET Testing

With a reassembled keyboard, a previously repaired CRT and a previously repaired mainboard we’re ready to stick the PET together and fire it up for further testing. We use separte channels on the power supply for mainboard and CRT and turn Over Current Protection on – just in case…

A piece of white paper behind the mainboard will help to localize any magic smoke trying to escape. No, hopefully not! It’s  just to hide the usual random stuff scattered on a bench.

Well, then! Take a deep breath! Cross your fingers! Push power button #1 (CRT)! Oookaaaay. No arcing. No smoke. OVP did not trip. A current flow of about 130 mA sounds reasonable. So far, so good. Take another deep breath and turn on channel #2 (mainboard)!

Uuaaah!!! I’d like to point out that this is not exactly what I was looking for. But no arcing, no smoke, no OVP trip either. About 2.5 A current flow is ok as well.

To the oscilloscope!

Horizontal sync, vertical sync and pixelstream are looking good, so we can’t blame it on the main circuitry. Oh, great! That means we’ll have to do probing on the CRT circuit board – close to the high voltage area. Any volunteers?

Fortunately it was much easier than I thought. Most errors are sitting in front of the machine, as the saying goes. You bet! I knew that the CRT needed 12 V to operate and that was precise what the power supply was set to. Nothing to complain, right? Well, as soon as I looked at the schematic I realized that the 12 V voltage regulator is situated inside the CRT and not on the mainboard. It’s a standard 7812 type regulator, so we have to add the dropout voltage of 2 V to the regulated output voltage. After changing channel #1 to 14.5 V the PET welcomes the RetroChallenge audience:

YEAH! That feels good! 🙂 A trivial BASIC program works as intended:

It’s running at cyberspeed <ahem>, so the last digit shows some ghost pixels. I checked the tape interfaces with an external Datassette and both were fine. But all attempts to get a device running on the IEEE-488 bus (aka GPIB) failed. Before we investigate this issue any further, we need to perform some more comprehensive tests:

Ahhh, it’s been the golden age when humans were able to outplay computers…

Ok, RetroChallenge is no amusement hall. We have a mission! Let’s track the IEEE-488 issue down! There are two 6520 Peripheral Interface Adapters (PIA) in a PET 2001, one acts as IEEE-488 bus controller, the other one mainly as keyboard controller and as datassette port controller to some extend. Keyboard and datassette ports have been verified. A simple swap should tell if the GPIB PIA is dead. When I had lifted the GPIB PIA out of its socket I found some residue on the pins as well as on the socket.

A toothbrush in collaboration with denatured alcohol removed it easily. A quick check (after PIA had been reinserted) verifies we have a working GPIB now! Hurray!




I call that a running system – the PET has been reanimated.  RetroChallenge Mission #1 accomplished.

RC 2017/04 – Keyboard Puzzle

Ok, let’s get started! As the disassembled PET takes a lot of space on the bench, it will be my first goal to put all parts back into the chassis. Most of the issues this computer had when I got it, should have been fixed during the previous repair sessions (which are not part of this RC entry), but it’s more convenient to perform measurements and/or soldering while the mainboard lies on the bench. So testing will go along with the reassembling procedure, just in case something has been overlooked.

Talking to computer systems of the 70s wasn’t like talking to a modern smartphone – we were forced to use a special device named ‘keyboard’ that looked similar to this one:


As you can certainly imagine, it’s been hard work to use such a keyboard, so blood, sweat and tears build up on the device after a while. In this case ‘a while’ translates to ’40 years’ and I was surprised to find only minor deposit on the keycaps…


… but decided to get rid of it anyway. Tissue, denatured alcohol, time and some more sweat got me to the point where the surface started to shine again:


Unfortunately the alcohol partially dissolved the labelling, so I used it only for cleaning the plastics. And to be honest, the whole process was agonizingly boring! It will take a looooong time to choose a suitable detergent for cleaning the top of the keycaps…

During the cleaning it crossed my mind that arranging things diffently might improve the usability of the keyboard.

I really enjoyed this puzzle although I heard a ghostly voice all the time shouting ‘Give me a Q! Give me a W! Give me an E!’ and so on. Can’t remember exactly where I heard this voice in my youth. Sesame Street? Most likely. Everything went well, except the ‘Q’-key. The keycap did not fit and guess what happened? Statler and Waldorf were laughing at me ‘When a spring sprang in spring! <chrrrrhrrhrr><chrrrr>’.

Glueing the keycap to this other light grey thingy wasn’t an option, but a few layers of flimsy PTFE tape made my day.

I’d like to believe that one can tell the difference…

RC 2017/04 – PET/CBM Color Graphic

My entry for RC 2017/04 will be a mingle-mangle of several things that are going through the back of my mind:

The Commodore PET 2001 turns 40 this year and I scored a defective one about a year ago on ebay. Some issues have been fixed already but the system is still disassembled and has to be tested as a whole. I assume the PET would appreciate to be reanimated at its birthday.

The Video Graphics Array (VGA) turns 30 this year. Having a weakness for graphic extensions (see my RC 2015/7 entry) my main entry to RC 2017/04 will be a PET/CBM Color Graphics Extension sending pixels to a VGA display.

The Atmel AVR 8 bit architecture turns 20 this year. So I’ll use this type of MCU for the graphics board.

Celebrating 40 years PET 2001 plus 30 years VGA plus 20 years AVR sum up to 90 years of Retrocomputing. That should comply with the RetroChallenge Rules quite easily.