Question regarding STT images

A forum for anything about the Steem Engine STE emulator, comments, problems, bug reports etc. Steven Seagal regularly provides updated versions of the original STEem code. The current version is v3.9.4.

Moderators: Mug UK, Steem Authors, Moderator Team

Gunstick
Captain Atari
Captain Atari
Posts: 258
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Thu Nov 27, 2003 7:23 pm

do you actually know the book "scheibenkleister"?
A german book of over 800 pages just about storage on the Atari. For the floppy there are 300 pages!

Everything is explained. It's that book who brought us hyperformat and self-made copy protection.

So if you have any questions on the FDC I can answer them (or rather the book can)...

Georges

User avatar
Steem Authors
Steem Developer
Steem Developer
Posts: 540
Joined: Tue Apr 30, 2002 10:34 pm
Location: UK
Contact:

Postby Steem Authors » Sat Dec 06, 2003 5:36 pm

Hi Simon,

Sorry this reply is so late, thanks for your name and all the help.

The ST does suffer the read track problems you mentioned, it certainly is a bit of a pain (I was hoping to just store the result of the read track command in the STT files, but that plan was soon scupperred). Do you think it would be possible to emulate the track corruption? Currently we just return the data without any corruption, but I know of at least one program that relies on some corruption being present.

Thanks again,
Russ

User avatar
Steem Authors
Steem Developer
Steem Developer
Posts: 540
Joined: Tue Apr 30, 2002 10:34 pm
Location: UK
Contact:

Postby Steem Authors » Sat Dec 06, 2003 5:37 pm

Hi Gunstick,

I haven't seen that book, sounds very useful. If I come across anything I need to know I'll contact you.

There is one thing that I keep meaning to test, does it have details of how exactly the write protect bit in the status register works? TOS relies on it being up to date to detect media changes but lots of programs expect it to always be 0 even if the disk is write protected.

Cheers,
Russ

Gunstick
Captain Atari
Captain Atari
Posts: 258
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Sat Dec 06, 2003 9:45 pm

Steem Authors wrote:There is one thing that I keep meaning to test, does it have details of how exactly the write protect bit in the status register works? TOS relies on it being up to date to detect media changes but lots of programs expect it to always be 0 even if the disk is write protected.


Ah the write protect bit... one of the big silly things in the ST

A floppy drive has the signals "disk change" and "write protect"
The ST only has "write protect"
yeah, so to detect disk change, a change on write protect signal is used.
when no disk is in the drive it signals "disk is write protected"
If the floppy disk is protected, no change occurs when swapping disks

WP status flopy status
HIGH non protected disk inside
LOW non protected disk is removed
LOW no disk in drive
LOW protected disk is inserted
LOW protected disk is in drive

Is that what you needed?

Georges

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Postby obo » Sun Dec 07, 2003 12:41 pm

Hi Russ,

Steem Authors wrote:The ST does suffer the read track problems you mentioned, it certainly is a bit of a pain (I was hoping to just store the result of the read track command in the STT files, but that plan was soon scupperred).


I'm having to optionally do that for my SAM Coupé disk images, as there is one title that stores protection data in the inter-sector gaps! What stopped you storing it in the STT files?

Steem Authors wrote:Do you think it would be possible to emulate the track corruption? Currently we just return the data without any corruption, but I know of at least one program that relies on some corruption being present.


I'm 95% sure it's possible to emulate, but it does rely on having the correct raw track information to feed through the algorithm, so you'd probably have to read it with an Amiga/CatWeasel. For my own emulation I return stored track data where available, and am planning to fake the corruption in other cases (assuming normal gap information). I've not coded it yet, as I need to check on some of the notes I made last year.

