Electronics > Projects, Designs, and Technical Stuff
Sharing SRAM device in bettween two bus masters - how was it done back then?
<< < (3/4) > >>
bsudbrink:

--- Quote from: Jr460 on November 26, 2018, 11:08:34 pm ---How about the CPU has lower priority and you use the wait line on the CPU who the video is reading the RAM.

--- End quote ---

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.
dmills:
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.
westfw:

--- Quote ---
--- Quote ---How about the CPU has lower priority and you use the wait line on the CPU who the video is reading the RAM.
--- End quote ---

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?
--- End quote ---
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) 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.)
[/url]
bson:
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.
Ian.M:
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.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod