Noob question: Tri-state logic chaos and system startup

[Aaron]

Dr Jefyll wrote:

If it were imperative to gain another byte then the double-duty operand/opcode would be worth it. But merely to save a diode... I dunno.

That's a very reasonable perspective, but I think we're already deep in the weeds (thanks to you ). This project screams "abuse" right from the get-go, and as it's 100% for my own edification and entertainment, I don't mind sacrificing software maintainability to pursue a smaller BOM. It's a fun exercise that I'll continue thinking on. I think the original RTI approach would have worked (unless S really is unpredictable), but the ability to lose a '138 definitely justifies the BRK change, and the other suggestions add up to some fun sprinkles on top, so...why not?

Anyway, I'll render out an updated schematic shortly with credit to you for the tweaks and we'll see where it goes. I need to clear my breadboard of the last project (already moved to a PCB) so that I can start in on this one!

[BigEd]

An excellent adventure!

Two points to note:
- yes, in NMOS 6502s, including Ricoh's 2A03, the stack pointer, together with A, X and Y, are indeterminate at power on. This is the kind of thing visual6502 can't model, being a digital, and binary, simulator.
- as it happens, there's a new page on the visual6502 wiki all about interrupt hijacking, which draws on extensive experiments with visual6502. I would take it as definitive, at least once 'many eyes' have looked it over and it's become mature.

[Dr Jefyll]

Thanks very much for those notes and links, Ed. No doubt I could've found them myself but I'm not as efficient as you when it comes to search skills (few people are, I suspect). And this topic is already stealing time which I "should" be spending on less frivolous pursuits!

Having said that, I'll throw one more idea out there (which I might or might not wrestle with, and others are certainly welcome). It might be possible to have the entire 64K filled with just one, 8- (not 16-) byte pattern. That'd free up the two NAND's which we recycled (as if that matters, but as Aaron said we're already well into the weeds, so who cares).

Up til now we've been storing code that includes two jump instructions (or equivalent). But we only need one. The ISR should end by falling through into the wait loop -- not jumping to it. Then the code can easily fit in 8 bytes. The trick is in mapping it so you get RST and NMI vectors that work. Luckily only 3 bits out of each 16-bit vector have any significance -- in context as a vector, I mean. And that gives some freedom to the other context, when those same bytes are interpreted as code. (I'm thinkin we don't need the IRQ/BRK vector, 'cause we'll use a JMP abs instead of BRK.)

[Aaron]

BigEd wrote:

- yes, in NMOS 6502s, including Ricoh's 2A03, the stack pointer, together with A, X and Y, are indeterminate at power on.

Ah! Thank you for this. This hadn't turned up in my own searches, and I'd certainly have been pulling my hair out--what little I have left, anyway!--if I'd built the thing and run into this.

Dr Jefyll wrote:

The ISR should end by falling through into the wait loop -- not jumping to it. Then the code can easily fit in 8 bytes. The trick is in mapping it so you get RST and NMI vectors that work. Luckily only 3 bits out of each 16-bit vector have any significance -- in context as a vector, I mean. And that gives some freedom to the other context, when those same bytes are interpreted as code. (I'm thinkin we don't need the IRQ/BRK vector, 'cause we'll use a JMP abs instead of BRK.)

