Creating relocatable CIO handler?

[tschak909]

Can somebody do a chalk-talk with me on a new CIO handler? in particular how to make it properly relocatable against MEMLO similar to the 850 handler?

 

I'm reaching the point where I need to start sketching out CIO functions for the R: and N: devices for the #FujiNet device.

 

-Thom

[phaeron]

You need to figure out the bootstrap mechanism, and then the actual handler relocation.

 

If you are targeting an 850-compatible bootstrap, there are two stages. The type-1/2 poll command returns a 12-byte SIO DCB which is then used to load the first stage to $0500, which is then started at $0506. This then loads and relocates the handler. DOS 2 AUTORUN.SYS hardcodes the $0500/0506 addresses and some communication programs also hardcode the $21 command and $0156 byte length of the loader/relocator.

 

Making the relocatable handler depends largely on how fine-grained of relocation you want and whether your assembler supports generating relocatable code. MADS's mode to generate relocatable code is really buggy and not recommended, so you're better off rolling your own with that assembler. CA65 should be better at this if you can adapt the binary format.

 

Page-aligned relocation is the easiest as you simply need to add the page offset to all high address bytes. The relocatable binary can be generated from a non-relocating assembler by assembling twice at different base addresses and differencing the results, which are then typically RLE encoded to produce the relocation table. Relocating to byte addresses is more difficult as it needs more relocation types. A SpartaDOS type system that only supports word relocations is simpler, but requires some less efficient workarounds in the handler code for places that would normally load low/high bytes. Supporting low/high byte relocation requires a more complex relocator and relocation table generation, particularly high byte relocations as they need the low byte as a reference. Altirra's replacement 850 handler does this and it requires differencing four assemblies to generate the tables (normal, low byte changed, high byte changed, low byte for high byte). If you're aiming for a high-performance handler, this is worth the effort as it makes it easier to use self-modifying code to work around the lack of ZP space.

 

[tschak909]

I suspect this may be a bit beyond my abilities, but, will take a crack at it.

-Thom

[Alfred]

The file SIMPLEREL.ACT is a program to create a high byte relocater that was used in the BASIC XE extensions file. Worth a look to get an idea.

[flashjazzcat]

I wrote a relocatable DS1305 RTC driver for SpartaDOS 3.x some months back, source code included:

This could be adapted for any other purpose, isn't tied to page boundaries, and does not depend on properties of the host DOS.

 

MADS has two relocatable formats: SDX and proprietary (the latter is used by my GOS), but neither is particularly relevant to writing a general purpose relocatable driver since the executable would need to have a fixup module built into it which would likely result in a more complex and bulky solution than just using a simple relocator such as that found in the above example. The proprietary MADS relocatable format wasn't really intended for 'external' use at all as far as I can tell; it's really designed to be used with the MADS linker, which produces non-relocatable standard binaries from C-like relocatable modules with fixup tables and symbolic references. I ended up writing a symbolic linking loader for the format purely because I didn't want to use the SDX format and there was nothing better available (and the MADS format is far from ideal since you can only have a single code block type per relocatable binary).

 

The SDX relocatable format is of course highly relevant if you want to port the drivers to SDX, and doing so would allow you to refer to your devices from the CLI using kernel device names ('NETn:' for Network 1, etc). I'd actually suggest focusing entirely on SDX since trying to install large drivers with other disk operating systems without consuming large amounts of base RAM such that MEMLO becomes unusably high can be a tricky exercise (you'd probably end up having to install driver code in extended memory and invent your own dispatch mechanism). SDX makes ample provision for all of this and allows for three different segment types in the same executable: absolute, relocatable block in main memory, and relocatable block in the extended bank. This is how SIDE.SYS - which has a 2.5K footprint or so - only raises MEMLO by about four pages.

 

The other solution - and probably the best overall - is to create a PBI/ECI device which works with any DOS and doesn't take up any system memory at all (it would have its own ROM and RAM). SDX kernel device name references could probably be accomplished with a little fiddling around (i.e. to get access to PBI-hosted CIO devices from the CLI using SDX kernel names). Of course the hardware then becomes somewhat more complex.

Edited November 18, 2019 by flashjazzcat