Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!ucla-cs!zen!ucbvax!COGSCI.BERKELEY.EDU!bryce From: bryce@COGSCI.BERKELEY.EDU Newsgroups: comp.sys.atari.st Subject: Re: 68020 Extension-board PAK-68 Message-ID: <8708071351.AA14935@cogsci.berkeley.edu> Date: Fri, 7-Aug-87 09:51:20 EDT Article-I.D.: cogsci.8708071351.AA14935 Posted: Fri Aug 7 09:51:20 1987 Date-Received: Sun, 9-Aug-87 01:39:06 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Lines: 53 > Here's some more detailed information about the 68020 extension-board... > > (I know it must be a very strange request, but if some kind soul could > transfer this note into the comp.amiga.* newsgroup ???... > > Unfortunately the current TOS version DOES DEFINITELY NOT WORK... > > AMIGA users might be more lucky! Though the AMIGA supports the 68010 > the step to the 68020 is not that far - so the OS RUNS with PAK-68 in- > stalled... but the author mentioned some doubts about the application > software ... Information for your technical amusement: On powerup the Amiga detects the 68020, enables the instruction cache, twiddles the stack frame and sets a bit for all the world to see. As far as the OS, compatibility is 100%. As is usual there are one or two naughty programs that don't follow the rules and won't work (Most notably Microsoft BASIC, but since when has Microsoft written good code for *ANY* machine? :-). Other software that does not work includes "Barbarian", an old version of the calculator and an old version of the Transformer. The leading cause of problems is the use of the officially blacklisted MOVE SR, instruction which is privileged on the '010 and '020 but not the 68000. There is an easy patch for that one, it's called decigel. Write to me if you want a copy to port to the ST, but really it's quite trivial. (It is also available from any Motorola distributor). The second most common cause of death is good 'ol timing loops as part of disk [protection]. Often they muck with reading the disk DMA registers directly, rather than letting the full-track DMA hardware do it for them. The third most common problem is programs that leave garbage in the upper 8 bits of a pointer. While this would not be a problem for a board that plugs into the 68000 socket, it would kill a *real* 68020 system. Microsoft BASIC seems to be guilty of this crime. The design team of an as-of-yet-unreleased, low cost double-speed 68020 plug in for the Amiga decided to place their 32 bit memory *within* the 16 Megabyte 68000 address space because of BASIC. (I argued that they should simply include the address of a company that sells a real BASIC :-) :-) :-) Very few programs actually fail, but there are those programmers that always want to give their programs that "special touch" :-) :-) :-). The last native C compiler to generate 68020 dirty code was quashed by a free update a long, long, time ago. (The bug went away when Lattice C went to rev 3.03 (or something close to that)) -Cheers!-