0

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:

  • 640x480 pixel
  • 25.175 MHz
  • Color mode: 8x8 pixel blocks with one color each (so the whole image fit in 8K RAM)
  • Text mode: ASCII character set

But I´m struggling with the video memory. Please take a look at my schematic (without the text mode).

enter image description here

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?

  • 3
    There is a YouTube vlogger named Ben Eater with an absolutely excellent channel discussing digital design that even I can understand. :-) He recently did a two part video on building the worlds 'worst' video card (his words, not mine), which you might find useful. After walking thru timing and support circuitry, he ultimately pulls his video from a static EEPROM - but I suspect there is a lot of useful information along the way that might help you in your design. Part One is here: youtu.be/l7rce6IQDWs - followed by Part Two here: youtu.be/uqY3FMuMuRo – Geo... Oct 13 '19 at 10:52
  • Thank you, but I already know these videos :) These videos give me the first impressions how to do it. – Kampi Oct 13 '19 at 13:01
  • So you are planning a low-res graphic mode of 80x60 pixels plus a high-res text mode? Why don't you use block graphic chars then? – Janka Oct 13 '19 at 22:06
  • Honest, as this is a one-off, try to salvage an EF9365 – Janka Oct 13 '19 at 22:11
  • I want use block graphic chars which are stored in an EEPROM. In text mode the content of the display RAM should be interpreted as ASCII character and so the data should be used as address for the EEPROM. In graphic mode the data from the display RAM gets interpreted as RGB data byte for a color cell with a size of 8x8 pixel (like in the C64). – Kampi Oct 14 '19 at 6:01
1

(Preface, this is RC.SE, not EE.SE, so less appropriate for such questions - so I wont go into schematic details)

a) Video RAM Access

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.

- Synchronized Memory

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.

- Separate Memory

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.

- Use Of a Dedicated Chip

Add a 9928 or 9950, have it do all the video mode, RAM and whatsoever handling and concentrate on video output circuitry.

b) Character ROM access time

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


Why a text mode at all?

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.

2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.