I had a dream....

[leZone]

solution is here ? http://cpcwiki.eu/forum/index.php/topic,1197.0.html

[arnoldemu]

solution is here ? http://cpcwiki.eu/forum/index.php/topic,1197.0.html

Well, almost.

I originally wanted a *cheap* interface that could be used *without* disc interface, for storage of simple files.
Something where you can put the card into the pc and dump files on it (using windows, e.g. no special tools), and then put into cpc and read those files. Ok I would need a filing system rom. But I can write that.

So this solution is too expensive and also for disc interfaces

[redbox]

Some rom software for CPC, which patches OS (cas in open/cas in direct etc...) and reads from SD Card. (I would be happy to write this).

This is exactly what I want to do with the parallel cable - so instead of a SD card, you have a PC attached as a 'server' and then the OS is patched on the CPC to read from the PC.  Or if this is not possible, I want to patch the 6128 Plus cartridge so that instead of Burnin' Rubber it has the CPC transfer utils for DSKs, Binaries, SNAs etc. - much like the patched PARADOS cartridge image you can get.

Parallel cables are cheap and most people have an old PC lying about 

Only thing is I've got to learn C++ so I can understand the old DOS sources for the PC utilities written for the parallel cable 

[TFM]

At this point I strongly advice you guys to look there:

http://8bit.yarek.pl/interface/yamod.ide8255/

Scroll a bit down to see the CPC version. This is the fastest solution to drive IDE devices (hard-discs or adapted SD-cards). It's faster than the SF-II.

So if you want again to create something new... PLEASE STAY COMPATIBLE!!!    And really have a look at this project, no need to invent the wheel again

Hope this help you!

[arnoldemu]

I am thinking about this idea again.

I can go into poundland and I can buy a sd card reader that looks like this for £1.
http://benryves.com/journal/3667153

scroll down to the picture of the white reader thingy and where it mentions poundland and it shows the connectors.

I understand the sd card needs 3.3v.

I've read elsewhere that as a "hack" you can put some pins into an idc connector and the sd card can fit into this. So this is another way to create a cheap connector.

Reading the spec it seems to say that the host controls the clock, and potentially this could be under cpc control by toggling a bit on a port on/off.
also the data could be read/written through a port too.

So the minimal requirements are:

Some kind of connector
power conversion from cpc's 5v down to 3v
some kind of port decoding
some software to do the toggling (bung it into a rom for example).
And then we could load/save data through sdcard???

and then it would be possible to have a rom providing access to the sdcard filesystem?

Or... is there more to it?

would it be cheaper to bung in a pic to do the port decoding, and some simple stuff, can the pic also adjust the voltage?

[Bryce]

