Sign in to follow this  
Followers 0
reboot

1541 emulates by sd card

54 posts in this topic

reboot,

this link has really made my day! I've been looking for ages for some C code to access memory cards.

Also, the way of connecting 6 buttons using only one (analog) input is quite clever.

Best regards, ilmenator

Share this post


Link to post
Share on other sites

Yeh nice one reboot :D I have some idea how happy you made ilmenator, he's been working really hard on that!

Share this post


Link to post
Share on other sites

This is indeed a great project - don't miss the promotion videos ;)

http://nl.youtube.com/watch?v=YEjF9uvv1gM

This reminds me, that replacing BankStick by SD/MMC is still on my ToDo list (meanwhile I got some cheap card sockets :))

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

ok for reading from the card but what about writing on it?

Share this post


Link to post
Share on other sites

Block read and write are not too different from each other!?

Best regards, ilmenator

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

...just leaves me speechless - as so often. This sounds GREAT!

Best regards, ilmenator

Share this post


Link to post
Share on other sites

:D awesomeness!!

Share this post


Link to post
Share on other sites

woohoo!

that is gonna rock

Share this post


Link to post
Share on other sites

Sweeeet  ;D This'll be fun.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

hello

has anybody know that link?

http://jderogee.tripod.com/project1541.htm

wonder if it works with my sp-12  ::).....or to load games on c64!

I brought up the idea of doing a group buy for this on the cctalk mailing list some time ago.  It kinda fizzled out.  Still, I'd like to get one of these eventually.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

TK, have you considered using CF cards instead to take advantage of their greater access speeds?

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

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...?

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0