6502.org

I've got a thing I call a debugger, which is essentially a single-cycler that also has indicator lights for most of the signals that aren't address or data.
I need to replace its connector, I think. It's currently a bunch of resistor cutoffs and LED legs, and annoyingly fragile.

Testing with the single-stepper, I have verified that the PLD is selecting the ROM and the VIA correctly.
However, I also tested the VIA's active-high CS1. Turns out I tied it low, straight into the ground plane, so the VIA never activates. I checked the KiCAD design, and it's there, too. I have corrected it for the next version of the design.
I didn't do the same thing to the 65SPI, thankfully.
In any case, I now need to figure out how to break that connection so I can make the appropriate one with a botch wire...

Nice to hear -- a big step forward identifying that booboo! Is the VIA in a socket? If it's soldered to the board you'll have to unsolder (remove) it, or cut the pin and bend it up so it can be tied high. Unless someone can suggest a better idea...

Edit: if you do decide to bend CS1 up, it's maybe best to begin by removing the solder from that pin. This might let you make the cut closer to the board.

Yeah, it's socketed. Almost everything is, at this stage.
I might desolder the SIL header I used for that side, and then cut the socket pin short and scrape off the pad.

You can simply unplug the VIA and drill the socket pin "away". - Not nice but working

EDIT: And if you solder a wire on that bent up pin, use the upper part of the pin, the wide part. You may then reuse the VIA later without having much trouble getting a fat pin into its socket. If possible solder quickly. It is pretty much stress for it.

I found myself unable to actually desolder it. Thankfully, I can cut away the plastic holding it in place. I didn't want to do this, because now, that socket will have to hang on by the pin. I couldn't get the pad off, either, so I've covered it with electrical tape.
But it now works as it should. It's going a bit fast for me to tell, but my logic probe says the port outputs are pulsing. I'll insert a delay loop or use a timer to slow it down later, so the count is visible.

You can use an audio amplifier and speakers to check for activity. You can add a counter (4024, 4040) as divider. Beware 5V signals are VERY LOUD

About a month later, and the chips are down. On the board, that is. I've tested them all working individually(well, each with their own little test programs), although I many need to test the RAM more exhaustively.

At the moment, I'm trying to write a bootloader of sorts, so that I don't have to pull the EEPROM out every time I want to do something different. Basically, it's supposed to load a binary from the beginning of an SPI-10 module, and run it. I've not succeeded in getting that to work yet, and I don't know why, which is annoying(not having a proper debugger doesn't help). I'm going to have a shot at rewriting it from a (hopefully) better spec. It'll involve 16-bit arithmetic, but that's not hard.

Perhaps you can create a tiny monitor that is capable of reading (and writing) something like S-records ore similar.
A little utility that moves itself into RAM and then programming a given region into the EEPROM would helpful as well. I would assume that in most cases there is sufficient space in your EEPROM to keep all these code snippets.

I had EWOZ working at one point, but I switched the display firmware so it would scroll instead of wrap,, and it uses LF as the line ending. And when I tried altering EWOZ to have it output a LF instead of a CR, it stopped working for some reason that I was unable to determine.
I have written a routine that should write to the ROM in-place, but I think the boot loader will be simpler than a monitor. I have a monitor planned, but that will be a rather larger undertaking, I think, but I had planned to get that into the machine using the boot loader, and then copying it to ROM.
There is 32K of ROM in the system, so I'd imagine there's space for quite a lot.

Congratulations on a fine looking project! Nice to see how this has evolved from the hand-wired prototype.
I see you have various options to consider, but FWIW here's another. Maybe as a stepping stone you should implement a drastically simplified bootloader. For example it could be limited to loading programs whose length is always 256 bytes, and it would always locate the program at $0200 (for example).

With this rudimentary capability in place you could then test successive versions of a proper bootloader without the restrictions.

( You could then go further and arrange that the new loader executes from ROM. However, there's perhaps not much advantage in taking that step. Having a loader that loads the loader is quite acceptable, IMO, and it makes it easy to add new features to the level-2 loader. Also, in a troubleshooting scenario it may be advantageous to be able to revert to the simplest level. )

So I tried a "primitive" loader (256 bytes always, with fixed target address), and it didn't work. I also tried a program that copies a bit of code in ROM, over to RAM, and then runs it. That also didn't work. I've tested the RAM(using the minipro) and according to that, it's fine.

One odd thing was that I had it echoing what it received as it copied, and that worked for a while, but it eventually stopped working, and it never successfully ran the payload.

I've been thinking about making a proper debugger to see precisely what's going on in there. A few shift registers, an Arduino, and a logging terminal will produce a nice trace, and will allow me to single-cycle the subject.
I'll need to be able to afford the shift registers, though, which could take a while.

Sad to read this. But can you explain more detailed what happens and appears not working?
My first thought reading this was: stack pointer. This means, somehow your code produces more pushes than pulls and finally your losing your way back.
I once use a 6522 timer (T2 as a single shot one) to fire an IRQ (in my case an NMI) just during the first instruction after RTI. I triggered the counter with the correct value, restore all regs, do the RTI and then the CPU fetches the next instruction. But one clock after that fetch the NMI was triggered and forces the CPU to finish this instruction and branch to the NMI service routine. This way I circumvent the need for auxiliary hardware to do single stepping.


Arne

I too am curious about the details. And do I understand correctly that this loader is using the 65SPI chip to read from the SPI-10 module? Have you thought about the initialization that's required? I hope interrupts aren't involved.

Like GaBuZoMeu, I have a feeling simple troubleshooting methods will suffice.

-- Jeff

The programs I've been attempting to bootload are something simple on VIA port B, either a set all high and stop, or a count up.
The 65SPI loader never produced a result(no lights), which wierded me out.
I then tried a serial loader. (with IRQs. It was pleasing to see it just work first time) That's what produced the trace a few times and then stopped doing so, for some reason. That didn't produce a result, either.

The initialization needed by the 65SPI amounts to making sure the control register is zeroed, and the slave selects are all high. I tend to make it shift out a byte without anything selected, just to make sure. For the DUART, I run my pre-baked init routine that I adapted from BDDs setup table, and converted to linear code.

I'll go back to the SPI loader(it's slightly simpler) and make sure it's still playing up. If it is, I'll post up the code.

The worst thing about this kind of development is that so many things can result in the subject appearing to do nothing at all.