[sdiy] Analysis of the TB-303 CPU timing

[rsdio at audiobanshee.com]

On Mar 20, 2017, at 2:37 PM, Rainer Buchty <rainer at buchty.net> wrote:
> 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).

That is an astute observation, Rainer. In addition, I'm certain that the two encodings execute in the same number of cycles (probably what you meant by behaving exactly identically), and that would make it moot for the purposes of analyzing the precise timing of the firmware. Besides, even if two encodings somehow had different cycle timings, the disassembler would still know this precise detail because it has access to the raw machine code.

> (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.)

It's often possible for multiple encodings to end up meaning the same thing. This is possible both for RISC architectures, where specific opcode bit fields are dedicated to specific functions, and also for irregular architectures like the i86. I don't know if it's fair to say that they really weren't meant to be used, because the opcode decoder took a lot of work to design, and I'm sure that every bit encoding was intended to be used for something. When multiple encodings have the same result, who's to say which one is "preferred" - they're both intended to work for at least some of the permutations. In other words, there's no way to drop the redundant results without also losing the unique operations.


> 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.

When I see ENTER and LEAVE, I assume 68000, which is a CISC design. By the time the 68000 came out, I think it's fair to say that many synth firmwares were being written in C, or at least using a macro-assembler. If I recall correctly, there are side effects of ENTER / LEAVE that are useful even when the parameter is 0x0. At the very least, the debugger may find it easier to trace through code. One of the driving motivations behind adding such opcodes as ENTER and LEAVE was to take advantage of high-level language compilers. Thus, I'd say it's a safe bet that these synths were coded in C.

> 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.

I'm fairly certain that all of the Ensoniq synths/samplers were based on the 68000 processor. So, all of my above comments about CISC processors and Standard C apply to the Mirage and probably everything that came after.

By the way, as part of my BSEE degree, I wrote a 68000 emulator in 1987-1988 that could run emulations of various hardware platforms that were based around that chip. I'm sure I've forgotten a lot of 68000 magic since then. The emulator included ROM, RAM, and UART peripheral emulation, too, so as to fully emulate the hardware platforms. It would have been a massive effort to emulate the DOC or ESP chips from Ensoniq, so I never simulated a real-time audio synthesizer based on the 68000. That emulator development served as the background experience for many disassemblers since.

Brian Willoughby
Sound Consulting