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:

FD Timing/Protection Information Tools for emulators

Postby DrCoolZic » Fri May 31, 2013 1:30 pm

In this thread I would like to publish some of the tools that I have developed to measure timing related to Atari floppy drives/disks.

Most if not all of these tools were developed originally to detect FD protection mechanisms used on Atari (see viewtopic.php?f=95&t=21952 and viewtopic.php?f=47&t=9012 and http://info-coach.fr/atari/software/preservation.php as a starting point).
As many Atari FD protections use some timing tricks all these tools also provides nice timing measurement capabilities.

By using the Kryoflux device it is possible to image FD at the flux transition level with a resolution of about 40ns which is pretty good (for information back in the 80s the Discovery Cartridge already provided the same capabilities :roll: ). Therefore Stream files and converted IPF files should be considered as the reference to get very precise timing information.

So it should be possible to perform the following tests starting from an Atari reference Floppy Disk:
  • Measure timing of the original FD on a real Atari
  • Measure very precise timing using Stream / IPF files obtained by imaging the original FD with the Kryoflux device.
  • Measure timing on emulators using STX / IPF files
The goal here is to see how precisely the FD are emulated with Steem/Hatari (from IPF and or STX files) and eventually if this can be improved.

To measure timings I will publish the following programs:
  • Panzer Program that run on Atari and that provides I believe as good as possible FD timing measurement on real Atari.
  • KFAnalyze that gives same kind of information on a PC from KryoFlux raw Stream files.
  • IPFAnalyze that provides again the same information on a PC but this time from SPS IPF files.

I have received a request from people developing Atari emulators to release these programs as soon as possible so they can perform test. Therefore I will published these programs quickly, but keep in mind that some of these programs were never published because I consider that they are still in beta so use with caution.

The next message will be kept up to date with releases.
Please provides feedback and in case of bugs/new features I will try my best.

Personally I will try to perform test using the Blood money game (see http://ataristeven.t15.org/Steem_games.htm) because I have the real FD, a Stream Version, and IPF version, and a STX version (but I am not sure they are all based on the exact same version).

For people that own a Kryoflux board they can use the following process (not tested):
  • Take an IPF file (remember that currently only SPS is capable of generating one) and write a FD from it with KryoFlux write capability
  • Generate raw Stream files from the created FD on a PC using Kryoflux imaging capabilities
  • Use the created FD to measure timing on Atari with Panzer
  • Create a Pasti .stx file from the floppy on Atari
  • Measure timing on PC using KFAnalyze (from Stream) and IPFAnalyze (from IPF)
  • Measure timing running Panzer on emulator with FD mounted from IPF and/or STX file
Last edited by DrCoolZic on Sat Jun 15, 2013 8:17 am, edited 2 times 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 Information Tools for emulators

Postby DrCoolZic » Fri May 31, 2013 1:31 pm

Program running on Atari
  • The PANZER (Protection ANalyZER) program automatically detects and reports most of the Key-disk Protections used on many Atari’s games. It also provides the capability to analyze and report detailed information about sectors and tracks. Note that the program is still in early beta test and may detect/report incorrect protection information. For safety reason makes sure that you write protect the floppy diskettes you want to analyze.
PANZER.rar

Programs running on Windows
IPFAnalyze.rar
You do not have the required permissions to view the files attached to this post.
Last edited by DrCoolZic on Fri May 31, 2013 3:24 pm, edited 2 times 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 Information Tools for emulators

Postby DrCoolZic » Fri May 31, 2013 1:32 pm

Reserved for comments

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

Re: FD Timing Information Tools for emulators

Postby npomarede » Fri May 31, 2013 10:12 pm

Hi

thanks for posting Panzer, I tested it and it's look very interesting. The possibility to check every FDC command and get precise timings can certainly help improving emulation by comparing result with real hardware. This will certainly be a very valuable tool in my case :D

But so far, I have 2 problems :
- screen height works only under monochrome ? Not a problem under emulation, but I can't use it on my 520 STF where I only have a color tv.
Is there a way to make the program work under med res too ? See the screenshot of what you get in medres (bottom half of the screen is missing :( )
panzer.png

- more serious : panzer doesn't work on my 520 stf (tos 1.02 fr). The program starts, but if I try Commands / Read Address or Read Sector for example, it never completes : drive light remains on, but nothing seems to happen. It doesn't abort either, even after several minutes, so you need to reset the ST. Maybe Panzer was only developped/tested under emulation ? Or does it work on your STF ? (but the same commands work under Hatari and Steem)

The feature to build a track with predefined gaps is also very nice to get reproduceable results as it allows to always format a track the same way.
That's just a detail (as it can be changed manually), but why do you use gap2=10 instead of 12 in the predef 10*512 track ? 12 is more standard and it will still fit in the track.

Anyway, nice tool, hope you can fix those issues and improve it :cheers:

Nicolas
You do not have the required permissions to view the files attached to this post.

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

Re: FD Timing Information Tools for emulators

Postby Steven Seagal » Sat Jun 01, 2013 5:38 pm

Downloaded the 'Panzer' but will certainly not run it now: I really want to release Steem v3.5.1 and won't try anything new lest I be drowned in more fascinating issues. :)
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 Information Tools for emulators

Postby DrCoolZic » Tue Jun 04, 2013 11:26 am

Nicolas,

Yes I am aware that the program only runs in high resolution. I might look at adding support for medium resolution in future. I am not that good on Atari GUI dev :(

The program has been developed almost exclusively on a real Atari because Steem emulation used to be not that good unless you used Pasti option.

All the development has been done on my main machine: an Atari STe with 4 MB of RAM
I also have a secondary Atari 1040 STF machine and I believe that the program has also been tested on this machine (I can double check). But this machine has been modified by B&C computer at the time I was living in the silicon valley (USA): the system has the JRI RAM upgrade (http://info-coach.fr/atari/hardware/mem ... rade_board) and therefore is equipped of 4MB of RAM with 1.04 US TOS

I have therefore no idea about the problem? It may be caused by the size of the RAM?

For the last question I do not understand. Ma version v0.10 date 2008-11-21 has GAP2=12 by default ???? And I am almost sure that I published this version ???
So unless you have changed to 10 (in which case it stays equal to 10 until changed again) it should be 12
Can you please confirm.

I just return from trip today but will not have too much time to do tests
To get maximum timing information I recommend that you use the "print protect." command

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

Re: FD Timing Information Tools for emulators

Postby npomarede » Tue Jun 04, 2013 11:45 am

DrCoolZic wrote:Nicolas,

Yes I am aware that the program only runs in high resolution. I might look at adding support for medium resolution in future. I am not that good on Atari GUI dev :(

I didn't code for GEM since a very long time, but as it's just about reducing the height, isn't it possible to quickly halve all Y values ?
The program has been developed almost exclusively on a real Atari because Steem emulation used to be not that good unless you used Pasti option.

All the development has been done on my main machine: an Atari STe with 4 MB of RAM
I also have a secondary Atari 1040 STF machine and I believe that the program has also been tested on this machine (I can double check). But this machine has been modified by B&C computer at the time I was living in the silicon valley (USA): the system has the JRI RAM upgrade (http://info-coach.fr/atari/hardware/mem ... rade_board) and therefore is equipped of 4MB of RAM with 1.04 US TOS

I have therefore no idea about the problem? It may be caused by the size of the RAM?

My STF has 1 MB of RAM ; should be enough ?
For the last question I do not understand. Ma version v0.10 date 2008-11-21 has GAP2=12 by default ???? And I am almost sure that I published this version ???
So unless you have changed to 10 (in which case it stays equal to 10 until changed again) it should be 12
Can you please confirm.

I just return from trip today but will not have too much time to do tests
To get maximum timing information I recommend that you use the "print protect." command

See the attached screenshot, predef 10x512 has G2=10, shouldn't it be G2=12 (like 9x512) ?

Nicolas

panzer_predef.png
You do not have the required permissions to view the files attached to this post.

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 Information Tools for emulators

Postby DrCoolZic » Tue Jun 04, 2013 12:51 pm

I understand we were not talking about the same menu!
Yes 12 makes more sense in this context I will change it in the next release
Note that in that case you can use the "build track" command
Thanks for feedback

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

Re: FD Timing Information Tools for emulators

Postby npomarede » Tue Jun 04, 2013 10:31 pm

Hello
I did some tests again on my PAL 520 STF double sided TOS 1.02 FR, and still no luck :(
I tried a simple "analysis / rotation time", I press OK in the popup window with 5 rotations, head is moving (I think it does a "restore"), drive light is on, and nothing else happens, removing the disk has no effect either, program loops forever (but you can still move the mouse)

I tried Hatari with STF mode, tos 1.02 FR, 512 KB or 1 MB, in med res too, and "rotation time" works, so memory size doesn't seem related, neither TOS.

It really seems there's a problem on real HW in my case with Panzer (but my STF works flawlessly with all demos/games I know, so I doubt it's a related to it).

Hard to tell where's the problem, if you have time, maybe you could build a version that display a small text/number on each steps, so we could see where the program gets stuck in my case.

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 Information Tools for emulators

Postby DrCoolZic » Wed Jun 05, 2013 10:11 am

I am slowly setting up environment for test.
I am currently mainly working on updating several documents to be ready when I start test.
So I have not yet had chance to test on my 1040 STF and yes we can try to create a debug version with output like you describe.

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 Information Tools for emulators

Postby DrCoolZic » Sun Jun 09, 2013 9:18 am

Nicolas,
I have been thinking to your problem on STF :mrgreen:

This was long time ago but I think I remember having problem detecting if FDisk is present in the drive on some machines?
When the program starts the first thing it does is to check that there is a disk in Drive A. Therefore at start-up the drive led should go on and motor should start. If no disk is present you should get a warning message. Currently timeout for commands in my FDLib is handled very poorly by polling status bit. I have to add an interrupt mechanism to handle timeout correctly.
I made some tests and it seems that in some unknown conditions my drive_ready function has bugs. Therefore what I will do is create a new "special version" for you that will bypass drive_ready detection. Of course you will have to make sure that there is a FD in the drive before you issue commands :oops:

You were asking about debug information while using Panzer. This is already available :)
Start Panzer. Got to Options->advance and in debug level enter 252
The program creates a Panzer.dbg file that contains a lot of information (this will slow down a lot the usage to a point where some command might not work correctly)
Actually rather use 156 for debug value this should give you the information you need ;)

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

Re: FD Timing Information Tools for emulators

Postby npomarede » Sun Jun 09, 2013 9:29 am

DrCoolZic wrote:Nicolas,
I have been thinking to your problem on STF :mrgreen:

This was long time ago but I think I remember having problem detecting if FDisk is present in the drive on some machines?
When the program starts the first thing it does is to check that there is a disk in Drive A. Therefore at start-up the drive led should go on and motor should start. If no disk is present you should get a warning message. Currently timeout for commands in my FDLib is handled very poorly by polling status bit. I have to add an interrupt mechanism to handle timeout correctly.
I made some tests and it seems that in some unknown conditions my drive_ready function has bugs. Therefore what I will do is create a new "special version" for you that will bypass drive_ready detection. Of course you will have to make sure that there is a FD in the drive before you issue commands :oops:

That's good news, I will test this when it's available. If it works better, maybe you could post the code of your 'drive_ready' function, so we can find the possible cause of the problem.
But in my case, the program start correctly, I can use the menus ; do you mean the test is made when I choose an FDC command, not before ?
You were asking about debug information while using Panzer. This is already available :)
Start Panzer. Got to Options->advance and in debug level enter 252
The program creates a Panzer.dbg file that contains a lot of information (this will slow down a lot the usage to a point where some command might not work correctly)
Actually rather use 156 for debug value this should give you the information you need ;)

The debug was to see what was happening in the case where my STF was stuck ; as I need a reset to exit the program, I don't think it would be good to do if a debug file is being written to at the same time, this could leave errors on the disk.

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 Information Tools for emulators

Postby DrCoolZic » Sun Jun 09, 2013 10:12 am

Ok I have created a new version 0.11 of Panzer
- modified code as requested: Buffer->Build predef ====> 10*512 now G2=12 instead of 10
- added a debug flag to turn of FD detection. Go to Options -> Advance and set debug level value to 002
if the problem is with fd_ready it will fiw the problem but make sure you have a FD in drive before using commands (although it should normally endup after a long long timeout).
Let me know if it works
You do not have the required permissions to view the files attached to this post.

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 Information Tools for emulators

Postby DrCoolZic » Sun Jun 09, 2013 1:04 pm

OK this new version 0.12 can be used in medium resolution. However this is not an official support for medium resolution because most forms would need to be reworked and the main display is not 100% correct. This is a lot of work (I am not good at GEM!) and it is not high priority ;)
This version support the debug level = 002 flag as described in previous release.
You do not have the required permissions to view the files attached to this post.

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 Information Tools for emulators

Postby DrCoolZic » Sun Jun 09, 2013 5:32 pm

I have made some test under Steem and it seems that the write / sector track do not work for me???
I do not have access to real atari but seems like write command might be broken?

I did not play too much with the program under Steem but it seems that the program does not work unless you use Pasti?
This is strange this means that the low level emulation seems pretty bad in Steem 3.2

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

Re: FD Timing Information Tools for emulators

Postby npomarede » Sun Jun 09, 2013 6:45 pm

DrCoolZic wrote:OK this new version 0.12 can be used in medium resolution. However this is not an official support for medium resolution because most forms would need to be reworked and the main display is not 100% correct. This is a lot of work (I am not good at GEM!) and it is not high priority ;)
This version support the debug level = 002 flag as described in previous release.

This gives good results :)
medres display looks good and readable ; as you say, a few alignment problems, but completely usable.
All commands are now working on my STF, no more lock, so the problem is really in the "verify disk in drive" function.
Note that the 1st time I started panzer 0.12, I had a crash with 3 bombs before the menu appears ; on other launches, it worked fined. Strange ...

