🚀 go-pugleaf

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.