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 ?)
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).
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
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
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.
By the way DrCoolZic you could want to update the DMA part of your doc regarding DRQ based on case Kick Off 2:
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)
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:
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???
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!
Users browsing this forum: No registered users and 3 guests