EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: Yansi on November 26, 2018, 10:28:53 pm
-
Hi!
Just as a mind exercise, I have kind of thought (to certain detail) how a composite video generators capable of displaying text may have been done in the past, in numerous 8-bit microcomputers.
The principle of generating video signal is rather simple: A text containing SRAM, character generator ROM and a couple of X any Y position counters, that generates pixels into lines and rows, reading the SRAM and CGROM sequentially.
What I do not understand and could not come up with a simple solution is, how could I share the SRAM device in between the precise periodic reading action of the video generator, while accessing the SRAM for R/W of text asynchronously from the main CPU?
I know that some 8-bit microcomputers had dedicated functionality to ease situations like this, but the question is, how would one solve this?
Supposed I have 8 pixels wide character on the display. That means that for at least every 8th pixel I need to read a character from the video SRAM. So for example having a line of 256 pixels (up to 32 characters per line) and while the video line is 64us (PAL), I need a pixel clock of 4MHz (because 256/64us = 4MHz). So every 2 microseconds I need to pull data from the SRAM.
How am I supposed to interface the SRAM to both the synchronous reading at 500kHz rate (4MHz/8pix wide chars), while being able to R/W access the SRAM from an external bus master, that operates at a completely asynchronous clock? Suppose I want to make an external peripheral for an 8-bit microcomputer, that would display text using composite video. So no modifications possible to the host system. It just provides its address and data buses, /WR and /RD signals.
Is there any obvious solution to it, that I have missed?
Please do not suggest using dual port SRAM. Or FPGA, or dedicated video chips. That is not defined as "back then" when 7400 TTL chips were the ducks guts and memory extremely expensive.
Just curious how things may have been done.
Thank you for any tips.
-
So okay, maybe found one way to implement this easily enough, with maybe acceptable drawbacks:
Just give the CPU system higher priority. Whenever it wants an access, it gets it. In that case, pixel values displayed may be corrupted. That may or may not be an issue, can't tell how big.
However in this case, switching the 1K SRAM (32x32 chars) in between the CPU host system and the video HW may be done with just four interface ICs like 74244/74245. (probably only 4 chips required).
-
So okay, maybe found one way to implement this easily enough, with maybe acceptable drawbacks:
Just give the CPU system higher priority. Whenever it wants an access, it gets it. In that case, pixel values displayed may be corrupted. That may or may not be an issue, can't tell how big.
However in this case, switching the 1K SRAM (32x32 chars) in between the CPU host system and the video HW may be done with just four interface ICs like 74244/74245. (probably only 4 chips required).
You might also be able to use a 74LS/74HC574 to clock latch the data bus.
-
How about the CPU has lower priority and you use the wait line on the CPU who the video is reading the RAM.
-
BrianHG: That solution I have described needs bus switches, not bus registers. 574 is a register (octal DFF), 244 (245) is just tristate (bidirectional) switch. :-//
Jr460: For example 8051 and compatible do not have any wait lines. Hence why I have written "I know that some 8-bit microcomputers had dedicated functionality to ease situations like this" - I think the 8080 system had the wait signal or sort of.
More interested in how that could be implemented without such signals?
-
Dual port SRAMs were available "back then." I recall using them in a design back around 1980 as shared memory between an 8085 master CPU and a slave processor. I think the slave was an 8748.
-
Updates to the video RAM were done during the blanking periods.
-
For example, the Apple ][ video memory works that way (afair):
The memory chips were fast enough to allow for two memory cycles within one CPU cycle. So an MUX switches address and data busses to the CPU for one memory cycle and to the video circuitry the other cycle. No need for the CPU to wait for anything.
Other schemes include CPU access while blanking periods, so the CPU had to wait, or vice versa - that lead to gross distorted screen while CPU access (e.g. the ZX81 way in fast mode).
Anyway, back then the memory often was fast enough to provide "parallel" CPU and video control access by the way mentioned above running at a simple and straightforward scheme.
-
On the Atari ST, for example, the mc68000 needs four clock cycles for a RAM access cycle.
During two of them, the CPU doesn't do anything to the RAMs.
These two cycles are used by the video hardware (Shifter) to read out video information from RAM, effectively interleaving RAM access without need to have one chip waiting for the other. You just need fast enough RAMs.
-
BrianHG: That solution I have described needs bus switches, not bus registers. 574 is a register (octal DFF), 244 (245) is just tristate (bidirectional) switch. :-//
Jr460: For example 8051 and compatible do not have any wait lines. Hence why I have written "I know that some 8-bit microcomputers had dedicated functionality to ease situations like this" - I think the 8080 system had the wait signal or sort of.
More interested in how that could be implemented without such signals?
Sorry, my mistake of habit. I was thinking about latched AB buss transceiver ICs, here is the real part number:
SN74ACT652, or SN74ACT646, or, 16 bit = 74ACT16652
You can also look at universal bus transceivers, but, they are 18 bits: SN74ABT162500
Bus exchange/Mux/Demux ICs exist. Basically 12 bits IO on one side, and 2x 12 bit IO channels on the other side, with separate output enables, internal latches or D-Registers depending on part number. Good if you get fast static ram, and swap between A bus and B buss at 2x clock cycle compared to the bus transfer cycle of your CPU and graphics side.
Take a look at this IDT part, bidirectional 24:12 analog switch bus fet. Yes, it's a bidirectional without any direction controls, just select A or B to be connected together.
https://www.idt.com/document/dst/qs33x257-datasheet (https://www.idt.com/document/dst/qs33x257-datasheet)
The way I used to do it before FPGAs was when the system clock went High, I operated the memory on the 'A' bus, when the clock went low, I operated the memory on the 'B' buss. Or, I divided the system clock by 2 doing this if my processor bus clock operated every 4 clock cycles using the HC652 and HC16652 ICs. The control logic driving the latch times and OEs was feed by a very fast GAL22V10 PLD which received the clock and bus controls from the system CPU. Note that I also got this wording with DRAM as well, but, it was only fast enough for 8 or 14 Mhz CPUs and the video display port was read only for the 14Mhz version.
-
How about the CPU has lower priority and you use the wait line on the CPU who the video is reading the RAM.
That is basically what the Cromemco Dazzler did. Not only was the CPU denied bus access during video reads, so was any other bus device. This could end up causing problems for time critical devices like floppy controllers. Interestingly, hard disk controllers, which came later, tended to have on board buffer memory so they weren't usually bothered by the Dazzler.
-
Smart designers back then tried very hard to NOT make the video and CPU asynchronous, it was much easier if everything ran off the same clock (This allowed wait or bus request to be used to tristate the processor to allow the video hardware to drive the bus).
Multiplexing was sometimes as simple as connecting the video circuit to the address bus thru 220R resistors and having the cpu drive right over the top of them, no tristate buffers required (Apart from the ones in the CPU).
Regards, Dan.
-
How about the CPU has lower priority and you use the wait line on the CPU who the video is reading the RAM.
Jr460: For example 8051 and compatible do not have any wait lines. Hence why I have written "I know that some 8-bit microcomputers had dedicated functionality to ease situations like this" - I think the 8080 system had the wait signal or sort of.
More interested in how that could be implemented without such signals?
Pretty much ALL microprocessors had some sort of wait-state capability. Memory was slow and buses were long. DMA capability was also common (another master would say "I want the bus" and the microprocessor would stop and tri-state itself pretty quickly.
The 8051 is neither a microprocessor, nor is it from "way back when." I don't recall ever seeing an 8051-based display. Or other multi-master system. In that age, 8051s were not very available, not easily programmable, and not very cheap compared to real microprocessors; and you'd have needed most of the same external components anyway.
The most common technique, I think, was to essentially implement a sort of pseudo-dual-ported memory. Memory chip access times were ~250ns, and instruction times were about 1us, and displays need access about every 1us, so in theory there is plenty of time for them both to access all the memory they need. It may get a bit tricky, though.
IIRC, the 6502 was especially popular becasue it was very predictable when it wouldn't need access to RAM. That's one of the reasons there were so many 6502-based personal computers with "clever" video setups (Apple [], Commodore PET/C64/etc, Atari 800...)
So... "Display gets priority" wasn't hard.
"CPU gets priority" wasn't really that bad if the display had dedicated memory (IIRC, the original IBM PC CGA card had CPU priority by default, or you could specifically have SW wait for blanking intervals. I wrote a terminal emulator and didn't pay attention to blanking, so some operations (scrolling, "insert line") would cause slightly glitchy displays. But still quite usable.)
You could wait for blanking intervals in software. This tended to slow things down. I had a weird TVT board that used a Z8 for it's comm and display processing that worked that way. 300bps normal speed (matching the modems of the day) worked fine (some sort of HW hack for scrolling.) "Erase to End of Line" could take 1.6 second, though !!
There is no shortage of "how to" text from that era online.I can recommend: "The Best of Byte Volume 1" 1977) (https://archive.org/details/best_of_byte_volume_1_1977_06) which I think contains several display projects
Don Lancaster's Books[url=http://Especially the "TVT Typerwrite Cookbook" and "The Cheap Video Cookbook" (which I think talks a lot about 6502 hacks.)] Especially the "TVT Typerwrite Cookbook" and "The Cheap Video Cookbook" (which I think talks a lot about 6502 hacks.)
(https://www.tinaja.com/ebksamp1.shtml)[/url]
-
On the Z80 you could probably sync video to RFSH#. You'd know it wouldn't be accessing memory during these two T cycles. Although it might be more suited for dual banked video memory I suppose since it's not periodic.
-
Not periodic isn't a problem - you just need a FIFO buffer between the RAM and the pixel serialiser. When /RFSH goes active, if the buffer's full, do nothing, otherwise fetch the next byte from RAM. Obviously the Z80 must run at a significantly higher clock speed than the rate the pixel serialiser needs bytes to get enough /RFSH cycles to keep the FIFO from running out. 16:1 will work for non-pathological code. That puts a severe limit on the resolution and colour depth that can be supported even with fast Z80.
You'd probably be better off splitting the VRAM into two interleaved banks (even vs odd address), each with its own FIFO for the video output bytestream, so that during any memory access to one bank the other could be read to get a byte into its FIFO, and during /RFSH, both could be read.
The pixel seraliser would alternate reads between the two FIFOs.
-
The 8051 is neither a microprocessor, nor is it from "way back when." I don't recall ever seeing an 8051-based display. Or other multi-master system. In that age, 8051s were not very available, not easily programmable, and not very cheap compared to real microprocessors; and you'd have needed most of the same external components anyway.
Somewhen around 1990 ... 1993, I've designed two 8051 based display systems as the display units for a piece of test equipment. They had one of these early B/W graphic LCD modules (one 640x400, the smaller one 240x128), that had to be driven with pixel clock, pixel data and H / V sync. Basically it had a video memory that was read out by some logic circuitry (all 74HCxxx style ICs), with time shared access granted to the external bus of the 8051. Because of the very predictable timing of the 8051, one could do two memory cycles (one video, one MCU) within one MCU cycle, so both had equal priority access without wait states. Just the same way many 6502 designs did as stated above.
Edit: found a hand-drawn schematic of the controller (posting it just because)
-
I've designed two 8051 based display systems ... graphic LCD modules ... that had to be driven with pixel clock, pixel data and H / V sync.
Neat; thanks for posting.
I've bought a couple of similar surplus displays; spec sheets always show pixel clocks designed to update the display at TV-like frequencies, but I've always wondered how arbitrary those rates were. After all, the LCD doesn't contain circuitry that is inherently tied to 60Hz...
-
Yep, there were actually a few simple video terminals based on 8051's AFAIR. Obviously nothing high-resolution, but for simple text terminals that did the trick.
-
Wow, thank you guys, some very valuable input has been put here. :-+
I have also learned about the existence of 6845. Had a brief look at it, however it seems, it does not produce the sync mix for composite video. They write in the datasheet, it can be connected to "video processing circuitry to generate a composite video signal. ". However I could not find any example of such circuitry, that would produce a composite video compliant sync signal, rather than some garbage that "just sometimes works". Do you have any examples of that?
Thx, Y