GAL Address Decoder

[BigEd]

Generally, the output of an uninitialised storage device is not defined - it will be either 0 or 1. So, if you're lucky, you might find the latch initialises to all-zero, but more likely it will come up random. It won't come up floating or in an intermediate state though.

But, I notice this part has a CLR* input: you should use that to power-on reset to all zero.
http://www.ti.com/lit/ds/scls134e/scls134e.pdf

Cheers
Ed

[banedon]

BigEd wrote:

Generally, the output of an uninitialised storage device is not defined - it will be either 0 or 1. So, if you're lucky, you might find the latch initialises to all-zero, but more likely it will come up random. It won't come up floating or in an intermediate state though.

But, I notice this part has a CLR* input: you should use that to power-on reset to all zero.
http://www.ti.com/lit/ds/scls134e/scls134e.pdf

Cheers
Ed

Thanks Ed. I hadn't spotted that and, yes, it should work nicely with the /reset line.

[BigDumbDinosaur]

Incidentally, there's a 74AC version of the 74HC259. In general, 74AC logic is faster than 74HC and has stronger drive. With the way in which you are cascading logic you can use all the speed you can get.

[banedon]

BigDumbDinosaur wrote:

Incidentally, there's a 74AC version of the 74HC259. In ge0neral, 74AC logic is faster than 74HC and has stronger drive. With the way in which you are cascading logic you can use all the speed you can get.

I did intend to buy one, but Farnell (where I get most of my components) don't seem to stock one (tried searching for 74AC259 - nothing comes up).
With regard to speed; Are you talking about for RAM bank swapping itself? I.e. having to talk through the VIA to the latch if a bank needs changing? Obviously, this would only effect changing the swap bank which is why I'm opting for a latch to hold the values.
This is my latest circuit digram with the address decode in the bottom left and the latches in the bottom right.

[EDIT] Or do you mean the logic in the GAL? If so then it should have a propagation of 15ns or less according to the datasheet.

[GARTHWILSON]

If you want to save some VIA pins, it looks like you could make the 259's, the LCD, and the keyboard controller share data lines. As long as only one thing is selected or strobed at a time, their data lines can be shared. You could get all that, and a printer interface, and more, all on one VIA and have the other one left free for experiments.

[banedon]

I've already read your excellent primer with regards to this and was going to tackle that at a later point (along with RS232C which I find slightly daunting lol).

[GARTHWILSON]

I have an RS-232 primer at http://wilsonminesco.com/RS-232/RS-232primer.html . (My apologies-- if you like pictures and diagrams, well, very few of them are in the first half of the article. Hopefully you'll still find it very clear.) RS-232 was later called EIA-232 and most recently TIA-232-F (based on what organizations adopted it as a standard, and the "-F" ending is the latest revision), but if you say "RS-232," everyone knows what you mean. It's an old industry workhorse that still very good for simplicity, long cable lengths, the fact that you can make up your own connectors, it's easy to view on an oscilloscope and troubleshoot if necessary, and probably other virtues I'm forgetting at the moment.

[BigDumbDinosaur]

banedon wrote:

BigDumbDinosaur wrote:

Incidentally, there's a 74AC version of the 74HC259. In ge0neral, 74AC logic is faster than 74HC and has stronger drive. With the way in which you are cascading logic you can use all the speed you can get.

I did intend to buy one, but Farnell (where I get most of my components) don't seem to stock one (tried searching for 74AC259 - nothing comes up).
With regard to speed; Are you talking about for RAM bank swapping itself? I.e. having to talk through the VIA to the latch if a bank needs changing? Obviously, this would only effect changing the swap bank which is why I'm opting for a latch to hold the values.
This is my latest circuit digram with the address decode in the bottom left and the latches in the bottom right.

[EDIT] Or do you mean the logic in the GAL? If so then it should have a propagation of 15ns or less according to the datasheet.

I'm referring to the prop time through the 65C22 added to the time required for the '259 to react to whatever comes out of the 65C22. Any GAL these days will be more than fast enough.

[cbscpe]

Hi Banedon,

any reason why you connect the '259 to the VIA port, it's actually a waste of VIA pins in my opinion. I always use them as they have been used in the Apple II computer. You need a /SEL which is qualified with PHI2 and covers a range of 16 addresses. Then I connect D -> A0, S0 ->A1, S1 ->A2 and S2 -> A3. /CLR is connected to /RES so you have a clear initial state. Then a simple LDA instruction can throw any of the flip-flop in the '259.

