schuster@dasys1.UUCP (Michael Schuster) (01/08/88)
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.
Last week on CompuServe's Atari Developer's Forum, Dave Small said that some
of Data Pacific's hard drives were acting "40-folder-ish" once connected
to a Mega, while they were fine when running on an older machine. The
version of FOLDRXXX.PRG they are using was the "official" one posted
to CIS, GEnie, etc. (I'm not even sure there exists more than one version).
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?
------------------------
--
l\ /l' _ Mike Schuster {sun!hoptoad,cmcl2!phri}!dasys1!schuster
l \/ lll/(_ Big Electric Cat schuster@dasys1.UUCP
l lll\(_ New York, NY USA DELPHI,GEnie:MSCHUSTER CIS:70346,1745 apratt@atari.UUCP (Allan Pratt) (01/12/88)
in article <2484@dasys1.UUCP>, schuster@dasys1.UUCP (Michael Schuster) says: > 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. > For Christ's sake! Everybody with a debugger thinks he can out-think the guy who wrote (and documented) a utility. (It happens that you have the table wrong: $4E75 is an "rts" instruction. The table starts with the next word, with date-address pairs.) Atari is not so foolish as to think that a patch which works for current and old ROMs (i.e. 6/1/1986 and older) works for all future ROMs. If we say it works for ALL ROMS, PAST PRESENT AND FUTURE don't you think we've put a little more thought into it than that? Yes, FOLDRXXX.PRG works for ALL ROMS. It will work for ALL FUTURE ROMS. (At least, all ROMs which have this problem.) I shouldn't have to defend it like this, but I will spell it out: For old ROMs, the location of the patch point is determined from the table. For newer ROMs, a pointer to the patch point was placed at the end of the OS header, so the address comes from the ROM itself. That's how you make things work for past, present, and future. The reason I am mad about this posting is that the LAST thing we need is people to start rumors discrediting Atari's patches. When we do try to fix something, please make sure of your facts before telling the world that it doesn't work. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
dag@chinet.UUCP (Daniel A. Glasser) (01/12/88)
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.