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:

Re: WD1772 Programming

Postby DrCoolZic » Fri Jan 30, 2015 1:18 pm

npomarede wrote: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

Test conditions:
    • Real Atari with internal real drive + CosmosEx but not the FD emulation used
    • format an empty diskette on Atari
    • test addresses with Panzer new version
    • image with KF
    • run Aufit 0.9 test timing same as on real Atari :)
    • Create an stx file of empty diskette
    • Run Panzer under Hatari and Steem mounting the stx file - bad timing :(

code in Panzer is

Code: Select all

      stime = _hz_200;
      *count = 0;
      thigh = tlow = 0;
      ctime = mfp_set_ctimer(TIMER_A, TIMER_PS10);   /* Start Timer A PS=10 */
      mfp_set_dtimer(TIMER_A, 0xFF);               /* reset to all one */
      do {
         itime = _hz_200;
         fdc_set_reg(FDC_CMDS, command);            /* send read address command */
         while ((time = (_hz_200 - itime) * 5) < 2000) {
            tlow = ~mfp_get_dtimer(TIMER_A);      /* read timer A */
            if (tlow < tlast) thigh++;            /* overflow inc */
            tlast = tlow;
            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 */
         timing_array[*count] = (thigh << 8) + tlow;   /* store timing */
         (*count)++;                           /* one more address */
      } while ((_hz_200 - stime) < 41);            /* wait a bit more than 200 ms */
      mfp_set_ctimer(TIMER_A, ctime);               /* restore timer */

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

Re: WD1772 Programming

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

What if you create the STX file on your ST using pasti.prg, without using KF+Aufit, and test it under Hatari/Steem ?

Also, apart from timings, when using panzer on ST/Hatari/Steem and you use the function to read all the ID fields of a track, do you get the same order in all 3 cases ? (it should be)

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 » Fri Jan 30, 2015 2:45 pm

npomarede wrote:What if you create the STX file on your ST using pasti.prg, without using KF+Aufit, and test it under Hatari/Steem ?

Did that (did not remember it was taking so much time to write stx file :))
Guess what seems like Aufit generates same file :oops:

Also, apart from timings, when using panzer on ST/Hatari/Steem and you use the function to read all the ID fields of a track, do you get the same order in all 3 cases ? (it should be)

Yes of course

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 2:53 pm

ooooooops :oops:
Speed of Hatari was set to 16 MHz
Now works fine. Actually Hatari is very accurate 8)
Steem is not too bad especially when setting slow drive but not as good :)

JimDrew
Atari Super Hero
Atari Super Hero
Posts: 638
Joined: Mon Nov 04, 2013 5:23 pm

Re: WD1772 Programming

Postby JimDrew » Fri Jan 30, 2015 4:18 pm

It's too bad you guys can't have a separate background task for Steem and HAtari that emulates the floppy system. That background task could just provide data using a mutual port. This is how the Amiga emulations work, and as a result we can emulate flux level data quite easily.
I am the flux ninja

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

Re: WD1772 Programming

Postby Steven Seagal » Fri Jan 30, 2015 5:09 pm

DrCoolZic wrote:Steem is not too bad especially when setting slow drive but not as good :)



Once again, Steem depends on pasti.dll for timings of STX images, not much to do except improve pasti.dll, which is the responsibility of ijor or some 3rd party team.

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 5:19 pm

Steven Seagal wrote:
DrCoolZic wrote:Steem is not too bad especially when setting slow drive but not as good :)



Once again, Steem depends on pasti.dll for timings of STX images, not much to do except improve pasti.dll, which is the responsibility of ijor or some 3rd party team.

Once machine set up correctly :oops: Steem FDC emulation is really not bad.

Actually both Hatari and Steem have improved a lot since I originally developed Panzer in 2008. At that time I could not use emulation at all.
I can now pre-test my SW on emulators, with reasonable accuracy, before I transfer to real Atari.

Good work and many thanks guys :)

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

Re: WD1772 Programming

Postby AtariZoll » Fri Jan 30, 2015 5:19 pm

