[sdiy] Analysis of the TB-303 CPU timing
krish0005 at gmail.com
Mon Mar 20 13:08:20 CET 2017
Yes, probably my mail was a bit too generic, but my warning was exactly the
following you synthesized:
"Don’t trust a disassembler unless you verify its translation against the
official data book for the CPU."
I'm quite sure Roland wrote that code directly in Assembly...
Still, my suggestion on a general level is to try different disassemblers,
and see if setting same exact processor part number gives you different
output.. (if really your disassembler also works with that specific CPU..
does it ? really ? )
I do know and understand optimization of code is done on higher level
codes, not machine level where it is already translated to its lowest form,
but still, Disassemblers might work differently, and as you do, writing
your own one is really the only option to be 100% sure of what it does
Nevertheless, i would suggest everybody interested on this thread to read
what Robin Whittle has said regarding Roland original CPU replacements
attempts and reverse engineering in the past:
So first of all.. do "we" have the original Data Book ?
Robin talked about a:
*NEC Microcomputer Products 1984 Data Book*
In the PDF from Julian i see this reference:
*(Japan, july 12, 1983 E2).*
* NEC Microcomputers, Inc., “µCOM-43 Users’*
*Manual,” (NEC Microcomputers, Inc. 1978)*
Are we sure its the same, and we have all necessary documentation to make
this checks and confirm the output of the disassembler ?
This referenced one and linked by Robin looks to be still up :
I'm citing a fraction of Robin's mail cause its related to previous
exchanges related to mask ROM decoding:
"The only way I know of getting a dump of the program memory is to
decapsulate the chip and analyse it with an electron microscope. As
far as I know, whatever eats the epoxy (not much - maybe nitric and
sulphuric acid) will make a mess of the delicate aluminium tracks.
Theoretically a scanning electron microscope image might be analysed
to reveal a pattern of 0s and 1s in the ROM section. With some
educated guesswork, this could be turned into the program memory contents. "
Haven't follow this thread carefully maybe, and i apologize if i missed
but in the end looks like having an electron microscope was not needed to
obtain a dump of the program memory and now you guys have a full dump and
successfully disassembled it, right ?
Well if yes, then of course still you need the official DataBook from NEC,
and carefully check what came out from your disassemblers to see if
everything was translated correctly.
Only after having completed this phase successfully you can go to the code
interpretation and analysis.
Most experienced people i talked to about disassemblers in the end said
"... but i prefer/preferred writing my own one."
Now i'm curios to know:
Which disassemblers has been used for this 303 reverse engineering testing ?
Was it possibile on them to select exactly that NEC family part number ?
How many disassemblers do you know that perfectly support that old 1982 CPU
Have you compared the output of more than 1 disassembler that was
configured to translate for that exact CPU ?
What you and Brian said about how disassembler are supposed to work is
Still i don't see enough technical evidence being shared here to tell if
this is also true in the facts, or not.
2017-03-20 12:11 GMT+01:00 <rsdio at audiobanshee.com>:
> There’s no need to chase three or four different disassemblers. All you
> need is the data book for the exact processor part number, and it will list
> a definitive set of opcodes. You’re correct that a generic disassembler
> might get some opcodes wrong, but then your listing will quickly turn into
> garbage, and that should be blatantly obvious. For these 8-bit processors,
> it’s usually a very quick task to check a few tens of opcodes (there are
> usually less than that, and not more than 256, of course). There is a
> one-to-one mapping between machine code and assembly code.
> There is no such thing as disassembler optimization. You have it
> backwards. When code is written in a high-level language like C, the
> compiler can create different opcodes for the same source depending upon
> the optimization level and the compiler vendor. However, when you’re
> looking at assembly or machine code, there is no optimization layer. What
> you see is what the processor will execute. In fact, the timing is
> precisely known when looking at machine code or disassembly of machine code
> into assembler syntax.
> So, the trouble here is not the disassembler, but recreating the original
> source code that the developers used. For something of the TB-303 era, the
> developers probably wrote the entire firmware in assembler. Writing
> firmware in C was not very common, especially when the ROM was only 2 KB.
> That’s fewer than 2048 instructions, because many instructions have
> operands that take an extra byte or two, and then there are the tables of
> data that should not be disassembled.
> Uncommented assembly is very difficult to read because there are no
> variable names or comments. It has nothing to do with optimization and
> everything to do with human-readable code. The processor doesn’t need the
> comments, so the ROM doesn’t include them.
> I write my own disassemblers for projects like this one. I do that because
> I can embed symbols that represent the custom hardware of the particular
> vintage synth in question. That means my disassembler listing is more human
> readable (at least for one particular human) than the default disassembler.
> Basically, you’re right: Don’t trust a disassembler unless you verify its
> translation against the official data book for the CPU. But optimization is
> not part of the process of disassembly. That’s in the realm of compilers.
> You’ll be able to determine the precise timing from the ROM data and the
> data book.
> Brian Willoughby
> Sound Consulting
> On Mar 20, 2017, at 3:50 AM, KRiSh <krish0005 at gmail.com> wrote:
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Synth-diy