English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   support.Hardware (http://eab.abime.net/forumdisplay.php?f=20)
-   -   VXL*30 68030 25Mhz accelerator performance (http://eab.abime.net/showthread.php?t=100394)

psoma 12 January 2020 08:27

VXL*30 68030 25Mhz accelerator performance
 
Hi,

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!?!?

Cheers,

Tom

Jope 12 January 2020 08:44

It has to access RAM at regular A500 speeds, so basically any speed improvement you will see is going to be for long running loops small enough to fit in the 030 caches.

AmigaHope 12 January 2020 08:56

Quote:

Originally Posted by psoma (Post 1371066)
Hi,

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!?!?

Cheers,

Tom

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.

psoma 12 January 2020 09:02

Ahah, this makes sense. So if/when I get some memory plugged into the sidecar via. An A590, I should start to see a performance bump in Frontier?

Cheers,

Tom

AmigaHope 12 January 2020 09:09

Quote:

Originally Posted by psoma (Post 1371072)
Ahah, this makes sense. So if/when I get some memory plugged into the sidecar via. An A590, I should start to see a performance bump in Frontier?

Cheers,

Tom

Yeah probably a 20%-30% performance improvement. If you got a RAM-32 board though you'd see like 200%+ improvement.

psoma 12 January 2020 09:11

Doh! Oh well, better than nothing.

I actually got the A500 to play a few games that run too fast on my A600 so maybe this is a blessing in disguise :)

Thanks again guys.

AmigaHope 12 January 2020 09:19

Quote:

Originally Posted by psoma (Post 1371077)
Doh! Oh well, better than nothing.

I actually got the A500 to play a few games that run too fast on my A600 so maybe this is a blessing in disguise :)

Thanks again guys.

BTW when you plug in that A590 make sure that the baseboard mem is getting added at less priority than the A590's mem, otherwise the system will allocate the baseboard's slow memory first! Your goal will be for software to load its main code into the A590 and then further allocations of data go into the baseboard.

Incidentally the fragmented memory of your baseboard may cause problems for some WHDload slaves that try to allocate memory in one big chunk. e.g. if it tries to cache a floppy by allocating in 880k chunks, those 511k chunks won't be big enough. If it loads data on a file-by-file basis then you it should be okay.

psoma 12 January 2020 11:36

Yep, I’m with you. Might see what happens with respect to contiguous RAM when it’s in 512KB Chip mode. Might still be 512K banks, but might not, in which case I can change the hardware switch back to 512K/1MB Chip seeing switching between 68000/68030 is largely irrelevant without the RAM32...

Liqourice 12 January 2020 18:30

If I had the knowhow I'd make a replacement board for the RAM-32 since I have one, with faulty DIP's though, and use memory that's easy to get. I don't know how many would like such a board though, how many VXL-30 are there out there?

I might consider sending the board to someone WITH the knowhow though. I don't want to part with it entirely even if it's not usable as it is, but if someone could use it as a model for a modern replacement I'm all for it since I could benefint from it myself.

psoma 12 January 2020 20:43

Fascinating! I do know of a number of folk looking for a RAM32 board for their VXLs - I mean, it’s not 10s of people, but I know of at least 3... 4 presuming you’re looking for a replacement too :)

I can solder and build, I just can’t design and engineer, so the challenge is out there - who can take a board like the RAM32, decipher it and come up with a functional equivalent?

AmigaHope 14 January 2020 21:08

Quote:

Originally Posted by psoma (Post 1371161)
Fascinating! I do know of a number of folk looking for a RAM32 board for their VXLs - I mean, it’s not 10s of people, but I know of at least 3... 4 presuming you’re looking for a replacement too :)

I can solder and build, I just can’t design and engineer, so the challenge is out there - who can take a board like the RAM32, decipher it and come up with a functional equivalent?

Well the actual RAM-32 is a bit fancy, it has an onboard kickstart ROM and a very early FPGA with ROM to handle the logic and presumably the autoconfig stuff. Making an exact duplicate would involve sourcing that ancient FPGA and that would be hard.

Probably would be easier to roll your own 32-bit RAM card that just talked to the VXL's bus but did autoconfig its own way. You could extract the ROMs for the FPGA though if you wanted to reverse engineer exactly what it's doing.

psoma 14 January 2020 22:30

Yeah, to be honest, the fancy features and exact 1:1 functionality aren't important to me. I'd just like some RAM presented to the VXL over a 32-bit bus to let the processor do its thing. If that involves running 50 wires around the case and some sticky tape, heck, I'll do it :)

r.cade 15 January 2020 00:04

That's going to be very difficult to figure out how to do that. I think your best bet will be to get a different accellerator and just set that aside in case you ever run across the memory board for it. Without that, as you found, it's mostly useless.

Liqourice 17 January 2020 21:30

Not gonna happen then I guess.

Roux NZ 17 January 2020 23:45

Hi , just expressing interest in a replacement ram board if anyone does reverse engineer one and produce them. Thanks!


All times are GMT +2. The time now is 00:06.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.04296 seconds with 11 queries