Another look at the Carte Blanche.

After we have designed the Carte Blanche we hoped that the Apple retro-computing community will start using it for their own projects. After all Apple 2 is all about the users doing their own development. Unfortunately that didn't quite happen for a while. Then two things happened recently: Steve made an HDMI plug-in board allowing direct connection to an LCD panel with up to 24 bits per pixel. Charlie designed a new video only configuration that supports a GS specific video.

It does not however support either the HDMI interface or the Double Hi Res video of the 2e and above.

So I have decided to revisit my project. Adding HDMI connectivity was not much of a problem – just a few extra output pins to be driven and somewhat more accurate video timing – HDMI proved to be a bit less forgiving than the plain old analog VGA. As a result I had to rework the video a lot deeper than previously expected.

I've been playing with FPGA Apple re-implementations for quite a while now. The original FPGApple used an analog VGA monitor. That made things simple: as long as the vertical and horizontal scan rates were within limits you could view the picture. A real Apple used NTSC for a display – 60 Hz and about 16 KHz horizontal scan rate. The standard VGA has also 60 Hz vertically but twice the horizontal rate. Real easy: double the scan lines and shift the pixels out at twice the Apple's speed – 28 MHz. Works great on an analog monitor but look very ugly on an LCD. At the time (circa 2000) that was not a big issue, but 10 years later virtually all the monitors are LCD.

Every LCD screen has a native resolution – the number of actual pixels. Suppose the screen is 1024x768. If you try to show a 640x480 picture full screen it will have to be scaled by the display's controller. That works reasonably well. If you watch it from a distance that is. Consider watching a standard resolution TV program on your HDTV. It does just that : up-converts the picture to fill up the whole panel. Another story is the pixel clock. If the picture is 640x480 at 60 Hz the LCD expects a 25 MHz pixel clock. If it finds a 28 MHz clock instead things become really ugly. So to feed an LCD one needs to rescan at 25 MHz (for standard VGA timing). Not a problem – we get honest 640 pixels and use 560 of them leaving some blank space, just as a real Apple did on a TV. Except that you can't adjust the width to fill the whole screen.

So the first order of business is a VGA compatible scan generator. No problem there. A 50 MHz system clock is used and is divided by 2 to get the pixel clock. SRAM is used to hold the frame buffer. At 50 MHz clock the memory cycle is 20 ns. The used parts are rated 15 ns so we are OK. Even in the DHR mode a byte is read from the video memory once in 7 pixel intervals. So we only use 1/14 of the memory bandwidth. The other 13/14 could be used to write to the frame buffer. In reality the 6502 can only access the slot once in 1 us – 50 memory cycles and will only write to memory once every several microseconds, so less than 1% of the memory bandwidth is needed here. We still have to make sure that Apple doesn't try to write to SRAM exactly when video is reading it. So we latch the data and address whenever the 6502 writes to (video) memory and do the actual write after a video access time slot.

So the new prototype configuration for the CB implements the DHR mode. Well, kind of. Interpreting the bit patterns to get realistic colors is somewhat tricky. The first implementation is quite simple and borrows the main idea from Apple PAL circuitry. DHR pixels are shifted into a register, 4 at a time. The color is determined by this pattern. If the current bit is “1” (which is current? Last one?) then a pixel is ON of the color found from the 4 bits. If “0” - the pixel is black.

So there are at least two problems: the not so solid colors and color “shadows”. Some “shadows” are present even on a real Apple, but my simple implementation was much worse. So two changes were made:

1. Simple logic turns a pixel white if 3 other pixels to the left or to the right are also “on”.

2. If the color calculated from the group of 4 (DHR) pixels is the same as a previous one (from the 4 pixels before the current ones), we turn solid colors on.

Here is the result. It would probably be best to provide a switch to turn this filter off if needed.