cheers

Peter

[banedon]

cbscpe wrote:

Hi Banedon,

any reason why you connect the '259 to the VIA port, it's actually a waste of VIA pins in my opinion. I always use them as they have been used in the Apple II computer. You need a /SEL which is qualified with PHI2 and covers a range of 16 addresses. Then I connect D -> A0, S0 ->A1, S1 ->A2 and S2 -> A3. /CLR is connected to /RES so you have a clear initial state. Then a simple LDA instruction can throw any of the flip-flop in the '259.

cheers

Peter

Hi Peter
It's mostly because I want to keep things off the 6502 address and data buses as much as possible. That way if I really need to put something on them then I don't have to worry about having already overloaded them.

But going with your idea, is this what you're suggesting? The only part I'm a bit uncertain of is where /SEL comes from. I assume a VIA pin as in my circuit diagram (please ignore it saying PA0- it should say PB0)?
If so, then surely then you have a disjunction between the right address being on the address bus and /SEL (/LE) going low.

[EDIT] ...or would use use the decoder to intercept a certain range (as small as possible) and then enable the latch select (/LE) pin? I'd have to introduce mode address pins if I did that to avoid wasting massive amounts of address space.

[cbscpe]

Hi banedon,

yes except something is odd with our 74HC259, pin 14 is the latch enable and should be the /LATCH_SEL signal and not +5V, the LATCH_SEL has no pin number. Have a look at it. Of course I would have the GAL decode a small (minimum 16-byte) range and only this range enables LE of the '259. I would add a 74ACT138 between the IO_SEL pin and the IO devices.
As for the load, a 74HCT259 is neglectable. I have 65C816 working with about 15 CMOS devices connected to the address bus without any problem.

cheers

Peter

[banedon]

cbscpe wrote:

Hi banedon,

yes except something is odd with our 74HC259, pin 14 is the latch enable and should be the /LATCH_SEL signal and not +5V, the LATCH_SEL has no pin number. Have a look at it. Of course I would have the GAL decode a small (minimum 16-byte) range and only this range enables LE of the '259. I would add a 74ACT138 between the IO_SEL pin and the IO devices.
As for the load, a 74HCT259 is neglectable. I have 65C816 working with about 15 CMOS devices connected to the address bus without any problem.

cheers

Peter

Sorry, that's my fault. I used a generic '259 device from Eagle CADs library and added on the /LE (/LATCH_SEL) manually.
I'll see if I can get a proper TI one.

My concern about adding the '259 in the way that you're suggesting is that I will have to either sacrifice a large amount of address space or lose more pins on the GAL to decode a 16 byte range. I think that would mean I would have to decode A15-A4 (12 pins worth) as opposed to A15-A12 (4 pins) that I'm using at the moment.

With regard to the I/O; I'm using one address decode pin out of the GAL which connects to /CS2 of all of the VIA's and then A4 to CS1 of VIA#1 and A5 to CS1 of VIA#2.

[GARTHWILSON]

banedon wrote:

It's mostly because I want to keep things off the 6502 address and data buses as much as possible. That way if I really need to put something on them then I don't have to worry about having already overloaded them.

At viewtopic.php?t=1908, Daryl says he put my 4Mx8 SRAM module on his SBC-4 and ran it at 12MHz with no problem. The SRAM module has 8 512Kx8 SRAM ICs on it, and he had other things on the buses as well, with no transceivers. WDC's pin drivers seem to be much stronger than the data sheets let on. Keep in mind of course that a CMOS input offers no DC load. The only load is a few pF of capacitance. That's not to say you don't still have to pay attention to inductance and transmission-line effects of traces and connectors though. No amount of drive strength can overcome problems there.

[cbscpe]

Hi banedon,

I then suggest that you "export" some functions from your GAL to a more appropriate device. E.g. add a AND gate for the IRQs (e.g. 74HCT21, this part of your computer is not time critical at all), or you could add a 74ACT138 to decode the IO range (this however is time-critical so you need a fast version).

cheers

Peter

[banedon]

Ok you've both convinced me . I'm going by what I've read elsewhere that you shouldn't over burden the buses - and I have no experience as to when this might happen.

What about having a couple of GALs in parallel? One intercepts the I/O and ROM and latch, the other does the RAM?
At least until I look at using PLCCs.

I.e.:

Or perhaps: