Dragonflight

Steven Seagal · Post by **Steven Seagal** » Tue Apr 29, 2014 7:12 pm

dlfrsilver wrote: Steem would require 'ghost write' like in winuae for games that are writing on themselves. otherwise, another solution would be like on amstrad CPC, we had a first the DSK format, which was for cracks and only that, then the EDSK format has been created, it can holds ANY protection due to its flexibility, even weak bits protections. The *.ST format should be enhanced to support special formats. This would be the solution for games like dragonflight.

When I wrote the OP that's how I thought, after further analysis, ghost disks and a disk format able to handle such case are two separate issues. In a later version of Steem, there will be ghost disks, .STG, for pasti, ipf, but basic, just some sector R/W intercept. Enough to save your score in Supercycles (my request for other cases still holds: http://www.atari-forum.com/viewtopic.php?f=4&t=26417).
And maybe a new disk image format, .STW, but this is harder, if interesting.

dlfrsilver · Post by **dlfrsilver** » Wed Apr 30, 2014 7:35 pm

Steven Seagal wrote:
dlfrsilver wrote: Steem would require 'ghost write' like in winuae for games that are writing on themselves. otherwise, another solution would be like on amstrad CPC, we had a first the DSK format, which was for cracks and only that, then the EDSK format has been created, it can holds ANY protection due to its flexibility, even weak bits protections. The *.ST format should be enhanced to support special formats. This would be the solution for games like dragonflight.
When I wrote the OP that's how I thought, after further analysis, ghost disks and a disk format able to handle such case are two separate issues. In a later version of Steem, there will be ghost disks, .STG, for pasti, ipf, but basic, just some sector R/W intercept. Enough to save your score in Supercycles (my request for other cases still holds: http://www.atari-forum.com/viewtopic.php?f=4&t=26417).
And maybe a new disk image format, .STW, but this is harder, if interesting.

Thank Steven for developping these

Steven Seagal · Post by **Steven Seagal** » Sat May 24, 2014 9:58 am

There will be a new disk image format, STW, able to handle Dragonflight.
I will open an apart thread in Steem/Development for the description.
(EDIT: http://www.atari-forum.com/viewtopic.ph ... 7&p=253577)

Meanwhile, since I asked technical questions here, I'll give the technical answers here as well.

This game creates backup disks, that you need to play, with a very special format.
1) Except the first one, each track is made up of five 1024 byte sectors and one 512 byte sectors, which allows to cram more data thanks to fewer inter-sector gaps.
2) Tracks all have the same recorded number (ID field): 178. This number is obtained by using the $F7 format code, that orders the WD1772 to issue two CRC (control) bytes. Notice that the CRC of the ID field itself is correct.
3) Each track has a special header in the pre-data gap zone (so an emulator really needs all the bytes of the disk, not just data and ID fields). This header is obtained by using the format codes $F5 (address mark) and $F7 (CRC).
Techniques of points (2) and (3) seem to have been used for fun by the author. We thank him because after much head-scratching they give us some good insights into the WD1772.
1) Contrary to what the doc states, the CRC Register isn't preset to ones
($FFFF) prior to data being shifted through the circuit, but to $CDB4.
This happens for each $A1 address mark (read or written), so the register
value after $A1 is the same no matter how many address marks.
When formatting the backup disk, Dragonflight writes a single $F5 (->$A1)
in its custom track headers and expects value $CDB4.
2) The format code $F7 may be used inside an ID field. The CRC bytes are added
to the CRC, so that this is correct. This implies that at the receipt of
$F7, the WD1772 saves the current value of the CRC (at least the lower
byte), before it is modified by adding the upper byte to the logic.
3) $F7 will trigger output of CRC only if the CRC is non null (Dragonflight
track headers).
Notice that the CRC is null if after a reset you output it:
$F5 -> $A1, CRC = $CDB4
$F7 -> $CD, $B4, CRC = 0
$F7 -> $F7
So the 2nd $F7 is really written $F7 on the disk.

