XBIOS call invoking another?

[simonsunnyboy]

Is it legit to issue another trap #14 within an already running trap #14 handler?
E.g. use the value from a different XBIOS call in a given replacement one?

[ThorstenOtto]

To some degree, yes. However TOS (and also EmuTOS) use the memory that the system variable savptr ($4a2) points to, to save the callers registers. That area is rather limited (5 levels in TOS, 3 in EmuTOS). And of course you are also using more space on the supervisor stack.

[simonsunnyboy]

Understood however is there a different way to invoke existing functionalities for a TSR which will not replace all calls like EmuTOS does?

For my special usecase I can probably work around the need and implement the necessary functionality in my own code but it would be nice to know if it is allowed.

BTW how does it handled Supexec()? This is a call I use very often to given my code SUpervidor rights for hardware access. IIRC I didn't ran into problems with calling more XBIOS stuffs from that one. Ofcourse I have no idea on nesting with the used TOS.

[ThorstenOtto]

You can try to call XBIOS from your function, but i would be careful about that. If some other TSR is doing the same, then you sooner or later run into trouble.

Supexec() is not special in this regard. It saves your registers, then calls your function. If that calls XBIOS again, its about the same as other scenarios.

[mfro]

Profibuch says Atari said (X)BIOS maximum reentrancy level is three (but requires you to manually adjust the save area).

Anyway, this doesn't help you much if somebody else already exhausted that as Thorsten said.