Pasti images that should, but don't work

[ijor]

Pasti images for the following titles don’t run due to bugs in Pasti.DLL:

Vroom (Lankhor)
Boulder Dash Construction Kit (Databyte release only).

The latter is not exactly a bug, but a known lack of functionality.

[ijor]

The titles below were removed from the list. They run with version 0.2h and above of Pasti.DLL

Space Ace II, Wrath of the Demon (and possibly other Readysoft titles)
Helter Skelter

[ijor]

Added Vroom to the list. Note that the game seems to be running fine for the first play. But on the second try, after you come back to the main menu and want to start again, it will keep loading constantly.

[Brume]

Resurrecting an old thread. Nicolas (Hatari) warned me about Vroom/Pasti troubles, so I imaged the disks with both Kryoflux and SuperCard Pro hardwares.

Here are the results:

- I've redone a second .STX (with pasti.org) from my original disk. It has the same results as the one mentioned by ijor: there's no way to restart a second game after a first play

- I've imaged the original disk with KF. The CTR file works fine with Hatari. We can play again after quitting or losing a game. That's the good news

- I've tried to convert the CTR file into STX format with aufit. The game stops at the intro, there's no way to play at least one game

- Actually, after imaging the game with SCP, I've tried to convert the SCP file into STX format with aufit. The games doesn't show the intro. It stays on a black screen, there's no way to play one game

If our experts in imaging process or emulation wants to take a look on the archives, they're welcome
The archives can be found here:

Vroom - CTR (Kryoflux)
http://dl.free.fr/tOy2vNiqu

Vroom - RAW (Kryoflux Stream)
http://dl.free.fr/k7LhFFe0U

Vroom - SCP (SuperCard Pro)
http://dl.free.fr/ofIu0ZGHN

Vroom - STX (Pasti.prg)
http://dl.free.fr/o8NUxhksM

[npomarede]

As a note, when a second game is started with the STX version, I see that the games tries to read track $26 and $27, and then it loops on reading thoses 2 tracks. There must be something special in one of those tracks that makes the STX version fails.

BTW Brume, did you try creating a new floppy from the SCP / KF dump, to see if it works on your STE ?

[Stefan jL]

I made an SCP of my copy of Vroom and then i made an STX of that using Aufit and i get the same result as mentioned for STX "there's no way to restart a second game after a first play".
And writing back the SCP to a disk and try and start that does not work at all.

[npomarede]

I made an SCP of my copy of Vroom and then i made an STX of that using Aufit and i get the same result as mentioned for STX "there's no way to restart a second game after a first play".
And writing back the SCP to a disk and try and start that does not work at all.

So, this game would not be dumpable with SCP ?

[JimDrew]

How did you try dumping/copying this with SCP? You may have to use SPLICE. I will take a look at the image.

You can duplicate 100% of anything with SCP. It just needs to know where the start/stop of each track is. If you are doing 5 revs with SPLICE mode, I am not sure why Aufit would not work for making a conversion to .stx format. DrCoolZic would know more about that.

[JimDrew]

Well, I had no problem making a working disk from Brume's SCP image here. This disk is index'd, so just click on the override file option and set the mode to INDEX and write it. That's it. Brume's image should be able to generate a .stx file using Aufit because the disk works fine.

Stephan's image, however, has the issue where after the 2nd time trying to play causes the drive to step back and forth forever. But.. his image is extremely dirty, full of weak bits and no flux areas. None of which appear in Brume's image.

[DrCoolZic]

Would be interesting to find exactly the protection used as it seems it is either not supported by the pasti dll or the stx image generated is incorrect.
Could it be something like the fuzzy read track that we have discovered on another game not supported by Pasti?

[JimDrew]

I am not sure where the protection check fails on Stephan's image... but Brume's image looks completely different. My guess is that with Brume's image the drive speed is "wobbly" because you can see the flux timing moving up and done like a sine wave. There are no obvious weakbits or no flux areas in that image. Stephan's image is a disaster. I am surprised that it even loads at all.

[AtariZoll]

I traced little STX image of Vroom at AtariMania - same problem - can play only 1 race. After that endless loading (loop).
It is protection with delayed effect. Problematic track is track 78 on side A. It is read 2x in row ( code at $5532 ) and EORs some data with track content, after some seeking, decoding. Since it happens 2x, original content will be there after 2 passes, if track data is same in both reads. I can not say more now, as code is tricky and hard to follow, but all it indicates that there is fuzzy data in that track. So, I think that should look are multiple revolution reads of SCP have different track data, after sync bytes.

