Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!portal!atari!apratt From: apratt@atari.UUCP (Allan Pratt) Newsgroups: comp.sys.atari.st Subject: Re: How can I find current DTA address w/o using TRAP #1? Message-ID: <2328@atari.UUCP> Date: 8 Oct 90 19:25:48 GMT References: <5429@bdt.UUCP> <1990Oct6.030223.10558@murdoch.acc.Virginia.EDU> Organization: Atari Corp., Sunnyvale CA Lines: 43 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