Steven Seagal · Post by **Steven Seagal** » Wed Jun 25, 2014 8:33 am

AtariZoll wrote: Another game with saves on non-standard floppy is Realm of the Trolls (aka Down at the Trolls) . It is with 512 byte sectors, but with sector #s starting at 0.
http://atari.8bitchip.info/ASTGA/R/realmtr.php

Looking at this case, dbug version, there's one more thing to emulate:
Data is written and read over the index pulse. Funny how challenging just a few cases are.

The game crashes in Steem, both versions, when you click 'Find halls not saved' in the 'Editor'.

[Edit] Works the same STF & STE.

AtariZoll · Post by **AtariZoll** » Wed Jun 25, 2014 3:17 pm

Would be good to see image of original.

DrCoolZic · Post by **DrCoolZic** » Sun Dec 14, 2014 11:17 pm

please post an image

DrCoolZic · Post by **DrCoolZic** » Sun Jan 18, 2015 7:58 am

alexh wrote:There were three localisations of the Atari version (English, French, German) which ones do you have? I have all three.

Dragonflight for Atari ST comes with three disks (A, B & C). Two of the disks (B & C) are never used directly. The game install makes backups of these two disks to "play" disks.

The game is designed to be playable on Atari ST with a single sided disk drive. I believe that Disk A and Disk C are single sided and B is double sided where the second side contains the data on Disk C.

Did you post the image somewhere?

alexh · Post by **alexh** » Sun Jan 18, 2015 10:41 am

I don't have a Kryoflux or SCP.

I only have an SD HxC and the retro computers themselves (Amiga 4000, Falcon MegaSte).

I would hapilly do this game (all three localisations) and Thalion Sound Demo if I had access to one.

I'm based in Oxfordshire UK if there is anyone nearby?

How much are the Kryoflux/SCP? About £100 inc postage? I don't think justify the cost for only a couple of disks.

Post by **Brume** » Sun Jan 18, 2015 12:25 pm

alexh wrote:I don't have a Kryoflux or SCP.

I only have an SD HxC and the retro computers themselves (Amiga 4000, Falcon MegaSte).

I would hapilly do this game (all three localisations) and Thalion Sound Demo if I had access to one.

I'm based in Oxfordshire UK if there is anyone nearby?

How much are the Kryoflux/SCP? About £100 inc postage? I don't think justify the cost for only a couple of disks.

Kryoflux' team will certainly correct me if I'm wrong, but an Amiga can now produce Kryoflux dumps:
http://forum.kryoflux.com/viewtopic.php?f=2&t=797

DrCoolZic · Post by **DrCoolZic** » Sun Jan 18, 2015 1:30 pm

I will comment the "technical post" from SS later but here is what I read with Aufit from the posted SCP file

dragonflight-t01.0.png

This using same sequence as union demo see http://www.atari-forum.com/viewtopic.ph ... 64#p265764

and Jupiter Masterdrive

jputer-t02.0.png

I have tried on my Atari the sequence F5 F7 F7
and when I read back I NEVER NEVER get C2 0B CD B4 F7
But when I read Jupiter master drive on real atari I ALWAYS ALWAYS get C2 0B CD B4 F7

