Well, it seems like all the maladies I've been having with the Kestrel 8K design have *vanished into thin air* once I replaced the clock circuit with a unit that had much sharper rise and fall times. In particular, I'm using a clock oscillator cans that you can get pretty cheaply. And even with the solderless breadboard, and the long, loopy wires, I've successfully ran the Kestrel 8K stably at 4 MHz. And judging by the oscilloscope traces, I can probably get a few more MHz out of it before I start running into capacitance-related problems.

So, lesson learned: if you're experiencing weird, wonky issues with the 65816 that seem to defy explanation, check the rise and fall times of that clock!

Well, not all bugs, it seems, was cured with this.

The following code:



does not run to completion.

After downloading it into the Kestrel's memory space, the CPU goes into native mode, immediately goes back into emulation mode, and then a *continuous* blast of memory writes occurs. That is, it never stops writing to memory, and so far as I can tell, the memory it's writing to seems to be between $0100-$01FF. Looking at the o'scope traces, I'm seeing three byte writes to memory, which implies a JSL instruction, since the CPU is operating in emulation mode. The address bus is confirmed to be $0000 and $0001 prior to the JSL.

So, I'm really confused....why is this happening? As I've replaced the RAM chip twice, I've effectively confirmed it's not the RAM chip.

I can no longer figure out why this is happening. I am at a *TOTAL* loss at this point. Why is this circuit just plain refusing to work when presented why any *shred* of a non-trivial program??????

*sigh*

AH HA!

I found the bug. The assembler, ACME, recognizes TAS as a valid opcode (especially since it is listed as a valid synonym for TCS), but produced no code for it. Therefore, JSR was pushing bytes into I/O space, and RTS was popping them from I/O space, with predictably disasterous results.

I detected this because I changed the IPL port around a bit, so that I can control the data bus _OE line independently of the address bus _OE line in the IPL circuitry (updated schematics for everything will be coming sometime tomorrow). Well, as I was stepping through the bytes in RAM, I noticed that after the first LDA, there was immediately after it another LDA.

So, the lesson in the opening post is valid -- tR/tF was key to solving the hardware bug. But TAS/TCS was key to solving the software bug that ensued thereafter.

So, right now, the Kestrel is, so far as my tests are showing currently, working as expected.

Oh, and I finally got around to replacing the 8K RAM chip with 32K.