Does my Blizz 030 actually work?

[Charlie]

FWIW:
I concur with NovaCoder's findings - With an accelerator the AGA chipset becomes the main bottleneck to performance. Without the kind of patches he's mentioned to offload demands of the chipset onto the faster CPU WB performance especially can be very disappointing.
You really want as much as possible to relegate the AGA chipset to the status of a glorified frame buffer and have the CPU take the load.

(Urgh, that sort-of means an accelerated Amiga becomes something like a 68k Mac - dirty!)

[blade002]

Is Blizkick and Fblit a bitch to install? did a search on Aminet and didn't know which Blizkick file to download? Would be really interested to see how my own Workbench performance is affected!? although i am running Bloodwych's Classic WB, would that matter?

[Charlie]

From (poor) memory Classic WB is pretty well served with regard to sensible patches - yes, more can always be done.

If I'm wrong Fblit & especially Blitzkick aren't difficult to install as long as you follow the instructions to the letter...
...Fblit can be an utter sod to set up if you intend any changes from the standard configuration - seeking those final tweaks in performance can result in buggering things up very nicely. Possibly worth leaving on the defaults, though further fiddling can really improve that ChipRam usage, especially if like me you like eye-candy.

BlazeWCP & IconBeFast also mentioned by NC are worth adding & require no more set up than adding the lines to s:startup-sequence.
FText is also a nice addition to Fblit - speeds up, um, text rendering among other things.

Then you're into the law of diminishing returns:
SystemPatch, Piru's exec44 to name a couple of worthwhile extras...

...the more patches, the harder to get them all to work together with any stability - then you're fiddling with Fblit's opaque options again to make things work properly...
...for me MCP's also well worth having, but getting it to play nice with the above - hey, all this fiddling is part of the charm isn't it?

[NovaCoder]

Originally Posted by StingRay

Nope, exactly the other way 'round. If they would be system-friendly they would hardly need any WHDLoad patch.

No you big silly, I meant...are they system friendly AFTER they'd been WHDLOAD'ED

In which case, the answer is 'yes' it seems.

Originally Posted by StingRay

They disable the system interrupts (=WB frozen) and do their magic.
It is no API (*sigh*) function, it's a few lines of "custom" code which does that. They don't dump any memory to disk, why should they?

That's interesting, so as AmigaOS doesn't have any memory protection, what stops the non-system friendly software overwritting your running WB programs...nothing I guess. Which is why I'm coding in a system friendly way

If they memory was dumped to disk (Windoze system hibernate style) the lack of memory protection would not be an issue, hence my comment

[NovaCoder]

Originally Posted by blade002

Is Blizkick and Fblit a bitch to install? did a search on Aminet and didn't know which Blizkick file to download? Would be really interested to see how my own Workbench performance is affected!? although i am running Bloodwych's Classic WB, would that matter?

Hiya,

I'm planing on putting a little guide together of the setup I've used for my 1200, I'll give you the link when it's done.

[NovaCoder]

Originally Posted by Charlie

FWIW:
the faster CPU WB performance especially can be very disappointing.
You really want as much as possible to relegate the AGA chipset to the status of a glorified frame buffer and have the CPU take the load.

Yep well said Charile, I was thinking the same thing, but didn't want to mention it

I think that FBlit/FText really starts the make a difference when you're using an 040/060.

[coze]

Originally Posted by NovaCoder

No you big silly, I meant...are they system friendly AFTER they'd been WHDLOAD'ED

In which case, the answer is 'yes' it seems.


That's interesting, so as AmigaOS doesn't have any memory protection, what stops the non-system friendly software overwritting your running WB programs...nothing I guess. Which is why I'm coding in a system friendly way

If they memory was dumped to disk (Windoze system hibernate style) the lack of memory protection would not be an issue, hence my comment

the memory is certainly not dumped to disk, there's no need to anyway.

I'm not a whdload wizard, but what whdload does is, upon a slave launch, get the required amount of memory from workbench, then freeze the workbench. Let the game/demo run in that confined memory space until it quits.

I think you and stingray have different definitions of 'system friendliness' which was the cause of confusion.

[NovaCoder]

Originally Posted by coze

I think you and stingray have different definitions of 'system friendliness' which was the cause of confusion.

I'm always confused

[Charlie]

Originally Posted by NovaCoder

I think that FBlit/FText really starts the make a difference when you're using an 040/060.

Yep.
My '060 A1200 is a very different beast with & without these patches: The difference between 1024x768x128 being practicable & being waaay to slow with too little chip RAM left to be remotely usable.

[StingRay]

Originally Posted by NovaCoder

No you big silly, I meant...are they system friendly AFTER they'd been WHDLOAD'ED

In which case, the answer is 'yes' it seems.

Long answer: Try to press Amiga+m while WHDLoad runs.
Short answer: No.

On a more serious note, see Coze's reply, he got it completely right.
System friendly means that the system is fully intact while the demo/game runs, i.e. you can switch screens etc. WHDLoad does not work like that (as that is simply impossible), it kills the system in a way demos/games do and restores everything when you quit.

Originally Posted by NovaCoder

That's interesting, so as AmigaOS doesn't have any memory protection, what stops the non-system friendly software overwritting your running WB programs...nothing I guess. Which is why I'm coding in a system friendly way

Hardware banging doesn't necessarily imply memory trashing. If the coder used the OS to allocate memory, there will be no problems. However, many of the old games and demos just don't allocate memory, instead they're just using absolute addresses and don't care at all about the OS. They will happily trash memory for obvious reasons.