How do degraders disable AGA?

[roondar]

I've been doing a few tests lately using the "7 bitplane" trick for OCS/ECS machines. Naturally, this doesn't work on AGA machines (you just get a standard 7 bitplane screen). However, I seem to remember that degrader software such as TUDE/Degrader/KillAGA managed to disable AGA and get these kind of effects to work even on an AGA machine.

IIRC, the same also happens if you select the display options in the Early Boot menu.

My question is: can this be done in a program?
As in, could I set specific chipset registers (or call some OS function) to get already booted AGA machines to temporarily act as if OCS/ECS for the purposes of this trick and then after the program is done reset them back to how they were?

[DanScott]

I am sure that nearly all the 7 bitplane trick effects done for OCS, probably had some different code path for running on AGA machines (ie.. enable regular HAM and create planes 5 and 6 in memory filled with the "pattern").. although I may be wrong

As for the main question.. I have no idea !

[ross]

Originally Posted by DanScott

I am sure that nearly all the 7 bitplane trick effects done for OCS, probably had some different code path for running on AGA machines (ie.. enable regular HAM and create planes 5 and 6 in memory filled with the "pattern").. although I may be wrong

Yes, 7-planes trick (and other oddities OCS only) can be emulated only by software path.
A full 'hardware degrader' register do not exist (and generic degraders don't do anything soft).

[roondar]

Ok, that's a bit of a shame but does make my course very clear
Edit: this also shows how dangerous it is to rely on memory. I could've sworn that these demo's used to work with a degrader, I never even considered two code paths

[Exodous]

As the author of a degrader tool, BootUte, I spent a lot of time not only writing my own tool, but analysing what others were doing too.

Pretty much all degraders just modified system table values and hardware registers to pretend the computer was something different.

To "change" the chipset that was running, was done by setting the appropriate value in the byte at offset gb_ChipRevBits0 from the graphics library base, so that if the demo queried the chipset, it would believe it was what it was expecting.

The degrader would then either set the chipset values directly, create a new screen, or blank viewport as a PAL or NTSC LORES display to get the chipset reset to a known state and then would launch the demo/game.

In many cases, this was all that was required to get the demo working visually as the demo/game failed because some of the newer registers were not initialised to a compatible state for the other settings.

The other "main" fix was to set the CPU status in exec to be a 68000, turn off CPU caches and install an illegal instruction trap for MOVE SR,<ea> which became privileged in the 68010+, but which software often used.


Clearly these workarounds could never actually fix something that was properly broken and this was where pre-execution patching came in. BootUte had this feature, but I moved to the PC running Linux (due to University course requirements) and sold my Amiga before I really made use of it.

From what I understand, this is pretty much what WHDLoad does, but it has taken it far further than I ever envisaged doing back in the mid 90's.

[roondar]

That's fascinating info, thanks

I suppose you'd end up doing things like resetting the fetchmode/sprite resolution to 1x then and just start the demo/game (with the move SR trap installed/cached disabled). Quite clever and amazing it worked so often!

Rebooting degraders often also allowed Kickstart to be set, which was neat. One feature I never got working was that some degraders claimed to be able to 'emulate' slow RAM, but even though my 68030 had a full MMU it never seemed to do anything.

[Exodous]

Emulating slow ram was another hack - basically set the appropriate entries in exec so the machine thought it had slow ram and go through the memory list changing the flags so it looked like slow ram to anything requesting it.

If the machine only had 1mb of chip ram, the hack was basically to split it into two and set one half as chip and one half as slow, again via system flags.

In reality, 99% of it was smoke and mirrors.

My original inspiration for BootUte was to fix apps that broke when I upgraded my A500 to Kickstart 2.04 and early versions emulated some of the underlying BCPL stuff from 1.3 that was removed in 2.04. As the program evolved, that code was removed as I found it wasn't really needed to fix most things.

[jotd]

there's also FMODE register, which must be set to 0 for ECS. But if the game queries deniseid by reading the register, it will give AGA away.

[hooverphonique]

And not forgetting setting the VBR to zero.

I wrote the degrader tool called Embedder, but I don't recall having the SR trap in there - I think it only resets the viewport, vbr and disables caches.

[roondar]

Ah yes, that's sure to fix quite a few games on Amiga's with faster CPU's.

[Photon]

Roondar I think you're asking what the Early Boot menu does? It should be easy to check. The code run may be different between 2.0 and 3.1.

But as mentioned it likely only sets FMODE and maybe one or two more things.

And this will not enable HAX OCS modes on AGA. It may may display HAM6 nearly as on OCS? But HAM5 tricks won't work. From memory.

[roondar]

Well, I wanted to know about both 3rd party degraders and the early boot menu so info about both is nice to know

[Photon]

Cool. None of them are able to 'disable AGA' as per thread title, so it's about the details.

I've released for OCS HAM5 which is incompatible with AGA, and I'd like to add that if you don't absolutely need it like I did, do support 68000/OCS and up and don't rely on degraders. A 'how' question instead is excellent. .