ADAM_TILGHMAN@bdt.UUCP (09/30/90)
I am in the middle of a project and have come upon an obstacle... I am using an external PD program, but in order to get it to do what I want I need to trap all FSFIRST/FSNEXT calls (in order to substitute my own filenames), as well as FOPEN() calls (to change the filename to suit my needs). So far I have this working perfectly EXCEPT for the fact that I can't find the current DTA address; is there any way that I can do this while processing a TRAP #1? Adam Tilghman P.S. - Please post replies to the net - my email feed is shaky
csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) (10/01/90)
ADAM_TILGHMAN@bdt.UUCP writes: > I am in the middle of a project and have come upon an obstacle... I am >using an external PD program, but in order to get it to do what I want >I need to trap all FSFIRST/FSNEXT calls (in order to substitute my own >filenames), as well as FOPEN() calls (to change the filename to suit my >needs). So far I have this working perfectly EXCEPT for the fact that >I can't find the current DTA address; is there any way that I can >do this while processing a TRAP #1? Experience tells me that you can call a GEMDOS function in your own trap #1 handler _before_ executing the actual function desired by the user or OS. So build a trap handler, analyse what you get on the stack (beware of the difference between 68000 and 68010/20/30/40), then call Fgetdta (save those registers!), then call the desired function. Worked for me, but I don't know if this is a documented feature, so please don't blame me if it won't work. It just seems logical if you look at the way the GEMDOS trap handler works. Do you _really_ need to know things like that? Another method comes to my mind: If you're linked into the GEMDOS trap you can also follow any manipulation of the current DTA address by tracing Fsetdta calls (watch out for those Pexec calls that place the default DTA into the basepage). Sounds much cleaner to me, but then, this method assumes that DTA addresses are only changed by Fsetdta and Pexec calls and that GEMDOS doesn't change them internally. Good luck, CB ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de ----------------------------------------------------------------------
roeder@robin.cs.uni-sb.de (Edgar &) (10/01/90)
In article <5429@bdt.UUCP> ADAM_TILGHMAN@bdt.UUCP writes: > I can't find the current DTA address; is there any way that I can > do this while processing a TRAP #1? The current process' DTA address is recorded in the basepage which can be derived from the act_pd system variable (this in turn is recorded in the sys_base (the first few bytes after the ROM-start) for TOS versions >= 1.2). BTW.: You should be able to call trap #1 recursively if you do it inline (for example in assembler) and avoid library routines that save the return address in a static memory location. The shell that i am using (Master) calls trap #1 very often in this way (even from inside a bios-trap --- but that's another story). Hope this helps! - Edgar
apratt@atari.UUCP (Allan Pratt) (10/02/90)
ADAM_TILGHMAN@bdt.UUCP writes: >I need to trap all FSFIRST/FSNEXT calls (in order to substitute my own >filenames), as well as FOPEN() calls (to change the filename to suit my >needs)... >I can't find the current DTA address; is there any way that I can >do this while processing a TRAP #1? Since you're intercepting trap 1 calls, this should be cake. Trap 1 is not inherently non-reentrant, it's GEMDOS that makes it so. Your code could make a "real" trap 1 call into GEMDOS for the Fgetdta call. Making a "real" trap 1 call can be done two ways: either you replace the old trap 1 vector, make your call, then write yours in again, or your "fake" the trap 1 by creating a stack frame and jumping to the old vector. Any time you catch GEMDOS or BIOS traps, or create a trap or interrupt stack frame, you should be sure to check the system variable "longframe" at $59e (word). If it's nonzero, you are on a machine with "long frames" -- an extra word on the stack after the SR and PC. Only the 68000 has short frames; every other 680x0 has long frames. I am answering this in such detail because I want to forestall somebody else pointing out that you can look in the current process' basepage for its current DTA pointer. This is not a published fact, and therefore the location and meaning of that variable is subject to change. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) (10/06/90)
In article <ROEDER.90Oct1153314@robin.cs.uni-sb.de> roeder@robin.cs.uni-sb.de (Edgar &) writes: >In article <5429@bdt.UUCP> ADAM_TILGHMAN@bdt.UUCP writes: > >> I can't find the current DTA address; is there any way that I can >> do this while processing a TRAP #1? > >The current process' DTA address is recorded in the basepage which can >be derived from the act_pd system variable (this in turn is recorded >in the sys_base (the first few bytes after the ROM-start) for TOS >versions >= 1.2). But I thought this is an "unofficial" way of finding the DTA, so it may break someday. Watching all SETDTA traps, on the other hand, will always work. -- "Restraint, hell. I'm just too fucking busy." -- Bill Wisner
klute@heike.informatik.uni-dortmund.de (Rainer Klute) (10/08/90)
In article <1990Oct6.030223.10558@murdoch.acc.Virginia.EDU>, gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) writes: |> >The current process' DTA address is recorded in the basepage which can |> >be derived from the act_pd system variable (this in turn is recorded |> >in the sys_base (the first few bytes after the ROM-start) for TOS |> >versions >= 1.2). |> |> But I thought this is an "unofficial" way of finding the DTA, so it |> may break someday. I noticed that the DTA entry in the basepage is 0x00000000 in TOS 1.4, which does not seem to be a useful DTA address. -- Dipl.-Inform. Rainer Klute klute@irb.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ Tel.: +49 231 755-4663 D-4600 Dortmund 50 |\|\ Fax : +49 231 755-2386
apratt@atari.UUCP (Allan Pratt) (10/09/90)
gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) writes: >roeder@robin.cs.uni-sb.de (Edgar &) writes: >>In article <5429@bdt.UUCP> ADAM_TILGHMAN@bdt.UUCP writes: >> >>> I can't find the current DTA address; is there any way that I can >>> do this while processing a TRAP #1? >> >>The current process' DTA address is recorded in the basepage which can >>be derived from the act_pd system variable (this in turn is recorded >>in the sys_base (the first few bytes after the ROM-start) for TOS >>versions >= 1.2). >But I thought this is an "unofficial" way of finding the DTA, so it >may break someday. No, this is "official" -- contrary to my earlier posting, it's documented in the original GEMDOS docs, and can't be considered a mistake. (Some things that were documented originally are now considered to have been "mistakenly documented" and are subject to change, but not many, and nothing important. Example: the Getmpb BIOS call should have been documented with "Used internally by GEMDOS" and nothing else.) >Watching all SETDTA traps, on the other hand, will always work. This is not the case. Each process starts with a default TPA which is not set via SETDTA. I'm not sure if that default DTA's location is documented, but in all existing TOSes it's the process' command line image, at (basepage+0x80). No system calls use the DTA except Fsfirst and Fsnext. It is not unlikely that a future GEMDOS might have new calls which accomplish the same thing but don't use the DTA at all, because having system information in user-supplied buffers doesn't make good sense. The DTA and Fsfirst/Fsnext will be maintained for backward compatibility, of course. (And the fact that we have to keep them around guarantees so much cruft in the code that there may not be much point in replacing them. But I digress.) ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
mwnewman@watmsg.uwaterloo.ca (the flying undying tomato express) (10/26/90)
In article <5429@bdt.UUCP> you write: > >I need to trap all FSFIRST/FSNEXT calls (in order to substitute my own >filenames), as well as FOPEN() calls ... >... So far I have this working perfectly EXCEPT for the fact that >I can't find the current DTA address; is there any way that I can >do this while processing a TRAP #1? You don't have to do it while processing trap #1. Just find out where it starts, and when it changes. ie: during the initialization of YOUR code (which shouldn't be in a trap #1), do a (normal) Fgetdta() call. This gives you the DTA address at the beginning. Now just trap Fsetdta() (along with Fopen etc. that you're already doing) in case this PD program changes the DTA. It seems to me this should be sufficient, but my ST is not at hand, so I can't check. mike newman mwnewman@msg.waterloo.edu