Steven Seagal wrote:...
Once again, Steem depends on pasti.dll for timings of STX images, not much to do except improve pasti.dll, which is the responsibility of ijor or some 3rd party team.


You are right. But that helps not :( Only chance to significantly improve Pasti.dll is if Ijor reactivate self, and at least publish sources.
Or doing same as Hatari coders - making new STX file supporting code for Steem :roll:
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: WD1772 Programming

Postby DrCoolZic » Fri Jan 30, 2015 5:25 pm

do not forget also pretty good hard disk emulation :)
Did not talk to ijor for years?

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 5:35 pm

look at that --- compare Aufit - Steem - Hatari
Pretty good :)

Not fully comparable because Panzer does calculation quite differently
You do not have the required permissions to view the files attached to this post.

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

Re: WD1772 Programming

Postby AtariZoll » Fri Jan 30, 2015 7:48 pm

DrCoolZic wrote:do not forget also pretty good hard disk emulation :)
Did not talk to ijor for years?

Well, Hatari has advance in it too. While Pasti emulates only basic ACSI commands, in Hatari there is ICD ACSI support, IDE support.
What is much better by Steem is Debugger :D Ah, and 6301 emul :idea:
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: WD1772 Programming

Postby DrCoolZic » Fri Jan 30, 2015 9:08 pm

As far as I remember Pasti does emulates the ICD extension but unfortunately limit the size to 1 or 2 GB? Ijor was suppose to fix it but never did

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

Re: WD1772 Programming

Postby npomarede » Fri Jan 30, 2015 9:10 pm

DrCoolZic wrote:look at that --- compare Aufit - Steem - Hatari
Pretty good :)

I see some slight differences, could you post the STX of your formatted disk, by comparing aufit and stx that would give me an example of what I should get under Hatari as it seems Hatari has a little more delay (could be the equivalent of just transferring 1 byte too late maybe)

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 » Sat Jan 31, 2015 9:52 am

npomarede wrote:
DrCoolZic wrote:look at that --- compare Aufit - Steem - Hatari
Pretty good :)

I see some slight differences, could you post the STX of your formatted disk, by comparing aufit and stx that would give me an example of what I should get under Hatari as it seems Hatari has a little more delay (could be the equivalent of just transferring 1 byte too late maybe)

Nicolas

Sure I will attached the stx file.
But it is difficult to compare
on Aufit you directly measure (using flux transition) the time of the first byte of the ID the $FE - so this is the exact value
On Panzer you wait for interrupt to be detected in the status. So you already have a delay IP -> status register -> read & test status. At that time (delayed ip) you reset the timer
on detecting the last byte the FDC may still perform some actions like checking the CRC and reset the busy and set the INRQ. The program test for this int through the MFP and store the current value of the timer. So we are measuring the time between a delayed interrupt detection and a delayed end of id field detection.
The other thing is that everything is done by polling the FDC and the MFP in C so some variation here.
So I did some test on real Atari and there are a relatively big variation on the time of the first id. After that the time between id seems relatively close from one test to the next (in other word all the timing are shifted). It seems that we get the same behavior with Hatari (seems to indicate excellent emulation).

Bottom line I would not worry too much as the measurements do not seem very accurate for reason mentioned above as well as drive variation.

I am experimenting to improve last sector detection. So now I measure rotation time in front of the read address.
Here it is interesting to note that detecting IP on idle is OK but will not really work to measure time between IP. The problem seems to be that the IP has a certain duration and when you poll it returns the status of the signal. If you are lucky you get the start of the signal but you may sample anywhere... So the right way in that case is to use the D4 command and wait for IRQ then terminate with a D0

Obviously a better solution would be to use interrupt ...
I am still doing test to try to improve the result and I'll keep you posted
You do not have the required permissions to view the files attached to this post.

Guest

Re: WD1772 Programming

Postby Guest » Fri Feb 27, 2015 6:26 pm

the code doesnt work because the _hz_200 variable is never initialised other than void,..
i would expect the header to more define the value of some of the variables
the code has many loose holes where is the header????

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 » Sat Feb 28, 2015 5:11 pm

simbo2 wrote:the code doesnt work because the _hz_200 variable is never initialised other than void,..
i would expect the header to more define the value of some of the variables
the code has many loose holes where is the header????

_hz_200 is the Atari hz_200 system variable at 0x4ba it is updated by the system
The code presented here is just for people to get an idea about how addresses field are read nothing more.
the _hz_200 is really not critical it is here just as a watch dog the real timing are measured with Timer A
I am thinking of making code public if this interest some people

Guest

Re: WD1772 Programming

Postby Guest » Sat Feb 28, 2015 8:53 pm

awch the code doesnt define even in comment the variables nature setting a variable to 200hz is a bit slower than even the clocks for the rs232 the clock for rs232/midi runs at 500hz so some less than half doesnt match a standard system setting .... 200hz??? is very slow 5ms ... floppy access??? :|
you are always better to fit an ajax chip then you have 2.74ms access and block transfer.... after 20 years i think change out all the capacitors then time again just my view but you actually need to gain a factor not just a factator....

User avatar
metalages
Atari freak
Atari freak
Posts: 50
Joined: Thu Jun 06, 2013 5:14 pm
Location: France
Contact:

Re: WD1772 Programming

Postby metalages » Mon May 04, 2015 9:15 pm

Hi all,

I do not know if this is the exact right place to post my question... Anyway... :angel:
I try to make a simple FDC loading routine using interupts.
=> I sequence "read sector (one by one)" interleaved with "seek tracks" commands on the FDC.

Everything works fine with Steem but not in Hatari. So I decided to test on a real STe and it has the same behaviour than Hatari unfortunately (for me) :cry:

What happens is :
- on all platforms it works perfectly till I am using the floppy drive A
- but as soon as I read data from a 2nd floppy from the drive B, I have troubles on Hatari and / or real STe (it just works fine in Steem)
=> in this case the sector count decrease very (very !) slowly like if some time outs happened in the end at each sector and the loaded data is incorrect

As it does not work, I tried various things like :
- waiting for the motor_on bit go to 0 before reselecting drive / side on the YM
- sending interupt command $D0 at the end of my loading before selecting new drive / sending new command
... but still the same problem ...

Have you ever faced this kind of problem or do you know what problem to look at when reading from both floppy drives alternatively ?
(or should I have to look for a stupid bug in my code one more time :wink: )

Thanks for your help
Jerome

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

Re: WD1772 Programming

Postby npomarede » Tue May 05, 2015 3:22 pm

Hi

when selecting drive B, did you unselect drive A too ? Selecting both drives could create problem.
Else, you can post your program here, I can give a look under Hatari using debug traces to see where it fails (or run hatari with option "--trace fdc" and look into the output log to see if some error are reported)

Nicolas

User avatar
metalages
Atari freak
Atari freak
Posts: 50
Joined: Thu Jun 06, 2013 5:14 pm
Location: France
Contact:

Re: WD1772 Programming

Postby metalages » Tue May 05, 2015 5:10 pm

Hi Nicolas,

Should be ok as I eor the two bits, but I'll check once more.
I am going to try Hatari with trace fdc mode to see if I can catch something there.
If I do not manage to find the problem with this, I'll send you my unit test program that triggers the problem very clearly :wink:
Thank you for your help :D
Best regards

Jerome

User avatar
metalages
Atari freak
Atari freak
Posts: 50
Joined: Thu Jun 06, 2013 5:14 pm
Location: France
Contact:

Re: WD1772 Programming

Postby metalages » Tue May 05, 2015 8:31 pm

Hi Nicolas,

Ok I tried the trace mode of Hatari and see where the problem happens.

A sequence "seek track then read sector" that works on Drive 0 gives something like :

Code: Select all

