NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/atari/st/16988

Text File | 1992-11-21 | 3.4 KB | 69 lines

Newsgroups: comp.sys.atari.st
Path: sparky!uunet!microsoft!hexnut!darekm
From: [e-mail] (Darek Mihocka)
Subject: Re: New TOS versions?
Message-ID: <[e-mail]>
Date: 22 Nov 92 01:15:45 GMT
Organization: Microsoft Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 55

>  I didn't know the story behind the inclusion of Line-F system before - I
>always thought it seem an extreamly slow way of doing things.
>  Interestingly some of the line A functions are actually very well written
>- I tried to write a fast resolution dependant line drawing routine in
>assembler once, using the best algorithms I could find in books and in the end
>used line A because it was so very nearly as fast.

Line A and Line F traps are a good idea and a bad idea, depending on what you
use them for. A line A or line F instruction occupies 2 bytes of code, compared
to 6 bytes for a typical JSR instruction. So if you make a lot of calls to the
same routines, it becomes a great reduction method to use line F, which is
exactly what the TOS ROMs did. The line F handler simply had a table of the
routines and jumped to the appropriate routine depending on what the full 16-bit
line F trap number was. Same goes for line A. The Mac operating system does the
same thing with line A.

But, there is a certain amount of overhead with handling each trap, let's just
say 100 clock cycles. A JSR RTS combination is only 36 cycles. If the routine
you're calling takes thousands of clock cycles, the overhead is minimum. But
if you do it every few lines of code like the TOS ROMs, you waste a lot of time
in the line F handler. That's exactly why TOS 1.0 on disk (which uses no line F)
is about 10% faster than TOS 1.0 in ROM. Of why TOS 1.4 in ROM is slower than
TOS 1.6 in ROM. 1.4 has line F and 1.6 doesn't.


>  Then sell the source to Derek for recompilation to 386 code for his
>Gemulator which would then be usably fast on a sub #1000 PC (if not too fast).

I'm way ahead of you there. When I sold off Quick ST to Codehead, I kept rights
to the source code for just such a purpose. Already, Gemulator 2.0 has parts
of Quick ST implemented in it as 386 code. That's what the QUICK option in
Gemulator does. oooooh, pretty sneaky, huh? Right now, a chunk of VT52 and
a little bit of VDI is implemented, so if you flick QUICK on, you'll notice
about a 50% speedup in text and string redraws, and about 10% in VDI. As I do
more work on it in the next few months you'll see the numbers go up more and more.

And this is a faster and more compatible thing to do than hooking trap handlers
like Quick ST does. The QUICK option actually writes 386 code directly over top
the 68000 in the TOS ROMs (since Gemulator loads them into RAM).

I'm not sure what you meant by "sub #1000 PC". Is that 1000 dollars or 1000 pounds?
Right now you can buy 25 Mhz 486SX machine for under $1000, and that will give
you roughly 8 Mhz 68000 emulation. You can still use the real Quick ST or Warp 9
running on Gemulator to give you the kind of speed ups you get on a real ST,
since Quick ST does things in less code, Gemulator has to emulate less code and
thus speeds up. Same reason it speeds up a real 68000.

- Darek

>
>- Leo


--
/--------------------------------------\
| Darek Mihocka. net: darekm@microsoft |
| Views expressed are my own, I think. |
\--------------------------------------/