Acolyte 6502 Schematic Video

[sburrow]

Hello everyone!

I'm here today to ask for a second pair of eyes on my schematic. Full story (still short): I had been working on a design like this for almost 6 months, but when I soldered it all together a couple of weeks ago, DOA. I am pretty sure it is data-bus contention because I tied BE directly to PHI2. To correct this mistake, I have redesigned the computer and am posting what I have here.

Here is the link to my video explaining the schematics, it's 12 minutes long:

<VIDEO LINK DELETED>

Attached are the B&W and Color versions of the Schematic I used in the video. Also, below is my IRQ-ISR code.

I would love to have your opinions on it. Not just that, but if you find anything that potentially won't work, I would *love* to know now before I order some boards and waste money on soldering parts to a large paperweight (again).

This is not meant to be fancy! It is fairly simplistic, hardly any expansion capabilities, but that's just the point. I'm not looking for "hey you should add X to it", I'm looking for "hey your logic here is wrong."

Any criticism is greatly welcomed. Thank you all very much, have a wonderful day.

Chad

Code: Select all

; 6502 running at 1.57 MHz,
; PS/2 keyboard running at 17 kHz
; That gives me 92 cycles between signals.
; /IRQ = Keyboard-Clock
; /SO = Keyboard-Data
; *** Need to use $_B illegal instruction to set /SO line!
irq_vector			        ; cycles = 7
	CLC			        ; cycles = 2
	ROL key_data		; cycles = 6
	CLV 			        ; cycles = 2, clears overflow bit
	.BYTE $0B 		        ; cycles = 1, sets the /SO line to whatever is on Keyboard-Data
	BVS irq_check 		; cycles = 2, low value on /SO
	INC key_data 		; cycles = (6), high value on /SO
irq_check			        ; cycles = (1)
	DEC key_counter		; cycles = 6
	BEQ irq_store		; cycles = 2
	BMI irq_clear		; cycles = 2
	RTI			        ; cycles = 6 -> total = 42
irq_store			        ; cycles = 1 (sub-total 34)
	PHA			        ; cycles = 3
	PHX			        ; cycles = 3
	LDA key_data		; cycles = 4
	LDX key_write		; cycles = 4
	STA key_array,X		; cycles = 5
	INC key_write		; cycles = 6
	PLX			        ; cycles = 4
	PLA			        ; cycles = 4
	RTI			        ; cycles = 6 -> total = 74
irq_clear			        ; cycles = 1 (sub-total 36)
	PHA			        ; cycles = 3
	LDA key_counter		; cycles = 4
	CMP #$FC		        ; cycles = 2
	BNE irq_exit		; cycles = 2
	LDA #$09		        ; cycles = 2
	STA key_counter		; cycles = 4
	PLA			        ; cycles = 4
	RTI			        ; cycles = 6 -> total = 64
irq_exit			        ; cycles = 1 (sub-total 49) 
	PLA			        ; cycles = 4
	RTI			        ; cycles = 6 -> total = 59

EDIT: Edited the code as per BDD's find.

[BigDumbDinosaur]

What’s the purpose of wiring the MPU’s BE to Ø2?

Quote:

Code: Select all

irq_store              ; cycles = 1 (sub-total 34)
   PHA                 ; cycles = 3
   PHX                 ; cycles = 3
   LDA key_data        ; cycles = 4
   LDX key_write       ; cycles = 4
   STA key_array,X     ; cycles = 5
   PLX                 ; cycles = 4
   PLA                 ; cycles = 4
   INC key_write       ; cycles = 6
   PLX                 ; cycles = 4     <———???
   PLA                 ; cycles = 4     <———???
   RTI                 ; cycles = 6 -> total = 82

The above code segment appears to be putting the stack out of balance. If so, it will virtually guarantee the system will go haywire.

[sburrow]

BigDumbDinosaur wrote:

What’s the purpose of wiring the MPU’s BE to Ø2?

The above code segment appears to be putting the stack out of balance. If so, it will virtually guarantee the system will go haywire.

Well, big oops on my code! Yes indeed to that, I just fixed it. Thank you for that. I must have missed that while copy/pasting something back and forth.

I wasn't using this code on the previous build, I was using a VIA for all I/O there, so I had my traditional IRQ-ISR. I know that wasn't the reason for the last board not working.

When BE is high, the 6502 runs as usual. When BE is low, the addr and data buses go to high-Z, which allows for my '590 counters to jump onto the address bus and talk to the RAM and ROM directly for the video colors and signals. I do this while PHI2 is low, so thus:

BE high -> PHI2 high
BE low -> PHI2 low

On this particular build, I forced BE to only go low during the second half of PHI2-low, allowing for the PHI2 falling edge to have the address and data buses unaffected. Essentially the BE line is saving me about 3x '245 chips.

But now that we are talking about it, I have something small to alter. I'm going to replace the A15 line on the ROM with BE instead of PHI2. Attached is the change. Thank you BDD.

Chad

EDIT: Added the B&W version too.

[BigDumbDinosaur]

sburrow wrote:

But now that we are talking about it, I have something small to alter. I'm going to replace the A15 line on the ROM with BE instead of PHI2. Attached is the change.

I'm not seeing what you changed due to your graphic having color combinations I can’t discern.

[sburrow]

BigDumbDinosaur wrote:

sburrow wrote:

But now that we are talking about it, I have something small to alter. I'm going to replace the A15 line on the ROM with BE instead of PHI2. Attached is the change.

I'm not seeing what you changed due to your graphic having color combinations I can’t discern.

