The DLOAD command
Back in the eighties I was intrigued by the DLOAD BASIC command that was there in the ROM, undocumented and mysterious, but all it did was giving IO error. Later I have learned that it uses a simple protocol for loading files onto the CoCo/Dragon from another computer over a serial line. However there is not much related information or software to be found.
It turns out DLOAD is buggy or unusable on several CoCo versions. I don't know whether it works on Dragon 64 with its serial port. On the Dragon 32 the low-level drivers are missing. Since it has no serial port, there was no use for including the serial port drivers (whether using ACIA as on Dragon 64 or bit-banger as on CoCo). However, the command itself and much of its code still sits in the ROM nonetheless. Probably because it shares much code with CLOAD, and the Dragon ROM designers did not want - or did not have time - to get rid of the unused code at the risk of modifying proven, CoCo-compatible CLOAD code.
Seeing that people were able to run DriveWire on the Dragon hardware using CoCo ROMs, I started playing with DriveWire myself. I ported DWDOS (a small program for booting Nitros-9 from BASIC via DriveWire) to my Dragon 32, but without the possibility of running Nitros-9 it merely served to see that the lower-level DriveWire code (including the bit-banging code shared between DWDOS and HDB-DOS) actually worked fine with my DriveWire adapter.
Now what? Make DWDOS more flexible and make it load arbitrary files from the DriveWire server? The server only serves disk sectors, so it would
need much hacking on the server to make it serve files instead. So this led to porting HDB-DOS to the Dragon instead. However, running HDB-DOS
or any other DOS for Dragon, the Dragon itself keeps track of drives, tracks, sectors and file fragments and directories. If you principally just wants to load files into your Dragon (and faster and more convenient than the tape interface), all that means a lot of memory-eating overhead. Especially if, in lack of a cartridge, you have HDB-DOS itself sitting in RAM...
DLOAD back from the digital graveyard
Originally I was thinking of reusing the unused DLOAD command name for an extended DWDOS file loader. But after studying and disassembling the DLOAD code in the Dragon 32 ROM and realizing how complete it was, I thought it would be a fun project to see if I could hook up the DriveWire low-level drivers where the serial drivers were missing.
I searched for places in the code where new low-level drivers could be hooked up. The code properly calls the same SERIN and SEROUT vectors
as on the Dragon 64, but where the latter has low-level code to talk with the ACIA, the Dragon 32 just jumps to an RTS. And no cleverly
prepared RAM hooks for future use. The "console_in" routine is used, and calls back into the DLOAD code if DEVNUM = -3 (DLOAD/serial). So this must be intercepted. But DLOAD also calls SERIN directly many places, and anyway needs to set up DEVNUM and other things.
So I ended up copying the whole DLOAD dispatch routine. It simply needed recompiling to call my own SERIN/SEROUT/SERSET routines instead. These provide the minimal glue to use the DriveWire DWRead and DWWrite routines. And to much delight and surprise it worked! So there we have it:
Original DLOAD code missing low-level drivers + Low-level drivers from DriveWire = working DLOAD
Obviouosly it also requires a DLOAD server on the other computer. I have massaged a DLOAD server from 1997 that I found on the internets to deal with today's realities (faster server CPUs and the need for speed - 57600 baud). And to serve the file that the Dragon asks for, not only a predefined one.
Where to get the code?
The Dragon code is at https://gitorious.org/m6809-computer-tools/dload-dragon . Since I don't want to distribute Dragon ROM code (nobody seems to do?), there is a bit of convolution taken care of by the Makefile. It requires you to have your (legally acquired) ROM dump in the folder, and to have Ciaran's "6809dasm.pl" disassembler from http://www.6809.org.uk/dragon/ there too. It will disassemble the ROM and reassemble the DLOAD code part together with the DriveWire and glue code.
Also the hdbdos folder from Toolshed must be around, either copied in or soft-linked, for providing the DriveWire routines. It can be found at
http://sourceforge.net/p/toolshed/code/ ... ee/hdbdos/
The DLOAD server code is at https://gitorious.org/m6809-computer-tools/dload-server
I am running it on Linux, and a quick test on Windows did not work out (patches welcome).
How to use it?
Because the new DLOAD code loads to top of ram, start with CLEAR 200,&H7BFF. Then CLOADM the dload-dw.wav file and run EXEC to "install" the code. Now your DLOAD command is alive and kicking! Simply type DLOADM to fetch the default file from the server, or DLOADM "FILE" to load FILE from the server.
See the README file in the dload server folder for how to start the server. Note that you have to set the baud rate to 57600 baud on the serial
port before running the server. For instance:
Code: Select all
sh dload.stty /dev/ttyUSB0 stty 57600 < /dev/ttyUSB0 ./dload test4096.bin B /dev/ttyUSB0 500
The low-level drivers and glue do not take much space, and can actually fit comfortably in unused spots in the Dragon 32 ROM (oh Dragon Data why why). Especially since the whole DLOAD higher level routine can be used as-is with only the SERIN, SEROUT and SERSET (baud selection routine, replaced by bit-banger initialization) vectors readjusted.
So filling in the holes in an otherwise unmodified BASIC ROM seems only right. Maybe adding an load-and-exec command too (DLOADXM?). Anyway, for this project I would need to partner up with someone who has an EPROM programmer and is willing to test it. Please tell.
A big advantage of a ROM version is that programs can use the whole RAM. Some existing programs will maybe load to top of RAM and overwrite the DLOAD routines in RAM. Not having to run "CLEAR" first would be a bonus, although the RAM version also could be tweaked to avoid this.
Having the DriveWire low-level routines in ROM, there would still be ca 160 free bytes left. It would be cool to squeeze in DWDOS/dwdgnhdb functionality too, so that we can load for instance HDB-DOS over DriveWire directly from power-on. But it might turn out to be be too tight on ROM space. Otherwise one can always load dwdgnhdb via DLOAD then the rest via DriveWire, but it would require switching from DLOAD to DriveWire on the server, fully doable, but less elegant.
As I mentioned, the DLOAD server which I have been modifying allows simple file selection. I have plenty of ideas for extended functionality, but I think rewriting it from scratch would make sense at this point. That has to come later in autumn for what I am concerned.