The Beast 030 (CD32)

[SpeedGeek]

Wow! Very impressive! A 68030 CPU overclocked to 70 MHz?

Seems like a name change is in order:

Mega-Clock Beast 030, Ultra-High-Speed Beast 030, etc.

Anyway, good work.

[Lunda]

Originally Posted by alenppc

As somebody who has hand-built over 800 CD32 accelerators, I have to ask: where did you find WHITE MCU connectors for the kipper riser? I've only ever seen them in brown

800! . I've built 3(one of each rev.) and almost had enough.

I had brown connectors too. I swapped them out because I thought they had gone bad(they had not btw). I was in a hurry and used PCI connectors I already had at home. It works but I wouldn't recommend it. There was some Dremel and glue work involved...

[abu_the_monkey]

it certainly looks to give the 4000/040 a run for its money in all but float point operations, probably due to the local fast ram, but, it would be nice to see how it performs in real world use, maybe with something demanding like KarlosTKG

https://github.com/0xABADCAFE/karlos-tkg

the comparison was the AIBB module Beast 030@70 vs A4000/040@25

[alenppc]

Originally Posted by Lunda

800! . I've built 3(one of each rev.) and almost had enough.

I had brown connectors too. I swapped them out because I thought they had gone bad(they had not btw). I was in a hurry and used PCI connectors I already had at home. It works but I wouldn't recommend it. There was some Dremel and glue work involved...

That's what I suspected Make sure that the card edge is always bevelled or it will be extremely easy to bend/destroy pins on those connectors... learned this the hard way.

[Lunda]

Originally Posted by alenppc

That's what I suspected Make sure that the card edge is always bevelled or it will be extremely easy to bend/destroy pins on those connectors... learned this the hard way.

That's exactly what happened on my first version, but the pins that I bent were not critical.

My plan initially was to to have a fixed riser soldered to the board. Have RGB, VGA and keyboard on the edge. I also wanted to put all power supplies on it, so only one 12V input would be needed.

[AmigaHope]

Systems with memory priority like this need some sort of hack so addbuffers preferentially uses the slower RAM. Anything using the default scsi.device tends to be pretty slow, so adding big addbuffers to devices can help a lot for filesystem access, but you don't want to use your high performance memory for that.

I wish someone could get ahold of one of the smart disk caching projects and modernize-stabilize them. They dramatically improved performance, particularly in workbench, but huge addbuffers act as good simple, stable help and they do help a lot with making file browsers snappy.

[Lunda]

Originally Posted by AmigaHope

Systems with memory priority like this need some sort of hack so addbuffers preferentially uses the slower RAM. Anything using the default scsi.device tends to be pretty slow, so adding big addbuffers to devices can help a lot for filesystem access, but you don't want to use your high performance memory for that.

I wish someone could get ahold of one of the smart disk caching projects and modernize-stabilize them. They dramatically improved performance, particularly in workbench, but huge addbuffers act as good simple, stable help and they do help a lot with making file browsers snappy.

Thanks for the advice.
I'm currently looking for ways to speed up Workbench using fast mem. With 280 MB fast, I don't mind spending it for any performance boost.

I have used a tool called MemPri successfully in the past to 'jump' between fast and slower fast mem. I'll try to add some big buffers in the slower mem this way.

[Lunda]

Originally Posted by abu_the_monkey

it certainly looks to give the 4000/040 a run for its money in all but float point operations, probably due to the local fast ram, but, it would be nice to see how it performs in real world use, maybe with something demanding like KarlosTKG

https://github.com/0xABADCAFE/karlos-tkg

the comparison was the AIBB module Beast 030@70 vs A4000/040@25

A new build of AB3D2... Amazing!

I gave it a try and it's demanding. around 6fps full screen, 10fps - 12fps small screen.
I will test again when/if I can get the planned 2 bus cycles chip write fixed(CPU can use the fast ram bus when a chip write is in progress).

Maybe the RTG mode will be faster if I get the VGA working.

It seems to force Data Burst which might not optimum for my setup, and even worse for users without one cycle burst. Even turning off the data cache completely is sometimes faster on my board.

[Lunda]

Originally Posted by SpeedGeek

Wow! Very impressive! A 68030 CPU overclocked to 70 MHz?

Seems like a name change is in order:

Mega-Clock Beast 030, Ultra-High-Speed Beast 030, etc.

Anyway, good work.

Thanks!
Haha, yes.
BTW, the name Beast is from when it was running at 66.6.

[btp]

Ultra cool project! Mighty impressive how you managed to cram so much on a CD32 accelerator.

Definitely keep us up to date on your progress !

[Karlos]

Originally Posted by Lunda

A new build of AB3D2... Amazing!

I gave it a try and it's demanding. around 6fps full screen, 10fps - 12fps small screen.
I will test again when/if I can get the planned 2 bus cycles chip write fixed(CPU can use the fast ram bus when a chip write is in progress).

Maybe the RTG mode will be faster if I get the VGA working.

It seems to force Data Burst which might not optimum for my setup, and even worse for users without one cycle burst. Even turning off the data cache completely is sometimes faster on my board.

Try the executable from that repo with the original game files. You might be pleasantly surprised.

[pipper]

Originally Posted by Lunda

It seems to force Data Burst which might not optimum for my setup, and even worse for users without one cycle burst. Even turning off the data cache completely is sometimes faster on my board.

