VBRANDT@DBNUAMA1.BITNET (12/20/89)
Hello all, [I'm sorry that I reply only now to this message, but the recent amount of Info-Atari16 Digests gave me a hard time catching up.] In Info-Atari16 #705, John M Williams (jmw%tasis.utas.oz@uunet.uu.net) said in reference to my earlier posting: >A recent article suggested three possible methods by which a process could >determine whether it was being run from the desktop or from a shell. I'd like >to suggest another method which works for me. I don't suggest that it is >foolproof however. It simply requires moving the basepage ptr up to its parent >until it becomes null. If this requires three iterations then the program >is running from the desktop. Any more and it is running from a shell. [Code example omitted] In Digest #734, nis!pwcs!stag!daemon@UMN-CS.CS.UMN.EDU (Dale Schumacher) replies: >Alright, I guess it's time to post this message again (is this the 3rd >time now?). The quoted message is mostly correct, but incomplete. The >situation is slightly different if you're in the /AUTO/ folder programs >at boot-time. I check for the text-base pointer pointing to ROM, as >recommended by Allan Pratt @ Atari. The following code (which, like John's >code, assumes access to a basepage pointer) uses this "approved" method. >I've also included a copy of <basepage.h> from dLibs for those who don't >know the layout of the basepage structure. [Code example omitted] Finally, in Digest #740, portal!atari!apratt@uunet.uu.net (Allan Pratt) joins the discussion: >dal@syntel.mn.org (Dale Schumacher) writes: >>I check for the text-base pointer pointing to ROM, as >>recommended by Allan Pratt @ Atari. > >Yeah, well, that was before there were RAM TOSes running around. Caveat >hacker. No RAM TOS is supported by Atari (at this time) and most are >illegal copies, making their users pirates, so it's not that great a >hardship. Thank you all for replying. One of the things I wanted to find out by posting my original code samples was whether one can rely on the 'somewhat-documented' facts one has to exploit to find out where the process came from. Is the three-times-iteration method approved? Will it hold true in later TOS revisions? Same goes for my method, checking the os_magic pointer. I took pains to ensure that the code samples I sent out also work with TOS 1.6 (STE) and TOS 3.0 (TT). Dales version has the advantage of also detecting that the program was started from the auto folder. My version also works with RAM and STE/TT TOSes. Maybe Allan can tell us if one or the other method will be supported by Atari, or if there will be some kind of system variable that tells the current process if his parent is a shell or the desktop. Such a variable would also make life easier for programs like Neodesk etc. A side note to Allan: Take the ROM TOS 1.4, disassemble it, make it fully relocatable, write a little RAM loader, and you have a RAM TOS. Does that make me a pirate??? [BTW: Such a RAM TOS is great for testing out little OS tweaks and patches ... :-)] ---------------------------------------------------------------------------- Bitnet: VBRANDT@DBNUAMA1 (will go away some day ...) Volker A. Brandt UNM409@DBNRHRZ1 (alternative) Angewandte Mathematik UUCP: ...!unido!DBNUAMA1.bitnet!vbrandt (Bonn, West Germany) ARPAnet: VBRANDT%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU
VBRANDT@DBNUAMA1.BITNET (12/20/89)
(Sorry for the last posting, correct subject, wrong file ...) Hello all, [I'm sorry that I reply only now to this message, but the recent amount of Info-Atari16 Digests gave me a hard time catching up.] In Info-Atari16 Digest #714, fox!portal!atari!kbad@apple.com (Ken Badertscher) said: > As an aside, I should point out that our VDI guy has put a lot of work >into the blit code for the TT, and it's pretty phenomenal _without_ >hardware assist. One other thing that will give a noticeable improvement >is the lack of Line F compression in STE and TT ROMs. The Line F >compression adds a bit of overhead to AES operations, and desktop/window/ >dialog operations are noticeably sped up when the compression is gone. Yes, Ken is right. QuickIndex reports a GEM speed increase of 9% when those blasted Line Fs are removed from the current TOS 1.4 version. In Info-Atari16 Digest #714, mcsun!hp4nl!ruuinf!verwer@uunet.uu.net (Nico Verwer) asks: > In article <1820@atari.UUCP>, kbad@atari.UUCP (Ken Badertscher) writes: >> walkerb@tramp.Colorado.EDU (Brian Walker) writes: >> | What did you do with the line F compression? >> It's gone. Because of the larger ROM space in the STE, (and TT), the line F >> compression is no longer required to make the TOS ROM image fit. With the >> exception overhead gone, the AES moves along noticeably faster, too. > >Why didn't Atari use large ROMs for the 1040 in the first place? Using >line-F makes upgrading to a 68020 and a floating-point coprocessor really >difficult. Now it also appears that exception overhead seriously affects >AES-speed 8-( ! >Were ROMs so expensive at the time that Atari felt they should decrease >ROM-size at any cost, or is this a problem of the MMU, or what? >Will there ever be a chance for 1040 owners to use a larger ROM-set, >thus being able to painlessly use a 68020 running standard TOS? Is it >possible to make a hack and solder the extra ROMs in? Or would you have >to replace the whole motherboard with an STE-board (which has the same >case anyway)? Note that the ROM image actually becomes SMALLER if you take out the Line F codes. Yes, that's right, the Line F handler and the jump table use up MORE memory than they save. So it's not a question of too small ROMs, but of inadequate programming. With a little work, you can make TOS 1.4 cooperate quite nicely with an 68020/030. The biggest obstacle is the way the timing routines (for things like floppy delay etc) are implemented. You have to recalculate all loop counters and the like manually. The cleanest way would be to use a timer, and if you look closely at the TT TOS 3.0, you'll see that the TT HAS AN EXTRA 68901 that is used for exactly that purpose!!!! Finally, in Digest #742, att!chinet!saj@ucbvax.Berkeley.EDU (Stephen Jacobs) wonders: >In article <1841@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes: >>rehrauer@apollo.HP.COM (Steve Rehrauer) writes: >>| I know what you mean by "Line F", but what's the "compression" refer to re: >>| ST ROMs? (Usually I'm only this dense on Mondays & national holidays...) >> >>The line F compression I refer to is a method we used in ST ROM which >>basically replaces common operations with line F instructions. The >>line F handler is able, by decoding the $Fxxx instruction, to determine >>what operation to perform. The handler then dispatches the exception >>to the appropriate OS routine. > >This brings up the question of what the ROM code does instead. Have all the >little line F routines been made into subroutines, with more-or-less ordinary >subroutine linkages (I don't know the exact count, but there are A LOT of >line F routines)? Are the routines invoked by subroutine calls to a >dispatcher (a la GEMDOS)? Has the code been brought inline? There's a lot of Line F instructions in a relatively small part of the ROM, the AES. They fall in two groups: 'fast' subroutine calls, and a "save-some- registers-unlink-stack-and-return" group. The only difference is the registers that are to be restored. The handler looks at the Line F code, checks which group it belongs to (the LSB determines that), branches accordingly. If it's a subroutine, the jump address is taken from a table. If it's a restore- register instruction, the register mask is decoded, and the requested action is performed. You can bet that this takes more time!! I don't want to post code samples since Atari probably won't like it. Unfortunately, the TOS14FIX.PRG that repairs those two TOS 1.4 bugs installs a new Line F trap. The solution is to fix the bugs within TOS while you're at it anyway. :-) Enough operatingsystemology for today. (Or is it TOSology? :-)
bds@lzaz.ATT.COM (Buce Szablak) (12/21/89)
In article <8912200800.AA14560@ucbvax.Berkeley.EDU>, VBRANDT@DBNUAMA1.BITNET writes:
# >No RAM TOS is supported by Atari (at this time) and most are
# >illegal copies, making their users pirates, so it's not that great a
# >hardship.
#
# A side note to Allan: Take the ROM TOS 1.4, disassemble it, make it fully
# relocatable, write a little RAM loader, and you have a RAM TOS. Does that make
# me a pirate???
I use my RAM TOS obtained when I bought my ST to run programs that won't
run under TOS 1.4. Anyone who bought their ST before the ROMS were available
(pre 1040 days) got a TOS on disk.