Seemed like a silly question but it just jumped out of the screen at me so I had to ask I really need to get a scope. There really is a wall you run into eventually where you need to see what them darn electrons are doing.

Indeed, in that last screenshot the scope channel was set to 10X erroneously.

So it's been a while since I was able to troubleshoot here, but I have some new findings that are making me tear my hair out. I have tried programming the ROM with "EA" in every bit. I'm still seeing very strange behavior. With the NOP-ROM in place, I'm still seeing LEDs driven by the 6522 illuminate. This was strange to me, so I set up my scope to capture CLK, SYNC, and RWB. It was my expectation that a ROM full of NOPs would never cause the RWB signal to go low. Is that a misunderstanding?

_________________
https://github.com/Individual-Solid/

Three write cycles in a row can only happen one way: an interrupt. So you need to check your interrupt lines (and possibly your reset line.) (And also check for BRK which is another kind of interrupt: might the 6502 see a 00 on the databus?)

<deletes almost-finishecd post>

Yes -- what Ed said. Check the level on your IRQB pin. I think you'll find it's low, and that's what's causing the unexpected interrupts.

-- Jeff

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

Hmm, something does seem to be pulling IRBQ low for a little while after a reset, but I am seeing plenty of RWB traffic before IRBQ ever goes low. NMIB has been reliably high in my experiments so far. I'm not sure what's pulling IRQB low, I'll do another visual inspection of the board, and I guess make sure nothing strange shows up on those signal lines with a DMM?



Probes are directly clipped to the 6502 pins. This trace is immediately after depressing the reset pushbutton.

_________________
https://github.com/Individual-Solid/

This is going to sound really stupid, but are you sure all the power and ground pins are connected to all the chips?
It's not unheard of for a chip with the Vcc pin disconnected to be powered by a high input through a protection diode - everything seems to work until all the inputs are low, when the chip loses power and forgets its state. Or, if it's powered through an input with a pullup resistor, a current surge could have a similar effect.

No stupid suggestions when it comes to this. I've done my vest to verify the basics but it's good to have concrete things to test.

While the board was powered down, I used the continuity tester and asserted that +5 and GND are connected to the pins as drawn on my schematic. Powered on the board and measured ~5.16v across +5/GND at each chip (CPU, ROM, logic gate, both VIAs). I suppose I should triple check the datasheets that these pin numbers are correct, but that'd be a surprise.

_________________
https://github.com/Individual-Solid/

Are you using the ROM that's filled entirely with $EA?

I'm not saying you should or shouldn't. But if you do, it's quite a specific test, and you need to arrange that the ROM is always selected, and everything else is never selected. The CPU is supposed to see 64K of NOPs, and run 'em all (wrapping around to zero again and keeping going). It's a useful way to verify things like all your address lines toggling.

But if your IO and RAM are still enabled, the NOPs wiill cease as soon as PC reaches the RAM or IO, and you'll get something unpredictable.

-- Jeff

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

PS -- good call, kernelthread. The point you mentioned was well worth checking!

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

Is the schematic here: http://forum.6502.org/download/file.php?id=12101 (on the first post of this thread) what you are using?
If so, you appear to have made a mistake with the I/O decoding. You have an nIOSEL line decoded as

nIOSEL = !(!A15 & A14)

by logic gates U2A and U2C. This is an active-low select which is active for addresses 4000-7FFF. So far so good. But you have connected it to pin 24 on each 6522, which are active-high chip select pins. VIA U6 is active when nIOSEL is high and A13 is low, and U7 is active when nIOSEL is high and A12 is low. This means that:

U6 is active for addresses 0000-1FFF, 8000-9FFF, C000-DFFF
U7 is active for addresses 0000-0FFF, 2000-2FFF, 8000-8FFF, A000-AFFF, C000-CFFF, E000-EFFF

So you have some addresses where there is contention between ROM and U6, some addresses where there is contention between ROM and U7 and some addresses where there is contention between all three.
If your ROM is contains all EA's, the first opcode fetch will be from EAEA which will immediately result in a collision between ROM and U7.
What you need to do is connect nIOSEL to the active low chip select on the two VIAs. Then use your spare NAND gate as an inverter attached to line A13 and have the active high chip select of one VIA driven by A13, and the active high chip select of the other VIA by !A13.

Another good call, kernelthread!

Individual_Solid, it seems that, until now, no-one has taken a close look at the schematic you posted. Unfortunately, that can happen sometimes.

Yes, that means...
- $4000 to $5FFF will activate the VIA whose active-high CS is driven by !A13, and
- $6000 to $7FFF will activate the VIA whose active-high CS is driven by A13.

There is another option, and maybe this is actually what you intended in the first place if you're basing your project on Garth's circuit. Do still connect nIOSEL to the active low chip select on both VIAs. But instead of using the fourth NAND section, connect one active-high CS to A13 and the other active-high CS to A12. Compared to the schematic you posted, the mods to accomplish this are pretty simple. For each VIA, simply swap the connections on pins 23 and 24.

This means...
- $4000 to $4FFF will activate nothing (so, don't use these addresses)
- $5000 to $5FFF will activate the VIA whose active-high CS is driven by A12
- $6000 to $6FFF will activate the VIA whose active-high CS is driven by A13
- $7000 to $7FFF will activate both VIAs (so, don't use these addresses)

Also, you perhaps need to better understand the operation of the "ROM full of NOPs" test. Or, just drop the idea and use a "real" program... in which case RAM and one or both VIAs can become involved.

-- Jeff

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

Aha! Indeed, kernelthread great spotting it. Yes, that's the schematic in play, and as you talk it through, that almost certainly explains a lot of the nonsense I was seeing. I'll be applying the solution Dr Jefyll suggested, that's the memory map I was going for (indeed inspired by Garth's circuit). I'm glad someone had the eagle eyes to spot it .



Ah, yes, of course. I suppose I was thinking that it'd be (at the slow speed I was running) quite a few cycles before the CPU made it into the land of unaddressed/weirdness. But of course, as pointed out, one of the VIAs was addressed in a range that included EAEA...

Wow, thank y'all so much. There's another heatwave hitting the PNW but in the morning when my office cools down, I'll bust out the bodge wire and fix up the CS pins on the VIAs.

_________________
https://github.com/Individual-Solid/

Heat be damned, I fired up the soldering iron and repaired the board. Who knew cutting a trace needed such force? And I now have complete control of the blinking LEDs, they dance to my whim. This board works!

_________________
https://github.com/Individual-Solid/

Great news!

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