6502.org

Oops, actually not the high order address bit. From the address decoder, it uses a ROM chip-select signal (dubbed "RS") to inhibit the single-step. The KIM-1 has two 1-kbyte ROM's (one in each 6530 RIOT), and this scheme lets you single-step anything not in the upper ROM. That includes the lower ROM, which has lots of good, stable (and well-documented) subroutines in it!
Here's a schematic except from the KIM-1 User Manual (which we have here on 6502.org). The sequence is:

• (loop in upper ROM refreshes LED display and waits for a keystroke)
• user hits the GO key. Registers are loaded (or pushed to stack) from images held in RAM, and an RTI effects a jump to the user program.
• SYNC and RS both go high as the first user instruction commences. If the SST single-step switch is closed, a pulse is presented to NMI, and the resulting interrupt pre-empts further execution of the user program.
• the NMI handler copies the CPU registers to their images held in RAM
• the LED display / keyboard-scan loop resumes

The loop recognizes other keys, of course, for example allowing you to enter/alter your code, examine and/or modify the register images, load or dump a cassette file, and so on.

As an alternative to single-stepping, KIM-1 users can also use a BRK instruction to synchronously halt their program, or simply press the ST (stop) push-button to asynchronously do so.

-- Jeff

Thanks!

And the early-November window has come and gone, and I got very little hardware work done. I swapped out the salvaged ATX power supply that was providing a ground point for the anti-static mat on my workspace with a different one (the new one containing a 24-pin connector, compatible with the sparkfun bench power supply kit that I had half-assembled before realizing that I didn't have a compatible power supply), ordered a mac floppy drive off of eBay (it shouldn't be too hard to set up to read a GCR disk, right?), and then spent the weekend hacking on my Forth implementation (I'm trying to re-write a standalone block-based PC Forth implementation into a Linux file-based Forth implementation, by bootstrapping from a rather anemic host Forth). So, I now have a use-case for a 6502 system, an angle on powering that use-case properly, and some progress made towards a cross-compilation toolchain.

I also checked the 6551s that I had on-hand, and they're the PLCCs with the same lot number and whatnot that have the stuck xmit status bit. I'm thinking about using them anyway to start with, as they have to be easier to interface than a 16550.

And I've also just ordered a couple of 65816s, the logic for latching the bank address, some faster can oscillators (the ones I have on hand are the 1.8 MHz UART clock cans), and a couple of other bits. I expect that they'll arrive in time that I can use them in my next window (starting the 15th, ending either the 19th or the 3rd). Meanwhile, I might make some progress on the software (Forth) end, since I have everything required for that with me.

I thought those floppy drives were your garden variety types. What's so special about them?

The connector for them is 20 pins, containing both power and data/control signals, the drive has two motor control modes, one of which causes the disk to spin slower when the head is positioned towards the outer edge of the disk, and is used to read both GCR and MFM disks (the one I got is new enough to be able to read both, the older models are only used for GCR disks).

The USB "mac" disk drives apparently can't read GCR disks, which is my actual use-case.

So, it's been more than a year, and finally over the past week I finished putting together a system with an '816, RAM, ROM, a UART, and enough free address space that I should be able to add a VIA if I also bring in a '138 to do the address decoding. It's all still on a solderless breadboard, and it's almost entirely untested, but it's there. I haven't done a continuity test over the various parts of the system, nor have I powered it up since putting in most of the wires, but even getting this far is a bit of an accomplishment for me at this point.

Aside from the discrete bits for the reset circuit, and the 1.8 MHz crystal (used for both the UART clock and for the main CPU clock), the breadboard holds:

• A WDC 65816.
• Two 74HC132 quad schmitt-trigger NANDs.
• A 74HC245 to keep the bank address from colliding the data bus.
• A 74HC573 to latch the low five bank address bits (it also latches the upper three bits, but those aren't currently used).
• A 32kx8 RAM of some sort.
• An SST39SF040 512kx8 FlashROM in a ZIF socket.
• A 16550A UART.

In the image, the left column has the crystal, one of the '132s, the CPU, and the '573. The middle column has the other '132, the RAM, the '245, and the ROM. The right column has the UART. You can see the battery holder (the 5v inverter board is on the bottom side) and a usb-serial adaptor over the unused fourth column on the breadboard.
There is ample board space and address space to add a VIA, though doing the address decoding reasonably looks to require a '138. Adding a '138 would also allow mounting a second ROM for in-system programming purposes or just having more storage capacity, and would still leave quite a bit of address space open (and conveniently-decoded).

My next steps are to work out an initial test program and to improve my (arduino-based) FlashROM programming setup to the point of being actually usable rather than a proof-of-concept for getting data onto a ROM. Eventually I want to do a more-permanent (wire-wrap) version, but there doesn't seem to be much point until I have something running on a breadboard.

It will be interesting to see progress! But, time for a new thread for the bringup, perhaps?

Cheers
Ed

Certainly. I wasn't quite sure if thread necromancy or thread nativity was more appropriate, so I went with the old thread to provide context. When I have more to report on this project I'll make a new thread and link back here.

Great! I'd say necromancy is fine here, but only if it's a continuation of the title topic.