xXDOS (=extended XDOS) - work in progress
Posted: Sat Jun 13, 2020 3:46 pm
Hi folks,
I thought it about time to come clean on how I'm spending my newly found quality time with my Einstens. (Only 2 - unlike some show-offs whom I won't name):
For a start, I'm still doing some native development on Einstein, as opposed to using emulation and cross-tools on the PC. Having said that, the limited capacity of Einstein's 3" disks is annoying me more and more; I must have been more patient in my younger days.
I am still using my trusty ZEN assembler/editor for assembly code development. I have tweaked its read and write routines so that I can read source files (and write assembly output list files) via the serial port. I currently do this using 'minicom' so it involves a lot of dashing from chair to chair....
... but I am in the process of taking this to the next level , which is where xXDOS comes in.
'xXDOS' is made by patching extra functionality into the spare room near the start of XDOS (etc.) image that gets loaded at start-up. Currently it takes up
0xe168 to 0xE203 but it's likely to grow a little.
With this extension in place, XDOS calls are routed through a filter. This filter intercepts disk-drive related calls which specify a drive number of 4 or greater (5 or greater in CP/M speak!) to an external server via the RS232C port. The server handles the data transfer to/from PC-based files and answers with a return code.
I already have a reasonable working prototype which handles open. create read and write sequential etc. .. but not yet everything. It works well with ZEN but does not yet work transparently with e.g. Einstein's COPY.COM. Now I need to investigate whether I can fix this by intercepting yet more XDOS calls - or whether there is something sneaky in COPY.COM that bypasses the XDOS mechanism and 'demands' a physical drive number.
Your constructive comments will be appreciated.
Larry Myerscough (aka papahippo)
I thought it about time to come clean on how I'm spending my newly found quality time with my Einstens. (Only 2 - unlike some show-offs whom I won't name):
For a start, I'm still doing some native development on Einstein, as opposed to using emulation and cross-tools on the PC. Having said that, the limited capacity of Einstein's 3" disks is annoying me more and more; I must have been more patient in my younger days.
I am still using my trusty ZEN assembler/editor for assembly code development. I have tweaked its read and write routines so that I can read source files (and write assembly output list files) via the serial port. I currently do this using 'minicom' so it involves a lot of dashing from chair to chair....
... but I am in the process of taking this to the next level , which is where xXDOS comes in.
'xXDOS' is made by patching extra functionality into the spare room near the start of XDOS (etc.) image that gets loaded at start-up. Currently it takes up
0xe168 to 0xE203 but it's likely to grow a little.
With this extension in place, XDOS calls are routed through a filter. This filter intercepts disk-drive related calls which specify a drive number of 4 or greater (5 or greater in CP/M speak!) to an external server via the RS232C port. The server handles the data transfer to/from PC-based files and answers with a return code.
I already have a reasonable working prototype which handles open. create read and write sequential etc. .. but not yet everything. It works well with ZEN but does not yet work transparently with e.g. Einstein's COPY.COM. Now I need to investigate whether I can fix this by intercepting yet more XDOS calls - or whether there is something sneaky in COPY.COM that bypasses the XDOS mechanism and 'demands' a physical drive number.
Your constructive comments will be appreciated.
Larry Myerscough (aka papahippo)