Page 4 of 5
Re: Memory-mapping logic - a thought
Posted: Mon Sep 18, 2017 2:05 pm
by commodorejohn
Okay, that's about what I thought I remembered, thanks. So I still need to sit down and work out the worst-cases, but at a glance I think it'll work for my purposes - I've got 15-20ns SRAMs (386/486-era cache chips) I can use, and a couple 45ns UV EPROMs, so that'll help in getting total access time down.
Oh, additionally, on the timing front, is there anything to be wary of when mixing 74-series logic families? I went with HCT by default because that's what bluesky's boards are using, but I picked up most of the requisite parts in AC and one in LS as well because it was cheap and the listed propagation delays were lower. Looking at the datasheets it looks like they all work fine with a 5V supply and get along with TTL logic levels, but as I've said the low-level electrical stuff is largely Greek to me so it can't hurt to ask.
Re: Memory-mapping logic - a thought
Posted: Mon Sep 18, 2017 4:25 pm
by GARTHWILSON
Again, it's in the 6502 primer, this time in the "
74xx Logic Families and Timing Margins" chapter.
Re: Memory-mapping logic - a thought
Posted: Tue Sep 19, 2017 12:32 am
by commodorejohn
Okay, so here's the access times for the parts I ordered for the design, according to the datasheets:
Code: Select all
Part Typical Max
HCT00 10 25
HCT14 18 32
HCT688 14 51
HCT02 10 25
HCT10 9 25
And the equivalent parts from faster logic families, if there doesn't wind up being any reason not to go that route:
Code: Select all
Part Typical Max
AC00 8
AC14 11
LS688 17 23
AC02 12
AC10 8
So the signal paths and their best- and worst-case times for both HCT and mixed logic should, I believe, look something like this:
Code: Select all
Signal Path BstHCT WrstHCT BstMix WrstMix
/MREQ c02 > x688 > x14 > bus 62 113 58 64
/IORQ c02 > x688 > bus 44 81 47 53
/WR c02 > x00 > bus 40 55 38 38
/RD c02 > x14 > x00 > bus 58 87 49 49
/ROM /MREQ > x02 > x10 81 163 78 84
/RAMA /MREQ > x02 > x02 82 163 82 88
/RAMB /ROM > x10 89 171 86 92
/RAMB looks better than I was afraid of - it's hardly worse than /ROM in the worst case and the difference should wash out since the SRAMs are three times as fast as the EPROM. Granted, the worst case is...not great, but even a few MHz would work for my purposes, and the best-case for HCT based on typical propagation delays is nearly as fast as for mixed logic.
Of course, in the end I'm just going to wind up going with the traditional "run it with faster and faster crystals until it starts acting glitchy, then dial back" approach, but it was good to sit down and work this out.
Re: Memory-mapping logic - a thought
Posted: Tue Sep 19, 2017 12:57 am
by commodorejohn
Dang, though, factoring in the 30ns address setup time for the 14MHz 65C02, that's only going to make about 4 MHz in the best case with mixed logic. This might not be as viable a design as I thought.
Just curious, if I went with a more standard design based around a '138, I don't suppose it's as simple as just wiring multiple select outputs together onto the chip-select of the device that any of them should select? Am I correct in my understanding that (where this even works) that functions as a logical-OR and would thus be useless for an active-low select line?
Re: Memory-mapping logic - a thought
Posted: Tue Sep 19, 2017 2:34 am
by commodorejohn
Thing I just realized: /MREQ is totally unnecessary for the top half of memory since I'm going to be locating the I/O page in the bottom half. Need to give this a think.
Re: Memory-mapping logic - a thought
Posted: Tue Sep 19, 2017 2:52 am
by GARTHWILSON
Of course, in the end I'm just going to wind up going with the traditional "run it with faster and faster crystals until it starts acting glitchy, then dial back" approach, but it was good to sit down and work this out.
From the
clock-generation page of the 6502 primer:
- If you want to see how fast your creation will go before it starts having problems, instead of buying a whole series of crystals or oscillators at incrementally higher frequencies to try, you can make yourself a variable-frequency oscillator (VFO) as shown in this forum post or the link it contains. Connect it only temporarily for the test and gradually turn the frequency up until you find problems, and then measure that frequency. A frequency counter is best, but you can get within perhaps 5% by measuring the period on an oscilloscope and inverting the number. Then get whatever standard-frequency crystal oscillator happens to lie in the 70-75% area, to make sure you'll have some safety margin for when operating conditions are not ideal (like higher temperature, an additional bus load when you expand the computer, or a slightly lower power supply voltage).
(Also linked there is
this forum topic and my post about a faster VFO.)
You don't need to have a bunch of crystal oscillators. The VFO allows you to gradually turn the speed up with a trimmer until you observe problems. Ideally you'd have a frequency counter to determine what that speed is; but you can also get an accurate idea from how fast a loop you write in the software executes.
Just curious, if I went with a more standard design based around a '138, I don't suppose it's as simple as just wiring multiple select outputs together onto the chip-select of the device that any of them should select? Am I correct in my understanding that (where this even works) that functions as a logical-OR and would thus be useless for an active-low select line?
Right. You cannot just wire-OR '138 outputs.
Re: Memory-mapping logic - a thought
Posted: Tue Sep 19, 2017 4:19 am
by BigDumbDinosaur
Just curious, if I went with a more standard design based around a '138, I don't suppose it's as simple as just wiring multiple select outputs together onto the chip-select of the device that any of them should select? Am I correct in my understanding that (where this even works) that functions as a logical-OR and would thus be useless for an active-low select line?
Right. You cannot just wire-OR '138 outputs.
You could with a bunch of Schottky diodes and a relatively low resistance pull-up. They would add 5-7ns to the prop time. It's a Mickey Mouse© solution, however.
Re: Memory-mapping logic - a thought
Posted: Thu Aug 02, 2018 5:55 am
by commodorejohn
Okay, after spending way too long not working on this project, I decided to give it a total rethink. As much as I like only devoting a modest amount of the address space to ROM, as long as we have write-through to RAM and can switch it out that's really not a big deal anyway, and a 32KB split makes everything so much simpler. With that in mind, the new plan:
- ROM select is generated with a three-way OR between the inverse of A15, a /ROMEN enable line provided by one of the I/O pins on the 65C22 board, and the /RD signal on the RC2014 bus. If any of these is high, /ROM is high.
- High RAM select is generated with a NAND between A15 and the output of an OR between /ROMEN and /RD. If A15 is high and either ROM is disabled or a write operation is being performed, /RAMB is low.
- Low RAM select is generated with a NAND between the inverse of A15 and the /IORQ signal on the RC2014 bus. If A15 is low and /IORQ is high, /RAMA is low.
I believe the logic is all correct here; I checked it in Logisim and it seems to give the results I was expecting. And the parts count is nicely minimal too: aside from the memories, all that's required are a 74x00 quad 2-input NAND and either a 74x4075 triple 3-input OR or a 74x32 quad 2-input OR (the former is faster in HCT logic, while if I go with mixed logic it's actually faster to cascade two OR gates on a 74F32 to get the 3-input OR.) If I worked everything out correctly, these are the approximate propagation delays:
Code: Select all
Part Typical Worst
74HCT00 10 22
74HCT688 14 51
74HCT4075 8 24
74AC00 2 8
74LS688 12 23
74F32 3 7
Signal Path TypHCT WrstHCT TypMix WrstMix
/IORQ c02 > x688 > bus 14 51 12 23
/RD c02 > x00 > bus 10 22 2 8
!A15 c02 > x00 10 22 2 8
/ROM !A15, /ROMEN, /RD > x4075 18 46
!A15, /RD > x32 > x32, /ROMEN 8 22
/RAMA /IORQ, !A15 > x00 24 73 14 31
/RAMB /ROMEN, /RD > x32 > x00, A15 28 68 7 23
Thoughts? Anything obvious I'm missing?
Re: Memory-mapping logic - a thought
Posted: Thu Aug 02, 2018 6:13 am
by BigDumbDinosaur
...if I go with mixed logic it's actually faster to cascade two OR gates on a 74F32 to get the 3-input OR.)
Your mixing of logic types may give you some trouble. In particular, I don't recommend the use of 74F or 74LS logic in a new design. Use 74AC32 if you really need that fast prop time—it's slightly faster than the 74F32, but far less power-hungry. Also note that in some cases, 74HCT devices are slower that 74HC and generally in the same speed range as 74LS.
The 74LS688 equality comparator is a relatively slow device and being LS, will have weak fanout, which may give you some grief. If you can, please post a schematic (in black and white) so we can see what you've got planned.
Re: Memory-mapping logic - a thought
Posted: Thu Aug 02, 2018 7:08 am
by GARTHWILSON
Check out the SN74LVC1G332 single 3-in OR gate, 5V, CMOS, 32mA drive current (even pulling
up), 3.5ns max @ 85°C, 3ns if you hold the load down to 15pF. (It doesn't tell how many ns, max or typ, @ 25°C.)
Data sheet at
http://www.ti.com/lit/gpn/sn74lvc1g332 or
http://www.ti.com/general/docs/lit/getl ... leType=pdf
Re: Memory-mapping logic - a thought
Posted: Thu Aug 02, 2018 7:35 am
by BigDumbDinosaur
Those things sure are dinky!
Re: Memory-mapping logic - a thought
Posted: Thu Aug 02, 2018 7:51 am
by commodorejohn
Your mixing of logic types may give you some trouble. In particular, I don't recommend the use of 74F or 74LS logic in a new design. Use 74AC32 if you really need that fast prop time—it's slightly faster than the 74F32, but far less power-hungry. Also note that in some cases, 74HCT devices are slower that 74HC and generally in the same speed range as 74LS.
Good to know, thanks. As I've said, the low-level electrical side of this stuff is something I really need to brush up on but don't have a particularly good handle on at the moment, so this kind of advice is much appreciated.
The 74LS688 equality comparator is a relatively slow device and being LS, will have weak fanout, which may give you some grief. If you can, please post a schematic (in black and white) so we can see what you've got planned.
Yeah, I think this was already mentioned upthread. Suffice to say that the '688 is part of bluesky's RC2014 65C02 design so I'd have to do some serious rejiggering in order to remove it from the design; in light of that, it seems simpler to just roll with it (and I
do like the limiting of the I/O area to a single page of memory!)
I'll try and work up a schematic, though.
(As far as fanout goes, it should only be going to the one section of the memory-mapping logic and two peripheral chips - is that likely to be enough to cause issues?)
Dayum, sir. That is a nice piece of silicon to know about. Unfortunately I don't think my skills extend to SMT work at this point in time, and it doesn't appear to be available in a through-hole package...
Re: Memory-mapping logic - a thought
Posted: Thu Aug 02, 2018 1:08 pm
by Dr Jefyll
That is a nice piece of silicon to know about. Unfortunately I don't think my skills extend to SMT work at this point in time, and it doesn't appear to be available in a through-hole package...
I think you'll find SMD parts easier to work with as you grow accustomed to them. And a 6-pin device has the advantage that most of the pins are located on a corner
(giving wider access to your soldering iron).
Of course a custom PCB is ideal, but for more casual hacking you can use an adapter like this...
... or do a dead-bug approach directly on your through-hole protoboard. As you see below, a SOT-23 sits quite comfortably on a .1" grid (and even more comfortably on a .05" grid).
BTW, these "1G" gates don't all use the same pinout for power and ground -- some use the corner pins, and some (like the one in my diagram) use pins midway along each side. Also, some devices can run on voltages up to 5V and others are recommended for 3.3V or less.
For more info, including a device selection guide, see
this post.
-- Jeff
Edit: here (below) is one prospective mounting scheme. The corner pins attach to leads running to adjacent holes, and the center pins go straight down. Assuming these pins are Vcc and Gnd, the bypass cap could be soldered on the opposite side of these same holes.
Re: Memory-mapping logic - a thought
Posted: Thu Aug 02, 2018 2:55 pm
by BigEd
If you placed the part at 45• over one hole, I think that would give you a fair bit of room.
Re: Memory-mapping logic - a thought
Posted: Thu Aug 02, 2018 3:11 pm
by Dr Jefyll
Not a bad idea, especially if the power and gnd pins are on the corners. But if they're midway along each side then the connections to the bypass cap are no longer at the minimum length (although they're still quite short, considering how small the entire assembly is).