Reverse Engineering of the Emulator I
Date: 2024-02-08, Author: unknown
The E-MU Emulator I was one of the early digital samplers, released in the year 1981. It has up to 8 voice polyphony and 128 kB RAM. Samples and software are stored on floppies.
There are many interesting sounds in the official sound library of the Emulator, which was distributed on 5.25” floppy disks with a proprietary data format. Unfortunately, the floppy data format is not publicly documented and existing conversion software like EMXP sucks.
Since there is no public documentation, the best way to solve this problem is to analyze the Emulator hardware and software and figure out how everything works. A good starting point is the service manual, which contains schematics of the Emulator as well as a somewhat useful description of how the firmware is supposed to work. The user manual is also worth a read to understand what the Emulator can do and how you are supposed to use it.
Hardware Overview
The Emulator consists of a Zilog Z80 CPU connected to
128 kB DRAM, a boot ROM, and a few Z80 peripherals like
SIO (serial interface for the FDD), PIO (parallel
interface to output a few digital control signals), CTC
(counter/timer), and a few DMA chips which are used for
data transfers to/from floppy and to the DACs.
The most interesting part when starting to analyze the
Emulator is how the boot process works: the boot ROM is
mapped at address 0 in the Z80 address
space. Therefore, one can just disassemble a
ROM dump
and see how it works. At least this is what you might
expect.
Copy Protection
Unfortunately, it is not that easy. E-MU really tried to prevent people from just looking at their code for some reason. The boot ROM uses a very simple protection mechanism: data/address line scrambling. The individual address lines are swapped with each other, and the individual data lines are also swapped with each other. As a result, when you try to disassemble a boot ROM dump, you only get garbage. But how can we decode it without a real Emulator? The service manual omits this piece of information.
But the developer of EMXP provides some information, because there is more copy protection in the Emulator and some people prefer to bypass it. In particular, a serial number is stored in the boot ROM and compared to the serial number stored on every floppy, and if it does not match, the Emulator refuses to use this floppy, because it was “copied”. To bypass this, you can change the serial number on the floppy or in the boot ROM, and the author of EMXP provides a document which describes how to change the serial number in the boot ROM.
At this point, I would also like to personally extend a great big “fuck you” to the E-Synthesist (author of EMXP) for withholding half of the information about the ROM scrambling as well as all information about the logical data structures on the floppy for no good reason. If this information was available, the project could have ended here. But we are hackerman, nobody can stop us anyway.
Bypassing the Copy Protection
Although the E-Synthesist does not provide all the necessary information, he still provides some useful information about the scrambling scheme: the complete data line mapping is available, and two addresses are also available.
Since the operating system code which is normally stored
on every floppy is also available
separately,
we can load this into a disassembler. With some trial
and error, we can figure out that the load address has
to be 500 and the program code is not
protected in any way. After a quick look at the
disassembly, we can see that the serial number has to be
stored at address 5F-60 in the
boot ROM and there has to be some subroutine at address
94.
The scrambling scheme means that every bit in the
original address corresponds to exactly one bit after
scrambling. As a result, we know two bit patterns: ROM
offset 237 which corresponds to the address
5F and ROM offset 208 which
corresponds to the address 60. We can use
this information as constraints for a brute force
search.
In addition, the boot ROM has to start with valid code, since the Z80 CPU will execute it. There must not be any undefined instructions up to the first branch. We can use a disassembler to automatically check an address line mapping and skip all mappings which result in invalid code.
Luckily, these constraints result in very few matches in
the end, which can easily be checked manually. After
all, we also know that address 94 has to be
some subroutine, and with this extra information we end
up at a single mapping for the address lines. Now we can
really disassemble the code or even emulate it.
This is the final result for the data line mapping to decode a data word:
0 => 6 1 => 2 2 => 0 3 => 1 4 => 7 5 => 5 6 => 3 7 => 4
And the final result for the address line mapping to encode an address to an offset in the ROM:
0 => 4 1 => 5 2 => 0 3 => 1 4 => 2 5 => 3 6 => 9 7 => 6 8 => 8 9 => 7
This mapping can now be translated to a C routine in an optimized way:
static inline u8 EMUDescrambleData(u8 data) { return ((data & 1) << 6) /* 0 */ | ((data & 2) << 1) /* 1 */ | ((data & 4) >> 2) /* 2 */ | ((data & 8) >> 2) /* 3 */ | ((data & 16) << 3) /* 4 */ | ((data & 32)) /* 5 */ | ((data & 64) >> 3) /* 6 */ | ((data & 128) >> 3); /* 7 */ } static inline u16 EMUScrambleAddr(u16 addr) { return ((addr & 1) << 4) /* 0 */ | ((addr & 2) << 4) /* 1 */ | ((addr & 4) >> 2) /* 2 */ | ((addr & 8) >> 2) /* 3 */ | ((addr & 16) >> 2) /* 4 */ | ((addr & 32) >> 2) /* 5 */ | ((addr & 64) << 3) /* 6 */ | ((addr & 128) >> 1) /* 7 */ | ((addr & 256)) /* 8 */ | ((addr & 512) >> 2); /* 9 */ }
Reading code from ROM is now simple:
u8 data = EMUDescrambleData(bootrom[EMUScrambleAddress(addr)]);
Now we have the readable boot ROM code, but analyzing it is painful, because Z80 code is awful, it is ugly, it is hard to read, and in general we want to avoid looking at it as much as possible.
Emulating the Emulator
It is much easier to just run the Emulator and see what it does. At least if we could just run the Emulator, somehow, without owning an Emulator. But if we cannot run it now, we can of course write our own emulator of the Emulator! All we need is to emulate the digital logic, because who cares about the audio part anyway?
To get started, we have to figure out the I/O address map, since that is how all the peripherals are addressed by the Z80. Reading the original schematics is hard, especially if you want to avoid any errors, but translating the glue logic to Verilog and simulating it is rather easy. The result is this I/O map:
A[7..0]:
00..0F: DMACS0
10..1F: DMACS1
20..2F: DMACS2
30..3F: DMACS3
40..4F: CTCCS
40: CTC CH 0
41: CTC CH 1
42: CTC CH 2
43: CTC CH 3
50..5F: PIOCS
50: PIO A:DATA
51: PIO A:CTL
52: PIO B:DATA
53: PIO B:CTL
60..6F: SIOCS
60: SIO A:DATA
61: SIO A:CTL
62: SIO B:DATA
63: SIO B:CTL
70..7F: DMACS4
80: CH0CSL
81: CH0CSH
82: CH1CSL
83: CH1CSH
84: CH2CSL
85: CH2CSH
86: CH3CSL
87: CH3CSH
88: CH4CSL
89: CH4CSH
8A: CH5CSL
8B: CH5CSH
8C: CH6CSL
8D: CH6CSH
8E: CH7CSL
8F: CH7CSH
C0: LED0CS
C1: LED1CS
C2: RELCS
C3: KBDCS
There is one important difference between output and
input: when reading from peripherals, I/O addresses
80-FF read from
KBDICS which selects the keyboard port.
The meaning of individual bits on many of these ports is as follows:
PIO PORTS => ASTB: ADC READY A[7..0]: ADC INPUT B[0]: ~STEP B[1]: ~DIR B[2]: ~TK00 B[3]: MODLTB B[4]: MODUTB B[5]: CPUA16 B[6]: SIO/~PIO B[7]: PDMA CHnCSH => D[7..5]: VCF CTL (3bit) D[4]: CHnA16 D[3]: GATEn D[2]: ~RSTCHn D[1..0]: TIMER PRESET 9..8 CHnCSL => D[7..0]: TIMER CONFIG 7..0 KBDCS => D[0]: POTSEL D[1]: TRIGPOT D[2]: ~FORC16 D[7..4]: KEYBOARD
One particular annoyance of the Emulator is the fact
that the Z80 code implements a custom floppy disk
controller which directly talks to the FDD via the SIO
chip. It is therefore necessary to emulate the FDD on a
very low level, with sufficient accuracy that the Z80
code gets the correct data. The other annoyance is the
CPUA16 bit. Remember the Emulator has
128 kB RAM, although it is an 8bit system, which can
only address 64 kB of RAM? The A16 address
bit is used to force access to the upper 64 kB of RAM.
If this logic is broken in some way, the system will
never boot properly. This bit is controlled by multiple
signals, including the CPUA16 signal as
well as the nFORC16 signal. But since code
would immediately stop working if there were no special
precautions, the A16 stays 0
if the address is within the boot ROM or OS code. The
easiest way to get this working is by exactly
re-implementing the relevant glue logic.
Once the Z80, PIO, SIO, CTC, DMA chips, and the FDD are implemented with sufficient accuracy, the boot ROM code finally boots, loads the first track of the OS code from the floppy, and starts executing it. The OS code loads the remaining track of the OS code and then loads the sound data into RAM. Eventually it waits for keyboard input. Now we are almost at the goal: we can finally watch the firmware do its thing.
The implementation of the virtual Emulator is available on GitHub at https://github.com/unknown-technologies/emulator
The Floppy Disk Drive
The Emulator's firmware directly controls the floppy disk drive, there is no separate FDD controller involved. As a result, our virtual Emulator has to implement a virtual FDD at a rather low level. But how does an FDD work?
An FDD is rather simple: it has a motor that spins the
disk at 300RPM as long as the MTR line is
active. The disk has a mark called the “index” hole
which marks the start of a track and whenever this
index hole passes over a sensor, a short “index pulse”
is generated on the INDEX line. This line
is connected to the DCD input of the SIO
which can generate an interrupt in the SIO. The Z80 code
programs the SIO to generate an interrupt whenever
DCD changes, which causes execution of a
subroutine whenever the index pulse is received.
The timing of these index pulses has to be roughly correct, therefore the emulation has to count Z80 clock cycles and trigger the interrupt at the right time if the FDD's motor is enabled.
The Emulator firmware also checks the time between index pulses, apparently as some kind of self test. This timing is checked via the CTC which therefore also has to run at a roughly correct timing.
In addition to the motor which turns the disk and the
index signal, there are also three more signals:
TRK00 which indicates that the head is
positioned over track 0, STEP which moves
the head by one track whenever a pulse is received on
this line, and DIR which selects the
direction in which the head should move with every step
pulse.
Data recorded on a floppy is roughly like storing the signal from a UART, except it is first encoded to a modified version of FM called “MFM”. In the Emulator there is some logic attached to the SIO to encode / decode the UART signal to MFM which is then stored on the floppy. Therefore, data written to the SIO is sent to the FDD and data read from the floppy is received by the SIO. We can completely ignore this for our virtual Emulator, because the Z80 only interacts with the SIO but never with the MFM encoded signal directly.
Of course a track on the floppy contains more than just the data itself that has to be stored; it also contains additional synchronization and metadata. This is important for our virtual Emulator, since we have to send the correct data to the SIO. The SIO also has some extra features like automatic CRC checking and CRC generation as well as automatic start mark detection. In our case we can completely ignore this, since CRC and start marks are completely handled by the SIO, and we never have to send this data to the Z80.
The only thing we have to care about here is that every track has a first data section which stores the track number and a second section which consists of 3584 bytes of data. In our virtual FDD we can just insert the current track in the first section and send the data from the floppy image in the second section.
Debugging with TRCView
Everyone who ever developed an interpreter or emulator knows that debugging such a piece of software is not so easy. Luckily there is a very potent tool which can be used both for debugging the emulator and for analyzing software running within an emulator: TRCView.
To use TRCView, the emulator has to record an execution trace which is essentially a machine-readable log file of everything that happened in the emulator, including all executed machine instructions, all memory accesses, and so on. It is rather easy to extend our virtual Emulator to record such an execution trace.
Once we can record execution traces, we can run the emulator for a few moments and load the recorded execution trace into TRCView. In TRCView we can then look at everything that happened, roughly comparable to a powerful debugger. The main difference between TRCView and a debugger is that the program finished execution already, and we can therefore “look into the future” and also “go back in time”, e.g., to see where a certain value came from and where it is used next. This is very useful to find errors in the emulator itself as well as to figure out what the emulated software expects at a certain point in time. In particular, this tool was very useful to figure out what the SIO chip has to return for the data read from the floppy disk.
The relevant code to record an execution trace is in the
file trace.c
in the virtual Emulator.
Whenever the boot ROM code waits for data to be transferred from the floppy disk, it waits in a busy wait loop. Of course we do not want to have a large amount of essentially NOPs in our execution trace. To avoid this, we disable tracing whenever we detect this wait loop. Once the Z80 receives an interrupt, we enable tracing again. As a result, we simply skip all the uninteresting jumps but still get everything relevant that happened.
Analyzing the Firmware
Now that the firmware correctly boots from floppy, we can finally have a close look at the code responsible for interpreting the sample metadata. To analyze this, we have to virtually press a key. We have no idea how keys are encoded though, so we have to figure this out first.
To figure out the mapping of keys, we have to remember
that the Emulator has LEDs for various operations as
well as audio voices for sound output. We can log
whenever the LEDs change and whenever a voice gets
configured. Then we can simply use a shell script to
automatically figure out which key means what. We start
by pressing the first key, which allocates a voice. Now
we see that voice allocation happens in a subroutine at
address 1167. We can now add some extra
logging to print whenever this subroutine is executed.
The following shell script iterates through all key presses and prints what happened as a result:
floppy="fdd/#17 Male Voices - Mixed Choir.emufd" for i in `seq 0 71`; do result=$(timeout 5 ./emulator -k$i -e "$floppy" | grep 'alloc_voice\|LEDs:' | tail -n 1) echo "$i => $result" done
We get the following result:
0 => alloc_voice(7) 1 => alloc_voice(6) 2 => alloc_voice(5) 3 => alloc_voice(4) 4 => alloc_voice(3) 5 => alloc_voice(2) 6 => alloc_voice(1) 7 => alloc_voice(0) 8 => alloc_voice(15) 9 => alloc_voice(14) 10 => alloc_voice(13) 11 => alloc_voice(12) 12 => alloc_voice(11) 13 => alloc_voice(10) 14 => alloc_voice(9) 15 => alloc_voice(8) 16 => alloc_voice(23) 17 => alloc_voice(22) 18 => alloc_voice(21) 19 => alloc_voice(20) 20 => alloc_voice(19) 21 => alloc_voice(18) 22 => alloc_voice(17) 23 => alloc_voice(16) 24 => alloc_voice(31) 25 => alloc_voice(30) 26 => alloc_voice(29) 27 => alloc_voice(28) 28 => alloc_voice(27) 29 => alloc_voice(26) 30 => alloc_voice(25) 31 => alloc_voice(24) 32 => alloc_voice(39) 33 => alloc_voice(38) 34 => alloc_voice(37) 35 => alloc_voice(36) 36 => alloc_voice(35) 37 => alloc_voice(34) 38 => alloc_voice(33) 39 => alloc_voice(32) 40 => alloc_voice(47) 41 => alloc_voice(46) 42 => alloc_voice(45) 43 => alloc_voice(44) 44 => alloc_voice(43) 45 => alloc_voice(42) 46 => alloc_voice(41) 47 => alloc_voice(40) 48 => LEDs: 49 => LEDs: 50 => LEDs: A 51 => LEDs: 52 => LEDs: GET_SEQ 53 => LEDs: 54 => LEDs: 55 => alloc_voice(48) 56 => LEDs: SUS_LWR 57 => LEDs: 58 => LEDs: SUS_UPR 59 => LEDs: 60 => LEDs: T/F 61 => LEDs: 62 => LEDs: 63 => LEDs: 64 => LEDs: GET_UPR 65 => LEDs: GET_LWR 66 => LEDs: SWAP 67 => LEDs: PUT 68 => LEDs: MOD_LWR 69 => LEDs: DYN 70 => LEDs: 71 => LEDs: MOD_UPR
Now we know that keys 0 to 47
as well as key 55 correspond to keys on the
keyboard while the rest corresponds to control keys. The
mapping between keys and allocated voices is slightly
strange, but after thinking about it for a minute we can
see that this is how the mapping works:
int key = midi_key ^ 7;
Now we can use this encoding to automatically test how voices are allocated. In particular, we want to know the frequencies and sample addresses.
Every voice uses two DMA channels: in the first phase the first DMA channel is programmed to play back the intro part of a sample and the second DMA channel is programmed to play back the loop part. Once the intro part finishes playback, the loop part is automatically triggered and continues playback. This channel automatically reloads, therefore no interaction from the CPU is necessary for playback after the voice is programmed.
The DMA channels are triggered by a timer, which initiates the transfer of a single sample data byte to the DAC. The timer is a simple up counter with automatic reload. Whenever the counter overflows, it triggers the DMA transfer.
Since the timer is driven by an 11.55MHz clock (this frequency is hard to find in the service manual, but it is mentioned somewhere in the text), we can now compute the playback sample rate:
double freq = 11.55e6 / (0x1000 - (0xC00 | timer));
The C00 is the hard-coded value of the
upper bits of the time constant, 1000 is
the overflow value.
Now the most interesting question is what is the tuning of this sample? We have to compute it. First we need the playback rate, which gives us the ratio how much the sample is transposed.
double playback = freq / 27778.0;
Now we have to know what the expected sound frequency for the pressed key is. We can use the following functions to convert a MIDI key to a frequency and vice versa using standard formulas:
static inline double midi_to_freq(double key) { return 440.0 * pow(2.0, (key - 69.0) / 12.0); } static inline double freq_to_midi(double freq) { return 69.0 + (12.0 * (log(freq / 440.0) / log(2.0))); }
With these two functions we can finally compute the root key of the sample:
double ref = midi_to_freq(midi + 24); double act = ref / playback; double root = freq_to_midi(act) - 24; int rootkey = round(root); double tuning = rootkey - root;
Of course now we have to think about if
tuning is really what we want.
What we computed is the root key and how much higher /
lower the sample is actually tuned. But most of the time
this is not what we want. Instead, we usually want to
know how much we have to tune the sample to precisely
get the root key. Therefore, we have to invert the sign
to get a more useful value:
double tuning = root - rootkey;
We can now print this extra information whenever a voice is programmed and then use a short shell script to figure out what the Emulator does for every key:
floppy="fdd/#17 Male Voices - Mixed Choir.emufd" for i in `seq 0 48`; do result=$(./emulator -m$i -e "$floppy" | grep CH.: | tail -n 1) printf "%02d => %s\n" $i "$result" done
We get the following table:
00 => CH4: TIMER=19F [18965.52Hz] RST=0 GATE=1 CHnA16=0 FC=3 ADDR=84FC:1DAA,A2A7:45FC => RATE=0.6828 ROOT=07 [G 0] [REF= 32.70Hz,ACT= 47.90Hz,ROOT= 6.61] 01 => CH4: TIMER=1C1 [20086.96Hz] CHnA16=0 FC=3 ADDR=84FC:1DAA,A2A7:45FC => RATE=0.7231 ROOT=07 [G 0] [REF= 34.65Hz,ACT= 47.91Hz,ROOT= 6.61] 02 => CH4: TIMER=1E1 [21270.72Hz] CHnA16=0 FC=3 ADDR=84FC:1DAA,A2A7:45FC => RATE=0.7657 ROOT=07 [G 0] [REF= 36.71Hz,ACT= 47.94Hz,ROOT= 6.62] 03 => CH4: TIMER=1FF [22514.62Hz] CHnA16=0 FC=3 ADDR=84FC:1DAA,A2A7:45FC => RATE=0.8105 ROOT=07 [G 0] [REF= 38.89Hz,ACT= 47.98Hz,ROOT= 6.64] 04 => CH4: TIMER=21C [23863.64Hz] CHnA16=0 FC=4 ADDR=84FC:1DAA,A2A7:45FC => RATE=0.8591 ROOT=07 [G 0] [REF= 41.20Hz,ACT= 47.96Hz,ROOT= 6.63] 05 => CH4: TIMER=237 [25273.52Hz] CHnA16=0 FC=4 ADDR=84FC:1DAA,A2A7:45FC => RATE=0.9098 ROOT=07 [G 0] [REF= 43.65Hz,ACT= 47.98Hz,ROOT= 6.64] 06 => CH4: TIMER=251 [26798.14Hz] CHnA16=0 FC=4 ADDR=84FC:1DAA,A2A7:45FC => RATE=0.9647 ROOT=07 [G 0] [REF= 46.25Hz,ACT= 47.94Hz,ROOT= 6.62] 07 => CH4: TIMER=269 [28378.38Hz] CHnA16=0 FC=4 ADDR=84FC:1DAA,A2A7:45FC => RATE=1.0216 ROOT=07 [G 0] [REF= 49.00Hz,ACT= 47.96Hz,ROOT= 6.63] 08 => CH4: TIMER=280 [30078.12Hz] CHnA16=0 FC=5 ADDR=84FC:1DAA,A2A7:45FC => RATE=1.0828 ROOT=07 [G 0] [REF= 51.91Hz,ACT= 47.94Hz,ROOT= 6.62] 09 => CH4: TIMER=296 [31906.08Hz] CHnA16=0 FC=5 ADDR=84FC:1DAA,A2A7:45FC => RATE=1.1486 ROOT=07 [G 0] [REF= 55.00Hz,ACT= 47.88Hz,ROOT= 6.60] 10 => CH4: TIMER=2AA [33771.93Hz] CHnA16=0 FC=5 ADDR=84FC:1DAA,A2A7:45FC => RATE=1.2158 ROOT=07 [G 0] [REF= 58.27Hz,ACT= 47.93Hz,ROOT= 6.62] 11 => CH4: TIMER=2BD [35758.51Hz] CHnA16=0 FC=5 ADDR=84FC:1DAA,A2A7:45FC => RATE=1.2873 ROOT=07 [G 0] [REF= 61.74Hz,ACT= 47.96Hz,ROOT= 6.63] 12 => CH4: TIMER=1A0 [18996.71Hz] CHnA16=0 FC=3 ADDR=2100:124C,334D:4256 => RATE=0.6839 ROOT=13 [G 1] [REF= 65.41Hz,ACT= 95.64Hz,ROOT=18.58] 13 => CH4: TIMER=1C2 [20121.95Hz] CHnA16=0 FC=3 ADDR=2100:124C,334D:4256 => RATE=0.7244 ROOT=13 [G 1] [REF= 69.30Hz,ACT= 95.66Hz,ROOT=18.58] 14 => CH4: TIMER=1E2 [21309.96Hz] CHnA16=0 FC=3 ADDR=2100:124C,334D:4256 => RATE=0.7672 ROOT=13 [G 1] [REF= 73.42Hz,ACT= 95.70Hz,ROOT=18.59] 15 => CH4: TIMER=200 [22558.59Hz] CHnA16=0 FC=3 ADDR=2100:124C,334D:4256 => RATE=0.8121 ROOT=13 [G 1] [REF= 77.78Hz,ACT= 95.78Hz,ROOT=18.60] 16 => CH4: TIMER=21D [23913.04Hz] CHnA16=0 FC=4 ADDR=2100:124C,334D:4256 => RATE=0.8609 ROOT=13 [G 1] [REF= 82.41Hz,ACT= 95.73Hz,ROOT=18.59] 17 => CH4: TIMER=238 [25328.95Hz] CHnA16=0 FC=4 ADDR=2100:124C,334D:4256 => RATE=0.9118 ROOT=13 [G 1] [REF= 87.31Hz,ACT= 95.75Hz,ROOT=18.60] 18 => CH4: TIMER=252 [26860.47Hz] CHnA16=0 FC=4 ADDR=2100:124C,334D:4256 => RATE=0.9670 ROOT=13 [G 1] [REF= 92.50Hz,ACT= 95.66Hz,ROOT=18.58] 19 => CH4: TIMER=26A [28448.28Hz] CHnA16=0 FC=4 ADDR=2100:124C,334D:4256 => RATE=1.0241 ROOT=13 [G 1] [REF= 98.00Hz,ACT= 95.69Hz,ROOT=18.59] 20 => CH4: TIMER=281 [30156.66Hz] CHnA16=0 FC=5 ADDR=2100:124C,334D:4256 => RATE=1.0856 ROOT=13 [G 1] [REF=103.83Hz,ACT= 95.64Hz,ROOT=18.58] 21 => CH4: TIMER=296 [31906.08Hz] CHnA16=0 FC=5 ADDR=2100:124C,334D:4256 => RATE=1.1486 ROOT=13 [G 1] [REF=110.00Hz,ACT= 95.77Hz,ROOT=18.60] 22 => CH4: TIMER=2AB [33870.97Hz] CHnA16=0 FC=5 ADDR=2100:124C,334D:4256 => RATE=1.2193 ROOT=13 [G 1] [REF=116.54Hz,ACT= 95.58Hz,ROOT=18.57] 23 => CH4: TIMER=2BE [35869.57Hz] CHnA16=0 FC=5 ADDR=2100:124C,334D:4256 => RATE=1.2913 ROOT=13 [G 1] [REF=123.47Hz,ACT= 95.62Hz,ROOT=18.57] 24 => CH7: TIMER=09C [13306.45Hz] CHnA16=1 FC=1 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.4790 ROOT=25 [C#3] [REF=130.81Hz,ACT=273.08Hz,ROOT=36.74] 25 => CH7: TIMER=0CC [14085.37Hz] CHnA16=1 FC=1 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.5071 ROOT=25 [C#3] [REF=138.59Hz,ACT=273.32Hz,ROOT=36.76] 26 => CH7: TIMER=0FA [14922.48Hz] CHnA16=1 FC=1 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.5372 ROOT=25 [C#3] [REF=146.83Hz,ACT=273.33Hz,ROOT=36.76] 27 => CH7: TIMER=126 [15821.92Hz] CHnA16=1 FC=1 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.5696 ROOT=25 [C#3] [REF=155.56Hz,ACT=273.12Hz,ROOT=36.74] 28 => CH7: TIMER=14F [16763.43Hz] CHnA16=1 FC=2 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.6035 ROOT=25 [C#3] [REF=164.81Hz,ACT=273.11Hz,ROOT=36.74] 29 => CH7: TIMER=175 [17741.94Hz] CHnA16=1 FC=2 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.6387 ROOT=25 [C#3] [REF=174.61Hz,ACT=273.39Hz,ROOT=36.76] 30 => CH7: TIMER=19A [18811.07Hz] CHnA16=1 FC=2 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.6772 ROOT=25 [C#3] [REF=185.00Hz,ACT=273.18Hz,ROOT=36.75] 31 => CH7: TIMER=1BC [19913.79Hz] CHnA16=1 FC=2 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.7169 ROOT=25 [C#3] [REF=196.00Hz,ACT=273.40Hz,ROOT=36.76] 32 => CH7: TIMER=1DD [21115.17Hz] CHnA16=1 FC=3 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.7601 ROOT=25 [C#3] [REF=207.65Hz,ACT=273.18Hz,ROOT=36.75] 33 => CH7: TIMER=1FC [22383.72Hz] CHnA16=1 FC=3 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.8058 ROOT=25 [C#3] [REF=220.00Hz,ACT=273.02Hz,ROOT=36.74] 34 => CH7: TIMER=219 [23716.63Hz] CHnA16=1 FC=3 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.8538 ROOT=25 [C#3] [REF=233.08Hz,ACT=273.00Hz,ROOT=36.74] 35 => CH7: TIMER=234 [25108.70Hz] CHnA16=1 FC=3 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.9039 ROOT=25 [C#3] [REF=246.94Hz,ACT=273.19Hz,ROOT=36.75] 36 => CH7: TIMER=24E [26612.90Hz] CHnA16=1 FC=4 ADDR=2100:1AEB,3BEC:B7C4 => RATE=0.9581 ROOT=25 [C#3] [REF=261.63Hz,ACT=273.08Hz,ROOT=36.74] 37 => CH7: TIMER=266 [28170.73Hz] CHnA16=1 FC=4 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.0141 ROOT=25 [C#3] [REF=277.18Hz,ACT=273.32Hz,ROOT=36.76] 38 => CH7: TIMER=27D [29844.96Hz] CHnA16=1 FC=4 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.0744 ROOT=25 [C#3] [REF=293.66Hz,ACT=273.33Hz,ROOT=36.76] 39 => CH7: TIMER=293 [31643.84Hz] CHnA16=1 FC=4 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.1392 ROOT=25 [C#3] [REF=311.13Hz,ACT=273.12Hz,ROOT=36.74] 40 => CH7: TIMER=2A8 [33575.58Hz] CHnA16=1 FC=5 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.2087 ROOT=25 [C#3] [REF=329.63Hz,ACT=272.71Hz,ROOT=36.72] 41 => CH7: TIMER=2BB [35538.46Hz] CHnA16=1 FC=5 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.2794 ROOT=25 [C#3] [REF=349.23Hz,ACT=272.97Hz,ROOT=36.73] 42 => CH7: TIMER=2CD [37622.15Hz] CHnA16=1 FC=5 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.3544 ROOT=25 [C#3] [REF=369.99Hz,ACT=273.18Hz,ROOT=36.75] 43 => CH7: TIMER=2DE [39827.59Hz] CHnA16=1 FC=5 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.4338 ROOT=25 [C#3] [REF=392.00Hz,ACT=273.40Hz,ROOT=36.76] 44 => CH7: TIMER=2EF [42307.69Hz] CHnA16=1 FC=6 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.5231 ROOT=25 [C#3] [REF=415.30Hz,ACT=272.68Hz,ROOT=36.72] 45 => CH7: TIMER=2FE [44767.44Hz] CHnA16=1 FC=6 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.6116 ROOT=25 [C#3] [REF=440.00Hz,ACT=273.02Hz,ROOT=36.74] 46 => CH7: TIMER=30D [47530.86Hz] CHnA16=1 FC=6 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.7111 ROOT=25 [C#3] [REF=466.16Hz,ACT=272.44Hz,ROOT=36.70] 47 => CH7: TIMER=31A [50217.39Hz] CHnA16=1 FC=6 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.8078 ROOT=25 [C#3] [REF=493.88Hz,ACT=273.19Hz,ROOT=36.75] 48 => CH7: TIMER=327 [53225.81Hz] CHnA16=1 FC=6 ADDR=2100:1AEB,3BEC:B7C4 => RATE=1.9161 ROOT=25 [C#3] [REF=523.25Hz,ACT=273.08Hz,ROOT=36.74]
Now we know exactly how the Emulator decodes the samples on this particular floppy. But we want to know how to do this ourselves, without running a virtual Emulator. To figure this out, we press a random key and record an execution trace:
./emulator -m15 -ttrace.trc -e fdd/\#17\ Male\ Voices\ -\ Mixed\ Choir.emufd
When we look at the execution trace, we only really care
about what happens in the subroutine at
1167 which we call
alloc_voice. We can see accesses to memory
at address 2000-2100 which is
clearly the metadata area on this particular floppy.
The code copies the DMA configuration from the multisample to a temporary location and then programs the DMA channels. Part of this can be seen in the following screenshot:
After looking around this subroutine for a while, we can define data structures for the sample metadata:
The most intriguing part is how the timer is programmed.
This is where the tuning is relevant: it
points to a table with the pre-computed time constants.
But we can clearly see that the values are bigger than a
time constant can possibly be. Turns out the extra bits
are used to adjust the VCF cutoff which acts as an
interpolation filter.
We are almost done now: we can compute the root keys, we can figure out the offsets for the sample data, we can also figure out the loop point and a cutoff. One thing that is still missing is some detail about banks: there are two different types of banks.
What we looked at so far is a multisample bank.
The Emulator also supports banks which only contain a
single sample and lack all the fancy tuning. Such a
basic bank essentially has the data structure we already
know: it is the part where the metadata gets copied to
in the alloc_voice subroutine. To detect a
multisample bank, a bit in the flags
variable is set: if flags & 10 is
non-zero, it is a multisample bank. Otherwise, it is a
basic bank.
What we also forgot until now: how many keys belong to a
sample in a multisample bank? The emulator uses fixed
key zones which can be seen in the
user manual.
It also seems like address 2020 stores the
number of keys per sample, for all samples in the bank.
Companding DAC
Now that we have the raw sound data, how do we decode it? The Emulator uses 8bit data with μ-law compression. The precise function to decode this can be found in the datasheet of the 6072 DAC chip. Funnily enough, the fact that a 6072 DAC is used is well hidden in the service manual and only mentioned somewhere in the text about which parts can fail. The decoding function can be translated to the following C code:
s16 decode6072(s8 val) {
int sign = val < 0;
int abs = val & 0x7F;
int c = abs >> 4;
int s = val & 0x0F;
int sgn = sign ? -1 : 1;
return (s16) (sgn * ((1 << c) * (2 * s + 33) - 33));
}
With this decoding function, we get values up to 8031, exactly according to the table in the datasheet. To get the full range of 16bit, we have to multiply the result by 4. With that we get an absolutely perfect decoding of the sample data. Only the analog reconstruction filter is missing of course, but this is something a sampler has to implement if we want to use the decoded samples.
Conclusion
We figured out how the E-MU Emulator really works. We watched the firmware do its thing and derived how the data on the floppy is structured. We even implemented our own virtual Emulator, so we can really see what happens, without relying on guesses and assumptions.
There is one remaining feature of the Emulator we completely ignored: the sequencer. But since the virtual Emulator is on GitHub, maybe you can figure out how that works?