6507 debugger using real hardware

[keoni29]

Because I needed a way to quickly debug code reliably I made this little test setup. It is a 6507 hooked up to a modern microcontroller: the propeller chip. The propeller generates clock signals and it acts as ram. It also gives the 6507 control over 4 I/O pins. Addresses $0000 and $0001 are the data direction and data register of the I/O port (just like the 6510!)

Another advantage over regular ram is that the propeller chip can send the address and data bus value after each clock cycle to my pc via usb! You can even load binaries from the pc.

 

[Rybags]

Cool. Pity the 6507 has no externally generated Interrupt capability though, makes it somewhat hard for you to be able to pause or grab the regsiter states.

[+batari]

Single-step debugging may be a little hard to manage but certainly you might be able to patch in a $00 (BRK) where you need to take a snapshot of the CPU state. I think $00 was chosen for the opcode for a reason, for at least two reasons I can think of. First, you can always burn zeros to an already-programmed EPROM. Second, often the pull-up transistors on that old NMOS stuff were very weak and could easily be overridden with a low signal without much risk of damage.

 

But I am curious what sort of things you need instruction-level debugging in real hardware for, that emulators can't do?

[Rybags]

The ability to just take a snapshot of RAM would probably come in useful. Of course it'd be most useful if the thing could exist inside a peripheral or 2600.

 

Maybe if it just shadowed the contents of what is written to TIA & RIOT and had the ability to offload snapshots at user-specified events.

[keoni29]

Single-step debugging may be a little hard to manage but certainly you might be able to patch in a $00 (BRK) where you need to take a snapshot of the CPU state. I think $00 was chosen for the opcode for a reason, for at least two reasons I can think of. First, you can always burn zeros to an already-programmed EPROM. Second, often the pull-up transistors on that old NMOS stuff were very weak and could easily be overridden with a low signal without much risk of damage.

 

But I am curious what sort of things you need instruction-level debugging in real hardware for, that emulators can't do?

Simple things like hooking up peripherals to an I/O port are quite difficult to pull off in a 6507 emulator. You'd have to modify the emulator and add a peripheral emulator.

 

The ability to just take a snapshot of RAM would probably come in useful. Of course it'd be most useful if the thing could exist inside a peripheral or 2600.

 

Maybe if it just shadowed the contents of what is written to TIA & RIOT and had the ability to offload snapshots at user-specified events.

 

It might be possible, but it is beyond the scope of this project.

[enthusi]

Thats a cool project. Im wondering though: are there any open questions you have on the 6507?

[keoni29]

Well actually: yes. I just started programming the 65xx series a week ago and I still have some questions on how the reset sequence works. Do you need to pulse the clock a couple of times while holding the reset pin down or do you only need the 8 initialisation cycles after the reset pulse?

[Rybags]

Any findings there yet? Many 6502 implementations seem to use the 555 timer to generate/hold the RESET during powerup.

Unsure what the reasoning is for holding RESET for whatever duration, maybe the expectation is to get the clock generation settled before startup.

 

Also, 6502 series (at least the early NMOS) supposedly have some settings indeterminate when powered on, e.g. Stack Pointer, Decimal Mode, IRQ mask.

[+batari]

Well actually: yes. I just started programming the 65xx series a week ago and I still have some questions on how the reset sequence works. Do you need to pulse the clock a couple of times while holding the reset pin down or do you only need the 8 initialisation cycles after the reset pulse?

I think the 2600 just has a pullup resistor and cap to ground on the reset line and that's it. Nothing fancy at all.

 

But if you're interested, while developing Harmony we wanted to detect when the 6507 actually started up. We made a simple logic analyzer that tried to determine what happened, and it was definitely not simple to detect. All manner of weird and seemingly random things took place and we couldn't make much sense of it. Simply checking for reset vectors or even a sequence wasn't nearly enough, nor were counting clock cycles or anything, sometimes it would work as expected, sometimes it would reset itself 3-4 times, sometimes it made no sense at all.

 

If anyone is interested I will look for the logic analyzer output.

[keoni29]

I found out that once it fetched the reset vector it starts fetching the first instruction. This happens during cycle 7 and 8 of the reset sequence after the reset pulse. I noticed that when I don't apply a couple of clock pulses during the reset pulse the cpu won't start up properly and it will not fetch the reset vector.

Edited February 19, 2014 by keoni29

[Rybags]

Not totally sure but RESET should act in some ways like IRQ or NMI - the sequence there is push PC and S to the stack then fetch PC from the hardware vector and continue execution.

 

As the chip is NMOS there is no sleep function and registers and much of the CPU is like dynamic RAM and requires continuous clocking to keep contents refreshed.

 

How well documented the actual Reset process is, unknown. From the programmer's point of view, the essential information is there anyway ie registers are indeterminate and the PC is fetched.

 

The intent of RESET was generally for powerup/coldstart anyway, a warmstart implementation is simple enough, Atari XL/later computers do so by keeping 3 "magic" numbers in RAM that wouldn't otherwise have that number when first powered on.

[+batari]

I found out that once it fetched the reset vector it starts fetching the first instruction. This happens during cycle 7 and 8 of the reset sequence after the reset pulse. I noticed that when I don't apply a couple of clock pulses during the reset pulse the cpu won't start up properly and it will not fetch the reset vector.

Yes, it typically does start fetching the first instruction after reset, but my results showed weird things happening after that. You'd get 3-4 false starts sometimes before the real start.

 

I assume since you were asking, you were trying to detect startup and it wasn't working as you'd expect. But maybe it does work more as you'd expect while you are running it on a proto board. Inside the 2600 with the RC on the reset line and the clock generated by the TIA, odd things happened.

 

We also tried to find documentation on the actual reset sequence but never found any documentation about it even after extensive searching. Your best bet might be the virtual 6502 project (that is, if it allows you to monitor what happens at reset.)

[keoni29]

I found this:http://www.pagetable.com/?p=410

I used the documentation of the reset sequence to determine when the cpu was ready.

[Bruce Tomlin]

Single-step debugging may be a little hard to manage but certainly you might be able to patch in a $00 (BRK) where you need to take a snapshot of the CPU state. I think $00 was chosen for the opcode for a reason, for at least two reasons I can think of. First, you can always burn zeros to an already-programmed EPROM. Second, often the pull-up transistors on that old NMOS stuff were very weak and could easily be overridden with a low signal without much risk of damage.

 

If I was doing it, I'd want to do it like the Applied Microsystems EM-180 series emulators and use a real 6502 (or a 6502C if you need a real HALT input), that switches worlds between target and debugger modes. When you do that, reading the target CPU state is easy. But it takes a lot of hardware to do that. (And when the CPU hits an illegal instruction that hoses the CPU, your emulator is hosed too. The 6502 has a LOT of opcodes that do that.)

 

Using a fast modern microprocessor has a lot of potential, especially if you use bus sniffing to determine the CPU state. For instance, if you see a LDA instruction, you can get the new value of A from the next bus cycle. For TAX, you move the sniffed value of A to X, etc. And stopping a 6507 should be really easy because of that HALT line.

 

But yeah, the 2600 is better done with a software emulator if for no other reason than you can't stop TIA with just an ICE on the CPU.

[Rybags]

6507 doesn't have a /HALT pin. There is /RDY which could be used by a debugger. But /RDY isn't an instant stop, there's minimum 1 cycle delay and it doesn't stop write operations so it can be longer.

 

Using a Sally 6502C might be an easier route. For a 2600 mode all you need to do is ignore A14-A15 and not supply any interrupts to IRQ or NMI.