I have tried many write combination to get C2001C921090C20BCDB4F700DEADC0DE (see my doc http://info-coach.fr/atari/documents/_m ... ection.pdf page 52)
So I do not think it is possible to write on Atari?

This drive me crazy?!?

DrCoolZic · Post by **DrCoolZic** » Sun Jan 18, 2015 1:59 pm

It seems even more complex than that ?!
Writing F5 F7 F7 does not always result in CD B4 F7
It seems that it depends on what is in front of the sequence
for example having 00 00 00 ... sequence in front will not produce CD B4 F7
but if 4E 4E 4E .... sequence in front it produce CD B4 F7

but never seen C2 0B

Here is the input to write

t02_1-write.PNG

And the result reading

t02_1-read.PNG

DrCoolZic · Post by **DrCoolZic** » Sun Jan 18, 2015 2:13 pm

Here is the track sampled with Kryoflux and analyzed by Aufit

T2-track.png

Cool. I started to wonder if Aufit was not decoding correctly

but it is decoded perfectly

For detail of the sync actually on the track (5224 in blue 4489 in red)

T2-head.png

DrCoolZic · Post by **DrCoolZic** » Sun Jan 18, 2015 3:57 pm

Steven Seagal wrote: This game creates backup disks, that you need to play, with a very special format.
1) Except the first one, each track is made up of five 1024 byte sectors and one 512 byte sectors, which allows to cram more data thanks to fewer inter-sector gaps.
2) Tracks all have the same recorded number (ID field): 178. This number is obtained by using the $F7 format code, that orders the WD1772 to issue two CRC (control) bytes. Notice that the CRC of the ID field itself is correct.
3) Each track has a special header in the pre-data gap zone (so an emulator really needs all the bytes of the disk, not just data and ID fields). This header is obtained by using the format codes $F5 (address mark) and $F7 (CRC).
Techniques of points (2) and (3) seem to have been used for fun by the author. We thank him because after much head-scratching they give us some good insights into the WD1772.
1) Contrary to what the doc states, the CRC Register isn't preset to ones ($FFFF) prior to data being shifted through the circuit, but to $CDB4. This happens for each $A1 address mark (read or written), so the register
value after $A1 is the same no matter how many address marks. When formatting the backup disk, Dragonflight writes a single $F5 (->$A1) in its custom track headers and expects value $CDB4.

This is a relatively well known behavior that I have discussed with Ijor long time ago. I have described this here http://info-coach.fr/atari/hardware/FD- ... _in_WD1772 many years ago.
I have also discussed that with IFW recently because he has a deep knowledge of the WD1772. It turn out that this is relatively irrelevant when emulating reading stream file because the only way to read a sector is to ALWAYS have 3 x 4489 sync sequence (not less not more). The only exception is to have 7 x 4489 the fourth sync is taken as an IAM and the WD1772 in that case rearm the sync detector and therefore takes the correctly the remaining 3 x 4489. But if you place for example 6 x A1 in front of the ID field the sector will not be found. People get confuse because they only see 2 x 4489 sync in the read track usually preceded by a C2 or 14 or equivalent. This is what is put in the DSR of the WD1772 but the sync detector sees correctly the 3 x 4489.
My original code was using the C4DB value but it was creating problems under certain circumstances. Therefore now the CRC is computed inside the stream decoder using directly data shifted in the sync decoder and reset is always performed on the first A1.

2) The format code $F7 may be used inside an ID field. The CRC bytes are added to the CRC, so that this is correct. This implies that at the receipt of $F7, the WD1772 saves the current value of the CRC (at least the lower byte), before it is modified by adding the upper byte to the logic.

Nice information it makes sense

3) $F7 will trigger output of CRC only if the CRC is non null (Dragonflight track headers). Notice that the CRC is null if after a reset you output it:
$F5 -> $A1, CRC = $CDB4
$F7 -> $CD, $B4, CRC = 0
$F7 -> $F7
So the 2nd $F7 is really written $F7 on the disk.

Again very nice information.
However as mentioned in a previous post this does not seems to work in all cases. My bet is this depends of the preceding bit but I need to test more.

Steven Seagal · Post by **Steven Seagal** » Sun Jan 18, 2015 6:23 pm

DrCoolZic wrote:This is a relatively well known behavior that I have discussed with Ijor long time ago. I have described this here http://info-coach.fr/atari/hardware/FD- ... _in_WD1772 many years ago.

Still doubtful though, I haven't found this behaviour in CRC doc.

[...]
3) $F7 will trigger output of CRC only if the CRC is non null (Dragonflight track headers). Notice that the CRC is null if after a reset you output it:
$F5 -> $A1, CRC = $CDB4
$F7 -> $CD, $B4, CRC = 0
$F7 -> $F7
So the 2nd $F7 is really written $F7 on the disk.
[...]
Again very nice information.
However as mentioned in a previous post this does not seems to work in all cases. My bet is this depends of the preceding bit but I need to test more.

