Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!hyc
From: hyc@math.lsa.umich.edu (Howard Chu)
Newsgroups: comp.sys.amiga
Subject: Re: Atari ST 1040 Emulator...
Keywords: atari, emulator
Message-ID: <1990Oct13.090111.19448@math.lsa.umich.edu>
Date: 13 Oct 90 09:01:11 GMT
References: <1990Oct05.050625.28960@hoss.unl.edu> <8839@helios.TAMU.EDU> <1990Oct5.185748.6998@uokmax.ecn.uoknor.edu>
Sender: usenet@math.lsa.umich.edu
Organization: University of Michigan Math Dept., Ann Arbor
Lines: 47

In article <1990Oct5.185748.6998@uokmax.ecn.uoknor.edu> slfields@uokmax.ecn.uoknor.edu (Scott L Fields) writes:
>In article <8839@helios.TAMU.EDU> n350bq@tamuts.tamu.edu (Duane Fields) writes:
>>I ran it on my 3000 and got nothing but a blank screen, if I have a system
>>disk will it work? Or does it sound like it doesn't work with the '030??
>
>You have just discovered the bane of the Atari users life. {NO ABILITY TO USE

Yes and no...
>A 68020/68030/68040/ETC.} The atari uses the reserved intruction basically
>called the 55 intereupt {if I remember}. Well, that instruction is used for

We call it the Line-F trap vector... (Any opcode of the form 0xF***). This
is indeed intended for coprocessor support in the '020 and up, and Atari really
blew it by using this vector in the ROMs. But that doesn't prevent the '020
from running TOS, just prevents it from being able to use a coprocessor.

The big problem is naive trap-handling code. There was only one type/size of
stack frame on the 68000, and there any many different ones on '020 and such.
This is what makes the biggest problems, though it can also be fixed with a
simple patch. (Snag the trap vector, save the context that the TOS doesn't
expect to see, push a short frame onto the stack, then jump back into the old
trap handler. Pop everything on return... A hassle, but doable.)

>the coproccessor supports in the 68020 and later chips. Try to run ST code on
>a 68020 or higher and BOOM!. OS calls make the machine crash. This is the main
>reason it has been so long for any Atari to use the 68020/etc period until the
>release of the TT. And that is basically incompatible with all previous soft 

All previous software? Not that bad. I think they mentioned numbers around
80-90% of existing software *still working*. Not bad, considering what they
had to start with. (Yeah, TOS sucks. But what would you expect of a system
that started from CP/M68K and then tried to be MSDOS with graphics?)

>ware. Oh well. I guess that is a good reason to NOT buy a 3000. What good is
>a machine that can't run Atari ST software. {excuse me while I throw up}

Say, can you run gcc, gdb, g++, and gnu-emacs on your Amiga? Concurrently?
It ain't exactly speedy, but I've done it on occasion on my ST. I think a
better question is "what good is a machine that can't run *GOOD* software."
This isn't intended to start a stupid flame-war... The ST is a pretty good
computer, the Amiga is pretty good. I hate Macs & PCs. What else needs to
be said?
--
  -- Howard Chu @ University of Michigan
  one million data bits stored on a chip, one million bits per chip
	if one of those data bits happens to flip,
		one million data bits stored on the chip...