I have made some test under Steem and it seems that the write / sector track do not work for me???
I do not have access to real atari but seems like write command might be broken?
I did not play too much with the program under Steem but it seems that the program does not work unless you use Pasti?
This is strange this means that the low level emulation seems pretty bad in Steem 3.2

I tested write track and write sector on my STF, and it works. I think Steem 3.2 has some limitations, many copy programs don't start with it, some FDC emulation is certainly missing. Maybe steem 3.5 works better, or you could try Hatari 1.6.2 (but FDC emulation doesn't support spin position, so some timings will be bad, better wait for Hatari 1.7).

Nicolas

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

Re: FD Timing Information Tools for emulators

Postby Steven Seagal » Sun Jun 09, 2013 6:51 pm

Of course Steem 3.2 has write track support, but timings are not precise.
Better wait for v3.5.1 (coming soon!)
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 Information Tools for emulators

Postby DrCoolZic » Mon Jun 10, 2013 8:40 am

I have just tested on Steem 3.5.0 and results are very strange without Pasti. Even a simple command to read addresses does not work properly unless you turn on Pasti. Here I am not talking about timing but basic correct behavior of "Read Address" command. Eagerly waiting 3.5.1 to see if it fixes FD problems.
Talking about timing: even in accurate timing option the timing for reading a sector from ST (without pasti) is totally wrong.
Problem with Pasti is that it is read only :(

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 Information Tools for emulators

Postby DrCoolZic » Mon Jun 10, 2013 8:46 am

npomarede wrote:medres display looks good and readable ; as you say, a few alignment problems, but completely usable.
All commands are now working on my STF, no more lock, so the problem is really in the "verify disk in drive" function.
Note that the 1st time I started panzer 0.12, I had a crash with 3 bombs before the menu appears ; on other launches, it worked fined. Strange ...

Later releases will be even slightly better for main/status windows in medres but redoing forms is a pain and they all seems to be usable (even if ugly).

Glad you confirmed what I suspected. I need to think of a better way to test if FD is present or just bypass it for now. Only drawback is that if no FD and command is issued the timeout to get back hand is very long.

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

Re: FD Timing Information Tools for emulators

Postby Steven Seagal » Mon Jun 10, 2013 5:05 pm

DrCoolZic wrote:I have just tested on Steem 3.5.0 and results are very strange without Pasti. Even a simple command to read addresses does not work properly unless you turn on Pasti. Here I am not talking about timing but basic correct behavior of "Read Address" command. Eagerly waiting 3.5.1 to see if it fixes FD problems.
Talking about timing: even in accurate timing option the timing for reading a sector from ST (without pasti) is totally wrong.
Problem with Pasti is that it is read only :(


Problem with 3.5.0 is that I hadn't seen yet that Steem was assuming 8000 bytes/track, all fixes are polluted by that.
I fixed 'read address' in 3.5.1 native, it's not trivial. Notice that ProCopy's 'Analyze' won't work with Pasti either.
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

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

Re: FD Timing Information Tools for emulators

Postby npomarede » Mon Jun 10, 2013 5:17 pm

Steven Seagal wrote:Problem with 3.5.0 is that I hadn't seen yet that Steem was assuming 8000 bytes/track, all fixes are polluted by that.
I fixed 'read address' in 3.5.1 native, it's not trivial. Notice that ProCopy's 'Analyze' won't work with Pasti either.

Are you sure it's 8000 bytes/track, this seems huge to me ; maybe it's just an oversized buffer?
As for Procopy, 'analyze' works in Hatari since 1.6.2, I don't remember what it does, but it's not related to spin or too precise gaps, because these were not 100 % accurate in 1.6.2, but doesn't prevent procopy from working.

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

Re: FD Timing Information Tools for emulators

Postby Steven Seagal » Mon Jun 10, 2013 5:34 pm

npomarede wrote:
Steven Seagal wrote:Problem with 3.5.0 is that I hadn't seen yet that Steem was assuming 8000 bytes/track, all fixes are polluted by that.
I fixed 'read address' in 3.5.1 native, it's not trivial. Notice that ProCopy's 'Analyze' won't work with Pasti either.

Are you sure it's 8000 bytes/track, this seems huge to me ; maybe it's just an oversized buffer?

Very odd, 8000 for speed, normal value (6xxx) for read/write track operation.

As for Procopy, 'analyze' works in Hatari since 1.6.2, I don't remember what it does, but it's not related to spin or too precise gaps, because these were not 100 % accurate in 1.6.2, but doesn't prevent procopy from working.


Sometimes it's just luck. In Steem, it's a 'read address' timing issue + sync with read track timing.
Not sure all timings are right (probably not), but at least this function will work.
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 Information Tools for emulators

Postby DrCoolZic » Fri Jun 14, 2013 4:47 pm

Hello Nicolas,

Here is a new version of Panzer.
FYI Panzer does not use any "system" call to access the HW. It uses a lib that I have developed that address directly the HW. As I said the Panzer project is not fully tested code and I found some problems in the FDLib. I have therefore modified a lot the library and I hope it should fix several minor problems. Now you should be able to use the Panzer program on your STF directly (not need to use the debug switch that I have mentioned). I have also tuned a bit the graphic display in medres so it should look OK (but did not changed the forms).

The version is now 0.20. Can you test it on your STF and let me know if it works for you.
I will soon travel for 3 weeks so if there is a problem let me know quickly.
I have made all the tests on real Atari STe because still lots of commands broken on Steem. I did not try on Hatari is it working better?

I have watchdog to guard execution of all FDC commands so the program should never get stuck :)
For that matter I am "timing" the execution of the commands and breaks if value is over command specific timeouts. For example to execute a seek command with motor off takes about 1100 to 1200 ms and with motor on very short. I do not expect the timing in emulator to be close to the "HW" values as they have no influence on the results. Bu in case you are interested (specially on real HW) you just need to set the debug level to 8 and look in the Panzer.dbg file. You will see the sequence of all FDC instructions and their timings :)

