I am going cra5y !

It works sometimes, and not other times, for identical input.

It is not initialization (I think) because the badge says everything (Registers, RAM etc) is zeroed on start of Run.

I can see that sometimes when I enter a "A" on my terminal (PuttY) I receive two(!?) characters in the serial buffer on the badge, the first being the DC3 code.

I did a pythonscript to slowly send characters and receive them (workaround for the Serial Bug flow control problem) and it works on the 1st run, but not on subsequent runs, unless I totally reboot everything. Again, it seems an extra DC3 sneaks in.

Somewhere, the USB/Serial/Windows gets buggered on receiving the binary header? But receiving binary is essential. I do not have flowcontrol enabled. (DC3 is ^Q ie flowcontrol)

Much later (update)

It's been a long debugging session. There were multiple flaws, partially obscuring each other, so fixing one, just created a different error. The highlights (or should that be lowlights :-) ? ) :

The serial interface on the badge is sensitive. It gets totally confused if you only take the high nibble, ie always take both. Likewise with writing. If you have confused it, you need to do a hard reset - the RUN does not clear it. (This was first tracked down when I put a logic analyzer on the serial, and saw that only the expected characters were sent)

In order to workaround the duplex problem - that no characters are waiting to be read when sending - the simple driver program and the badge code have to agree. I wasted a lot of time on one assembler bug, that actually was an oversight in the protocol.