The last few days Pulkomandy has been working in a prototype SD card reader/writer for the CPC through the printer port, you can find more details about this project here (http://pushnpop.net/topic-336-1.html).
The article speaks of needing to add in a filesystem.
From what I know and have said on the wiki is that HDOS has independent device drivers, so any device can be attached with little effort on the software front. So it is possible to quickly implement the device with an already developed filesystem to support it. Examples of the device drivers can be found on the wiki or I can email the drivers to whom ever wishes to develop a driver for themselves.
Also it is possbile to use the IDE interface with an adaptor card for SD if the article is correct in its use of the signal lines. The benefit here is that the IDE interface is customisable to allow for more than just one card to be attached, since it uses the 8255 to make-up an IDE port and the 8255 can be adapted to control and SD card intead (or many SD cards). I still have some of the IDE interfaces for sale.
Regards
rpalmer
Thanks rpalmer, i have passed the info to Pulkomandy :)
The magic of the HxC is that it runs out of the box, no ROMs or meddling with FS necessary. I see quite a few complications in normal use that would prohibit widespread adoption.
On the other hand, it's so cheap that -hell yeah!
Imagine - if we ever see another mega-game released on the CPC, it could be sold with the adapter itself AND an SD card to store all the data, and the price would still be down to earth...
Hi there :)
I'm making some progress on this. Yesterday I made some research on the existing FS solutions.
It turns out that none of the existing one are actually extpandable with device drivers ! I was planning to make some tests with RODOS, but actually I didn't find a way to add a driver to it, while the documentation says it should be possible...
I looked at HDOS (could find some infos in the forum, not in the wiki itself), and, I didn't find any info on how to write drivers. Moreover, it seems to be a huge number of RSXs, and most of them just seem to do nothing in the version of the ROM I have. That's not very user friendly :)
Anyway, I hope to see people building their own or getting them from someone else, and add drivers to whatever they think is useful. On my side, given the state of existing solutions and their documentation, it ends up being easier to rewrite my own FS. I have finished the design of disk structures, and I'm now writing the PC tool to access it while SyX does the CPC ROM.
As you may have seen on pushnpop forum, I published the sourcecode for sector read/write :
http://pulkomandy.tk/drop/cpcsd.z80 (http://pulkomandy.tk/drop/cpcsd.z80)
The schematics
http://pulkomandy.tk/drop/cpcsd.png (http://pulkomandy.tk/drop/cpcsd.png)
And pictures of the prototype
http://pulkomandy.tk/drop/cpcsdA.JPG (http://pulkomandy.tk/drop/cpcsdA.JPG)
http://pulkomandy.tk/drop/cpcsdB.JPG (http://pulkomandy.tk/drop/cpcsdB.JPG)
Quote from: PulkoMandy on 08:11, 06 May 12
Anyway, I hope to see people building their own or getting them from someone else, and add drivers to whatever they think is useful. On my side, given the state of existing solutions and their documentation, it ends up being easier to rewrite my own FS. I have finished the design of disk structures, and I'm now writing the PC tool to access it while SyX does the CPC ROM.
Once done, i will probably add the HxC "Direct Access" layer to this new mass storage driver.
;)
Nice ! So I don't have to do it ;)
I want one, too!!! :D
Quote from: Jeff_HxC2001 on 09:17, 06 May 12
Once done, i will probably add the HxC "Direct Access" layer to this new mass storage driver.
;)
Ohhh seeing what the ST HDD mode looks like, I approve :)
I'm also very interested.
I like that it is using the printer port as I do not use this port.
I always have a ROM board & external floppy plugged in, so nice to not clutter those ports and use a previously unused port :)
Cheers,
Shane
hello Pulkomand,
The reason why a version of the HDOS rom does nothing was simply to show an initial version of what could be developed.
The latest version does have all the RSX's working (and the ROM has to be purchased). The device driver is free, so if you want the latest just contact me.
As for the drivers, I cant see how the drivers source does not explain to developers "how" to create a driver. I saw the whole source for a given device simple as it can be, but if you need some "HELP" then dont hesitate to contact me for more info/help on this matter. My current device driver ROM has the ethernet drivers in it and the TCP/IP packet management.
I would also like to add that FutureOS, Symbos, etc are all specific "Programs" which means they may not work with existing basic programs or existing disc software. HDOS with its driver development and potential to emulate floppy disks on a device, means that existing software can be used with the benefit of speed coming from the new device. I am not saying that HDOS is better then anything else, but i am just saying that any existing s/w like RODOS were created when the only big storage device attachable was floppy and that any new device would require RODOS to be modified (and the source for RODOS and so on may not be available). I also understand from what I have seen on CPCWiki, that there is no independent device driver DOS existing apart from HDOS.
The requirement of so many RSX's in the HDOS was so that the system can be setup to operate with a new device, rather than trying to determine which device the user wishes to use. The use of a hardwired device would have been possible but any changes to the desired device would be impossible as it would be in ROM and hence fixed forever, so i choose to let the user decide which device to use. This may change if a memory backed memory module were created to allow configurations to exist between power on/off switching.
rpalmer
Well, I use a ramcard for my roms so changing the ROM when I need another device is no problem for me.
I have already disassembled part of RODOS to try to understand how it works, so source unavailability is not a problem for me.
On the other hand, I'm not willing to buy your ROM before I could even test anything. Sorry !
I don't think a device driver has to be so complicated. We need to read and write sectors, and get device capacity. Can't think of anything else. RODOS is almost there, but writing my own system is a bit more fun :)
Hi Pulko, I'm looking forward to your implementation. Do you use a special format for the SD card. I like to support it too.
Quote from: PulkoMandy on 10:28, 06 May 12
Nice ! So I don't have to do it ;)
One thing to keep in mind : keep the possibility to have an MBR sector on the sdcard : By this way you can have an FAT32 partition + your FS on the same sdcard ;)
Why not handling FAT on the SD Card for CPC too ?
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. Or, you could use R-DOS as already mentionned, I heard support for FAT is at least planned ? (don't know it too well).
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
It's all open source anyway, so I hope people will take care of writing their own software for it.
Quote from: PulkoMandy on 17:55, 08 May 12
... Or, you could use R-DOS as already mentionned, I heard support for FAT is at least planned ?...
Offtopic: What's R-DOS???
The R-DOS I do know is the DOS-enhancement ROM for the RAM drive from Dobbertin providing a 444 KB RAM disc C under BASIC, CP/M 2.2 and CP/M Plus (dk'tronics compatible).
Oops. I'm mixing them all up now.
I meant HDOS here.
We are using R-DOS and RODOS as sources of ideas on how to do things. I was planning to add support for the SD card to RODOS directly (the user manual seemed to imply it was just about providing the code to read and write sectors), but it turns out that it also needs a lot of patching in the code of RODOS itself : all commands withe extra drive numbers are rejected by RODOS... And I don't like the on disk structures, and, I think it uses too much RAM :)
Our filesystem is making some progress. For now I do a version in C/C++ for PC, it is easier to prototype and design the disk structures. I have the simplest operations in place (reading and writing on a non-fragmented device). I need to add directories support and removing files (which will create some fragmentation, needs some more support). Then, we port everything to z80 assembly code and put it in the ROM.
Actually RDOS can be patched here, instead of a RAM disc you would have an SD-disc. But it's just one idea.
Accessing an SD card through a parallel port, just because - Hack a Day (http://hackaday.com/2012/05/13/accessing-an-sd-card-through-a-parallel-port-just-because/)
ELECTRONICS - THE KING OF HOBBIES!: An attempt to mount an SD/MMC connected at parallel port of PC (a linux device driver) (http://blog.vinu.co.in/2012/05/attempt-to-mount-sdmmc-connected-at.html)
This look familiar?
Quote from: Badstarr on 05:24, 14 May 12
Accessing an SD card through a parallel port, just because - Hack a Day (http://hackaday.com/2012/05/13/accessing-an-sd-card-through-a-parallel-port-just-because/)
ELECTRONICS - THE KING OF HOBBIES!: An attempt to mount an SD/MMC connected at parallel port of PC (a linux device driver) (http://blog.vinu.co.in/2012/05/attempt-to-mount-sdmmc-connected-at.html)
This look familiar?
Like this (2009) :
The Dreamcast Junkyard: A Dreamcast SD Card Adaptor! (http://the-dreamcast-junkyard.blogspot.fr/2009/03/dreamcast-sd-card-adaptor.html)
SD Card Адаптор для Dreamcast Serial / Hardware / DC-SWAT - Сайт (http://www.dc-swat.ru/blog/hardware/14.html)
I'm stil lwondering why no one tried it on CPC before.
Actually I worked from a version for the Thomson MO5. It seems very easy to make this work on other computers as well.
Quote from: PulkoMandy on 17:19, 14 May 12
I'm stil lwondering why no one tried it on CPC before.
Maybe it's the limited speed.
Well, it's still quite ok. Since there is no speed up delay and seek time (unlike floppies), I think it *feels* about as fast.
But I still have to try it in filesystem mode, loading a 16K picture from the first sectors isn't a good test :)
BTW, the code for the filesystem is coming along. I have the basic file operations working on PC (catalog, read and write files). I still have some work to do on these (handle fragmentation, directories, and more than 32 entries per user). Meanwhile, SyX is working on the expansion ROM. He has the logic to interface with AMSDOS done (overriding RSX, reserving memory, and so on), now we need to convert the FS code to z80 and see how it goes.
Quotethrough the printer port
so we should forget our digiblaster ? :'(
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.
Therefore these bigboxes, printer-switches do exist. I already use two(!) of them at the same time (sic).
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... ;D
(which all of you purists wouldn't like...)
Also, would the printer port need to be upgraded into 8bit ?
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... :D
Quote from: MacDeath on 03:37, 15 May 12
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... ;D
(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.
Quote from: PulkoMandy on 17:19, 14 May 12
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...
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.
QuoteFunny 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... ;D
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.
...would it possible to use the SD like a normal 3" Floppy in case of a disc loader system (trackmo)?
@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.
Quote from: hal 6128 on 15:06, 15 May 12...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??? :P
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.
Quote from: Octoate on 10:32, 15 May 12
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.
Quote from: TFM/FS on 17:25, 15 May 12
But if somebody can do a PC program to fill the card, ...
PulkoMandy is working in it and is working great ;)
Cool! I must have overread that one!! That's very good news.
Quote from: PulkoMandy on 17:55, 08 May 12
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).
Quote from: joska on 20:21, 15 May 12
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.
@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 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.
:)
Quote from: TFM/FS on 17:25, 15 May 12
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...
Quote from: Bryce on 08:28, 15 May 12
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.
Quote from: TFM/FS on 21:33, 15 May 12
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.
Quote from: SyX on 21:54, 15 May 12
@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.
Quote from: SyX on 18:49, 15 May 12
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.
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.
Quote from: arnoldemu on 09:37, 16 May 12
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:
QuoteFAT 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.
Quote from: arnoldemu on 09:37, 16 May 12
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 :D 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.
Quote from: arnoldemu on 09:37, 16 May 12Hmm 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. :)
Quote from: TotO on 15:59, 16 May 12
It will be great to support FAT16.
- Faster than FAT32 on CPC
For which reason is FAT16 faster?
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)
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 :)
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.
Quote from: TFM/FS on 19:18, 16 May 12Well, 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? :)
Quote from: PulkoMandy on 19:31, 16 May 12Using 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!
If there is interrest for CP/M Plus support I may can help, have to search the CPCs source codes in Munich...
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 !
Quote from: TotO on 20:30, 16 May 12
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 :)
One other example of FAT32 on CPC :
SourceForge.net Repository - [hxcfloppyemu] Index of (http://hxcfloppyemu.svn.sourceforge.net/viewvc/hxcfloppyemu/HxCFloppyEmulator/HxCFloppyEmulator_file_selector/HxCFloppyEmulator_file_selector_AmstradCPC/trunk/)
Can access / read / write (without changing its size) files on root and subdirectories.
Quote from: Jeff_HxC2001 on 22:47, 16 May 12
One other example of FAT32 on CPC :
SourceForge.net Repository - [hxcfloppyemu] Index of (http://hxcfloppyemu.svn.sourceforge.net/viewvc/hxcfloppyemu/HxCFloppyEmulator/HxCFloppyEmulator_file_selector/HxCFloppyEmulator_file_selector_AmstradCPC/trunk/)
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.
Quote from: PulkoMandy on 22:18, 16 May 12
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.
I so want this that I would love to beta test it and give it a run for its money
Quote from: morcar on 18:19, 28 May 12
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 (http://www.ebay.co.uk/itm/SD-Card-Module-Slot-Socket-Reader-For-Arduino-ARM-MCU-Read-And-Write-K-/190709344383?pt=UK_Computing_Other_Computing_Networking&hash=item2c6729a87f)
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? ;)
?? 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 :D
Bryce.
Quote from: Bryce on 19:09, 08 October 12
?? 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 :D
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. ;D
I am now asking for the wheels and a key then I will be speeding down the road :laugh:
Ok, it will work, but it's an aweful lot of software work and would be seriously slow.
Bryce.
Quote from: arnoldemu on 18:48, 08 October 12
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 (http://www.ebay.co.uk/itm/SD-Card-Module-Slot-Socket-Reader-For-Arduino-ARM-MCU-Read-And-Write-K-/190709344383?pt=UK_Computing_Other_Computing_Networking&hash=item2c6729a87f)
Looks nice!!! :)
Quote from: arnoldemu on 18:48, 08 October 12
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).
Quote from: arnoldemu on 18:48, 08 October 12
@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.