Jean
You do not have the required permissions to view the files attached to this post.

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

Re: FD Timing Information Tools for emulators

Postby npomarede » Sat Jun 15, 2013 9:24 am

DrCoolZic wrote:Hello Nicolas,
The version is now 0.20. Can you test it on your STF and let me know if it works for you.
I will soon travel for 3 weeks so if there is a problem let me know quickly.
I have made all the tests on real Atari STe because still lots of commands broken on Steem. I did not try on Hatari is it working better?

I have watchdog to guard execution of all FDC commands so the program should never get stuck :)
For that matter I am "timing" the execution of the commands and breaks if value is over command specific timeouts. For example to execute a seek command with motor off takes about 1100 to 1200 ms and with motor on very short.

Hello
version 0.20 works on my STF (note that with 0.12, I didn't have to change the debug value to make it works either)
From what I see, the floppy detection is still removed at the moment ? (that's fine with me)

I do not expect the timing in emulator to be close to the "HW" values as they have no influence on the results. Bu in case you are interested (specially on real HW) you just need to set the debug level to 8 and look in the Panzer.dbg file. You will see the sequence of all FDC instructions and their timings :)

Jean

Well, one could think that accurate timings are not required when using MSA/ST images, and that will be true for maybe 99.99% or more of all the disks you will use. But some programs are really expecting exact values because their behaviour depend on the fact that the command should complete in a known delay (for example : decompressing the data on the fly while sectors are loaded, playing a music until the end of the loading, reading sectors in a specific order depending on the delay between the read sectors commands (involves the rotation speed), ...)
Some cracked games also still expect "read address" or "read track" to work, it 's just that the crack will skip the result.
In Hatari for example, you can use "fast disk mode" in nearly all games/demos, but a few of them will not work and you really need to use the accurate values.

Hatari 1.6.2 was already quite accurate on DMA transfer, GAPs and type I commands, Hatari 1.7 improve on type II/III commands by adding index pulse and spin,as well as some small changes in the GAPS.

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 » Sat Jun 15, 2013 7:01 pm

FD detection was not removed in 0.12 unless you turn the debug on.
The way it was done is not stupid but not very useful either.
How do you know you have a floppy in the drive? what I was doing is a recalibrate + seek to a specif track with verify flag on. For this to succeed you need to have a floppy disk inserted that is formatted. Seek verify check that the track number of the first found id matches the track you are seeking. This should work well as I said witha formatted FD but will fail if the F disk is not formatted or use some protection trick.
All the commands have reasonable timeout in the WD command itself doubled by timeout in the way I call the commands and therefore it is not so important to know upfront. If you try to read and you do not have a FD the command will fail. In the last version my FD_ready function is more an FD_reset function as it call a reaclibrate so we start on know territory and set some state variables in the lib.


Social Media

     

Return to “Development”

Who is online

Users browsing this forum: No registered users and 1 guest