The HxC floppy emulator manager by NoRecess (a CPC program for selecting which disk image to load into the emulator) must use it.
Ah, yes, now I remember it!
CPCSD is nice because it is very simple and should cost <10Euro/£.
The price is a good argument indeed. It's probably slower, as the transfer should be bit-based instead of byte-based like the FDC does.
The HxC is nice because the driver required should be quite small as it does most of the work for you 
!
Yes, because the FDC routines, which are still required, are already existing
(a stand-alone HXC SD card driver would be probably larger than a CPCSD driver, as the FDC routines are more complex)
HxC support would not only be for the CPC, as it should work with basically anything with a floppy interface (so MsX and PCW too).
I didn't had the PCW in mind! That would be so cool to have a PCW with such a mass storage, too! Great idea
Regarding the MSX: I never heard about an MSX user using an HxC. They have tons of fast, good and DOS compatible mass storage devices (including drivers to mount DSK images), so that a HxC is not needed here (and they are quite proud about this fact
).
1. Is it possible for users to write device drivers for SymbOS, or do you need the full source code?
Currently this is only possible on the MSX. Here it was absolutely necessary, as there are so many different FDC types and IDE/SD card/SCSI mass storage devices.
The reasons why the drivers are currently hardcoded in the CPC version are these:
- all CPCs have the same FDC; during the last years the SYMBiFACE II was the only available and quite actual hardware with a mass storage interface (IDE), where some 100 pieces were produced. So IMHO it was ok only to support these two device types (FDC+IDE)
- a dynamic driver model like on the MSX requires more memory; due to bank switching reasons the driver code has to be placed in the first 64K; this is the most narrow and valuable memory area for the core part of SymbOS; but especially on the CPC the memory is quite limited here, as it also contains the 16K screen (the MSX has its own dedicated video ram)
- SymbOS should be bootable directly from "harddisc" by using the rom version without the need of a floppy disc, so that it's available within a few seconds. But that means, the driver must already be there and can't be loaded during booting (as then Amsdos would be required, which can't access the "harddisc"). On the MSX it's not a problem as MSX-DOS runs fine with FAT-harddiscs and can be used for booting. There could be probably a solution for the CPC, too, but it's more difficult and until today I didn't see an important reason for having dynamic drivers.
2. Is there a technical reason why SymbOS can't launch normal AMSDOS programs? Obviously it would nuke SymbOS because all the RAM would be taken over, and you would need to make sure the programs can make ROM calls so it would have to set everything back to "reset" state first, but is this very hard? It would be really neat to be able to do this (particularly if you can load DSK images into the HxC).
Are you speaking about...
- launching programs from the (emulated) floppy disc: This would require a controlled reset of the CPC and to send the string RUN"filename"[+return] to the keyboard buffer; that would be a stupid but probably simple and working program starter
Maybe it's possible to install a sniffer, which checks for a special key combination. SymbOS is copied into higher ram and loaded back, as soon as the user is pressing the key combination (and the program doesn't kill or reset the CPC OS).
- launching programs from a FAT partition: This would be only possible, if loading additional parts isn't required later and the whole program is stored in one BIN. Something like this can be already done by using SNApshot files.
3. Have you thought about a suspend/resume function where you copy all the RAM contents and current state to disk for resuming where you left off later? You could even copy it into higher RAM if you have enough spare, then if you ran an AMSDOS program you could use e.g. a multiface to resume symbos later by restoring the RAM contents, or autoboot from the saved RAM image on reset.
Similiar to the first suggestion in 2.) . Well, yes, I thought about this several times. The most interesting part is, how to make a controlled reset of the CPC, so that some "exit"-code remains somewhere in Ram (below the stack probably). A "suspend to harddisc" would be fine, too. It's a little bit tricky. Because of the multitasking environment you have to freeze some parts first, before writing the dump into a file.
CU,
Prodatron
