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: 1062
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: FD Timing/Protection Information Tools for emulators

Postby npomarede » Sat Jun 15, 2013 7:20 pm

DrCoolZic wrote:FD detection was not removed in 0.12 unless you turn the debug on.

That's strange, I didn't change debug flag, but with 0.12 and 0.20 it worked and I didn't see any lock. Maybe on my STF the function to check disk sometimes works and sometimes fails ? 0.12 definitly worked, while 0.10 was always stuck.
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.

Maybe you can check if a disk is inserted by also reading a track ? Isn't read track supposed to fail with RNF if no disk is present ? (or if it's not formatted)
You can also just do a "read address" on a track ; it should work with protected disk too, as long as the disk has at least 1 sector ; even if the track in the ID field is not the one of the real track, it will work (while seek + verify would not work with a protected disk if track byte is wrong on purpose in the ID field.

BTW, how do you accurately count the number of bytes in a track ? Since the DMA transfers by block of 16, you can't be sure that the last 16 bytes or less are not in the DMA buffer after a read track. Or do you measure the time between 2 index pulses to get an average value of a byte, that you use to get an estimation of the number of byte in the last DMA buffer when the command is complete from the FDC point of view ? Or you do some "read address" to flush the DMA buffer ?

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 8:04 pm

As I said it should have been working even with the first release as they are timeout all over the place???
You suggestion is fine but as I said it is always time to find out that there is no FDisk ...

For your last question I had to double check. Unfortunately it is not possible to know exactly the number of bytes read during the read track. As you mentioned you can have up to 15 bytes stuck in the DMA. If you do an extra command at the end to force an extra DMA transfer you sill do not know how many byte where there before ... Humm interesting if you do 3 read address you know the content of what you are adding and therefore you can infer what was in the DMA buffer before that. I should experiment.
However in most case this is not really important. I only had one case where a protection place an sector index field at the very very end of the track and I was missing few interesting bytes.
So bottom line currently it should always be a multiple of 16 and may miss few bytes.

For timing measurement I add up the measured the time it takes to transfer the 16 bytes chunks (+ I add time for the first block that you cant be measured). The resulting timing is then corrected by the speed of the rotation of the drive. The normal speed in 300 RPM if this is not the case I apply a correction factor (this is done by measuring the timing between two IP). Same process is applied for sector speed.

As mentioned in my "FD programming document" using a timer set to approximately 4µs period in a tight loop in assembly language gives very good precision. I am currently in the process of cross checking my results with measure at the flux level with a Kryoflux device (about 50ns precision!!!). For information "my" timing seems closer to reality that the one from Pasti STX file but I cant be sure on one or two tests ;)

Also probably not that important I will probably improve precision of my read track function by adding few read address commands at the end of the read track commands (excellent idea).
I should probably also document this trick in my doc :mrgreen:

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 » Thu Sep 05, 2013 8:57 pm

I checked Panzer 0.20 in Steem, and it revealed some trouble with Force Interrupt emulation, command $D4 (IRQ on IP) wasn't really implemented. It is used by the program to check rotation speed. Now it will work :)

But there's a problem I can't figure out, maybe not an emulation issue, in Steem, some commands hang in TOS1.00 or 1.02, not with TOS1.04 (STF) or 1.06 (STE). This only happens in monochrome mode, maybe some timers are messed up?
eg: FDC Status
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 » Fri Sep 06, 2013 10:04 am

Steven Seagal wrote:I checked Panzer 0.20 in Steem, and it revealed some trouble with Force Interrupt emulation, command $D4 (IRQ on IP) wasn't really implemented. It is used by the program to check rotation speed. Now it will work :)

But there's a problem I can't figure out, maybe not an emulation issue, in Steem, some commands hang in TOS1.00 or 1.02, not with TOS1.04 (STF) or 1.06 (STE). This only happens in monochrome mode, maybe some timers are messed up?
eg: FDC Status

