WANTED: most missing images

[DrCoolZic]

I just looked at Albedo
It is strange that it does not work with current Steem. Here is the start of the track

albedo-t00.0-start-new.PNG

Nothing very exciting We have the first sector id field just at the beginning of the track without 4E gap.
So why it did not work with Aufit 0.4c? look at the same start of track

albedo-t00.0-start-old.PNG

As you can see the 3 Sync mark where not detected perfectly.
Pasti wanted to be smart so before the first A1 the bits are complemented (shifted?) so all the bits before the A1 will be returned changed by pasti.dll.
Program must be reading track and testing for 00 followed by 14 A1 A1 or C2 A1 A1 ???
I guess that this is why it does not work in Steem. So normally if you use the patched dll it should work.

beyond that some weird sequences are written at end of track but do not know if checked.?

albedo-t00.0-end.PNG

[DrCoolZic]

Also - may be not part of protection but data tracks are quite strange.
here is a global view with $C2 display turned on

albedo-t01.0.png

usually with this kind of data track you have a sync sequence a beginning and then "escaped data" until the end

Here you can see that the data track is split in 5 areas each starting with the following sync sequence
1st part C2C2C2C2A1A1A1A1
following parts C2A1A1A1 (reas as 14A1A1A1)
see atached rtf file

t01.0-track.rar

and then at the end of the track the same sequences as used in track 00.0:
long sequence of $C2 followed by sequence of $F5 followed by long sequence of $F7

Quite strange

again look at the rtf file (need program like MS word to read)

[DrCoolZic]

note that at end of all data tracks we have before the sequences already described the word MYRIAD encoded

albedo-t01-track-end.PNG

[DrCoolZic]

I just checked the generated stx file and indeed it works in Hatari but not in Steem even with the patched DLL provided here viewtopic.php?f=47&t=15121#p251563

So really do not know why it wont work on Steem?
May be a problem with read track? But unless Steem 3.7 bypass pasti dll dont know why it works on new version and not on old patched?

seems like last read is sector 41 on track 0?

[AtariZoll]

I tested with randomizer patched pasti.dll at start. So, problem is not there for sure. After some more time spent, I see that even with regular Pasti 02H it starts in approx every 10th case (passes prot. test) . Code is tricky and long. There is usage of Timers B and C, and I'm sure that it tests some times while reading track 0's sectors, which has some data in gaps for first stage of tests.
Trk. 0 sector data : Sectors: 6 #s: 10x3, 5x3, 20x2, 15x3, 41x3, 1x2 - 3 means 1K sector, 2 means 512byte sector .
I think that it is timing issue, read track test passes, but as we know Pasti sector read timings are not too accurate. Probably it is fixed, improved in latest Hatari, and in latest Steem SSE beta ...
In any case, STX image self is OK.

Ah, and considering "Amiga tracks" - I complained against using that term couple times in past, but some just repeat their own, without really thinking about ..

I was not sure about what patch Steven made with Pasti - looked, and it is randomizer, for problem we discovered with Jupiter Masterdrive - eh, short memory

[DrCoolZic]

I cannot find the problem. This is very hard to explain what is going on

On Hatari it works all the time. On Steem based on you input I have tried to start the game may be 30 times and ONE and only ONE time it started ???????

As far as timing one track 00.0 the clock seems not to change above normal spec so does not seems like we have bit width variation. And anyway this is not written in STX file so it wont work on Hatari.

The only other possible timing measure would be position of sectors. You describe sectors 10 5 20 15 41 1
on the actual track the order is 1 10 5 20 15 41
with sector 1 being located extremely close to index no 4E gap byte.
So may be they check position of this sector relative to index a look for a value of about 200 ms ???

[DrCoolZic]

Based on my previous post I have further experimented.
Pasti support track image with 2 bytes or 4 bytes track header. With 4 bytes header the pasti image give the offset of the first sync byte in the track
see http://info-coach.fr/atari/documents/_m ... tation.pdf section 2.2.4.1.1 page 6 for more info

Latest release of pasti imager does not seems to write this information and therefore Aufit does not write it either. But the code is there so just had to change the value of a switch and I have generated a file with FirstSyncOffset values in header.
And now in works in Steem in most cases (but not always).

So there must be a problem to measure the timing of this first A1 in Steem and using stx with 4 bytes header definitively help.
Most probably some timing issues have been fixed in new version ????
To bad Mr Steven Seagal is not looking at this thread it would probably know?

attached is a version with sync-header.
Note that the program run consistently with or without header in Hatari

[AtariZoll]

...
The only other possible timing measure would be position of sectors. You describe sectors 10 5 20 15 41 1
on the actual track the order is 1 10 5 20 15 41
with sector 1 being located extremely close to index no 4E gap byte.
So may be they check position of this sector relative to index a look for a value of about 200 ms ???