I believe the corruption is down to the address mark detector being left on during READ_TRACK. It trips over a pattern in the bit-stream, and ends up returning the MFM sync bits rather than the data bits (that's why blank tracks appear mainly as 0xff). From what I remember, I'd pinned down the bit pattern causing the problem, but I'd not finished looking at the switch point to see if any bits were dropped.

Si

Gunstick
Captain Atari
Captain Atari
Posts: 258
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Sun Dec 07, 2003 2:31 pm

Hey, some more quotes from the Scheibenkleiste book about read track and copy protection

first you have to know that reading a track gives always different results as long as there are no sync bytes.
You would need to emulate the physical magnetization of the media and a floppy head reading that and then emulate the MFM decoding.

Now a copy protection would be written into the gap like this
00 00 00 00 F5 F5 F5 10 20 30 40
the protection code is the 10 20 30 40
the 00 00 00 00 part will be read as garbage differently at each read
the F5 bytes generate sync bytes on the disk

Now reading this gives you A1 bye instead of the F5, so reading A1 but writing F5
?? ?? ?? ?? 14 A1 A1 10 20 30 40

Better copy protection
writing 00 00 00 29 10 20 30 40
and then reading gives you crap, but it's always the same
the $29 is the so called killerbit pattern

now to complicate things we write
00 00 00 29 F5 10 20 30 40
And reading that gives
?? ?? ?? 14 0C 10 20 30 40
HUH? no A1 or C2 showing there is a sync byte, that info is masked by the preceding $29


More? Yes there's more
let's write F5 F5 F5 F7 F7 (the F7 should generate checksums)
and reading does not give 2 checksums:
14 A1 A1 CD B4 F7
the first F7 made the CDB4 checksum and the second F7 was written as is!
Writing that back would result in something like
14 A1 A1 CD B4 A1 F2 (the second F7 is now the first F7 and creates a checksum)

combining all this is the following pattern to write track
00 29 F5 F7 F7

the 29 will mask the sync byte and the second F7 gets hidden by a checksum


Having fun with adress fields
write F5 F5 F5 FE F7 F7 02 F7
note the double F7
reading gives
14 A1 A1 FE B2 30 F7 02 AA 14
ok, track $B2, side 48 and sector number $F7... huh, sector $F7 how to write that, because F7 generates a checksum. So writing it and reading back gives:
14 A1 A1 FE B2 30 00 00 ....


Georges

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Postby obo » Sun Dec 07, 2003 10:25 pm

Gunstick wrote:first you have to know that reading a track gives always different results as long as there are no sync bytes.


I suppose that could be faked by randomly changing the start position in the bit-stream. For normal use the only unsynced bit is between the index pulse and the first sync mark, which could be fiddled if it was really needed. Something in the ST world might be sneaky enough to rely on it, but I'm certain no SAM disks do.


Gunstick wrote:You would need to emulate the physical magnetization of the media and a floppy head reading that and then emulate the MFM decoding.


The FDI format (http://www.oldskool.org/disk2fdi) aims to read everything at MFM level, storing as much detail as is needed to represent the disk at the lowest level. It also has short-hand way of representing standard disk structure, so as not to make it too bloated for most disks.

I was going to use FDI for protected disks, but it's 2 years since the original beta, and it's still not finished. Even worse, it's no longer free so I'm giving up on it!


Gunstick wrote:Better copy protection
writing 00 00 00 29 10 20 30 40
and then reading gives you crap, but it's always the same
the $29 is the so called killerbit pattern


From the notes I made last year, I have the bit pattern of "000101001" written down, which is an extra leading zero bit ahead of the 0x29 pattern you mention. I'll have to check it, but I have a feeling it didn't work if the leading bit was a 1 - I'll try out 01 29 when I get a chance. It's also worth noting that this killerbit pattern works anywhere in the bit-stream - it doesn't have to be aligned on a byte boundary to be triggered.

Does the book have any more details on what causes it? Is it just the address mark decoder being enabled?

<snip>
All interesting stuff - thanks for posting it Georges!

Gunstick
Captain Atari
Captain Atari
Posts: 258
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Mon Dec 08, 2003 12:52 am

obo wrote:From the notes I made last year, I have the bit pattern of "000101001" written down, which is an extra leading zero bit ahead of the 0x29 pattern you mention. I'll have to check it, but I have a feeling it didn't work if the leading bit was a 1 - I'll try out 01 29 when I get a chance. It's also worth noting that this killerbit pattern works anywhere in the bit-stream - it doesn't have to be aligned on a byte boundary to be triggered.

Does the book have any more details on what causes it? Is it just the address mark decoder being enabled?


yes indeed it has. The book is VERY detailed

in MFM code:
00-F4 is written as is
F5 is written as sync byte A1 without any clock info, AND the checksum register is initialized to CDB4
F6 is written as sync byte C2, no CRC modif, and C2 is not detected by READ ADR or READ SECT
F7 writes the checksum, next byte is written as is
F8-FF adress marks

btw, short MFM explanation:
0 bit: write as x0
1 bit: write as 01
(x means complement of previous bit) this introduces inside the bytes some regular clock
so writing gives

Code: Select all

1 0 1 0 0 0 0 1  = the written byte (an $A1)
0100010010101001   = the MFM coding

NOTE: somehow the BBS is not formatting code as fixed width, at least not in preview, or not in Mozilla.

ok, now what does "writing A1 without clock" mean
well it has no clock between bit 4 and 5 (with $C2 it's bit 3 and 4)
so it looks like this

Code: Select all

0100010010101001 = normal A1
0100010010001001 = sync A1


the controller has an 'adress mark detector' triggering on missing clock and signals the FDC when it sees the bit pattern

during READ TRACK the adress mark detector is NOT switched off
after the index pluse the controller reads the bits (or the clocks) until a syncbyte
the first sync byte gets read as C2 or 14 and sometimes as 0A
Unfortunately the resync is done on the 000101001 pattern of 9 bits, this happens with
$29 and previous lower bit at 0
$52, $53 and 2 previous bits 0
$A4,$A5,$A6,$A7 and 3 previous bits 0
$14 and following byte's high bit set (bit 7)
$0A, $8A and following byte having bit6 set and bit 7 zero (e.g. $43)
$05, $45, $85, $C5 and following byte with bit 6 & 7 zero and bit 5 set (e.g. $21)
now that sync creates a half bit shift in the following data, and the controller now reads
clock bits as data bits.
This is great on track 41 ($29)
the adress mark looks like this
A1 A1 A1 FE 29 00 01 02 ....
and read track reads
14 A1 A1 FE 14 7F FE 7C ...

but why does it read $29 with preceding 0 bit as sync?
well it's a BUG !
in MFM it looks like this

Code: Select all

1010010001001001
 0 0 1 0 1 0 0 1    = $29
1 1 0 0 0 0 1 0     = $C2

so the controller confuses data and clock bytes, sees a $C2 and syncs on that
result, it shifts everything by a half bit


Georges

User avatar
Steem Authors
Steem Developer
Steem Developer
Posts: 540
Joined: Tue Apr 30, 2002 10:34 pm
Location: UK
Contact:

Postby Steem Authors » Wed Dec 10, 2003 11:45 pm

Hi Gunstick,

Thanks a lot for the info about write protect and read track corruption, hopefully I'll be able to knock up some sort of fake corruption for the next version of Steem.

As far as write protect goes, I'm not 100% sure but I think that there is always some sort of change in the write protect bit when a disk is inserted, TOS really relys on it in order to detect media change. It might be that when a disk is half-inserted in the drive it reads as read-write, but this is something I must check.

Anyway, media change seems to work so I'm not overly concerned with it. What is confusing me is that after the FDC performs a read sector command the write protect bit is always clear, even on a write protected disk. I really need to know how long it stays clear and what can return it to its correct state, is there anything in the book about that?

Cheers,
Russ

User avatar
Steem Authors
Steem Developer
Steem Developer
Posts: 540
Joined: Tue Apr 30, 2002 10:34 pm
Location: UK
Contact:

Postby Steem Authors » Wed Dec 10, 2003 11:46 pm

Hi Simon,

I'm having to optionally do that for my SAM Coupé disk images, as there is one title that stores protection data in the inter-sector gaps! What stopped you storing it in the STT files?

Actually all the code is in Steem's disk imager to put the result of read track in the STT files, and the code is in Steem to read it. Unfortunately I couldn't find any programs that were fixed by including the data, lots of them did read track, got what they would on the ST, and then crashed anyway. I thought it wasn't really worth adding an option to treble the size of the images when it didn't improve anything! :)

I'm 95% sure it's possible to emulate, but it does rely on having the correct raw track information to feed through the algorithm, so you'd probably have to read it with an Amiga/CatWeasel.

Ouch, that is a bit tricky, I don't have any way of making those images. It might be best for Steem to leave this until we can include CAPS images, unfortunately that requires a complete rewrite of the FDC, so it might be a while.

For my own emulation I return stored track data where available, and am planning to fake the corruption in other cases (assuming normal gap information). I've not coded it yet, as I need to check on some of the notes I made last year.

Yes I think that is the best option for Steem too, it doesn't even have to be that accurate really. Any ST programs that take any more than a glance at the results of read track on a normal disk image will figure out it is fake, fortunately most only glance. :)

Thanks again,
Russ

Gunstick
Captain Atari
Captain Atari
Posts: 258
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Thu Dec 11, 2003 10:51 pm

Steem Authors wrote:Hi Gunstick,

As far as write protect goes, I'm not 100% sure but I think that there is always some sort of change in the write protect bit when a disk is inserted, TOS really relys on it in order to detect media change. It might be that when a disk is half-inserted in the drive it reads as read-write, but this is something I must check.


No, the write protect works as I described. The book has another long section about how TOS recreates from one write protect signal again the mediachange and writeprotect status.

What the book says is the only WP problem is when swapping between protected disks. There will be no mediachange in that case. Why is that? Because the drive detects the button-push and puts the WP to low.

For the rest, TOS takes care (more or less successful) In old rom from $FC19B0 and blitterTOS at $FC1BC4 is the flopvbl routine doing it's tricks.
Every 8th VBL it checks the WP signal from the drive. With 2 drives at 50Hz that makes 2*8*1/50=0.32 sec delay.
The status are put in undocumentd variables they call wpstatus0, wpstatus1, wplatch0 and wplatch1
stored from $9B2 (old TOS) $9F8 (blitterTOS) on

wpstatus contains FF if the drive is protected
wplatch contains FF is during one scan period the WP was on

the bios MEDIACH call now does this:
if the time since last floppy access is >= 1.5 seconds AND if during that time the WP was at least once activated, THEN the change status is 1, in all other cases it's 0
From TOS 1.4 on that time is 1.15 seconds

Now if MEDIACH says there's a possible change, the BIOS reads the bootsector serial number to make shure. If they are the same, no disk change is assumed.

That explains some of my experiences with the ST. I apparently was able to change diskettes in less than 1.5 seconds! And the other problem with the serial number did make me some data corruption.

Georges

User avatar
Steem Authors
Steem Developer
Steem Developer
Posts: 540
Joined: Tue Apr 30, 2002 10:34 pm
Location: UK
Contact:

Postby Steem Authors » Mon Dec 15, 2003 8:03 pm

Hi Georges,

Thanks for the info, that's very interesting stuff. I have had problems with media change detection on my ST too, but I never thought it was so flakey. Steem actually just hacks this up by switching the write protect bit on and off after a disk is inserted, so that is why I never looked into it very much.

So TOS definitely expects the write protect bit to be up to date all the time, I wonder how long the FDC leaves it off after a read sector? I will write a test program sometime soon to find out, but this might not clear things up completely as it may be that the bit can be changed back to the real state in some way I haven't thought of.

Thanks again,
Russ


Social Media

     

Return to “Steem”

Who is online

Users browsing this forum: No registered users and 1 guest