TK.

What is the type number of the IIC EEPROMs? If they are manufactured by ST, the CS lines (pin 1-3) won't work. AMD EEPROMS: Pin 3 won't work. Only Microchip EEPROMs (24LC512) will allow you to use all chip select lines. So - my assumption is, that you are using ST EEPROMs Best Regards, Thorsten.

This issue totally rankles me - did I already mention, that I love such text adventures? ;) With WinXP you are able to specify the cluster size by using the "format" command in the DOS shell, e.g. [tt]format <device>: /FS:FAT /A:16k[/tt] will lead to a cluster size of 32 sectors (0x20) d: is the <device> ID (e.g. k: for my SD card reader) But there are also dependencies between partition and cluster size, e.g. with a 1 GB partition the minimum cluster size is 16k, otherwise FAT16 (65536) cannot cover all clusters (16k * 512 * 2^16 = 1 GB) You could try this cluster size, but I guess that I won't solve the issue. The traces and variable dump are still consistent. E.g., we can see that the file starts at sector 0x45e 00000000158385 ms | Sysex message: F0 00 00 00 00 00 04 05 0E F7 and that it ends at sector 0x49d 00000000173943 ms | Sysex message: F0 00 00 00 00 00 04 09 0D F7 512 bytes * (0x49d-0x45e+1) = 32768 -> correct Between 0x49d and 0x45e the sector number is continuously incremented -> correct Means: SDCARD_FILE_Seek() always returns the correct sector number in sdcard_file_sector, because this is the value which is dumped by the SysEx string at the end of SDCARD_FILE_Seek() The other variables lead to correct calculations as well (don't want to go too much into detail here...) Between SDCARD_FILE_Seek() and SDCARD_WriteSector() I don't see any modification of the sdcard_file_sector variable in your code -> good By using a different cluster size, you've proven that SDCARD_WriteSector() itself, but also your PROG_SRAM_Read() function is working, otherwise the file would still be corrupted after 2k So, I need some more input. - check the same with a cluster size of 16k (probably this won't lead to new results, data corrupted after 16k?) - check your SDCC version, it should be 2.8.0 (or higher) -> type "sdcc --version" - if this doesn't help, I will send you a routine which dumps the SRAM content + the interesting sectors of your SD card for easier comparison - it should give us the final answer :) Best Regards, Thorsten.

It looks fine - SDCARD_FILE_Seek() goes through the FAT to search for the cluster (smaller strings). The longer strings contain the found sector number in nibble-format - the sector number is increasing, which indicates, that a) the file system isn't fragmented (it doesn't matter anyhow, the algorithm can also work with fragmented partitions), but more important: that the FAT algorithm is working. To doublecheck smaller cluster sizes, I re-partitioned my own SD-Card with gparted, and formatted it with 2k cluster size. I was able to reproduce the bug with the previous sdcard version, and tested the new one - successfully. The sysex_overwrite application modifies .syx files with 64k size correctly. My assumption is, that the filesystem of your card is corrupted due to the experiments with the previous version. Random things can happen if random sectors are written ;) Did you already re-format your sdcard? Best Regards, Thorsten.

There is a second "#if 0" which has to be enabled as well - it tells me the finally found sector (I will check this tomorrow evening) Best Regards, Thorsten.

Now with an alternative format (2 nibble format) and a documentation (-> see README.txt) http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsyx_dump%2F Additional enhancements are not planned from my side. Best Regards, Thorsten.

0x800 means, that the next cluster has to be read in the FAT In order to debug this, I need some more informations: open sdcard_file.inc, search for "#if 0", and replace it by "#if 1". After rebuild and application upload, some SysEx messages should be sent on each file access. Copy&Paste the SysEx strings which are dumped during a write operation Best Regards, Thorsten.

cool! :) Btw.: I never noticed this error, since the low byte of the next variable, which was accidently used as high byte during the operation, is 0x00 with my SDcard, but 0xbe with yours ;) Best Regards, Thorsten.

Ok, I think that I found the issue - expected value was 0x00be, but you got 0xbebe due to a wrong 16bit operation Update is in the repository: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fsdcard%2F (you could also try an update via tortoise, it should work now) Best Regards, Thorsten.

Could you please doublecheck, if this value is correct: _sdcard_file_sector_cl2 0x000a16 BE BE [/code] Best Regards, Thorsten.

