Hm. You said you tried to minimize the code as much as possible, but perhaps you went too far! Or did you omit something from the listing you posted?

After the sta $6000, the CPU is gonna keep going unless you tell it otherwise. In the listing below I added an endless loop to keep it busy. But without this the CPU will keep incrementing PC and executing whatever it finds... such as old remnants of whatever was stored in the EEPROM previously! No telling wehat nonsense might result from that.

-- Jeff

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

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

Oh! Very good catch. While I was testing my blinking program I had a loop going, but I definitely did simplify too far. I just switched to Jeff's program (and then went slightly simpler, all 8 outputs to high)



This was assembled with RetroAssembler. I can't attach the .bin directly but if anyone wants to see a screenshot of it or a hexdump I can confirm exactly what I'm putting onto the ROM.

When I power on the computer, nothing happens.

I accidentally knocked (into unlocked/non connecting) the ZIF lever on the ROM socket while it was powered up, and then a few LEDs did power on. Hitting reset causes them to go off briefly then power back up. Again, this is while the ROM is sitting loose in the ZIF socket without the latch closed.

Given this sort of strange outcome, it does seem like pin-by-pin checking the address lines into the ROM is a good idea. I already verified the databus lines.

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

Well, I had positively verified the databus lines. That is D0 on the ROM matched D0 on the CPU and the VIA etc. etc. What I didn't test was if they were connected anywhere else. A little extra time with the continuity tester shows there is constant continuity between D3 and GND. D0-D2 do not observe this behavior so it's (probably?) not just the internal disconnected state? I don't see any obvious solder bridges or anything, but I'll have to keep looking.

EDIT: Solder bridge discovered and brushed clean, D3 is no longer tied to GND. But still nothing behaving as expected. More poking and beeping...

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

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

OK, just checking some details. I guess you realize your program can't possibly make the LEDs blink -- they'll either be on or off. And, in order to come on when the VIA pin is high, you need the VIA pin to be attached to the Anode of the LED, and its Cathode goes to ground. And you'll have a resistor in series, placed either on the Anode side or the Cathode side -- it doesn't matter which.

If you're uncertain about which LED lead is which, try connecting the LED & resistor from +5 to ground instead of from the VIA pin to ground.

BTW - there's unfortunately a certain small risk that the little accident you mentioned re the ROM and the ZIF may have damaged the ROM. We'll have to wait and see.

-- Jeff

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

I much appreciate the help! Yes, the goal right now would just be to turn on all of the LEDs and keep them on after reset.

I'm attaching a photograph of my setup, but yes, that's how I have things wired. the resistors are soldered directly to the cathode of the LED. The VIA out is connected to the anode through a breadboard. I have verified each LED functions when connected directly to +5.





Well, on a whim I grabbed another ROM (from Jameco, definitely used, I read it before writing and "Hello World" was there clear as day) and programmed it with the same program. Now, when I power on / hit the reset button, the LED connected to PB7 lights up for a brief moment and then dims again. I programmed a third ROM, with it, nothing visible on the output.

All of these chips worked on the breadboard, but that doesn't rule out anything going wrong in the two prototypes since then causing damage. I only have a second 65c02, but several dupes of the rest of what I need. I probably should keep testing continuity before I pull the only other CPU i have out of its antistatic.

EDIT: adding the photo...

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

Can you remind me, please, what sort of troubleshooting instruments you have? A Logic Analyzer, I recall. How about a Digital Multi-Meter (DMM)? Or any kind of meter, really. Logic Probe? Oscilloscope? Just asking!

If you haven't already, make sure your 5 Volt supply really is 5V (within 5%, say). Basic troubleshooting, to check the power -- measured right at the pins of the chips, not further upstream.

Another good test would be a NOP Generator. I don't have Lee Davison's link handy, but Daryl talks about it here. To get your CPU to see nothing but $EA on the data bus, you can fill your ROM with that value. Or, remove the RAM, ROM and both VIA's, then use 8 resistors (about 10K; not critical) to pull the appropriate data bus lines high or low.

