Ok here is the second revision of the board, well atleast the Schematic of it.



Important changes:

Fixed the Reset button.
Added a Resistor array to pull down the unused inputs of the 541 (U3) (also added a pin header).
Added a decoupling capacitor to the 3.3V rail of the FT240X.
Connected all unused inputs on the GALs with GND (there was only 1 usused input on U2, for the rest of the IO Pins i can set them to output in WinCUPL).
Added a power switch, when off it connects the board's Vcc lines to GND (through a resistor to avoid any kind of shorts).

am I missing anything?

Here's another idea (if I am correct) about the '541 enable, since we were worried about that being slow.

Right now /RD_STATUS is slowed by having to wait for the first GAL to generate /EN_IO before it can bring /RD_STATUS low. Since you have two enable inputs on the '541, you could instead bring /EN_IO to one of them (leaving /RD_STATUS) on the other, but change /RD_STATUS in the second GAL not to be qualified by /EN_IO, reducing the delay to enable the '541, I think.

_________________
Curt J. Sampson - github.com/0cjs

In the future, I recommend you decrease your pull-up resistors to 3.3K. The lower resistance will improved noise immunity without affecting the ability of any connected devices to pull a strong logic 0.

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

I think that would work, although it could be classified as a kludge.

Ultimately, the solution will be in using a CPLD for the glue logic. An ATF1504AS has much more in the way of logic resources than any GAL, plus has 32 uncommitted I/O pins in a PLCC44 package. Also, the entire ATF15xx family can be programmed in-circuit via JTAG, which makes logic changes a quick and easy process. An ATF1504AS will easily handle what this circuit is doing, plus more.

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

that could actually work, it would parallelize the generation of the enable signal, basically making it twice as fast.


well i would like to start with the ATF1504, but i need a programmer.
plus i wasn't sure if i should directly replace the GALs with the ATF1504 because i never worked with it before.
but i guess you guys have, so as long as i show the schematic of how i want to wire it up on the board you could tell me if there is something wrong with it.

also i wanted to order a breakout board for the ATF1504 so i could experiment with it on it's own.

I know i could've made it a lot slimer but i wanted to see what each pin does.
I'm also not 100% sure on the pinout of the JTAG connector. i assume this is correct:



sadly i don't have 3.3k resistor arrays, so i need to order some.

It's a fine idea to implement your glue logic with a CPLD, but it's also a fine idea to use GALs. Don't let one opinion give you the idea that there's only way to do things, or that there's a consensus among members as to which approach to pick.

true but i also want to stop using these GALs, they have few IO pins, are old, have little space on them to program with, and it safes space to use a CPLD.
plus one of my ultimate goals is to use standalone FPGAs in projects, so starting with CPLDs is a great idea.

but this again makes me unsure if i should replace the GALs in the next revision
or keep the GALs for now, order the breakout board so i can safely experiment with the CPLD so i can properly implement it in the 3rd revision.

Ah, good point! So it actually does double-bonus work: speeding up that signal and bringing the kludge factor up towards something a bit more appropriate for hardware. :-)

(Yes, I am a software guy. Even though I now, unlike twenty years ago, understand why a lot of hardware I programmed was the way it was, I still have difficulty forgiving hardware designers for what they put me through. And yes, I'm looking at you, Woz. :-))

_________________
Curt J. Sampson - github.com/0cjs

I'm not opining there is only one way. My latest POC unit highlights that, as it's all discrete logic.

That said, there is a potential problem with the way he's doing things right now, in that there can be a race between GALs due to differences in internal prop time. GAL prop times are specified on worst-case pin-to-pin values. No minimum is specified and that's where one can run into trouble with two GALs making logic decisions "in parallel." While I'm not saying that is what is happening in his system, the possibility does exist.

Back in the days (around 1991) when I was writing code for a 65C02 terminal server that used two GALs, every so often the unit given to me for testing would go whack-a-doodle for no apparent reason. I spent a lot of time poring over my code trying to find the error that surely had to be causing all the trouble.

The cause turned out to be a difference in GAL speeds resulting in some logic going "backwards." Ø2 was 8 MHz in this unit, which was clipping right along for a 65C02-based system in those days. Timing was somewhat touchy. When the board was hooked up to a logic analyzer it was seen that one of the GALs was slowing down more than the other as its temperature rose (back then, GALS were more power-hungry than now). The board had to be redesigned because of this behavior and the new design ended up with a small CPLD so all logic could be encapsulated in a single device.

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

This is the one I use.

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

morale of the story, throw everything you can into a single chip.



ok nice, sadly quite expensive but whatever, it will work.
i found the same on Mouser as well so i can order it with my other components. problem is that they are out of stock, and it will take a few months for new ones to arrive (acording to the site).

ok now a few questions about somne of the pins on the ATF1504.
I know the use of the 4 JTAG pins, and will avoid using them for IO stuff. (I assume my JTAG connector is correct as i cannot find a pinout of the Atmel Programmer's connector online)
I have an idea what some other pins do, like the GCLR (Global Clear) which probably resets all internal flip flops.
and the GCLK (Global Clock) pins, which are likely used for the clock input of the flipflops, why there are 3 of them though, no idea.
but now the confusing pins:
OE (Output enable), there are 2 of these and one of them is on the same pin as a Global clock, no idea what they are for.
PD (???), there are also 2 of these, again no idea what they might be for.

It's the way you express yourself, BDD, that reads very much as if that is your opinion, and that it's the only valid opinion. I don't want to harp on this, or to divert the discussion, but that's the reason why I feel obliged to point out, from time to time, that there's more than one way to do things.

The multiple GCLKs, OE and so on will be configurable in their use, based on what you program into the device. You'll need to look at the internal structure of the device to figure out what it's capable of and how those signals can be used.

how the frick did i miss that. just looking at the datasheet it explains them.
and i thought i read through the whole thing...

ok with the help of that i tried to assign all the pins in such a way that makes it easier to route.
overall i used up all IO pins, and there were only 2 input pins open that i connected to GND. (pin 2 and pin 44)



it also fits on the PCB, though i had to move some Ground Traces around for that.

That philosophy is what brought about the high level of integration seen in today's computers.


I have one and it works quite well. Microchip (Atmel) aparently produces these things in batches, which explains why Mouser has them on backorder.


I tried to read your JTAG connection schematic but, once again, color is preventing me from clearly seeing what's in it.


OE is exactly what the name implies. That said, those pins are not dedicated to that function and can be used as regular I/O pins.

PD is "power down" and would be used to reduce power consumption when the circuit is idling. As with OE, PD can be used for regular I/O.

Other than avoiding the use of the designated JTAG pins as I/O (there is a booby-trap waiting for you if you do declare one of those pins for anything other than JTAG), and applying your clock signal (if used) to GCLK and reset to GCLR, you are free to use pins as required. However, I recommend you design your logic before you lay out the rest of the circuit and let the fitter decide how to best use the CPLD's resources.

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