I had a dream.. it was simple.
A simple solution which would work for all cpcs, 464, etc.
A hardware interface to plug into the back of cpcs.. or maybe even plug into cassette port, or printer.. or ...?
But the basic interface is the same. A SD card slot, a PIC or ATMega or similar providing some I/O ports and control for sd card. (Just I/O for read/write).
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).
SD Card formatted to MS-DOS.
So..?
I was thinking it could be cheap?
it would work for all cpc/plus because no disc interface is needed.. just plug in and enter commands to load.
Ok, it would not work with protected software or anything hitting fdc directly... and then I had another though.. if we really needed this.. why not emulate the fdc controller too?
Is this dream impossible or too expensive?
Don't worry about the cost... make it so ;)
Actually do worry about the costs, but only if we're talking over £50 - 60.
I like the dream. very much.
it would help me overcome the limitations of the SymbiFaceII, the custom OS format of BonnyDOS and the limitations of the (lotharek) SD-card reader.
I'd happily purchase a couple of these devices (and would be willing to donate $$$ towards prototype costs, if someone were to take on the hardware construction)
Hi Martin Luther,
we seem to have similar dreams ideas. I've been playing around with a similar project lately, however I was planning to connect a 2.5in HDD to the expansion port. The idea was to simply connect the data and address bus of the HDD (with a simple address decoder and buffers) directly to the CPC expansion port, plus a dual socket EPROM section to hold the RSXs. Obviously the entire HDD control then needs to be done by the CPC, but it simplifies the Hardware immensly, my initial plan was to avoid using a µProcessor at all on the adapter. I had been looking at using BonnyDOS for the project, but if someone is willing to write a FAT compatible OS, it would have the advantage of being swappable between CPC and PC.
For an SD version, things are slightly more complicated, because the data needs to be converted to be passed to the SD. It means a µP is most likely required, will need further investigation.
Generally though, yes I'm interested and would be willing to take care of the hardware side of things.
Bryce.
Hi Arnoldemu,
I had a very quick look at what the lowest cost solution to connect an SD Card to a CPC would be. Using a low-cost PIC with an SPI bus (PIC16F819 cost about €2.30 here) I could communicate low-level with an SD Card, passing the commands and data on to the CPC using maybe 2 Addresses (8 Bit Data und 8 Bits for Status/Commands). The circuit would be semi-dumb though. It would initialise the SD Card for SPI Mode read/write and from then on just pass the data back and forth. I estimate the entire circuit would cost around €20 to build (not including the EPROMS). Would this be enough for you to base a FAT system on? How much EPROM do you think your code would require?
Bryce.
I like where this is going...
Quote from: Bryce on 13:07, 04 May 10
Hi Arnoldemu,
I had a very quick look at what the lowest cost solution to connect an SD Card to a CPC would be. Using a low-cost PIC with an SPI bus (PIC16F819 cost about €2.30 here) I could communicate low-level with an SD Card, passing the commands and data on to the CPC using maybe 2 Addresses (8 Bit Data und 8 Bits for Status/Commands). The circuit would be semi-dumb though. It would initialise the SD Card for SPI Mode read/write and from then on just pass the data back and forth. I estimate the entire circuit would cost around €20 to build (not including the EPROMS). Would this be enough for you to base a FAT system on? How much EPROM do you think your code would require?
Bryce.
This is a great value. It is not a problem that the circuit would be dumb, I don't have a problem with that.
I would like a 16K eprom if possible. 8k would be a push.
I've written a fat reader in the past (source lost), but I'm happy to write a newer one again.
I plan to have the same kind of | commands and interface that amsdos has, but it'll be dos based reading/writing.
Ok, I can't promise a circuit tomorrow, but I will look into it within the next few days and get back to you. If it only requires one ROM then that's even better (as far as cost is concerned), BDOS required 3 as far as I can remember. I'll also try to stick with regular thru-pin components (no SMD except for the SD-Card Slot) to keep it "Hobbiest-friendly".
I checked some more component prices, an SD-Card Slot cost €8.50 here!!! Will have to investigate whether there are cheaper sources.
To all: is there any particular address range which I should use (or avoid) to keep things compatible. It's probably best to use an address used by other HDD/Symbiface devices, because the chance of having both connected simultaneously is rather low. Let me know...
Bryce.
Please can we design it to sit nicely alongside the CPC or Plus... my Symbiface II is a complete eyesore.
When the circuit design is finished, we can work on alternative layouts for individual tastes. It should be a lot smaller than a Symbiface though.
Bryce.
I already thought about such an expansion, too and I think that this is a great idea. For the implementation: if you already use a microcontroller, then the microcontroller can handle the FAT implementation. You can then control it via CPC with simple commands (e.g. open file, read x bytes, etc.). I guess that this can speedup the development on the CPC side, because the implementation within the ROM will be much simpler.
Personnally, I dream that i have a USB port for my Amstrads.
Working like a USB port on my PC.
How fun would it be to plug a 1gb flash memory key...
Or a modern gamecontroller, Mouse or Wireless keyboard.
Perhaps even internet connection ?
oops.
one dream at a time ;)
I think FAT16 should be good.
Windows, and also Linux can read/write to it.
So, a FAT16 rom for CPC + IDE interface with SD-Card support would be really cool.
AFAIK sd-cards are formatted in FAT16 as standard.
And sd-cards are cheap today. 4gb ~4-8€
So this would be a great equipment for a CPC!
BTW, My dream didn't include putting dsk files on the sd-card.
Only normal files.
I've started (and never finished :( ) a similar project few years ago, but using a compact flash instead of SD/MMC.
The main reason for using a Compact flash was the erase block size. On CF, it is one block (512byte), on SD this is not fixed and can be bigger than 16K. So write support on SD would require a big buffer for read/modify/write.
Using CF also simplify the design as you only have to deal with a 8bit device using 8 IO addresses. So it's mainly a matter of address decoding and buffers (if you want to support 3.3v CF).
About FAT support :
Support for fat 12/16/32 is equal in complexity. You may still find fat12 on small capacity memory (16Mb).
Support for long name is an other issue when it come to write. But we do not need that on CPC (long name, not write ;) )
I agree the design is much easier with a CF card, but bear in mind that they are increasingly hard to find and they are more expensive than SD cards.
@arnoldemu, I think it would be better that the device supported loading of dsk files (and maybe cdt or sna files) but I know this add a lot of complexity to the design.
Although an 8-Bit port on the CF Card may seem like an advantage (I was of this opinion too), the SPI port and addressing offered on all SD/MMC cards (they offer 4 different interface methods!) isn't really that complicated , especially when a lot of µPs from Microchip/Atmel offer a fully programmable SPI port which only requires 3 pins of the µP (Data in, Data Out, Clock), leaving more pins over to control other signals to the CPC. After reading up on SD Cards and their protocols, I changed my mind on which Card I should choose.
µP Embedded FAT: Would mean using a bigger more expensive processor, which would be more or less Symbiface III, the aim of this board should be to minimise and simplify the hardware.
DSK Support: Isn't really necessary if the FAT supports sub-directories, then each directory can be considered a disk (of almost unlimited size), so why bother with DSKs? Or do they offer something more?
Bryce.
€8 for a slot is way too expensive; I guess you could just buy a batch of card readers, say from Deal Extreme and rip them apart for a much lower price :D
As far as formats go, I'd stay clear from FAT16 because who knows how long it survives... plus, I think the limit is 2GB on it? Not great!
Quote from: Bryce on 22:09, 04 May 10
Although an 8-Bit port on the CF Card may seem like an advantage (I was of this opinion too), the SPI port and addressing offered on all SD/MMC cards (they offer 4 different interface methods!) isn't really that complicated , especially when a lot of µPs from Microchip/Atmel offer a fully programmable SPI port which only requires 3 pins of the µP (Data in, Data Out, Clock), leaving more pins over to control other signals to the CPC. After reading up on SD Cards and their protocols, I changed my mind on which Card I should choose.
µP Embedded FAT: Would mean using a bigger more expensive processor, which would be more or less Symbiface III, the aim of this board should be to minimise and simplify the hardware.
DSK Support: Isn't really necessary if the FAT supports sub-directories, then each directory can be considered a disk (of almost unlimited size), so why bother with DSKs? Or do they offer something more?
Bryce.
Dsk is a dump of a 3" disc.
Note to others: Trying to support that could be a real problem and it would be impossible to support copyprotected ones because of their direct access to the fdc chip.
I was originally thinking just files. As far as fat support, really there is not much in fat12, fat16, fat32, except larger cluster sizes.
Most cheap card readers don't have a seperate SD Slot component, it's one big chunk of plastic with 4 or 5 slots, so you'd have to saw off the bit you need. I'm sure there'll be other sources though.
FAT16 is pretty old, and FAT32 is probably a better option and not much different to implement as far as I know.
That's up to Arnoldemu to make that decision though. The cluster sizes on an SD card in SPI mode are fixed at 512bytes. Not sure if this causes an issue or is an advantage? Arnoldemu?
Bryce.
Quote from: Gryzor on 08:51, 05 May 10
€8 for a slot is way too expensive; I guess you could just buy a batch of card readers, say from Deal Extreme and rip them apart for a much lower price :D
As far as formats go, I'd stay clear from FAT16 because who knows how long it survives... plus, I think the limit is 2GB on it? Not great!
Depends on the OS, 4 GB for FAT16 on a Windows 2000 box. And there are workarounds to get DOS to see a 4GB partition also. I'm not sure FAT32 would work for this project, as its more windows orientated. In fact, I've heard of people formatting a FAT16 partition upto 32 GB? Plus It is very efficient, both in speed and storage, especially on volumes smaller than 256 MB. Did I mention its compatible with almost anything???
Drive Size
| Default FAT16 Cluster Size
| Default FAT32 Cluster Size
|
260 MB–511 MB
| 8 KB
| Not supported
|
512 MB–1,023 MB
| 16 KB
| 4 KB
|
1,024 MB–2 GB
| 32 KB
| 4 KB
|
2 GB–8 GB
| Not supported
| 4 KB
|
8 GB–16 GB
| Not supported
| 8 KB
|
16 GB–32 GB
| Not supported
| 16 KB
|
> 32 GB
| Not supported
| 32 KB |
Also take into account that those figures are per partition and more than one partition could be created on an SD card. And what's more, how much software actually exists for the CPC? Would you ever fill 32GB, even if you had every game ever released on the drive?
Bryce.
Quote from: Bryce on 09:49, 05 May 10
Also take into account that those figures are per partition and more than one partition could be created on an SD card. And what's more, how much software actually exists for the CPC? Would you ever fill 32GB, even if you had every game ever released on the drive?
Bryce.
True, listen up peeps, this guy knows his onions.
- http://piters.tripod.com/zxcf.htm (http://piters.tripod.com/zxcf.htm)
a spectrum compact card interface and it's really simple. cpc version anyone?
solution is here ? http://cpcwiki.eu/forum/index.php/topic,1197.0.html (http://cpcwiki.eu/forum/index.php/topic,1197.0.html)
Quote from: leZone on 12:59, 17 September 10
solution is here ? http://cpcwiki.eu/forum/index.php/topic,1197.0.html (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 ;)
Quote from: arnoldemu on 09:42, 04 May 10
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 :(
At this point I strongly advice you guys to look there:
http://8bit.yarek.pl/interface/yamod.ide8255/ (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!
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?
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.
Quote from: Bryce on 22:19, 11 November 10
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.
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.
Quote from: Bryce on 11:48, 12 November 10
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.
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.
One step closer to the dream???
http://frank.circleofcurrent.com/cache/fat_sd.htm (http://frank.circleofcurrent.com/cache/fat_sd.htm)
http://elm-chan.org/fsw/ff/00index_e.html (http://elm-chan.org/fsw/ff/00index_e.html)
http://www.sparkfun.com/tutorials/65 (http://www.sparkfun.com/tutorials/65)
Compile into a cpc rom, add the I/O code....?
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?
Quote from: ynot.zer0 on 11:16, 28 May 11
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.
Perhaps this Hack can serve as a basis for an SD-Card on a CPC?
http://zdoom.ic.cz/gameboy.html (http://zdoom.ic.cz/gameboy.html)
Quote from: MaV on 18:12, 03 July 11
Perhaps this Hack can serve as a basis for an SD-Card on a CPC?
http://zdoom.ic.cz/gameboy.html (http://zdoom.ic.cz/gameboy.html)
This, in fact, would be(come) an HxC-style Plus cartridge emulator.
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.
Quote from: Bryce on 21:25, 03 July 11
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...
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/ (http://www.atarimax.com/usbcart/documentation/)
Bryce.
http://members.multimania.co.uk/mmbeeb/#mmchardware (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.