• Please review our updated Terms and Rules here

Circuit Design for "invisible" RAM sharing with a Z80 CPU?

Bruce Tomlin said:
If I understand correctly, the point is to avoid the infamous "TRS-80 snow", and also to avoid slowing down the CPU during accesses because cycle counting is a thing, etc. But if you put a super-fast Z80 in there, does cycle timing even matter anymore? At that point you might as well just put in wait states.
Click to expand...

Well, it's a little more than snow avoidance; imagine if you had a TRS-80 Model 1 and were trying to run *code* from video memory; you'd probably end up with a mostly black screen. That's kind of what I'm trying to do here, make *all* the RAM in the system (potential) VRAM...

Robbbert said:
My first computer (kit computer) had what you call "unified" memory. The video circuit would ask the Z80 to give up the bus (by using BUSREQ), read the current video page and display it. At the end it would hand control back. So the CPU ran at half speed, but there was no snow.

The great thing with this system is that by using a certain OUT command, you could choose any part of memory to be the video page.
Click to expand...

Yeah, and honestly if I wasn't trying to be (partially) TRS-80 compatible I think the "cost" of doing that on a completely novel architecture would probably be mostly fine; if the CPU were running at 10+mhz only half the time it'd feel mostly fast enough. The main drawback would be you'd probably need to blank the screen whenever you did high-speed I/O.

Poking around I stumbled across this javascript toy that lets you describe digital timing diagrams in the form of JSON files, and I used it to draw out roughly what I think I'm going to try programming into the GALs for the first attempt.

wavedrom(5).png

"vbread" and "chread" are the two cycles that per character that the video hardware needs access to memory; "vbread" is reading and latching the framebuffer for a pixel pattern or character value, and during "chread" that latched value is added to an address offset to get the actual pixels to latch into the output shift register. The "maddr" line represents what owns the address bus (and, effectively, data bus and memory control signals) for each clock period; the remaining 75% of the time the CPU gets control. This diagram shows three possible clocks for the CPU; "sloclk" is the pixel clock /8 and has a "normal" 50/50 duty cycle, "medclock" is effectively pixel clock divided by 3/8th by running the CPU running at pixel clock/2 half the time with every-third low duty cycle being 3x normal length, and "fstclock" gives you 5/8th full speed twith a kind of weird duty cycle bracketing the video reads.

