Garbled graphics on modern Amigas

[absence]

I'm trying to fix an old game that only displays garbage on the screen when run on some modern Amigas. My guess is that it's caused by SetPatch setting the AGA fetch mode to something high, but the game's data is only word aligned. Aligning it properly is out of the question, so I'm interested in reducing the fetch mode to 1x while the game runs (if that's the correct way to fix this problem).

I tried clearing the FMODE hardware register both using the CPU during startup, and using the copper, but it still displays garbage. The game is OS friendly while its main menu is visible (using OpenScreen, OwnBlitter, etc.), but calls Forbid() and Permit() upon entering and leaving the actual game levels. What do I need to do to get this working? Could the problem be something other than the fetch mode?

[FOL]

Originally Posted by absence

I'm trying to fix an old game that only displays garbage on the screen when run on some modern Amigas. My guess is that it's caused by SetPatch setting the AGA fetch mode to something high, but the game's data is only word aligned. Aligning it properly is out of the question, so I'm interested in reducing the fetch mode to 1x while the game runs (if that's the correct way to fix this problem).

I tried clearing the FMODE hardware register both using the CPU during startup, and using the copper, but it still displays garbage. The game is OS friendly while its main menu is visible (using OpenScreen, OwnBlitter, etc.), but calls Forbid() and Permit() upon entering and leaving the actual game levels. What do I need to do to get this working? Could the problem be something other than the fetch mode?

Why not just setpatch NOAGA?

[musashi5150]

You could turn the cpu caches off too - that could do the trick.

[StingRay]

Check if modulos are set correctly, many old games just rely on the WB/OS values and don't set modulos properly. Needless to say that this is bound to fail on AGA Amigas/newer versions of the OS.

[absence]

I've done some more testing, and this is looking strange. On a 020 with AGA, if I skip the startup-sequence and run the game, it works fine but gurus on exit (8100 0005). The same results occur when disabling cache, running SetPatch with or without NOAGA, or selecting enhanced chipset in the early startup menu.

If I let Workbench start, I get garbled graphics even when the screen mode preference is set to plain old 4-colour PAL hires, but the game doesn't guru on exit anymore. If I set chipset to enhanced in the early startup menu, it works fine from WB without guru.

Since it works without startup-sequence with AGA and SetPatch, I assume the problem isn't FMODE after all, but what can the problem be?

Originally Posted by FOL

Why not just setpatch NOAGA?

This makes the game work from Workbench (same as selecting enhanced chipset in the early startup menu). I'd like to avoid the reboot though.

Originally Posted by musashi5150

You could turn the cpu caches off too - that could do the trick.

I've tried, and it doesn't affect anything. I've only tested with 020 so far, so maybe it will be necessary for 040.

Originally Posted by StingRay

Check if modulos are set correctly, many old games just rely on the WB/OS values and don't set modulos properly. Needless to say that this is bound to fail on AGA Amigas/newer versions of the OS.

Yes, they're set to zero (the bitmap pitch is equal to the width).

[StingRay]

Originally Posted by absence

If I let Workbench start, I get garbled graphics even when the screen mode preference is set to plain old 4-colour PAL hires, but the game doesn't guru on exit anymore.

Add a LoadView(0) call and see if that changes anything.

Originally Posted by absence

Yes, they're set to zero (the bitmap pitch is equal to the width).

In all copperlists? Which game is it btw?

[absence]

Further testing. If I remove IPrefs from the startup-sequence, it works fine from WB with AGA and 020. So what kind of evil stuff does IPrefs do to the hardware? The pointer sprite has been set to lores all the time, just to rule that out.

Also, if I run without startup-sequence and run loadwb, endcli, and start a new shell, the game doesn't guru on exit anymore.

[StingRay]

Originally Posted by absence

So what kind of evil stuff does IPrefs do to the hardware?

Wrong question, the right question is: What does the game not do to setup the hardware correctly?

[absence]

Originally Posted by StingRay

Add a LoadView(0) call and see if that changes anything.

Where exactly should it go? I tried sticking it in the main loop so it gets called every frame, but it doesn't change anything.

Originally Posted by StingRay

In all copperlists? Which game is it btw?

Yes. The game is Turboraketti.

[StingRay]

Originally Posted by absence

Where exactly should it go? I tried sticking it in the main loop so it gets called every frame, but it doesn't change anything.

Usually just done once in the init part. But if you called it in the mainloop and it didn't change anything the problem is somewhere else anyway.

Originally Posted by absence

Yes. The game is Turboraketti.

If I'm not too tired I'll have a look when I'm back from work today.

[absence]

Originally Posted by StingRay

Wrong question, the right question is: What does the game not do to setup the hardware correctly?

Hard for me to say, but I can tell you what it DOES to set it up.

First it opens a screen using OpenScreen (640x256 1bpl CUSTOMSCREEN with 0 for gadgets and custombitmap, 0x8000 for viewmode (hires?), topaz.font 8 with 0 for style and flags), uses both LoadRGB4 and SetRGB4 to set the palette, and writes data to a pointer in the screen struct. This displays the title screen, and it works without problems (isn't garbled).

Then it just writes its copper list address to gfxbase's "lof list", and from there on it's all garbled. If this is the right way of doing it, the problem is probably in what the copper list does or doesn't. The opened screen's format is all wrong though, but I'm not sure if it matters when you replace the copper list.

[Toni Wilen]

It is guranteed to be FMODE compatibility problem. FMODE > 0 rarely works without recalculating (OCS/ECS) DDFSTRT/DDFSTOP values. (much bigger program than BPLxPT aligment)

LoadView(0) won't work because of OpenScreen() sets high FMODE again. LoadView(0); (plus usual WaitTOF();WaitTOF();) before custom copper list is set should fix the problem.

[StingRay]

Originally Posted by Toni Wilen

It is guranteed to be FMODE compatibility problem.

It actually was my first thought too but:

Originally Posted by absence

I tried clearing the FMODE hardware register both using the CPU during startup, and using the copper, but it still displays garbage.

[Toni Wilen]

Oh, right.. hmm.. Does it look like "wrong modulo"-garbage or "just garbage"-garbage?

Memory list corruption guru may point to missing blitter wait(s). (which would also explain the garbage). Or perhaps the game tries to be too tricky and pokes/reads the bitmap structure in Screen structure returned by OpenScreen() which is interleaved under KS3.x but "normal" under older OS versions.

[absence]

Originally Posted by Toni Wilen

Oh, right.. hmm.. Does it look like "wrong modulo"-garbage or "just garbage"-garbage?

Looks like the attached screen shot. Second screenshot is what it's supposed to look like.

Originally Posted by Toni Wilen

Memory list corruption guru may point to missing blitter wait(s). (which would also explain the garbage). Or perhaps the game tries to be too tricky and pokes/reads the bitmap structure in Screen structure returned by OpenScreen() which is interleaved under KS3.x but "normal" under older OS versions.

It does write to the bitmap structure for the title screen, but there's no garbage at that point. It's not until the custom copper list is loaded that the problems start. It doesn't use the bitmap structure after that, but I guess a few "well" placed memory writes could explain the gurus. Strange that they don't occur after Workbench is loaded and a new shell is started though. As for the blitter it's not used much at all, and it seems to wait when it is.

[StingRay]

I just had a quick look and it seems it's fetch mode related, I added a LoadView(0) before the system is killed (check offset $1830 in ReSource) and the screen looked OK then. Will do some more tests when I'm back home. The code I added looks like this:

	move.l	34(a1),OldView
	move.l	a1,a6
	sub.l	a1,a1
	bsr.w	.DoView

; orig code here:
	lea	($DFF000),a6
	move.w	($1C,a6),(lbW00A8F6)
	move.w	(2,a6),(lbW00A8F8)
	move.w	($10,a6),(lbW00A8FA)

	...
	rts

.DoView	jsr	-222(a6)			; LoadView()
	jsr	-270(a6)			; WaitTOF()
	jmp	-270(a6)

[absence]

Originally Posted by StingRay

I just had a quick look and it seems it's fetch mode related, I added a LoadView(0) before the system is killed (check offset $1830 in ReSource) and the screen looked OK then. Will do some more tests when I'm back home. The code I added looks like this:

Works like a charm, but only in-game and not in the menu (the subroutine at $1830 isn't called until a selection is made in the menu). The menu loop starts at $922 in Resource, and I have tried adding your LoadView code both before and after the second BSR (which potentially calls ScreenToFront), and the graphics are still garbled. Is this because the system is alive in the menu? Someone mentioned there's a problem with hires sprites too, but I assume this doesn't affect the bitplanes and can be dealt with later.

[StingRay]

Originally Posted by absence

Works like a charm, but only in-game and not in the menu (the subroutine at $1830 isn't called until a selection is made in the menu).

That's of course true. However, menu screen looks OK here (i.e. it never looked wrong here). Anyway, more testing when I'm back from work.

[StingRay]

OK, so I tried to reproduce the bug with the menu screen but I was not successful. It never looked buggy, whatever I tried. Can you tell me exactly what you do to make the screen mess up? (Kickstart, WB version etc)

[absence]

Originally Posted by StingRay

OK, so I tried to reproduce the bug with the menu screen but I was not successful. It never looked buggy, whatever I tried. Can you tell me exactly what you do to make the screen mess up? (Kickstart, WB version etc)

Hmm.. Maybe it's an emulation issue? I run Winuae 1.6.1 with the following settings. CPU: 020, 24-bit, fastest possible, no FPU. Chipset: AGA, A1200, full collision level, 100% accurate sound, "compatible" advanced settings (I've tried cycle exact too, even though it's for A500, but same result). ROM/RAM: Kickstart 3.1 A1200 40.68, 2MB chip, 4MB fast. Workbench: 3.1 (40.42) with no fancy stuff installed (s:user-startup only contains an assign) and default preferences except screen mode is DBLPAL high res no flicker (640x512) 4 colours, and pointer is high res. I also tried to delete everything in envarc:sys and reboot, but still same result.