And by me Brume's STX image converted via Aufit works on Steem 3.2 - with same error after first race.

[npomarede]

I traced little STX image of Vroom at AtariMania - same problem - can play only 1 race. After that endless loading (loop).
It is protection with delayed effect. Problematic track is track 78 on side A. It is read 2x in row ( code at $5532 ) and EORs some data with track content, after some seeking, decoding. Since it happens 2x, original content will be there after 2 passes, if track data is same in both reads. I can not say more now, as code is tricky and hard to follow, but all it indicates that there is fuzzy data in that track. So, I think that should look are multiple revolution reads of SCP have different track data, after sync bytes.

And by me Brume's STX image converted via Aufit works on Steem 3.2 - with same error after first race.

Thanks for tracing this ; the CTR dump is working in Hatari, but not in latest Steem according to Brume, this would confirm some kind of fuzzy bytes in the track, because Hatari correctly handles revolution's counter for capslib 5.1 and AFAIK it's not yet the case in Steem (so Steem will always read the same track data, not the next revolution)

This is what I see in track 78 side 0 :

Code: Select all

  track 156 BlockSize=13298 FuzzySize=2048 Sectors=0009 Flags=0061 MFMSize=6220 TrackNb=4e Side=0 RecordType=0 TrackImage=yes (6220 bytes, sync=0000) Timings=5,260
    sector  0 DataOffset=6222 BitPosition=536 ReadTime=16336 [track=4e head=00 sector=01 size=02 crc=06a9] FdcStatus=00 Reserved=00 TimingsOffset=0
    sector  1 DataOffset=6734 BitPosition=5432 ReadTime=16525 [track=4e head=00 sector=3a size=02 crc=dfc6] FdcStatus=89 Reserved=00 TimingsOffset=10834
    sector  2 DataOffset=7246 BitPosition=10320 ReadTime=16330 [track=4e head=00 sector=03 size=02 crc=60cb] FdcStatus=00 Reserved=00 TimingsOffset=0
    sector  3 DataOffset=7758 BitPosition=15208 ReadTime=16128 [track=4e head=00 sector=30 size=02 crc=300d] FdcStatus=89 Reserved=00 TimingsOffset=10898
    sector  4 DataOffset=8270 BitPosition=20096 ReadTime=16336 [track=4e head=00 sector=05 size=02 crc=ca6d] FdcStatus=00 Reserved=00 TimingsOffset=0
    sector  5 DataOffset=8782 BitPosition=24992 ReadTime=16289 [track=4e head=00 sector=0a size=02 crc=da53] FdcStatus=89 Reserved=00 TimingsOffset=10962
    sector  6 DataOffset=9294 BitPosition=29888 ReadTime=16343 [track=4e head=00 sector=07 size=02 crc=ac0f] FdcStatus=00 Reserved=00 TimingsOffset=0
    sector  7 DataOffset=9806 BitPosition=34776 ReadTime=17050 [track=4e head=00 sector=6a size=02 crc=d179] FdcStatus=89 Reserved=00 TimingsOffset=11026
    sector  8 DataOffset=10318 BitPosition=39664 ReadTime=16363 [track=4e head=00 sector=09 size=02 crc=8f00] FdcStatus=00 Reserved=00 TimingsOffset=0

We can see that sectors 3a, 30, a and 6a have fuzzy bytes and also non standard timings.
- Either the protection is only included in the sectors, but pasti was not able to correctly detect it completely
- Or the rest of the track (gaps) also includes some fuzzy bytes or some non standard timings, and this is not supported by pasti at all

Maybe Dr CoolZic's Aufit allows to see the track's layout to check if fuzzy bytes or variable timings are also included in the GAPs or only in sectors ?

[AtariZoll]

I even did not look infos about STX image at first test. Track 78 is different than others - there is fuzzy data in track , + some density variations. It has some sectors too, but game reads it only as track, at least mentioned 2 reads in row. So, it is certainly case of unsupported by Pasti fuzzy data in track dump.

[npomarede]

If fuzzy bytes / timings variation are only in the sectors, then it could be theoretically at the pasti.dll level to read the track and replace all the bytes that belong to the specific sector by some fuzzy bytes and get the equivalent of a "fuzzy track"

But this is rather tricky to do, you need to find the correct start of each sector in the track (which can include weird gaps).
From the results, it seems pasti.dll doesn't implement this "mixing" between fuzzy sector and the track's bytes.
(in Hatari, I also didn't implement it, because a) I didn't know if it would be used in some dumps and b) I didn't know if pasti did it )

