fujinet Atari DOS 2.5, moving DUP further up by about $200 bytes?

[tschak909]

We now have, thanks to AtariAge users, a buildable version of Atari DOS 2.5, which can be built with MAC/65 to produce a usable disk image. I'm curious, as to whether we can move the non-resident part of DUP further up in memory by about 512 bytes or so, so that my #FujiNet N: driver can exist and function under DUP, without being clobbered?

 

I know it's possible, but I'm not seeing immediately the equates to change to re-assemble to the new location?

 

-Thom

[tschak909]

@ndary @ivop @Urchlay @bob1200xl any insight?

 

-Thom

 

[Rybags]

I think you could, but you'll likely have the situation where any "growth" of the resident portion, ie adding extra file buffers or drives, will clobber your handler.

But nothing stopping you configuring for what you regard as a necessary configuration and using that.  In most cases 2 drives, 3 files is plenty.

 

Another thing to note is there's config bits and bytes that are in known Page 7 locations.

Something to consider though is if DUP makes direct calls anywhere to the resident portion, in which case you'd need to reassemble it as well.

[thorfdbg]

12 hours ago, tschak909 said:

@ndary @ivop @Urchlay @bob1200xl any insight?

 

-Thom

 

You probably not only need a new DUP.SYS, but also a new DOS.SYS as creating the MEM.SAV is part of the DOS portion, and this now needs to save another memory area.

 

Frankly, I would argue against this approach. It is fragile and will break if the user does not use your modfied DOS - which some won't.

[tschak909]

I'm trying to offer a solution, especially since there IS source code to DOS 2.5. (and arguably DOS 2.0S)

 

Once I get the binary loader into the N: device, it will be functionally complete, I just have to tackle relocation there... but I really wanted to make something that could be used in the DUP, because it REALLY is a usable device, I am both copying and loading files from the network seamlessly with it, and getting it to run on DOS 2 will require either:

 

* Shrinking it down to fit in the gnats arse of space between the FMS and non-resident DUP (shrink it to a rough target of 512 bytes)

* Somehow moving DUP to keep from clobbering things, OR

* tacking the N: device onto the end of DUP and fudging HATABS while DUP is running.

 

Seriously, N: works _EVERYWHERE_ except the DUP in DOS 2, and this makes my brain itch. Atari did a good job with CIO, only to be let down by something as dumb as this. There has to be a workable solution.

 

-Thom

[thorfdbg]

22 hours ago, tschak909 said:

I'm trying to offer a solution, especially since there IS source code to DOS 2.5. (and arguably DOS 2.0S)

 

Seriously, N: works _EVERYWHERE_ except the DUP in DOS 2, and this makes my brain itch. Atari did a good job with CIO, only to be let down by something as dumb as this. There has to be a workable solution.

Look, if you already require users to run a custom DOS, why not let them run a more useful custom DOS to begin with?

[tschak909]

@thorfdbg I don't require it. This is only an issue with using DUP in DOS 2. I'm just trying to smooth over some bumps. sigh.

 

Am trying to demonstrate the power of hooking up the network transparency possible in #FujiNet to the Atari CIO. Have you not been following the videos I've been posting? 

 

I've shown this running under:

 

* DOS XL / OS/A+ 2

* MyDOS

* SpartaDOS

* XDOS

* LiteDOS

* Atari DOS 3

* Turbo DOS XE

 

-Thom

[+DjayBee]

Why don't you steal some memory from the space allocated for sector buffers?

• Boot DOS (should work with 2.0 and 2.5).
• Add $200 to the value in $70C.
• Write DOS to a new disk.

It does not really steal the memory, but forces DOS to allocate its buffers $200 bytes higher in RAM.

 

When your handler loads, it reads the address from $70C, subtracts $200 from it and relocates to this address.

 

Unless the to-be loaded binary file collides with the $200 bytes bigger FMS, this should work with everything.

 

Update 1:

When I tested this right now, the allocated bytes got added to the saved DOS.SYS. This way it probably would be possible to add your handler permanently to a DOS.SYS.

You only would need to find a way to initialize it during boot.

 

Update 2:

Steal the DOSINI from $704 and route it through your handler's init routine.

Since the handler's code is embedded into DUP.SYS, it will always be there.

Edited May 27, 2020 by DjayBee

[tschak909]

holy shit! those approaches just might work!

 

-Thom

[tschak909]

Yup, that worked!

-Thom

[+DjayBee]

If you also steal DOSINI then you must take care of DUP. It overwrites DOSINI always with $1540.

 

DOSINI is restored by DUP when you exit to cartridge via "B", but not when doing a binary load.

 

If you press RESET after running DUP, your handler is disabled.

[tschak909]

what opportunity can I take to re-vector back to my DOSINI?

 

-Thom

[+DjayBee]

Unfortunately I am not an expert in the OS, particularly not in how you can influence what is happening after RESET.

 

But I am sure that one of the experts will chime in soon.

 

