WHDLoad and 68060 issues with image corruption

[Betelgeuse]

I have an A4000 with Cyberstorm MK2 and 128MB of Cyberstorm RAM, 2MB Chip RAM, and I think another 16MB of A4000 Fast-RAM (all motherboard RAM slots populated), Picasso IV also acting as a flicker fixer for WHDLoad games. The problem is when running WHDLoad games with tooltips set to CACHECHIP and DCACHE, some games show image corruption, particularly in text. For some games the issue is minor, for others it makes the game unplayable (like ST: 25th Anniversary). Setting the flag CHIPNOCACHE solves the corruption, but makes some games a lot slower (like Tornado AGA or Robinson's Requiem AGA, Star Trek runs fine then and is plenty fast). There is no corruption when running these games from a regular install, not thru WHDLoad (the latter is more convenient though). Is there any way to avoid the corruption issue?

[guest11527]

The problem is when running WHDLoad games with tooltips set to CACHECHIP and DCACHE, some games show image corruption, particularly in text.

Of course. Chip memory is not cacheable simply because the data can change under the CPU any time by using the blitter without the CPU cache noticing the change. Caching requires that the memory contents does not change by any means but the CPU.

Hence, CACHECHIP is certainly a pretty bad idea - as you observe.

[klx300r]

@ Betelgeuse

I've got basically same setup as you except my CS is the MKIII and I gave up with WHDLoad on my A4000 as try as I may I only can get to the game intro at best to pop up so I use my 1200 with WB3.1 and 030 to happily run all my WHDLoad stuff...will be watching this thread to hopefully see if you can get WHDLoad working properly with A4000 & CS060 board and wish you luck:)

[Betelgeuse]

Of course. Chip memory is not cacheable simply because the data can change under the CPU any time by using the blitter without the CPU cache noticing the change. Caching requires that the memory contents does not change by any means but the CPU.

Hence, CACHECHIP is certainly a pretty bad idea - as you observe.

Makes sense, but why then have the option in the first place?

[amiga1260]

I have no problems getting WHDLoad Games running without glitches on my Blizzard 1260, Commodore 3660 and Cyberstorm 060 MK 1.

You need to set the maxtransfer value at 00x01fe00 with HDtoolbox for all the partitions.
The best result is to copy the game again on HD.

[UberFreak]

I'm running WHDLoad (demos mostly) on an A4000 with CSmk1 060.
From my experience with a few hundred demos and games, about 50% run, some with glitches here and there.
The other 50% require lots of massaging, playing around with tooltips etc, but that doesn't always help.
Its mostly old slaves that have issues.

I've recently built a basic KS1.2 A500 with a Gotek, just for running all the old stuff without hassle or glitches.

[giZmo350]

I'm running WHDLoad (demos mostly) on an A4000 with CSmk1 060.
From my experience with a few hundred demos and games, about 50% run, some with glitches here and there.
The other 50% require lots of massaging, playing around with tooltips etc, but that doesn't always help.
Its mostly old slaves that have issues.

My experience with my A2000 with a Blizz 2060 is pretty much the same.

I've recently built a basic KS1.2 A500 with a Gotek, just for running all the old stuff without hassle or glitches.

I recently did the exact same thing, for the exact same reason, after buying a Gotek & external cable. I haven't gotten around to even starting the Gotek install yet as I have no idea where to start or what to do. :lol::lol:

[kolla]

Makes sense, but why then have the option in the first place?

I looked through the docs, and only find "ChipNoCache"

http://www.whdload.de/docs/en/opt.html#ChipNoCache

http://www.whdload.de/docs/en/cache.html#chipmem

[Betelgeuse]

I looked through the docs, and only find "ChipNoCache"

http://www.whdload.de/docs/en/opt.html#ChipNoCache

http://www.whdload.de/docs/en/cache.html#chipmem

I think chip caching is on with the DCACHE tooltip, some readme files mention CHIPCACHE but I also didn't see it in the docs. So in the end DCACHE turns on all caching including chip caching. How does it differ from the CACHE command or what's turned on with SetPatch and the CPU command?

[kolla]

How does it differ from the CACHE command or what's turned on with SetPatch and the CPU command?

I suppose these are options for within the "virtual" system that WHDLoad starts, and not the "host" system.

Btw - you know that with WHDLoad you can boot into OS3.1 or OS3.1.3 from OS3.9, with a defined directory as boot disk for the "instance", run programs in there, and at any time press the defined exit key to shut down the virtual OS3.1 or 1.3 "instance" and be back in OS3.9? Very convenient for running programs that somehow struggle with OS3.9, or as a test environment for your own hackish asm code

http://www.whdload.de/apps/alla.html

[guest11527]

How does it differ from the CACHE command or what's turned on with SetPatch and the CPU command?

That is hard to tell without the documentation. Caching on the 68060 is controlled by two switches. First, there is a global on/off switch for the cache that is controlled by the CPU command (somewhat), but the final tuning of caching is due to the MMU, which is setup by the 68060.library. Hence, even if "DCACHE" is on via SetPatch, the MMU still turns it off for the chip memory.

Now, what WHDLoad does is completely unclear. In particular, whether it builds a custom MMU table. Given the defects you observed, it seems likely that it does, albeit in an incorrect manner.

[kolla]

Now, what WHDLoad does is completely unclear. In particular, whether it builds a custom MMU table. Given the defects you observed, it seems likely that it does, albeit in an incorrect manner.

It does, the documentation is quite clear about that.

http://www.whdload.de/docs/en/mmu.html
http://www.whdload.de/docs/en/cache.html