When you're developing something that lives only inside of an emulator, there's a big chance that the code, which seems to work just fine in a debugger, will fail to work on real hardware. That's exactely why I wanted to hook up a logic analyzer and see what my code is doing outside of a silicon chip. Unfortunately due to my non existing safety precautions I have released the magic smoke from the CPU and didn't have a chance to see my code on real hardware. You know the story.
This time I have taken a slightly different approach. No darn logic analyzers. Real hardware only. This is what I ended up with:
It's pretty simple: just an octal edge-triggered latch and some LEDs. The latches are connected to PB4..6 and the clock input goes to PC2. As you can see this time I have used some heavy duty tape, just in case :) OK, but will it work?
Nothing happens so far. Maybe I should change the bank number?
Nice, looks like a binary five! So it works. Kinda. I have cheated a little bit. You see, the code I wrote gets executed only if I explicitely change the bank number, but if the patch is loaded from the memory (e.g. on power on or patch change), nothing happens. I have to dig a little deeper and find another place to call my bank switching routine. But I think that I already earned a beer:)
Oh, there's one more thing that can complicate a thing or two. This piece of code:
LXI EA, 2680H ; EA = $2680 (working patch) LXI H, 2000H ; HL = $2000 (patch memory) .1AEEH: LDAX H ; A = (HL) ANI A, 7FH ; highest bit = 0 STAX H ; save back to (HL) INX H ; HL++ DEQ EA, H ; loop until EA==HL JR .1AEEH
For some strange reason the memory region which contains patches gets ANDed with 0x7F to set the highest bit to zero. If you look at the DW6000 bit map, you can see that no parameter uses the highest byte. Unfortunately my parameter violates this rule:
Is there any reason behind it? Well, there are two ways to find out: a) analyze the source code or b) disable it and see what happens. Guess which path I will take:)