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 ). 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

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.

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

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

Nicolas

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

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 RAMI 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 12Can you please confirm.

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

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 RAMI 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 12Can you please confirm.

I just return from trip today but will not have too much time to do testsTo 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.

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 releaseNote that in that case you can use the "build track" commandThanks for feedback

HelloI 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 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.

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

You were asking about debug information while using Panzer. This is already available Start Panzer. Got to Options->advance and in debug level enter 252The 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

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

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 252The 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.

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 002if 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.

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.

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

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).

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

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.

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.

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.

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.

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.

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.

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.

Helloversion 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.

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.