aduncan@rhea.trl.oz.au (Allan Duncan) (01/15/90)
Some of the WARS-II I concur with, some I don't. Just a few comments from this distant land. > 3) Commodore-Amiga does not sell the needed patch. There is no offical > support for the patch. > > Therefore, "Amiga does not support the 68010". I'm sure it's "in there" for 1.4, so will the Amiga then support the 68010? It might be in the SetPatch too, but I'm not going to reboot now to find out! > As to statement (d: '030 MMU is not upward compatible with the 68851): I always thought the '030 MMU was a subset of the '851, and was described as such. The realities of silicon real estate must crop up somewhere! > Assertion a: MOVE SR is a quirk in the definition of the 68000. > Assertion b: MOVE SR is a bug in the definition of the 68K family. > As to opinion h (68000 should be replace by the 68010), think how > much simpler this whole mess would be if Motorola had just admited > the mistake and replaced the 68000 with the '010. The whole family > would then really be compatible and much nasty code would have been > avoided. > > I also realize that it was politically impossible for Motorola (or > anyone else, for that matter) to admit it as a design flaw, they > had to sell the '010 as a "Newer, Better Chip" that allows virtual > machines. They probably also thought they could price the '010 > higher and make more money. Oh well, reality intrudes again. Now for some flack.... I go back a long way in micros (in fact as far as pre IC), and can remember when there was only the 68000. One of the problems that was found was that when building paged virtual memory, a page fault could occur deep in some complex instruction which was then aborted while the new page was fetched in. Because of the potential for some intermediate stage of the addressing calculation leading to the page fault to have irrevocably changed the environment, and the absence of the EXACT internal state of the processor at the time of the page fault, it was impossible to continue the program with any certainty. Solutions to this included the second processor strategy mentioned previously. When this difficulty (bug?) came to Motorola's attention, they produced a new version of the chip that preserved the internal state. Whilst they were at it, they also beefed up the chip and added a little bit for the theoreticians - virtual machine capability. Note the priorities. As an aside, the 68000 was hand laid in tape. I believe all others since then have been done with CAD. What has puzzled me slightly is why the 68000 has continued to be used in preference to the 68010. Price is usually determined by the area of silicon consumed, all I can suggest is that there were more generous second sourcing agreements for the 68000, with the result that they are turned out like sausages, with varying qualities - one of the first things to do when expansion boxes don't work is to put in a GENUINE 68000! Well, Mostek were given Motorola masks at the start, I don't know how it has gone since then. As to the suggestion that Motorola are ripping you off with the price of the 68010, have you done a price comparison with the Intel stuff? I continue to be astounded at what they ask (and get) for mediocre silicon! Allan Duncan ACSnet aduncan@rhea.trl.oz ARPA aduncan%rhea.trl.oz.au@uunet.uu.net UUCP {uunet,hplabs,ukc}!munnari!rhea.trl.oz.au!aduncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia.