That would work, although it's a bit clunky. You'll need to carefully analyze everything so that unavoidable differences in prop time between the two GALs will not cause unforeseen logic states.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yeah I know . I think I'll design things this way for now, but seriously look at what it'll take to implement CPLDs.

Hi banedon,

If you consider to use a second GAL then I would suggest that you make some design changes.

I always have a global /WR and /RD signal that are qualified with PHI2 to create a global output and write enable signals thus I take advantage of the fact the output enable access time of memory is faster than the chip enable access time and the fact that write enable pulse is not required to be as long as the chip enable pulse.



These signals then go to the /OE and /WE of the memory chips. And if you want they can be used to support chips which really require a /WR and /RD as the SC26C92 et.al.

Instead of having individual select signals for the 65xx peripheral chips I would create a special 65xx IO signal that is asserted with a special pattern for A4,A5,A6,A7 so you can take advantage of the two chip select available on the 6522 and 6551




this signal is connected to /CS2 of the VIA and the /CS1 of the ACIA

A4 is connected to the CS1 of VIA1
A5 is connected to the CS1 of VIA2
A6 is connected to the CS1 of VIA3
A7 is connected to the CS0 of ACIA

with this you save some pins on the GAL and at the same time the IO65XX makes sure that only one 65xx peripheral is active, regardless of accidental access outside the IO65xx range.

For the other peripherals, i.e. the two 74HCT259 you then can fill the gaps not used by the above ranges and another IO SEL for future expansions that covers the range from $80C0 to $80FF



Note that the LE signals are qualified with PHI2. I would not put a critical IO to the addresses right after the RAM, so that's why I omit the range $800x. This is because when you run a memory test that looks for the top of RAM he will probably try to read/write to $8000. For example many basic interpreters do that at a cold start.

So your first GAL would look like



In this way you have grouped all time-critical signals into one GAL. All signals where different delays could be a problem into one GAL. The other GAL would be like the following grouping the other signals.



The difference in delay to /RAM and the delay to /SRAMA15+6 is not critical it is only important that they are stable before the leading edge of PHI2.

Note I used the normal GAL/PAL syntax that is used by most assemblers for the binary operations which is different to #&! used in WinCUPL.

cheers

Peter

Many thanks, Peter. if you don't mind me asking; when you say a global /RW and /RD signal would they be generated by both GALs or just the one or would they come from a different IC?
Also a few questions with regard to your GAL pin layout:
1) I cannot seem to find the /RAM select pin
2) Is /SPKR (speaker?), /KBD (keyboard?), STRB (strobe?) for future expansion?
3) Also, what are /ANN, /LC, /INP?
4) Doesn't PHI2 need to come in on pin 1 (CLK/I)?
The answers are probably staring me in the face, but I cannot see them .

Hi banedon,

first my apology to confuse you, the first GAL layout was a wrong copy & paste from another project I'm working on. I edited my posting and put the correct GAL layout to match what I wrote. The global /WR and /RD signals are only create by the first GAL (now corrected) and are used for memory and other non 65xx IO chips.

So my corrections should answer questions 1), 2), 3) there are no such signals in your projects

4) PHI2 as seen for the GAL is a normal signal, that in your case it is the clock for the CPU is not important to the GAL. The CLK input of the GAL has a completely differnt meaning and is only used when you want to clock the output macro cell registers, here is an example for the use of the CLK signal for my dual-rate 65xx CPU clock


With the syntax .R you indicate that the output should change on the leading edge of the now real clock input on PIN1. Only when you have registered outputs PIN 1 changes from normal input to the CLOCK for the OMLC registers of the GAL.

cheers

Peter

No worries. I was just a bit confused .

I can sort of see were you're going with this, but given that the GALs are both the same part number, why would there be a timing issue if I were to, say, put the /ROM select in the second GAL and the /RAM select in the first?
Or is this trying to get the /RD and /WR outputs in the same GAL as the time critical ones so that they're better timed together as they all come form the same device?

/RD and /WR outputs should ideally be generated by the same GAL to guarantee exclusivity at all times.

Your timing concerns would come from the fact that identical GALs, even ones manufactured from the same wafer, are not guaranteed to have identical prop times. The manufacturer will guarantee that the prop times will not exceed the advertised value (e.g., 10ns pin-to-pin) but won't state the minimums, which can and often do vary from part to part.

