With all those informations, I knew it wasn't enough just to know what the contents of the ROMs were, I also had to simulate the logic behavior ot them.

Knowing that the frequencies won't exceed 160kHz, I decided to do my first attempt with a ATTiny2313 and its internal flash. I used a FTDI USB to RS232 TTL cable to debug and first try to retrieve address sets. I didn't do any clean voltage adaptation on the inputs, knowing they had clamp diodes I just dropped some resistors in series on the AVR's pins.

First, I didn't pay attention to the asynchronous story with M0, so I connected ROMCLK to the INT0 pin to get an interrupt on its falling edge. Unfortunately, for some reason, the interrupt was triggered after a variable delay and I couldn't get valid address readings every time.

I then chose to simply ignore ROMCLK and used the Pin Change Interrupt to catch the rising edges of M0 and M1. I managed to get a valid addresses at this level (0x800C when I pressed the "Module select" button, the microcontroller was trying to read the magic bytes).

After this encouraging result, I got the AVR to answer the magic bytes back (0xAAAA) on ADD8. After adding the code to ignore the dummy read, I just used the DDRB register to set ADD8 as an output on the rising edge of M0 (first mistake). It worked about once every 5 tries.

I first thought it was a voltage problem, because the AVR could only answer at 0 or 5V (actually 0.3V and 6V because ADD8 is pulled up by the S&S). The low level is 0.3V instead of -3.5V, so that could have been a problem. I splitted the line ADD8 to go as an input to the AVR, and to a NPN transistor drived by the AVR to make an open collector output.

Unfortunately, even with a low level at -3V, the S&S wasn't always recognizing the AVR.Looking more closely at the scope, I realized that the AVR answered was after a variable delay, like with the triggering of INT0. To make the AVR more reactive, I reorganized the code to make a kind of "prefetch" for each bit to save a few microseconds, with success! Thus, the dummy read finally was used, allowing the code to load the first bit and the following ones after each read (instead of before).

With the same code simulating the ROM, I was able to load the correct spelling of a word and thus confirm a part of the memory map.

Here is a copy of the AVRStudio project and the C source at this point.

Until now, I used the internal flash of the AVR via the C function "pgm_read_byte". Wanting to test the reading of voice data, I needed a few kilobytes (more than the 1kB remaining on Tiny2313, which has 2), so I took the only serial memory chip I had, a 24AA256 i2c EEPROM.

After having spent a bit of time writing big-bang functions to talk to the EEPROM, I had the S&S recognize the data coming from it. The audio was still giving anything, though. Knowing that the reading by the microcontroller was working, the problem was only with the synthesizer accesses.

I realized that the S&S's microcontroller always read in groups of 4 bits, spaced by several microseconds. This actually allowed my code to have the time to read bytes out of the EEPROM. By cons, when the synthesizer began to speak, he read the bits in blocks of different sizes, at double the speed. Remember the LPC frames ? There are 4 bits of energy, 1 for repeat, 5 for pitch...

Let's suppose that the synthesizer wants to read the first frame (which is not silent):
The first 4+1 bits are good because they were all part of the same byte loaded during dummy read. But when the next block of 5 bits are read, my code has no time to read the new byte from the EEPROM and inevitably, the synthesizer receives bad data.

I quickly remembered that i2c didn't allow speeds exceeding 400kHz, so it was impossible to read data on time, even with larger prefetch. Having already spent several hours on the first try and with no SPI EEPROM on hand, I thought the project was going to stop there.

But it was without counting on a gift [Grapsus] sent me a few days ago, which was just next to me !...