[sdiy] Analysis of the TB-303 CPU timing

[Roman Sowa]

With all due respect I strongly disagree. Disassembler takes the 
instruction code and turns it into mnemonics, so there's no room for 
optimization, or missed/altered codes. If it's clear for the micro to 
see just those bits, it's just as good for turning that into readable form.
There are instructions of course that can have different mnemonics for 
ease of writing but share exactly the same code. Nevertheless for 
someone writting code in assembler it's rather obvious. And one needs a 
bit of assembler experience in order to analyze the code.

Roman
who wrote a disassembler once long time ago

W dniu 2017-03-20 o 11:50, KRiSh pisze:
> as far as i remember, disassemblers are not guaranteed to output exactly
> the original code.
>
> it depends how the disassembler work and only defining the processor
> family or model could not be enough..
>
> you might obtain a very similar version of the original code, but not as
> optimized as the original nor 100% identical.
>
> any "optimization" is of course useful in the context of each
> corresponding project,
> and we are talking about a 1981 project so, probably there where some..
>
> i understood the thread is to try re-creating the original source code
> and understand deeply how the 303 seq works,
> especially including any quirk that might contribute to its disputed
> "magic" or "unique" feel.
>
> If that's the objective, then i assume more work is needed on the
> pre-requisites in this case.
>
> I would compare at least 3/4 different disassemblers output and see if
> the code resulting code is the same.
>
> Is it the same ?
>
> If not what is different ?
>
> which disassemblers have been used so far ?
>
> Trusting your disassembler 100% and use the resulting code being
> confident it is already 100% equal to original is a wrong assumption
> IMHO that could lead you to waste your time (in this particular case).
>
> If recreating also the quirks is important here, then you really need
> the correct original code to understand and identify all the
> interactions of the routines/interrupts and their timings, especially
> because efficiency of code and, as said any "optimization", would be
> very important or crucial to the resulting timing.
>
> IMHO, just my 2 cents, etc
>
> K
>
>
>