Trouble using FloImg or FdRawCmd

WinSTon, Nostalgia, MSA Converter, FloImg, Makedisk and all the others.

Moderators: Mug UK, Moderator Team

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Trouble using FloImg or FdRawCmd

Postby leonard » Wed Sep 20, 2006 9:10 am

Hi all,

Few days ago I discover floimg and fdrawcmd.sys, great tools ! Today I tryed to "image" an atari original disk (my "flipo demo"). Classic disk, 80 trakcs, 10 sectors, 2 sides). I get some errors with floimg:

when I try to analyse the disk, I get an error saying the bootsector is not readable. Don't care, I setup myself the disk geometry in floimg (80tracks,10sectors,2sides), then run "floppy to image". The disk is reading each tracks. but displaying "RNF error". After some seconds, the 80 tracks are read. when looking to the file image "test.st", it's very strange. It seems some sectors are not read. Worst, the first sector (boot sector) start at offset $400 ! (instead of 0).

did you get such strange things? I can post the "test.img" if anyone want.
Leonard/OXYGENE.

ppera

Postby ppera » Wed Sep 20, 2006 12:20 pm

RNF means that sector is not found - floppy damaged.
In such case program reads nothing, and dumps random data to output file (actually just what is in buffer at moment).
You may look in log file which sectors where not read (RNF) or read with errors (CRC), there is calculated logical sector # too, for easier finding location which holds not valid data.

Btw. I expected from programmer to know what RNF means... :D

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Sep 20, 2006 1:28 pm

I expected from programmer to know what RNF means


