FD Timing/Protection Information Tools for emulators

A place to discuss current and future developments for STeem

Moderators: Mug UK, Steem Authors, Moderator Team

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

Re: FD Timing/Protection Information Tools for emulators

Postby npomarede » Fri Sep 13, 2013 9:43 am

Hello
I will try to run the same programs you sent to see if I can reproduce the error (probably next week).
But in the case of Hatari, I don't think you need to run additional programs to set the clock ; press F12 and in 'system' enable the real time clock, this should be enough.

Nicolas

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Fri Sep 13, 2013 10:00 am

Same actually for Steem
The reason of presence of all these programs is that the C drive I use is an exact copy of what I use in my real Atari using ultrasatan :)

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Fri Sep 13, 2013 4:15 pm

npomarede wrote:(btw, did you receive the mail I sent you some times ago about some fixes for the DMA description in your FDC doc ?)
Nicolas


I have completed a new version of my FD/HD programming document that includes some (most) of the information you provided. The document is not yet on my site so it is attached to this post
You do not have the required permissions to view the files attached to this post.

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

Re: FD Timing/Protection Information Tools for emulators

Postby Steven Seagal » Sat Sep 21, 2013 3:45 pm

DrCoolZic wrote:
PS. On steem without .stx I still get 0 for sector timing I guess this is related to DMA not beeig correctly emulated (works fine when stx files mounted).


DMA emu has been improved while adding IPF support.
Please make sure 'slow' disk mode is selected for other image types.

About your doc, I used it before but I had to convert the PDF or it was impossible to copy/paste.
Surely this isn't the intent?

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Sun Sep 22, 2013 12:17 pm

I just checked and indeed the previous version was secured. You could print but not copy. Not sure why I did that?
The version I just released is not secured so you can copy anything you want 8)

User avatar
Maartau
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2588
Joined: Thu Dec 15, 2005 2:15 am
Location: France

Re: FD Timing/Protection Information Tools for emulators

Postby Maartau » Sat Sep 28, 2013 12:14 pm

DrCoolZic wrote:I have completed a new version of my FD/HD programming document that includes some (most) of the information you provided. The document is not yet on my site so it is attached to this post


Cheers : really good job :thumbs: .
Member of :
- aTaRi LeGeNd ,
- eLiTe ! ,
- NoExTrA .

Don't hesitate to visit http://www.atarimania.com/ & http://www.atarilegend.com/ :D

-> Slowed due to serious health troubles <-

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

Re: FD Timing/Protection Information Tools for emulators

Postby npomarede » Thu Jun 19, 2014 10:49 pm

Hello

while testing write sectors with multibit=1 (command 0xb0) in Hatari, I think I noticed a bug in panzer :
from what I see in my traces, you send a force int 0xd0 command to stop the write sector once DMA address reaches start address + length of all sectors.
For example, if you write two 512 byte sectors at address $10000, you stop when DMA address == $10400.

Doing this is OK when reading sectors, but it's wrong when writing sectors, because in that case DMA address is incremented by 16 and then you need to write those 16 bytes to the disk (+ 2 CRC bytes). If you stop when address==$10400, then the last 16 bytes will not be written, they stay in the DMA FIFO :(
I don't know exactly the behaviour of the FDC when it receives a force int before completing the sector, butI guess it will be truncated and the CRC won't be updated too (you will keep the data that where previously here in this sector)

So, a correct stop condition in panzer would be to wait for address==$10400 + 16, to be sure the last 16 bytes were written to disk.
But even if you do this and you send immediately a force int, you're likely to stop the write sectors command before the 2 CRC bytes were written.
Writing these 2 bytes will need 2*256 cycles (for a 68000 cpu at 8 MHz).

Either you do a kind of wait loop with some "dbf", but this will fail with faster CPU / MHz, or the best way would be to start an MFP timer to wait at least the equivalent of 512 cpu cycles (take 1024 to be safe), and then you should be able to send the force int command.

NOTE : I didn't try this on a real STF, but I think it will be wrong too

Nicolas

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Fri Jun 20, 2014 6:55 pm

npomarede wrote:Hello

while testing write sectors with multibit=1 (command 0xb0) in Hatari, I think I noticed a bug in panzer :
from what I see in my traces, you send a force int 0xd0 command to stop the write sector once DMA address reaches start address + length of all sectors.
For example, if you write two 512 byte sectors at address $10000, you stop when DMA address == $10400.

