~io a5 a4 VIA
0 0 0 neither
0 0 1 VIA 1
0 1 0 VIA 2
0 1 1 both
It's obviously a question of never addressing the io/3x range, but generally I'd prefer something that physically excluded the possibility of two devices sending to the bus at the same time.
On occasion (rare, I know! ) my software has been known to do something other than that which I intended.
There's a lot to be said for a 74xxx138 (choose family to supply the delay your system can handle): two low and one high enable, and decoding of three address lines... so using A4-6 and an output - either polarity - for an iosel, and A7 and A8 if desired to add up to 32 VIAs!
I agree. The 74xx138 is a versatile chip. You might also consider a single 74xx139 which could perform double-duty of sorts... That is, providing clock qualified read/write signals as well as four I/O device select strobes which could free several pins on the GAL... And, you could still connect two VIA's to one I/O select line.
Um, isn't there a risk there of inadvertently selecting _both_ VIAs?
It may be useful if for example you want to start the timers of both simultaneously. I can do that on my workbench computer, and in the 6502 Primer, but I don't think I've ever taken advantage of it, nor has it ever resulted in any trouble.
~io a5 a4 VIA
0 0 0 neither
0 0 1 VIA 1
0 1 0 VIA 2
0 1 1 both
Thanks for posting that. I can never read Michael’s drawings—the color combinations foil me every time.
With that truth table, it’s clear a decoding train wreck is waiting to happen.
Quote:
It's obviously a question of never addressing the io/3x range, but generally I'd prefer something that physically excluded the possibility of two devices sending to the bus at the same time.
On occasion (rare, I know! ) my software has been known to do something other than that which I intended.
What you note is akin to what can happen in a unit in which RDY is directly connected to VCC. The programmer didn’t mean to execute a WAI instruction, but due to a bug in the code, one got executed and RDY tried to short out VCC.
Avoiding this sort of thing is “defensive design,” which is essentially nothing more than anticipating circuit conditions that may lead to undesirable states. Oftentimes, expediency contradicts defensive design and leads to obdurate hardware bugs. My first POC unit was a victim of weird I/O problems because I didn’t use VDA and VPA to qualify addressing, as recommended in the 65C816 data sheet. It was expedient to not use those signals, but proved to be a mistake.
Quote:
There's a lot to be said for a 74xxx138 (choose family to supply the delay your system can handle): two low and one high enable, and decoding of three address lines... so using A4-6 and an output - either polarity - for an iosel, and A7 and A8 if desired to add up to 32 VIAs!
Since I/O is where the bulk of the decoding is needed, using a 74x138 eliminates most of the GAL’s raison d’être, eh? Might as well just build the decoding with discrete logic, as only a few more pieces of it would be required.
65C02 Mapping w/Discrete Logic
The above is a three-chip solution (not counting the decoder), including the qualified read/write. The memory map won’t be as granular as can be achieved with a GAL, but there would be chip selects for eight I/O devices.
Last edited by BigDumbDinosaur on Thu Nov 28, 2024 7:52 pm, edited 1 time in total.
You know me, BDD: I prefer discrete logic every time. But that's just my design ethic, I suppose - it hurts my brain to think of a decoder PAL eating all those milliamps!
Um, isn't there a risk there of inadvertently selecting _both_ VIAs?
It may be useful if for example you want to start the timers of both simultaneously. I can do that on my workbench computer, and in the 6502 Primer, but I don't think I've ever taken advantage of it, nor has it ever resulted in any trouble.
You’d have to somehow guarantee the two VIAs can never be simultaneously selected during a read cycle so major data bus contention doesn’t occur.
You know me, BDD: I prefer discrete logic every time. But that's just my design ethic, I suppose - it hurts my brain to think of a decoder PAL eating all those milliamps!
I recall that when programmable logic became a big thing toward the latter 1980s, power consumption was a common complaint with designers. All those internal gates gotta be fed, whether they are doing any useful work...or not. It’s gotten somewhat better over the years, but a single GAL eats up a lot more juice than a handful of CMOS gates. The ATF22V10 is rated at up to 130 mA in standby for the 5, 7 and 10 nanosecond versions. During active switching, that can rise to 150 mA.
Ironically, the ATF1504 CPLD is more economical with power usage, despite having far more capability than the 22V10.
Last edited by BigDumbDinosaur on Fri Nov 29, 2024 3:11 am, edited 1 time in total.
And 150mA is starting to be noticeable if you are, for example, driving your circuit from a standard USB port... particularly if you need another high-current part in there as well.
There's a lot to be said for a 74xxx138 (choose family to supply the delay your system can handle)
Note that the '138 is very slow in 74HC, 74HCT, 74LS, and several others. The 74FCT138CT is fast though.
BigDumbDinosaur wrote:
GARTHWILSON wrote:
barnacle wrote:
Um, isn't there a risk there of inadvertently selecting _both_ VIAs?
It may be useful if for example you want to start the timers of both simultaneously. I can do that on my workbench computer, and in the 6502 Primer, but I don't think I've ever taken advantage of it, nor has it ever resulted in any trouble.
You’d have to somehow guarantee the two VIAs can never be simultaneously selected during a read cycle so major data bus contention doesn’t occur.
Well, I've been doing it this way for over 30 years, and like I said, it has never been a problem. I've never accidentally selected two at once to read from, unless it happened in a crash scenario where I had to use the reset button anyway; and even then, the pulse duration would have been far too short to do any damage. I/O addresses to access should, in almost all cases, be constants anyway, like VIA2PB, and the assembler won't make a mistake and set an extra bit in the address constant.
And 150mA is starting to be noticeable if you are, for example, driving your circuit from a standard USB port... particularly if you need another high-current part in there as well.
Observation has also shown that the output voltage of a USB port tends to sag under any significant loading and might not even reach 5 volts with light loading. Not helping any are those minuscule wires in a typical USB cable—a not-insignificant series resistance.
USB ports are good for powering thumb drives and charging phones, but they suck as a power source for a 6502 system. Lacking an actual computer-grade power supply, a 9 volt DC wall wart with at least a 500 mA rating, driving a 7805 regulator on the PCB, is better than any USB port.
There's a lot to be said for a 74xxx138 (choose family to supply the delay your system can handle)
Note that the '138 is very slow in 74HC, 74HCT, 74LS, and several others. The 74FTC138CT is fast though.
You mean the 74FCT138? That part has a VOH of 3.3, even when VCC is 5 volts.
I’ve used the 74AC138 in my discrete designs. Switching speeds for 74AC138 and the 74AHC138 are about the same as that of the 74FCT138, but with a higher VOH in a 5 volt system.
You mean the 74FCT138? That part has a VOH of 3.3, even when VCC is 5 volts.
Yes, FCT. Going too fast again. I'll go back and fix it.
I was forgetting that I'm using pull-up resistors to help it get higher output voltage. Since the logic-low output is so strong, and since it's being used for I/O address decoding and only one output at a time will be low and usually all outputs are high, you can make the pull-ups pretty heavy without any significant effect on the current consumption of the computer.
) my software has been known to do something other than that which I intended.
It was expedient to not use those signals, but proved to be a mistake.