xXDOS (=extended XDOS) - work in progress

Software discussion & Emulation
Post Reply
papahippo
Posts: 14
Joined: Tue May 12, 2020 12:03 pm

xXDOS (=extended XDOS) - work in progress

Post by papahippo » 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)

papahippo
Posts: 14
Joined: Tue May 12, 2020 12:03 pm

XDOS versions [Re: xXDOS (=extended XDOS) - work in progress]

Post by papahippo » Sun Jun 14, 2020 1:24 pm

A quick question if I may.

Is anyone using an XDOS version other than 1.11 and 1.31? if so, could you go into MOS and check that the locations E168 through E2FF all contain FF?
This is so I can safely use that region for my (x)XDOS extension code.

Thanks,
Larry

Lardo Boffin
Posts: 296
Joined: Thu Oct 24, 2019 11:47 am

Re: XDOS versions [Re: xXDOS (=extended XDOS) - work in progress]

Post by Lardo Boffin » Wed Dec 30, 2020 9:11 am

papahippo wrote:
Sun Jun 14, 2020 1:24 pm
A quick question if I may.

Is anyone using an XDOS version other than 1.11 and 1.31? if so, could you go into MOS and check that the locations E168 through E2FF all contain FF?
This is so I can safely use that region for my (x)XDOS extension code.

Thanks,
Larry
I don’t have any versions other than that. I would suggest going for it - given the small user base people can adapt.
TC-01 + einSDein + TM-01 + TK-02 + gotek

retrogamer
Posts: 76
Joined: Tue Jun 01, 2021 12:00 am

Re: xXDOS (=extended XDOS) - work in progress

Post by retrogamer » Wed Jun 16, 2021 11:50 pm

Yes, XtalDOS 1.31 (1984) has FF from E168 to E2FF.

However, XtalDOS 2.05 (System 5 Plus - 1987) has FF from E168 to E1FF, but there's code from E200 upwards!

Similarly, DOS80 V1.0 (System 80 - 1986) also has code in that region. There's a C9 (RET) in E168, FF from E169 upwards, and code from E200.

So the xXDOS patch might need to be relocated for later DOS versions.

I too have been looking for a way to overcome the limited capacity of single-sided 40 track 3" discs. I'll post details if I successfully configure my Gotek on drive 1 to use 800k with a double-sided 80 track format!

Richard

Post Reply