Doing this is OK when reading sectors, but it's wrong when writing sectors, because in that case DMA address is incremented by 16 and then you need to write those 16 bytes to the disk (+ 2 CRC bytes). If you stop when address==$10400, then the last 16 bytes will not be written, they stay in the DMA FIFO :(
I don't know exactly the behaviour of the FDC when it receives a force int before completing the sector, butI guess it will be truncated and the CRC won't be updated too (you will keep the data that where previously here in this sector)

So, a correct stop condition in panzer would be to wait for address==$10400 + 16, to be sure the last 16 bytes were written to disk.
But even if you do this and you send immediately a force int, you're likely to stop the write sectors command before the 2 CRC bytes were written.
Writing these 2 bytes will need 2*256 cycles (for a 68000 cpu at 8 MHz).

Either you do a kind of wait loop with some "dbf", but this will fail with faster CPU / MHz, or the best way would be to start an MFP timer to wait at least the equivalent of 512 cpu cycles (take 1024 to be safe), and then you should be able to send the force int command.

NOTE : I didn't try this on a real STF, but I think it will be wrong too

Nicolas

Thanks this is very interesting info ... I need to look at this in detail.
I currently do not have time to work on Atari stuff but I will look at it later :)
thanks again

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

Re: FD Timing/Protection Information Tools for emulators

Postby npomarede » Fri Jun 20, 2014 7:00 pm

No rush needed :) I put this report here to just to be sure we don't forget it.

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Sat Jun 21, 2014 3:29 pm

Nicolas I looked at the reported problem and if Panzer is not working in this condition it is probably a problem in the emulator not in Panzer. I think that what confuses you is the name “Force interrupt” command that seems to indicate an immediate interrupt but this is not always the case.

Detail information:
  • In Panzer if you read (or write) one sector then the multiple record flag is set to zero (m=0) and if you read (or write) two or more sectors this flag is set to one. This is done on purpose so you can test single or multiple sector read/write commands as the behavior is quite different. For single sector read/write the read/write command terminate “automatically”, in case of multiple read/write sector it is necessary to terminate the command using the force interrupt command and this has to be done before all the bytes are transferred to the FDC (see below).
  • It is important to understand how the force interrupt command works: This command is usually used to immediately terminate a command EXCEPT in the case of a read/write command with the multiple record flag set. In that case this command indicates that the current sector is the last sector to read/written. In that case the WD1772 continues to send or receive all the bytes for the current sector as specified in the sector size and reads or writes the CRC bytes and terminates the command after all this has been completed. Fortunately it is not necessary to care about how much time is necessary to send receive the reminding bytes as you describe.
