Detecting DUP.SYS in memory to adjust relocation of a handler?

[tschak909]

I'm currently working on the FujiNet Atari User's Guide, and I got to NDEV.DOC, which documents loading the N: handler, and I had a particular thought:

 

Right now, NDEV.COM can't load in DOS 2.0S' DUP.SYS, because the driver is a bit too big to fit in the area between MEMLO and where DUP is loaded. MEM.SAV only helps when you jump to a cartridge, in this case, bringing the N: handler back into memory.

 

While we really can't do anything with the N: handler loaded via AUTORUN.SYS, could we potentially do a Load of NDEV while in DUP, detect if we're in DUP, and adjust the relocation to a higher memlo?

 

Yes, I know this would raise MEMLO, a bunch. But it would make file operations on N: possible from within DOS 2.0 DUP.

 

FWIW: MyDOS 4.53, nor any of the other FMS suffer from this problem (OS/A+ and DOS XL even handle NDEV just fine).

 

The other aspect would be to try and shrink NDEV's memory footprint to below DUP's load point.

 

For reference, the current N: device handler code is here:

https://github.com/FujiNetWIFI/fujinet-nhandler

 

Thoughts?

 

-Thom

[_The Doctor__]

thoughts? pursue both avenues, not either or.

[thorfdbg]

Not really. You can certainly detect when DUP.SYS is about to be loaded (DOSVEC, $0a), but that does not help you a lot because it will stomp on top of your memory anyhow, and even if you relocate yourself to the end of DUP, the DUP will use that memory to copy files or disks. Call it what you like - but the Atari DUP was not very wisely designed. For the XL systems, you may attempt to hide your code under the basic ROM or the Os ROM to get out of the way, and only have a minimal jump table in RAM. DUP is not relocatable either, that is, even if you raise MEMLO, it will ignore that and just load on top of whatever was there.

[Rybags]

Check for presence of certain data in known locations?

Though if you're not using MEM.SAV you could potentially have most of DUP.SYS present in Ram after it has been exited.

Unless there's some flag byte somewhere then it mightn't be possible.

Does DOSVEC retain the same value in a no BASIC situation whether DUP.SYS is in memory or not?

 

And all that said, what works for Dos 2.x won't necessarily be good for 3rd party Doses.