Re: [hatari-devel] Re: Leonard/Oxygene trace protection crashes on Hatari

[ Thread Index | Date Index | More Archives ]

Le 21/12/2016 à 12:16, Nicolas Pomarède a écrit :
Le 21/12/2016 à 12:04, Troed Sångberg a écrit :
It's probably different. It's now verified to work on Steem 3.2 and
Steem SSE 3.7.2 (Linux) in the thread above


I downloaded the demozoo version and I confirm it's different from the
one I used here :

different crc32 on the sprite.prg file and different size 40045 (good)
vs 40290 (bad).

I checked this demo ; the good news is that the video-sync decoding is not that particular, it's used in several other demos and supported by Hatari, nothing really special in this version by Leonard.

This demo will work in fact since Hatari 1.4, and up to Hatari 1.9

Unfortunately, the demo reads the video counter to decode itself, but there's a point where it reads counter at cycle 56 on line 310, and as you know, this is near this spot that video counter is reloaded with the content of $ff8201/8203 (bad luck !)

In Hatari 2.0, I added support for really reloading video counter around cycle 50, but my measures on STF were made with a not too precise method (~20 jitter cycles). This seemed good enough, but now I see I need to improve this to a more accurate value (basically, the demo reads the restarted video counter $600, while it should read the bottom of screen value $7d00, which alters the decoding)

Will take a look at the demozoo one as well as to the that is
available too (which contains several protected demo to test)

Most demos/intro work correctly with default Hatari settings.

But 3 of them require gemdos HD emulation to be turned off, else it's seen as a cartridge (at address $FA0000) and the decoding will fail on purpose (to prevent using ripping cartridge) :

I need to give a closer look to ab160.prg as it doesn't seem to work correctly.


Mail converted by MHonArc 2.6.19+