Ways how SW testing copy protection

A forum about Atari protected floppy disks analysis, preservation, emulation, tools

Moderators: DrCoolZic, Brume

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: Ways how SW testing copy protection

Postby IFW » Wed Feb 26, 2014 7:10 pm

I have a hunch, that it is actually FM data written, but read in MFM mode for your experiments... Those patterns in CTA very much look like that.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2928
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Ways how SW testing copy protection

Postby AtariZoll » Wed Feb 26, 2014 7:12 pm

All this is nice (or better said pretty messy :D ) . But there is strange track read content of Ijor STX, as is visible on memory content screenshot. Additionally, it crashes (Steem, Pasti, and not game) when put there some normal track content . So, I tend somehow to think that there are some hacks for this specific title. version.
Considering empty tracks in images: it all depends from multiple factors. If SW tests those tracks then should not find there sectors and usual track content. So, in case of conversion to STX it depends on what Pasti will supply to disk commands. I guess that it is ready for it, since public images hold usually not formatted tracks over 80 .
There is way to stop global warming.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Wed Feb 26, 2014 8:08 pm

What is interesting is that without sync reading gives usually somewhat unpredictable results. But this kind of pattern seems to "auto synchronize" or at least give results in 00 55 AA FF range ;)
The fact that the track is read 10 times indicates that some unpredictability is expected. To handle this correctly it would be necessary to compare several read track (for images several revolution) and detect some kind of fuzzy bytes similar to what is done in Power Drift (but quite differently).

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1984
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Ways how SW testing copy protection

Postby Steven Seagal » Wed Feb 26, 2014 8:39 pm

AtariZoll wrote:Well, it reads actually track 78 and not 0 . Pasti status gives false info in this case from some reason - there stays track 0 when giving track read command .


Looked at it, it's not wrong, Pasti gives the right register TR value, which is different from the head position.
The program seeks, changes TR, reads, it's all legit:

Code: Select all

Pasti: Restore drive 0
FDC DR 78
FDC HBL 133732 CR $13 drive A side 0 TR 0 SR 18 DR 78
FDC IRQ HBL 137389 CR 13 STR E0 ( MO WP SU ) TR 78 SR 18 DR 78 ($4E) A0: T 78/0 DMA CR 80 $738B0 SR 3 #19 PC 5EEE
FDC TR 0
FDC HBL 137491 CR $E0 drive A side 0 TR 0 SR 18 DR 78
Pasti: Read track. track: 78, side: 0
FDC IRQ HBL 142707 CR E0 STR 84 ( MO LD ) TR 0 SR 18 DR 0 ($0) A0: T 78/0 DMA CR 80 $738B0 SR 3 #19 PC 5EF6
FDC HBL 142708 CR $ 3 drive A side 0 TR 0 SR 18 DR 0
Pasti: Restore drive 0

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Wed Feb 26, 2014 9:59 pm

Thanks Steven.
If I read correctly the status is 84 that sounds resonable

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2928
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Ways how SW testing copy protection

Postby AtariZoll » Thu Feb 27, 2014 10:42 am

I just used Browsers, Pasti Status - as did many times before.

Anyway, here is something what should make things more clear:
I made short test proggy, which reads track 78 20 times in row, and saves result in file. Only 256 first bytes of each track read are saved.
Here is src, so can do modifications easy:

Code: Select all


* Floppy track read proggy

* Define track and number of passes here :

track       equ   78
passes      equ   20


*Hardware registers:

gpip equ  $fffffa01

dmal    equ $ffff860d
dmam equ $ffff860b
dmah   equ $ffff8609

fdcc    equ $ffff8604
dmac  equ $ffff8606

flock   equ  $43E



begin

   pea   insfft(pc)
   move.w  #9,-(sp)
   trap   #1
   addq.l  #6,sp

   move.w  #7,-(sp)
   trap  #1
   addq.l  #2,sp


* Go supervisor :

   clr.l  -(sp)
   move.w  #32,-(sp)
   trap  #1
   addq.l  #6,sp



  bsr   readprep


* Store current track :


  move.w #$82,(a2)  *Track register
  bsr delay

  move.w  (a3),curTr   * Current track


  move.w #$86,(a2)  *Data register
  bsr delay

  move.w  #track,(a3) *Track No
  bsr delay
  bsr comand
  move.w #$13,(a3)  *Seek command, steprate 3ms
  bsr comexd 
  tst.b   d0
  bne    error

  lea   oubuf(pc),a6
  move.w  #passes,d6


mloop

*  Set DMA address :
   move.l   a6,d0

  move.b d0,dmal.w
  lsr.w #8,d0
  move.b d0,dmam.w
  swap d0
  move.b d0,dmah.w
 
  move.w #$84,(a2)
  bsr delay
  move.w  d3,(a3)
  bsr delay

  move.w #$90,(a2)
  move.w #$190,(a2)
  move.w #$90,(a2)
  bsr delay
  move.w #13,(a3)  *Block number=13 for track read
  bsr comand


  move.w #$E0,(a3)  * Read track command
  bsr delay
  bsr comexd
  tst.b   d0
  bne   error

  lea  256(a6),a6
  subq.w  #1,d6
  bne   mloop

* Finished, need to save to current DIR, drive :

  bsr   deselFlo


* If run from floppy need to insert save floppy :

   pea   inssavt(pc)
   move.w  #9,-(sp)
   trap   #1
   addq.l  #6,sp

   move.w  #7,-(sp)
   trap  #1
   addq.l  #2,sp


* Current drive ? :

   move.w   #25,-(sp)
   trap  #1
   addq.l  #2,sp

   tst.b   d0
   bne.s   notA


*Force media change for A :

  clr.w -(sp)
  pea fakofn(pc)
  move.w #61,-(sp)
  trap #1
  addq.l #8,sp


notA
   
   clr.w   -(a7)
   pea   savnam(pc)
   move.w   #$3C,-(a7)
   trap   #1
   addq.l   #8,a7
   move.w   d0,d7
   bmi   error
      
   pea   oubuf(pc)
   pea   passes*256
   move.w   d7,-(a7)
   move.w   #$40,-(a7)
   trap   #1
   lea   12(sp),sp

   move.w   d7,-(a7)
   move.w   #$3E,-(a7)
   trap   #1
   addq.l   #4,a7

toExit
   clr.w   -(sp)
   trap   #1

* Finished


error   
   pea   errort(pc)
   move.w  #9,-(sp)
   trap   #1
   addq.l  #6,sp

   move.w  #7,-(sp)
   trap  #1
   addq.l  #2,sp

   bra.s   toExit



readprep   
 
  st   flock.w
  movea.w #$8800,a2
  move.b #14,(a2)


  move.b  (a2),d7
  bclr  #1,d7
  move.b  d7,2(a2)

* Prepare registers for DMA, FDC access
  lea dmac.w,a2  *DMA mode register
  lea fdcc.w,a3  *FDC register(s)
  rts



comand move.w #$80,(a2)

delay move.l d7,-(sp)
  moveq #12,d7
dll  dbf d7,dll
  move.l (sp)+,d7
  rts


comexd 
  move.l #1300000,d0 *  for time-out
cfort  btst #5,gpip.w
  beq.s cef
  subq.l #1,d0
  bne.s cfort
 
  move.w #$fe,d0 *Drive not ready-usually means-no disk in drive
  rts

cef  move.w #$180,(a2)  *Read status   
  moveq  #0,d0
  rts     


deselFlo    * deselecting floppy after finished
* by watching motor on in status

  lea dmac.w,a2  *DMA mode register
  lea fdcc.w,a3  *FDC register(s)


  move.w #$86,(a2)  *Data register
  bsr delay

  move.w  curTr(pc),(a3) * Back to track where was
  bsr delay
  bsr comand
  move.w #$13,(a3)  *Seek command, steprate 3ms
  bsr comexd 


readFloS   nop
  move.w #$180,(a2)  *Read status     12T
  bsr   delay
  move.w (a3),d0     *    8T

  btst   #7,d0
  bne.s   readFlos
 
  movea.w #$8800,a2
  move.b #14,(a2)

  move.b  (a2),d7
  bset  #1,d7
  move.b  d7,2(a2)

  sf   flock.w
  rts


curTr    dc.w   0

insfft   dc.b  13,10,"Insert floppy for testing, and press any key",0

inssavt    dc.b  13,10,"Insert floppy for saving, and press any key",0

errort   dc.b   13,10,"Error happened",0

savnam   dc.b  "TREADS.BIN",0


