Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!ucbvax!DBNUAMA1.BITNET!VBRANDT
From: VBRANDT@DBNUAMA1.BITNET
Newsgroups: comp.sys.atari.st
Subject: Line F again
Message-ID: <8912200802.AA14955@ucbvax.Berkeley.EDU>
Date: 20 Dec 89 08:03:08 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 88
X-Unparsable-Date: Tue, 19 Dec 89 11:33:58 SET

(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? :-)