Hardware VGA Episode 03: Readout module
HTML-код
- Опубликовано: 27 авг 2024
- In this episode of the Hardware VGA series, we explain and test the Readout module, which generates the video memory addresses of the character and attribute values that the pixel generator will need to render pixels.
The schematics, simulation files, GAL equations, etc. are on the Github site: github.com/dav...
The "elevator music" in the Readout module overview part of the video is "Brazilian Bossa Nova Jazz Acoustic Guitar Podcast Music" by Denis Pavlov: pixabay.com/mu.... I feel a little bad for describing it as "elevator music" because it's objectively great. Anyway, you can support Denis here: buymeacoffee.c...
The idea of using elevator music during a discussion of a technical topic is, of course, an homage to @CuriousMarc. I'm assuming you're already subscribed to his channel, but if you're not, geez, subscribe already.
Contents:
00:17 Introduction
00:52 Overview of the Readout module (with elevator music)
13:44 Simulation
15:33 Prototype hardware
16:17 Testing the prototype hardware
22:02 Ground bounce (and how we might deal with it)
24:14 Conclusions and next steps
Based on viewer feedback, I've uploaded an alternate version of this video without any background music during the narration: ruclips.net/video/r6SRkNa0OIo/видео.html
Take a look to see if the part you need is available in 74AHC ... nearly as fast as 74ACT, but doesn't switch quite as hard so no ground bounce. (Though, those are all CMOS-level parts so might be an issue with the low output drive of the GAL... not very many 74AHCT...)
I think I did look for 74AHCT parts and didn't see the ones I needed. It really is annoying that GALs don't guarantee more than 2.4V as the output high.
Have you considered storing the character data and the attribute data in physically separate RAMs? This would allow both to be accessed simultaneously by the read out module, requiring only 12 bits of counting. I _think_ it should still be possible to arrange the RAMs so that the CPU interface to them still appears as contiguous pairs of bytes instead of separate blocks, e.g. by using A1-A12 from the CPU as A0-A11 to the RAMs, with the CPU's A0 line instead of A12 as the CS/~CS line. Alternatively, maybe having them as separate blocks might be better anyway from a programmer's PoV?
I did think about putting character and attribute data in separate RAM chips. I didn't realize that you could play tricks with A0 to make characters and attributes appear to be contiguous: that's a very clever idea. Allowing parallel loading of character and attributes would potentially double the throughput, which would be nice, although there's plenty of time to load characters and attributes sequentially, even with the relatively slow 70 ns RAM chips I'm using.
@@davehohacks a further idea relating to the need to start the RAM accesses in advance of the start of the visual area (and during the "previous" scan line) - I'd be tempted to drop an 8-bit shift register ('595 ?) as a configurable delay on the HSYNC line near the final output stage (such that it only affects the monitor's version of that signal).
Alternatively some timing diagrams depict the 48 clocks of the horizontal back-porch being the start of the current line, and not the very end of the previous one, such that the line actually starts at the rising edge of HSYNC. This perhaps complicates the clock counters compared to starting the visual area at clock zero, but IMHO it sure beats having to think about doing stuff while the previous line is still going.
@@RayBellis Good ideas! I did consider starting scanlines with the back porch rather than the visible area, but eventually decided it was easier to just increment the vertical count early. (Although, now that I'm thinking about it, these are more or less equivalent ideas.) That ended up being a fairly easy change. I didn't think about delaying hsync with a shift register. Thinking about this right now, you could put all of the signals in a FIFO memory pretty easily and avoid the issue entirely.