fakofn dc.b "A:\\N",0
   

   even

   section   bss

oubuf    ds.b 50000




Can run from floppy - then need to replace disks according to messages. Or from hard disk/card - then no need for juggling :D
So, who has Barbarian Psygnosis , please run this proggy and post saved file TREADS.BIN here .

I did run it in Steem Debugger with barbarian STX and now the surprise: Pasti supports fuzzyness of track start without sync.
From every track read, only first 256 byte is saved:

BarbTreads.png


And if run it with some standard floppy, will see similar fuzziness, only that will not have 0-s or $FFs, but $72, $84, $09 ... at track start.

SW:
TREADT1.ZIP
You do not have the required permissions to view the files attached to this post.
There is way to stop global warming.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Ways how SW testing copy protection

Postby npomarede » Thu Feb 27, 2014 12:42 pm

AtariZoll wrote:I did run it in Steem Debugger with barbarian STX and now the surprise: Pasti supports fuzzyness of track start without sync.
And if run it with some standard floppy, will see similar fuzziness, only that will not have 0-s or $FFs, but $72, $84, $09 ... at track start.


Maybe pasti.ddl is using the optional "sync" field before the track image to emulate this behaviour ? Because apart from that, I don't see the usefulness of this "sync" value, as you can as well inspect the track buffer yourself and see at what position the 1st 0xA1 appears.
At least, I don't use this value so far in my STX support in Hatari and I didn't encounter any STX file that wouldn't work.
One would need to disassemble pasti.dll to see how it works, but I don't like x86 asm, I prefer 68000 :)

Nicolas

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Thu Feb 27, 2014 1:44 pm

Peter I am glad you pointed that out.
I now remember that I already noticed this some time ago when playing with my Panzer program (viewtopic.php?f=94&t=25114&hilit=panzer&start=25#p237762 viewtopic.php?f=94&t=25114&hilit=panzer&start=25#p237714)
If you read on a real Atari the track often starts with 4e or 90 and I was surprise that Pasti was giving this info even when no track was pastified.
So I have looked again on what is provided by Pasti using Panzer 0.22

Lets take barbarian d1 as an example. Track 00.0 is not imaged so when you try to do a read track you get a message that tells you you are trying to read track without track info but Pasti will create perfect information for you
First time you read you get the normal gap $4e followed by sync, id, gap, data ...
read-no-track-1.PNG

But second time you get $90 in the gap followed by sync, id, gap, data
read-no-track-2.PNG

This is the exact behavior on a real Atari (except than rather than 1 over two it is random).
This is usually not very useful and can probably be ignored in most cases.
However if you know read track 78 you get
read-track-78-1.PNG

If you read a second time you get
read-track-78-2.PNG

Bytes have been changed and this changed value continue for the first 512 bytes.

And this is very smart for protection that check the value of bytes before the first sync ;)

What is not clear is how the value are converted from 1 read to second read. It seems pretty obvious for 00 to ff but less obvious fro 4e to 90 and even less obvious if you take other values.
I suspect that the bytes must be converted to MFM bytes and shifted left or right but I need to check ...
Of course the change of the value only happen before the first sync ... otherwise the read track would return false value one time over two.