Just attached the B&W version too, sorry about that BDD.

[Alarm Siren]

Is the "MicroSD Card Adapter" (J9) going to be a connector off to a different board that has the actual SD card socket on it? I ask because if J9 is meant to be the actual socket, MicroSD cards have more than six pads...

Not a mistake per se, and I expect you're aware already, but I note SPI-MISO goes into ~SO without anything to stop it. I understand that in theory SPI-MISO should only change when you clock the SPI bus, but you'll need to be careful that said clock doesn't happen when you don't want it to, or you could get some hard to diagnose bugs later on.

Total aside, but I recognise the U5 symbol being from the library I created. Glad to see it was helpful

[sburrow]

Alarm Siren wrote:

Is the "MicroSD Card Adapter" (J9) going to be a connector off to a different board that has the actual SD card socket on it? I ask because if J9 is meant to be the actual socket, MicroSD cards have more than six pads...

Yes indeed, there is this "SPI Micro SD Card Adapter" which is sold in bulk by various folks for cheap. It has been very fruitful.

Quote:

Not a mistake per se, and I expect you're aware already, but I note SPI-MISO goes into ~SO without anything to stop it. I understand that in theory SPI-MISO should only change when you clock the SPI bus, but you'll need to be careful that said clock doesn't happen when you don't want it to, or you could get some hard to diagnose bugs later on.

And that's the risk for sure. I went to the schematics for the SD Card Adapter, and it has a direct connection from the SD card itself to the MISO pin (through a voltage regulator of course). As per the SPI standard, it should be floating while not in operation. "Should" is the keyword I suppose. If that doesn't seem to work out, it will at least not brick the entire board though, I can just take the SD card out!

Quote:

Total aside, but I recognise the U5 symbol being from the library I created. Glad to see it was helpful

Yes, thank you for that. I have been using those for a while now!

Thanks for looking it over, I appreciate the feedback.

Chad

[sburrow]

I just ordered the boards and parts. There goes $100, hopefully it works. Thanks everyone!

Chad

[sburrow]

Update:

Well, that was a dud too... Pretty disappointing. It might be something simple that I'm overlooking, ordering some replacement parts to see if I can get something to work, but highly doubtful.

Whelp, there you have it. Onward to the next one. (?)

Chad

[Dr Jefyll]

In what way is it a dud? Will it at least execute the reset sequence if you single-step it?

Sorry to hear about the setback. But it's too soon, IMO, to move onward to the next one!

-- Jeff

[sburrow]

Dr Jefyll wrote:

In what way is it a dud? Will it at least execute the reset sequence if you single-step it?

I haven't tried that. That is a good idea, but I'm running video and processor on the same bus, so it is very hard to detect what is going on exactly. I see data bus contention, just like last time. I was *sure* I checked the timing on it and that it would work. When BE goes low, everything is fine, the video circuit works as expected, just like last time. When BE goes high (during PHI2 high and the first half of PHI2 low) everything goes haywire on the data bus. I'm seeing 2.5V on the scope, just like last time. The address lines are fine, though I can hardly tell if it is 'as expected'.

Moral of the story: Don't use BE, just use some 245's like a normal person.

Quote:

Sorry to hear about the setback. But it's too soon, IMO, to move onward to the next one!
-- Jeff

That's the plan. I have some parts coming in, I will try replacing this and that.

Otherwise, I'm going to a working model and just removing some features I no longer need.

Thank you.

Chad

[Dr Jefyll]

Looking at the schematic, bus contention -- other than a brief transient during changeover, perhaps -- doesn't seem to be possible. I see the BE input on the CPU is driven by the same signal as all the /OE inputs on the '590 counters. So, does the schematic differ from what actually got built? (IOW, better check the wiring there!)

If there truly is bus contention then you're likely to notice some chips getting warmer than you'd expect. Also, the current drawn from the power supply will be abnormally high (perhaps causing the PSU output to sag below 5 volts).

Are the 590's socketed? If you remove them, will the CPU boot?

-- Jeff

[sburrow]

Dr Jefyll wrote:

Are the 590's socketed? If you remove them, will the CPU boot?

Just tried that, same stuff. The CPU data bus is sometimes at 0V, then 5V, then 2.5V, etc. That is without the 590's.

I appreciate the suggestions Jeff.

Chad

[Dr Jefyll]

Oh, the data bus. Sorry -- my suggestion about the 590's made no sense (because they drive the address bus).

Still, I think you have the skills to sort this out. Contention means there's more than one device driving the bus in question. So, in context of the data bus, ask yourself, what are the prospective suspects? CPU, obviously. RAM. ROM. I/O. And maybe other stuff, if there's a wiring error.

One possible approach is to use your 'scope. See which devices are enabled when this 2.5V level is observed.

-- Jeff

[plasmo]

Chad,
One good way to debug your circuit is to explain it to another person who presumably don't know anything about it. It forces you to take a few steps back and explain your assumptions (why you think these assumptions are correct?) and other parts of logic (surely these logic have nothing to do with current problem, or do they?) and force you to explain the logic in simpler, possibly different terms (tiresome task of sketching out the details that are already proven, or are they?). I've sat in design reviews said absolutely nothing but watched the designers solved their own problems because they were forced to go back explaining the assumption and details they thought are already proven and working. A "second pair of eyes" sometimes mean a different way for YOU to look at the problem.

So start from the beginning; post your latest schematic, circuit board design, pictures of your assembled board, and explain the problems you are seeing.
Bill