[sdiy] Analysis of the TB-303 CPU timing

[Rainer Buchty]

On Mon, 20 Mar 2017, Neil Johnson wrote:

> For many micros (especially smaller ones) I'd agree, but that's not 
> always the case.  For example the A86 shareware assembler touted a 
> unique "footprint" in the generated machine code (for example, there 
> are two encodings of the "MOV AX, BX" instruction) that, according to 
> the author, could be used to determined if the object code was 
> generated by A86 or not.

It however does neither make a functional difference (the different 
encodings behave exactly identical) nor a logical one (the source code 
also looks identical).

(Thanks for bringing that up! I wasn't aware that x86 allowed that, and 
I'm still unsure whether really Intel endorsed that. From the 
descriptions I found, it seems more like a "look this works, too", but 
wasn't really meant to be used that way.)

> I've long suspected that some synth OS code that I've looked at might 
> have been written in something like PL/M.  I agree back then C was 
> probably not mature enough, but PL/M was.

Was it also officially available to the non-Intel/non-Zilog world? (But, 
yes, from the language features I can see why it could be used at least 
for code that was neither time- nor space-constrained.)

Some synth OSes are weird. For instance, the FZ-1 OS even kept ENTER 
0x0,0x0 / LEAVE ... Either they had weird coding guidelines at 
Casio ("make a function/procedure always look like one") or were using a 
higher-level approach with an insufficient optimizer. An assembly 
programmer surely wouldn't have kept that.

Likewise, the older Ensoniq stuff has quite a number of unreachable code 
lines in there, or stuff like branches to RTS.

I guess they used all sorts of tools back then to make life easier and 
then applied manual changes.

Rainer