fdc write 8606 ctrl=0x86 VBL=357 video_cyc=1136 112@2 pc=123c
fdc write 8604 data=0x6 VBL=357 video_cyc=1156 132@2 pc=1242
fdc write 8604 data=0x6 VBL=357 video_cyc=1156 132@2 pc=1242
fdc write 8606 ctrl=0x80 VBL=357 video_cyc=1180 156@2 pc=1248
fdc write 8604 data=0x13 VBL=357 video_cyc=1200 176@2 pc=124e
fdc write 8604 command=0x13 VBL=357 video_cyc=1200 176@2 pc=124e
fdc clear irq VBL=357 HBL=2
fdc type I seek dest_track=0x6 spinup=on verify=off steprate=3 drive=0 tr=0x5 head_track=0x5 VBL=357 video_cyc=1200 176@2 pc=124e
fdc start motor without spinup VBL=357 video_cyc=1944 408@3 pc=28a2
fdc update index drive=0 side=1 counter=1 ip_time=57158072 VBL=357 HBL=50
fdc complete command VBL=357 video_cyc=25968 368@50 pc=334e
fdc set irq 0x0 source 0x1 VBL=357 HBL=50
fdc change drive/side io_porta_old=0x4 io_porta_new=0x5 side 1->0 drive 0->0 VBL=357 HBL=50
fdc ipf change drive/side io_porta_old=0x4 io_porta_new=0x5 VBL=357 HBL=50
fdc write dma address ff860d val=0x00 address=0xfa00 VBL=357 video_cyc=26124 12@51 pc=119a
fdc write dma address ff860b val=0xfa address=0xfa00 VBL=357 video_cyc=26144 32@51 pc=11a0
fdc write dma address ff8609 val=0x00 address=0xfa00 VBL=357 video_cyc=26164 52@51 pc=11a6
fdc write 8606 ctrl=0x90 VBL=357 video_cyc=26184 72@51 pc=11ac
fdc write 8606 ctrl=0x190 VBL=357 video_cyc=26204 92@51 pc=11b2
fdc reset dma VBL=357 video_cyc=26204 92@51 pc=11b2
fdc write 8606 ctrl=0x90 VBL=357 video_cyc=26224 112@51 pc=11b8
fdc reset dma VBL=357 video_cyc=26224 112@51 pc=11b8
fdc write 8604 data=0x1 VBL=357 video_cyc=26244 132@51 pc=11be
fdc write 8604 dma sector count=0x1 VBL=357 video_cyc=26244 132@51 pc=11be
fdc write 8606 ctrl=0x84 VBL=357 video_cyc=26264 152@51 pc=11c4
fdc write 8604 data=0x1 VBL=357 video_cyc=26284 172@51 pc=11ca
fdc write 8604 sector=0x1 VBL=357 video_cyc=26284 172@51 pc=11ca
fdc write 8606 ctrl=0x80 VBL=357 video_cyc=26308 196@51 pc=11d0
fdc write 8604 data=0x80 VBL=357 video_cyc=26328 216@51 pc=11d6
fdc write 8604 command=0x80 VBL=357 video_cyc=26328 216@51 pc=11d6
fdc clear irq VBL=357 HBL=51
fdc type II read sector sector=0x1 multi=off spinup=on settle=off tr=0x6 head_track=0x6 side=0 drive=0 dmasector=1 addr=0xfa00 VBL=357 video_cyc=26328 216@51 pc=11d6
fdc start motor without spinup VBL=357 video_cyc=26348 236@51 pc=11d6
fdc read sector addr=0xfa00 drive=0 track=6 sect=1 side=0 VBL=357 video_cyc=56584 264@110 pc=26c8
fdc write 0xfa10 to dma address VBL=357 video_cyc=60680 264@118 pc=2e20
...
fdc complete command VBL=358 video_cyc=27928 280@54 pc=190a


on Drive 1 same sequence with additionnal drive select at the begining gives (read sector ends with RNF) :

Code: Select all

