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
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 9:07 am

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

This is correct but I still have not figure out the exact timing that causes the extra 9 to 10 bytes.

Of course the DMA cannot transfer at the same time to the CPU and to the FDC. When a FIFO is empty a bus grant is made and a refill of the FIFO is perform in one operation (8 words transfer). But on the FDC side one byte is transferred at a time.
This is hopefully explained page 7 and page 10-11 of my FD programming doc v1.0 http://info-coach.fr/atari/documents/my ... LG-V10.pdf

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 9:11 am

Steven Seagal wrote:
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"?

I guess this is the "Accurate disk timing (slow)"?
Answer is no I did not use.
So I turned this option on and I have tested again but it did not change the result :(

User avatar
Steven Seagal
Atari God
Atari God
Posts: 1629
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 11:51 am

I checked it in the source, data is read or written by packets of 16 bytes, which is fine enough for ST and MSA formats, I don't intend to fix that. There's no CRC info in ST and MSA anyway, right?
With the STW format data is read or written byte by byte and reading back gives CRC error.
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

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 11:55 am

This is fine with me. This is just for info my program has a bug and it is probably not important that Steem behaves like a real Atari in this very specific situation.

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 4:51 pm

Here is Panzer 0.24 that fixes the bug found by Nicolas.
Will now work if count > 1 specified for Read and Write sector commands
Internally for read sector: count = 1 read with multi=0 / count > 1 read with multi = 1 and check DMA address to stop with force interrupt
for write sector: always call count time the write command with multi always set to 0

**** However it is important to know that count > 1 currently ONLY works for 512 bytes sectors. So if you try to read 5 x 1024 bytes sectors it will fail ****
You do not have the required permissions to view the files attached to this post.
Last edited by DrCoolZic on Thu Jun 26, 2014 8:19 am, 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 » Wed Jun 25, 2014 5:06 pm

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

This is correct but I still have not figure out the exact timing that causes the extra 9 to 10 bytes.

Of course the DMA cannot transfer at the same time to the CPU and to the FDC. When a FIFO is empty a bus grant is made and a refill of the FIFO is perform in one operation (8 words transfer). But on the FDC side one byte is transferred at a time.
This is hopefully explained page 7 and page 10-11 of my FD programming doc v1.0 http://info-coach.fr/atari/documents/my ... LG-V10.pdf

I said that transfer can't happen on "both side" of the DMA but this may be wrong. The "CPU buses" and the Devices buses" are totally decoupled and it would be possible to perform simultaneous transfers. It is just a matter of implementation and anyway it has no real impact on the behavior of the DMA.

As mentioned above to Steven I was referring to my version 1.1 that contains a lot more information about the way the DMA works (including the bit 6 behavior). I have also added a pseudo block diagram of the DMA that should help.

I need to work a lot on this document including rewriting the section on multi sector write but all this will take time. So meanwhile I am going to release my version 1.1 that contains a lot of interesting information about the DMA....
You do not have the required permissions to view the files attached to this post.

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

Re: FD Timing/Protection Information Tools for emulators

Postby Dio » Thu Jun 26, 2014 10:22 am

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

I would expect that what actually happens is that this is an artifact of the DMA protocol. The rule for initiating a read transfer on the CPU side is probably (Either FIFO empty) && (Write DMA enabled). So what happens is two back-to-back transfers, and the CPU doesn't get any cycles in the middle, so it's impossible to see a case when the first FIFO isn't full from the CPU.

The actual transfer to the FDC can probably happen if a DRQ is seen any time after the first FIFO is full. So both FIFOs aren't necessarily filled first, but it probably happens that way in the general case because the 32 cycles required for a DMA transfer is a very short time to the FDC. Not so much to the HDC though, but since the DMA is enabled at command init, the two FIFOs are almost certainly full by the time that DRQ is asserted.

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 » Thu Jun 26, 2014 6:03 pm

The normal sequence is to set the DMA first. At the end of the init sequence the two DMA buffers are filled before the program starts the FDC/HDC wirite command. Therefore in write mode the two FIDOs of the DMA are always filled before the command starts.
What Nicoloas describes is that at the end of a sector we have the second buffer that is filled with 16 bytes beyond the end of the sector. At this time my program sends a force interrupt this happen roughly in the middle of the FIFO ....

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 » Thu Jun 26, 2014 6:03 pm

The normal sequence is to set the DMA first. At the end of the init sequence the two DMA buffers are filled before the program starts the FDC/HDC wirite command. Therefore in write mode the two FIDOs of the DMA are always filled before the command starts.
What Nicoloas describes is that at the end of a sector we have the second buffer that is filled with 16 bytes beyond the end of the sector. At this time my program sends a force interrupt this happen roughly in the middle of the FIFO ....

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

Re: FD Timing/Protection Information Tools for emulators

Postby Steven Seagal » Sun Jul 13, 2014 10:39 am

I think this part of doc is incorrect:

When using the immediate interrupt condition (i3 = 1) an interrupt is
immediately generated and the current command is terminated. Reading the status or writing to the
Command Register does not automatically clear the interrupt. The Hex $D0 is the only command that
enables the immediate interrupt (Hex $D8) to clear on a subsequent load Command Register or Read
Status Register operation. Always follow a Hex $D8 with a $D0 command.


I wonder if they meant $D4 instead?
At any rate, case Super Monaco GP (SMGP.MSA on Pirate Gold CD) shows that reading STR clears IRQ after $D8.
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

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 Jul 14, 2014 8:30 am

Thanks for info I will look at it when back home :)

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

Re: FD Timing/Protection Information Tools for emulators

Postby npomarede » Tue Jul 22, 2014 2:04 pm

Steven Seagal wrote:I think this part of doc is incorrect:

When using the immediate interrupt condition (i3 = 1) an interrupt is
immediately generated and the current command is terminated. Reading the status or writing to the
Command Register does not automatically clear the interrupt. The Hex $D0 is the only command that
enables the immediate interrupt (Hex $D8) to clear on a subsequent load Command Register or Read
Status Register operation. Always follow a Hex $D8 with a $D0 command.


I wonder if they meant $D4 instead?
At any rate, case Super Monaco GP (SMGP.MSA on Pirate Gold CD) shows that reading STR clears IRQ after $D8.

This part of the doc is incomplete. I checked it some time ago on my STF (and changes were added since to Hatari and caps library 5.1 to handle it) : it's not only $D0 that stops the immediate interrupt condition sets by $D8, but any new command after a $D8 will have the same effect on the immediate interrupt as sending a $D0 after $D8.

Nicolas


Social Media

     

Return to “Development”

Who is online

Users browsing this forum: No registered users and 2 guests