EDIT : are you sure it uses read track on 78 ? In my traces when running the STX, I get some read sectors on track 78 with dma sector count = 12 :

Code: Select all

fdc type I seek dest_track=0x15 spinup=on verify=off steprate=3 drive=0 tr=0x14 head_track=0x14 VBL=1253 video_cyc=37748 372@73 pc=1e9ee
fdc type III read track spinup=on settle=off tr=0x15 head_track=0x15 side=0 drive=0 addr=0x200 VBL=1253 video_cyc=64488 488@125 pc=1e9ee
fdc type I seek dest_track=0x4e spinup=on verify=off steprate=3 drive=0 tr=0x15 head_track=0x15 VBL=1405 video_cyc=3032 472@5 pc=1e9ee
fdc type II read sector sector=0x1 multi=on spinup=on settle=off tr=0x4e head_track=0x4e side=0 drive=0 dmasector=12 addr=0x200 VBL=1468 video_cyc=145764 356@284 pc=1e9ee
fdc type II read sector with multi sector=0x2 track=0x4e side=0 drive=0 addr=0x400 VBL=1471 video_cyc=45580 12@89 pc=1e9f8
fdc type IV force int 0xd0 irq=0 index=0 VBL=1471 video_cyc=45796 228@89 pc=1e9ee
fdc type I seek dest_track=0x4e spinup=on verify=off steprate=3 drive=0 tr=0x4e head_track=0x4e VBL=1471 video_cyc=54608 336@106 pc=1e9ee
fdc type II read sector sector=0x3 multi=on spinup=on settle=off tr=0x4e head_track=0x4e side=0 drive=0 dmasector=12 addr=0x200 VBL=1471 video_cyc=62868 404@122 pc=1e9ee
fdc type II read sector with multi sector=0x4 track=0x4e side=0 drive=0 addr=0x400 VBL=1473 video_cyc=38108 220@74 pc=1e9f8
fdc type IV force int 0xd0 irq=0 index=0 VBL=1473 video_cyc=38264 376@74 pc=1e9ee
fdc type I seek dest_track=0x15 spinup=on verify=off steprate=3 drive=0 tr=0x4e head_track=0x4e VBL=1473 video_cyc=49056 416@95 pc=1e9ee
fdc type III read track spinup=on settle=off tr=0x15 head_track=0x15 side=0 drive=0 addr=0x200 VBL=1481 video_cyc=137756 28@269 pc=1e9ee
fdc type I seek dest_track=0x16 spinup=on verify=off steprate=3 drive=0 tr=0x15 head_track=0x15 VBL=1522 video_cyc=88000 448@171 pc=1e9ee

[JimDrew]

I took a look of track 78, side 0 (bottom) with SCP's editor/analyzer. You can see that in fact there are fuzzy bits and valid sectors.

[npomarede]

I took a look of track 78, side 0 (bottom) with SCP's editor/analyzer. You can see that in fact there are fuzzy bits and valid sectors.

Yes, this is the same result as in the STX image : 5 "normal" sectors and 4 "fuzzy" ones.
Are you able with your analyzer to see if those fuzzy bytes are only in the data part of the sectors or if they happen in gaps too (maybe you could have an option in your analyzer to zoom on the graph and to show some vertical line for the boundaries of sector data for example ?)

[DrCoolZic]

If fuzzy bytes / timings variation are only in the sectors, then it could be theoretically at the pasti.dll level to read the track and replace all the bytes that belong to the specific sector by some fuzzy bytes and get the equivalent of a "fuzzy track"

But this is rather tricky to do, you need to find the correct start of each sector in the track (which can include weird gaps).
From the results, it seems pasti.dll doesn't implement this "mixing" between fuzzy sector and the track's bytes.
(in Hatari, I also didn't implement it, because a) I didn't know if it would be used in some dumps and b) I didn't know if pasti did it )

I suppose that you do this for an stx file that contains fuzzy sector but that does NOT contains read track information?
Normally you can't replace sector information in a read track by information from a read sector as the $C2 sync leads usually to different data (although stx format support the cases of same data in both for space saving).
From what I understand the latest version of Pasti imager ALWAYS write track read data. By doing this you minimize the risk of not finding a protection that requires track data the penalty is a bigger image size but this is no more a problem.

[npomarede]

If fuzzy bytes / timings variation are only in the sectors, then it could be theoretically at the pasti.dll level to read the track and replace all the bytes that belong to the specific sector by some fuzzy bytes and get the equivalent of a "fuzzy track"

