Conference hydra::amiga_v1

    
    I have been runing with an 010 in my Amiga for almost a year now
    and havn't found anything that won't work with it (short of
    Transformer and the V1.1 WB Calculator.)
    
    If you are runing under 1.1 of the OS, you will want to get a copy of
    the DeciGEL program (I can upload if you like) and add it to your
    startup-sequence.  Basically, this program establishes a "privileged
    instruction trap" handler which intercepts all priv'd instructions
    on the processor.  Because a 000 MOVE SR instruction will cause
    a priv-vio on the 010 (unless the processor is in supervisor mode),
    this routine will kick off mid-stream during the execution of the
    instruction, change mode to supervisor, execute the instruction,
    and return back to user -all transparently to the software-.
    Basically, in effect, making your system %100 compatible with all
    000 software.  Obviously, any code which depends on CPU timing,
    etc.. will break, as the 010 is much faster than the 000, but like
    I said, I havn't found anything that abusive of the system in a
    year of intense Amigaing: EXCEPT TRANSFORMER.  Transformer is (in
    my opinion) junk anyway.  It won't run under V1.2 of the OS either.
    I sure like the idea of S/W emulation though.
        
    V1.2 *I think* has the above routine built-into it.  At minimum,
    they fixed the calculator program so it doesn't do a MOVE SR anymore.
    (That is to say, I have had no probs runing V1.2 since January with
    an 010 and no DeciGEL wedge.)
        
    The performance improvement gained by an 010 upgrade is definitely
    worth the $74 for the chip!  You gain between 5% and 50% depending
    on the operation.  Floating point mathematics, for example, are
    sped up considerably (40%-50%.)  Basic MOVE, BRANCH/JUMP type
    instructions don't benifit that much (maybe only 5-20%.)  Tightly
    bound sequences of repetative instructions (eg, loops) benifit from
    the increased efficiency and optimizations done in the 010 internal
    logic and speed up by a factor of roughly 15-30%.
    
    Basically, what you are looking at is a $74 (relatively inexpensive)
    supercharge for your $1k+ Amiga!  It is definitely a bargin.  (I
    remember trying to speed up TRS80's along time ago in a galaxy far
    far away...)
    
    In any case, I have a spec sheet from Motorola on the benifits of
    68000 to 68010 upgrading that came along with the DeciGEL program
    from my favorite BBS.  I will add here as time permits (need to
    upload from my Amiga at home!)
    
    The upgrade is as simple as swapping out the chips.
    
    -Tom Gray

    Thanks for the response... I can get the 68010 for $55.00 from Future
    Electronics, which makes it an even better bargain!
    
    I really don't use Transformer myself, but I keep it in reserve
    in case I have to give an emergency demo to a prospective Amiga
    buyer.
    

    Ed,
    
    If you have DBW_RENDER, I would be interested if you ran something
    before making the 010 swap, then ran the same thing afterwards and
    measured the difference.  I would consider doing the same thing
    (and risk blowing up my Amiga, since I'm pretty much of a hardware
    klutz), but only if DBW_RENDER *was* verified to run 40-50% faster.
    
    -jim

    I hope to be able to make the swap this weekend, and I'll post any
    benchmarks I can come up with here.  

    
    Here's another Q. Will the titles written in raw 68000 code work
    with the upgrade? If not, I'm wondering about the possibility of
    a 68000/68010 dip switch? Any ideas/suggestions?
    
    

    I made the swap last night.  The whole job took under a half hour,
    most of which was spent prying the damn case apart.  I was pleasantly
    surprised to see that my vintage Amiga (Oct. '85) didn't have a
    single wirewrap or ECO on the motherboard.  This thing is built
    like a tank.
    
    The 68000 came out with a brisk pry with a nail file, and the '010
    popped right in.
    
    I bother to do much benchmarking with the 68000 in, (sorry, no data
    on DBW_Render), but I did benchmark a Mandelbrot Fractal and a looong
    problem in AmigaBASIC.
    
    
    Benchmark					68000		68010
    
    AmigaBASIC program that graphs a three      7:13             6:40
    dimensional function of the form 
    Z=(sin^2(x)/x^2)*(sin^2(y)/y^2) from
    the region x=-20 to 20 and y=-20 to 20
    The program plots a 3D graph of the 
    function on a 640x400 4 color window, 
    and uses 64 data points for the graph
    
    Mandelbrot Fractal on a 16 color            1:03              :52
    640 x 400 screen
    
    My own custom-crafted AmigaBASIC             :27              :23
    program that iteratively solves
    for the velocity switch point during
    an exponential velocity seek for 
    a linear actuator for a disk drive
   
    As you can see, the speedup for AmigaBASIC programs is around 10-15%.
    Not breathtaking, but not bad for $55.00 and a half hour of my time.
    By the way, Flight Simulator works just fine too.  If I find any
    programs that don't work, I'll post them here.  I am a pretty depraved
    gamer, so I suspect I may see some problems eventually.  I have
    not had to use DeciGEL yet, but I am keeping it nearby.
    
    It looks lke there could be some real speedups from a 68881 hardware
    fpp upgrade.  I am anxiously awaiting the MicroBotics multifunction
    module, which comes with software to replace AmigaDOS' software
    floating point libraries.

    Just as a follow up report, I've had absolutely NO compatibility
    problems with the 68010 installed.  Games, Aegis Draw, DPaint ][,
    Deluxe Music, you name it, it all works fine.  I haven't even had
    to use Decigel yet either.
    
    A while back, a series of notes went out on comp.sys.atari that
    the Amiga would not support a 68010.  Well, that is pure crap. 
    It works like a charm.
    

Re: .7

>    A while back, a series of notes went out on comp.sys.atari that
>    the Amiga would not support a 68010.  Well, that is pure crap. 

It sure is.  The Amiga has supported the 68010 and the 68020 for almost
a year.  Kickstart 1.1 was released with the explicit goal of supporting
the 68010 and 68020: the only thing that didn't support the 68010 and 68020
was the calculator program.  I read this in the developer's notes for 1.1.

When 1.2 was released, C/A was bright enough to realize that people
had been ignoring their pleas not to use instructions that were
privileged on the 68010, and so put the trap handler that fixes up
such abuses into Kickstart.

Considering that every one of the ROM Kernal Manuals begins with a
polemic demanding that you write your code compatibly with a 68010
and 68020, you would think that 68010 support would not be considered
a surprise.  Considering that every Amiga magazine has an advertisement
for CSA's 68020 turbo Amiga, 68020 support should be no surprise either.
Where do ST users get their information on the Amiga?  Do they just make
it up, or do they get it straight from the Atari disinformation headquarters?

    re: -2
    
    Ed, 
    
    Are you sure everything is perfect.  I understand your neighbor's
    garage door opens every time you click the left button on your mouse
    now...;-)
    
    Randy
    

                     -< Amiga information from the USENET >-