Also, it's important to understand that prop times are always stated as pin-to-pin, even in cases where a pin is used as an intermediate logic node. Hence if an output's state is determined by a logic statement that uses a pin node, the prop time from input to output is actually 2x the advertised prop time.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Hi banedon,

as BDD said, you must not rely on propagation delays of GALs for signals that must have matched timing. There are several ways to respect that rule.

As for /RD and /WR, they typically are created by the same GAL as they need the same input signals (RW and PHI2). If you create both signals in the same GAL you do not need to duplicate all these input signals on two GALs, that could save PINs on one of the GALs. In our case timing is not mandating that they must be created by the same GAL because of the way they are generated and the way they are used. As both signals are gated with PHI2 and as RW is stable well ahead of the leading edge of PHI2 there is no risk that both signals are asserted at any time (asserted in this case means "low" as they are inverted). Also in regards of /RD /WR created on the same GAL as /ROM and /RAM, this is also not necessary. What is important is that /RAM or /ROM are asserted and stable some time ahead of either /RD or /WR being asserted. So the LOW phase of PHI2 must be longer than "tsua" (address setup time) of the CPU + "tpd" (propagation delay) of the GAL.
As we already have seen, /RD and /WR are never asserted at the same time and can only be asserted when PHI2 is HIGH. So during the HIGH phase either /RAM or /ROM (exclusively) and either /RD or /WR (exclusively) are asserted only. So you never have a read conflict and you never have spurious writes. At the end of the HIGH phase of PHI2 the timing again is a bit more critical as RW and the address output of the CPU shortly after the falling edge of PHI2 become invalid.At least RW and A0..15 are stable during the whole HIGH phase of PHI2. But normal GALs are fast enough to make sure that /RD and /WR are relyably de-asserted and stable once PHI2 is low, regardless of the holdtime (as long it is >0ns) of the RW signal provided that PHI2 arrives at the GAL before the invalid RW.
Due to the fact that we rely on the /RD and /WR signal being gated with PHI2 you must not gate /RAM or /ROM with PHI2 and the GAL(s) creating /RD and /WR signals should guarantee stable outputs in all cases of RW and PHI2 signals (i.e. they must be comfortable with RW being invalid short after PHI2 transitions to low without creating spikes).
It is no problem to move /ROM and /RAM to the second GAL in case you need more IO select signals.

cheers

Peter

That's a good analysis.

Something to always keep in mind in systems in which the 65C21, 65C22 and/or 65C51 are used is that chip selects and RWB for those devices should not be qualified by Ø2 and must be valid before the rise of Ø2. These devices "know" about the 65xx bus cycle and "know" that D0-D7 is not valid during Ø2 low.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

ok... I need to try and get this right in my mind.

- All devices will pick up address and data from the buses on /PHI2 going high
- 65Cxx devices do not need to have their chip selects (CS) and R/W delayed so they enable at /PHI2 going high
- All non-65Cxx devices (ROMs, RAMs, etc.) should have their R/W delayed until /PHI2 goes high

This would mean that if I have a R/W signal from the 65C02 and /WR &/RD (phased with the /PHI2 being high) from the GAL decoder, then I need to supply the R/W directly to 65Cxx devices and the /RW and /RD to all the devices.

If I have the above correct, then do you need to delay the CS of non-65Cxx devices or would you enable the CS straight away, but delay R/W?

not quite...

65xx devices require that chip select, RW and address signals are valid and stable on the leading edge of PHI2. This means that the chip select signals must be generated without any delay, that is they must not be qualified with PHI2

Then there are other devices (e.g. SC62C92 DUART) require that the chip select and the address signals are valid whenever the write enable or the read enable signal are asserted. Even if the chip select setup time can be 0ns you should never qualify the chip select signals and the read or write enable with PHI2. Due to delay differences it could be that chip select will be asserted after a read or write signal and the results will be unpredictable. Therefore for these devices it is the best to generate the chip select as fast as possible, i.e. also without any delay and without using PHI2 to qualify them. These devices have no RW signal and no PHI2 input. Instead they have a /RD and a /WR input. If you use PHI2 to qualify /RD and /WR to make sure that all conditions for these devices are met and at the same time the access is sychronized to PHI2 of the CPU, because we must not forget that this is a 65xx computer and the CPU relies on the 65xx timing as well.

