CPCSD: new mass storage solution

[MacDeath]

My Arduino has an Ethernet shield with a SD card reader... (alongside the ethernet, can't use both at the same time though)...

can't this be used ?

I'm still curious you guys still always go for custom cards and don't use the easily findable and available Arduino.

[SyX]

Hmm it seems you will not be using FAT filesystem?
Why not? CPC could read this (through rpalmers roms or other).

The reasons are in the thread already, PulkoMandy said:

FAT is possible, but needs more RAM buffers for managing stuff. It already works on CPC, as you have noticed if you used NoRecess host software for the HxC floppy emulator (this one uses C code). A z80 asm implementation of FAT is also available from the Retroleum project, and should not be too hard to plug in a CPC ROM.
The increased RAM usage means more compatibility problems with existing software. We are trying to keep the ROM as close as possible to AMSDOS. remember I'm doing this for fun, and designing my own FS sounds like a lot more fun than using an existing one ! :q

And we have taken note of the suggestion of Jeff_HxC2001 of having a MBR sector in the card to have a FAT32 partition coexisting with the filesystem of PulkoMandy.

I may have the time soon to write some filesystem code, so we can support read and write on cpc.

The project supports read and write in the cpc, that is guaranteed. But it's nice being able to handle operations, that it could take a lot of time in the CPC (for example, formating a 32 Gb sdhc is not going to be fun), in the PC using a tool or a filesystem driver for a more native way.

And of course, i encourage you to write a FAT filesystem, because every improve is going to improve the CPC community    And if we can help you with it, only said it.

@MacDeath: We are not using Arduino or XXX for pissing the people, read the full thread and you will get a better idea of the goals.

[TotO]

Hmm it seems you will not be using FAT filesystem?
Why not? CPC could read this (through rpalmers roms or other).

I may have the time soon to write some filesystem code, so we can support read and write on cpc.

It will be great to support FAT16.
- Faster than FAT32 on CPC
- 8.3 filenames and directory support
- 1KB clusters can handle 64MB MMC/SD (around 160x floppies)
- can be formated from the PC or CPC

A really cheaper SSD for all, that can change the daily use of our computer.

[TFM]

It will be great to support FAT16.
- Faster than FAT32 on CPC

For which reason is FAT16 faster?

[TotO]

Because, the implementation is more complexe and need more CPU power to be handled by a Z80.
(like for OFS, FFS, SFS or PFS, ... On Amiga as exemple)

[TFM]

Well, I'm not sure if that's the point.

Loading a sector still takes the same time for all file-systems, since the low-level routines "read sector" are the same. Guess that's the bottle neck.

Well, we will see one day 

[PulkoMandy]

It is very easy (I think I already said that ?) to plug an SD card to the CPC Booster if you want to go for a microcontroller based solution.
I have some problems with it, but they are not technical ones :
* Plugging a 20MHz chip to a 4MHz computer never feels like the good way to solve a problem. Why not replace the z80 completely then ? Or, I could use a PC as well ?
* Adding a microcontroller makes the hardware more complex, less easy to build, cost more, and need more work to get working than I'm willing to spend on it.
* Using the parallel port is interesting because it makes the device a lot more portable on many other computers. I have no knowledge to write the drivers, but an Atari ST or amiga version can be made.
* well, this started off as a weekend project, just messing with stuff I had on my desk.

[TotO]

Well, I'm not sure if that's the point.

Loading a sector still takes the same time for all file-systems, since the low-level routines "read sector" are the same. Guess that's the bottle neck.

Well, we will see one day 

32bit addressing with the Z80, w/o loosing speed?

[TotO]

Using the parallel port is interesting because it makes the device a lot more portable on many other computers.

I'm not sure it was interesting for Amiga, because they (A600/A1200) already support harddrive and Compact Flash with FAT32 for PC exchange.
But, on CPC and may be Spectrum, Oric, C64, ... It's a great feature.
And, for CP/M users, they can exchange data and use the same programs!

[TFM]

If there is interrest for CP/M Plus support I may can help, have to search the CPCs source codes in Munich...

[PulkoMandy]

As for using an arduino... well... do you see a printer port compatible connector on it ? a CPC expansion port ? No, of course. So it would need just as much wiring to connect it to the CPC.

And the arduino really has nothing very original on board : a microcontroller, a quartz, and a serial port. This is *not* the hard part.

Problems I noticed when trying to interface a microcontroller to a CPC :
* CPC expansion port has a lot of pins : 16 address + 8 data + about 8 "various" control signals. You need 32 pins to just talk with the CPC. Leaves not that much free for useful stuff.
* The CPC is the master in communication on this port. This means the controller needs to answer very fast. Either there is an extra buffer system, which slows down things, or you need cycle-accurate assembler code on the device, which will spend most of the time talking with the CPC. It's trickier than it seems.

For FAT support : both FAT16 and FAT32 are possible (note: you need 32bit math to access a 4GB card anyway). The problem is FAT needs some RAM buffers to work (more than 2Kbytes), to store the current dir, the cluster being worked on, and so on. This extra memory use means a lot of programs will have trouble running from it, so it is useful only as a way to share files with a PC. A custom filesystem allows to reduce memory use to about 512 bytes (a single SD card sector) buffer, and it can be more tightly integrated with AMSDOS (supports user numbers, reuse most of AMSDOS variables).

Anyway, you have the code to read and write sectors, and you have the hardware schematics. So, please ywrite your own softwar eif you don't like mine. I'm more than happy to see people using the card in other ways and improving on the design. Just have fun !

[TFM]

32bit addressing with the Z80, w/o loosing speed?

As a working example you can use SymbOS.
My personal experience is small, I started to do FAT32 support (LBA only), but lost "fun" on it through some struggles in the scene in that day (years ago). But I was able to read files from root at least, and I/O did make more than 95% of time-usage. Well, don't take that as good example, it's not finished. And I honestly got only a glimpse of it. Furthermore I never did other FArTs ;-) Just my impression 

