Your remark is completely uncalled-for, Ed. I hope you don't develop color-blindness when you get older and struggle to read as a result of it.

I can always drop out as a participant in trying to help someone debug a circuit. I can't read the schematic he posted, so there's little point in continuing to contribute.

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

Inputs should never be permitted to float on any CMOS device, for the reasons explained by Chromatix. If you are not using an input just connect it to Vcc with a 3.3K. If you later decide to use the input you can do so without having to change anything, as virtually all known devices can sink the required current to pull the input low.

As for the unused GAL pins, if you can, declare them as outputs and set them to zero (low). If you cannot declare them as outputs you'll have to do the same thing as for other CMOS inputs.

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

Do you have a hex dump / output listing for this code?

Granted, I'm late to the party, so this might have been mentioned already...

Looking at the schematic. I don't see a decoupling capacitor on the FT240 chip where the 3.3V out is used to supply the VCCIO line. The datasheet specifically shows a 0.1uF cap on that line. Is the cap installed and just omitted on the schematic?

_________________
Regards, KM
https://github.com/floobydust

to be honest i kinda blacked out while designing that because i thought pulling it to either could be bad for the following: what if i pull it to GND with a resistor but have signal on it that is by default high? it would constantly draw current.
but now i actually thought about that and realised that 5V / 4.7kOhm = ~1mA
soo yea, that's not really the end of the world.

for the second revision the 6 unused inputs will be pulled to GND (but i'll keep the pin header to add more bits in the future)

about the GAL, some pins can only be inputs so i'll also put those to GND (though i don't think i'll need a resistor for that)




I mean i did use a disassembler to verify that my assembler is working, but sure. here you go: PASTEBIN
note it's the full dump, since it's an 8kB FLASH in the Memory map the file is always exactly 8kB large.



nope, i just genuinely forgot about that one when designing my circuit, i'll add it in the second revision.

_________________
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?

I do apologise for my intemperate comment.

Does IO_A_EN actually do what it is supposed to do? If the select logic is wrong, you'll be reading random(ish) values from the data bus rather than values from the FTDI chip.



This looks odd to me; should the "&"s for A1_7_EN be "|"s instead?

It works as intended. i can read and write from the FT240X just fine. i guess it could also work with ORs but then i would need to change

to:

so that it's not inverted anymore



I made this monochrome and high contrast version for you, should be readable:

Thanks. As long as it's black on white it will be readable. It doesn't even have to be high contrast, just monochromatic.

Something in your GAL logic caught my attention:

Code:

IO_EN    = A15 & A14 & !A13 & A12 & A11 & A10 & A9 & A8;
...
IO_A_EN    = !IO_EN & !A1_7_EN;

Is IO_EN an actual pin or just an intermediate term? Reason I ask is if IO_EN is an actual pin then the equation IO_A_EN = !IO_EN & !A1_7_EN will incur an extra pin-to-pin delay, since it references another pin. If the GAL is rated at 10ns, 20ns will elapse from the time !(A15 & A14 & !A13 & A12 & A11 & A10 & A9 & A8) becomes true and the GAL asserts IO_A_EN. Dunno if that added delay is tripping you up, but it may be. In any case, you aren't saving any logic resources with code like that because of the need for feedback from IO_EN back into the logic matrix. I would write it as:

Code:

IO_A_EN    = !(A15 & A14 & !A13 & A12 & A11 & A10 & A9 & A8);

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

(Take my ideas with a big grain of salt, 'cause I'm a noob at this. Corrections welcome.)


What's the delay between bringing /RD_STATUS low (at the output of U2) and reading D1 from the '541 output? Looking at the data sheet, it seems that it could easily require up to 50 ns for D1 to stabilize. And that might explain why it works well when you clock the system more slowly.

You'll have to calculate that delay, of course, rather than measure it. This would be a time when a (four-channel) 'scope would come in handy: you could monitor the '541's input, enable and output (triggering on the enable) all together and see both the delay and confirm that the output signal is properly following the input, when run both slowly and at full speed. And I guess throw your fourth probe on the clock so you could check against the 6502's bus timings for data reads.

Also, I don't know if this really would make any difference, but rather than routing /RD_STATUS to both enables of the '541, for some reason I'd feel more comfortable with tying one of them permanently low and using just the remaining pin to enable the chip.

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

IO_EN is pin on the GAL, because I don't have enough inputs to do it in a single one, i use U1 to get the IO_EN signal, and then send it to U2 to decode the FT240X addresses.
I think you're misreading a bit because the 2 parts you showed are from seperate GALs.
another reason i want to start with the ATF1504. (but i still need to look for a cheap programmer and make a breakout board)
but 20ns extra shouldn't be that bad when i just run it at 1MHz, with each half of the clock staying for around 500ns.

and your code also seems to be missing half.

would equal this:

since IO_EN only covers A8-A15, and A1_7_EN, like the name may imply handles A1-A7.




hmm that really seems like a lot of delay, i wonder if i could just replace the 541 with a GAL, but i don't know if they support 3 state outputs....
yet again another reason i should start looking into more Complex PLDs... one you could say CPLDs

If speed is the problem, then instead of a 74HC541, you could use a 74AC541. It would be a better match timing-wise for the fast GALs. Some 74-series parts are also available as 74AHC, which is nearly as fast as 74AC but with softer drive (less noise inducing).

comparing the datasheets (if i'm reading them correctly)

the 74HC541 seems to have a delay of ~20ns from OE to Output,
while the 74AHC541 seems to only have a ~8ns delay from OE to Output.

that should be fast enough even at 10MHz, since it's faster than my RAM.

I can try those in the second revision, luckly they are pin compatible so i just have to order the chips and not have to redesign the PCB

There's no luck to it - the whole 74-series is intended to be pin compatible between versions, and you only have to watch out for signalling levels and (in older versions) fan-out limitations. If they change the pinout, they'll introduce a new part number to make the difference clear.