But doubtful too. I have no special knowledge, I just looked at what Dragonflight seems to expect for all my findings.
This hasn't been tested on hardware.

DrCoolZic · Post by **DrCoolZic** » Mon Jan 19, 2015 9:29 am

Is there anybody with a good version of dragonflight and a Kryoflux or SuperCard Pro board?

There is an scp version available on retrobackup but quality does not seems good enough so I have not been able to cretae working copies on FD of the games.

So what I would need is the following
1) a good sampling of disk a / b-c / c if possible with multiple revolutions - 5 would be perfect

2) start the game and select create a backup
- you will be asked to format a disk at the end a number will be provided - please note this number
- now copy disk b to this newly formatted disk (follow instruction)
I never succeeded to go further as the program always indicates that the disk is corrupted ??? So seems like my copy did not succeed
- it might also ask you to make a backup of disk c?

3) So now you should have one or two new "backup disks" created
Please create scp / raw images of these backup disks if possible with multiple revolutions - 5 would be perfect

and publish or send
thanks in advance

Maartau · Post by **Maartau** » Mon Jan 19, 2015 4:19 pm

Will also be interested by a KF or SCP

...

DrCoolZic · Post by **DrCoolZic** » Mon Jan 19, 2015 4:39 pm

DrCoolZic wrote:It seems even more complex than that ?!
Writing F5 F7 F7 does not always result in CD B4 F7
It seems that it depends on what is in front of the sequence
for example having 00 00 00 ... sequence in front will not produce CD B4 F7
but if 4E 4E 4E .... sequence in front it produce CD B4 F7

but never seen C2 0B

See the solution here http://www.atari-forum.com/viewtopic.php?f=104&t=27448

DrCoolZic · Post by **DrCoolZic** » Tue Jan 20, 2015 8:34 am

Playing Dragonflight on current Steem or Hatari
You might be interested to know how to play dragonflight on current version of Steem or Hatari.

Here is the procedure:
Load dragonflight-a.stx in Steem and start
In the main menu select create a new game

dragon-1.PNG

After introduction you will be asked to insert the backup disk B

dragon-2.PNG

Place dragonflight-backup-b.stx in drive A of Steem
The program detects automatically the presence of the disk and loads the game
Now you can play

dragon-3.PNG

Notes:
1 - this does not work if I use the published stx files. It seems (?) that the backup file has to match the disk A (?) So I provide a disk A stx
2 - Of course currently you cannot save the game but new Steem with STX files and new Hatari with wd1772 files should be able to save game
3 - I have produced the backup disk based on FD generated with SCP files published on AF. However as explained above these originals do not seems to be of good quality because the creation of disk b backup always fail for me during the checking phase (see http://www.atari-forum.com/viewtopic.ph ... &start=575). However the backup disk seems of good enough quality so you can play the game

4 - SO PLEASE someone that have a real dragonflight diskset please provide good image of it ....

Provided disk-a and backup-disk-b in stx format as generated by Aufit 0.9
Notice that the size of the stx images is much smaller that the one published on Internet. Thanks to Aufit using the Pasti optimization capability (use track data in sector).

Enjoy

DrCoolZic · Post by **DrCoolZic** » Tue Jan 20, 2015 2:27 pm

Steven Seagal wrote: ... insights into the WD1772.
1) Contrary to what the doc states, the CRC Register isn't preset to ones ($FFFF) prior to data being shifted through the circuit, but to $CDB4. This happens for each $A1 address mark (read or written), so the register value after $A1 is the same no matter how many address marks.

Correct this has been verified

2) The format code $F7 may be used inside an ID field.

Correct this has been verified

3) $F7 will trigger output of CRC only if the CRC is non null

Incorrect F7 always output CRC unless escaped (see below).

