Dos 2.5 and memlo

[danwinslow]

So, I am testing some other dos's with my device handler. Dos 2.5 seems to have an issue, or, more accurately there's something I don't understand about dos 2.5. What I'm doing is loading the handler at memlo, bumping memlo up after the load to protect it. When I return from my loader program, the final RTS back to dos runs a few instructions and then does an RTS of it's own that puts me right in the middle of the handler I just loaded, at an unfortunate location that immediately causes a crash. I checked after a coldstart, and it looks to me like dos 2.5 has code at that spot ($2982), through up to about $32FF. I thought that a program was free to use memory after memlo, so I am surprised that this is causing an issue. If dos needs all that space, I would expect it to set an appropriate value for memlo. What am I missing here?

[danwinslow]

Well, ok, it seems that this is a DUP.SYS area....it ends at $3306. Why isn't memlo updated to indicate this?

 

Theory : I think it's because DOS plans on reloading this area anyway after program execution, which it's supposed to do (I think) when DOS is returned to. But, I'm messing around with DOSVEC to protect my program from warmstart and that's messing up the reload mechanism or something. I'm not sure how to protect a handler in low memory though.

Edited January 19, 2016 by danwinslow

[flashjazzcat]

Use DOSINI to patch your init to the warmstart routine, not DOSVEC.

[danwinslow]

Hi Jon. Yes, that's a typo, I'm actually using DOSINI at $C. If I start things at $3307, and raise memlo past that the appropriate amount, then all is well with dos, although I lose a huge chunk of memory between the old memlo and 3307. Did people just put up with that for handlers or what?

 

MY new problem is this load address pushes my handler into the $4000 range, which is bad due to all the bank switching it does. I think I'll just say 'does not work with Dos 2.5'.

[Rybags]

The problem with Dos 2.x and others that load DUP.SYS.

 

The Ram between MEMLO and thet top of where DUP.SYS would reside isn't guaranteed to be non-volatile. If no MEM.SAV is used it gets wiped, DOS signals this by setting WARMST to 00 which any language cart will know means an implied NEW takes place.

 

Any user handler that relies on that memory should do a similar check. WARMST should only be 00 upon the first call, it remains at 00 until a warmstart is caused either by software call or the user pressing RESET.

What might be needed is a stub of code somewhere else that verifies your program's integrity before calling it.

Edited January 19, 2016 by Rybags

[1050]

What am I missing here?

Possibly a simple thing like H. writing DOS files back to the boot disk. So very hard to say accurately from my keyboard though. But this one is too easy to forget to do.

 

After loading a handler to memlo, you are supposed to bump memlo value by your handler size and then do a JSR run thru DOSINI so DOS can re-initalize with the new numbers. At this point if you don't write back DOS files you don't boot with the new values and it's very easy to get lost on what happened first, second and third. Keep an eye on SASA (070Ch) buffer allocation start address with stock value of $19CC. Your handler size bump should be evident here after a run thru DOSINI, one can always cheat and bump open file buffer counts too.

[Rybags]

Redoing the call to DOSINI sounds about right, and I would think you'd need to do so with WARMST=00 otherwise it wouldn't touch the pointers.

 

Messing with buffer addresses, drive counts and stuff I'd stay away from. In relying on stuff like that you start to tie yourself to a particular Dos and will likely run into problems with others.

 

Also, re DOSINI since the OS only provides for limited init calls you'd probably want to set up nesting, ie take the vector over yourself then nest what was there to begin with.

[1050]

Messing with buffer addresses, drive counts and stuff I'd stay away from. In relying on stuff like that you start to tie yourself to a particular Dos and will likely run into problems with others.

Yep, it should be the last desperate move of a desperate coder, but we can cheat sometimes. Even writing back DOS files can be problematic as now you have a bumped memlo and no driver in the slot for it. Adding the driver and bumping memlo again isn't the smart move either. TSR (terminate and stay resident drivers) is a subject not covered very well can I say?

 

