ccemdd@rivm.UUCP (Marco Dedecker) (07/17/89)
I own an A500, and I would like to know if there is someone that has replaced his 68000 by an 68010. I am thinking of replacing my 68000 by an 68010, but there are somethings I need to know. - Is swapping the chips all you need to do, or are there some other ajustments you have to make ? - Does all the software still work with the 68010 ? - What are the advantages of the 68010 ? I remember someone sending a list of advantages of the 68010, but at that time I wasn't interested, so I don't have it anymore. I would appreciate it if someone could send me that list. Thanks in advance, Marco Dedecker
raz%kilowatt@Sun.COM (Steve -Raz- Berry) (07/18/89)
In article <1407@rivm05.UUCP> ccemdd@rivm.UUCP (Marco Dedecker) writes: >I own an A500, and I would like to know if there is someone that has >replaced his 68000 by an 68010. Way back in the begining I owned an A500. I also upgraded to a 68010 when I was able to get a engineering sample from a local Moto rep. >I am thinking of replacing my 68000 by an 68010, but there are >somethings I need to know. >- Is swapping the chips all you need to do, or are there some other > ajustments you have to make ? That's all there is to it. The Amiga OS will automaticly figure out that you have installed a '010 and accomodate it. Of course opening the A500's case is no walk in the park, so it's not as simple as it sounds. Also remember that your warentee will be void if you open the case. >- Does all the software still work with the 68010 ? NO. Some games won't work. There may be other "productivity" software that won't work either. The way I would test any new software that you buy would be to check it out on a A2620 machine at your local dealer first. Chances are that if it works on the A2620, it *probably* will work on the '010. There are a few PD programs that will "fix" an improperly written program to run on a '010. The two that I am aware of are Fix68010 and Decigel (I think). Don't ask me for them cause I don't have them anymore. >- What are the advantages of the 68010 ? > >I remember someone sending a list of advantages of the 68010, but >at that time I wasn't interested, so I don't have it anymore. >I would appreciate it if someone could send me that list. I'll give you what I remember. 10% speed improvement. This is due to optimization of the nano-code that executes the instructions. 3 line instruction cache. This allows very small loops to execute internal to the chip. It's effect however is nearly nil except in very rare cases. More internal state information is dumped on the stack during exceptions to allow the processor to resume exectution properly. The 68k didn't save enough state to allow a vertual memory system to function properly. The 68010 does. The MOVE <sr>,ea (or are the operands the otherway around?) was moved to be a supervisor only instruction. Properly written programs will not use this instruction so you should be safe right?? ;-| >Thanks in advance, One caveat, I had MASSIVE problems with my system with a '010 and the FFS when 1.3 came out. This turned out to be a problem with the '010 itself and was fixed by replacing the chip with the original 68K. It took me ages to find, mainly because everything worked fine with the old file system, and I was beta testing the FFS before it was released. I don't know how many times I saw the R/W error eat my hard disk. Andy was real patient with me, even though I was probably driving him crazy with a problem he couldn't fix. So the moral is BE CAREFUL and back up everything first. >Marco Dedecker I want to make it completely clear that the '010 functions prefectly fine in the Amiga. My problems occured because of a bad sample. -- Steve -Raz- Berry Disclaimer: I didn't do nutin! UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com KILOWATT: sun!kilowatt!archive-server archive-server%kilowatt.EBay@sun.com
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (07/18/89)
In article <116164@sun.Eng.Sun.COM> raz@sun.UUCP (Steve -Raz- Berry) writes: <In article <1407@rivm05.UUCP> ccemdd@rivm.UUCP (Marco Dedecker) writes: <>I own an A500, and I would like to know if there is someone that has <>replaced his 68000 by an 68010. < <Way back in the begining I owned an A500. I also upgraded to a 68010 <when I was able to get a engineering sample from a local Moto rep. Long before there was an A500, I dropped a 68010 into an A1000. Other than the problems of yanking & replacing the chip, there shouldn't be much difference. <>- Does all the software still work with the 68010 ? < <NO. Some games won't work. There may be other "productivity" software <that won't work either. The way I would test any new software that <you buy would be to check it out on a A2620 machine at your local <dealer first. Chances are that if it works on the A2620, it *probably* <will work on the '010. Almost everything post 1.1 will work. You can fix most applications by running decigel (which catches the exception generated by the '010, does the right thing, and returns), which can be found on Fish Disk 18. On the other hand, the '010 tends to break copy protection schemes. Also, badly written (the rule about not using the sr moves is the _first thing_ in the Amiga (not AW) version of the RKMs) games that don't let you have a startup-sequence can't be fixed. <>- What are the advantages of the 68010 ? <> <>I remember someone sending a list of advantages of the 68010, but <>at that time I wasn't interested, so I don't have it anymore. <>I would appreciate it if someone could send me that list. < <I'll give you what I remember. < <10% speed improvement. This is due to optimization of the nano-code <that executes the instructions. Motorola claims up to 25%. I measured about 5% when I did the drop-in. It all depends on your applications. <3 line instruction cache. This allows very small loops to execute <internal to the chip. It's effect however is nearly nil except in <very rare cases. Only if you use the wrong compiler :-). Lattice 5.0 can be told to generate optimal code for the '0x0, x = 0, 1, 2, 3. Default is to generate code for "all", whatever that means. In reality, most any simple operation on a block of memory (like copying it, or searching for a value) can be written to land in that cache. This means that those operations don't wait for intermediate instruction fetches, and get to run at memory speed (much nicer than an unnamed architechtures "block move instructions"; also more usefull). <The MOVE <sr>,ea (or are the operands the otherway around?) was moved <to be a supervisor only instruction. Properly written programs will <not use this instruction so you should be safe right?? ;-| This is what breaks programs that decigel fixes. <>Thanks in advance, < <One caveat, I had MASSIVE problems with my system with a '010 and the <FFS when 1.3 came out. This turned out to be a problem with the '010 <itself and was fixed by replacing the chip with the original 68K. Note that the tighter specs on the '010 make the converse more likely to be true. Converting to a ceramic '010 is a recommended step when dealing with the "double expansion guru blues." <mike -- Come all you rolling minstrels, Mike Meyer And together we will try, mwm@berkeley.edu To rouse the spirit of the air, ucbvax!mwm And move the rolling sky. mwm@ucbjade.BITNET
wdimm@lehi3b15.csee.Lehigh.EDU (William Dimm) (07/19/89)
Since the person who was talking about using the 68010 said that he had problems when he switched to FFS, I just wanted to comment that the 68010 definitely does work with FFS (he didn't say that it didn't, but he didn't say that it did...). I am using mine in an Amiga 1000, with a CLtd SCSI controller. Version 3.0 of their SCSIdos works fine with a 68010, although there may have been a problem with earlier versions (I had some troubles, but couldn't 'definitely' blame them on the 68010). Now, my question. Am I correct in assuming that the 'C10' (or whatever the letter was - maybe it was 'L') at the end of the '68010' on my chip means that it is 10Mhz? Are there faster ones available? Do you need anything special to run a faster 68010, and how much do they cost? Bill Dimm wdimm@lehi3b15.csee.Lehigh.EDU wcd0@lehigh.BITNET
raz%kilowatt@Sun.COM (Steve -Raz- Berry) (07/19/89)
In article <26405@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: )>In article <116164@sun.Eng.Sun.COM> raz@sun.UUCP (Steve -Raz- Berry) writes: )><In article <1407@rivm05.UUCP> ccemdd@rivm.UUCP (Marco Dedecker) writes: )<>I own an A500, and I would like to know if there is someone that has )<>replaced his 68000 by an 68010. )<3 line instruction cache. This allows very small loops to execute )<internal to the chip. It's effect however is nearly nil except in )<very rare cases. )Only if you use the wrong compiler :-). Lattice 5.0 can be told to )generate optimal code for the '0x0, x = 0, 1, 2, 3. Default is to )generate code for "all", whatever that means. Hey, watch it. Astec is coming out with V5.0 RSN ;-( )In reality, most any simple operation on a block of memory (like copying it, )or searching for a value) can be written to land in that cache. This )means that those operations don't wait for intermediate instruction )fetches, and get to run at memory speed (much nicer than an unnamed )architechtures "block move instructions"; also more usefull). Gee, I thought that was what the blitter was for :-) Can you show me examples of how Lattice optimizes code for the '010? I can't think of hardly anything else that such a small cache could be used for besides block moves. What kind of tight loop uses only three words? )<One caveat, I had MASSIVE problems with my system with a '010 and the )<FFS when 1.3 came out. This turned out to be a problem with the '010 )<itself and was fixed by replacing the chip with the original 68K. )Note that the tighter specs on the '010 make the converse more likely )to be true. Converting to a ceramic '010 is a recommended step when )dealing with the "double expansion guru blues." I think you misunderstood me. I *did* blame the '010 (for being fried). I would have prefered a ceramic part, but hey, it was free. I was just trying to impress upon the need for caution. )Come all you rolling minstrels, Mike Meyer ---- Steve -Raz- Berry Disclaimer: I didn't do nutin! UUCP: sun!kilowatt!raz ARPA: raz%kilowatt.EBay@sun.com KILOWATT: sun!kilowatt!archive-server archive-server%kilowatt.EBay@sun.com
dbk@teroach.UUCP (Dave Kinzer) (07/19/89)
In article <116272@sun.Eng.Sun.COM> raz@sun.UUCP (Steve -Raz- Berry) writes: [ about 68000s ] >Both of the letters sound right. I believe that it stands for the >package type, L for plastic and C for ceramic. Yes that means that it >is a 10Mhz part. Yes, you can get them as fast as 12.5Mhz. Not quite >fast enough for the CMI PA, and not an even multiple of the Ami's L- Plastic, G - Ceramic, RC, ZB, ZC - Shapes not destined for your computer. 68000s are now available in 16MHz flavor too. >I have redirected followups to c.s.a.t -and it worked! | // GOATS - Gladly Offering All Their Support Dave Kinzer (602)897-3085| | // >> In Hell you need 4Mb to Multitask! << uunet!mcdphx!teroach!dbk | | \X/ #define policy_maker(name) (name->salary > 3 * dave.salary) |
mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (07/19/89)
In article <116365@sun.Eng.Sun.COM> raz@sun.UUCP (Steve -Raz- Berry) writes: <In article <26405@agate.BERKELEY.EDU> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: <)>In article <116164@sun.Eng.Sun.COM> raz@sun.UUCP (Steve -Raz- Berry) writes: <)><In article <1407@rivm05.UUCP> ccemdd@rivm.UUCP (Marco Dedecker) writes: <)<>I own an A500, and I would like to know if there is someone that has <)<>replaced his 68000 by an 68010. < <)<3 line instruction cache. This allows very small loops to execute <)<internal to the chip. It's effect however is nearly nil except in <)<very rare cases. < <)In reality, most any simple operation on a block of memory (like copying it, <)or searching for a value) can be written to land in that cache. This <)means that those operations don't wait for intermediate instruction <)fetches, and get to run at memory speed (much nicer than an unnamed <)architechtures "block move instructions"; also more usefull). < <Gee, I thought that was what the blitter was for :-) You're right, the blitter does that. On the other hand, the 68010 may be able to do it faster. The difference will be small. Except that the Amiga has dual-ported memory, so the CPU can be doing usefull things while the blitter is doing the block op. On '0[123]0 systems without dual-ported memory, a blitter is a waste as far as speed is concerned. <Can you show me <examples of how Lattice optimizes code for the '010? I can't think of <hardly anything else that such a small cache could be used for besides <block moves. What kind of tight loop uses only three words? No, I can't show you code from Lattice, because I haven't gone looking for it. Maybe one of the SAS or Lattice people will talk about it. I do know that the mem* routines have been using dbcc instructions in ways that will run in loop mode since 4.0. Currently, they get generatted inline (who wants to waste time calling functions for those?). The actual criterion is a single 1-word instruction before a dbcc instruction. Things that come to mind to fit that are: checksums. Bit counting. long-precision arithmetic. Probably others. Finally, Josh Rovero <PROVERO@WSMR-SIMTEL20.ARMY.MIL> reported by mail that RAM: ran 40% faster after converting to an '010. I haven't verified it, and I'm not going to go disassemble my machine to do so. <)Note that the tighter specs on the '010 make the converse more likely <)to be true. Converting to a ceramic '010 is a recommended step when <)dealing with the "double expansion guru blues." < <I think you misunderstood me. I *did* blame the '010 (for being <fried). I would have prefered a ceramic part, but hey, it was free. <I was just trying to impress upon the need for caution. I didn't mistunderstand you. I just wanted to point out that things are more likely to improve than the opposite when going to an '010. <mike -- So this is where the future lies Mike Meyer In a beer gut belly; In an open fly mwm@berkeley.edu Brilcreamed, acrylic, mindless boys ucbvax!mwm Punching, kicking, making noise mwm@ucbjade.BITNET
scott@ssgp32.UU.NET (Scott Evernden) (07/20/89)
In article <1407@rivm05.UUCP>, ccemdd@rivm.UUCP (Marco Dedecker) writes: > I am thinking of replacing my 68000 by an 68010, but there are > somethings I need to know. > > - Is swapping the chips all you need to do, or are there some other > ajustments you have to make ? Thats all you need to do. I switched mine over 2 years ago with no ill effects. > - Does all the software still work with the 68010 ? All current software (that I have anyways) works just fine. (The old pre-1.2 Calculator used to blow up on /0 errors). Even A-Max works properly with the 68010 (w/ 128K ROMS of course). There is a PD program called "decigel" available in various places which patches the trap vector for the 1 instruction which is incompatible. I can't remember the last time I used "decigel". > - What are the advantages of the 68010 ? About 7% speed improvement as measured by Jez San's Amiga Speed Program (recently on BIX and elsewhere). This number is about exactly what I have experienced up to now, and I think it agrees with Motorola's own figures. I think the speedup is noticeable, but then I can also see infrared and hear to 25KHz ;-), so... Should you replace your 68000 with a 68010? Well, they don't cost $60 anymore (what like $12 or so??), so you can't really lose. You can always go back... -scott -- Scott Evernden PRIME Computer Inc. scott@ssgp32.Prime.COM Commercial Systems Group uunet!ssgp32!scott Technology Drive (508) 478-8600 x2984 Milford, MA 01757
thad@cup.portal.com (Thad P Floryan) (07/20/89)
Steve -Raz- Berry asks: " ... block moves. What kind of tight loop uses only three words? " regarding the 68010. To keep things simple (and keeping within the spirit of the copyright law permitting "extractions" for purposes such as this), on pages 264-265 of the book "68000,,68010,68020 PRIMER" by Stan Kelly-Bootle and Bob Fowler (SAMS), we find: " The MC68010 automatically detects when certain 3-word instruction loops have repeated more than one time, and then goes into loop mode. In this mode, the instructions are not repeatedly fetched from memory, as would occur during normal operation, but are locked into the CPU pre-fetch queue and decode register, and not fetched again. If the loop is interrupted by any exceptions, loop mode will resume after returning and going through two or more loop repetitions. Thus, simple loops such as the movement of a block of bytes, the summation of a list of numbers, and the shifting of a group of numbers, can be executed at speeds comparable to the speed of a single (for example, block move) instruction. The allowable loops consist of certain 1-word instructions followed by a DBcc instruction ..... " Certain forms of the following instructions are "loop mode-able": MOVE, ADD, SUB, CMP, AND, OR, EOR, ABCD, ADDX, SBCD, SUBX, CLR, NEG, NEGX, NOT, TST, NBCD, ASL, ASR, LSL, LSR, ROL, ROR, ROXL and ROXR. See the book (and other similar ones) for more info. Steve's comments re: the blitter neglect the fact the blitter will NOT operate in "FAST" RAM; it is limited to CHIP ram. If someone makes a peripheral card utilizing one of Motorola's 68000-family dual DMA chips (or some other vendors' chips), many of the block move features of the blitter can THEN be done in FAST ram. People seem to overlook that DMA can go "three ways": 1) RAM to <something else> 2) <something else> to RAM 3) RAM to RAM As to whether this is feasible on the (synchronously-clocked) Amiga is something I have NOT investigated at all. Something with more "free time" will, I'm sure, have real fun exploring these (and other) possibilities! :-) Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]