Jump to content

1541 emulates by sd card


reboot
 Share

Recommended Posts

  • Replies 53
  • Created
  • Last Reply

Top Posters In This Topic

I had a look at the C code of the project - I'm afraid it's a little over my head. The main problem is that there are so many features that I cannot really see where to start. I would not need any kind of file system, a block-wise access to the memory card would be just okay.

I guess I need to invest some more time than what I had thought at first  :).

Also, I am not sure about the code compatibility with the SDCC compiler?

Best regards, ilmenator

Link to comment
Share on other sites

I only see the difficulity to handle the FAT file system when adding files, I guess that it requires a lot of code and probably a lot of RAM.

On the other hand: it should be easy to prepare directory structures for different purposes.

E.g. MBSID: just prepare bank A/B/...G in different directories, and put 128 files with a size of 512 bytes into each, which are the "slots" for 8*128 patches

This would also simplify the patch exchange between MBSID and your computer :)

Best Regards, Thorsten.

Link to comment
Share on other sites

Surprise ;)

sd_card_proto1.jpg

sd_card_proto2.jpg

sd_dir.gif

I quickly soldered a prototype board, and uploaded the example application for a "mass storage device" (AN1003).

The C code which accesses the SD card looks simple. However, the challenge will be to make the code small enough, so that it fits into existing applications (w/o USB support of course). It also makes sense to use the bitbanging method instead of SPI peripheral for higher GPIO flexibility (speed doesn't really matter, considered that a SD card is already much faster than a IIC EEPROM)

I think, that it can be easily re-written in assembly, and provided as a MIOS Module

Best Regards, Thorsten.

Link to comment
Share on other sites

I know it is early days at the moment but.... TK do you know what pins you may use for this? I'm doing some designing right now and would like to be sure I leave room for this baby ;)

I've started arranging an order of 25+ SD sockets too, so we should have enough for people to do some testing when it comes to that.

Link to comment
Share on other sites

I know it is early days at the moment but.... TK do you know what pins you may use for this? I'm doing some designing right now and would like to be sure I leave room for this baby ;)

I've started arranging an order of 25+ SD sockets too, so we should have enough for people to do some testing when it comes to that.

It's much too early to prepare SD card support for applications, because I'm still in the evaluation phase. Meanwhile I've written routines to read/write sectors, but it's still unclear to me, if FAT support is feasible for applications like MBSID, because it requires a lot of additional code. Maybe with some dirty programming tricks it will be possible...

Means in other words: it's a piece of cake to use a SD card as BankStick replacement, but once you want to transfer files to/from a computer as well (-> FAT support), a solution which works flexible enough probably gets too complex.

Some useful resources I found:

FAT16 driver by Roland Riegel: http://www.roland-riegel.de/sd-reader/

FAT in a nutshell: http://home.teleport.com/~brainy/fat16.htm

A very geeky SD socket replacement by Rob Wentworth: http://uanr.com/sdfloppy/

The last side confirms, that data input and output can easily be merged to a single line, which means, that only 3 GPIO pins are required (one dedicated pin for CS#, two pins for clock and data IO). The upcoming sdcard driver will allow to freely assign the pins to GPIOs

I won't have the time to continue the evaluation in the next two weeks, but you can be sure that SD cards will be supported in future :) (I will open a new thread later). A nice demonstration project would be a MIDI file player, but it could also be a MIDI stream recorder ;)

Best Regards, Thorsten.

Link to comment
Share on other sites

Haha ;)

A PIC is too slow to take advantage of the bandwidth already provided by MMC/SD cards, so it doesn't really make sense to consider alternative solutions.

Isn't it much more difficult to interface a CF card to a microcontroller?

Best Regards, Thorsten.

Link to comment
Share on other sites

Isn't it much more difficult to interface a CF card to a microcontroller?

In theory probably not, because it can also be addressed linearly, and there is even some PIC assembler code around on the net. But I was not able to get it to run when I tried that seriously last year (could have been my fault, naturally  ;)). My advice would be to forget CF.

I won't have the time to continue the evaluation in the next two weeks, but you can be sure that SD cards will be supported in future :)

GREAT, GREAT, GREAT!  ;D

Yikes!

Best regards, ilmenator

Link to comment
Share on other sites

To give you some numbers: reading a 512 byte sector takes ca. 3 mS, writing a 512 byte sector ca. 4 mS

For comparison to an IIC EEPROM: 512 byte read ca. 11 mS, 512 byte write ca. 100 mS

Flash memory consumption of the driver: ca. 600 bytes

TK: Perhaps it would be better, to have a tool for the PC to write to the midibox format, than to have the midibox support FAT...?

of course, it would be better - but who is skillfull enough to implement such a tool? It could be difficult to get raw data access via a common SD card reader.

However, writing/reading sectors of the card via SysEx would work as usual, we are speaking about a more comfortable, and especially faster solution (if you want to read/write data from any computer w/ a cheapo SD card reader). I think, that it wouldn't be so difficult to search in the root directory for a single file which holds the complete data (e.g. "SIDBANKS.DAT"), and to go through the FAT to find out the corresponding clusters/sectors. So long the used clusters are cached in a buffer, it wouldn't decrease the access speed. It's something which cannot be realized in one day, but maybe in two until it will work ;)

Best Regards, Thorsten.

Link to comment
Share on other sites

I did some work using CF a while back. The I/O is parallel, a CF card effectively looks like an IDE drive. This is very good for fast cameras where transferring data to the card is the bottleneck. In the world of microcontrollers as used in the MIDIbox, a serial peripheral interface is better: it only uses a few pins, and the interface is going to be fast enough anyway.

CF are good for booting micro PC's from, and for very fast large block data. They can virtually be interchanged with small hard discs, (in fact, some of the bigger camera cards were small hard discs). They are physically large, and have a complex socket which needs a minimum of 20-something connections. CF pairs very well with the older PCMCIA/PC-Card slots, being virtually a straight through interface that needs no real drivers, (the new ExpressCard has trashed that, of course)

SD are the other common standard, (along with smaller MicroSD and XD). They are small, serial and come in sizes well big enough for our purposes. They seem to be a lot cheaper too. As camera cards get bigger, we can recycle the smaller ones for MIDIbox.

As TK says, the FAT files interface is going to be a challenge, and if it's going to be a challenge for TK, then I'm not even going to take a look at it! Perhaps one approach might be to go modular: add another micro to the SD card interface, and make the card subsystem look like a big stack of banksticks. Select banks by simple title or number, (no long file names, thank goodness), and only 'see' certain file types. Don't allow file operations beyond load/save/delete from the MIDIbox. MIDIbox generated file names might have to be of the generated form FILENN.XXX. Set up a simple list of XXX extensions for MIDIbox. ".SV3", ".SQ3", ".SID" or whatever, and refuse operations on others, (apart from perhaps 'delete', with a good 'are you sure' system). Date/Time would have to be set as defaults, unless someone wants to interface an I2C real time clock, (not that hard, thinking about it - I've got a feeling there might be a handle waiting in MIOS for just that too, knowing TK). Do your file renaming and 'housekeeping'  on the PC.

With regard to sockets, I wouldn't think of buying in yet: the sockets are easy. The board they go on is going to be the hard part. It has to hold the socket, (more easily available in surface mount), and some flexible way of panel mounting it. An activity light is nearly essential, (to avoid pulling the card during a write), and there might well be some I/O parts. A panel bezel with a simple screw mount would be good as well - plenty of design things to be digging in to, and  group buy of sockets, PCB's and bezels would be even more useful.

Just a few thoughts. In my case it was work for a FORTH based data logger running on the late lamented TDS series of cards, we had to use CF - SD hadn't come out at that time, and I shudder to remember just what a 512K card cost back then. We did have an RTC, the main effort was doing a low power mode to get maximum battery life. I think the final version would run 2/3 months in the field.

TK: you never cease to surprise us!

Best wishes

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share


×
×
  • Create New...