GARTHWILSON wrote:
(I don't know about four transitions per second though! If you have the logic analyzer, you can go at least at many kHz, right?)
My thought was four transitions per second on A14 and A13, with the phi2 clock running at 3.579545 MHz, meaning a lot of code spent in a dead loop. But the point about the logic analyzer raised a possibility too convenient to ignore (which I will comment on below).
Arlet wrote:
Don't worry. The problem with floating inputs in CMOS is that you can get more current consumption, but that only happens when you keep the voltage in the intermediate level. And the current usually isn't excessive as long as you don't put multiple pins in that state for prolonged periods of time. As Garth says, when the voltage is well defined, and you let it float, it's going to stay at that level for a while.
Okay, so floating for a single cycle at a time won't be a problem. I know that it's been done to good effect on NMOS 6502 systems (such as the Apple ][) to monitor things like DMA processes stealing the bus for a cycle every so often, or the video data stream on a timeshared bus, but wasn't sure how safe it was especially when dealing with CMOS parts.
Arlet wrote:
In any case, when tinkering with electronics, I recommend getting a power supply with adjustable current limit, so you can set the maximum current at a safe level. If you can't afford one, pick a supply with a low current, like an old phone charger or wall wart rather than an old PC PSU.
My current power supply is two AA batteries in a holder with a 5v converter affixed to the underside. That might allow drawing enough current to do damage, but nowhere near what an old ATX supply can put out.
Arlet wrote:
Be aware that a logic analyzer works in binary, and can only be trusted if you know that the signals really are well defined. For instance, if you have two devices on the bus both talking at the same time, you may get some intermediate voltage. On the logic analyzer, you'll just get ones and zeroes.
This is something that I should have already known just from background knowledge, but hadn't put together yet. Thank you for the warning.
Based in part on everybody's input thus far, I decided to revise my plan:
I set up my oscilloscope and my free-run board and made sure that the free-run was still working.
I next set up my logic analyzer, hooking it up to phi2, and the address bus, and got that working. This means that I know that my test equipment functions, and that I have some idea as to how to use it... And obviates the LED test for validating that reading from ROM works. Too convenient a possibility to ignore, as I mentioned above.
Next, I added a line from the logic analyzer to the RESB pin on the 'c02, and worked out how to get a trace starting from the cycle before RESB goes back high. I can see the reset sequence run, from finishing executing the previous instruction, to saving the state on the stack, to loading the RESET vector, to starting execution at $EAEA (because I have the data bus configured as a NOP generator).
I seem to have just enough probe connectors / grabbers to cover the address and data busses, plus a clock line, plus maybe three other signals (phi2, RESB, and R/~W, probably). I expect that it would be more cost-effective to buy another of the same type of analyzer (maybe the G model this time) from eBay than to source the probe connectors individually. Given a logic analyzer and a ROM programmer, I can't imagine needing a single-step circuit in my design.
I still need to work out my small test program, but now it can be as simple as INC $00 / INC A / PHA / PHA / INC $01 / PLA / JMP back to the beginning. That would show that the ROM works. It would show that the RAM at least partly works once there's RAM in the system, is trivial to hand-assemble, and so on.
Thank you, all, for your help and input.