Have fun, and keep us posted!

-- Jeff

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

I have a cheap Sparkfun Logic Analyzer, a reliable DMM, and a logic probe. I have an "Espotek Labrador" that claims to be a USB oscilloscope but I haven't given it a real spin. I recognize I should probably pick up a 'scope, but doing the research (I know there are threads here) hasn't been a need...yet.

I had been trying to use the analyzer on the VIA output pins (as they're the only thing I have broken out of the board), but of course now that you mention it, I can desocket the RAM (which I'm not using yet) and get at the lower address pins and data pins there to try a NOP generator. I'll give that a shot tomorrow!

I'd like to confirm that I'm understanding the logic analyzer sample rate properly. If I am trying to monitor the bus of a CPU running at 1MHz, should I be sampling at 1MHz, or something like 2MHz to ensure I don't miss ...frames? pulses?

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

That logic analyser doesn't appear to have a clock input, so there's no way to control the relationship between its samples and your signals. In that situation, the higher the sample rate the easier it will be to interpret what's going on. 6502 systems have things happening at various places throughout the clock cycle, and 1MHz sampling is going to entirely miss that (it has a good chance of missing some important signals altogether). I'd start with the highest it can do, and only decrease that if you need a long capture time.

An important question you want it to answer is "what are the states of these signals an the falling edge of phi2?" For that, it's easiest if you can guarantee having a sample between those signals being asserted and phi2 falling, and another between phi2 falling and those signals being removed. With (for example) write data's hold time being only 10ns, you'd need a 100Mhz sample rate to ensure this. With a lower clock it's still possible to understand what's going on, but it will require interpretation and understanding what you're looking at. Seeing two signals change at the same time on the trace does not mean they changed at the same time in reality - one will have changed before the other, and you can't tell which.

_________________
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 appreciate the explanation of how to maybe find success with the logic analyzer. I ordered a Rigol DS scope. I'll be able to look more closely when it arrives.

But a bit of good news - I moved the ICs back to my breadboard which I didn't tear down yet, and things still work! Good to know all the ICs are good.

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

Alright, so I now have a Rigol 4-channel DSO in addition to my cheapo logic analyzer. I'm pretty new with the thing, but I've at least learned about different triggering modes and basic operations. Before I start uploading a pile of screenshots I wanted to think through the appropriate tests.

It seems first things first would be making sure that I can read NOPs out of ROM. To do this, I would put the logic analyzer (at the highest resolution possible) on the lower eight address lines (?) - and the scope on CLK, SYNC, and ROMSEL. I should see CLK doing its thing, ROMSEL every second cycle, and binary counting on the address bus?

If this succeeds, next up is going back to my solid-LEDs-on program, scope on CLK & IOSEL. Here I want to see IOSEL low BEFORE CLK falls. I should probably adjust the program to continuously write the same value to the 6522 registers (instead of writing once and then NOP looping), so it's easier to catch on the scope.

Am I thinking the right way? Should I keep using my 1MHz can oscillator for these tests, or switch to an arduino toggling a pin a little more slowly? I'm thinking it'd be more educational to stick with the oscillator and learn to use the scope at speed.

Okay, now that I documented that, it's time to dig in and see what I can see. But if I made a misunderstanding of what I'm looking for, advice is appreciated. Thanks!

EDIT: attaching two scope traces, the first is RESB and SYNC on hitting the reset button, the second is just the clock right at pin 37. My only IC grabbers have pretty long wires on them before they get to the probe, so I think some of the bounce is just from that. But it does look like reset is rising quickly enough...I think...

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

I don't have a scope and I'm not sure how you have yours set up but is your reset signal reading 50+V? almost 80Vpp??

My guess: the probe is set to 10x attenuation (almost always what you want for this kind of work), but the scope hasn't been told about it. So that's actually only 5V.
Edit: Oh wait, no. Probably the other way around.