sixxie wrote:I never really got into OS-9 - I tried it enough to appreciate its architecture, but pretty much everything I ever did with the Dragon demanded full control. An OS-9 only solution would be the most elegant, as an OS-9 module could provide direct access to files as though it were a hard disk, but I suspect the market in the UK would be limited (if there are loads of people on here who always booted into OS-9, please feel free to correct my blinkered view!). Of course, the market is already limited.
The market size doesn't really bother me. I also write games for the Atari 7800 and its market isn't very big. Its homebrew scene has made leaps and bounds in the last few years tho.
I guess really I'd want both - no pressure, now
Yep! a solution for both OS9 and normal Dragon users would be best.
If you start from scratch, how about a device that simply provides n handles into files on a FAT filesystem. A regular DOS cart can be patched so that instead of controlling a floppy it reads/writes to chunks of 256 bytes on file handles 0 <= n <= 3 (standard DOS drives), perhaps even have a filename that is recognised as a "default drive 1" so you can power on and type BOOT for OS-9: Then an OS-9 driver can understand that the indexes into these handles can be as large as it likes and use a large file as a hard disk. The DOS cart patches would be easy, the OS-9 module I'm not so sure of.
I'm imagining a memory mapped command register, with one of the commands being to accept a file handle number and a string of characters specifying a file on the SD to mount on that handle. Other commands read and write some specified chunk of 256 bytes within the file. You replace the "write track" routine in DOS with one that issues a command to create or extend the length of a file if necessary. A MOUNT command is added to DOS, with everything else staying the same.
The MMC/SD card needs some initialisation commands to get it into a state that you can access it. For the "magic reads/writes" (by that I mean higher than raw sector level) into the Dragon memory map to get to the MMC/SD card would require an intelligent controller on the cartridge. The controller would have to read the FAT, find the starting cluster of the file representing the drive and convert Dragon sector/track information into offsets into the file. Its not impossible but in my mind the cart should handle the donkey work.
Is there full source code (preferably commented) to an up to date DOS cart available?
You take direct control of the blocks on the SD (forget FAT), have a small "boot image" at the front that boots OS-9 along with its driver to use the rest of the SD as a hard disk. Direct access to the SD sectors is probably easier than using FAT (and in this case, yes, the 256 bytes out of every 512 would probably come into play, though that's not really a big deal).
I assume in OS9 that there is a file system that sits on top of the media driver. Any links to how the file information is stored on disk at raw sector level would be appreciated.
I think 3 solutions are needed :-
1) Standard Dragon mode - limited to double sided, 80 tracks, 18 sectors using disk images stored on the MMC/SD card.
2) Standard OS9 mode - same scenario as above
3) Expanded OS9 mode - have two partitions on the MMC/SD card. One partition contains the OS9 boot image in FAT and the second partition can be accessed using the native OS9 file system driver. However, I don't think Windows allows you to have multiple partitions on an MMC/SD card as standard. Maybe it would be better to have a small file for booting and a very large file to represent a super sized media?
I think that avoiding writing to FAT at raw sector level in all the above cases would be the best option and probably the least amount of work.
Comments?
PS: I'm itching to get a Dragon now
![Laughing :lol:](./images/smilies/icon_lol.gif)
.