I used STX image by Brume, what is not made via Aufit. So, it seems that by imaging happened that WDC missed first sector, and therefore it is last in STX . I need to look better in STX about it ...

[DrCoolZic]

Image posted by Brume is version 3.2 (latest) done with tool=01 (pasti image writer) and as I said latest version of pasti imager does not write Sync position

albedo-stx-pasti.PNG

my image is 3.2 tool=AF (for Aufit ) and has SyncPos

albedo-stx-aufit.PNG

I have added a checkbox in next release of Aufit so will be an option
New release also write ST file for non protected FD

[DrCoolZic]

Actually one big difference is that first sector with Aufit is sector 1 at bit position 90 (see previous post)
and the one made with pasti imager sector 1 is the last with a bit position of 50144 this value seems extremely suspicious ??? knowing that the track has 39469 flux ???

It is strange that pasti does not find this sector at start of track?
Could be that it issues a read address command after receiving index interrupt and that WD1772 does have enough time to get ready to read?

[DrCoolZic]

looking at "data tracks" they are definitively broken in five "big sector".

Each sector is prefix with 3 A1 sequence. Doing this allow to have huge sector and to re-synchronize 5 times. Therefore this must be more reliable than the standard "all data in one huge sector"

[AtariZoll]

Actually one big difference is that first sector with Aufit is sector 1 at bit position 90 (see previous post)
and the one made with pasti imager sector 1 is the last with a bit position of 50144 this value seems extremely suspicious ??? knowing that the track has 39469 flux ???
It is strange that pasti does not find this sector at start of track?
Could be that it issues a read address command after receiving index interrupt and that WD1772 does have enough time to get ready to read?

Yep. most likely there is more delay after index in Pasti imager than time to first sector header.
With your patched STX, success rate is about 30% - passes prot. check in every 3rd run in Steem 3.2 . Will try to look that nasty code better tomorrow ..

[Steven Seagal]

There's no special improvement in v3.7 for this case.
In current build the 1st STX version fails most of the time, though you may have a lucky streak.
The albedo-with-sync-header version seems to load most of the time.
The CTR version seems to never fail.

[DrCoolZic]

This is strange. I wonder if there are some switch not set correctly for me.
The ctr version form Brume never loads I get to the desktop after some time and if I try to open the disk A it says data may be corrupted?

would you have any idea why it works on Hatari and not on Steem
I suspect this is related to position of sector 1 but it is unclear.

did you try ctr on 3.6.4 or 3.7 beta?

I have several ctr/ipf not working. Do you need to setup Steem with specific options for this to work?
viewtopic.php?f=104&t=27335&p=265709#p265709

[npomarede]

Based on my previous post I have further experimented.
Pasti support track image with 2 bytes or 4 bytes track header. With 4 bytes header the pasti image give the offset of the first sync byte in the track
see http://info-coach.fr/atari/documents/_m ... tation.pdf section 2.2.4.1.1 page 6 for more info

Latest release of pasti imager does not seems to write this information and therefore Aufit does not write it either. But the code is there so just had to change the value of a switch and I have generated a file with FirstSyncOffset values in header.
And now in works in Steem in most cases (but not always).

So there must be a problem to measure the timing of this first A1 in Steem and using stx with 4 bytes header definitively help.
Most probably some timing issues have been fixed in new version ????
To bad Mr Steven Seagal is not looking at this thread it would probably know?

attached is a version with sync-header.
Note that the program run consistently with or without header in Hatari

Hi