Also, re DOSINI since the OS only provides for limited init calls you'd probably want to set up nesting, ie take the vector over yourself then nest what was there to begin with.

I've never run into an issue with a simple JSR ($0C). Or if you are done entirely JMP ($0C). But in general I do agree on limited init calls after boot up as this can lead to trouble - Type 2 DOS seems to be the exception where it just doesn't matter how many times it happens in my experience. It does fix a lot of things for DOS too.

[danwinslow]

Hah, writing the dos back, I remember that from long ago now that you mention it. I decided to not worry too much about the older dos's, I assume they aren't really in use much anyway. But the problem may be that I am not jumping back through DOSINI correctly on init as you mention. I think I'll mess around a bit with this 2.5 issue just to learn something. RealDOS, Sparta, xbios, and maybe MYDOS are the ones I want to make sure it works with.

 

I call this code initially at the CLC below the JSR $FFFF, and on warmstart I call it at the beginning. So, I am just RTS'ing straight back to the loader code on init, and I probably should chain through to the old vector....not sure exactly what happens if I do that with the stack...will I eventually come back out of dos or does it go off on it's own at that point?

_dosini_handler:
    ; jump through old dosini, target set by aipbank.c
    jsr $FFFF
    clc
    ; reset memlo upwards by 3k bytes
    lda MEMLO+1
    adc #12 ; 3k
    sta MEMLO+1
    lda #1
    sta novbi
    sta novbd
    .ifdef USE_OSRAM
    jsr init_int_handler
    .endif
    jsr _int_installer
    jsr _handler_installer
    jsr handler_close
    jsr bank_in
    inton
    jsr bank_out
    lda #0
    sta invbd
    sta novbi
    sta novbd
    rts

Edited January 19, 2016 by danwinslow

[Rybags]

The Atari OS as good as it is doesn't lend well to multiple drivers and such things - insofar as being able to load a bunch of independant ones and have them coexist. In the XL that problem is corrected to an extent but relocatable and dynamically loaded drivers are really only available to peripherals that support it and keep the required code resident.

 

The relocation loader thing is a good idea, I haven't looked into it, would be handy if it could be utilized by normal programs but I tend to think it probably isn't. In any case you'd need the right assembler that can create the extra relocation information that needs to be packaged along with the object module.

Edited January 19, 2016 by Rybags

[danwinslow]

I wrote a little in-line relocator in C that moves the code to memlo and then fixes it up. Any opcode that takes a 2 byte address is examined, and if its target is within the relocation window it gets fixed up. Doesn't handle LSB/MSB stuff, but that's easy enough to avoid.

[flashjazzcat]

I don't miss the days of custom relocators for DOS 2.x, MyDOS and SpartaDOS 3.x. I used to put labels next to every instruction which required relocation, then have a table of said label addresses at the end (grouped into LSB, MSB, and words). A little code block would relocate the addresses then move the code down to MEMLO. I think the "DOSKEY" TSR I wrote used this method, despite the fact it was targeted at SDX (since I didn't know how to write relocatable SDX binaries in those days).

 

In any case: angling everything towards SDX (although this might be regarded as contentious in some circles) makes life a whole lot easier. DOS handles code relocation and you can specify code blocks which are transparently relocated into extended memory if it's available.

[danwinslow]

I really wish I understood more about how to do that with SDX. Are there any small code examples I could look at?

[flashjazzcat]

The programming manual on the SDX upgrade site is priority reading, and if you need any skeletal driver code I can certainly provide you with that if there's none already out there. Really, Konrad put so much work into the programming documentation it would be great to see more than a tiny handful of people using the information provided to write native SDX stuff.

[danwinslow]

I agree, and I did read through the manual, just yesterday in fact. It's very good, but of course by necessity doesn't cover every detail a newb like me would need. If you could send me some skeletal driver code, I would be very grateful.

[flashjazzcat]

Done!

[Kyle22]

This may be helpful: http://mads.atari8.info/mads_eng.html#_relok

[flashjazzcat]

Section on SDX relocatable binaries is here.