My test files are usually bigger than 64k, so that they allocate multiple clusters. With the SRAM read function of MIOS Studio you could dump the sector content which is read (probably starting at 0x100, check the project.map file), and also the sector variables (starting at 0x80, absolute addresses can be found in the .map file as well) The content of following variables would be interesting (please note: check the project.map file for the addresses used by your application!!!) _sdcard_file_mode 0x000080 _sdcard_file_name_ptr 0x000081 _sdcard_file_cluster 0x000084 _sdcard_file_sector 0x000086 _sdcard_file_dir_entry_num 0x00008a _sdcard_file_dir_entry_ptr 0x00008c _sdcard_file_sector0 0x00008f _sdcard_file_sector_fat 0x000091 _sdcard_file_sector_root 0x000093 _sdcard_file_root_sectors 0x000095 _sdcard_file_sector_cl2 0x000096 _sdcard_file_cluster_size 0x000098 _sdcard_file_seek_offset 0x000099 _sdcard_file_seek_cluster 0x00009d The most interesting variable is _sdcard_file_cluster_size, because this one could be different at your side. Also the content of the MBR (sector #0) and the parition boot sector (sector number in _sdcard_file_sector0) could be interesting (if _sdcard_buffer_p0 and ..1 is located at 0x100/0x200, dump 0x100..0x2ff) Best Regards, Thorsten.

Ja - wenn man das Board mit einem 24LC04 EEPROM bestueckt, kann man dem Interface einen eigenen Namen geben. Das EEPROM laesst sich mit dieser Applikation programmieren: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmbhp%2Fmbhp_usb_gm5_eeprom%2F Gegenueber Ploytec habe ich bereits auch schon angeregt, dass der eigene Treiber (ja, er kommt ebenfalls von Ploytec, und er ist leider immer noch nicht fertig) die Moeglichkeit eroeffnen koennte, jedem einzelnen MIDI Input und Output einen eigenen Namen zu geben. Wenn diese Information im EEPROM gespeichert wird, wuerden sie auch noch dann erscheinen, wenn man das Interface an einen anderen Compter anstoepselt. Ob sich das dann auch implementieren laesst, weiss ich nicht. Gruss, Thorsten.

No, I'm thinking about a special requirement for the program you are using to send the dump. EEPROM writes are blocking operations, it has to be ensured that at the time the EEPROM is programmed no additional MIDI data is received. MIOS Studio (and other tools which are interacting with MIDIbox applications, like the MBSID V2 Editor) are waiting for an acknowledge string sent by the core after the EEPROM has been programmed before sending a new SysEx command. You probably already noticed this ("Smart Mode") Alternatively the tool has to wait for a specific time before sending anything else to prevent the MIDI in buffer overrun (e.g. see hints about SysEx transfers with MIDI-Ox at various ucapps pages) You are refering to a state machine handler for SysEx transfers. It is required as well to parse the SysEx stream... However, since I was planning to write a SysEx handler example anyhow, I started with it Code is located here: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsyx_dump%2F The code is a bit more complex than somebody could program a simple handler... the reason is, that I take many error cases into account to improve the robustness. I also consider different use cases (e.g. SysEx handling when MIDI merger is enabled - a different topic, but covered by the example) Normaly you should never receive an error acknowledge, but if somebody owns a bad, unstable MIDI interface, some diagnose messages are always very helpful. It also provides an optional checksum protection (disadvantage: checksum has to be re-calculated when patch is modified manually), and optional BankStick support in patch.c (therefore the abstraction layer) What is missing yet in this example, and what I'm planning to add later: a README.txt which explains the programming model and the different options and a new option which allows to send the EEPROM content nibble-wise, so that all 8 instead only the last 7 bits are transfered. If this code looks too complicated, then just consider again the usage of the generic MIOS download feature ;) (Still don't know, why exactly you are not using it, I especially don't know, what your application is doing exactly) Best Regards, Thorsten.

You could use NTDiskViewer to display the sector contents: http://www.download3000.com/download_48627.html Don't want to say that this tool is good, but it was the first one I found and sufficient for my needs Best Regards, Thorsten.

It was blocked by the firewall of the new server - I fixed this Best Regards, Thorsten.

Really great news, that at least SD card reads are working at your side :) Yes, thats correct. Creating new files would require a more complex FAT16 handling, which would consume much more flash memory. I quickly checked this by turning the sysex_sender into a sysex_overwriter function: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsdcard%2Fsysex_overwriter%2F it works as expected. Possible error at Windows side: you don't eject the device (right-click on device, "Auswerfen"), so that your PC reads the old content from cache Possible error at application side: it is not allowed to increment sdcard_file_sector, instead it has to be determined by the SDCARD_FILE_Seek(offset) function for the case that your FAT is fragmented. Hopefully yes! Good to know, that 4GB cards can be used this way. ;-) Best Regards, Thorsten.