Thanks for the info. I do not have time to work on it now but I will have a look later.
I have a real Atari STF with TOS 1.04 US I will try the program on it.

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 » Sat Sep 07, 2013 12:09 pm

This seems to be the right thread to ask some questions. :?:

What happens when there's no media in the drive?
Does the motor run?
Can the FDC count index pulses?
Do commands time out or trigger IRQ?
A most interesting case is European Demos on 2 drives when you only inserted disk A and you select a demo on disk B.
There's also the slow booting in TOS.
In the CIA we learned that ST ruled
Steem SSE: http://ataristeven.exxoshost.co.uk/Steem.htm

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 » Sat Sep 07, 2013 3:56 pm

The motor does spin when there's no disk in the drive. I presume that index pulses are produced, because the motor-off condition for the FDC is several index pulses (this is why the motor never stops spinning if you deselect the drive) and it does stop spinning if the disk is ejected before the drive light goes out.

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 » Sat Sep 07, 2013 5:57 pm

IIRC, booting on no disk, the drive would eventually stop too?
Index pulse is normally a hole in the floppy disk itself, so it isn't easy to explain.
Or maybe, as there's no media, the IP are counted very fast, so the FDC doesn't wait 1 second but executes the command almost instantly, and shuts off the motor almost instantly too after IRQ?
On a real ST, this could be checked by reading STR, is IP always set?
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 Sep 09, 2013 7:37 am

Steven Seagal wrote:This seems to be the right thread to ask some questions. :?:

sure I will try my best :wink:

What happens when there's no media in the drive?
Does the motor run?

Yes the LED and motor are turned on

Can the FDC count index pulses?

Of course not! If there is no media there is no index. The index is on the FDisk and is used to "align" correctly tracks

Do commands time out or trigger IRQ?

I think Both :) If you look at the 1772 doc http://info-coach.fr/atari/documents/my ... LG-V11.pdf
In most cases people use the MO flag so that the controller set the MO signal and waits for 6 IP to be detected. It is not clearly indicated what happen if no IP is detected but based on my test the controller time out and trigger an IRQ with the RNF bit set. My guess is that it waits for a bit more than 1.2s (6 * 200 ms).

A most interesting case is European Demos on 2 drives when you only inserted disk A and you select a demo on disk B.

???

There's also the slow booting in TOS.

