WD1772 Programming

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

Moderators: DrCoolZic, Brume

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

WD1772 Programming

Postby DrCoolZic » Wed Jan 28, 2015 1:34 pm

I am reworking some parts of Panzer that did not work very well.

Does any one has a good "algorithm" to find all addresses of a track ... of course using read address ...

normally read address only read the first address field it finds on the track after receiving the command.
As I want to start with the first address field after the index pulse, I first wait for the index pulse in the status register. If the FDC is idle you can find this information in bit S1 of the status register.
No I want to read all address field sector until the next index pulse. I thought of still checking the IP in the satus register but of course this is wrong because we are now executing read address commands in a loop.
So the best solution I have found is to loop reading address for the next 200 ms. On my test I am always(?) getting an extra address that I can remove easily but I do not like the solution.

The code look like this

Code: Select all

   /* wait for index pulse in status */
   *count = 0;
   stime = _hz_200;
   while ((time = (_hz_200 - stime) * 5) <  2000)
      if (fdc_get_reg(FDC_CMDS) & FDC_IP) break;
   if (time < 2000) {
      /* we read all addresses until next index pulse */
      stime = _hz_200;
      do {
         itime = _hz_200;
         fdc_set_reg(FDC_CMDS, command);         /* send read address command */
         while ((time = (_hz_200 - itime) * 5) < 2000) {
            if (mfp_fdc_int()) break;
         }
         *status = fdc_get_status(READ_MODE);   /* store FDC status */
         if (*status++ & 0x10) break;         /* if RNF we break */
         if (time >= 2000) break;            /* break on timeout */
         (*count)++;
      } while ((_hz_200 - stime) < 40);
   }   /* no timeout */


_hz_200 is the Atari real time clock. Of course some extra read are added after to pass the DMA 16bytes boundary ...
To get rid of the extra address I compare the sect num and if same I remove but does not seems very reliable
So any idea is welcome.

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

Re: WD1772 Programming

Postby AtariZoll » Wed Jan 28, 2015 8:44 pm

In my old trackcopy program I used similar method . There is watching of IP, and after that starting to read sector address fields. Timer C was used to abort operation after 0.2 secs, better said after 41 cycles of it.
I see now 2 ways how to improve it: must disable all interrupts while checks IP, otherwise sometimes may miss it, or will be too much delay if it occurs in middle of Vblank service routine.
Even better would be to activate one timer after detected index pulse. set to 0.196 sec or close to it, so SW will start reading little before index pulse. therefore certainly will not miss if it is very close to index - WD1772 can catch it faster. I'm sure.
So, basically by not using only system timer, but for instance Timer A for start, and little changed Timer C, we can get better results. Vblank should be disabled during whole test, while Timer C should be changed, and doing only count, nothing more, for fastest possible response.

I will do code in this way in ASM, and compare accuracy with old method. In week-two .
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

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

Re: WD1772 Programming

Postby npomarede » Wed Jan 28, 2015 10:08 pm

Hi
I also thought about this, and after testing a lot of combinations some times ago to measure timings in update of the FDC's status reg, I think I have a new method that could work.

We know that if the FDC is not busy and we send a force int ($d0) command then the status register will show the same bits as a type I command, so we can read track0, motor, index pulse, ...

From what I measured on my STF, it takes at max 100 cpu cycles between sending the $D0 command and seing the update in the status register.
We also know that it takes approximatively 256 cpu cycles to transfer one byte from the FDC to the DMA.

So, I think that we can have the following program :
- set nb_addresses_read=0
- wait for IP to have the start of the track
- repeat loop :
- send read address
- increase nb_addresses_read variable
- wait for busy bit to be cleared
- send force int $D0 command
- wait for approx 100 cpu cycles (could be 200 to be safe)
- read status register. If IP is set, exit repeat loop
- end repeat

then do 3 more "read address" to be sure to flush the DMA FIFO.

So, instead of having a loop with only some "read address", we add some "force int" to be able to read the IP bit.
I didn't check this on my STF, but I think it could work, it would need to be tested.

