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

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.


----- Original Message ----- 
From: "Andre Lewis bassmeister3000@... [xl7]" <xl7@yahoogroups.com>
To: <xl7@yahoogroups.com>
Sent: Monday, July 14, 2014 12:45 AM
Subject: Re: [xl7] Re: Fwd: [p2k] Any interest remaining in a 
self-programming FLASH SIMM?


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]" 
<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)


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com