The character $F7 is an escape character: this means that the byte after the $F7 will never be interpreted as special character by the wd1772
For example
F7 F7 will produce XX XX F7
F7 F5 will produce XX XX F5
F7 F7 F7 F7 F7 F7 F7 F7 .... will produce XX XX F7 F7 F7 F7 F7 F7 F7 ....

More info here http://www.atari-forum.com/viewtopic.ph ... 10#p265877

DrCoolZic · Post by **DrCoolZic** » Tue Jan 20, 2015 3:21 pm

DrCoolZic wrote: I have tried many write combination to get C2001C921090C20BCDB4F700DEADC0DE (see my doc http://info-coach.fr/atari/documents/_m ... ection.pdf page 52)
So I do not think it is possible to write on Atari?
This drive me crazy?!?

Yes we can - see here http://www.atari-forum.com/viewtopic.ph ... 38#p265938

DrCoolZic · Post by **DrCoolZic** » Wed Jan 21, 2015 9:26 am

More information about how the protection works

I have received a backup from Jim of disk B see http://www.atari-forum.com/viewtopic.ph ... 28#p266011
From that SCP file I have created an STX file with Aufit.
Then I have used my new version 0.8 of AIR (pasti reader) to compare the STX files.

They have the same content with 2 exceptions: T00.0 S2 and T00.1 S2 differs.
When you are asked to create the backup, after formatting the backup disk an hexa number is given. For me it was 90 BA 64 (note: this seems a random number different each time you format backup disk).
This number is written at beginning of sectors mentioned above. I have used notepad+ to shown the difference:

dragon-jim-vs-mine.PNG

Then I have tried to see what is the difference between the original and the backup.
Here I had to use KDIFF3 to check the difference because there are a lot of differences.
Of course we find the differences already mentioned of the random number but then we have a lot of differences on all tracks side 1 starting at track 1
The original is double sided with real data on both side
The backup is also dual sided but in fact it does not contain any useful information on side 1 as all the sectors contains 00 bytes. The magic 14 0B CD B4 F7 sequence is written + all same sectors as the original just that they only contain 00 bytes. I think I remember to have seen somewhere that the game was suppose to run on single sided machine. This may be why no useful information is written on side 1 ???

dragon-ori-vs-jim.PNG

For info I have tested running the Game on Hatari using the procedure described above (using backup disk b) and it works fine. But in order for the game to load (hitting the space bar) I had to disable the joystick in Hatari configuration (see http://www.atari-forum.com/viewtopic.ph ... 08#p266024)

Also tested using Jim disk b backup (converted to stx) and works the same. This seems to indicate that you should be able to use any backup disk. I think the only constraint is that if you create backup for disk B and C they must use the same number, but I have never been asked for disk C because the save process failed for me (see above).

Anybody have been asked to create a backup for disk C ????

alexh · Post by **alexh** » Wed Jan 21, 2015 11:50 am

AFAIR, Disk A is single sided, Disk C is also single sided and Disk B is dual sided with Disk C on side 1.

DrCoolZic · Post by **DrCoolZic** » Wed Jan 21, 2015 12:12 pm

alexh wrote:AFAIR, Disk A is single sided, Disk C is also single sided and Disk B is dual sided with Disk C on side 1.

On a working set do you have to create a backup of disk B and Disc C?
According to Jim the reason why disk B is requested twice is to read the two sides, but he did not say if after reading the second side of disk B a backup for disk C is written?
I think in the help file it is mentioned that backup B and C must use the same number?

alexh · Post by **alexh** » Wed Jan 21, 2015 1:11 pm

Unfortunately I do not remember.

If you have a double sided drive you don't need and never use Disk C so I suspect not if you have a double sided drive.

JimDrew · Post by **JimDrew** » Wed Jan 21, 2015 4:59 pm

Disk A is double sided. Disk B is also double-sided. Disk C is single sided, and that is never asked for in the backup menu. I get no failures of disk B, but at no time am I asked for disk C.

Atari-Forum

Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight

Re: Dragonflight