Now that I’ve completed a basic 6502-based computer, my next milestone is to implement a video output system. The Apple ///’s video system was unique, in that it provided similar video modes to the Apple II, as well as additional modes to display higher resolutions with many more colors.
Additionally, unlike the II which was designed to only output an NTSC composite signal out of an RCA-style jack, the Apple ///’s video subsystem was designed to output TTL level RGB component video through a 15 pin monitor connector. This same RGB-centered configuration would not be seen again until the Apple IIgs. In fact, the Apple IIgs color monitor can be used on the Apple ///, although the pins for the Red, Blue and Green signals need to be swapped. Otherwise odd colors will be shown on the IIgs monitor.
It’s only after this RGB signal is generated that is it is mixed down to a simple black-and-white composite signal for use with composite-only monitors through the RCA connector.
The NTSC portion of the video output depends on standard clock signals, including a 3.5MHz color burst reference signal, and horizontal and vertical scan signals. These are generated from the timing circuitry based upon the 14MHz master clock which is then halved, then halved again and again to create the various synchronized clock signals needed throughout the ///.
In order to learn the video section, I’m starting with the basic 40 and 80 column text modes. The ///’s text modes differ from the ][ in that the (40 column) characters themselves can have color face and background, opposed to the b/w only text in the ][. This is because the first page of video memory contains the ASCII text and the second mirroring page of memory contains the color information.
To generate the text characters, the /// continuously cycles through each horizontal line of the screen. As it does, it figures out which ASCII characters in that row are in the related section of RAM. As it does, it figures out which row of the 7 rows containing the pixels making up that character it needs in order to lay out that line of pixels. The first row of the default in-ROM ASCII character set is generally blank.
I’m not giving the mechanics justice in my explanation, but basically this is how text and graphics are created in the ///.
As I began deconstructing the chip components that make up the video section, then rebuilding it on a breadboard, I quickly realized that, although the effort helped me understand how the circuitry worked, it really didn’t add any benefit to my end product of a simpler, reduced chip-count system.
I then turned my attention to trying to re-implement the video subsection on an Arduino board. However, in my research and testing, I concluded that a stock Arduino, clocked at 16MHz would still not be fast enough to replicate in code what the chips were doing.
I wanted to still stay true to a native chip-based system. So, in a moment of quiet reflection, I asked myself the tried-and-true metaphysical question any good electrical engineer should: WWWD (What Would Woz Do) ?
And then the idea came to me in a whisper of that familiar zealous voice. Probably the same thing someone else with more experience would have instinctively thought right away: build the video section in an FPGA.
I’ve never investigated FPGAs before, because the elitist retro-enthusiast side of me considered it cheating. So I don’t know much about them other than they do exactly what I wanted to accomplish: take a bunch of TTL logic chips and put them into one chip. Almost the same way as the IWM (Integrated Woz Machine) in the IIGS – a floppy disk controller card on one chip.
I’ve downloaded some circuit-design CAD software which will export the necessary file to write an FPGA, and I’m painstakingly duplicating the timing division and video circuitry from the schematics. Next step will be to acquire the proper FPGA and take it for a spin.