That's a good point. I guess, we should remove any code that is fudging with the cache settings. It made sense when the CD32 was a fixed target, but nowadays one should probably trust the system's setting.

Can you elaborate on how enabling data burst can hurt?

[Lunda]

Originally Posted by pipper

That's a good point. I guess, we should remove any code that is fudging with the cache settings. It made sense when the CD32 was a fixed target, but nowadays one should probably trust the system's setting.

Can you elaborate on how enabling data burst can hurt?

Most applications seem to run faster without data burst. If the software was developed with data burst in mind, it will be faster.
Maybe KarlosTKG is. I did some tests without data burst, and It didn't run faster.

If the burst transfers data to the cache that will result in a cache hit, it is of course faster.
If the added cycles(3 in best case) don't fill the cache with anything useful, those cycles were wasted. So the same cycles can get you two correct transfers instead.

The first read bus transfer use a minimum of 2 cycles, but often at least 3.

That's what this means: 2:1:1:1 or 3:1:1:1...

So if you have 3:2:2:2 RAM and the burst doesn't provide any useful data, you waste even more cycles.

[Karlos]

Originally Posted by pipper

That's a good point. I guess, we should remove any code that is fudging with the cache settings. It made sense when the CD32 was a fixed target, but nowadays one should probably trust the system's setting.

Can you elaborate on how enabling data burst can hurt?

I thought you already removed the cache manipulation code in TKG? There was seome stuff to freeze it, IIRC.

[pipper]

I had effectively null-op'ed the CACHE_FREEZE_ON macro because I believe this would rather hurt than help on 040/060,

There's still one instance of 'DataCacheOn' in the code which boils down to:

DataCacheOn		macro
				movem.l	a0-a6/d0-d7,-(sp)
				moveq	#-1,d0
				move.l	#CACRF_EnableD|CACRF_WriteAllocate|CACRF_DBE,d1
				CALLEXEC CacheControl
				movem.l	(sp)+,a0-a6/d0-d7
				endm

I think we should probably remove that as well.

[AmigaHope]

Originally Posted by Lunda

Thanks for the advice.
I'm currently looking for ways to speed up Workbench using fast mem. With 280 MB fast, I don't mind spending it for any performance boost.

I have used a tool called MemPri successfully in the past to 'jump' between fast and slower fast mem. I'll try to add some big buffers in the slower mem this way.

Check out Powercache and FutureDriveAccelerator -- these are third-party modern dynamic read/write caches like the ones built into modern operating systems. Neither is perfect and both have bugs, but Powercache in particular made Workbench extremely fast on my A4000 w/128M of fast ram.

Unfortunately neither has had any development for a *long* time.

All Amigas with a ton of fast RAM should at least have massive Addbuffers for all devices, or at least the devices that are commonly used. The built-in read only buffers are rock solid since they've been in AmigaOS since the beginning, but unfortunately they are fixed-size and per-partition, so if you have a lot of devices you waste a lot of memory for the ones you're not using.

[Lunda]

Originally Posted by AmigaHope

Check out Powercache and FutureDriveAccelerator -- these are third-party modern dynamic read/write caches like the ones built into modern operating systems. Neither is perfect and both have bugs, but Powercache in particular made Workbench extremely fast on my A4000 w/128M of fast ram.

Unfortunately neither has had any development for a *long* time.

All Amigas with a ton of fast RAM should at least have massive Addbuffers for all devices, or at least the devices that are commonly used. The built-in read only buffers are rock solid since they've been in AmigaOS since the beginning, but unfortunately they are fixed-size and per-partition, so if you have a lot of devices you waste a lot of memory for the ones you're not using.

Good suggestions, but they didn't improve speed much on my system.

Open a folder with 250 files in icon view: 7.26 s with Powercache. 7.30 without.
The HD LED stopped flashing and the Powercache stats shows usage.

I don't think the disk is the bottleneck in my system. With a faster CPU, Powercache will probably make a bigger difference.
Nowadays with SSDs things are different. See attached benchmark on random read from Norton MacOS(I'll look for a good disk bench for Amiga).
I found a RAM test too...

I probably need something like an icon cache. Cache all icons pre rendered in fast ram.

[Lunda]

Originally Posted by Karlos

Try the executable from that repo with the original game files. You might be pleasantly surprised.

I just tested this. Yes, It is a bit faster with the original game assets, but I prefer running with the new game files.

I also tested the original game.
On my machine the original on default small screen feels about the same speed as KarlosTKG at full screen, using original game files.

I get 15fps to 19fps using original game files with the new executable on small screen setting.

[AmigaHope]

Originally Posted by Lunda

I don't think the disk is the bottleneck in my system. With a faster CPU, Powercache will probably make a bigger difference.

I should point out here that while yeah a faster CPU helps, Powercache isn't much faster than regular Addbuffers on read operations since they both implement read caching. (memory is hazy but I think powercache does help by doing some prefetch)

Powercache has two big advantages though -- write caching (which makes multitasking with anything that writes to the disk dramatically smoother), and smart memory usage so you don't have to tune fixed Addbuffers manually for every device you mount (wasting memory on devices you're not using).

[Karlos]

Just to be clear, KarlosTKG is just the game mod. The executable that is included is from pipper's repo. The mod now depends on it because it has fixes for various problems and limitations.