| Re: [hatari-devel] Re: Leonard/Oxygene trace protection crashes on Hatari |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel 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
/Troed
I downloaded the demozoo version and I confirm it's different from the
one I used here :
http://atari-forum.com/viewtopic.php?p=43319#p43319
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 sample.zip 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) :
lom13.prg
rallp01.prg
rallmp02.prg
I need to give a closer look to ab160.prg as it doesn't seem to work
correctly.
Nicolas