And last but not least there are memory devices. They have chip select signals that must be asserted. As for the timing they have almost nor requirements. Whether the address is already stable or not when you assert the chip select they don't care. They require that the addresses are stable for a given amount of time (tacc) to make sure the correct memory cell is accessed. Output enable only enables the tri-state output buffers. For a write the memory requires that the /WE pulse is of a minimal length and that addresses are valid and stable before the leading edge of /WE (before /WE is de-asserted), which is in most cases the same tacc as for reads and that data is valid some time before /WE is de-asserted, which normally is much shorter than tacc. However there are some subtle things to know. To read from a memory both /CE and /OE must be asserted, the time from /CE to a valid data is called tacc and the time form a valid /OE to valid data is toe and is mostly the delay the tri-state buffers take from Z-state to a valid logic state. And for a write /CE and /WE must be asserted. Again tacc is much longer then the twe write enable pulse length. Again it is the best to assert chip selects as fast as possible and not delay them and definitively not use PHI2 to qualify them. This is because memory devices often only activate the internal address when /CE is asserted and else go into a power down mode. Now you still need to synchronize the memory access. And that's where you can use the /RD and /WR signal form the previous section into action again. You just connect all /OE from all memory devices to the /RD signal and all /WE signals from the memory to the /WR signal. This makes sure that the tri-state buffers of the memory chips are only active during the high phase of PHI2 and that for writes the memory chips will use the data that was becoming valid during the high phase of PHI2 and which will be invalid short after the falling edge of PHI2 again.

In other words:

- create all chip select signals without any additional delay and without using PHI2.
- directly connect the RW of the CPU with the RW line of all 65xx peripherals, the same as for the address lines
- generate a /RD and a /WR signal as shown in the GAL equation (using RW and PHI2)and connect them with all /RD and /WR signals of non 65xx peripherals and with all /OE and /WE signals of all memories

Now to completely confuse you. There is another set of (simple) peripherals, the edge sensitive latches, which have only a clock or enable signal but not chip select, e.g. 74HCT259. There the enable must be qualified with PHI2 to make sure that they are selected only during the high-phase of PHI2 as they rely on stable inputs on D, S0,S1,S2 when the enable input is asserted. A 74HCT573 or other edge triggered latches have the same requirement. Also some LCD displays go into this category. There you have to create a dedicated chip-select for every device which is qualified with PHI2

cheers

Peter

All true and correct, except note that the '259 and '573 are transparent latches, not edge-triggered. So for the '573 for example, using it for the bank address byte with the inverted phase 2 going to its Enable input, data bus changes are reflected at its outputs as long as phase 2 is low, then frozen at its outputs when phase 2 rises (ie, when its Enable input goes low). This is necessary for getting all 24 bits of the address out on the bus well in advance of the phase-2 rising edge.

The '574 OTOH is edge-triggered, so it might make a good output-only device if you don't want the outputs changing during the phase-2-high time before the data has settled. The '574 will wait for the edge (from the decode logic, not directly phase 2) before changing the outputs.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Hi Garth,

thanks for the correction. The '573 is not well suited as it is a transparent latch with a positive enable, as you mentioned is mainly used as the bank address latch in a 65816 system. For a IO register I had actually the '574 in mind when I wrote this
Normally I prefer the '259 as it comes in a smaller package and allows to change individual bits by just referring to an address and does not require valid data when you connect the address bits to the data and select inputs as in this example. So you don't need the contents of a register to set output pins.

cheers

Peter

Yes, that's handy. The '259 is connected so it takes its data from the address bus. And, to output an address, the CPU needn't alter the contents of any registers.

FWIW and slightly OT: If the CPU is a 'C02, you can arrange for a '259 or other latch/flip-flop to take its data from a (previously) undefined instruction. You get new opcodes that do I/O. They're unbelievably fast -- jusy one cycle. And again, you can twiddle the output pins without altering the contents of a CPU register. http://wilsonminesco.com/6502primer/potpourri.html#Jeff

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Unfortunately, Jeff's clever little trick won't work with the 65C816, since it has no undefined opcodes.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!