I´m planning to build a small computer system, based on the W65C02 from Western Design Center. This computer system should also have a VGA interface with a graphic and a text mode, defined with the following parameters:
But I´m struggling with the video memory. Please take a look at my schematic (without the text mode).
I don´t know how I should realize the CPU interface for the video RAM. One idea was to use double buffering, so the VGA controller uses another memory than the CPU or is it enough to only write to the memory when a blank phase is active. This would result in 639 pauses with 6,3 µs each and one pause with 1,4 ms per frame (the CPU should run with a clock of 1 MHz).
The next thing is: How do I implement the text mode. My first idea is to use the video data as an address for a character EEPROM (some small EEPROM containing the ASCII character set) and the pixel address bits 0 to 2 for the pixel of the character, stored in the EEPROM. But the EEPROM has an access time of 70 ns. Is this enough? Assuming that I use the textmode and the pixel address is 0, so the first pixel of the EEPROM will be read 70 ns later and then the pixel address is 1. So I have some delay. Is this assumption wrong? How was the text mode in some older PC systems realized?103Kampi
(Preface, this is RC.SE, not EE.SE, so less appropriate for such questions - so I wont go into schematic details)
As usual there are many ways. The most common are synchronizing CPU speed and video to use 'the' other half. Or separate both RAMs and access only during pause. Or use a dedicated video chip already offering separation.
Eventually the most common in way used in 6502 systems - at least by number of sold units since every Apple II or Commodore does it. After all, a 1 MHz 6502 needs 2 MHz memory to function, but uses only every second 'slot' for access - leaving half the bandwith for some other device. In this case Video. To build it, a bunch of muxes are needed to access RAM from either (video, CPU) side. While it seams to offer simple access, it does have several disadvantages
Grabbing memory from already limited address space
Grabbing quite a lot for higher resolutions
CPU clock must be in sync with video clock, resulting in rather strange CPU-Speeds (*1)
For a new system I'd rather not go that way. It got way to harsh limitations.
This needs about the same set of muxes, but now not handled directly by the CPU, but via a few latches. While adding a tiny overhead in writing to RAM, it simplifies not only design and removes most of the obstacles from synchronized memory but as well
Speed of CPU can be set independent of Video and vice versa
Frees up lots of rare CPU address space as only 3-4 memory locations are needed within CPU address space, leaving all the 'rest' for program and data
Access latches can be organized independent of memory structure, offering a application centric view of like Rows and columns in separate registers
The last one will considerable simplify low level programming, more than offseting the added instructions to set registers, as now conversion between row/column and memory address is done in hardware.
Add a 9928 or 9950, have it do all the video mode, RAM and whatsoever handling and concentrate on video output circuitry.
Well, it depends on all the timing you want to have. You got to do the math yourself, figuring out how it fits - after all, that's the most basic task here. If you're doing something like classic home computers, it'll be more than enough. Then again, doing it at 100 Hz and high resolution you may want to rethink the whole concept
Text modes are a classic way to save on RAM need for image storage. Quite handy back when each KiB counted, and large flat bitmaps were a high end luxury. But here you got high resolution bitmap, so why bothering with a text mode at all, complicating the design? Draw them, like next to any computer does nowadays. It'll be just 8 bytes instead of 1, done at quite low level, so not much slow down either. Especially when using separate memory (*2). Offering much freedom in character design and combination of graphics and text as well. There's a reason the very first Mac got bitmap (*3).
*1 - Think the odd speeds of various Commodores, making them run as well at different speeds depending on video standard, creating hurdles for timing dependant software. Or the variable clock length of an Apple II.
*2 - With readable latches a simple INC ROW will do all necessary address handling.
*3 - And as well why the planned 6809 got replaced by a 68k - having a considerable bitmap in 64 KiB address space sucks.
How do I implement the text mode.
The usual method is to send the video data Byte to the 8 higher address inputs of the character ROM to select the character pattern, and the low bits of the video line counter to the low ROM address inputs (eg. A0-3 for an 8x16 font) to select the pattern row. The character ROM then outputs 8 bits which are latched and serialized to pixels via a parallel to serial shift register. Since the ROM is only read once at the start of each character row, the access time just has to be less than 8 pixels.
But will 70nS be fast enough for VGA? At 25.175MHz and 640 pixels (80 characters per line) the pixel width is 39.7ns. Multiplied by 8 pixels per character gives you ~310ns for ROM access - plenty enough.
If you want individually colored characters then you also need color attributes stored in another area of video RAM (which could be a small separate RAM chip eg. 2kx8 for 80x25 characters). This is read at the same time as the character ROM, and its output latched while the row pixels are being sent. The upper and lower nibbles of the latched attribute Byte are fed into a 4 bit 2-1 mux switched by the pixel bit to color each pixel. The 4 bit output is then converted to analog to produce 16 foreground and 16 background colors.
© 2012 - Nathan Osman - [About]