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.

RC 2016/1 – Let’s try again!

My entry to Retrochallenge 2015/07 was quite successful but left room for improvement. So I’ll take a new attempt based on the experience with the previous entry:

The project for Winter Warmup will be a follow-up to HRE aka High Resolution Extension aka monochrome 648 x 256 pixel graphics board for Commodore PET/CBM 8000 series:

Goal #1: replace the breadboard by a printed circuit board

Goal #2: improve firmware (character support; more sophisticated data transfer protocol; circles)

Goal #3: implement CBM control software as a BASIC extension

Goal #4: add color capabilities in the remaining time (no, just kidding).

Talking about goal #4: What happens when you leave a nerd alone with a full pint of beer and a crazy idea on New Year’s Eve? Yep! He will come up with an even more insane idea!

So this is goal #4 defined and explained in detail:
– add VGA port
– add color mode with 160 x 200 pixel resolution at 8 colors
– add firmware functions similar to monochrome mode
– buy ticket valid for 10 meetings with psychologist

EDIT: Unfortunately I haven’t had time to get this project going. It’s still in my mind, though. To be continued some day …

EDIT: The ‘some day’ will be RetroChallenge 2017/04 and here is the link to my entry.

RC 2015/7 – Follow up #1

A month has past since the end of Retrochallenge 2015/07 and … I miss the feeling! Yep, I miss the Retrochallenge feeling. That is, working on a challenging project just for fun. Specifically working on interesting stuff for ancient computers. Ok, I assume you’re one of the 0.0236986301 ppm of world population who do understand what I’m talking about if you’re reading this at all.

Therefore I won’t wait for RC 2016/01. I’ll continue to work on my RC 2015/07 project and turn the proof of concept into a working prototype. To be honest I already restarted the project and didn’t tell you. 😉

Finding the Vsync bug that showed up in the demo video (RC 2015/7 final post) has been the first task. As I have mentioned before it is critical to count every single cycle within the video output routines. And what happens when you work after work ’til late night? You sometimes can’t count anymore! The error was caused by a not equally timed program path. There is a reason why they call an oscilloscope “electronic engineer’s best friend”. Would have been clever to verify the counted cycles with my friend somewhat earlier…

Optimizing the code gave me some additional free cycles so I could increase the resolution from 640 by 250 to 648 by 256. It’s nothing to write home about but the extended resolution allows to draw small symbols outside the CBM text region which might come in handy in certain cases.

One page consumes 648 * 256 / 8 = 20,736 bytes of external SRAM. The size of the installed SRAM is 131,072 bytes (128k * 8 bit). How do we make use of the remaining memory? Several framebuffers! The ATmega162 can address 64k of external SRAM minus 1k internal SRAM minus 256 bytes registers. These 64,256 bytes contain 3 framebuffers and leave 2k for future ideas. The other half of the SRAM chip can be reached by banking. That equals to six independend framebuffers and two 2k free memory blocks in total.

The framebuffers can be used in two modes. In mode 0 all six buffers are orthogonal. In mode 1 only the three buffers in bank 0 are available for drawing while the three buffers in bank 1 are used to implement a second ‘color’. You may call this lower level of brightness ‘dark green’ as well as ‘transparent green’. The following image shows the extended resolution by a border drawn outside the CBM display real estate and explains the meaning of ‘dark/transparent green’.
interlaced02Please take a closer look at the characters ‘T’ in the bottom half of the screen and ‘1’ in ‘Line 21’ as well as the disruption of the right border line. These seem to be side effects of the wild wiring – sometimes present, sometimes absent. EDIT: No, it’s a problem of the CBM mainboard that persists even if I disconnect the HRE completely. Talking about the characters only. The line disruption is most likely a problem of the HRE. And no, it’s not the dust on my camera.

To get the second ‘color’ two associated framebuffers at the same address on different memory banks are used. The video output routine switches between these two buffers at a frequency of 25 Hz. If a pixel at a specific location is set in both framebuffers it will be displayed at full brightness. If it is set in one framebuffer only it will be displayed at half brightness. Due to the fact that CBM text is always displayed at full brightness it will shine through in areas of ‘dark green’.

Unfortunately the applicability of this second ‘color’ is very limited: A refresh rate of 25 Hz implies severe flickering. Adjusting the potentiometer at the back of the screen to reduce overall brightness might help a bit but won’t provide a good display quality.

I plan to modify the user port communication but haven’t come up with a better solution. A first attempt to implement a more sophisticated protocol killed the balanced timing.