You wouldn't notice such issues if you would setup your project properly. It's also hard to help you if you are starting to modify modules by hand, or if you are using expired packages from different releases. Therefore I recomment you: 1) use the most current mios_base package or use SVN, both contain the latest releases - especially of j5_io and hw_flags.inc 2) Don't copy files you find in application release packages, they could be expired or buggy (bugs which may not be relevant for the released application, but for yours) 3) try to use global defines or packages whenever possible. E.g., it was a good decition to use j5_io, because it allows other users to compile the project for PIC18F452 without modifying your source code Best Regards, Thorsten.

of course, this is important. It must be ensured, that the selected hardware flags are matching with your processor type (specified in the Makefile as PROCESSOR variable), because as you can see in j5_io.inc, the ADC is disabled depending on PIC_DERIVATIVE_NEW_ADC (defined in hw_flags.h) You can doublecheck the right selection by searching in the .lst file (in your project it's probably named project.lst) for the J5_IO_Init function. You should see, that opcodes have been generated for "movlw 0x0f", but not for "movlw 0x07" If this doesn't help: what is the content of address 0xf92 (TRISA), 0xf96 (TRISE) and 0xfc1 (ADCON1) - they can be read out with the debugging window of MIOS Studio. Best Regards, Thorsten.

SVN: I will check this soon, seems to be an incompatibility with the new server (common access via ssh is working, but it isn't public) As you can see here: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fmodules%2Fj5_io%2F the last change was 2008-08-05, and this version is also available in the current mios_base package Best Regards, Thorsten.

Without reading the complete posting: which version of j5_io.asm are you using? Recently I found a bug, and updated the mios_base package The change is also available in the repository (for the case that you are using SVN to receive updates automatically) Best Regards, Thorsten.

Hi, check out sm_c_example2 :) http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsm_c_example2%2F No, it's only possible to add assembly code to C routines (but it's very tricky and not straightforward) Mostly it's easier to place assembly functions in a separate module, and to call the assembly code from C - this is demonstrated in sm_c_example2 Best Regards, Thorsten.

Cannot be realized with the existing concepts, but it's a nice application for a seperate core which somebody else could program (e.g. in C) Best Regards, Thorsten.

Not planned from my side; a tool which converts MIDI files into MBSEQ compatible patterns would have to be programmed by somebody else Best Regards, Thorsten.

Yes, this has been changed, but it is a feature :) This will show the edit screen so long you press&hold the layer button, and the message will disappear 2 seconds after the button has been depressed. Very nice for quickly checking, which events are played by a track without changing into the edit screen. You don't need to remember, how to enter the current menu page again. It's especially nice in conjunction with the step recording function, because it allows you to check the recorded values without leaving recording mode. yes, because it's only a layer display, and not layer edit mode Really? Why not pressing the edit button if you want to edit a layer? Without too much effort I could add following functions to the existing code: - replaying the current step of selected tracks so long a special button is pressed - after releasing the button function, either continue with the next step, or continue with the step which would be played if you wouldn't activate the function (in other words: if you activate the function for 4 16th note steps, the track would continue with the 5th step) I think that both possibilities are useful. The first matches with your descriptions, the second has the advantage that the track is in-synch again with other tracks once you release the button - optional 2x, 3x or 4x multi-triggers per step So, you want to speed up the step progression and clock dividers in addition. Thats possible, but it wouldn't allow to synchronize back to the other tracks before the next measure is reached. Is this acceptable? Maybe a special menu page would be helpful, where you can tweak multiple speed/repeat/step behaviour parameters which control this special function, so that everybody can decide by himself, which settings are working best with his style. haha - no ;) But I find these experimental features attractive. :) Best Regards, Thorsten.

I'm sure that I understood your question, I'm not sure how I can explain the methods better. You are asking: My answer was: You can modify the .hex file with a common text editor. You could also write a text processing script (if you know how to do this) to extract the data section and to write it into a new .hex file before loading the new file into MIOS Studio. It isn't difficult to do, there are many programming examples for SysEx handling and EEPROM store/load operations in the repository, but it seems that you haven't looked into the files... this makes it really difficult to help you. As mentioned before, most of the MIDIbox applications are supporting exactly these SysEx functions, and they are mostly programmed on different ways to cover special application requirements. They are not using MIOS Studio to exchange data. However, so long the incoming data is buffered (or directly written into existing data structures for the informations you want to exchange), you can read and write back with a selfwritten SysEx handler. Your SysEx handler has to store the received (and temporary stored) informations into the EEPROM after the transfer has been finished. But as mentioned before, you have to take care that during the EEPROM write operation no additional MIDI data will be received to prevent data loss. Best Regards, Thorsten.

Yes, the new server is incredible! Don't forget to push the "Paypal Webhosting" button at the right upper corner of this webpage if you aggree :) Best Regards, Thorsten.