Modern storage options?

[GroovyBee]

I'm looking to get a Dragon 32/64 at some point in the near future and I was wondering what the modern storage options are. What has replaced the original floppy drive system? Is there a modern MMC/SD solution? I haven't found anything Dragon specific so I'm assuming that there is a Coco-1 solution that works. Thanks for any help.

[sixxie]

Nothing that I know of.

coco3.com offer a Micro SD based system, but the ROM in it will certainly need a rewrite for the Dragon (also, he's based in America).

[zephyr]

You may also find something suitable (with a slight modification?) at Cloud-9.

http://www.cloud9tech.com/

[GroovyBee]

Thanks for the information. What about the software to drive them on the Dragon? I might just have to design my own hardware. Its a long time since I've done any 6809 coding tho. That was one of the reasons I wanted a Dragon . If such a device was made available would anybody else be interested in one?

[sixxie]

I should coco! (I'll get me coat)

Would you be looking to make something that worked with disk images on a FAT filesystem, or that sliced the flash up in a direct fashion?

I could probably help out patching up a DragonDOS ROM to work with whatever you came up with

[GroovyBee]

I can see 2 solutions :-

1) Full FAT16/32 support. Files would be seen by the Dragon as if they were stored natively e.g. you would copy "FRED.BAS" onto the memory card on the PC and the Dragon would aslo be able to read "FRED.BAS". I'm not sure if this would work on legacy Dragon apps because they'll only expect 80 tracks at maximum. This could potentailly waste lots of your MMC/SD space if this is the case. You'd also lose half the card's capacity anyway because the Dragon sector size is only 256 bytes. I'm not sure what happens within OS9. Can it support large capacity drives with a suitable driver?

2) Mount Dragon disk images. The MMC/SD would contain one or more Dragon disk images. A bootloader app would be loaded on reset that would allow you to select which image would be mounted as a drive number (0 to 3, 1 to 4 whatever it is). For example the imaginary game image called "PITFALL.DSK" could be mounted as drive 2 and "FISH.DSK" could be mounted as drive 1. The dragon would then treat those images as RAW data. Effectively it would be a file system within a file system. This means that Windows/MAC/Linux is responsible for the real FAT structure e.g. reading, writing, formating, creating directories etc. The Dragon is then only allowed to write/read/format within the confines of the file mounted for its drive. In all cases the memory cards real FAT is only ever read. This should protect the FAT structure from being corrupted by the Dragon. I'm not sure if that came across clearly . I'll give a little example :-

For a Double Sided, 80 track, 18 sector image would be :-

= 80 x 18 x 256 bytes
= 368640 bytes

On MMC/SD it would actually be a file of 737280 bytes (each 256 byte Dragon sector would map to a 512 byte FAT sector). The first 256 bytes of the file would contain the Dragon's standard DIRECTORY TRACK e.g. free sector bitmap, sectors, tracks etc. At 512*3 bytes into the file it would contain the DIRECTORY ENTRIES for the disk.

What do you think is best?

[Alastair]

There's an article on pages 12 and 13 of the August 1988 issue of Dragon User that may be of some interest: it deals with OS-9 and hard drives.

In the unlikely event that you do not possess a copy of this issue you should download "DragonUser_0888.pdf" from
http://archive.worldofdragon.org/archiv ... User/1988/

[GroovyBee]

There's an article on pages 12 and 13 of the August 1988 issue of Dragon User that may be of some interest: it deals with OS-9 and hard drives.

Thanks for that. At least its possible to create a driver for OS9 . I wonder if the "crashes" that the author reported were down to the driver or the technology of the day?

[sixxie]

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.

I guess really I'd want both - no pressure, now

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.

Or a simpler alternative, that might get you results quicker:

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).

Yikes, wall of text! And all from someone with no real hardware experience! (So feel free to point out any bits that would be really hard to do ).

[GroovyBee]

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 .