[sdiy] Analysis of the TB-303 CPU timing
rainer at buchty.net
Mon Mar 20 22:37:20 CET 2017
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.
More information about the Synth-diy