================================================================================
Note 718.0  Memory Fill/Copy/Compare statistics + some assembly exam  No replies
LABC::GRAY "CORY.BERKELEY.EDU!dillon"               186 lines  25-APR-1987 00:51
--------------------------------------------------------------------------------

Newsgroups: comp.sys.amiga
Path: decwrl!decvax!ucbvax!CORY.BERKELEY.EDU!dillon
Subject: Memory Fill/Copy/Compare statistics + some assembly examples w/ DBcc
Posted: 24 Apr 87 05:35:18 GMT
Organization: 
 
 
	(I better sign my name here... this is a long article)
 
				-Matt
 
	Here is a good example of how to use a DBcc statement, including
how to extend it to handle counts larger than 16 bits (only two more
instructions).  I've tested all three of these routines.
 
	The routines transfer information a byte at a time.  Theoretically,
transfering information a word or a long at a time would be about 2x and 4x
as fast, but you need to add code to take care of initial an trailing 
alignment.  If you made a restriction that the supplied arguments were on
word or long boundries, and the size in multiples of 2 or 4 bytes, you
could implement such an improvment by a simple shift of the count register
to the right by 1 or 2 before beginning the loop, and using move.w/move.l
instead of move.b in the code below.
 
	The best example for the use of DBcc is the BCMP() routine, which
employs an actual condition (it uses DBNE) to exit the loop on compare
failure.
 
68000 specs,  clock-cycles-per-loop/MBytes-per-second on Amiga
where the MBsec is the total transfer rate.  E.g. if you want to zero
396K, it will take a second.  If you want to move 324K from one place to
another it will take a second.
 
68000 @ 7.14Mhz
				BSET/BZERO	BMOV		BCMP
 
	as is:			18/0.396 MBsec	22/0.324 MBsec	22/0.324 MBsec
	mod for	word at a time	18/0.793 MBsec	22/0.649 MBsec	22/0.649 MBsec
	mod for long at a time	22/1.298 MBsec	30/0.952 MBsec	30/0.952 MBsec
 
 
Transfering a long at a time is about 3x faster than transfering a byte at a
time.  A 68010 can do memory fills/moves/compares from 1.3x to 1.6x faster 
than a 68000 can (1.6x for fills, 1.3x for moves/compares).
 
-----------------------------------------------------------
 
Oh yah.. extending the count beyond 16 bits.  Just look at the assembly.
Since DBcc only effects the lower word of a data register, you can still use
a single data register to hold the 32-bit 'count' you want, and simply add
a two instruction outer loop after the DBcc inner loop.
 
 
--- Just for kicks, this is what a 68010 would give you ---
 
Since the loops in all cases will take two instructions, both a word in size,
if you have a 68010 it will enter loop mode operation, which gives 
significantly faster results: (clock cycle times are for the meat of the loop)
 
68010 @ 7.14Mhz
				BSET/BZERO	BMOV		BCMP
 
	as is:			10/0.714 MBsec	14/0.510 MBsec	14/0.510 MBsec
	mod for	word at a time	10/1.428 MBsec	14/1.002 MBsec	14/1.002 MBsec
	mod for long at a time	14/2.040 MBsec	22/1.298 MBsec	22/1.298 MBsec
 
 
 
