ken@gatech.edu (Ken Seefried III) (06/02/88)
I have seen all the talk about putting a 68020 in a 68000 socket, but is it
similarly possible to put a 68020 in a 68010 socket? What software problems
would be expected (as the priviledged opcodes on the '020 are also on the
'010, no?).
my conception of an '020 daughtercard (for my own system) includes a nice
heafty portion of 32-bit RAM...I don't really see a good reason to do it
otherwise.
now this might be a really silly, but what are the prospects of putting a
68030 in a 68000 (or '010 or '020) socket (with plenty of 32-bit RAM...)
ken seefried iii ...!{akgua, allegra, amd, harpo, hplabs,
ken@gatech.edu inhp4, masscomp, rlgvax, sb1, uf-cgrl,
ccastks@gitvm1.bitnet unmvax, ut-ngp, ut-sally}!gatech!ken
soon to be open: ...!gatech!spooge!ken (finally ;'})michael@mcdchg.UUCP (Michael Bodine) (06/04/88)
> I have seen all the talk about putting a 68020 in a 68000 socket, but is it > similarly possible to put a 68020 in a 68010 socket? What software problems > would be expected (as the priviledged opcodes on the '020 are also on the > '010, no?). As the 68000 and 68010 are pin compatible, there are no mechanical or electrical problems with using the same hardware in either socket. The 010 software is upward compatible with the 020, as opposed to the 000 which is MOSTLY upward compatible with the 020, so software gotchas should be fewer. Not to be construed as a commitment that there won't be any! > now this might be a really silly, but what are the prospects of putting a > 68030 in a 68000 (or '010 or '020) socket (with plenty of 32-bit RAM...) There are, in fact, internal ap notes and products from vendors like CSA which detail placing 030's in 020 sockets. I haven't seen anything that gives a design for an 030 into a 000 socket...although you COULD plug the 020 daughter board into the 000 socket and the 030 into the 020 socket on the daughter board. B-) A do-able thing. If you've lots of spare time and are in love with your soldering iron. By the time you were done, tho', you could probably go out and buy some small existing 030 hardware with lots less hassle and not much more money. Without a cache architecture for your local RAM, the performance enhancements seen with these kinds of add-ins are usually not that significant except for certain algorithms that run out of the on-chip cache. The limiting factor is the access path from the original socket to the original memory, which is usually far slower than the new chip wants to take it, so the new chip ends up starved for instructions most of the time. Still a fun exercise for the home-brew fanatic and a great learning experience for a designer. But the 030 comes in a 128 pin grid array package -- a lot of hair pulling to get that baby all wired up! Have fun... -- [ Michael Bodine, michael@mcdchg.UUCP Opinions expressed are mine and haven't ] [ been seen, commented on or in any way approved or even allowed by Motorola ] [ MicroComputer Division, Motorola General Systems Group or Motorola, Inc. ] [ No one else agrees with me; why should my employer? ]
thad@cup.portal.com (06/04/88)
You should have no major problems operating a suitably adapted daughter carded 68020 in a "68010 socket". I've used both 68010s and 68020s in Amigas since 1985, and several weeks ago operated a 68030 on the same machine. There are commercially available cards facilitating such conversion, with provision for 32-bit-wide RAM (static) cards attached "locally". Software changes require enabling the cache(s) and cognizance of the different stack frames. Operating systems such as that on the Amiga handle the different processors with ease, and Motorola publishes AppNotes detailing these steps in the general sense.
jbn@glacier.STANFORD.EDU (John B. Nagle) (06/04/88)
I'd like to suggest to Motorola that they bring out a 68020 in a form pin-compatible with the 68010 and 68000. The object is software compability; it's annoying that one can't run the same software on all machines of, say, the Apple line. This causes trouble in the retail software market, since multiple versions have to be manufactured, distributed, and stocked. As the IBM market fragments into the DOS market, the OS/2-286 market, and the OS/?-386 market, one of Motorola's edges is its consistent architecture. Now that Intel is coming out with a 386 in 286 packaging, Motorola needs to catch up. John Nagle
hase@netmbx.UUCP (Hartmut Semken) (06/05/88)
In article <17206@gatech.edu> ken@gatech.edu (Ken Seefried III) writes: >I have seen all the talk about putting a 68020 in a 68000 socket, but is it >similarly possible to put a 68020 in a 68010 socket? What software problems Yes. No problem: the 67999 (for my opinion the 010 is the 'real' 68000) and the 010 are pin-compatible and have the same bus timing. The problem is not the hardware (the PAK68 board made by a german computer magazine called c't will do) but the software (as you said). If the system and application software can deal with the greater stack frame of the 020, everything should work. hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP High on a rocky promontory sat an Electric Monk on a bored horse. (D. Adams)
thad@cup.portal.com (06/06/88)
Why do you feel there's such a software incompatibility between the various 680x0 processors? I've been operating 68000, 68010 and 68020/68881 combinations in my Amigas for over two years now with impugnity. There are fewer than 10 commercial software products (of the more than 700+ available), and fewer than five public domain (of the thousands available) that don't function properly on the '020 Amigas, and the reason are simple: 1. Some earlier commercial software releases were produced using a C compiler that generated (or whose library utilized) the dreaded `MOVE SR,<ea>' instruction. Fixes for this are distributed by Motorola (as described in App Notes, etc.) and are also user- installable by running the DeciGEL program in the background (this program traps privilege violations, examines the opcode at the offending location, and patches it to be MOVE CCR, then re-executes the instruction) 2. self-modifying code (which wreaks havoc with the '020 when the instruction cache is enabled). Both the problems above are due to software producers who chose to ignore Amiga programming guidelines issued in May 1985 The Amiga's OS has supported all 680x0 variants since 1986 (with release 1.2), and it automatically enables the 020's cache if an '020 is detected upon system boot and startup. The Amiga OS release 1.3 automatically vectors to a 68881 if one is present, thus permitting all existing programs the use of the math chip. Guidelines for implementing compatibility are available from Motorola who claims, in their App Notes, that any operating system can be fixed in just a matter of hours (ref: Motorola's MICRO MINUTES MM-444-02). As a matter of interest, the 68030/68882 combination also operates fine on the Amiga. Products (e.g. piggyback *AND* plug-in boards) exist commercially today. Several manufacturers' boards (both '020 and '030) were demonstrated and available for purchase recently at the Santa Clara Convention Center, and one or two different types are usually shown in the Hacker's Kitchen room during the FAUG (First Amiga Users' Group) meetings at the Palo Alto Hyatt Hotel (about 1,000 members usually in attendance, along with a wet bar! :-) whose next meeting is this Tuesday, June 7, at 7PM. You're welcome to attend. Finally, attempting to "shoe-horn" a 68020 into an 68000-size package is not reasonable, since you'd lose the 32-bit wide data path and other niceties of the 68020's design. Piggyback adapter cards permitting an '020 to be used as a replacement for an '000 or '010 are readily available at 'reasonable' cost. Without wishing to start another "my computer is better than yours" debate, I respectfully suggest that you express your concerns to the manufacturer of your computer system and to the software producers. There is NO need to produce multiple versions, packaging, etc. of commercial software releases IF the system software and hardware was thoughtfully and intelligently designed and implemented. One example: on the Amiga, the user's tasks and processes run non-privileged; if they NEED the processor's condition codes, a system call (GetCC() for C, JSR _LVOGetCC(A6) for assembler) provides the codes in a processor-indepedent manner. The MC68000 has been "out" since 1978, and the 68010 and 68020 were not exactly born yesterday. These issues have been understood and addressed years ago, so I'm sorry to hear you are burdened with a system that doesn't permit expansion flexibility and processor upgrade.
alan@pdn.UUCP (Alan Lovejoy) (06/06/88)
In article <17479@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: >I'd like to suggest to Motorola that they bring out a 68020 in a >form pin-compatible with the 68010 and 68000. The object is software >compability; it's annoying that one can't run the same software on all >machines of, say, the Apple line. This causes trouble in the retail software Pin compatibility has nothing whatever to do with software compatibility. The software incompatibiliites between the '000, the '010 and the '020 are caused by the fact that some instructions do not have the same privilege status on the '010 and '020 as they do on the '000 (which should normally only affect operating system code), by the fact that the '020 has an instruction cache which invalidates some "dirty tricks" involving self-modifying code which Motorola warned everyone would not be portable and by the fact that the chips may operate at different clock speeds and execute instructions in a different number of cycles, causing problems for code which tries to mark time by executing a known number of instructions with a known number of cycles. Pin compatibility means that two different chips can be plugged into the same socket and both will work--it does not mean that both chips are necessarily software compatible in any way! -- Alan Lovejoy; alan@pdn; 813-530-8241; Paradyne Corporation: Largo, Florida. Disclaimer: Do not confuse my views with the official views of Paradyne Corporation (regardless of how confusing those views may be). Motto: Never put off to run-time what you can do at compile-time!
jbn@glacier.STANFORD.EDU (John B. Nagle) (06/06/88)
In article <6276@cup.portal.com> thad@cup.portal.com writes: >Why do you feel there's such a software incompatibility between the various >680x0 processors? > The problem is, of course, the multiply hardware. The 68000 and 68010 lack hardware for a 32x32 bit multiply, while the 68020 and 68030 have such hardware and a new opcode. Compilers for the 68000 and 68010 typically call a subroutine for every multiply. Some of the smarter compilers handle multiplies by constants in special ways (typically using addition and shifting) to avoid the overhead of the multiply subroutine whenever possible. This speeds up subscript calculations considerably. On Sun machines, software is generated for the 68020 or 68010 based on a compiler switch. Much new software built for the 68020 will not run on the older Sun II machines, which have 68010 processors. The Sun II is considered obsolete in the Sun world, having been superseded by the Sun III more than two (three?) years ago. This history will repeat itself at the low end, on the Mac and Amiga lines. As the mainstream products become 68020-based, more software will be built that assumes a 68020 platform. This software will not run on the smaller machines of the product line. There are already Mac II only products, including CAD systems. There will be more. But there will be 16-bit Macs for a long time to come; there are manufacturing economies, and not all users need the power of a 32-bit machine. What will be needed is a part that the manufacturers can use in later versions of their low-end machines that handles the instruction set of the 68020 but is electrically compabible with the 68010. A microcode subroutine for multiply would probably be sufficient to provide compatibility across the product line. This part should not be significantly more expensive than the 68010 in volume, or it will not achieve its purpose. Motorola need not be the vendor here. Other vendors make 68010-like parts, including Siemens and Signetics. The latter has its own design, the 68070, now going into volume production. But if Motorola does it, the part may achieve greater acceptance, and should, in time, supersede the 68000/68010. John Nagle
ford@elgar.UUCP (Mike "Ford" Ditto) (06/11/88)
In article <17482@glacier.STANFORD.EDU> jbn@glacier.UUCP (John B. Nagle) writes: >In article <6276@cup.portal.com> thad@cup.portal.com writes: >>Why do you feel there's such a software incompatibility between the various >>680x0 processors? >> > The problem is, of course, the multiply hardware. The floating-point instructions are far more significant, followed by the new addressing modes and the 32-bit instructions. > [ description of new, faster, better software that won't run on the > older CPU's ] ... > This history will repeat itself at the low end, on the Mac and Amiga >lines. As the mainstream products become 68020-based, more software will >be built that assumes a 68020 platform. This software will not run on the >smaller machines of the product line. > > What will be needed is a part that the manufacturers can use in later >versions of their low-end machines that handles the instruction set of the >68020 but is electrically compabible with the 68010. This part already exists, it's Motorola part number MC68010. A relatively simple change to the operating system is required to use it (if the O.S. was written for 68000-only), but then the full 68020 (and '030, and '040, ...) instruction sets can be executed by adding an emulation package. This software can be upgraded as Motorola adds new instructions to the 68000 family, and it will allow normal 68000 code to run at full speed. The emulated instructions will run slower than they would if done in microcode, but they will work. In other words, Motorola has done their part, now Apple, etc., can do their part... if they feel there is a need. At this time, I think it's best for Mac and Amiga software to be distributed in 68000- acceptable form since the 68000-to-68020 ratio is still pretty high. It will change, of course, especially now that Apple and CBM have 68020 and 030 products. -=] Ford [=- "Once there were parking lots, (In Real Life: Mike Ditto) now it's a peaceful oasis. ford%kenobi@crash.CTS.COM This was a Pizza Hut, ...!sdcsvax!crash!kenobi!ford now it's all covered with daisies." -- Talking Heads