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!