LINDAHL@brandeis.BITNET (03/06/87)
Date: Fri, 6 Mar 87 14:54 EST From: <LINDAHL@BRANDEIS.BITNET> (Greg Lindahl [lindahl@brandeis.bitnet]) Subject: a 68010 for your st? To: info-atari16@score.stanford.edu X-Original-To: atari16, LINDAHL i'm on spring break, and since i have nothing better to do i was thinking of hooking up a 68010 to my st. yes, it's a disgusting hack from the hardware side... i was wondering: has anyone else done this? what software problems do you have other than MOVE SR,<ea> (fixable by grabbing the priv violation vector)? i know that the different stack frames will probably clobber my favorite debugger, but after looking into the st bios i don't think that it ever looks at the stack frame except for the bomb handler, which doesn't care what kind of stack frame it is. comments anyone? Greg Lindahl | bitnet: lindahl@brandeis.bitnet brandeis radio astronomy group (BRAG) | ci$: [76515,1122] --------------------------------------| us snail: box 2522 brandeis university "OK, if stupidity isn't an impeachable| waltham mass (usa) 02254-9110 offense, then what is?" | telco: (617) 899-5884 [ don't send me mail thru the ucbvax gate, 'cuz UCBJADE doesn't know that Brandeis exists... ]
dyer@atari.UUCP (Landon Dyer) (03/08/87)
> i'm on spring break, and since i have nothing better to do i was thinking > of hooking up a 68010 to my st. yes, it's a disgusting hack from the hardware > side... i was wondering: has anyone else done this? what software problems > do you have other than MOVE SR,<ea> (fixable by grabbing the priv violation > vector)? > > i know that the different stack frames will probably clobber my favorite > debugger, but after looking into the st bios i don't think that it ever > looks at the stack frame except for the bomb handler, which doesn't care what > kind of stack frame it is. It's not really a disgusting hardware hack, since the 68000 and 68010 are pin compatible. But TOS will not work with a 68010; it dies on the first "constructed" RTE. HOWEVER, at least for boot ROMs, the system will get far enough into system initialization to load an executable boot sector from floppy. I can't say this for sure about TOS in ROM, and since I've never tried it, well, it probably doesn't work.... Adding a 68010 will not noticably increase your machine's performance, unless you are prepared to re-write the graphics primitives to take advantage of the DBRA loop-mode. And naturally [I more or less have to say this] Atari doesn't condone making this kind of modification to your machine.... -- -Landon Dyer, Atari Corp. {sun,lll-lcc,imagen}!atari!dyer The views expressed here do not not necessarily reflect those of Atari Corp. Segments are for worms.
fletch@fluke.UUCP (03/13/87)
In article <8703062012.AA22292@ucbvax.Berkeley.EDU> LINDAHL%BRANDEIS.BITNET@forsythe.stanford.edu writes: >i'm on spring break, and since i have nothing better to do i was thinking >of hooking up a 68010 to my st. yes, it's a disgusting hack from the hardware >side... i was wondering: has anyone else done this? what software problems >do you have other than MOVE SR,<ea> (fixable by grabbing the priv violation >vector)? > >i know that the different stack frames will probably clobber my favorite >debugger, but after looking into the st bios i don't think that it ever >looks at the stack frame except for the bomb handler, which doesn't care what >kind of stack frame it is. > >comments anyone? > I have taken the first step of the installing a 68010 in place of the 68000; I simply swapped microprocessor chips. TOS (dated 11-20-1985 in code) will not boot with the 68010. I observed both bus errors and privilege violations. When I have the ability to make cartridges, I plan on making a cartridge to allow TOS to run on the 68010. The vector base register will allow all exceptions to be intercepted, even if apps redefine the vectors. The idea is to intercept all vectors, handle group 0 exeptions (bus error, address error and reset) and emulate the MOVE from SR instruction. TOS may make this difficult. It appears that not all exception returns are done with the RTE instruction, but some are. The extra word on the stack (extra 23 words for bus errors) cannot be played with unless it is known how TOS will return from the exception. The benefits of the 68010 would be faster multiple/divide times, pre-fetch and a fast loop mode. The loop mode would be nice for things like clearing memory. I am disappointed that the code in ROM was not written in a way to be compatible with the 68010 chip. Apparenty the Amiga OS was. I would be interested in mail from others who have looked at something like this or have comments/warnings/dire predictions. Simple fixes always welcome.
fletch@fluke.UUCP (03/13/87)
This is the signature file for my preceding posting.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fletcher holmquist john fluke mfg co. (206) 356-5051
{cornell,decvax,ihnp4,sdcsvax,tektronix,utscrgv}!uw-beaver--\
{decwrl!sun,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}--> !fluke!fletchjohn@viper.UUCP (John Stanley) (03/17/87)
In article <574@tc-fletch.tc.fluke.COM> fletch@tc.fluke.COM (Fletcher Holmquist) writes: > >When I have the ability to make cartridges, I plan on making a cartridge to >allow TOS to run on the 68010. The vector base register will allow all >exceptions to be intercepted, even if apps redefine the vectors. > Good luck. I'm looking forward to hearing more about your plans for this.. >....... I am disappointed that the code in ROM was not written in a way to >be compatible with the 68010 chip. Apparenty the Amiga OS was. > I've been discussing this with a small group of Amiga users. They are having the same problems upgrading to 68010's as we are. Aparently there is either an alternate "kick-start" disk for use with 68010 Amigas and/or there are some people experimenting with a method of detecting the different CPU's and booting the correct Amiga os based on what's in the machine. Either way, it means they have two different operating systems for the different cpus. This is a major problem all users wanting to upgrade are going to have to face regardless of the machine (ST or Amiga) they're using. --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john
grr@cbmvax.cbm.UUCP (George Robbins) (03/17/87)
In article <682@viper.UUCP> john@viper.UUCP (John Stanley) writes: > >I've been discussing this with a small group of Amiga users. They are having >the same problems upgrading to 68010's as we are. Aparently there >is either an alternate "kick-start" disk for use with 68010 Amigas and/or >there are some people experimenting with a method of detecting the different >CPU's and booting the correct Amiga os based on what's in the machine. > > Either way, it means they have two different operating systems for the >different cpus. This is a major problem all users wanting to upgrade are >going to have to face regardless of the machine (ST or Amiga) they're using. > >John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems I truely hope this will not be the beginning of another flame war!!! The Amiga operating system was *designed* to work with 68000's, 68010's and 68020's interchangably, and does so remarkably well in the current 1.2 software release, thank you. Some third party software writers were less cautious of this and other expansion issues and as a result their *application* software fails to work on enhanced systems. There are a number of little band-aids available that are intended to make this crippled software work in the 68010/020 environment. The whole problem should go away when software authors and marketeers realize that the Amiga is not a single machine, but rather a family of highly compatible machines with differing features. Persons finding any processor dependent bugs in the software are of course encouraged to forward bug reports to Commodore, so that these things can be fixed in our next software release. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
daveh@cbmvax.cbm.UUCP (Dave Haynie) (03/17/87)
in article <682@viper.UUCP>, john@viper.UUCP (John Stanley) says: > > I've been discussing this with a small group of Amiga users. They are having > the same problems upgrading to 68010's as we are. Aparently there > is either an alternate "kick-start" disk for use with 68010 Amigas and/or > there are some people experimenting with a method of detecting the different > CPU's and booting the correct Amiga os based on what's in the machine. > > Either way, it means they have two different operating systems for the > different cpus. This is a major problem all users wanting to upgrade are > going to have to face regardless of the machine (ST or Amiga) they're using. WRONG!!! The Amiga works just dandy with a 68010, 68020, etc. No alternate KickStart or other major modification is necessary (well, of course, you'd need some interface hardware for a 68020). The Amiga's OS was designed from the start to support any of the 680xx chips running at any speed, and knows which chip is in the system, and provides processor independent ways of doing the things that cause problems in other OSs. There are two major problems with running the 68010 or 68020 on a system that was originally intended for the 68000. The first of these problems is the use of the 68000's MOVE from SR instruction. The newer processors allow this instruction only in Supervisor mode so an operating system running in User Mode can't see the "S" bit and tell that its really not in Supervisor mode, where most OSs like to be. The 68010 give you a MOVE from CCR instruction to access the condition codes. The Amiga's Exec provides a processor independent function, "GetCC()", which allows a program to get condition codes from any processor. A (very) few developers have ignored this; fortunately for any application that does ignore this and uses the MOVE from SR, its a small matter to install an exception handler that'll trap the exception this causes, read the condition codes via GetCC(), and then resume normal operation. The other big problem when upgrading processors is the fact that the newer processors store much more information on their exception stacks than the 68000 does. The 68010, for instance, stores information on the internal processor state to support instruction continuation necessary for virtual memory systems. Unfortunately, lots of 68000 programmers like to play around with what's on the stack after an exception. If you switch from a 68000 to a 68010, there's going to be different stuff there, and if your program depends on that stuff, it'll probably die with the 68010 or 68020 in place. The Amiga's ExecBase structure contains a field that tells a program the type of processor in use; thus, any exception handling code can use this to examine exception stacks in a way appropriate to the processor currently in use. Unfortunately, this is a much more complicated problem than the MOVE from SR problem, so there's no real way to fix programs that don't watch out for other processors in place other than rewriting the offending code (this if of course true for all 68000 systems, not just the Amiga or Atari). All of the Amiga's OS software works on any processor, and probably more than 95% of all commercial and public domain software are well (the Amiga ROM Kernal Manual talks about 68010 and 68020 compatibility right on the 5th page of its preface; all the developers work from this book). > John Stanley (john@viper.UUCP) > Software Consultant - DynaSoft Systems > UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dave Haynie Commodore Technology // /| ___ __ __ __ {ihnp4|caip|rutgers}!cbmvax!daveh |\ // /_| | / \ / \ / \ Commodore rarely admits to knowing me, \\// / | +--+ | | | | | | much less sharing my personal opinions. \/ / | |___ \__/ \__/ \__/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cmcmanis@sun.uucp (Chuck McManis) (03/17/87)
In article <682@viper.UUCP>, john@viper.UUCP (John Stanley) writes: > I've been discussing this with a small group of Amiga users. They are having > the same problems upgrading to 68010's as we are. Aparently there > is either an alternate "kick-start" disk for use with 68010 Amigas and/or > there are some people experimenting with a method of detecting the different > CPU's and booting the correct Amiga os based on what's in the machine. > > Either way, it means they have two different operating systems for the > different cpus. This is a major problem all users wanting to upgrade are > going to have to face regardless of the machine (ST or Amiga) they're using. > > --- > John Stanley (john@viper.UUCP) > Software Consultant - DynaSoft Systems > UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john John is mistaken, the Amiga will boot with either a 68010 or a 68020 as the main processor. In the first case you simply replace the 68000 chip with an '010 and reboot. In the second you will need the CSA adapter card since the '020 and '000 are not pin compatible. The only problem you encounter arises from people using the dreaded MOV SR, EA instruction, which *none* of the C compilers generate. (I understand TDI modula-2 may) There is an O/S function call to get the SR in a compatible way no matter what chip is installed. Also there is a program to install an exception handler for misbehaving programs but the OS totally and transparently supports the higher level chips. DRI was exceptionally short sited in not providing that support in GEM. Summary : The Amiga can run '000, '010, and '020 processors without a change in the O/S or system software. All programs written in C work also. -- Inews filler. -- Inews filler. -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
john@viper.UUCP (John Stanley) (03/18/87)
In article <1563@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > >Some third party software writers were less cautious of this and other >expansion issues and as a result their *application* software fails to work >on enhanced systems. There are a number of little band-aids available that >are intended to make this crippled software work in the 68010/020 environment. It turns out that *application* problems are, in fact, what was causing the incompatability. The people I was speaking to on this subject are more "users" than "systems-people". All they knew was they tried to run some programs on an upgraded machine and it would bomb. They went to the shop where the upgrade was done. The people there gave them new boot disks and that solved their problems. (It would appear that a patch was added to those disks for the specific programs causing problems...) They assumed it was a different OS and I, foolishly it appears, assumed that they knew what they were talking about. Sorry for any confusion... --- John Stanley (john@viper.UUCP) Software Consultant - DynaSoft Systems UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john