CPCSD: new mass storage solution

[fgbrain]

through the printer port

so we should forget our digiblaster ? 

[Bryce]

Well it definitely wouldn't be DigiBlaster compatible, or to be exact, the DigiBlaster is zero compatible with anything connected to the printer port. The DigiBlaster resistors would really mess up the data signals for other devices.

Bryce.

[TFM]

Therefore these bigboxes, printer-switches do exist. I already use two(!) of them at the same time (sic).

[MacDeath]

Wasn't digiblaster CPU/RAM intensive anyway ?

I mean, some external soundcard could easily be better, but ok it could just be a MP3 player vaguely controled by the CPC...
(which all of you purists wouldn't like...)

Also, would the printer port need to be upgraded into 8bit ?

[TotO]

Funny to see peoples speaking about the low speed for this "low cost SSD".
It's faster than the Floppy Disc, and I don't speak about tapes...

[Bryce]

Wasn't digiblaster CPU/RAM intensive anyway ?

I mean, some external soundcard could easily be better, but ok it could just be a MP3 player vaguely controled by the CPC...
(which all of you purists wouldn't like...)

Also, would the printer port need to be upgraded into 8bit ?

Maybe I should look at making the CPCSID

Bryce.

[Octoate]

I'm stil lwondering why no one tried it on CPC before.

Nilquader designed a similar device over a year ago and used it with the CPC, the NC100 and under MS-DOS. So, yes, there was already a device, but currently the development is stalled.

For the speed discussion: Hey, this device will allow you to access gigabytes for a very, very cheap price - why complaining about speed? Speed isn't the question here...

[SyX]

And sources and schematics are free to use and abuse for the community. If somebody want to attach a compatible interface using the expansion port, only need to change the low level access routines, totally painless compared to write a new "disk" rom.

[MacDeath]

Funny to see peoples speaking about the low speed for this "low cost SSD".
It's faster than the Floppy Disc, and I don't speak about tapes...

but still slower than my USB2 or firewire on my modern PC...

but you may be right, if it is faster the floppy, it's quite fast enough.

the CPC has at best 128K to fill... not like we need those to be full in 1 nanosecond.

one question is... how could it perform with the loading and displaying/playing/streaming trick, like the Batman demo does ?

Also how does it perform compaired to the various HardDiscDrives solutions available for CPC ?


no one answered me about the 8bit printer port upgrade.

[HAL6128]

...would it possible to use the SD like a normal 3" Floppy in case of a disc loader system (trackmo)?

[Bryce]

@MacDeath: It shouldn't need an 8-bit port to work, there's enough signals there to communicate with an SD Card.

Regarding the speed, SD Cards communicate using an SPI signal, which means that it's a serial signal with an on-the-fly variable frequency (ie: you can continuously change the speed of the data flow), so the upper speed limit will be mainly definied by how fast the CPC can request/recieve bits. This will be down to how the software is written, but the top speed is obviously limited by the speed of the Z80. The theoretical top speed should be easy to calculate. But remember, the data is being pulled across bit for bit, not byte for byte.

Bryce.

[SyX]

...would it possible to use the SD like a normal 3" Floppy in case of a disc loader system (trackmo)?

Sure, new demos could make that easily taking a look to the sources; but for old demos accesing directly to the FDC, you will need to patch them... CPC WHDLoad project???

[PulkoMandy]

It is possible to use the tape port on the 6128Plus if you want to keep the printer port. On other CPCs it is not possible because of the tape relay (unless you remove that).
The printer port is also very simple, you can build something similar with 2 or 3 logic chips. But I'm too lazy to do it.


There are a lot of other solutions to plug an SD card to a CPC :
* Using the HxC floppy emulator
* Using the SPI port of the CPC Booster microcontroller
(both of these can be faster than the printer port version)


But, you have to connect it somewhere anyway.

[TFM]

For the speed discussion: Hey, this device will allow you to access gigabytes for a very, very cheap price - why complaining about speed? Speed isn't the question here...

It's slower than a floppy disc, we discussed that in Push'n'Pop. So how much years do you need to fill a GB? IMHO that's overkill.
But if somebody can do a PC program to fill the card, then I may have the time to patch RDOS to use it like Dobbertin RAM drive C - or maybe mounting DSKs and simulate a floppy.

[SyX]

But if somebody can do a PC program to fill the card, ...

PulkoMandy is working in it and is working great

[TFM]

Cool! I must have overread that one!! That's very good news.

[joska]

FAT is possible, but needs more RAM buffers for managing stuff.

I'm completely new to the CPC, so this might be obvious (or already made): But why not use a microcontroller to drive the SD-card? You could then read/write in nibbles through the printer port, this would be much faster than bit-banging SPI directly on the CPC. Also, you can offload the FAT16 driver to the microcontroller, which means almost no RAM-usage on the CPC and a very, very simple driver (just forward the OS-calls to the microcontroller).

[TFM]

I'm completely new to the CPC, so this might be obvious (or already made): But why not use a microcontroller to drive the SD-card? You could then read/write in nibbles through the printer port, this would be much faster than bit-banging SPI directly on the CPC. Also, you can offload the FAT16 driver to the microcontroller, which means almost no RAM-usage on the CPC and a very, very simple driver (just forward the OS-calls to the microcontroller).

The printer port does only allow to read single bits (because it's an output port, not considered to read data). Writing would be doable in nibbles / bytes though. But usually people would more often read data.

[SyX]

@joska: If you read this thread you will see that the initial idea of PulkoMandy is a simply, cheaper, easy to make, easy to understand, open (sources and schematics) and fun little project. And when it's finished, i'm sure that a lot of people will try to improve and customize it, using microcontrollers, attaching to other ports, adding disk images support, making the "pino puente", ... But before to run, we must learn to walk

[arnoldemu]

I plan to use it just as it is.. parallel port, SPI transfer, loading from rom.
I think it's a really great low-cost device.

There are lots of 1 file cracks/packs that cngsoft has made, so you will  already be able to run lots of programs from it.

Many programs that use firmware and talk to the firmware nicely for loading will work direct i hope (e.g. nightshift music demo should work off it), some other programs will need patching (e.g. they assume disc rom is in slot 7, when this device could be used on 464 without disc)... but I don't see this as a problem.

For people with 464 who find it hard to find a ddi-1 disc interface, they could now use this for faster loading on 464.

[Octoate]

It's slower than a floppy disc, we discussed that in Push'n'Pop. So how much years do you need to fill a GB? IMHO that's overkill.

I didn't write that the SD card gets filled by the CPC (this also doesn't make sense). It is not very complicated to write file system drivers for e.g. Windows or Linux...

@joska: That's correct. You can use a microcontroller to do all the work, but this will make the circuit more expensive and needs more parts than the printer port solution. If a microcontroller is used, it is only a small step to a full featured expansion port interface...

[Executioner]

Maybe I should look at making the CPCSID

How about a simple RAM buffer with a counter/timer chip that can be programmed to sequence through 8 bit samples stored in the RAM starting at a particular point and at a certain frequency and output them directly to a simple DAC.

[joska]

The printer port does only allow to read single bits (because it's an output port, not considered to read data). Writing would be doable in nibbles / bytes though. But usually people would more often read data.

OK, I see. I didn't know that the printer port was unidirectional. In that case there's nothing to gain speedwise to use a microcontroller.

[joska]

@joska: If you read this thread you will see that the initial idea of PulkoMandy is a simply, cheaper, easy to make, easy to understand, open (sources and schematics) and fun little project. And when it's finished, i'm sure that a lot of people will try to improve and customize it, using microcontrollers, attaching to other ports, adding disk images support, making the "pino puente", ... But before to run, we must learn to walk

I have experience with microcontrollers but little experience with the CPC, that's probably why I see the microcontroller solution as more simple But since you can't read from the printer port there's really only one advantage with a microcontroller - offloading the FAT-driver to the microcontroller to simplify the software on the CPC-side.

[arnoldemu]

PulkoMandy is working in it and is working great

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.