in my case in the STX library I wrote for Hatari, I never use the Sync Position available in some cases before track data, because I just didn't find any doc for it, and all games seem to work well without this so far. So I have no idea what the original pasti.dll does with this. Maybe it's related to the "pseudo random" bytes returned by a read track before the first 3 A1. When doing multiple read track on a floppy, we can see that these bytes are changing and I think pasti.dll tries to mimic that, but it fails sometimes (I think that's what prevented Jupiter Masterdrive from working). Under Hatari I also never try to randomizes those first bytes, I returned them as they were stored in the STX files.

Nicolas

[dlfrsilver]

As said, Albedo only works with Steem beta 3.7.0. ; It doesn't work on steem 3.6.4 ;

and Aufit last release is able to make a good STX file with no problem.

[DrCoolZic]

in my case in the STX library I wrote for Hatari, I never use the Sync Position available in some cases before track data, because I just didn't find any doc for it, and all games seem to work well without this so far. So I have no idea what the original pasti.dll does with this. Maybe it's related to the "pseudo random" bytes returned by a read track before the first 3 A1. When doing multiple read track on a floppy, we can see that these bytes are changing and I think pasti.dll tries to mimic that, but it fails sometimes (I think that's what prevented Jupiter Masterdrive from working). Under Hatari I also never try to randomizes those first bytes, I returned them as they were stored in the STX files.

Nicolas

This makes sense. My guess is that it is here for historical reason. Now the pasti imager does not write it anymore. Basically it allows you to find the location of the first sector.
But the right way to find position of sectors is to use the bitPosition of the SectorDescriptor. This value gives the position by counting the number of DATA bits (not MFM bits) so assuming 2µs for cell you can multiply the bitPosition by 4 to get the position. Of course you have to wrap around if this value is bigger than 200ms (you should do it because it works in Hatari )

Now back to Albedo

Actually one big difference is that first sector with Aufit is sector 1 at bit position 90 (see previous post)
and the one made with pasti imager sector 1 is the last with a bit position of 50144 this value seems extremely suspicious ??? knowing that the track has 39469 flux ???

In the file generated by Pasti for reason I ignore the first sector (sector 1) is read as the last sector of the track. The position is 50144 in bit or roughly 200576 µs. So this is really 576 µs
In the file generated by Aufit the position is 90 in bits or 360 µs
Now if you take the pasti with fistSync offset, that I have generated, a value of 8 is given for the first sector (sect 1). If you add the sync this gives you a position of (8+3) * 32 = 384 µs and I guess this is helping pasti to compute the right position for sector 1.

I do not have the Albedo disk so I would be interested if someone (Brume?) with the disk can make the following test:
- with albedo in the drive starts Panzer
- execute the "Read IDs" command on track 0
- report the result

This command wait for the index pulse then send 24 read address commands and figure out the number of sectors on the track and of course their order.
If there is enough time between the detection of the index pulse and reception of the read address commands then the WD1772 should find sector 1 as the first sector. Otherwise if it is not the first it will be placed as the last.

[AtariZoll]

As said, Albedo only works with Steem beta 3.7.0. ; It doesn't work on steem 3.6.4 ;

and Aufit last release is able to make a good STX file with no problem.

Please. try to be more accurate. It is called Steem SSE beta ... And not only with it, but Hatari 1.8 - you contradict to your previous post.
And we understood all from your first post about that. But, we aim not playing game on PC, we want to know what happens, and to understand where exactly is the reason why it fails with regular Pasti.dll . So, I traced it in Steem Debugger 3.2, with couple Pasti versions.

I was not able to test with Steem SSE Beta 3.7 - really don't see where can get it - and I need Boiler v. But tested with Hatari 1.8 . Unfortunately, it is pain in the ass to set it properly - to get rid of double bus error halts of emulator - what this version of Hatari somehow likes a lot to do
After that initial trouble I can say that both STX images work 100%, so all runs were successful . What means that problem is not that sector #1 is placed as last in genuine STX. I traced code a lot, and it does some very tricky sector loading time measurings, what sets proper value in reg d6, for further decrypting while load game code, data . And as we know, in this emulator versions were made some improvements in better rotation emulation, sector loading times, etc. Hatari uses not Pasti.dll , which is not much accurate in this.
So, the problem is Pasti.dll , and not Pasti imaging tool in this case.

[dlfrsilver]

As said, Albedo only works with Steem beta 3.7.0. ; It doesn't work on steem 3.6.4 ;

and Aufit last release is able to make a good STX file with no problem.

Please. try to be more accurate. It is called Steem SSE beta ... And not only with it, but Hatari 1.8 - you contradict to your previous post.
And we understood all from your first post about that. But, we aim not playing game on PC, we want to know what happens, and to understand where exactly is the reason why it fails with regular Pasti.dll . So, I traced it in Steem Debugger 3.2, with couple Pasti versions.

I was not able to test with Steem SSE Beta 3.7 - really don't see where can get it - and I need Boiler v. But tested with Hatari 1.8 . Unfortunately, it is pain in the ass to set it properly - to get rid of double bus error halts of emulator - what this version of Hatari somehow likes a lot to do
After that initial trouble I can say that both STX images work 100%, so all runs were successful . What means that problem is not that sector #1 is placed as last in genuine STX. I traced code a lot, and it does some very tricky sector loading time measurings, what sets proper value in reg d6, for further decrypting while load game code, data . And as we know, in this emulator versions were made some improvements in better rotation emulation, sector loading times, etc. Hatari uses not Pasti.dll , which is not much accurate in this.
So, the problem is Pasti.dll , and not Pasti imaging tool in this case.

i use pasti 0.2h dll, and i hope that Steven won't disagree, but check your PM for Steem SSE Beta 3.7.0. for you to check.

The first STX i got from Brume doesn't work, (either on Steem 3.6.4 or 3.7.0 beta).

[AtariZoll]

Thanx Silver. I tested .. and it is nothing better in Steem SSE 3.7 beta than in Steem 3.2 . If you are lucky, it will start - by me it was in about 1/3 attempts. Only in Hatari 1.8 it starts always, and genuine STX (not done via Aufit) too.

So, more testings .. I decided to play with sector timings in STX file. After some tries I set all sector load time values for track 0 to 0 - what means normal loading times (btw. there are some very strange values) , and all sector start times relative to index to $0200 .
And success rate was still same ! What leads me to conclusion - after seeing some testing of DMA mid. counter in code - that emulation must emulate enough accurately rotation and DMA transfers too . I guess that npomarede could say something too ...

[npomarede]

And success rate was still same ! What leads me to conclusion - after seeing some testing of DMA mid. counter in code - that emulation must emulate enough accurately rotation and DMA transfers too . I guess that npomarede could say something too ...

Hi
regarding Hatari, I really spend dozens of hours for 1.8 to write test programs on my STF to very precisely measure timings in all possible FDC command (seeking, reading, index pulse, transferring data, ...). As for transfers through DMA, they're buffered in a DMA FIFO as the real HW would do.
I think that one main difference at the moment between Hatari and Steem (unless it was changed lately in Steem) is that Hatari really handle all the FDC events at the cycle level, while in Steem the FDC operations are updated on every HBL (FDC emulation is updated every HBL, not after each CPU instruction). This will of course create rounding errors that could explain the difference you saw in read sector's timings.
Note that as the FDC will only transfer 16 bytes at a time with the DMA, the rounding error will not be that big when transfering data, because you need to align on the DMA anyway and group everything in blocks of 16 bytes ; but if you want to accurately start a transfer at the 347th bytes of a track for example, then it could matter (but I don't remember how Steem's code handles this, so maybe it's not the case anymore). When using pasti.dll, I don't know if the events are handled every HBL or with a better accuracy.

But maybe the problem is in pasti.dll and it could be complicated to patch.

Else, I'm surprised Hatari stopped on bus error for you, what version/OS did you use ? By default Hatari is supposed to continue when bus error or other exceptions are encountered.

Nicolas

[AtariZoll]

OK, now we know why Hatari 1.8 is so slow with floppies
Seriously - lot of work is needed because only couple titles, with very weird solutions. As said, I'm not sure that this is what we need to focus on. Steem solved such things via patches. So, instead spending lot of time to make very accurate emulation they went on something what we could describe as semi-cracking . In that time it was probably only way, otherwise it would be too slow for machines of era.
As I know, Steem still emualtes some things via tasks performed in H-blanks, so FDC emul. too. Really have no clue is Pasti using it too. But tests with Microprose Golf proved that timing is not well emulated. And that was much simpler case.

Not bus error, but double bus error. It just appears when should not. I needed to set things in CPU emul, FDC emul. to get rid off .
Maybe config file needs clean up ?

[npomarede]

Not bus error, but double bus error. It just appears when should not. I needed to set things in CPU emul, FDC emul. to get rid off .
Maybe config file needs clean up ?

Yes, maybe remove your current hatari.cfg and start Hatari, it will use default params that should be good. If so, save the config from Hatari to create a new working version.

[dlfrsilver]

OK, now we know why Hatari 1.8 is so slow with floppies
Seriously - lot of work is needed because only couple titles, with very weird solutions. As said, I'm not sure that this is what we need to focus on. Steem solved such things via patches. So, instead spending lot of time to make very accurate emulation they went on something what we could describe as semi-cracking . In that time it was probably only way, otherwise it would be too slow for machines of era.
As I know, Steem still emualtes some things via tasks performed in H-blanks, so FDC emul. too. Really have no clue is Pasti using it too. But tests with Microprose Golf proved that timing is not well emulated. And that was much simpler case.

Not bus error, but double bus error. It just appears when should not. I needed to set things in CPU emul, FDC emul. to get rid off .
Maybe config file needs clean up ?

Pera,

Please try the STX file i made from Brume's dump with latest Aufit. Steem 3.7.0. Beta runs it flawless everytime i load it.

[Steven Seagal]

I think that one main difference at the moment between Hatari and Steem (unless it was changed lately in Steem) is that Hatari really handle all the FDC events at the cycle level, while in Steem the FDC operations are updated on every HBL (FDC emulation is updated every HBL, not after each CPU instruction).

Steem native emulation: HBL
CAPSimg: some cycles are run each HBL (guess it's the same in Hatari)
Pasti: cycle as indicated by pasti.dll - sometimes it's wrong eg MPS Golf, better with Steem native
STW (who cares): cycle ("event")