fdc change drive/side io_porta_old=0x4 io_porta_new=0x3 side 1->0 drive 0->1 VBL=458 HBL=2
fdc ipf change drive/side io_porta_old=0x4 io_porta_new=0x3 VBL=458 HBL=2
fdc write 8606 ctrl=0x86 VBL=458 video_cyc=1148 124@2 pc=1162
fdc write 8604 data=0x1c VBL=458 video_cyc=1168 144@2 pc=1168
fdc write 8604 data=0x1c VBL=458 video_cyc=1168 144@2 pc=1168
fdc write 8606 ctrl=0x80 VBL=458 video_cyc=1192 168@2 pc=116e
fdc write 8604 data=0x13 VBL=458 video_cyc=1212 188@2 pc=1174
fdc write 8604 command=0x13 VBL=458 video_cyc=1212 188@2 pc=1174
fdc clear irq VBL=458 HBL=2
fdc type I seek dest_track=0x1c spinup=on verify=off steprate=3 drive=1 tr=0x6 head_track=0x0 VBL=458 video_cyc=1212 188@2 pc=1174
fdc start motor with spinup VBL=458 video_cyc=1936 400@3 pc=288a
fdc init index drive=1 side=0 counter=0 ip_time=73295257 VBL=458 HBL=3
fdc update index drive=1 side=0 counter=1 ip_time=74899506 VBL=467 HBL=272
fdc update index drive=1 side=0 counter=2 ip_time=76503755 VBL=477 HBL=275
fdc update index drive=1 side=0 counter=3 ip_time=78108004 VBL=487 HBL=278
fdc update index drive=1 side=0 counter=4 ip_time=79712253 VBL=497 HBL=281
fdc update index drive=1 side=0 counter=5 ip_time=81316502 VBL=507 HBL=284
fdc update index drive=1 side=0 counter=6 ip_time=82920751 VBL=517 HBL=288
fdc complete command VBL=521 video_cyc=35180 364@68 pc=334e
fdc set irq 0x0 source 0x1 VBL=521 HBL=68
fdc write dma address ff860d val=0xf0 address=0x112f0 VBL=521 video_cyc=35336 8@69 pc=119a
fdc write dma address ff860b val=0x7f address=0x17ff0 VBL=521 video_cyc=35356 28@69 pc=11a0
fdc write dma address ff8609 val=0x04 address=0x47ff0 VBL=521 video_cyc=35376 48@69 pc=11a6
fdc write 8606 ctrl=0x90 VBL=521 video_cyc=35396 68@69 pc=11ac
fdc write 8606 ctrl=0x190 VBL=521 video_cyc=35416 88@69 pc=11b2
fdc reset dma VBL=521 video_cyc=35416 88@69 pc=11b2
fdc write 8606 ctrl=0x90 VBL=521 video_cyc=35436 108@69 pc=11b8
fdc reset dma VBL=521 video_cyc=35436 108@69 pc=11b8
fdc write 8604 data=0x1 VBL=521 video_cyc=35456 128@69 pc=11be
fdc write 8604 dma sector count=0x1 VBL=521 video_cyc=35456 128@69 pc=11be
fdc write 8606 ctrl=0x84 VBL=521 video_cyc=35476 148@69 pc=11c4
fdc write 8604 data=0x8 VBL=521 video_cyc=35496 168@69 pc=11ca
fdc write 8604 sector=0x8 VBL=521 video_cyc=35496 168@69 pc=11ca
fdc write 8606 ctrl=0x80 VBL=521 video_cyc=35520 192@69 pc=11d0
fdc write 8604 data=0x80 VBL=521 video_cyc=35540 212@69 pc=11d6
fdc write 8604 command=0x80 VBL=521 video_cyc=35540 212@69 pc=11d6
fdc clear irq VBL=521 HBL=69
fdc type II read sector sector=0x8 multi=off spinup=on settle=off tr=0x1c head_track=0x16 side=0 drive=1 dmasector=1 addr=0x47ff0 VBL=521 video_cyc=35540 212@69 pc=11d6
fdc start motor without spinup VBL=521 video_cyc=35560 232@69 pc=11d6
fdc update index drive=1 side=0 counter=1 ip_time=84525000 VBL=528 HBL=24
fdc update index drive=1 side=0 counter=2 ip_time=86129249 VBL=538 HBL=27
fdc update index drive=1 side=0 counter=3 ip_time=87733498 VBL=548 HBL=31
fdc update index drive=1 side=0 counter=4 ip_time=89337747 VBL=558 HBL=34
fdc update index drive=1 side=0 counter=5 ip_time=90941996 VBL=568 HBL=37
fdc type II read sector=8 track=0x16 side=0 drive=1 RNF VBL=568 video_cyc=19164 220@37 pc=18f4
fdc complete command VBL=568 video_cyc=19164 220@37 pc=18f4