But this is rather tricky to do, you need to find the correct start of each sector in the track (which can include weird gaps).
From the results, it seems pasti.dll doesn't implement this "mixing" between fuzzy sector and the track's bytes.
(in Hatari, I also didn't implement it, because a) I didn't know if it would be used in some dumps and b) I didn't know if pasti did it )

I suppose that you do this for an stx file that contains fuzzy sector but that does NOT contains read track information?
Normally you can't replace sector information in a read track by information from a read sector as the $C2 sync leads usually to different data (although stx format support the cases of same data in both for space saving).
From what I understand the latest version of Pasti imager ALWAYS write track read data. By doing this you minimize the risk of not finding a protection that requires track data the penalty is a bigger image size but this is no more a problem.

No, this is for a STX that contains both track data and fuzzy sector data.
In that case, the track data don't show any fuzzy bytes (this is not supported in STX) but they should because the embedded sectors are fuzzy ; so in all logic, you should be able to mix the fuzzy sectors with the track image to get a fuzzy track. But this is not supported in pasti.dll.

[DrCoolZic]

I have looked at track 78 and this is quite interesting.
First you have four sectors (58, 48, 10, and 106) with fuzzy bytes. Fuzzy bytes are obtained by using unformatted areas. Nothing special that Pasti would not be able to handle.

vroom_trk_78.PNG

But here comes the interesting part that I have never seen before
The last sector is in fact composed of an ID record followed by two DATA records. The first data record is read normally by the WD1772 but the second sector cannot be read using a read sector command because it is located too far from the ID record. Therefore the only way to read it is by using a read track command.
This sector contains the normal A1 A1 A1 FB header that is used to sync correctly the WD1772 but … at the beginning of the sector we see some transitions that violates the normal MFM codding. And guess what this results in fuzzy bytes.

vroom_trk78_zoom.PNG

You can look at this with Aufit by using the read Track Buffer command and change the Rev value. You will see that for
rev 1 we have A1 A1 A1 FB 00 4E 80 00 E7 7F FB 7F F7 BF 7F FF FF FF FF…
rev 2 we have A1 A1 A1 FB 00 4E 80 00 E7 7F FB 7F E5 BF 7F FF FF FF FF…
rev 3 we have A1 A1 A1 FB 00 4E 80 00 E7 7F FB FF F5 00 80 00 00 00 00 …
Etc.

So you see that the beginning is always the same but after few bytes we have fuzzy bytes and there is no way to describe this with the STX format

[DrCoolZic]

No, this is for a STX that contains both track data and fuzzy sector data.
In that case, the track data don't show any fuzzy bytes (this is not supported in STX) but they should because the embedded sectors are fuzzy ; so in all logic, you should be able to mix the fuzzy sectors with the track image to get a fuzzy track. But this is not supported in pasti.dll.

Then in that case it will give wrong results in most cases because as I mentioned in most cases the "sector" data in a read track are DIFFERENT from the data in the read sector.
But is should not matter much as the data are fuzzy anyway

[DrCoolZic]

So it looks like we now have two games that uses fuzzy bytes in a read track!

• Power Drift
• VRoom

[AtariZoll]

Yes, public Pasti imager writes always track dump ( made with track read command ) for all tracks. But only 1 rotation sample.
As I said, code for track 78 is at $5532 - it is well visible that track read command is used.

It would be good that someone ( DrCoolZic ? ) extract all 5 track dumps of side A, track 78 from SCP image and post here, so I can load all them in order, after track readings finished in Steem Debugger - then will see exactly how copy protection check works and confirm that this is really case of fuzzy data in track read.

[DrCoolZic]

Unfortunately Aufit do not currently have write track data capability ... so I cant do it

Pure speculation ...
The code is probably looking for the non readable last sector located after sector 9 in the read track data
For that matter look for A1 A1 A1 FB sequence and compare the first few bytes (looks like byte 8 is a good candidate)

If you want to simulate what you can do is put a break point after reading track and substitute byte 8 ion the non readable last data record
bellow is an image of the end of track 78

vroom_trk78_read_track_data.PNG

[Steven Seagal]

Thanks for tracing this ; the CTR dump is working in Hatari, but not in latest Steem according to Brume, this would confirm some kind of fuzzy bytes in the track, because Hatari correctly handles revolution's counter for capslib 5.1 and AFAIK it's not yet the case in Steem (so Steem will always read the same track data, not the next revolution)

It works in current build though, it must be the same "unlocking" problem we discussed.
I'm tempted to release a v3.6.4 with this fix, this would be the "CTR car race build" (Outrun, Vroom).