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

This has been discussed before in the group. It would be fantastic to see it completed. Flash is faster.
Looking forward to hearing more about it. 


On Monday, July 14, 2014 5:15 AM, "Carl Lofgren carl_lofgren@...m [xl7]" <xl7@yahoogroups.com> wrote:
 


  
[Attachment(s) from Carl Lofgren included below]
I'm very much interested 
in this project!

/C


'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@... [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@yahoo.se [xl7]" <xl7@yahoogroups.com> 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