Emu XL-7 & MP-7 User's Group

'Jon Carroll' joncarroll@... [xl7]

14 Jul 2014 10:11

�

really don't need RAM for 'fast access' to the samples considering the speed
of the ROM involved. Flash memory i s going to end up being much faster than
the original ROMs.

here's a picture of an original 32 MB flash ROM:

http://www.theavenuesinstruments.com/i/Sampler/EmuFlash32_640.jpg

the Flash chips on it are Intel e28f640
datasheet here:
http://www.ic-on-line.cn/view_download.php?id=1511688&file=0257\ge28f640j3_164745.pdf

125 ns initial access speed
25 ns page reads

most papaers on using it refer to it as 120 ns speed. that is about 8 Mhz.

SD is 208 Mhz. I really don't see how there will be a speed problem that
will require yet another memory controller and interface on the card.

Andre Lewis bassmeister3000@yahoo.com [xl7]

14 Jul 2014 09:45

�

I tend to believe that it's worth the effort to make it dynamic.  A static rom would mean having �a hardware burner to create it.  If we have �a solid plan I think it's doable.

Hardware, I think we should be using an atmel AVR chip, they are small low powered and fast enough to pump everything through. �They also can deal with SD cards easily, and possibly USB.

We also need some RAM on board for fast access to the samples. �;I think 64mb is the largest sized rom? �Or is it 128mb? �a four layer card, some resister packs. �

Is there a crystal on the expansion cards or is it clocked by the EMU?

Are there any standard IC's on the ROMs or are they all proprietary EMU?

From the software side of things we need to reverse engineer some of the actual stored formats, like patches, beats, and riffs. �We should be able to deliver these directly from our shared bus as well.

We can get some of this from the initial power on of the device, I have a 2gs rigol which should be able to get the initial boot sequence. �

We might also have to report a proxy sample set to the EMU so we have time to load up the samples into RAM. �New sd cards seem to be able to dump across a lot of info quickly, so we could also cheap out and play directly from the sdcard, though I don't think this is a good idea.

We may need an app to package these on the host side, doing things like mapping patches to samples, or ensuring samples get loaded in a specific order.

I like your idea about cheap PWM, it's actually a fun idea. �I was also thinking in terms of wavetable sweeps as well. �I guess we could use velocity as the key to trigger it, since most of the real processing happens after the ROM has dumped it's samples.

We should put together a google doc to start tracking this stuff.

On Sunday, July 13, 2014 5:39 AM, "janoch23@... [xl7]" wrote:

�

Don't get me wrong, I'd love dynamic sample loading. I was just saying that if it makes things less likely to happen at all than a regular flash rom, I'd prefer the latter. Otoh, if there is a bigger interest in a dynamic ram solution, then that would be more likely to happen.

In fact, if there's another CPU on the ROM module controlling RAM emulating flash rom, why not make it truly dynamic and modify the bytes on the fly for true PWM waves and supersaw :-) Seriously, naive rectangular PWM shouldn't be too impossible... Let's replace all the RAM chips with GHz FPGAs! :-o (no, please don't)

janoch23@... [xl7]

13 Jul 2014 14:39

�

Don't get me wrong, I'd love dynamic sample loading. I was just saying that if it makes things less likely to happen at all than a regular flash rom, I'd prefer the latter. Otoh, if there is a bigger interest in a dynamic ram solution, then that would be more likely to happen.

In fact, if there's another CPU on the ROM module controlling RAM emulating flash rom, why not make it truly dynamic and modify the bytes on the fly for true PWM waves and supersaw :-) Seriously, naive rectangular PWM shouldn't be too impossible... Let's replace all the RAM chips with GHz FPGAs! :-o (no, please don't)

Andre Lewis bassmeister3000@... [xl7]

13 Jul 2014 10:26

�

I don't think a dynamically loaded sample set is any different than a rom based set, other than that you wouldn't need to keep an E5000 around to load samples. �Every part of the sound engine is sample based, so I can see being able to load samples dynamically as a welcome addition, if for not other reason that with a minor case modification I would never need to open my XL7 again to add samples. �We could also do some tricks to allow patches to address more samples than the 8mb by paging, dynamically changing address pointers to sounds.

A lot of the atmel chips can be clocked up to 100mhz, so I think we can respond quickly enough if we load things up in local ram and add some caching. �

Are the roms the same for all 2500 variants? I would feel better about hacking apart one of the XL1's etc than a command station.

The other things on the emulated chips would be patches, beats and demo riffs.

Did any of the other sampler ranges include chip burners as standard or are they all 'Optional'?

Andre