Not 100% sure but here is what I believe happen (look an my boot sequence diagram http://info-coach.fr/atari/documents/my ... tartup.jpg)
After sometimes the attempt to boot from the floppy (step 15) by issuing a BIOS read sector. This in turn call the low level 1772 read sector command which of course fails. The BIOS performs several attempts to read the first sector and uses the "shoe-shine" technique: after two read faisl the head is moved to another track (usually 5 or 10) and return back to track 0. The idea is that by moving the head back and forth you can eliminate potential dust. If you listen to the drive during boot without media you will here after sometime a strong noise when the head is moved (note that the first thing performed is a FD restore cmd to place the head at track 0).

As I mentioned earlier it is not so easy to find out if a media has been inserted in the drive. One technique is to do a seek to a specific track with the v flag on => in that case the controller verify the track number (see page 19 of my 1772 doc). But this only works on a formatted Fdisk.

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 Sep 09, 2013 8:44 am

Steven Seagal wrote:IIRC, booting on no disk, the drive would eventually stop too?

Yes. For more info look at page 13 of my doc http://info-coach.fr/atari/documents/my ... LG-V10.pdf

Code: Select all

•   You should be careful before deselecting a drive. The FDC will automatically turn off the motor after the 10 index pulse (10 * 200ms) if no command has been received during this period. However the drive needs to be selected in order to the index pulse to be conveyed to the FDC. This implies that you must wait for the motor to stop before deselecting the drive.

Again it is not clear what is the meaning of 10 IP if no media present so I guess that 2s is used.
See also tips in page 28 of same doc
When programming you also need to take care of the flock variable (at $43e) to disable the _flopvbl routine (see page 11 of doc).

Code: Select all

•   Turn off the floppy VBL check routine _flopvbl while using the FDC/DMA by setting the floppy lock variable (flock at $43e) to $FF. This prevents the VBL routine to screw up the transfer by accessing the DMA chip registers periodically. When the transfer is finished you have to reset the flock variable to 0 this will cause the _flopvbl routine to automatically deselect the drive for you once the FDC has shut off the motor.


Index pulse is normally a hole in the floppy disk itself, so it isn't easy to explain.

Yes see http://info-coach.fr/atari/hardware/FD-Hard.php
so no media no IP

Or maybe, as there's no media, the IP are counted very fast, so the FDC doesn't wait 1 second but executes the command almost instantly, and shuts off the motor almost instantly too after IRQ?

No

On a real ST, this could be checked by reading STR, is IP always set?

when controller is set to type I command bit S1 of SR indicates status of IP signal
Not checked but when no media this should always be 0

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 Sep 09, 2013 8:59 am

Steven Seagal wrote:I checked Panzer 0.20 in Steem, and it revealed some trouble with Force Interrupt emulation, command $D4 (IRQ on IP) wasn't really implemented. It is used by the program to check rotation speed. Now it will work :)


Rotation speed is used in several place to "correct" timing information.
Precise timing is measured using timers in MFP 68901. But these values are corrected based on actual rotation speed. Suppose you measure 16420 µs for reading a sector but the RPM of your drive is 305 (ie your drive run a bit fast) the timing is corrected "to a perfect drive" so result is 16151 = 16420 / (305 * 300)

Panzer was working correctly when stx file were used but not with st files probably for that reason. I guess this new version is not yet available? or has the modification been checked in on the repository?

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 Sep 09, 2013 9:24 am

Seems like I have the answer to my last question fix to IP counter has been pushed with rev 127 if I am right 8)
Last edited by DrCoolZic on Mon Sep 09, 2013 12:50 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 » Mon Sep 09, 2013 12:22 pm

I have build Steem Beta 3.5.3 with latest code
I have converted the dsp/dsw files to sln/vcxproj and compiled with Visual Studio 2012 after minor modification

When I run Panzer and I use Analysis->"Rotation time" command I still get 0 µs for rotation time
This is when I mount in drive A a freshly formatted FD using .st image.
By the way I was looking at the FD drive display now available in Steem : quite nice turning red when writing. Why 1 and 2 for side instead of the more classic 0 and 1?

So question is: did you fix the int pb when .st image are used?

Update: Hum quite strange :?:
When I did the above test I did not place the pasti.dll in the Steem directory and this resulted in mentioned problem
If I add the pasti.dll and only mount a .st file in drive A I still get the same result.
But if I mount a .stx file in drive B and rerun the test on DRIVE A it now works ?????
Even better if I unmount the .stx file from drive B the results for drive A are still good?
Now other stupid test: I unmount both drives and I run the test the program returns random results sometimes a value around 200000µs and sometimes 0 µs ???

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 » Mon Sep 09, 2013 7:09 pm

@DrCoolZic
Thx for your answers, I'll meditate on this.

Some indications:

- Except when the code changes have no real effect, commits are soon followed by a beta build.
I just uploaded one now because those builds are quite buggy (he he):

https://sourceforge.net/projects/steems ... SE%20Beta/?
[r129] beta bugfix shifter trick line +2

- The fix for rotation check was first added here: [r124] some FDC fixes

- There's a slow (accurate) disk mode option in the disk manager. All fixes depend on this option being selected. In the source it's called ADAT.
When it is selected OSD disk info gives sector, if not, only drive, side & track.

- About side 0/1 or 1/2, I don't know what's best. It's meant for the player, not for the programmer.
I also hesitate about track. In ProCopy track 0 is called 1, I'm not sure in other programs.