Hi Arnoldemu,
      you're not far off, generally that would be possible, the only bit you forgot is that the SD Cards data interface is serial (SPI) not parallel, so you would need an IC to read the 8 bits in parallel and send them out in series, but that's not a problem either. I often considered building this exact circuit, as it really is that easy, in fact the 3.3v "converter" consists of just two resistors The main issue (which is why I've never built it) isn't a hardware issue, it's a software issue. You must do they entire FAT control in z80, which is way beyond anything I could manage and would need to be in a ROM otherwise it would take up too much RAM, which also means that the entire FAT Control (driver) would have to be 16K (or less) assembly language. Is that possible?

Bryce.

[arnoldemu]

Hi Arnoldemu,
      you're not far off, generally that would be possible, the only bit you forgot is that the SD Cards data interface is serial (SPI) not parallel, so you would need an IC to read the 8 bits in parallel and send them out in series, but that's not a problem either. I often considered building this exact circuit, as it really is that easy, in fact the 3.3v "converter" consists of just two resistors The main issue (which is why I've never built it) isn't a hardware issue, it's a software issue. You must do they entire FAT control in z80, which is way beyond anything I could manage and would need to be in a ROM otherwise it would take up too much RAM, which also means that the entire FAT Control (driver) would have to be 16K (or less) assembly language. Is that possible?

Bryce.

Yes I read that it was serial, and again that could be done under software control. Interesting that the 3.3v converter is two resistors... which would you suggest?

So perhaps this device is within my scope of creation now? I have some ttl logic chips, so I may be able to knock up a simple device with very simple port decoding..

Coding the driver is not a problem for me, perhaps fitting it into 16k may be...
ok I'm going to look into this furthur and perhaps build a prototype circuit that I can use to make the initial code.

In the past I have written code to read discs created on the atari st, and that uses fat12, the code itself was small, about 4k or so, and that included my own code for reading/writing direct using the fdc. So, I think quite a lot could be put into 16k. Well if 16k is a problem, then 2 rom chips together could be used.

[Bryce]

Hi Arnoldemu,
        for Data going from the TTL device to the SD Card you can use a simple voltage divider like the one shown below (yes the data also needs to be 3.3V) to bring the 5V down to 3.3V. Data coming from the SD Card is also at 3.3V, so it can be connected directly to the TTL device if the TTL IC accepts 3.3V as being a "1" (check the datasheet), if not you'll have to use the 3.3V to switch a 5V source using a transistor.

I wouldn't recommend using a divider to create the 3.3V supply voltage for the SD Card though, but a low-cost variable regulator such as the LM317 could be used to achieve this.

Bryce.

[arnoldemu]

Hi Arnoldemu,
        for Data going from the TTL device to the SD Card you can use a simple voltage divider like the one shown below (yes the data also needs to be 3.3V) to bring the 5V down to 3.3V. Data coming from the SD Card is also at 3.3V, so it can be connected directly to the TTL device if the TTL IC accepts 3.3V as being a "1" (check the datasheet), if not you'll have to use the 3.3V to switch a 5V source using a transistor.

I wouldn't recommend using a divider to create the 3.3V supply voltage for the SD Card though, but a low-cost variable regulator such as the LM317 could be used to achieve this.

Bryce.

I was wondering if one of them MAX devices would be good to swap over the voltages?

I am thinking of starting to write some software first, because I am more familiar with that, starting with something to read fat based floppy discs, then I can then add the code for talking to the sdcard using spi using some i/o ports I will pluck out of thin air. When I can then simulate it, I'll have a go at making some real hardware and using real i/o ports.

[Bryce]

Maxim have a whole range of devices, but they're not that cheap. For a seriously robust design they'd be the right choice, but if you want to keep the device as cheap as possible, then I'd go for something simpler.

Let me know how the software side goes, then I'll take a proper look at what can be done on the hardware side

Bryce.

[arnoldemu]

One step closer to the dream???

http://frank.circleofcurrent.com/cache/fat_sd.htm

http://elm-chan.org/fsw/ff/00index_e.html

http://www.sparkfun.com/tutorials/65

Compile into a cpc rom, add the I/O code....?

[Ynot.zer0]

I've just been researching the exact same items, albeit from an Arduino.  The question I have is: if I acn read that data to/from the SD Card (via the Arduino C libraries), how do I get it to interface with the Amstrad CPC? What sort of code do I need to write and how do I connect it to the CPC? Is it via the Floppy Disc driver controller?

[arnoldemu]

I've just been researching the exact same items, albeit from an Arduino.  The question I have is: if I acn read that data to/from the SD Card (via the Arduino C libraries), how do I get it to interface with the Amstrad CPC? What sort of code do I need to write and how do I connect it to the CPC? Is it via the Floppy Disc driver controller?

You need an I/O port on the CPC, then use the z80's IN/OUT instructions to access it.
To make this in hardware you need to decode the /IORQ, /RD, /WR, /M1, address lines and data lines I think.

I was thinking it may be possible to do all of it with just the z80 with no need for arduino etc.
The problem is writing the SPI protocol, but this library may already have it in there.

[MaV]

Perhaps this Hack can serve as a basis for an SD-Card on a CPC?

http://zdoom.ic.cz/gameboy.html

[OCT]

Perhaps this Hack can serve as a basis for an SD-Card on a CPC?
http://zdoom.ic.cz/gameboy.html

This, in fact, would be(come) an HxC-style Plus cartridge emulator.

[Bryce]

Not quite. The Plus cartridge port doesn't have a /WR pin, making writing to the port pretty difficult. It's not impossible, just very complicated.

Bryce.

[OCT]

Not quite. The Plus cartridge port doesn't have a /WR pin, making writing to the port pretty difficult. It's not impossible, just very complicated.

I wasn't even thinking of emulating RAM on that, though the Czech solution seems to have found a way to do that nicely on the Gameboy, and future software might support something like it on the Plus (though that's for a very small niche market of course).
What I had in mind was that it might be the starting point for one more approach to a customizable multi-cart:
Imagine a one-line LCD/(O)LED on the protruding label part of a cartridge, along with buttons to select which EPROM image it shows to the Plus on reset...

[Bryce]

Oh, ok. That would work. There are similar systems (less the display) available for the Atari XL/XE like the Atarimax USB Cartridge:

http://www.atarimax.com/usbcart/documentation/

Bryce.

[arnoldemu]

http://members.multimania.co.uk/mmbeeb/#mmchardware

this is the easy/simple kind of thing I was talking about.
It would need some ttl for i/o decode.

I would need to choose a good i/o port to make it work.