The limitation is that if you have 2 consecutive addresses on the track, you might miss the 2nd one because you won't have enough time to send the "read address" command fast enough, but I'm not sure there're some cases like this.

Nicolas

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

Re: WD1772 Programming

Postby DrCoolZic » Thu Jan 29, 2015 9:16 am

Both idea are good
I was about to combine them but actually whatever we do there will be no guarantee that we will get the first one. Looking with KF/Aufit I have some extreme test cases where we have one or two sync at end of track and the rest of the address field after the index pulse. In some other test case the sync & id field are located right after the ip. This is the bad news but the good news is that program checking this wont be able to do better?
The only thing important is to make sure we get all the IDs.
I am going to implement Nicolas idea. But not sure how to wait for 100 cpu cycles in C (probably a very short loop like

Code: Select all

i = 5 /* need to find the right number */
while (i--);


One more thing for Nicolas. While testing on Hatari. I have created a blank disk with 80 tracks (0-79?) and I test read address on track 80 and I found some data? Actually if I do a read track I find some data???
This does not happen on Steem

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

Re: WD1772 Programming

Postby DrCoolZic » Thu Jan 29, 2015 9:25 am

Next question how do we find out that there is a disk inserted in the drive?
This sound easy but it is not :(

Originally I was using a seek verify. So if a "normal" disk is inserted the FDC after a seek then read an address and verify that the track value in the address field matches the track specified in the seek.
But on "strange" or more important on unformatted disks it does not work?

So I tried to use IP. I thought that If disk inserted I should get IP if no disk I should get no IP? Well unfortunately this is not true. Disk inserted or not the drive send IP back at normal speed of the motor.
By the way this indicate that contrary to 5" drive the IP detector is on the "drive motor mechanism" and not a "mark" on the Floppy.

I may also use read address and check for RNF but again this would only work if disk has at least one id field???

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

Re: WD1772 Programming

Postby npomarede » Thu Jan 29, 2015 9:33 am

DrCoolZic wrote:Both idea are good
I was about to combine them but actually whatever we do there will be no guarantee that we will get the first one. Looking with KF/Aufit I have some extreme test cases where we have one or two sync at end of track and the rest of the address field after the index pulse. In some other test case the sync & id field are located right after the ip. This is the bad news but the good news is that program checking this wont be able to do better?
The only thing important is to make sure we get all the IDs.
I am going to implement Nicolas idea. But not sure how to wait for 100 cpu cycles in C (probably a very short loop like

Code: Select all

i = 5 /* need to find the right number */
while (i--);


I don't think you can do this in C directly, you don't know how the while loop will be assembled.
Easiest way would be to include some asm code in your C source with 30 NOP for example (120 cycles). Check the doc of your C compiler to do that.
As for the case where the address field overlaps the IP, you can indeed not read the 1st one, but after one revolution, you can read all the addresses again to get 2 revolutions of data by storing the state of IP with each address field.
It should then be possible to get a correct list and to detect overlaps.
One more thing for Nicolas. While testing on Hatari. I have created a blank disk with 80 tracks (0-79?) and I test read address on track 80 and I found some data? Actually if I do a read track I find some data???
This does not happen on Steem

Hatari doesn't create blank/unformatted disks, it always create .ST disks, so you will always have sectors and data on them.
If you really want to check an empty track, you can try to image an unformatted disk using pasti and use this STX file with Hatari.

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

Re: WD1772 Programming

Postby AtariZoll » Thu Jan 29, 2015 9:36 am

DrCoolZic wrote:Both idea are good
I was about to combine them but actually whatever we do there will be no guarantee that we will get the first one. Looking with KF/Aufit I have some extreme test cases where we have one or two sync at end of track and the rest of the address field after the index pulse. In some other test case the sync & id field are located right after the ip. This is the bad news but the good news is that program checking this wont be able to do better?
...

This is why I propose to use timer after index, then wait little less than one rotation time, and then start scanning for ... So, this will catch those extreme cases, and cases where it is very close to index.
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

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

Re: WD1772 Programming

Postby npomarede » Thu Jan 29, 2015 9:48 am

DrCoolZic wrote:Next question how do we find out that there is a disk inserted in the drive?
This sound easy but it is not :(

Originally I was using a seek verify. So if a "normal" disk is inserted the FDC after a seek then read an address and verify that the track value in the address field matches the track specified in the seek.
But on "strange" or more important on unformatted disks it does not work?

So I tried to use IP. I thought that If disk inserted I should get IP if no disk I should get no IP? Well unfortunately this is not true. Disk inserted or not the drive send IP back at normal speed of the motor.
By the way this indicate that contrary to 5" drive the IP detector is on the "drive motor mechanism" and not a "mark" on the Floppy.

I may also use read address and check for RNF but again this would only work if disk has at least one id field???

Simple answer : it's broken.
Unfortunatelly, the ST doesn't report the "disk inserted" signal present on other drive/computer, so you need to find an alternative solution.
I also tested this extensively on my STF, you won't get any IP signal unless a disk is inserted.
So you can do a read track on any track and see if the command completes. It doesn't matter what content you get, what matters is that the command completes by itself.

But you need to take into account that if you do a "read track" and there's no disk, then the command will never complete, drive wil keep spinning for hours, so you need to handle a timeout yourself.
So you could do :
- send read track
- if command completes, a disk is inserted
- after 2 seconds, if command didn't complete, send a force interrupt, it means there's no disk in drive.

As you say, read address would only work with formatted disk, so it's not good. Read track will work with unformatted tracks too.
Same for seek + verify, it would only work with formatted disk and would not work with some protected disks where the address fields don't match the physical head position.

Nicolas

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

Re: WD1772 Programming

Postby DrCoolZic » Thu Jan 29, 2015 9:51 am

npomarede wrote:I don't think you can do this in C directly, you don't know how the while loop will be assembled.
Easiest way would be to include some asm code in your C source with 30 NOP for example (120 cycles). Check the doc of your C compiler to do that.

Pure C allows to see the asm generated so I might use this or there is also the capability to include ASM in the C code directly (need to remember how).

As for the case where the address field overlaps the IP, you can indeed not read the 1st one, but after one revolution, you can read all the addresses again to get 2 revolutions of data by storing the state of IP with each address field.
It should then be possible to get a correct list and to detect overlaps.

In my previous version of lib I was checking overlapping to detect correct number of IP (looking at sector number in id field). But even that is tricky because you have some games that uses the same ip twice and usually one at beginning and one at the end (night shift sector 66 at start and end). So in fact I was testing not one overlap but two. But this would break if 3 same sectors!!!

Hatari doesn't create blank/unformatted disks, it always create .ST disks, so you will always have sectors and data on them.
If you really want to check an empty track, you can try to image an unformatted disk using pasti and use this STX file with Hatari.

the .st file contains description for 80 tracks so if I ask for data on track 80 it should find that it is outside of .st range and return nothing for adress and sector and eventually random for track.
currently if you do a read track it return perfectly valid data? But I do not know wher from? may be wrap on track 0?
In Steem when you try to read past track described in .st the read address return RNF (did not try raed track)

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

Re: WD1772 Programming

Postby DrCoolZic » Thu Jan 29, 2015 9:56 am

AtariZoll wrote:
DrCoolZic wrote:Both idea are good
I was about to combine them but actually whatever we do there will be no guarantee that we will get the first one. Looking with KF/Aufit I have some extreme test cases where we have one or two sync at end of track and the rest of the address field after the index pulse. In some other test case the sync & id field are located right after the ip. This is the bad news but the good news is that program checking this wont be able to do better?
...

This is why I propose to use timer after index, then wait little less than one rotation time, and then start scanning for ... So, this will catch those extreme cases, and cases where it is very close to index.

As I said it is a good idea but you will never know with precision (and is it important) if the ID fields starts few bytes before or after the index pulse.
I said is it important because due to speed variation you may get an ID field before or after the index if located almost on top of IP

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

Re: WD1772 Programming

Postby DrCoolZic » Thu Jan 29, 2015 9:59 am

By the way while talking about sync over index pulse. Are you aware of the bug of the WD1770 where the FDC go crazy in this condition during read track :)
Your program should be ready to get over 10 000 bytes in a read track!!!
More on this in what you always wanted to know. Wonder if emulator like Hatari/Steem handle this?

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

Re: WD1772 Programming

Postby npomarede » Thu Jan 29, 2015 10:00 am

DrCoolZic wrote:
npomarede wrote:As for the case where the address field overlaps the IP, you can indeed not read the 1st one, but after one revolution, you can read all the addresses again to get 2 revolutions of data by storing the state of IP with each address field.
It should then be possible to get a correct list and to detect overlaps.

In my previous version of lib I was checking overlapping to detect correct number of IP (looking at sector number in id field). But even that is tricky because you have some games that uses the same ip twice and usually one at beginning and one at the end (night shift sector 66 at start and end). So in fact I was testing not one overlap but two. But this would break if 3 same sectors!!!

yes, but the difference here is that you would also have the value of the IP signal associated with each address field. So you should have only one case of overlap to solve : the one where IP goes from 0 to 1 when 2nd revolution starts.
Apart from that, you don't need to use the content of the address fields, doesn't matter if several id field have the same value.

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

Re: WD1772 Programming

Postby npomarede » Thu Jan 29, 2015 10:17 am

DrCoolZic wrote:the .st file contains description for 80 tracks so if I ask for data on track 80 it should find that it is outside of .st range and return nothing for adress and sector and eventually random for track.
currently if you do a read track it return perfectly valid data? But I do not know wher from? may be wrap on track 0?
In Steem when you try to read past track described in .st the read address return RNF (did not try raed track)

I confirm there's a small bug in Hatari. If you try to "read sector" after max track, you correctly get RNF, but it's not checked when doing "read address".
Hatari will also return a valid track when reading after max track, but it should return random bytes in that case too.
I will fix this for next Hatari version (note that it's correctly handled when using STX files)

Nicolas

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

Re: WD1772 Programming

Postby AtariZoll » Thu Jan 29, 2015 12:57 pm

DrCoolZic wrote:...
As I said it is a good idea but you will never know with precision (and is it important) if the ID fields starts few bytes before or after the index pulse.
I said is it important because due to speed variation you may get an ID field before or after the index if located almost on top of IP

Such cases are not reliable - different floppy drive will see it different - some may see start before IP , some after OP. And that's not because speed variation, but because small mechanic differences in mechanic - index pulse generating components.
I think that it is not possible to detect exact position relative to index pulse beyond some accuracy level in Atari ST, and with regular HW .

What copy protections may be so sensitive on this ?
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

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

Re: WD1772 Programming

Postby DrCoolZic » Thu Jan 29, 2015 1:17 pm

I did not succeed to make it work
I could not find correct timing after sending the force interrupt: either I miss the IP or I skip some IDs ...
So probably I will stick with my solution for now :?:

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

Re: WD1772 Programming

Postby DrCoolZic » Thu Jan 29, 2015 1:31 pm

npomarede wrote:But you need to take into account that if you do a "read track" and there's no disk, then the command will never complete, drive will keep spinning for hours, so you need to handle a timeout yourself.
So you could do :
- send read track
- if command completes, a disk is inserted
- after 2 seconds, if command didn't complete, send a force interrupt, it means there's no disk in drive.

Nicolas

Does not work for me on Atari STE with TOS 2.06 ?
Command terminates without problem with FDC status $80

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

Re: WD1772 Programming

Postby npomarede » Thu Jan 29, 2015 2:00 pm

DrCoolZic wrote:
npomarede wrote:But you need to take into account that if you do a "read track" and there's no disk, then the command will never complete, drive will keep spinning for hours, so you need to handle a timeout yourself.
So you could do :
- send read track
- if command completes, a disk is inserted
- after 2 seconds, if command didn't complete, send a force interrupt, it means there's no disk in drive.

Nicolas

Does not work for me on Atari STE with TOS 2.06 ?
Command terminates without problem with FDC status $80

You must have something else that runs in the background.
All my tests on STF were done with interrupts turned off (move 2700,sr).
Sending the read track E0 or E8 (with/without motor spinup) will never complete if there's no disk in drive (the bit 5 in fffa01 will not go back to 0 and busy bit in status reg remains to 1).
"Read track" wait for the IP signal to change, but IP signal will never change without a disk in drive, so "read track" will remain stuck.

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

Re: WD1772 Programming

Postby DrCoolZic » Thu Jan 29, 2015 2:08 pm

npomarede wrote:Unfortunatelly, the ST doesn't report the "disk inserted" signal present on other drive/computer, so you need to find an alternative solution.
I also tested this extensively on my STF, you won't get any IP signal unless a disk is inserted.
So you can do a read track on any track and see if the command completes. It doesn't matter what content you get, what matters is that the command completes by itself.
Nicolas


npomarede wrote:Sending the read track E0 or E8 (with/without motor spinup) will never complete if there's no disk in drive (the bit 5 in fffa01 will not go back to 0 and busy bit in status reg remains to 1).
"Read track" wait for the IP signal to change, but IP signal will never change without a disk in drive, so "read track" will remain stuck.


This is where we are not in agreement. On my machine I ALWAYS get an IP independently of disk inserted or not.
As I mentioned even without disk I am still getting IP with variable timing (motor variation). This differ from 5" drive that have IP based on small hole on the disk.
Just try with Panzer rotation time (measure time between IP) without floppy ...

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

Re: WD1772 Programming

Postby npomarede » Thu Jan 29, 2015 2:19 pm

DrCoolZic wrote:This is where we are not in agreement. On my machine I ALWAYS get an IP independently of disk inserted or not.
As I mentioned even without disk I am still getting IP with variable timing (motor variation). This differ from 5" drive that have IP based on small hole on the disk.
Just try with Panzer rotation time (measure time between IP) without floppy ...

Maybe you have a different drive model ? IIRC IFW or Hippy Dave also confirmed the IP signal was not generated unless a floppy was inserted.

If you switch ON your STE without any floppy, and wait for the GEM to appear after a while, does the led drive turned off after a moment or does it always stay on ?

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

Re: WD1772 Programming

Postby DrCoolZic » Thu Jan 29, 2015 2:44 pm

npomarede wrote:
DrCoolZic wrote:This is where we are not in agreement. On my machine I ALWAYS get an IP independently of disk inserted or not.
As I mentioned even without disk I am still getting IP with variable timing (motor variation). This differ from 5" drive that have IP based on small hole on the disk.
Just try with Panzer rotation time (measure time between IP) without floppy ...

Maybe you have a different drive model ? IIRC IFW or Hippy Dave also confirmed the IP signal was not generated unless a floppy was inserted.

If you switch ON your STE without any floppy, and wait for the GEM to appear after a while, does the led drive turned off after a moment or does it always stay on ?

Hum quite interesting.
This is also what I thought and this is why I tested FD presence by waiting fot time out on IP but it failed on ... my system with CosmosEx internal and a Cumana CSA354 external floppy drive (set as primary drive A using a "drive switch").

I tested on another STE with internal drive and yes no floppy no IP!!!

also tested by putting CosmosEx as primary drive and here I am also getting IP (wrong emul? - need to tell Jookie).

So this solve my problem. Just wait for IP in idle/interrupt mode and if time out no floppy
Will fail in some cases (like my external drive) but should work in most cases
Thanks

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

Re: WD1772 Programming

Postby IFW » Thu Jan 29, 2015 2:48 pm

npomarede wrote:
DrCoolZic wrote:This is where we are not in agreement. On my machine I ALWAYS get an IP independently of disk inserted or not.
As I mentioned even without disk I am still getting IP with variable timing (motor variation). This differ from 5" drive that have IP based on small hole on the disk.
Just try with Panzer rotation time (measure time between IP) without floppy ...

Maybe you have a different drive model ? IIRC IFW or Hippy Dave also confirmed the IP signal was not generated unless a floppy was inserted.

If you switch ON your STE without any floppy, and wait for the GEM to appear after a while, does the led drive turned off after a moment or does it always stay on ?


Yes, it was verified on my STF - also on several Amigas.
Possibly depends on the drive model though, like some other behavior as well, so just go with the common method which is no IP unless disk is inserted.

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

Re: WD1772 Programming

Postby npomarede » Thu Jan 29, 2015 2:52 pm

DrCoolZic wrote:Hum quite interesting.
This is also what I thought and this is why I tested FD presence by waiting fot time out on IP but it failed on ... my system with CosmosEx internal and a Cumana CSA354 external floppy drive (set as primary drive A using a "drive switch").

I tested on another STE with internal drive and yes no floppy no IP!!!

also tested by putting CosmosEx as primary drive and here I am also getting IP (wrong emul? - need to tell Jookie).

Not sure it really matters or causes problems, but in all accuracy, this should not send IP.
So this solve my problem. Just wait for IP in idle/interrupt mode and if time out no floppy
Will fail in some cases (like my external drive) but should work in most cases
Thanks

I also have an external drive that I can use as drive A using a switch, and I don't get any IP when there's no floppy. Yours might be different.
In all cases, this is also confirmed by the fact that TOS is unable to accurately tell if a disk is ejected or not. To do this, TOS tests for change in the WP bit, which can solve some cases, but not all of them.
If it was really possible to detect a disk is present in drive at 100% certainty, I'm quite sure it would be used in TOS, instead of the hack where it monitors WP bit on each VBL.

Nicolas

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

Re: WD1772 Programming

Postby DrCoolZic » Thu Jan 29, 2015 3:38 pm

I also know about this hack. But when you start the system how do you know if there is a FD or not. At this point you certainly cant detect change in WP :)

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

Re: WD1772 Programming

Postby DrCoolZic » Fri Jan 30, 2015 12:46 pm

Ok I finally found a read address "algorithm" that I like :)
I was looking at a way to find out about position of sector on track using a timer.

For the Data part of the sector it is possible to check when transfer of data through DMA start. In that case you get roughly the time of the start of the segment + 16 bytes
For the ID part we can measure time from index to read address complete. This gives roughly the time for the last bytes of the ID segment.

So I use
1 - init variables
2 - wait for IP
3 - start and reset timer A / set DMA ...
4 - send read address command
5 - wait completion
6 - measure timing (store info) & increase address count
7 - loop for over 200 ms (so we get all addr) to step 4
8 - read 3 extra to pass DMA
9 - post fix number of sectors by checking sector over 200 ms

I will probably need to adjust timing values.
I have checked on a real Atari with values computed with Aufit from RAW STX files of the FD ... and ... value are pretty close

I have tried Panzer with this new algo on both Steem and Hatari using a .stx file generated from KF raw file and result are not good?
to stop the loop I use the real time clock hz_200 and this seems not emulated correctly (or FDC?) on Steem I read 23 sectors instead of 9 and in Hatari 18 sectors.
Other problem is the the timing return by TIMER_A at completion of read address is wrong: either timer is not accurate of FDC is not accurate
For example for sector 9 on real Atari timing is around 160 ms on Steem I get 63 ms and on Hatari 80 ms ???

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

Re: WD1772 Programming

Postby npomarede » Fri Jan 30, 2015 1:02 pm

Hi

I'm pretty sure MFP timers are accurate under Steem and Hatari, else a lot of demos/games would not work at all.

How did you test on your Atari, with a cosmo ex or with a real drive + real floppy ? Are you sure the sector interleaving was kept the same as in the original STX file ?
Rob Northen protection (amongst others) relies on precise FDC timings and so far I saw none of them failed under Hatari, so unless you have more details, I would say the problem is on your side :)

Nicolas


Social Media

     

Return to “Floppy Disk Preservation”

Who is online

Users browsing this forum: No registered users and 1 guest