Since you only need to handle DOS 2.0 and 2.5, you could leave DOSINI alone and patch $1540.
Both versions share the code from $1540-$1544.

 

JSR <your-init>

NOP

NOP

 

and end your init-code with

 

LDA #0

STA $159E

RTS

 

 

[tschak909]

I _REALLY_ want to yell at the sky for the CIO INIT vector not being usable (because HATABS gets wiped and re-set too early in the warm reset process).

 

-Thom

Edited May 27, 2020 by tschak909

[tschak909]

darn, turns out this approach won't work, I made a fundamental calculation error and raised the DOS buffers WAY too high (I noticed that DOS.SYS was 237 sectors long). whoops.

 

Looks like I will have to make a version that loads into memhi for dup. urgh.

 

Current n-handler here: n-handler.atr

 

Current source here:

https://github.com/FujiNetWIFI/atariwifi/blob/master/n-handler/handler/src/ndev.s

 

It was so nice though, I was binary loading stuff and copying stuff both to and from N: devices in DUP. it was beautiful! ?

-Thom

 

 

[+DjayBee]

Hmmm, the bigger the handler, the more programs will not work with it because their needed memory will overlap with the handler's.

[tschak909]

def need help crunching this handler down...

 

-Thom

[Alfred]

1 hour ago, tschak909 said:

I _REALLY_ want to yell at the sky for the CIO INIT vector not being usable (because HATABS gets wiped and re-set too early in the warm reset process).

 

-Thom

Don't think that's the problem. Warmstart processing calls the INIT vector for the ROM device table only. It does not walk the table, so any added handlers would not have their INIT functions invoked. At least not in the version of the XL OS I'm looking at.

[Alfred]

7 hours ago, tschak909 said:

what opportunity can I take to re-vector back to my DOSINI?

 

-Thom

Looking at the XL OS listing, it appears you might be able to trap CASINI. A mask of $02 in BOOTQ($09) will cause the OS to invoke CASINI during warmstart processing. DOSINI will be invoked later. I've looked at the sequence a couple of times now, I think it should work. Just have your installer code do something like:

 

LDA $09

ORA #$02

STA $09

 

and you ought to be able trap CASINI ($02/$03) during subsequent reset. I think the chances of running into a legitimate cassette loaded program using your N: are pretty remote. Interestingly, cartridges cannot prevent cassette booting or re-initialization. They can only control the disk drive.

[+DjayBee]

23 hours ago, tschak909 said:

Current source here

49 bytes less - therefore below $300 (DIFF for comparison)

 

ndev.asm

 

... but IMHO still too big.

Edited May 28, 2020 by DjayBee

[tschak909]

@DjayBee if the init code is moved to another out of the way segment, that peels away 160 bytes or so...

 

-Thom

 

[+DjayBee]

But where to?

 

How about overlaying init and handler?

 

Keep only a stub of init resident which does a call to SIO and loads the real init code into the handler's program area from the FujiNet.

After initializiation reuse the stub to read the (now overlayed) handler's code from the FujiNet and overwrite the no longer needed init code..

 

Edit:

- Why do you alter MEMLO twice during init (10 bytes)?

- Why do you save DOSINI to DSAV (8 bytes)? It is nowhere used.

 

Another 11 bytes saved: ndev.asm (length $2EA bytes without buffers)

Edited May 28, 2020 by DjayBee

[tschak909]

55 minutes ago, DjayBee said:

But where to?

 

How about overlaying init and handler?

 

Keep only a stub of init resident which does a call to SIO and loads the real init code into the handler's program area from the FujiNet.

After initializiation reuse the stub to read the (now overlayed) handler's code from the FujiNet and overwrite the no longer needed init code..

 

Edit:

- Why do you alter MEMLO twice during init (10 bytes)?

- Why do you save DOSINI to DSAV (8 bytes)? It is nowhere used.

 

Another 11 bytes saved: ndev.asm

good points. those can be shaved.

 

-Thom

[Alfred]

1 hour ago, DjayBee said:

 

Another 11 bytes saved: ndev.asm (length $2EA bytes without buffers)

Good job. I'm waiting to see how much you can beat mine (which is $257 without the buffers) by.?

 

Really though it's going to be near impossible. You have $210 bytes available which has to include buffers. I was thinking maybe 8 byte buffers, using ASL to count the bytes, but even that I don't think will do it.

Edited May 28, 2020 by Alfred

[+DjayBee]

@tschak909

- Do your buffers need to be aligned to anything? Currently they are aligned to a page boundary.

- Can you work with only one buffer?

- Can the FujiNet firmware be modified to work with 64 byte "sectors" instead of 128 byte?

 

Reason for these questions:

With plain and standard DOS 2.5 there is a gap of $2A0 bytes between MEMLO and DUP.

If you reduce the supported disk drives from 2 to 1 and the number of open files from 3 to 2, you gain another $100 bytes.

This does not compute for DOS 2.0S, because it is $90 byte larger than 2.5.