Starting with my first SBC Project, Plans and Confusions

[BigDumbDinosaur]

BigEd wrote:

There's every chance the grumbler will ask for a monochrome schematic...

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.

[BigDumbDinosaur]

Proxy wrote:

the reason i let them float is because i wanted to add a pin header to potentially add more status bits without having to use up an additional IO Address...
i guess for the second revision i can still do that but have a 2 wide pin header so when the inputs are unused i can use a jumper to connect the pins to GND, and when i want to use them i just remove the jumper to connect a wire.
should solve the floating pin problem without having to permanently connect them to GND.

with the floating pins on the GALs, can i just set them to outputs without any logic attached? will that just defualt them to one state?

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.

[rwiker]

Proxy wrote:

Alright, so to update everyone to the current status of the board

[ ... ]

also the code i'm currently running on it:

Code: Select all

INIT:
	
	LDX #0xFF
	TXS
	LDA #0x00
	TAX
	TAY

START:

	.LOOP:
		LDA #0b00000010
		.WAIT_RX:			; Loops until there is data available in the FIFO
			
			LDX #0x1F
			.DELAY_RX:		; Do Nothing for a while
				DEX
			BNE .DELAY_RX
			
			BIT STT
		BNE .WAIT_RX
		
		LDA INP				; Reads a Byte from the FT240X
		PHA
		
		LDA #0b00000001
		.WAIT_TX:			; Loops until there is space in the FIFO to write data into
			
			LDX #0x1F
			.DELAY_TX:		; Do Nothing for a while
				DEX
			BNE .DELAY_TX
			
			BIT STT
		BNE .WAIT_TX
		
		PLA
		STA OUT				; Sends the red byte back into the FT240X
		
	BRA .LOOP
STP

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

[floobydust]

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?

[Proxy]

BigDumbDinosaur wrote:

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.

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)

rwiker wrote:

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

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.

floobydust wrote:

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?

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

[GARTHWILSON]

Proxy wrote:

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.

CMOS inputs don't take any DC current except the possibly a few femptoamps of leakage, and leaving them disconnected does not make them go high like the case with bipolar logic like 74xx, 74LSxx, 74Lxx, etc.. You could put even a 1M resistor to one rail or the other and it would still pull it to a legitimate logic state, and of course the load to anything you connect later would be truly negligible. But if you don't pull it one way or another, the input voltage can wander between valid logic stats, and I saw a circuit years ago where it was demonstrated that even cigarette smoke blown toward the circuit changed the voltage at the input!

[BigEd]

BigDumbDinosaur wrote:

BigEd wrote:

There's every chance the grumbler will ask for a monochrome schematic...

Your remark is completely uncalled-for, Ed.

I do apologise for my intemperate comment.

[rwiker]

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.

Quote:

Code: Select all

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

...


/* ****************** LOGIC ************************/
A1_7_EN    = A7 & A6 & A5 & A4 & A3 & A2 & A1;
IO_A_EN    = !IO_EN & !A1_7_EN;


RD_STATUS = IO_A_EN & A0 & PH2 & RW;
RD_FT240X = IO_A_EN & !A0 & PH2 & RW;
WR_FT240X = IO_A_EN & !A0 & PH2 & !RW;

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

[Proxy]

rwiker wrote:

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.

Quote:

Code: Select all

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

...


/* ****************** LOGIC ************************/
A1_7_EN    = A7 & A6 & A5 & A4 & A3 & A2 & A1;
IO_A_EN    = !IO_EN & !A1_7_EN;


RD_STATUS = IO_A_EN & A0 & PH2 & RW;
RD_FT240X = IO_A_EN & !A0 & PH2 & RW;
WR_FT240X = IO_A_EN & !A0 & PH2 & !RW;

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

Code: Select all

IO_A_EN    = !IO_EN & !A1_7_EN;

to:

Code: Select all

IO_A_EN    = !IO_EN & A1_7_EN;

so that it's not inverted anymore

BigDumbDinosaur wrote:

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.

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

[BigDumbDinosaur]

Proxy wrote:

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

chrome_2020-03-24_15-58-38.jpg

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: Select all

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: Select all

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

[cjs]

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

Proxy wrote:

2. something with the 3 State buffer i use to read the bits. (SN74HC541N)

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.

[Proxy]

BigDumbDinosaur wrote:

Something in your GAL logic caught my attention:

Code: Select all

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: Select all

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

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.

Code: Select all

IO_A_EN    = !IO_EN & !A1_7_EN

would equal this:

Code: Select all

IO_A_EN    = !(A15 & A14 & !A13 & A12 & A11 & A10 & A9 & A8 & !A7 & !A6 & !A5 & !A4 & !A3 & !A2 & !A1);

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

cjs wrote:

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

Proxy wrote:

2. something with the 3 State buffer i use to read the bits. (SN74HC541N)

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.

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

[Chromatix]

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).

[Proxy]

Chromatix wrote:

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

[Chromatix]

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.