NOTE: All passed arguments are 32 bits each 
 
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
#	bcmp.asm
#	bmov.asm
#	bset.asm
# This archive created: Thu Apr 23 20:56:55 1987
export PATH; PATH=/bin:/usr/bin:$PATH
echo shar: "extracting 'bcmp.asm'" '(590 characters)'
if test -f 'bcmp.asm'
then
	echo shar: "will not over-write existing file 'bcmp.asm'"
else
cat << \!Funky!Stuff! > 'bcmp.asm'
 
;BCMP.ASM
;	using byte operations
;
;   BCMP(p1,p2,n)   return 0=failed, 1=compare ok
 
     xdef  _bcmp
 
_bcmp:
	movem.l	4(A7),A0/A1	;A0 = ptr1, A1 = ptr2
	move.l	12(A7),D1	;# bytes
	clr.l	D0		;def. return value is false, also sets Z bit
	bra	drop		;drop into the DBF loop
loop	cmpm.b	(A0)+,(A1)+
drop	dbne.w	D1,loop		;until count exhausted or compare failed
	bne	end
	sub.l	#$10000,D1	;for buffers >65535
	bpl	loop		;branch	to loop	because	D0.W now is FFFF
	addq.l	#1,D0		;return	TRUE
end	rts
 
 
!Funky!Stuff!
fi  # end of overwriting check
echo shar: "extracting 'bmov.asm'" '(504 characters)'
if test -f 'bmov.asm'
then
	echo shar: "will not over-write existing file 'bmov.asm'"
else
cat << \!Funky!Stuff! > 'bmov.asm'
 
;BMOV.ASM
;      4    8	12
;BMOV(src,dest,bytes)
;
 
	xdef  _bmov
 
_bmov
	move.l	4(A7),A0	;source
	move.l	8(A7),A1	;destination
	move.l	12(A7),D0	;bytes
	cmp.l	A0,A1
	beq	end		;trivial case
	ble	dropfwd		;forward copy  (dest < src)
	add.l	D0,A0		;backward copy (dest > src)
	add.l	D0,A1
	bra	dropbck
 
loopfwd	move.b	(A0)+,(A1)+
dropfwd	dbf.w	D0,loopfwd
	sub.l	#$10000,D0
	bpl	loopfwd
	bra	end
 
loopbck	move.b	-(A0),-(A1)
dropbck	dbf.w	D0,loopbck
	sub.l	#$10000,D0
	bpl	loopbck
end	move.l	8(A7),D0
	rts
 
 
!Funky!Stuff!
fi  # end of overwriting check
echo shar: "extracting 'bset.asm'" '(593 characters)'
if test -f 'bset.asm'
then
	echo shar: "will not over-write existing file 'bset.asm'"
else
cat << \!Funky!Stuff! > 'bset.asm'
 
;BSET.ASM
;BZERO.ASM
;
 
     xdef  _bset
     xdef  _bzero
 
_bzero
	clr.l	D1
	bra	begin
_bset
	move.b	15(A7),D1	;12(A7)-> msb .	. lsb	(D1.B = data)
begin
	move.l	4(A7),A0	;A0 = pointer to memory
	move.l	8(A7),D0	;D0 = bytes to set
	bra	drop		;drop into the DBF loop
loop	move.b	D1,(A0)+
drop	dbf.w	D0,loop		;remember, only	effects	lower word
	sub.l	#$10000,D0	;for buffers >65535
	bpl	loop		;branch	to loop	because	D0.W now is FFFF
	move.l	4(A7),D0	;return	pointer	to buffer start
	rts
 
 
!Funky!Stuff!
fi  # end of overwriting check
exit 0
#	End of shell archive

    I have another question concerning the 68010.  According to Computer
    Shopper advertisements, there are at least two versions.  One of
    them runs at a max of 8 MHz, and the other, I believe, runs at 10
    MHz.  (It might be 12, but I don't remember)  At any rate, would
    it be any better to spend the extra for the 10 MHz version?  If
    so, would I have to alter the clock speed?  Is altering the clock
    speed possible to any extent without annoying the custom chips?
    
    Chris
    

>    Would it be any better to spend the extra for the 10 MHz version?  If
>    so, would I have to alter the clock speed?  
    
    The 10 MHz spec refers to the maximim clock speed at which the chip
    _can_ operate.  To turn this around, the 680x0 in your machine must
    be rated 8 MHz or higher.  There's no real advantage to using the
    faster chip at the Amiga's standard 7.14 MHz clock speed.
    
>    Is altering the clock
>    speed possible to any extent without annoying the custom chips?
    
    No.  The 7.14+ MHz clock speed is twice the NTSC television colorburst
    frequency.  In other words, if you speed up the Amiga clock, you
    speed up the video refresh rate to some non-standard value.  This
    is a problem mostly if you want to record the video from your machine.
    Practically speaking, though, it's unlikely the custom chips and
    DRAM can go much faster without getting into the area of flaky operation.