6502.org

Interesting - I was thinking single step would be really crucial. Perhaps in the early stages it is?

Mmm. To my mind, a single-step circuit is entirely unnecessary, and that was before I had access to a logic analyzer. My current plans call for building a system with a UART and possibly a VIA or two. Having a logic analyzer means that I can capture a trace of what went across the data and address busses starting at a given point (reset seems like a good one to start with), which is far easier to capture than a bunch of LEDs (or using a scope or multimeter probe) on the various signal lines. And once the UART works enough to be able to talk with another computer then, yes, debugging gets a whole awful lot easier, at least in theory.

For starting without single-step and without a logic analyzer, throw LEDs somewhere that you can control, such as the high address lines, or on VIA outputs or something. The more LEDs, the more information you can get from a single run. Have your initial programs end by putting a status on the LEDs and going into an infinite loop (or switching between more than one states visible on the LEDs with sufficient delay that you can see what the states are). It's possible to write code that doesn't use RAM (as mentioned earlier in this thread, and as happens in modern PC BIOSes before the north bridge / memory controller is configured, or in old-school PC BIOSes before one of the DMA channels is configured for DRAM refresh), even if it can be a bit twisty at times. Having a logic analyzer means that I can jump straight to just trying to hit the RAM at a couple of points and watching the values on the bus to make sure that they're "right". It also means that I don't need to think my test program through nearly as much to start with.

I would say it has some value when you're still learning the instruction set and you don't have it down clearly in your mind what particular instructions do. After you get past the very basics and your programs are more than a handful of instructions, single-stepping becomes so slow so as to usually be useless. It may take many thousands (or even millions) of steps to find your bug, so it becomes more productive to put beeps or status outputs at strategic points in the program, see what you get, relocate them, etc., until you zero in on the problem. Something I did in my early years was to have debugging routine which I would call at key points in the code that would stop and let me peek around at different registers and memory locations. I called it BREAK but did not use the BRK instruction but rather JSR BREAK. Now most of the stuff I work on is realtime, meaning that if you pause the computer to look around, the hardware it's controlling won't work at all, whether because of time constants, resonances, whatever; so having it quickly output a status on the fly and keep moving is important. A single pin to connect an oscilloscope to is often enough.

I would favor beeps over LEDs for many things though, because the beep can tell you where it is in the program by its frequency and duration, and lets you know that the program is indeed in control, whereas an LED could get turned off and on unintentionally by bugs and it doesn't tell you where it is in the program-- unless you put a pulse of a given duration to the LED which may come too often to can't see it anyway, and then you're back to using the oscilloscope.

Don't give up too fast. Why do you think it will be better with a 65816 in November? How do you programmed your ROM? Can you proof that it still contains the right data? Last weekend I placed my EEPROM wrong into my breadboard (shifted by one hole) and the then wrongly connected wires wrote several bytes into to EEPROM in cause of a flapping or floating R/W line. (but I was not aware of this) After I moved the EEPROM to the correct position, the whole system behaved really strange and I was looking for a problem with the wiring. About half an hour I was looking for the bug in my setup, until I checked the content of the eeprom and wrote the correct data again. Placing the ROM with correct data to the correct place, the system worked as expected immediately.
I think the shortest programm for testing is an infinite loop by doing something like this: then set the resetvector to $e000 and watch what happens on the address- and data-bus. So you only have to write 5 bytes to your ROM.
I've done a lot of testing without RAM on my system. The only thing is, that you cannot use the stack or store data in other places then X,Y and A. But this is still enough to create delay loops and let one address-line flap in a defined period. This can really easy be monitored with an oscilloscope or a logic analyser.
I also played with two 74HC574 octal D-flip-flops using one as input and one as output, still without RAM in my system. I hooked up 8 LEDs (over a ULN2803 darlington driver) to the output lines to have some visual feedback.
Here's the code for that. It's long, because of the missing RAM, but it takes the byte from the "input" chip and writes the byte to the output chip. wait a while and then let all LEDs blink several times. then start again. Once the simple 8-bit output works (without the need to interact with a VIA chip), you can easily create debug output by switch on the LEDs one by one whenever a block of code has been completed. This is my "documentation" for this setup: Mario.

Immediately. Nice! This is what I find as well when troubleshooting FPGA's. Alhtough I do keep the programming to minimal in order to fully test the hardware.
The main point is as you have stated Mario, is to never give up!

I'm not giving up, I'm out of time. I am no longer anywhere near my hardware, nor will I be until November. Why will it be better (with or without the '816)? I'll have time to work on it again, and I have a plan to address some of the problems that I observed over the past few days. Also, I'll be starting from a position of having done more of the work already. Admittedly, my scope will be more ambitious as well, but it still seems quite doable.

As far as ROMs go, I'm using SST39SF040 parts (512Kx8 FlashROM), and ZIF sockets. My programming setup is an Arduino Mega 2560 R3 wired up to a ZIF socket (there are ample digital pins available, so I don't need any discretes here), and my programming software only writes the program if the sector is blank, and at the end dumps out the program space. I can easily verify if the ROM contents are still good, write a new ROM if they aren't, and with a bit more work I should be able to erase a ROM and try again that way.

I'll see your 5-byte minmal loop and raise you a 3-byte minmal loop: The RESET vector overlaps the operand of the JMP.

Now, all that said, writing up actual documentation for the system is something that I could probably improve upon. Perhaps including more of a "postmortem" as well, the way that I'm currently doing for my arduino ROM programmer code (I'm on the third "test" program in that series, the first to try to store a program into the chip).

Exactly what I found. Once I got past a simple program to light up LEDs on the VIA it wasn't much use. The programs got to big and I got more familiar with the instructions so I had more idea what was going on anyway. I was thinking of adding a beeper on one my the unused pins on the VIA I use to scan my keyboard matrix. Seems like that's a great idea.

Simon

I suppose I was thinking about the very first steps, perhaps having toggled a program into a front panel, or when first trying to get the bootstrap code right.

Jeff tells me that the KIM-1 has a single-step mode. So it must be a good idea!

Cheers
Ed

I think the AIM-65 did too, where Sync was used with an interrupt. (Then once you're in the interrupt monitor routine, the I bit was set so it wouldn't recursively interrupt with every instruction in that interrupt monitor routine.)

(I should add: Jeff said that the KIM-1 uses NMI, and masks in the high order address bit, so it single-steps only low memory programs and not the monitor itself. No need for a mask and no interference with IRQ. In both cases, you need enough of a monitor in place to offer some user interface in response to each step. Ruud has written about this at http://www.baltissen.org/newhtm/kim.htm)

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.