- There's a new option 'Pasti only for STX' in the SSE option page. If it isn't checked, Pasti may work with MSA and ST images. It's still a bit experimental.

- When a STX or IPF image is mounted, accurate disk mode switches on, or some STX images wouldn't work with option 'Pasti only for STX' checked, maybe this confused you.

This is a screenshot from here:

http://ataristeven.t15.org/Steem_35_com ... htm#Panzer

Image
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 Sep 11, 2013 4:00 pm

New version of Panzer 0.21
Major change is on the GUI. This version now officially support medium resolution. All resources have been reworked and code has been modified so information is now displayed with reasonable font size in medium res.

Nicholas if you are still around try it and let me know.
Next step is to work on functionality and tests
Still weird behavior on Steem
How does it work in Hatari?
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/Protection Information Tools for emulators

Postby Steven Seagal » Wed Sep 11, 2013 7:49 pm

DrCoolZic wrote:Still weird behavior on Steem


Please be more specific. Right now I only looked at and fixed rotation speed check, or isn't it fixed?
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/Protection Information Tools for emulators

Postby npomarede » Wed Sep 11, 2013 10:19 pm

DrCoolZic wrote:New version of Panzer 0.21
Major change is on the GUI. This version now officially support medium resolution. All resources have been reworked and code has been modified so information is now displayed with reasonable font size in medium res.

Nicholas if you are still around try it and let me know.
Next step is to work on functionality and tests
Still weird behavior on Steem
How does it work in Hatari?

Hello
thanks for updating panzer.
I tested 0.21 in Hatari, UI seems OK in med res. There's a small 'error' in build predef track, G2=10 for 10 sectors, but you said earlier it was fixed to be G2=12 (same value as for 9 sectors per track).
All commands are working under Hatari 1.7, the only missing one is the one to measure RPM (I didn't have time to fix it in time for 1.7, but I'm adding the missing part to the devel version of Hatari, so it will be ok for next release).

'track details' seems very slow to me : it reads the track, but when you click in the right scrollbar to move one page down for example, it takes several seconds to display the next bytes and I don't see why it takes so long ? Is this a problem with GEM which is too slow or something else ?

I will try to test version 0.21 on my STF later and will report how it works.

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

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 » Thu Sep 12, 2013 12:25 pm

npomarede wrote:I tested 0.21 in Hatari, UI seems OK in med res. There's a small 'error' in build predef track, G2=10 for 10 sectors, but you said earlier it was fixed to be G2=12 (same value as for 9 sectors per track).

You are correct for 10*512 sector I have modified G2 to 12 as you requested. What is incorrect is the value displayed in the GEM form. To support med res I had to redo most of the forms in the rsc file. In middle of the work I have completely corrupted the resource (I am pretty bad with Atari graphics :( ) file I have restarted from scratch with the original 0.1 rsc file !!!! I forgot to change the value in this specific form. Next version will correct the display but the value used to fill the buffer is correctly set to 12 ... :)
Actually attached is the corrected rsc :)

All commands are working under Hatari 1.7, the only missing one is the one to measure RPM (I didn't have time to fix it in time for 1.7, but I'm adding the missing part to the devel version of Hatari, so it will be ok for next release).

The routine to get the rot time is the following: I am using Timer A to measure timing. I send the 0xD4 (interupt on next index) command to the FDC and inside a loop I poll the FDC status looking FDC_IP bit (bit 2). On the first one I store the value of the timer and on the next one I compute the elapsed time in the timer and send int terminate 0xD0. In other word I measure the time between two IPs.

'track details' seems very slow to me : it reads the track, but when you click in the right scrollbar to move one page down for example, it takes several seconds to display the next bytes and I don't see why it takes so long ? Is this a problem with GEM which is too slow or something else ?

I do not remember all the details but I agree it is terribly slow. It is a problem of optimization, normally you compute the GEM stuff for what need to be displayed only and ignore the rest (something like this ;) ) but for the smart track detail somehow I need to recompute everything (again I do not remember the details) and it is slow. I might look at a way to improve the perf but for the time I recommand you just do not use :oops:

I will try to test version 0.21 on my STF later and will report how it works.

thanks

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

Yes interesting. I am working on a new version of my FDC programming doc and will include your information.

I am still thinking at your question regarding the read track command (adding extra read address command to flush the buffer). Problem is to make it work all the time. On a normal track should be easy but with some protections the very last bytes placed on the track are an address block (so address is before IP and data are after IP) and this might be confusing ...

Jean

PS I need to get latest Hatari and do some tests :mrgreen:
You do not have the required permissions to view the files attached to this post.
Last edited by DrCoolZic on Thu Sep 12, 2013 12:31 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 » Thu Sep 12, 2013 12:30 pm

Steven Seagal wrote:
DrCoolZic wrote:Still weird behavior on Steem


Please be more specific. Right now I only looked at and fixed rotation speed check, or isn't it fixed?

As I already mentioned if you run the test after mounting a regular .st file it does not work. You have to mount either an .stx (or I think an .ipf) file for the test to work.
I need to perform more test and report

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 Sep 12, 2013 1:14 pm

Nicolas

I have just downloaded Hatari 1.7.0. I had not play with the program for quite some time and seems pretty good :)

Effectively the timings are not working because of the problem with the rot time. What I will do is to add a flag so we can get timing even if the rot time is zero. As already mentioned the rot time is used to correct values returned by timing the read sector/track to a perfect 300 RPM drive.
While this might make sense on real Atari it probably mean nothing on an emulator (I would expect the value to be 300 on an emulator).

I also wanted to test the med resolution of Panzer but unfortunately Hatari crash before I can get there :(
I mount a GEMDOS drive, starts in low res, swhitch to mid res. The system reboot in med res drives are displayed and boom the screen get filled with garbage, the emulator reboot to a screen where I have lost the hard drive (disk c is gone and i have a cartridge with atari.tos inside)?

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 » Thu Sep 12, 2013 1:24 pm

DrCoolZic wrote:Nicolas

I have just downloaded Hatari 1.7.0. I had not play with the program for quite some time and seems pretty good :)

Effectively the timings are not working because of the problem with the rot time. What I will do is to add a flag so we can get timing even if the rot time is zero. As already mentioned the rot time is used to correct values returned by timing the read sector/track to a perfect 300 RPM drive.
While this might make sense on real Atari it probably mean nothing on an emulator (I would expect the value to be 300 on an emulator).

Next version will have a configurable RPM value of 300 and disk transfer speed will take the RPM into account as a real STF would.
I also wanted to test the med resolution of Panzer but unfortunately Hatari crash before I can get there :(
I mount a GEMDOS drive, starts in low res, swhitch to mid res. The system reboot in med res drives are displayed and boom the screen get filled with garbage, the emulator reboot to a screen where I have lost the hard drive (disk c is gone and i have a cartridge with atari.tos inside)?

That's strange, never saw this. Be sure to not use the falcon version of hatari 1.7, it has some remaining bug for STF/STE ; use STF mode and 68000 cpu. What TOS are you using ? Does it crash if you do the same without mounting a gemdos drive ? Maybe there's an 'auto' folder in your drive ? Could you test with Hatari 1.6 to see if it's a regression or not ?

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 » Thu Sep 12, 2013 2:52 pm

Nicolas
I found the problem. Actually it was a bit difficult because there was a combination of two problems :)

The first problem is that I have a program in AUTO called CLOCKY.PRG. This program display the clock in the menu bar and I think (not sure) it also take care of year 2000 pb on Atari.
When this program is present at boot time the Hatari emulator does not use correctly the med resolution info saved in DESKTOP.INF.
Therefore I had to switch from low res to med res (even though I had save med red on the desktop).

