[Coco] DW3 WireBug mode

[Aaron Wolfe]

On Thu, Jul 4, 2013 at 4:14 PM, Tormod Volden <lists.tormod at gmail.com> wrote:
> On Thu, Jul 4, 2013 at 5:14 AM, Robert Gault wrote:
>> Mark Marlette wrote:
>>> This would require that HDB-DOS go to 16K, as I recall there was about 8
>>> bytes left free in the current version.
>>>
>>> There are reason why Boisy never broke the 16K barrier, which of course he
>>> knew how to do in a heartbeat. I just don't know them ATM.
>>>
>>> So unless the code is compact or something is removed.......not a lot of
>>> space left.
>>
>> There is a small amount of space that could be used for extra routines if we
>> were willing to give up the FlexiKey code. Probably it would not free up
>> enough space though.
>>
>> Using a 16K ROM is not that difficult and ADOS3 is an example. It certainly
>> would take very careful coding on a Coco3 since Basic code resides in the
>> second 8K.
>
> If keeping it to 8K has some merit: For a DW-only version one could
> sacrifice the real floppy disk support, I think that would free up 365
> bytes (the original DSKCON routine). Still not a lot and I don't know
> how much WireBug would need. However it would be plenty for adding
> some extra RAM hooks. Then a small wirebug server could be loaded into
> RAM when needed and hooked up. The sacrificed floppy disk support
> could also be loaded into RAM for the odd occasion.
>

Some time ago I added support for "named objects" to the DriveWire
protocol.  These are just binary blobs that can be referred to by an
arbitrary name.  They can correspond to content on a drive or embedded
in the server or really anything, the source is purposely left
undefined.  All the coco needs to know is the name of the blob it
wants and the server will provide it.

Using this mechanism, we could easily embed a number of overlays/rom
sections/etc into the server and allow a coco to request them as
needed.  These could be the Wirebug code or code for accessing
different hardware.  The time to load a few KB of data over drivewire
is minimal.  I could imagine a disk copy routine that loaded the
SuperIDE i/o code via named object, read a buffer full of sectors,
loaded the FDD code over DW, wrote out the buffer, and so on.  The
overhead to "swap" different I/O routines on top of each other as
needed would not be terribly bad.

Perhaps using some smart organization and a collection of blobs we
could stay in 8k and still extend the functionality of HDBDOS as
desired?