For more detail I recommend that you look at my document “Atari Floppy Disk Programming” at http://info-coach.fr/atari/documents/my ... LG-V10.pdf as well as my edited WD1772 Datasheet at http://info-coach.fr/atari/documents/my ... LG-V11.pdf
Also you can read the article from David Small “Probing the FDC” (Start Magazine 1986 page 97 http://www.atarimania.com/mags/pdf/atar ... ssue_2.pdf ). See also the FLOP.S routine provided by Atari in the BIOS to developers.

Note that for the read/write command Panzer works exactly the same way as the BIOS even though it is written in C instead of ASM. See http://dev-docs.atariforge.org/ search BIOS (BIOS_Listing_7-9-1985.pdf).

I do not have access to an Atari currently so I can’t check but I would be surprise if it does not work.
I would be interested to find out what is not working in the Hatari emulation?
Are you using the WD1772 emulation from the SPS library or did you wrote your own?
Jean

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

Re: FD Timing/Protection Information Tools for emulators

Postby npomarede » Sat Jun 21, 2014 4:53 pm

The tests are made using my own fdc emulation (not the one in capslib, as it doesn't support writing sectors :) )
Based on the original WD1772 doc, I don't see explicitely that the force interrrupt on a multiple write sectors command will let the command complete until the end of the current sector. The doc just says that Force Int will interrupt the command. With all other command, force int stops the command immediately, so I would expect to it do the same, even with a multiple sector command (the article by Dave Small doesn't give more indication on this subject too, it's more a rewrite of the original WD1772 in a more "natural" language)

But I didn't check this on real ST, so I can't say for sure what is the real behaviour, I will try to write a small test program to test it later.

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Sat Jun 21, 2014 5:10 pm

I know this is not crystal clear but you should look at the document BIOS_Listing_7-9-1985.pdf referenced above.
Search for page 883 routine _flowpwr

I am almost sure the WD1772 works like what I have described. It would be very hard if you have to compute the exact timing to stop the FDC at a precise time :(

I thought I had the flop.s file but I cant find it ?

I will see if I can find other doc that confirm this

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

Re: FD Timing/Protection Information Tools for emulators

Postby npomarede » Sat Jun 21, 2014 9:48 pm

Page 883 does not confirm this. When count>1, the bios doesn't set the multi bit, it just does several write sector with multi=0 (you can see the use of command 0xa0) and decrement count until it reaches 0.
I'm really not sure there're many programs using write + multi=1 to check how they behave (read + multi is often used, but that's easier to handle)

EDIT : correct typo : I meant the TOS uses command 0xa0 in that case, not 0xb0
Last edited by npomarede on Sun Jun 22, 2014 9:32 pm, edited 1 time in total.

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Sun Jun 22, 2014 8:01 am

I have looked again to the flop.s routines and you are right the multi-write flag is not used for writing several sectors. I did this code long time ago and I thought it worked like this.

Reading multiple sectors apparently uses the multi flag but this is not used for the write. What is even more scary is the comment written on page 878 that says _flopwr understands ccount (but cannot do multi sectors DMA a HW constraints).

I need to check Panzer and my FDLIB to see exactly what I have done. Meanwhile would be interesting to test on real machine

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

Re: FD Timing/Protection Information Tools for emulators

Postby Steven Seagal » Sun Jun 22, 2014 8:45 am

The case I know that does $B0 multisector write is Platoon.
I never saw anywhere that $D0 didn't interrupt at once.
What happens is that the FDC stops writing at the first sector not found (RNF), then you interrupt or you wait that it times out.
By the way DrCoolZic you could want to update the DMA part of your doc regarding DRQ based on case Kick Off 2:
viewtopic.php?f=94&t=25093&p=254456#p254402

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

Re: FD Timing/Protection Information Tools for emulators

Postby npomarede » Sun Jun 22, 2014 9:39 pm

Yes, the case of Platoon is "simpler" because the game just writes 5 sectors in a row using the multi bit and it waits until a RNF is received (which happens when FDC tries to find sector 6, but this track has only 5 sectors).

So in that case, no need to interrupt with force int, the game rewrites all the sectors everytime, which can be another method when you want to use multi bit=1 :
- first read all sectors with multi bit=1 (should take only 1 revolution if there's no interleave)
- modify the data in 1 or several sectors
- write back all sectors with multi bit=1 (will take only 1 revolution)
- wait for RNF

If you want to write only a selected set of sectors without reading the whole track's sectors first, then I think you must carefully send a force int command when DMA address reaches the expected value + delay for CRC (as described above)

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Mon Jun 23, 2014 11:37 am

Steven Seagal wrote:The case I know that does $B0 multisector write is Platoon.
I never saw anywhere that $D0 didn't interrupt at once.
What happens is that the FDC stops writing at the first sector not found (RNF), then you interrupt or you wait that it times out.

You are right I am still wandering were I found this stupid description ??? :(

By the way DrCoolZic you could want to update the DMA part of your doc regarding DRQ based on case Kick Off 2:
viewtopic.php?f=94&t=25093&p=254456#p254402

Not sure what you want me to update based on KickOff 2. My document already indicates that bit 6 is just ignored. This is a well known fact.

What I definitively need to change is the write "multi" that does not work as described

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Mon Jun 23, 2014 11:44 am

npomarede wrote:Yes, the case of Platoon is "simpler" because the game just writes 5 sectors in a row using the multi bit and it waits until a RNF is received (which happens when FDC tries to find sector 6, but this track has only 5 sectors).

So in that case, no need to interrupt with force int, the game rewrites all the sectors everytime, which can be another method when you want to use multi bit=1 :
- first read all sectors with multi bit=1 (should take only 1 revolution if there's no interleave)
- modify the data in 1 or several sectors
- write back all sectors with multi bit=1 (will take only 1 revolution)
- wait for RNF

If you want to write only a selected set of sectors without reading the whole track's sectors first, then I think you must carefully send a force int command when DMA address reaches the expected value + delay for CRC (as described above)

Nice trick but really not something I would recommend.
As far as using delay as you described above this sounds a bit dangerous because DMA latency is not precisely known.

I guess things works well in "multi" read mode because you have some extra time to send the immediate interrupt while the WD1772 is working on the CRC computation (two extra bytes) ...

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Mon Jun 23, 2014 12:04 pm

To fix the problem in Panzer I need to fix the bug in my FDLIB as well as in Panzer. I dont know when I will do this.
Meanwhile you should be able to write sector one by one. If sector count is one then the write command with multi is not used and should work.


For info I did a lot of tests on reading FD but very few on witting FD (either write sector or write track). This is something I should do.
Thanks again for finding the bug :)


It will also take time to update the FD programming document.
I also have a DD programming doc that covers FD/HD programming but it is in an even more unstable state!

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Tue Jun 24, 2014 9:55 pm

Steven Seagal wrote:By the way DrCoolZic you could want to update the DMA part of your doc regarding DRQ based on case Kick Off 2:


I have started to modify my documentation based on information provided by Nicolas. Doing so I just realized that I did not yet published version 1.1 of my documentation that explicitly explain the behavior of bit 6 of the DMA.
Sorry I thought it was published. It would not make sense to publish it now so you will need to wait for version 1.2 that explain the problem with the multi write.
I also want to add in the doc some other discoveries I made about the internal behavior of the WD1772

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Wed Jun 25, 2014 8:36 am

I have been able to make some tests on a real Atari and the results are strange!
I do a "write multiple" with a sector count of 3. The write multiple fails but it is not the last 16 bytes that are missing but 25 or 26 bytes (not always same number)? And the remaining bytes of the sector have different values each time I do a write.
This confirms that the force interrupt terminate the command ASAP (still for read multiple the CRC computation is carries out as indicated in the doc).

For information: I have tested the behavior on Steem 3.6.0 (with Pasti on) and the write multi works perfectly :)
So if I write multiple 3 sectors and read multiple same sectors all the bytes are written/read correctly. I guess it should not
However if I do a read track the information written is not updated in the track???

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

Re: FD Timing/Protection Information Tools for emulators

Postby Steven Seagal » Wed Jun 25, 2014 8:48 am

DrCoolZic wrote:For information: I have tested the behavior on Steem 3.6.0 (with Pasti on) and the write multi works perfectly :)
So if I write multiple 3 sectors and read multiple same sectors all the bytes are written/read correctly. I guess it should not
However if I do a read track the information written is not updated in the track???


If Pasti is on, Steem version is more or less irrelevant. Unfortunately ijor has deserted the forum.
However I found that writes with pasti.dll are instant, there's no attempt to emulate timings, so you shouldn't rely on this.

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

Re: FD Timing/Protection Information Tools for emulators

Postby npomarede » Wed Jun 25, 2014 8:53 am

I think I have an explanation for these 25-25 bytes : the DMA FIFO is in fact 2 FIFOs of 16 bytes, and DMA switches between each every 16 bytes.
In case of reading, both FIFO start empty. but in case of writing, both FIFO are filled first (because the DMA doesn't seem able to use a FIFO to send data to the FDC while the FIFO is refilled, so it must fill 2 FIFOs at start).
So, you will have up to 32 bytes ahead, and I guess that's why you end with more than 16 bytes when you do the force int.

If you stop a write track in the middle with a force int, I think you will get a similar result : an altered track where end of track will not be overwritten.

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

Re: FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Wed Jun 25, 2014 8:55 am

OK I did the test in Steem with Pasti off and it fixes the problem of the read track information "not updated".
However the write multiple still works perfectly but it should not!

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

Re: FD Timing/Protection Information Tools for emulators

Postby Steven Seagal » Wed Jun 25, 2014 9:03 am

DrCoolZic wrote:OK I did the test in Steem with Pasti off and it fixes the problem of the read track information "not updated".
However the write multiple still works perfectly but it should not!


Stupid question but do you use option "Slow drive"?


Social Media

     

Return to “Development”

Who is online

Users browsing this forum: No registered users and 1 guest