The Ultra sampler can write any set of wave forms to the FLASH SIMM - that may or may not be the image of an existing ROM. I understand that the Ultra also writes a dummy set of presets to the PRESET area of the SIMM which are then used for the P2K to know where the wave forms are to make use of them. If you do write a copy of an existing ROM then it would be easy enough to sysex the presets from that ROM to the P2K to load into the FLASH presets. But no such sysex' exist for your custom ROM - you would need to manually generate each one (unless you have software to help.
The beats and riffs and other guff are on the secondary FLASH which also holds the presets.
Because of the configuration/wiring the ID pins hold the same state for each SIMM socket. however the combined state of the three pins can be used to tell when the P2K is talking to a SIMM socket (with the read
signal). Using this means continually sampling the ID pin state to know which bank of 32MB the P2K wants to address allowing ONE SIMM MODULE TO APPEAR AS UP TO FOUR SIMM MODULES AT THE SAME TIME.
Multisamples are automagically handled once the P2K knows that they are there - with each being associated with a specific MIDI note and being played back at normal sampling rate for that note and altered sample rate for adjacent notes. That may or may not create problems for playing sounds back live (what you call dynamically) depending
on the implementation.
!
From: "Andre Lewis bassmeister3000@... [xl7]"
To: "xl7@yahoogroups.com"
Sent: Tuesday, 15 July 2014 9:09 AM
Subject: Re: [xl7] Re: Fwd: [p2k] Any interest remaining in a self-programming FLASH SIMM?
To: "xl7@yahoogroups.com"
Sent: Tuesday, 15 July 2014 9:09 AM
Subject: Re: [xl7] Re: Fwd: [p2k] Any interest remaining in a self-programming FLASH SIMM?
�
Still reading through the datasheet for the flash memory at this point. �Interesting, looks like 1 16 byte bus with a chip select. � Still reading it though.�
I'm not as worried about dynamically
generating waveforms, but it would be interesting. �It would definitely be possible to do sample and glide I would think or noise.
How are multi-samples handled? �I could see just creating a multisample of a square wave and intentionally misusing the velocity to select different duty cycle samples or generating it.�
Jack, I'm curious what you have already. �Is it set up for the EMU devices already? �
I also like the idea of using the pin selects to emulate more than one board at a time, but wouldn't that be a configuration read at boot time rather than for every read?
Are the blank FLASH modules burned by the sampler the same as the actual ROMS used in say the MP-7? �
You are also saying that each module has it's own user writeable flash for the actual programs?
As mentioned before, the beats and riffs are on a separate flash, and not writeable by the Ultra series.
Andre
On Monday, July 14, 2014 3:44 PM, "Jack Pratt woodsworth1@... [xl7]" wrote:
�
[Attachment(s) from Jack Pratt included below]
There seems to be a lot of confusion about how the FLASH works and what is and isn't possible. So here are some thoughts...
A FLASH SIMM only contains WAVE and PRESET data in two separate address spaces. There is also electronics to decode the
addressing pins and to buffer the inputs and outputs (since the P2K electronics is 5V and the FLASH chips are 3V3), but
nothing active.
To the best of my knowledge an Ultra sampler can modify the contents of the WAVE memory and the P2K can modify the contents of the PRESET data. [Whether this is a hardware or a software limitation is not clear] In the WAVE memory there is details about�multiwaveforms (that is where in the
WAVE memory the various components start) which is used by the P2K in generating
presets.
My impression is that people mostly want to do the following things:
1. get access to as many (existing) ROMs as possible
2. compose their own ROMs
3. do sampler sorts of things
The best way to do this (IMO) is to have a micro on
the SIMM that will allow
the FLASH to be 'reprogrammed' via USB. With appropriate software any image (existing or composed) could be transferred to the SIMM.
There are three 'ID' pins on the SIMM connector which determine which SIMM is being addressed. �Because of the P2K hardware implementation it is possible to tell from these three pins which SIMM is being addressed so that a single SIMM could be used to fill an entire 128MB memory space rather than a single 32MB space.
Therefore it seems
appropriate to have a single SIMM with 128MB (WAVE) + 16MB (PRESET) memory that will emulate four SIMMs simultaneously.�In order to do this a logic device would be an appropriate addition to the board to decode the ID pins and perform other functions.
Finally the logic device can be used to provide access to on-the-fly sounds.
However there are plenty of limitations to this.
Firstly a wave from generally consists of a one-time section and a looped section. The one-time section usually corresponds to the attack and decay portions of the envelope and the loop plays for the sustain and release portion. The SIMM doesn't inherently know where in the wave form the P2K is so its hard to modify the sound on the fly and make it sound appropriate.
Secondly if two notes of the
same wave form are played at the same time then the SIMM will be addressed in two different
locations of the wave form so that it is not possible for the SIMM to provide individual wave forms for each note severely limiting the usefulness of sounds modified on-the-fly.
Consequently the most optimal solution for 'on-the-fly' sounds would be to use them in 'drum' presets or �monophonic
ones.
All this is fairly easy to do if you have the time and money. In fact I already have the design for something that would do all this.
!
From: "Bruce
Manning brujerman@... [xl7]"
To: "xl7@yahoogroups.com"
Sent: Monday, 14 July 2014 11:27 PM
Subject: Re: [xl7] Re: Fwd: [p2k] Any interest remaining in a self-programming FLASH SIMM? [1 Attachment]
To: "xl7@yahoogroups.com"
Sent: Monday, 14 July 2014 11:27 PM
Subject: Re: [xl7] Re: Fwd: [p2k] Any interest remaining in a self-programming FLASH SIMM? [1 Attachment]
�
[Attachment(s) from Bruce Manning included below]
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@... [xl7]"
wrote:
�
[Attachment(s) from Carl Lofgren included below]
I'm very much interested
in this project!
/C
/C
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.
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.
�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)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)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
Attachments
- No local attachments were found for this message.