Yahoo Groups archive

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

Index last updated: 2026-04-29 00:09 UTC

Message

RE: [xl7] FLASH SIMM

2010-01-24 by Beowolf

It sounds like you have been analyzing the advantages of your suggestion for
quite awhile and I would be interested when they are available. Thanks for
your major input to the group.

 

Bruce

 

 

 

From: xl7@yahoogroups.com [mailto:xl7@yahoogroups.com] On Behalf Of Jack
Pratt
Sent: Saturday, January 23, 2010 1:12 PM
To: xl7@yahoogroups.com
Subject: Re: [xl7] FLASH SIMM

 

  

Hi Bob.

 

Essentially the programming board is just an image programmer. Its not a
sampler that allows you to modify anything, but allows you to put an image
(created by something else) into the FLASH SIMM.

 

You'll understand why if I give a little more detail. This SIMM would look
different to the E-MU FLASH SIMMs so that the E-MU hardware that is used to
program the E-MU ones probably wouldn't work. The reason that there is a
modicom of doubt is because the J3 devices used on the E-MU SIMMs and the
M29EWs that I want to use both have a CFI interface. If the E-MU programmers
made use of the CFI interface then it is possible that new ones may be
programmable but I would doubt it.

 

In any case, the existing procedure for E-MU FLASH SIMMs is to take them to
an Ultra sampler and put some waves on them. AFter that you return them to a
proteus module to put presets on them. THe Ultra sampler doesn't know
anything about the preset memory and so is unable to program it. While it is
in the Ultra you can generate some 'Ultra only' presets that can be stored
on the FLASH SIMM, but these are not accessible by the proteus module when
you move the SIMM there. Once in the proteus module, you initially have no
presets, but must create/write them all yourself. [you create them in a user
bank, then copy the entire bank over to the FLASH SIMM]

 

The problem is that the format of the information on the SIMM is unknown (at
this time). E-MU FLASH SIMMs appear like file systems to the Ultra Sampler
but I don't know of that is just a representation of the content. It seems
unlikely that there is in fact a file system on the SIMMs but anything is
possible. The format of the preset infomation is less known. Apart from the
MIDI sysex dumps which indicate the type of preset information on the SIMMs,
the actual layout that the Proteus module need to see to make use of the
SIMM is unknown [to me].

 

There are ways to find out:

  A. get some existing SIMMs and take the FLASH devices off to read them via
a programmer.

  B. make a board that will read their content.

 

Option A is a bit destructive, but could be done. Option B is better because
it would also allow writing once the format is known, so its the better
solution for me [unless lots of people want to donate SIMMs to the cause - I
really don't want to wreck a lot of mine].

 

Knowing what the format looks like could allow the programming board to
modify individual items - but to what end? 

Firstly there's no way to know what effect your changes will have [apart
from purely cosmetic ones like names of items] since you can't play the
waves/presets back. 

Secondly there's the issue of being able to make the changes. Even if you
only want to write to a single byte, you have to keep a copy of the entire
erase block to be able to put the rest back as it was. These FLASH devices
have 128K erase blocks. The write blocks are smaller but when you erase you
need to erase 128K. That might sound like a small amount but very few
microcontrollers have on-chip RAM more than a few kilobytes and even if you
found one with 128K of RAM [there are some of those about] you need more for
programming structures like stack and variables.

 

So its much simpler to just allow an image to be written to the FLASH and
that's that. The image gets generated on a PC with whatever tool gets
created for that purpose, but the programmer doesn't know anything about the
content. And simpler means available much sooner.

 

The solution I had in mind was to have a compact FLASH connector on the
programmer board, and the board copies an image file from the compact FLASH
to the FLASH SIMM. A USB interface would also be provided to allow a PC to
write the contents of the Compact FLASH card. This is a simple solution (is
quicker to implement) -> the programmer board with compact FLASH device
looks like a mass-storage device to the PC, so you can put whatever image
you want onto the compact FLASH (don't need a separate USB-compact FLASH
reader) and then program it. Not having special drivers on the PC is a big
plus!

 

Since the programmer doesn't know anything about content, some PC
application will need to be created to allow the generation of the images.
This is a much more flexible approach, as the functionality of the PC
program can be much more easily modified by anyone who wants to. Part of the
goal here is to know what goes into the image so you could then pack waves
from any source into a wave image. However, then you would have no presets,
so you would need to create them in user banks. To get these into the FLASH
SIMM, you would need to create sysex dumps which would then be packed into
an appropriate preset image and then the wave + preset information
programmed into the FLASH SIMM a second time to free up the user banks (for
the next image). The images would be easy to share.

 

Hope this makes clear what I am proposing.

 

 

 

 

 

 

  _____  

From: Bob S. <tttsystems@...>
To: xl7@yahoogroups.com
Sent: Sat, January 23, 2010 11:11:18 PM
Subject: Re: [xl7] FLASH SIMM

  

Hi Jack

A couple of questions on the proposed programming board.

Is it an external board where you would need to remove the SIMM from the
synth, program it, then return the SIMM? Or would it coexist within the
synth with the SIMM?

What is the proposed PC interface to the programmming board? Would it
include or require software or drivers to communicate to the board from the
PC?

The current flash setup with the Ultra sampler allows the naming of the
sample and the programming of basic non-alterable presets. Is functionality
maintained or is this a more basic version of convert a sample to the right
format and then write that sample in the EEPROM on the SIMM?

Thanks
Bob
El Segundo, CA

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.