oh yes don't worry I know what it means. What I don't enderstand is that my original DD floppy is working on ATARI (humm, don't tryed it since a while). But the log reports *so* much error that it couldn't be possible. (I'm sure the disk is working on real atari drive).

Any idea?? Tomorrow I'll try with several atari disks... I'm sure there is an issue with the driver, or my PC floppy controller?

PS: I attached the log, there is "tons" of error. My disk can't contains so much errors (at least one per track !!)
You do not have the required permissions to view the files attached to this post.
Leonard/OXYGENE.

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Sep 20, 2006 1:29 pm

After reading the log I'm pretty sure there is a strange issue in the driver or the PC floppy controller. Looks carefully what sectors get an RNF error: it's always the same pattern:

1,9,7,5,3,
1,9,7,5,3,
1,9,7,5,3,
etc..

Don't you see a problem?
Leonard/OXYGENE.

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Sep 20, 2006 1:40 pm

all append as the PC disk controller miss a sector every 8 sectors. It miss the first one (sector1), and then read 7 next sectors correctly, then miss the next one, then reads correctly the next 7, etc...
which gives the strange pattern 1,9,7,5,3,1,9,7,5,3,etc... for sector RNF error.

Simon (author of FdRawCmd.sys), do you have an idea?
Leonard/OXYGENE.

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Postby obo » Wed Sep 20, 2006 2:54 pm

It reminds me a lot of the problem where disks are formatted gap4a at the start of the track being too small. That first sector on the track then begins inside the index hole area, and due to a PC controller quirk it can't see/read it. The WD1772 controller in the ST is much more relaxed about the values, and doesn't suffer from this problem.

If you combine that with using sector numbers skewed between tracks, you'd probably get exactly the pattern of missing sectors you're seeing. Is that possible?

A few retro systems (including the TRS-80) wrote disks in that way, and they are a problem for the standard PC controller to access. One solution is to use a special cable (http://home.planet.nl/~srahman/trs80hw1.htm) to suppress alternate index pulses, which prevents the controller from being blinded during alternate index pulses. Another solution is to use a 2-drive method like Disk2FDI, which bypasses the controller detection and decoding, so it can see them.

I'll email you a diagnostic program to help determine the disk layout, which should confirm whether that's the problem...

Si
Last edited by obo on Wed Sep 20, 2006 3:45 pm, edited 1 time in total.

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Sep 20, 2006 3:22 pm

Hi Owen !

Well, that disk is my own demo. I don't use special format etc. I often used "fastcopy pro" on ST to format my disk, so that one is probably formatted wxith Fastcopy. One hint: I used fastcopy to format because I noticed floppy formated with fastcopy were "faster" (I mean, reading sectors were faster). Few years ago Ijor explain me the reason: fastcopy pro use a dummy sector header to speed up the first sector decoding when changing track. Maybe it could explain why almost every ST floppy are w<orking on pc and maybe Fastcopy formatted are not?

Here is the scan log, made on the 20 first tracks of the disk, with the program you send me by mail:

Both sides, 20 tracks:
warning: this disk may not be 100% PC compatible!
250Kbps MFM, 512 bytes/sector:
0:0 2 3 4 5 6 7 8 9 10
1:0 8 9 10 1 2 3 4 5 6
2:0 4 5 6 7 8 9 10 1 2
3:0 10 1 2 3 4 5 6 7 8
4:0 6 7 8 9 10 1 2 3 4
5:0 2 3 4 5 6 7 8 9 10
6:0 8 9 10 1 2 3 4 5 6
7:0 4 5 6 7 8 9 10 1 2
8:0 10 1 2 3 4 5 6 7 8
9:0 6 7 8 9 10 1 2 3 4
10:0 2 3 4 5 6 7 8 9 10
11:0 8 9 10 1 2 3 4 5 6
12:0 4 5 6 7 8 9 10 1 2
13:0 10 1 2 3 4 5 6 7 8
14:0 6 7 8 9 10 1 2 3 4
15:0 2 3 4 5 6 7 8 9 10
16:0 8 9 10 1 2 3 4 5 6
17:0 4 5 6 7 8 9 10 1 2
18:0 10 1 2 3 4 5 6 7 8
19:0 6 7 8 9 10 1 2 3 4
250Kbps MFM, 512 bytes/sector:
0:1 10 1 2 3 4 5 6 7 8
1:1 6 7 8 9 10 1 2 3 4
2:1 2 3 4 5 6 7 8 9 10
3:1 8 9 10 1 2 3 4 5 6
4:1 4 5 6 7 8 9 10 1 2
5:1 10 1 2 3 4 5 6 7 8
6:1 6 7 8 9 10 1 2 3 4
7:1 2 3 4 5 6 7 8 9 10
8:1 8 9 10 1 2 3 4 5 6
9:1 4 5 6 7 8 9 10 1 2
10:1 10 1 2 3 4 5 6 7 8
11:1 6 7 8 9 10 1 2 3 4
12:1 2 3 4 5 6 7 8 9 10
13:1 8 9 10 1 2 3 4 5 6
14:1 4 5 6 7 8 9 10 1 2
15:1 10 1 2 3 4 5 6 7 8
16:1 6 7 8 9 10 1 2 3 4
17:1 2 3 4 5 6 7 8 9 10
18:1 8 9 10 1 2 3 4 5 6
19:1 4 5 6 7 8 9 10 1 2


Any idea? Do you think these disk can't be read on PC at all?
Leonard/OXYGENE.

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Re: Trouble using FloImg or FdRawCmd

Postby obo » Wed Sep 20, 2006 3:23 pm

leonard wrote:when I try to analyse the disk, I get an error saying the bootsector is not readable.

That would also match with the index hole problem, as sector 1 will usually be the first sector on track 0, and therefore hidden from the PC controller. floimg reports the error and falls back on standard geometry values, and when it performs the copy it finds 1 sector per track is missing.

A simple solution would be to format a new 80-track disk using floimg, which is guaranteed to be PC compatible. Then go to your ST and sector-copy the problem disk on to that newly formatted disk. Then use floimg to transfer the new copy to the PC.

I'm pretty sure normal ST disks aren't formatted with a small gap4a, so I can only guess your game disk was custom-formatted by something else?

Si

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Sep 20, 2006 3:27 pm

it's not a game, it's my own demo disk. But as I said (we post at the same time), I often formatted my disk with "fastcopy pro". But many atari users formatted there disk with fastcopy pro.
Leonard/OXYGENE.

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Postby obo » Wed Sep 20, 2006 3:35 pm

leonard wrote:One hint: I used fastcopy to format because I noticed floppy formated with fastcopy were "faster" (I mean, reading sectors were faster).

It sounds like this program is causing the problem, by using a small gap4a.

The extra speed isn't part of the problem, but is gained by skewing the sector numbers between tracks. If you offset the sector numbers by 1 or more, the head can be stepped to the next track and be almost ready to read sector 1. With normal disks the sector numbers are all the same, and it wastes almost a full revolution (200ms) waiting for sector 1 to come around again.

Your fastcopy disks are skewed by 4 sectors, but you could probably speed it up even more by reducing this to 2 or even 1 sector. Perhaps Pera could add an skew option to his program, so you can do this on the PC too?

Here is the scan log, made on the 20 first tracks of the disk, with the program you send me by mail:

Both sides, 20 tracks:
warning: this disk may not be 100% PC compatible!
250Kbps MFM, 512 bytes/sector:
0:0 2 3 4 5 6 7 8 9 10
1:0 8 9 10 1 2 3 4 5 6

This shows that sector 1 is missing from the first track, sector 7 from the next track, etc. The warning message at the top is also displayed if the position of the first visible sector indicates that a sector could be hidden by this controller problem.

There aren't any timing details in the log, so you probably missed the /a flag from the command-line. Would it be possible to repeat the scan with the /a flag? Thanks!

Any idea? Do you think these disk can't be read on PC at all?

The only PC solutions are using that special cable, using a Disk2FDI 2-drive method to access it, or using a CatWeasel controller card. Since you have access to a real ST, the easiest method is to copy the problem disks to known safe disks on the ST, then create images of the copies.

Si
Last edited by obo on Wed Sep 20, 2006 3:45 pm, edited 1 time in total.

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Postby obo » Wed Sep 20, 2006 3:42 pm

leonard wrote:But many atari users formatted there disk with fastcopy pro.

Unfortunately, the disks it formats use gap4a sizes below the sizes in the IBM System 34 specification, which causes problems with PC floppy controllers. 11-sector ST disks cause even more problems, because other gaps are reduced to values that the WD1772 can _just_ handle, but the PC controller rejects.

It's a shame, because increasing the gap4a size doesn't have to reduce the storage capacity of the track. There's no problem with overlapping the end of a sector into the index area at the start of the track, it's only a problem when sectors begin in this area.

Si

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Sep 20, 2006 3:47 pm

I just retreived the great Ijor explain about the "fast" floppy mode with fastcopy formatted disk:

http://www.atari-forum.com/viewtopic.php?t=6454&postdays=0&postorder=asc&start=60

Yes. This is because TOS performs seeks with a &#8220;Seek with Verify&#8221; FDC command. When the FDC performs this command it first does the actual physical seek, then it tries to find a sector header (just a header, it doesn&#8217;t look for the sector data) with a matching track number. Then TOS issues the actual sector read command to the FDC.

So the sequence of events is: The head is positioned on the right track. A sector header is read. And lastly the desired sector is read.

In a standard formatted disk this will have the following effect: The FDC would need to &#8220;wait&#8221;, at least, for a full sector between reading the header (by the Seek with verify) and the sector. This is because every header is followed by a full sector. And this is assuming the sectors are smartly skewed/twisted across tracks. Otherwise, as it is the case of a TOS or DOS formatted disk, the wait would be almost a full revolution.

But with the additional extra header inserted by custom formatters the &#8220;wait&#8221; is much smaller. This is because the first sector comes right after the extra header. In other words, the first sector on the track is found right away after performing the Seek with Verify.


For the timing problem, yes I missed the /a option. Here is the complete log:

Code: Select all

Both sides, 20 tracks:   
warning: this disk may not be 100 PC compatible!
250Kbps MFM, 512 bytes/sector:
  0:0   2 3 4 5 6 7 8 9 10
         6249: 625 602 600 602 603 603 602 601 601
  1:0   8 9 10 1 2 3 4 5 6
         6249: 625 601 600 605 600 601 604 601 601
  2:0   4 5 6 7 8 9 10 1 2
         6248: 626 602 601 604 601 602 603 601 601
  3:0   10 1 2 3 4 5 6 7 8
         6248: 627 601 601 605 600 600 603 601 602
  4:0   6 7 8 9 10 1 2 3 4
         6249: 628 601 601 606 599 601 603 602 602
  5:0   2 3 4 5 6 7 8 9 10
         6248: 627 602 600 602 602 602 602 603 601
  6:0   8 9 10 1 2 3 4 5 6
         6249: 628 600 600 603 602 602 603 602 601
  7:0   4 5 6 7 8 9 10 1 2
         6248: 626 601 600 602 603 601 602 602 602
  8:0   10 1 2 3 4 5 6 7 8
         6250: 625 602 601 601 603 602 601 602 602
  9:0   6 7 8 9 10 1 2 3 4
         6248: 627 601 601 602 603 601 602 602 602
 10:0   2 3 4 5 6 7 8 9 10
         6249: 627 601 601 602 603 602 602 602 603
 11:0   8 9 10 1 2 3 4 5 6
         6248: 628 601 601 602 603 601 602 603 602
 12:0   4 5 6 7 8 9 10 1 2
         6248: 628 601 601 602 602 602 602 602 603
 13:0   10 1 2 3 4 5 6 7 8
         6249: 628 601 601 602 604 600 602 602 602
 14:0   6 7 8 9 10 1 2 3 4
         6249: 628 601 602 601 602 602 602 602 602
 15:0   2 3 4 5 6 7 8 9 10
         6249: 628 601 602 601 603 602 602 602 602
 16:0   8 9 10 1 2 3 4 5 6
         6250: 625 602 602 601 603 601 601 603 602
 17:0   4 5 6 7 8 9 10 1 2
         6250: 626 602 602 602 603 601 601 603 602
 18:0   10 1 2 3 4 5 6 7 8
         6249: 626 601 602 601 603 601 601 604 602
 19:0   6 7 8 9 10 1 2 3 4
         6249: 625 601 602 601 604 601 601 605 602
250Kbps MFM, 512 bytes/sector:
  0:1   10 1 2 3 4 5 6 7 8
         6249: 626 602 600 603 602 602 603 601 601
  1:1   6 7 8 9 10 1 2 3 4
         6247: 628 601 599 606 600 600 605 600 601
  2:1   2 3 4 5 6 7 8 9 10
         6248: 628 601 601 605 600 601 604 601 602
  3:1   8 9 10 1 2 3 4 5 6
         6248: 630 602 601 606 601 600 603 601 602
  4:1   4 5 6 7 8 9 10 1 2
         6249: 630 602 600 605 601 601 603 602 602
  5:1   10 1 2 3 4 5 6 7 8
         6248: 630 602 600 602 602 602 603 602 601
  6:1   6 7 8 9 10 1 2 3 4
         6249: 631 601 600 602 602 602 603 602 602
  7:1   2 3 4 5 6 7 8 9 10
         6249: 629 601 601 602 603 602 602 604 601
  8:1   8 9 10 1 2 3 4 5 6
         6249: 628 601 601 602 604 601 601 602 602
  9:1   4 5 6 7 8 9 10 1 2
         6249: 629 601 601 602 603 602 602 602 603
 10:1   10 1 2 3 4 5 6 7 8
         6249: 629 601 601 602 603 602 602 603 603
 11:1   6 7 8 9 10 1 2 3 4
         6248: 631 601 601 602 602 602 602 602 603
 12:1   2 3 4 5 6 7 8 9 10
         6250: 630 602 602 602 603 601 602 603 602
 13:1   8 9 10 1 2 3 4 5 6
         6249: 631 601 602 601 603 602 602 602 603
 14:1   4 5 6 7 8 9 10 1 2
         6248: 631 601 601 602 603 601 602 602 602
 15:1   10 1 2 3 4 5 6 7 8
         6248: 631 600 601 601 603 602 602 602 602
 16:1   6 7 8 9 10 1 2 3 4
         6248: 626 601 602 601 603 601 602 603 603
 17:1   2 3 4 5 6 7 8 9 10
         6248: 626 601 602 601 603 600 601 603 602
 18:1   8 9 10 1 2 3 4 5 6
         6249: 626 601 602 601 603 601 601 604 603
 19:1   4 5 6 7 8 9 10 1 2
         6249: 625 602 602 601 604 601 601 605 602


Are you really telling me that fastcopy formated disk are not reliable? oh my god I'm not lucky, almost all my disk are fastcopy-pro formatted...

I had in mind to add FdCmdRaw native support in SainT, so you can boot real demo disk on your PC !!! But if it does not work with my disk, I think I will suffer of a lack of motivation :-)
Leonard/OXYGENE.

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Sep 20, 2006 3:53 pm

I though about one thing. The interlaced sector number is not the problem. Ijor explain the trick and I guess maybe your routine could read it. First of all, did FdRawCmd perform a "read track" or a "read sector"?

Fastocpy pro just use a dummy sector header, so the "seek and verify" command could get the right track number in the sector header field. Then, follow another sector header (the right one), then the first sector data.

If you're doing a read-track, and then "search" sectors inside the track data, maybe your routine is confused by the dupplication of a sector header for the first sector of each track?
Leonard/OXYGENE.

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby unseenmenace » Wed Sep 20, 2006 3:58 pm

Have you tried a different floppy drive on your PC?
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Sep 20, 2006 4:03 pm

Have you tried a different floppy drive on your PC?


no... unfortunatly I only have one floppy drive.

Could someone do the test: if he succeed to read floppys with fdrawcmd (or floimg), can he (she :-)) format a new disk on real atari with fastcopy pro and try to image it?

If it fail we'll pretty sure problem came from fastcopy and not the disk.
Leonard/OXYGENE.

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Postby obo » Wed Sep 20, 2006 4:06 pm

leonard wrote:

Code: Select all

Both sides, 20 tracks:   
warning: this disk may not be 100 PC compatible!
250Kbps MFM, 512 bytes/sector:
  0:0   2 3 4 5 6 7 8 9 10
         6249: 625 602 600 602 603 603 602 601 601

Thanks for the updated log. The extra values show the byte length of the track, and the byte gaps between each sector.

The first visible sector begins approximately 625 bytes from the index hole, and subsequent sectors are spaced 602 bytes apart (that includes the 512 bytes of data and all gaps).

We know that the real first sector is missing, and the 625 bytes is suspiciously large for the first visible sector. Subtracting a normal (for this disk) 602 byte gap from the 625 bytes indicates the gap4a value is around 23 bytes in size. A normal PC disk uses a gap4a of around 160 bytes, and it'll probably need to be at least 40-60 bytes for the first sector to be visible.

Are you really telling me that fastcopy formated disk are not reliable? oh my god I'm not lucky, almost all my disk are fastcopy-pro formatted...

I'm afraid so - they're ST-compatible, but not 100% PC-compatible :(

I had in mind to add FdCmdRaw native support in SainT, so you can boot real demo disk on your PC !!! But if it does not work with my disk, I think I will suffer of a lack of motivation :-)

Heh, I think I'd feel the same in your position! I don't remember reading many disk transfer problems that sound like this, so I guess most people aren't affected? They'd all benefit from a nice read-disk feature :wink:

Of course, these disks will be a problem for any PC program that uses the normal floppy controller, not just floimg/fdrawcmd. Transferring them is a one-time thing too, and if there's anything unique on them you might want to do it sooner rather than later!

Si

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Postby obo » Wed Sep 20, 2006 4:12 pm

unseenmenace wrote:Have you tried a different floppy drive on your PC?

I'm 99.99% sure it wouldn't help, as the results are too consistent with a known limitation of the PC floppy controller.

The drive itself is quite a simple piece of hardware, and it's the controller that does all the magic for interpreting the bit stream. Similar to the long-running saga about reading Amiga disks on the PC - the drive isn't the problem, it's the controller that doesn't recognise the disk format (thankfully, Vincent found a hardware quirk to trick it into exposing enough information to do it using Disk2FDI).

Si

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Sep 20, 2006 4:19 pm

Obo, could you change your program to "dump" the complete track (about 6250 bytes as the log report) ? Don't you think the data of the first sector is reliable using "read-track" command?
If you can send me a special version I can test it. (a version wich output the complete track into a hex dump listing).
Leonard/OXYGENE.

ppera

Postby ppera » Wed Sep 20, 2006 4:44 pm

Interesting is it with Fastcopy Pro. I will dig out it and check, but probably next week only.

About reading speed on Atari ST:

For floppies with 10 sec/tr skew of 2 is reqired - TOS is simple too slow to catch first sector if skew is 1. It is not big difference in speed, btw.

For HD floppies skew of 4 is needed from same reason.


fdrawcmd of course reads sectorwise, not trackwise - it is only way.
Even on Atari must read sectorwise 'own' floppies.

Probably it will not read on PC - some tricks work only on specific HW.

I was able to read all my floppies well - but they are pretty 'conservative' formatted - 10 or 20 sec/tr, standard gaps.

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Postby obo » Wed Sep 20, 2006 4:44 pm

leonard wrote:could you change your program to "dump" the complete track (about 6250 bytes as the log report) ? Don't you think the data of the first sector is reliable using "read-track" command?

The PC controller doesn't have a true raw "read track" command like the WD1772 has. It does have a "read track" command, but that simply reads the contents of the data fields from each sector in the order they are found on the track - it works like a special multi-sector read, without doing any matching on sector numbers.

It's not actually possible to read all the gap information using standard PC controller commands. My program uses repeated read-id commands to detect the cyl/head/sector/size values in the ID header, and notes the time each was found to build a picture of where the sectors are on each track.

I have a disk affected by the index problem at home, so I'll double-check that the PC's dumb read-track can't see the problem sectors. I'm fairly sure I've tested it already, but it wouldn't hurt to try again!

The Disk2FDI method could be used to read the disks in a system with 2 floppy drives, but that wouldn't be very practical for real-disk access in an emulator. It might still help you transfer your disks, but it'd take a little more time to add support for it to my program.

Si

obo
Atari freak
Atari freak
Posts: 51
Joined: Mon Nov 10, 2003 12:38 am
Location: Nottingham, UK

Postby obo » Wed Sep 20, 2006 4:51 pm

ppera wrote:For floppies with 10 sec/tr skew of 2 is reqired - TOS is simple too slow to catch first sector if skew is 1. It is not big difference in speed, btw.

Is that still true if you reduce the gap3 size between sectors? With 10-sector SAM Coupé disks I only skew by 1 sector, with a gap3 of 23 bytes between sectors. The smaller gap means there is more time between the end of sector 10 on the current track, and the start of the skewed sector 1 on the next track. Both the SAM and PC are able to read the disk at maximum speed, taking not much over 30 seconds.

Agreed that it doesn't make a huge difference overall, adding a few seconds to the time for a full disk transfer...

Si

ppera

Postby ppera » Wed Sep 20, 2006 5:30 pm

obo wrote:Is that still true if you reduce the gap3 size between sectors? ...
Agreed that it doesn't make a huge difference overall, adding a few seconds to the time for a full disk transfer...


Didn't try it - from phylosophical reasons :D

Floppies are already unreliable, why then forcing things to get couple % speed or 10 % capacity (hyperformat - after half year none of those floppies was readable without errors) .

ijor
Hardware Guru
Hardware Guru
Posts: 3898
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Wed Sep 20, 2006 8:30 pm

obo wrote:It reminds me a lot of the problem where disks are formatted gap4a at the start of the track being too small. That first sector on the track then begins inside the index hole area, and due to a PC controller quirk it can't see/read it...

The only PC solutions are using that special cable, using a Disk2FDI 2-drive method to access it, or using a CatWeasel controller card...


All my PCs can read those disks, using a standard PC controller, without any problems.

My program uses repeated read-id commands to detect the cyl/head/sector/size values in the ID header,


This is the problem. Add a config option to read sectors blindly, or some other similar solution. The PC controller can read that sector. The problem is using the Read Id command.

ijor
Hardware Guru
Hardware Guru
Posts: 3898
Joined: Sat May 29, 2004 7:52 pm
Contact:

Postby ijor » Wed Sep 20, 2006 8:41 pm

leonard wrote:Obo, could you change your program to "dump" the complete track (about 6250 bytes as the log report) ?


Hi Leonard,

Do you actually want to image that disk, or you were just testing the software?

For the purposes of imaging the disk, try the old school solution: Boot Win 9X or pure DOS and use makedisk or your favorite old imaging tool.

obo wrote:
unseenmenace wrote:Have you tried a different floppy drive on your PC?

I'm 99.99% sure it wouldn't help, as the results are too consistent with a known limitation of the PC floppy controller.


Actually, it might help. Each drive has a different index aligment. Using a different drive might make the first header appear later/earlier and then your software might work.

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Sep 20, 2006 8:42 pm

All my PCs can read those disks, using a standard PC controller, without any problems.


Hey ijor ! always here to solve floppy tricks :-)

could you explain a bit more your method? I'm not familiar with Pc controller (I though there were a "read track" command but it seems not?)

obo, if there is a method to improve your great FdRawCmd driver and read my demo disk in real time, I will definitivly add the feature to SainT !

Ijor, we all are waiting for your explain ! :-)
Leonard/OXYGENE.


Social Media

     

Return to “Other emulators & tools”

Who is online

Users browsing this forum: No registered users and 5 guests