(That last one is super aggressive and is too fast for the rated speed of the Z80s I have on hand so maybe I'll skip that one. It *feels* like it might be just possible to do 6/8th speed by fussing with the clock phases but it's pretty unnecessary; 5/8ths speed for the pixel clock I'm planning to use is going to be like 9mhz, which is a stupid fast TRS-80. The 3/8th speed is over 5mhz, which is about as fast as a Model I could ever go with a lot of hacking. )

I know from earlier testing that doing vbread and chread in single ticks seems to work fine, so... cautiously optimistic this might work? Nothing ventured nothing gained, I guess.
 
Re: BUSREQ and BUSACK - see my post suggesting DMA.
The 8257/8237 was a bit less demanding in that it has a lot idle cycles in between requests. I guess the question here is how important is "immediate" access. Could the DMA activity be held to 1 out of every 3 request opportunities, for example.
 
Eudimorphodon said:
The main drawback would be you'd probably need to blank the screen whenever you did high-speed I/O.
Click to expand...
Yes that is quite true. This particular system (Dick Smith Super-80) turned off the screen for cassette i/o, but you'd need to do that for anything that required exact timing. You'd probably have to see how it affected floppy-disk i/o, for example.
 
On the 8085, we routinely did disk DMA along with video refresh with no problems. However, with graphics on a low speed MPU, maybe that won't work. Another argument for a separate video memory?
 
Chuck(G) said:
Re: BUSREQ and BUSACK - see my post suggesting DMA.
Click to expand...

I was going to implement the bus sharing with external multiplexers instead of busreq/busack because of the aforementioned unpredictable latency problem if I’m asking the Z80 nicely to formally hand it over.

Essentially the idea here is if the CPU actually does qualify all I/O at the clock transitions then it shouldn’t be wise to the fact that somebody else pulled the rug out from under it during the first part of that long low cycle; all that matters is that the Z80 is back in control long enough before the positive transition that the bus states are stable? It shouldn’t know anything is happening at all… hopefully. Maybe. That’s the Hail Mary.
 
Chuck(G) said:
As an aside, what were you thinking about using for RAM?
Click to expand...

For the breadboard, probably a single AS6C4008 512Kx8 55ns SRAM. (Or maybe a 1008 128K for the smoke test, I have both lying around.) It should be good for up to close to 20mhz. In surface mount there are similar chips as fast as 25ns for only $4 or so.

I have a stash of 74670’s I was thinking of using as a paging circuit, although that’s a bridge I’ll burn when I come to it.
 
Hmmm, so the SRAM you'll be using is going to be a lot faster than the 200 nsec DRAM that we used back in the x80 days. I wonder if you could double-speed clock your SRAM accesses, such that the CPU would be oblivious to the display activity.
 
I think my biggest nagging worry is just overall cumulative propagation delays in the multiplexing goo and the state machinery. I kind of wonder if I should preemptively get some faster grade buffers than the LS/HCT I have on hand.
 
Nowadays, the logic family hardly matters WRT cost. Recently, I ordered some SOIC 74x74 chips and found that the ACT variety were cheaper than the LS ones.
 
Yeah. The local outlet (which is irritatingly closed on Saturdays now) has ALS, F, and ACT flavors of ’245s and ‘573s (the major tinkertoys I’ve been using) for around the same price in breadboard friendly format, I guess I need to remind myself what the speed hierarchy is…
 
Unfortunately I ended up with zero time to do actual work on the project this weekend, but I did do a little more light reading and I stumbled across a thing I'm wondering if I need to worry about at all. Looking in the datasheet for the CMOS Z80s I have on hand on page 34 it says that the input voltages for the I/O pins are TTL compatible (0.8v low, 2.2v high), but it says the clock input voltages should be between -0.3v - 0.45v low, VCC-0.6v - VCC+0.3v high. Is this actually correct/slash/an actual requirement?

It seems like most people are driving their Z80s with simple LS or HCT oscillator circuits/dividers, but I wouldn't think the voltage swing from those would be as wide as this datasheet implies. Is there some kind of high-swing/high-speed driver circuit I should stick after the division circuit? (With the 6502 I was just driving it off the output pin of a GAL and that seemed to be fine, but the datasheet says the ATF family GALs is only "guarunteed" for TTL-like voltage swings between 0.5-2.4v.)
 
Mostly what I've seen is the Z80 clock being driven by an XCO, which I believe is LSTTL.
If you want closer-to-rail swings, use a CMOS driver.

This isn't nearly as awful as some of the early stuff. I've got a few TO-100 8-bit memories here that claim to be DTL level compatible but demand a 7 volt clock.

Contrast with the National Semi PACE MPU--all I/O levels were +8V high, except for the clock, which was +5V.
 
I guess I'll play it by ear. The datasheet for the ATF22V10C, which *is* a CMOS part with TTL compatible inputs, is kind of coy about what to really expect from the output swing; it give a "minimum" output voltage but no "typical" or "max". If worse comes to worse running it through a 74ACT buffer to get it closer to the rails will hopefully fix it
.
(I did find an old design note for the NMOS Z80 that talked about using pull-ups to increase the clock swing when driven from TTL; it also has a circuit for using a transistor for an "active pullup", which... basically amounts to a Schmitt trigger? This fragment makes pull-ups on their own sound *very slow*.)
 
On the bright side the datasheet for the CMOS one confirmed that the max pulse width for either the low or high phase of the clock is "DC", so the theory of holding a clock phase indefinitely while "something else" steals the bus should be sound, unless there's something critical I've missed. The challenge mostly looks like it's going to be keeping switching times for the bus multiplexers and control signals tight enough.
 
You must log in or register to reply here.
Back
Top