So why it does not work for Power drift ...
Bad luck :( the byte change happen until the first sync and in power drift the change is between two sets of sync ...

I have just received another game called Falcon that probably uses a similar protection ... look at this thread for more info on Falcon viewtopic.php?f=95&t=26161&p=247974#p247979

Based on this information I definitively need to fix Aufit to handle this problem ...
You do not have the required permissions to view the files attached to this post.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2928
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Ways how SW testing copy protection

Postby AtariZoll » Thu Feb 27, 2014 1:47 pm

npomarede wrote:..
Maybe pasti.ddl is using the optional "sync" field before the track image to emulate this behaviour ? Because apart from that, I don't see the usefulness of this "sync" value, as you can as well inspect the track buffer yourself and see at what position the 1st 0xA1 appears.
At least, I don't use this value so far in my STX support in Hatari and I didn't encounter any STX file that wouldn't work.
One would need to disassemble pasti.dll to see how it works, but I don't like x86 asm, I prefer 68000 :)
Nicolas


I don't think that it uses any optional sync. It just tries to emulate real thing - that when starting track read you will jump in middle of flux stream, so in middle of some byte, and even phase is random - therefore data may be 0 or $FF ( all bits mutually inverted). It is simple case. If there is some different value, then it may be shifted by some bits, + inverted, as is visible when dump some standard track.
Ah, and here lies answer why $FFs at track end - because index position varies in both directions.
What would be good is to make Pasti image with public Pasti tool of Barbarian Psyg. , floppy 1, to see will there be 'fuzzyness' .
DrCoolZic: have you Atari for that ?
I'm not sure that $A1 is only what can be used for syncing - our experts DrCoolZic , JimDrew and IFW could say more about ...
There is way to stop global warming.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Thu Feb 27, 2014 1:52 pm

AtariZoll wrote:I'm not sure that $A1 is only what can be used for syncing - our experts DrCoolZic , JimDrew and IFW could say more about ...

WD1772 sync with 4489 (A1) or 5224 (C2)
But I have never seen C2 used on purpose for sync (but found a lot by accident).

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2928
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Ways how SW testing copy protection

Postby AtariZoll » Thu Feb 27, 2014 1:55 pm

DrCoolZic wrote:...
If you read on a real Atari the track often starts with 4e or 90 and I was surprise that Pasti was giving this info even when no track was pastified.
So I have looked again on what is provided by Pasti using Panzer 0.22
...
So why it does not work for Power drift ...
Bad luck :( the byte change happen until the first sync and in power drift the change is between two sets of sync ...


Even Steem generates standard track content when ST or MSA image is 'inserted' - as I showed few posts earlier. But it gives same pattern all time.
In case of Power Drift we have real fuzzy content, because it is after sync .
There is way to stop global warming.

User avatar
npomarede
Atari God
Atari God
Posts: 1178
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Ways how SW testing copy protection

Postby npomarede » Thu Feb 27, 2014 1:59 pm

DrCoolZic wrote:
AtariZoll wrote:I'm not sure that $A1 is only what can be used for syncing - our experts DrCoolZic , JimDrew and IFW could say more about ...

WD1772 sync with 4489 (A1) or 5224 (C1)
But I have never seen C1 used on purpose for sync (but found a lot by accident).

I think you made a typo, the other sync 5224 is C2, not C1

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Thu Feb 27, 2014 2:27 pm

npomarede wrote:I think you made a typo, the other sync 5224 is C2, not C1

Yes thanks

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Thu Feb 27, 2014 3:00 pm

DrCoolZic wrote:I suspect that the bytes must be converted to MFM bytes and shifted left or right but I need to check ...

Confirmed. Some examples:

4E = 9254 in MFM Shifted right gives 492A = 90
00 = AAAA in MFM shifted right gives 5555 = FF

other interesting sequence
8888 = 00 ===> 4444 = AA ====> 2222 = 00 ====> 1111 = 55 ====> 8888 = 00
so 00 may become AA that may become 00 that may become 55 that may become 00 each time shifted

IFW
Captain Atari
Captain Atari
Posts: 181
Joined: Fri Jul 22, 2011 4:53 pm

Re: Ways how SW testing copy protection

Postby IFW » Thu Feb 27, 2014 5:03 pm

Yes, WD only syncs on 4489 or 5224. Scan the track to see any, 1 should be enough of either...

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Wed Jun 04, 2014 4:18 pm

For information new release V1.2 of my document "Atari Floppy Disk Copy Protection". Hopefully contains a lot of information about copy protections used on Atari platform
This is a major rewrite that can be found at viewtopic.php?f=95&t=21952&p=253989#p253989

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Ways how SW testing copy protection

Postby Dio » Wed Jun 04, 2014 5:57 pm

DrCoolZic wrote:other interesting sequence
8888 = 00 ===> 4444 = AA ====> 2222 = 00 ====> 1111 = 55 ====> 8888 = 00
so 00 may become AA that may become 00 that may become 55 that may become 00 each time shifted

Note that the 8888 / 2222 encodings for 00 aren't typical, they have missing clock pulses from the expected pattern. 00 is encoded as 0101... and therefore its MFM conjugate from the inserted clock pulses is always FF. However, AA and 55 will be encoded as 4444 and 8888.

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1984
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: Ways how SW testing copy protection

Postby Steven Seagal » Wed Jun 04, 2014 7:59 pm

DrCoolZic wrote:WD1772 sync with 4489 (A1) or 5224 (C2)
But I have never seen C2 used on purpose for sync (but found a lot by accident).


I think I saw one in Platoon.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Wed Jun 04, 2014 9:10 pm

Steven Seagal wrote:
DrCoolZic wrote:WD1772 sync with 4489 (A1) or 5224 (C2)
But I have never seen C2 used on purpose for sync (but found a lot by accident).


I think I saw one in Platoon.

Thanks. interesting
Anyone has Kryoflux or SCP image?

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Sun Nov 02, 2014 5:40 pm

@AtariZoll

Is it possible for you to see how the Colorado game checks the protection (I am personally unable to do that :( )

I do not think that the explanation given by Markus is correct http://www.sarnau.info/atari:protection_colorado

Reference viewtopic.php?f=102&t=25854&hilit=list+of+difficult&start=200#p247350
First the game uses the Macrodos/speedlock protection I would be curious to understand how this protection is checked?
My guess is that the sector is split in 4 segment and timing of these 4 segment is measured but this is just a guess.

Second thing which is not mentioned in the above reference is the presence of a weird ID segment at the end of the track 01
this segment is very close to the last sector and contains the following values all in hexadecimal:
00 00 00 00 00 00 00 00 A1 A1 A1 A1 A1 A1 A1 A1 FF 0E A4 96 A4 02 01 ....

the read address command should be able to read this segment as an ID for a sector 150 (but no data following) with all sort of invalid values in it (Non standard IDAM, Invalid track number, Invalid sector length, and Invalid ID CRC).
Is this field also checked as part of the protection?
Are values in this ID used for something?

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Sun Nov 02, 2014 5:58 pm

I just checked I have another FD of colorado. It also contains this last ID close to the end of track 01.0 with a content slightly different
00 00 00 00 00 00 00 00 A1 A1 A1 A1 A1 A1 A1 FF 02 00 08 12 A0 80 ....

Same strange sequence of 4 A1 followed by 3 A1 followed by FF ....

When I say A1 this is in fact the A1 sync mark with missing clock i.e. 0x4489 :)

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2928
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Ways how SW testing copy protection

Postby AtariZoll » Mon Nov 03, 2014 10:49 am

It seems that there are at least 3 versions of Colorado . STX image at AM is Action 16 release, and it has more-less usual Silmarils protection - lot of sector IDs on track 79 .
I DL-ed 7z archive with SCP and STX - what is converted from SCP. I guess. It has track load of trk. #1 . Will look for actual check code little later .
What Markus described must be some other release.
There is way to stop global warming.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Mon Nov 03, 2014 12:11 pm

Never heard of Colorado with track 79 having large number of sector on track 79?
attached is stx files of my two version of Colorado (not tested but should be ok)
colorado.rar
You do not have the required permissions to view the files attached to this post.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2928
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Ways how SW testing copy protection

Postby AtariZoll » Mon Nov 03, 2014 2:14 pm

DrCoolZic wrote:Never heard of Colorado with track 79 having large number of sector on track 79?
attached is stx files of my two version of Colorado (not tested but should be ok)
colorado.rar


That type of protection - lot of sector IDs on 1 track was used by many French releases. Don't know about some name used for .
Both versions you posted are almost same. There are 2 little different files .

Despite using track #1 read and some checks of data, it is ineffective, as passes with regularly formatted floppy too. Real protection is sector 1 on track 1, and yes, it uses measuring of sector segment reading times with help of Timer A and DMA address pointers. It measures time of 32 segments in order, what is actually max value, since DMA transfers min 16 sectors at once. There must be different loading times - range of results is $254-$280 to pass copy protection check (code is encrypted of course).
There is way to stop global warming.

User avatar
DrCoolZic
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2144
Joined: Mon Oct 03, 2005 7:03 pm
Location: France
Contact:

Re: Ways how SW testing copy protection

Postby DrCoolZic » Mon Nov 03, 2014 4:00 pm

Perfect this what I was expectingfor checking of Macrodos / speedlock protection.
But did yuo found code to check that track 1 has an extra sector without data (ID segment without DATA segment) with weir content.
This can probably be done by using read address command (even though we have 7 sync sequence instead of 3) or by doing a read track and looking for 7 A1 followed by FF


Social Media

     

Return to “Floppy Disk Preservation”

Who is online

Users browsing this forum: No registered users and 2 guests