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

OK... confusion.


The SIMM needs to have FLASH. There really isn't a better way to provide sufficient memory space for a full 32MB SIMM with anything else, unless you have a special project that doesn't need 32MB (eg, live feed sound).

The question is how you reprogram the FLASH - typically a microcontroller would be used (because the need to have an separate Ultra sampler and swap SIMMs between modules is a pain). If the microcontroller has a USB interface then you could transfer an image via USB. If it has an SD card (spi) interface then you could get it to transfer an image from the SD card. To make it useful you need to have some way of getting it to make the change when you want it - not at other times (making a change when you an SD card is present on power up is possible but requires access to the SD card slot whereas a USB interface could be available at any time). After you reprogram the SIMM the system needs to be powered off because the operating system ONLY READS THE CONTENTS OF PRESET MEMORY AT POWER UP - this is to avoid bus contention when sounds are being played back.

To allow the micro to program the FLASH you need to be able to block the address lines so that the P2K module is not causing contention on the address pins - since you also need to have some logic on the board to decode the signals then it makes sense to use a logic device for the buffering. If you do this then you can have the logic device do some special things on the same SIMM - like recognise multiple SIMM slots for the one device (ie up to 128MB of wave data), or recognise certain addresses for special functions [like telling the micro which SD card image to program, or provide 'live' modified sounds - such as from the micro via USB or SD card --> but these sounds are limited in what can be accomplished without changes to the operating system]

To make a SIMM really useful it needs to be used with the module closed. This avoids the problem of damage to the module with it open. having an SD card on a flying lead is just BAD. The best solution would be to have a micro SD card on the SIMM which you can ALSO program (download to) via USB and use special addresses in the SIMM memory map to tell it which image to copy from SD card to FLASH memory. That is one preset would address those memory locations depending on which key was pressed. The output from that preset would be a 'bad' sound if the FLASH write couldn't happen or failed, or a 'happy' sound after a successful transfer of image.

This arrangement should make everyone happy... 



________________________________
 From: "janoch23@yahoo.se [xl7]" <xl7@yahoogroups.com>
To: xl7@yahoogroups.com 
Sent: Thursday, 17 July 2014 6:38 AM
Subject: Re: [xl7] Any interest remaining in a self-programming FLASH SIMM?
 


  
But aren't you talking about using the ARM as a real-time software emulator of the Flash chips? Me thinks it would be very hard to make the ARM work like that, emulating a >10Mhz bus in software, esp. with respects to signal latency, not knowing what the P2k architecture expects. An FPGA maybe, but RAM chips seems like something more likely to work imho. And even if SD cards are spec'ed at 208MHz, isn't that only for burst transfers?


It would seem like a good idea, however, to make the microcontroller accept large SD cards (like 32GB SDHC, or maybe even that is getting old these days), and then add a simple one-button interface (or something) for selecting which 128 MB set of multiple sets stored on the SD is loaded at boot.

But this is assuming there is still hardware development to be done. From what I understand, Jack Pratt already have the design more or less ready for production?

---In xl7@yahoogroups.com, <bassmeister3000@...> wrote :


Exactly.  One ARM chip to deal with the transforms for the data, and loading samples/patches/etc dynamically from SD.  Since there are plenty of ARM libs for dealing with SD, it becomes a matter of getting the right signal to the right pin on the device at the right time.  

The flash on the cards seems to use a 16bit hardware bus, using paging to
get to different parts of the flash memory.  Still a little confusing, so reading through this again.  But it definitely seems there are a lot more pins on the expansion card than there needs to be.  It makes me think that either they break out the flash chips to their own set of pins, or there are a lot of unconnected or ground/vcc pins.  The flash also apparently has it's own processor and command set for reading/writing the chip.  Since it looks like the flash can take either direct pin writes or using the command set, we would need to figure out which one the the expansion is wired for.  

Anyone have an expansion card out that they could take a picture of with a light behind it?  Front and back. Preferably high resolution.  Might not see anything with a four layer card, but might show vias and the traces.

Andre