Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!chinet!dag From: dag@chinet.UUCP (Daniel A. Glasser) Newsgroups: comp.sys.atari.st Subject: Re: Does FOLDRXXX _really_ work w/new ROMS? Keywords: TOS ROMS 40 FOLDER BUG FIX Message-ID: <2097@chinet.UUCP> Date: 12 Jan 88 03:36:54 GMT References: <2484@dasys1.UUCP> Reply-To: dag@chinet.UUCP (Daniel A. Glasser) Organization: Chinet - Public Access Unix Lines: 100 Newsgroups: comp.sys.atari.st Subject: Re: Does FOLDRXXX _really_ work w/new ROMS? Summary: The straight dope about FOLDRXXX Expires: References: <2484@dasys1.UUCP> Sender: Reply-To: dag@chinet.UUCP (Daniel A. Glasser) Followup-To: Distribution: Organization: Chinet - Public Access Unix Keywords: TOS ROMS 40 FOLDER BUG FIX In article <2484@dasys1.UUCP> schuster@dasys1.UUCP (Michael Schuster) writes: > >Recently some articles were posted by Atari folks (I forgot who - perhaps >it was Allan Pratt) as well as Landon Dyer, in which it was asserted that >FOLDRXXX.PRG will work properly with ALL versions of TOS - past, present, >and future. > [paragraph about 40-folderish problems with mega deleted] > >This brings me back to GEMBOOT. The most recent version I have (v1.10) came >with a utility program to find and display the address of the GEM memory >block nodelist (GEMFRL) as well as display all the allocated memory blocks. >The docs state that in the "old" roms GEMFRL was located at $56FA and if >this location is no longer valid, the GEMBOOT environment must be changed >to reflect the actual location of GEMFRL. > >Running this program under the new (04/22/87) roms gives a location of >$7E9C, and GEMBOOT does indeed enlarge the number of type 4 (directory >cache) memory blocks when so configured. > >Next I looked at FOLDRXXX.PRG. The discussion on CIS said that it contained >a look-up table of ROM version dates. Within the program the following >information (re-formatted, of course) appears: > $4E75 11/20/1985 > $56FA 02/06/1986 > $56FA 04/24/1986 > $56FA 06/01/1986 > $7E0A 00/00/0000 >(actually the last "date" might not be an entry at all, as the table is >padded at the end with nulls). > >This table brings forth two very alarming impressions! >1. The system date of the current roms, 04/11/1987, is NOWHERE IN THIS TABLE. >2. The address of $7E0A, which I take it is a projection of where GEMFRL might > be in the future, is WRONG. The TOS header lists GEMFRL at $7E9C. > >Just for fun, I zapped the last "entry" to read: > $7E9C 04/22/1987 >rebooted my system, and re-ran GEMFRL.TOS. The number of type 4 blocks allocated >had increased by 50%! > >Granted a lot of the above information may be shaky, reverse-engineered, or >based upon other people's mistaken "facts". Still, it raises questions about >the point-blank assertion that FOLDRXXX.PRG was designed to work with ANY >POSSIBLE version of TOS. Would an Atari spokesperson care to post a COMPLETE, >AUTHORITATIVE answer? I am not from Atari, but the answer that I believe to be the correct one is this: As of the time that FOLDRXXX was written, there had been only the listed versions (dates) of the ROMs created by Atari. A decision had been made within Atari to put a pointer to this elusive location (the list pointer) into all future ROM versions at a specific location. Therefore, if FOLDRXXX cannot find the date of the ROM in the table built into it, it assumes it to be a ROM that follows the new conventions, and uses the pointer from the ROM instead. That is the mechianism that (name witheld) at Atari has assured me is the way that FOLDRXXX will work with ALL future ROMs that Atari produces. Non-atari ROMs may not follow this convention. I have tested this assertion using a mechanism I'm not able to divuldge at this time to try this out with a version of TOS loaded at other locations, and FOLDRXXX works fine with them as well (so it uses an offset from SYSBASE, not a fixed ROM address). Now, all atari has to do is to publicly document these offsets so that programs that use the important information in these places can work on all future ROM versions. The desired locations are: The GEMDOS current process pointer The GEMDOS buffer pool pointers The BIOS/XBIOS jump tables for stream devices The Mouse Hidden / displayed counter The shift state mask (since it is not kosher to use Kbshift() from an interrupt hander) Allan? Neil? Any comments on these from anyone at Atari? dag PS: Alan: Thanks for the info! -- Daniel A. Glasser ...!ihnp4!chinet!dag ...!ihnp4!mwc!dag ...!ihnp4!mwc!gorgon!dag One of those things that goes "BUMP!!! (ouch!)" in the night.