And here comes the second problem that causes Hatari to crash. I have xcontrol.acc on the root directory and a CPX directory that contains several accessories. One of then is called CLOCK_E.CPX. It allows to set the clock to year 2013 ... When this accessory is present changing from mid to low res is OK but changing from low to mid crashes the emulation (not the emulator)

You will find attached all the programs I have talked about (PS they all work fine on a real Atari and on Steem).

Steven
If you read this message. question: it seems that Steem do not use the DESKTOP.INF information to remember in which resolution to start? So if you define to use mid res and save the desktop when you restart Steem it comes in low res. Is this a known bug? Or might be related to the above problems? Thanks

EDIT: Strange now it seems to work. I need to investigate more????
EDIT EDIT 13 Sept: In fact the problem is related to Steem not executing the programs in AUTO folder when a blank disk is present in the A drive see viewtopic.php?f=94&t=25093&p=237838#p237838
You do not have the required permissions to view the files attached to this post.
Last edited by DrCoolZic on Fri Sep 13, 2013 9:40 am, edited 3 times in total.

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 » Thu Sep 12, 2013 2:58 pm

DrCoolZic wrote:Nicolas
I found the problem. Actually it was a bit difficult because there was a combination of two problems :)

The first problem is that I have a program in AUTO called CLOCKY.PRG. This program display the clock in the menu bar and I think (not sure) it also take care of year 2000 pb on Atari.
When this program is present at boot time the Hatari emulator does not use correctly the med resolution info saved in DESKTOP.INF.
Therefore I had to switch from low res to med res (even though I had save med red on the desktop).

And here comes the second problem that causes Hatari to crash. I have xcontrol.acc on the root directory and a CPX directory that contains several accessories. One of then is called CLOCK_E.CPX. It allows to set the clock to year 2013 ... When this accessory is present changing from mid to low res is OK but changing from low to mid crashes the emulation (not the emulator)

You will find attached all the programs I have talked about (PS they all work fine on a real Atari and on Steem).

Steven
If you read this message. question: it seems that Steem do not use the DESKTOP.INF information to remember in which resolution to start? So if you define to use mid res and save the desktop when you restart Steem it comes in low res. Is this a known bug? Or might be related to the above problems? Thanks


I will try to reproduce this ; but what TOS did you use ? Some TOS are known to be bugged (even on real ST) and doesn't correctly restore the resolution from desktop.inf, so this is not an emulation issue in Hatari or Steem.

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 » Thu Sep 12, 2013 3:11 pm

Nicolas,

I was using tos162fr.img with STE emulation
I switched to tos104fr.img with ST emulation and same problem.

By the way I also tested on Hatari 1.3.1 and 1.6.0 and same problem.

I usually use 162 in emulator because this is what I have on my real STE (and 104 for my ST). I also have a 106 system but this version has bug :(
I also have a 206 ROM but not yet installed :(

By the way just to be sure I have described correctly: If I remove CLOCKY.PRG from AUTO folder the Hatari emulation boot in the correct resolution
You do not have the required permissions to view the files attached to this post.
Last edited by DrCoolZic on Thu Sep 12, 2013 8:25 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 » Thu Sep 12, 2013 5:45 pm

I have created a new version of Panzer 0.22 that ignore the correction factor if rotation time is zero.
This is obviously only usefull for current emulation problem but it is quite interesting

I have run this version of the program on Hatari 1.7.0 and it gives pretty good timing results for sector and track timing analysis (see attached pictures)
So you must be doing pretty good emulation of DMA timing.

Also attached the new version of the program with also the corrected resource file

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).
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/Protection Information Tools for emulators

Postby DrCoolZic » Fri Sep 13, 2013 9:36 am

Nicolas this is strange I am running some more test this morning an now I have the following error when I start un RGB mode (works fine in monochrome)
I did not have this error yesterday but I did not change anything ???
You do not have the required permissions to view the files attached to this post.


Social Media

     

Return to “Development”

Who is online

Users browsing this forum: No registered users and 2 guests