The "falling through" approach was one of the first I'd entertained, but I guess my devil's hat wasn't firmly in place back then. Here's one 8-byte solution, although I'm not happy about the cycles wasted on the TXA. I'll think on this some more and see if I can find a better one (that doesn't need an extra instruction). I'm also back to 15 diodes, so hmmm... Which kind of contortionist am I trying to be? (STA could be STX if TXA was replaced with CLC or some other no-oppish thing, but that feels somehow worse. I guess, if I just let go of the diode count, I may as well use a NOP...)

Code: Select all

$xxx0: $xx (flip-flop)
$xxx1: $40
$xxx2: $4C (JMP absolute)
$xxx3: $02
$xxx4: $A2 (LDX immediate)
$xxx5: $xx (flip-flop)
$xxx6: $8A (TXA)
$xxx7: $8D (STA absolute)

This solution is entertaining in large part because the low byte of the reset vector is also the first instruction of the NMI ISR, and the low byte of the NMI vector is also the first instruction executed on reset! Who'd have thought you could have "spaghetti code" with only eight bytes?

EDIT: And an 8-byte version with 12 diodes. Uses a throwaway ASL as a no-op. This is pleasing because, as a reset vector, in has the same effective value as LDX, so the LDX and STA can become LDY/STY. I'll probably settle here for now. My brain is tired, and at this point the functionality of the thing is pretty well nailed, I think!

Code: Select all

$xxx0: $xx (flip-flop)
$xxx1: $40
$xxx2: $4C (JMP absolute)
$xxx3: $02
$xxx4: $0A ASL ; as a NOP
$xxx5: $A0 LDY
$xxx6: $xx (flip-flop)
$xxx7: $8C STY

[Dr Jefyll]

Aaron wrote:

And an 8-byte version with 12 diodes. Uses a throwaway ASL as a no-op. This is pleasing because, as a reset vector, in has the same effective value as LDX, so the LDX and STA can become LDY/STY.

Nice! And illustrative of what can be accomplished with one's devil's hat firmly in place! Further improvement is no doubt possible, but I agree that, with half the circuit already removed, the gains going forward will be smaller.

If you find energy to resume the battle it might be worth reconsidering BRK as a JMP. Interrupt hijacking might ruin this idea, but I'm not sure. One very specific question needs to be answered. If the wait loop is a series of back-to-back BRK's, is it possible for an NMI to actually get lost ? Obviously BRK is smaller than JMP absolute, and that might be helpful.

Another possibility is to forget NMI and simply use RST only. IOW, no exit from the wait loop. Every time the 2A03 comes out of reset it does one access for the Arduino then stalls (waits "forever" -- ie, until the next reset). It means one less vector that needs to be mapped properly, and again that might be helpful.

Hardware-wise, the two HC574's could be replaced by two HC670's, and that makes the project slightly smaller, physically (a pair of 16-pin IC's rather than a pair of 20-pins). It also leaves you with two extra registers to play with, and that'd let you eliminate some diodes at least.

[Aaron]

Dr Jefyll wrote:

Another possibility is to forget NMI and simply use RST only. It means one less vector that needs to be mapped properly, and again that might be helpful.

This is another thing I'd wondered about, but set aside for fear that asserting RST might reinitialize certain internal audio registers, and that would definitely be bad. I've seen conflicting accounts of this, but I'll play with it.

Regarding the HC670's: Those do look quite interesting--definitely something to keep in mind! I had contemplated replacing the HC574's with HC595's so that pin-starved MCUs might have an easier time of it (using SPI). I might head in that direction first.

I went ahead and rendered out a new schematic showing the 8-byte approach with the throwaway ASL. Thanks again for all the encouragement!

EDIT: Although... (Damn! Too much fun to keep twiddling with this!) For the shortest time between NMI's, it'll probably be best to go with something that puts the "NOP" (ASL, CLC, or whatever) at the end rather than the start. Then another NMI can land on the "NOP" and it won't matter. An example would be:

Code: Select all

$xxx0: $40
$xxx1: $0A (ASL ;or CLC....or NOP)
$xxx2: $4C (JMP)
$xxx3: $02
$xxx4: $A2 (LDX)
$xxx5: (flip-flop)
$xxx6: $8E (STX)
$xxx7: (flip-flop)

[Dr Jefyll]

Aaron wrote:

RST might reinitialize certain internal audio registers, and that would definitely be bad.

Oops, good point -- I didn't think of that!

Quote:

I had contemplated replacing the HC574's with HC595's so that pin-starved MCUs might have an easier time of it

IOW connect to the MCU with a 1-bit data bus, not 8-bit. Certainly a viable approach, which'd save a lot of pins (but slow things down somewhat, although perhaps not enough to matter). Using 670's you could opt for a 4-bit bus, which might prove to be the happy medium. (IOW the MCU writes 1 nibble at a time, even though the 2A02 reads are byte-wide.)