YM port A is set to 3, so both drives should not be selected in the same time.
It seems that the headtrack when launching read sector is at x16 while tr=x1c (but it should have reached 0x1c instead with the previous seek track operation ?) So I wonder if it could be a problem of restoring track register after having toggled the current drive (drive 0 headtrack is 6 just before and 6 + 0x16 = 0x1c ... :) ) If this is the case I suppose the FDC makes a difference between current track and destination track to apply a seek track operation instead of considering track register value as an absolute "track address" ? But why an RNF result in this case ?

Jerome

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

Re: WD1772 Programming

Postby npomarede » Tue May 05, 2015 8:48 pm

metalages wrote:YM port A is set to 3, so both drives should not be selected in the same time.
It seems that the headtrack when launching read sector is at x16 while tr=x1c (but it should have reached 0x1c instead with the previous seek track operation ?) So I wonder if it could be a problem of restoring track register after having toggled the current drive (drive 0 headtrack is 6 just before and 6 + 0x16 = 0x1c ... :) ) If this is the case I suppose the FDC makes a difference between current track and destination track to apply a seek track operation instead of considering track register value as an absolute "track address" ? But why an RNF result in this case ?
Jerome

Hi
in the WD1772, the track register holds the "logical" position of the head. This can be different from the physical position of the head in drive A or B.
(some protections will do this on purpose to store to store sectors with track number 15 for example on the physical track 20)

But in your case, if you move head on drive A to track 6 with the "update track" bit set, the WD1772 will now store "6" in its internal track reg.
If you switch to drive B and tell it to seek to track 8 for example, it will do a STEP +2 because it expects current head to be on track 6 (as indicated in the track reg).
But if physical head was in fact on track 22 on drive B, doing your step to track 8 will do 2 STEPs and so the physical head will now be on track 24 !
But after that internal track reg will be 8.
So, when you read a sector the WD1772 will report RNF because the track number in the sector you read will be 24 (because you're physically on track 24) but the WD1772 expects to find a sector with the same track number as in the internal track reg, ie 8.

Solution for this : for each drive, you should maintain your own value of the physical head position. Each time you switch between drive A and B, you should first set the internal track register to the value you previously saved for that drive. After that, the seek/step/... command will correctly move the head and your read sector command will work.

Nicolas

User avatar
metalages
Atari freak
Atari freak
Posts: 50
Joined: Thu Jun 06, 2013 5:14 pm
Location: France
Contact:

Re: WD1772 Programming

Postby metalages » Wed May 06, 2015 6:30 am

Hi Nicolas,
I got it during the night :D sector ID field contains track index in some ways, that causing an RNF...
I'll try to backup / restore track register when swapping the drives activation and tell you if everything run fine now.
Thank you for your precious help putting me on the right track :wink:
Best regards
Jerome

User avatar
metalages
Atari freak
Atari freak
Posts: 50
Joined: Thu Jun 06, 2013 5:14 pm
Location: France
Contact:

Re: WD1772 Programming

Postby metalages » Thu May 07, 2015 9:48 pm

Hi Nicolas,
I found time to fix my FDC routine and try it in real conditions.
With the track register backup / restore it perfectly works on both Hatari and Atari :wink:
Thanks a lot for your help
Best regards
Jerome

User avatar
metalages
Atari freak
Atari freak
Posts: 50
Joined: Thu Jun 06, 2013 5:14 pm
Location: France
Contact:

Re: WD1772 Programming

Postby metalages » Mon Jul 20, 2015 3:46 pm



Social Media

     

Return to “Floppy Disk Preservation”

Who is online

Users browsing this forum: No registered users and 1 guest