View Single Post
Old 12 January 2020, 08:56   #3
Registered User
Join Date: Sep 2006
Location: New Sandusky
Posts: 685
Originally Posted by psoma View Post

I picked up an A500 with a 25Mhz VXL*30 68030 accelerator board. Now, the thing doesn't have the optional RAM32 board attached, and I've been told that without it there's virtually "no acceleration" but I couldn't, nay, wouldn't believe that... Sure, for WB usage and loading to/from RAM, I can see how going over the standard bus would prohibit the accelerator spreading its wings, but surely the 68030 @ 25Mhz would run, say, Frontier better than an 8Mhz 68000?!?

So, no. It appears it doesn't.

Flicking between the 68000 and 68030 the intro performance was more or less imperceptible. Can anyone explain why this is the case?!? Again - I accept that general purpose app usage would be slow, but why is the ability to render a pre-loaded 3D scene not improved (apparently) one iota by a CPU that should be 3 times as fast?!?

I compare this to my A600 with a 33Mhz 68030 Furia and the intro flies. I don't get it!?!?


The 68030 will get better performance in three ways:

1) Faster instruction execution (less cycles per instruction)
2) Faster memory bandwidth (either from cache or from main ram)
3) Better instructions that do more (on 020/030 vs 000 this means 32->64 precision MULs/DIVs)

In your case you're only really getting help from 1), which isn't helping you much. Your CPU is sitting spending most of its time doing nothing waiting for data to feed it. You could theoretically get help from 3), but Frontier is not written to do this.

You are getting some speedup from your caches, but on 030 they are only 256 bytes, which means they only really shine in tight loops on smaller amounts of data. Run some tight code like hand-optimized compression software or something and you'll notice it runs much better than your 68000. A chess program will probably run way faster at the same AI settings as well.

Meanwhile Frontier is constantly blowing the cache away transferring large amounts of data that have no way of fitting in those tiny of caches. Bits of the render loop might fit in the instruction cache but there's so much physics going on in Frontier that the code almost certainly is getting flushed a lot too.

In the worst case you're on a slow-ram only system (i.e. trapdoor memory) -- that hurts performance in color-heavy displays even on the stock 68000 -- it will speed up by like 20% just from adding real 7Mhz fast mem. That's also why the stock A1200 was so crippled (adding fast memory literally doubled the speed).

68000-optimized games like Frontier also eschew the slower instructions like DIV that were improved the most on the 020/30, preferring to do calculations using bit-shifting, etc. which aren't significantly improved. This is all done to keep the CPU from stalling the rendering process as much as possible.

The original Amiga team were pretty smart. They balanced the normal half-and-half DMA mode of the Amiga to keep a 7Mhz 68000 fed as fast is it could calculate it under typical code. They then left the option to add more local ram for the CPU if you wanted better performance in heavy graphics situations (e.g. 16-color hires). This bus is only meant to feed a 68000 at 7Mhz. You could have the fastest Bugatti Veyron but it wouldn't go very fast if you put the fuel pump from a Smart Car in it.

Last edited by AmigaHope; 12 January 2020 at 09:07.
AmigaHope is offline  
Page generated in 0.04285 seconds with 11 queries