[Jeff_HxC2001]

One other example of FAT32 on CPC :
SourceForge.net Repository - [hxcfloppyemu] Index of

Can access / read / write (without changing its size) files on root and subdirectories.

[TFM]

One other example of FAT32 on CPC :
SourceForge.net Repository - [hxcfloppyemu] Index of

Can access / read / write (without changing its size) files on root and subdirectories.

Ah... Can you tell us if you see speed differences between FAT16 or FAT32? Maybe ToTo made an important point. I cound never try it out.

[Bryce]

As for using an arduino... well... do you see a printer port compatible connector on it ? a CPC expansion port ? No, of course. So it would need just as much wiring to connect it to the CPC.

And the arduino really has nothing very original on board : a microcontroller, a quartz, and a serial port. This is *not* the hard part.

Problems I noticed when trying to interface a microcontroller to a CPC :
* CPC expansion port has a lot of pins : 16 address + 8 data + about 8 "various" control signals. You need 32 pins to just talk with the CPC. Leaves not that much free for useful stuff.
* The CPC is the master in communication on this port. This means the controller needs to answer very fast. Either there is an extra buffer system, which slows down things, or you need cycle-accurate assembler code on the device, which will spend most of the time talking with the CPC. It's trickier than it seems.

Well explained. Connecting an Arduino to a CPC takes more hardware than the custom device would need to do the same job (minus the Arduino). But connecting a custom µP device (PIC / Atmel) isn't that difficult. The 32 Pins are not always required, it depends what you want the device to do. Usually you can get away with decoding just the required address with a few cheap logic gates and enabling the µP when it's being addressed, freeing up µP cycles for other stuff. But it's still tricky, because a µP can't answer in realtime as the CPC usually requires. So data buffers are usually needed.

Bryce.

[morcar]

I so want this that I would love to beta test it and give it a run for its money

[arnoldemu]

I so want this that I would love to beta test it and give it a run for its money

I asked PulkoMandy about the h/w.
He told me about this:

SD Card Module Slot Socket Reader For Arduino ARM MCU Read And Write #K | eBay

Ok, so it needs wiring up to an edge connector for the parallel port. What are the needed connections?
mosi is output (?) one of the data pins?
sck for data pin.
cs for data pin?
miso is on the ready input?
...?

@Syx: How is the filesystem going?

[Bryce]

?? It's only the socket with a voltage regulator! Without lots of hardware you would need to create the entire SPI bus in software and add address decoding. It's like finding an old tyre at the side of the road and asking what would you need to add to make a Ferrari out of it

Bryce.

[arnoldemu]

?? It's only the socket with a voltage regulator! Without lots of hardware you would need to create the entire SPI bus in software and add address decoding. It's like finding an old tyre at the side of the road and asking what would you need to add to make a Ferrari out of it

Bryce.

PulkoMandy had a design which connects to the cpc's parallel port. All decoding is done
There is another design by Nilquader which is very similar.

Yes you would do the spi bus in software, and that is what SyX's filesystem does
So, it is not so bad.

It is like having a ferrari without a key and wheels.

I am now asking for the wheels and a key then I will be speeding down the road 

[Bryce]

Ok, it will work, but it's an aweful lot of software work and would be seriously slow.

Bryce.

[SyX]

I asked PulkoMandy about the h/w.
He told me about this:

SD Card Module Slot Socket Reader For Arduino ARM MCU Read And Write #K | eBay

Looks nice!!!

Ok, so it needs wiring up to an edge connector for the parallel port. What are the needed connections?
mosi is output (?) one of the data pins?
sck for data pin.
cs for data pin?
miso is on the ready input?
...?

For the CPCSD (but if you have any doubt about the building ask to PulkoMandy, he is always very helpful and direct feedback is always great for the motivation):
* MOSI is data output (DO in scheme).
* MISO is data input (DI).
* CS is slave select (CS).
* SCK is the clock signal for the protocol (CLK).

@Syx: How is the filesystem going?

We continue busy with real life, but at least this morning i have been able to stole a few minutes for converting a pair of routines to z80... i have been playing with the idea of making a "hackaton online" during a weekend for giving a boost to the project and being to release a final version soon

PD: We both are working in the filesystem, it's not only me.