search

wwarthen / FAT

RomWBW HBIOS FAT Filesystem Utility
Other
6 stars 2 forks source link

Difficulty with floppy disks #2

Open z80micro-mc opened 5 months ago

z80micro-mc commented 5 months ago

I can move data on an SD card configured as FAT partition and as CP/M slices ok.

However, I am having difficulties with Floppy disks neither 720KB nor 1.44 MB would appear to work.

If I format the disk under FDU and Zeta2 SBC recognises the floppy and can read / write to it under CP/M. However, Windows claims that the disk is unformatted and requires a low level format. The resulting FAT12 floppy is not recognised on Zeta2 under FAT.

Nor will Zeta2 allow me to clrdir4 the Windows formatted floppy and access it from CP/M.

Ideas?

z80micro-mc commented 5 months ago

I have ROMWBW 3.4.1 package ZETA2_STD.ROM loaded.

1.44 MB floppy drive on ZETA2 and external TEAC USB drive (with USB001) on Windows PC.

Peter

wwarthen commented 5 months ago

If I format the disk under FDU and Zeta2 SBC recognises the floppy and can read / write to it under CP/M.

Good, this indicates your hardware is basically working.

However, Windows claims that the disk is unformatted and requires a low level format.

This would be expected. FDU just does a low-level format of the floppy which is sufficient for CP/M. However, Windows requires the FAT filesystem to be initialized on the disk. FDU does not do that, so the disk is not recognized. However, I don't know why Windows wants to do a "low-level" format of the disk. It should just require a regular (filesystem) format.

The resulting FAT12 floppy is not recognised on Zeta2 under FAT.

This is surprising. I assume this disk works under Windows at this point, right? It seems like there is some kind of low-level incompatibility between your Windows floppy hardware and the Zeta 2 floppy hardware. For example, if one of the floppy drives is misaligned or has poor rotation speed accuracy, then a floppy that is low-level formatted on one will not work on the other. This kind of stuff with floppy drives can be ugly.

I suggest you use FDU to format the floppy on the Zeta. Then use "FAT FORMAT" to initialize a FAT filesystem on the floppy using Zeta. Then try reading/writing the floppy using "FAT COPY" on the Zeta. If that all works, then try putting the floppy in your Windows machine to see if it can read it. If not, I strongly suspect a floppy hardware issue on one system or the other.

Nor will Zeta2 allow me to clrdir4 the Windows formatted floppy and access it from CP/M.

CLRDIR should work. Since it does not, this is even more evidence that there is some kind of hardware incompatibility between the floppy drives.

Thanks,

Wayne

z80micro-mc commented 5 months ago

Wayne,

Thanks for the prompt response.

I have made some further progress:

Zeta2 1) Disks formated with FDU and directory cleared with clrdir are useable on Zeta2 under CP/M.

2) Disks formated with FDU followed by FAT Format work on Zeta using FAT to transfer files between CP/M and FAT12.

3) Disks formated under WIN10 on a PC give Bad sector errors on Zeta even after clrdir. They only become useable on Zeta after FDU reformat.

4) Disks formated under WIN10 on a pc, are not recognised by FAT on Zeta.

5) Disks formated with FDU followed by FAT format on Zeta are not recognised by WIN10.

6) My Research Machines Nimbus PC (Dos3.1 on 80186) does not recognise the Zeta disks.

7) Zeta does not recognise Nimbus CP/M 86 1.1 disks.

I have now tried swapping the 1.44 MB drive on the Zeta for a 720 KB drive. I am getting some degree of transferability between the WIN10 PC and zeta, bearing this and your comments in mind I will look to check the drive alignment of the 1.44 MB drive. However, it would be helpful if FDU had a couple of extra functions: a) display motor speed using the index pulse timing and b) seek track to that I can position the heads over a particular track on an alignment disk.

Many thanks for you input.

Peter

------ Original Message ------ From: "Wayne Warthen" @.> To: "wwarthen/FAT" @.> Cc: "z80micro-mc" @.>; "Author" @.> Sent: Sunday, 28 Apr, 24 At 15:13 Subject: Re: [wwarthen/FAT] Difficulty with floppy disks (Issue #2)

If I format the disk under FDU and Zeta2 SBC recognises the floppy and can read / write to it under CP/M. Good, this indicates your hardware is basically working. However, Windows claims that the disk is unformatted and requires a low level format. This would be expected. FDU just does a low-level format of the floppy which is sufficient for CP/M. However, Windows requires the FAT filesystem to be initialized on the disk. FDU does not do that, so the disk is not recognized. However, I don't know why Windows wants to do a "low-level" format of the disk. It should just require a regular (filesystem) format. The resulting FAT12 floppy is not recognised on Zeta2 under FAT. This is surprising. I assume this disk works under Windows at this point, right? It seems like there is some kind of low-level incompatibility between your Windows floppy hardware and the Zeta 2 floppy hardware. For example, if one of the floppy drives is misaligned or has poor rotation speed accuracy, then a floppy that is low-level formatted on one will not work on the other. This kind of stuff with floppy drives can be ugly. I suggest you use FDU to format the floppy on the Zeta. Then use "FAT FORMAT" to initialize a FAT filesystem on the floppy using Zeta. Then try reading/writing the floppy using "FAT COPY" on the Zeta. If that all works, then try putting the floppy in your Windows machine to see if it can read it. If not, I strongly suspect a floppy hardware issue on one system or the other. Nor will Zeta2 allow me to clrdir4 the Windows formatted floppy and access it from CP/M. CLRDIR should work. Since it does not, this is even more evidence that there is some kind of hardware incompatibility between the floppy drives. Thanks, Wayne — Reply to this email directly, view it on GitHub https://github.com/wwarthen/FAT/issues/2#issuecomment-2081497779 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64GRVP3MZNOVCMQPAU3Y7T7YJAVCNFSM6AAAAABG46DEMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGQ4TONZXHE . You are receiving this because you authored the thread.Message ID: @.***>

wwarthen commented 5 months ago

Sounds like you are making progress.

However, it would be helpful if FDU had a couple of extra functions: a) display motor speed using the index pulse timing

This is difficult for an application that runs in a wide variety of different hardware. In order to do index pulse timing, I need a time reference which is different or non-existent on most of the FDU supported systems.

and b) seek track to that I can position the heads over a particular track on an alignment disk.

This can be done now in the "FDC (C)MDS" sub-menu.

FWIW, I am well aware that FDU is very poor user interface. It has just been hard to prioritize working on it.

Thanks,

Wayne

z80micro-mc commented 5 months ago

Wayne,

Further information on RM Nimbus (80186 MSDOS PC running MSDOS3.10 with 720 KB disks)

Now that I can basically read Zeta produced disks at the sector level, I can now look further as to why they are not recognised.

Nimbus has a slightly older form of the MBR (sector 1), it does not contain the media bytes 55 AA at 1fe.

I have attached a pdf comparing the sector 1s.

RM 720KB floppy have 1440 sectors of 512 bytes in MFM and use them as blks 0 - 1439 in CHS (ie T0, H0, S1-9; followed by T0, H1, S1-9; followed by T1, H0, S1-9 ...).

RM CP/M86 v1.1 has: x 128 byte logical sectors 710 KB 128 directory entries 128 entries checked 2 KB alloc blocks 36 logical SPT128 2 Reserved Tracks

Not sure why Zeta CP/M reserves 4 Tracks given that CCP is 2KB, BDOS is 3.5KB, and normally BIOS is ~ 0.5 KB. Why have so many tracks been reserved? Particularly given that it does not appear to be possible to boot of a floppy disk.

I suspect the issue with ZETA <-> Nimbus is probably that neither recognises the others MBR. - Main culprit is probably the lack of the 55 AA at 1fe. My PC is quite happy to interchange DOS FAT12 disks with the RM.

Peter

5680

------ Original Message ------ From: "Wayne Warthen" @.> To: "wwarthen/FAT" @.> Cc: "z80micro-mc" @.>; "Author" @.> Sent: Sunday, 28 Apr, 24 At 15:13 Subject: Re: [wwarthen/FAT] Difficulty with floppy disks (Issue #2)

If I format the disk under FDU and Zeta2 SBC recognises the floppy and can read / write to it under CP/M. Good, this indicates your hardware is basically working. However, Windows claims that the disk is unformatted and requires a low level format. This would be expected. FDU just does a low-level format of the floppy which is sufficient for CP/M. However, Windows requires the FAT filesystem to be initialized on the disk. FDU does not do that, so the disk is not recognized. However, I don't know why Windows wants to do a "low-level" format of the disk. It should just require a regular (filesystem) format. The resulting FAT12 floppy is not recognised on Zeta2 under FAT. This is surprising. I assume this disk works under Windows at this point, right? It seems like there is some kind of low-level incompatibility between your Windows floppy hardware and the Zeta 2 floppy hardware. For example, if one of the floppy drives is misaligned or has poor rotation speed accuracy, then a floppy that is low-level formatted on one will not work on the other. This kind of stuff with floppy drives can be ugly. I suggest you use FDU to format the floppy on the Zeta. Then use "FAT FORMAT" to initialize a FAT filesystem on the floppy using Zeta. Then try reading/writing the floppy using "FAT COPY" on the Zeta. If that all works, then try putting the floppy in your Windows machine to see if it can read it. If not, I strongly suspect a floppy hardware issue on one system or the other. Nor will Zeta2 allow me to clrdir4 the Windows formatted floppy and access it from CP/M. CLRDIR should work. Since it does not, this is even more evidence that there is some kind of hardware incompatibility between the floppy drives. Thanks, Wayne — Reply to this email directly, view it on GitHub https://github.com/wwarthen/FAT/issues/2#issuecomment-2081497779 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64GRVP3MZNOVCMQPAU3Y7T7YJAVCNFSM6AAAAABG46DEMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGQ4TONZXHE . You are receiving this because you authored the thread.Message ID: @.***>

wwarthen commented 5 months ago

Got it. Yes, it is definitely the case that "FAT" is going to expect to see the 0x55 0xAA signature at the end of the MBR. If not, it is not going to like it. An MBR without a signature is a new one on me. I was under the impression that the signature was there on the very first DOS MBR, but you seem to have found evidence to the contrary. The FAT tools use FsFat for all interaction with the FAT filesystem. It is FsFat itself that is expecting the signature. I would prefer not to muck around with that code.

Regarding the RomWBW floppy boot tracks. The following must fit on the boot tracks:

Loader: 1.5K (3 sectors) CCP: 2K (4 sectors) BDOS: 3.5K (7 sectors) CBIOS: 6.5K (13 sectors)

Total: 13.5K (27 sectors)

Since there are 9 sectors per track on a 720K floppy, we need 27/9 tracks which is 3 tracks. However, on a 1440K floppy, a track is 18 sectors and so we need 2 tracks (36 sectors). I chose to use 4 tracks on a 720K floppy to 1) allow for some future CBIOS growth, and 2) to be consistent with the 1440K floppy format. I hope that makes sense.

It is absolutely possible to boot from floppy. Just use SYSCOPY to setup the boot tracks. This is documented in the User Guide.

Thanks,

Wayne

z80micro-mc commented 5 months ago

Hi Wayne,

01FEH 55 AA is known in some systems as 'DOS boot signature' and was supposed to designate that the media was bootable, it came in after DOS 2.0

In previous versions of DOS it did not exist. DOS 2.0 OEM introduced the concept of a BPB at 00BH to allow systems to exchange media with those of other OEMs and was extended with later releases of DOS. At MSDOS 3.2 it became mandatory.

The 1st byte of the FAT which contained the media id - the same as 015H in the boot sector.

I'll have a go at hacking an RM 720KB disk by putting the 55AA DOS boot signature at the end of the boot sector.

Thanks for the clarification of the 4 reserved tracks, on the systems uponn which I have worked in the past the loadable BIOS was very small typically ~ 0.5KB so 1 sector and most of the hardware specific stuff was in the System ROM. RM used RST 38H as an 'EMT fn' instruction. Where the RST was followed by the ROM function to be called, parameters held in various registers.

The RM Z80 CP/M may prove a little more trouble some as RM 8 bit systems treated the 2 sides of a disk as 2 separate logical drives. Though in their original form they only supported 8", 5.25" 40T drives and later 80T drives in either FM (SD) or MFM (DD). Though with a slight mod they can be persuaded to look at a 3.5" 720KB drive as an 80T 5.25" (96TPI) drive.

I'll also take a look at the CP/M86 implementation and see if I can mod it to add support for Zeta CP/M disks.

Peter

------ Original Message ------ From: "Wayne Warthen" @.> To: "wwarthen/FAT" @.> Cc: "z80micro-mc" @.>; "Author" @.> Sent: Tuesday, 30 Apr, 24 At 23:07 Subject: Re: [wwarthen/FAT] Difficulty with floppy disks (Issue #2)

Got it. Yes, it is definitely the case that "FAT" is going to expect to see the 0x55 0xAA signature at the end of the MBR. If not, it is not going to like it. An MBR without a signature is a new one on me. I was under the impression that the signature was there on the very first DOS MBR, but you seem to have found evidence to the contrary. The FAT tools uses FsFat for all interaction with the FAT filesystem. It is FsFat itself that is expecting the signature. I would prefer not to much around with that code. Regarding the RomWBW floppy boot tracks. The following must fit on the boot tracks: Loader: 1.5K (3 sectors) CCP: 2K (4 sectors) BDOS: 3.5K (7 sectors) CBIOS: 6.5K (13 sectors) Total: 13.5K (27 sectors) Since there are 9 sectors per track on a 720K floppy, we need 27/9 tracks which is 3 tracks. However, on a 1440K floppy, a track is 18 sectors and so we need 2 tracks (36 sectors). I chose to use 4 tracks on a 720K floppy to 1) allow for some future CBIOS growth, and 2) to be consistent with the 1440K floppy format. I hope that makes sense. It is absolutely possible to boot from floppy. Just use SYSCOPY to setup the boot tracks. This is documented in the User Guide. Thanks, Wayne — Reply to this email directly, view it on GitHub https://github.com/wwarthen/FAT/issues/2#issuecomment-2087524665 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64F4XSB6M4OE4MCY3XLZAAIZHAVCNFSM6AAAAABG46DEMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBXGUZDINRWGU . You are receiving this because you authored the thread.Message ID: @.***>

wwarthen commented 5 months ago

Hi @z80micro-mc,

01FEH 55 AA is known in some systems as 'DOS boot signature' and was supposed to designate that the media was bootable, it came in after DOS 2.0

In previous versions of DOS it did not exist. DOS 2.0 OEM introduced the concept of a BPB at 00BH to allow systems to exchange media with those of other OEMs and was extended with later releases of DOS. At MSDOS 3.2 it became mandatory.

The 1st byte of the FAT which contained the media id - the same as 015H in the boot sector.

Thank you for clarifying this. Good to know!

I'll have a go at hacking an RM 720KB disk by putting the 55AA DOS boot signature at the end of the boot sector.

OK, good luck!

Thanks for the clarification of the 4 reserved tracks, on the systems uponn which I have worked in the past the loadable BIOS was very small typically ~ 0.5KB so 1 sector and most of the hardware specific stuff was in the System ROM. RM used RST 38H as an 'EMT fn' instruction. Where the RST was followed by the ROM function to be called, parameters held in various registers.

Yeah, admittedly, the RomWBW CBIOS is a little more complex than older CBIOSes. RomWBW does use a similar function dispatching technique where you can use RST 8 to invoke a function.

The RM Z80 CP/M may prove a little more trouble some as RM 8 bit systems treated the 2 sides of a disk as 2 separate logical drives. Though in their original form they only supported 8", 5.25" 40T drives and later 80T drives in either FM (SD) or MFM (DD). Though with a slight mod they can be persuaded to look at a 3.5" 720KB drive as an 80T 5.25" (96TPI) drive.

I'll also take a look at the CP/M86 implementation and see if I can mod it to add support for Zeta CP/M disks.

OK, great.

Thanks, Wayne

z80micro-mc commented 5 months ago

Hi Wayne,

Thanks for all the responses it is most helpful.

Not much further today!

However, looking at the BPB produced by 'FAT format 2:' a few things come forwards:

1) It would appear to use F8 as the media identifier for 720KB disks rather than F9. 2) It would appear to be formatting a floppy as FAT16 and not FAT12. 3) It would appear to be using 1/2 KB clusters ie 1 sector per cluster, I was not aware that was valid. 4) It only creates 1 FAT, DOS disks normally have 2, there are utilities that can reconcile problems with the FAT from the 2nd copy, not that they are very common. I wouldn't have a clue how to generate a single FAT disk using Microsoft tools. 5) It would appear to allow for 512 root directory entries instead of the normal 112 or 224! 6) It would appear to have a funny number of sectors per FAT of 01DF. Normal disks would be 0003 7) It would appear to have 63 sectors per track, and not 0009. 8) It would appear to have 255 sides instead of 2.

Take a look at Starman's article for floppy ofsets. https://thestarman.pcministry.com/asm/mbr/DOS50FDB.htm#BPB

Your thoughts?

Peter

------ Original Message ------ From: "Wayne Warthen" @.> To: "wwarthen/FAT" @.> Cc: "z80micro-mc" @.>; "Mention" @.> Sent: Wednesday, 1 May, 24 At 01:42 Subject: Re: [wwarthen/FAT] Difficulty with floppy disks (Issue #2)

Hi @z80micro-mc https://github.com/z80micro-mc , 01FEH 55 AA is known in some systems as 'DOS boot signature' and was supposed to designate that the media was bootable, it came in after DOS 2.0 In previous versions of DOS it did not exist. DOS 2.0 OEM introduced the concept of a BPB at 00BH to allow systems to exchange media with those of other OEMs and was extended with later releases of DOS. At MSDOS 3.2 it became mandatory. The 1st byte of the FAT which contained the media id - the same as 015H in the boot sector. Thank you for clarifying this. Good to know! I'll have a go at hacking an RM 720KB disk by putting the 55AA DOS boot signature at the end of the boot sector. OK, good luck! Thanks for the clarification of the 4 reserved tracks, on the systems uponn which I have worked in the past the loadable BIOS was very small typically ~ 0.5KB so 1 sector and most of the hardware specific stuff was in the System ROM. RM used RST 38H as an 'EMT fn' instruction. Where the RST was followed by the ROM function to be called, parameters held in various registers. Yeah, admittedly, the RomWBW CBIOS is a little more complex than older CBIOSes. RomWBW does use a similar function dispatching technique where you can use RST 8 to invoke a function. The RM Z80 CP/M may prove a little more trouble some as RM 8 bit systems treated the 2 sides of a disk as 2 separate logical drives. Though in their original form they only supported 8", 5.25" 40T drives and later 80T drives in either FM (SD) or MFM (DD). Though with a slight mod they can be persuaded to look at a 3.5" 720KB drive as an 80T 5.25" (96TPI) drive. I'll also take a look at the CP/M86 implementation and see if I can mod it to add support for Zeta CP/M disks. OK, great. Thanks, Wayne — Reply to this email directly, view it on GitHub https://github.com/wwarthen/FAT/issues/2#issuecomment-2087777379 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64D3IZZQYJK7TG23QJDZAA27LAVCNFSM6AAAAABG46DEMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBXG43TOMZXHE . You are receiving this because you were mentioned.Message ID: @.***>

wwarthen commented 5 months ago

Hi @z80micro-mc,

I had no idea that FAT FORMAT was doing such a poor job with floppy disks. The FAT application utilizes the FatFs library for all access and manipulation of FAT filesystems. It is a widely used library and I am using the latest version of the code available.

The specific function within FatFs being used to format a disk is f_mkfs. I am using the following values for the opt parameter:

Parameter Value
fmt FM_ANY \| FM_SFD
n_fat 1
align 0
n_root 0
au_size 0

I am open to suggestions for changing these parameters, but please keep in mind that FAT FORMAT needs to handle any type and size of media. I do have the ability to pass different parameters for a hard disk vs. a floppy disk.

Thanks,

Wayne

z80micro-mc commented 5 months ago

Hi Wayne,

I have taken a look at a couple of genuine Microsoft 720KB IBM PC & compatible distribution disks, the first is MicroSoft Basic and the second is Microsoft Word v5.

They are as follows:

00B: 00 02 ; 512 bytes / sector as per RM 00D: 02 ; sectors / cluster ( 1KB) as per RM 00E: 01 00 ; 1 reserved sector as per RM 010: 02 ; 2 FATS as per RM 011: 70 00 ; 112 root directory entries as per RM 013: A0 05 ; 1440 sectors as per RM 015: F9 ; F9 media descriptor 720 KB DSDD 9SPT / 1.2 MB as per RM 016: 03 00 ; 3 sectors per FAT as per RM. 018: 09 00 ; 9 SPT as per RM 01A: 02 00 ; 2 sides as per RM 01C: 00 00 00 00 ; 0 hidden sectors as per RM 020: 00 00 00 00 ; 0 partiton sectors as per RM 024: 00 00 ; reserved as per RM 026: 00 ; Extended BPB not implemented

1fe: 55 AA ; DOS boot signature XXX different from RM which is 00 00.

The BASIC disk claims that it is an MSDOS3.3 disk and the WORD 5 that it is an IBM 3.3 disk.

Peter

------ Original Message ------ From: "Wayne Warthen" @.> To: "wwarthen/FAT" @.> Cc: "z80micro-mc" @.>; "Mention" @.> Sent: Wednesday, 1 May, 24 At 18:29 Subject: Re: [wwarthen/FAT] Difficulty with floppy disks (Issue #2)

Hi @z80micro-mc https://github.com/z80micro-mc , I had no idea that FAT FORMAT was doing such a poor job with floppy disks. The FAT application utilizes the FatFs library http://elm-chan.org/fsw/ff/ for all access and manipulation of FAT filesystems. It is a widely used library and I am using the latest version of the code available. The specific function within FatFs being used to format a disk is f_mkfs http://elm-chan.org/fsw/ff/doc/mkfs.html . I am using the following values for the opt parameter: ParameterValuefmtFM_ANY | FM_SFDn_fat1align0n_root0au_size0

I am open to suggestions for changing these parameters, but please keep in mind that FAT FORMAT needs to handle any type and size of media. I do have the ability to pass different parameters for a hard disk vs. a floppy disk. Thanks, Wayne — Reply to this email directly, view it on GitHub https://github.com/wwarthen/FAT/issues/2#issuecomment-2088808608 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64GWLZPX4ZXFKVXW7YTZAERBNAVCNFSM6AAAAABG46DEMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYHAYDQNRQHA . You are receiving this because you were mentioned.Message ID: @.***>

wwarthen commented 5 months ago

Hi @z80micro-mc,

Sorry for the slow reply. I have been trying to wrap my head around some of this information and what I might be able to do to improve FAT FORMAT. There are some things I can improve, but some things are built into the FsFat library and I have no control over them.

One last comment. In an earlier message, you mentioned that you thought FsFat was producing a FAT16 formatted floppy. I have looked at this in detail and do not think this is the case. It is a FAT12 format.

One other piece of information. In my testing, I am finding that Windows has no trouble with the RomWBW formatted floppy. However, MS-DOS 6.22 definitely does not like it. I suspect the biggest issue is the incorrect values for Sides and Sectors per Track.

I propose to change the FAT application to use 2 FAT copies and 224 directory entries. I can also add a warning in the documentation and that formatting FAT floppies is best done on a Windows/DOS machine. Is there anything else you think should be changed (that is possible)?

Thanks,

Wayne

z80micro-mc commented 5 months ago

Wayne,

WOW! You have been busy in your spare time.

I will do some experiments with RM and various parameters.

What does a MSDOS6.22 formated 720 KB disk do under FAT on ROMWBW on your system? You said that dos622 does not like a ROMWBW FAT Formatted 720 KB disk.

The other aspect upon which you did not comment was the use of F8 for the media descriptor (offset 015H in sector 1 and offset 000 in FAT table). I'll try hacking an RM disk to media type F8 and see what happens. As I previously said the Microsoft distribution and an IBM genuine 720K also use F9 for 720 KB disks.

When you have an updated version of FAT I would be happy to test it. I will then also try using FDU to patch the other values (SPT and heads to the correct values).

If you patch the 'FAT type message' from 'FAT ' to 'FAT12 ' to be consistent with the actual format,

though this is only there for information and not actually used by most systems.

I have problems with 720 KB disks under windows. My later systems do not have an internal Floppy and use an external USB Floppy drive. I have 2 of these both CIpotZIZ: a) With TEAC drive and USB UF001F i/f and b) YE-data drive with YE-Data USB i/f neither of which would appear perform a low level format. The TEAC doesn't like the parameters and although the YE would appear to accept the parameters it does not appear to actual perform the lowlevel format. It only seems to do a Quick format on an already formatted disk and writes its own sector 1 and clears the FAT and directory. They will both read / write to a preformatted 720 disk. They will both low level format a 1.44 Mb disk ok.

Neither of these is particularly succesful at formating unformated 720 KB disks though they will both happily read a disk formated on the RM Nimbus and exchange files (though given the standard 720 KB heads vers the 1.44 heads caveats). I can format them on a genuine Alps internal 1.44 drive on a slightly older Win XP system either running XP or MSDOS622. My other system is an RM VX/2 which is basically an AT clone running MSDOS6.22 with 1.2 and 1.44 Mb drives.

Depending upon the results it may be easier to restamp sector 1 with the 'amended values' after format, perhaps as part of FAT FORMAT.

I have ordered another RAW 3.5" 1.44 drive and will see if I get better transferability with this. If I do then it is dig out the Alignment disk and scope and spend sometime recalibrating the drives.

Again many thanks for looking into this.

Peter

------ Original Message ------ From: "Wayne Warthen" @.> To: "wwarthen/FAT" @.> Cc: "z80micro-mc" @.>; "Mention" @.> Sent: Thursday, 2 May, 24 At 23:31 Subject: Re: [wwarthen/FAT] Difficulty with floppy disks (Issue #2)

Hi @z80micro-mc https://github.com/z80micro-mc , Sorry for the slow reply. I have been trying to wrap my head around some of this information and what I might be able to do to improve FAT FORMAT. There are some things I can improve, but some things are built into the FsFat library and I have no control over them.

One last comment. In an earlier message, you mentioned that you thought FsFat was producing a FAT16 formatted floppy. I have looked at this in detail and do not think this is the case. It is a FAT12 format. One other piece of information. In my testing, I am finding that Windows has no trouble with the RomWBW formatted floppy. However, MS-DOS 6.22 definitely does not like it. I suspect the biggest issue is the incorrect values for Sides and Sectors per Track. I propose to change the FAT application to use 2 FAT copies and 224 directory entries. I can also add a warning in the documentation and that formatting FAT floppies is best done on a Windows/DOS machine. Is there anything else you think should be changed (that is possible)? Thanks, Wayne — Reply to this email directly, view it on GitHub https://github.com/wwarthen/FAT/issues/2#issuecomment-2091856414 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64FGJG53COLGJXDLC7TZAK5EDAVCNFSM6AAAAABG46DEMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJRHA2TMNBRGQ . You are receiving this because you were mentioned.Message ID: @.***>

z80micro-mc commented 5 months ago

Wayne,

Further results.

1) Zeta 2 does not like floppy disks formatted under dos, it complains of 'missing address mark' I get this on disks formatted on RM Nimbus or on those from Intel based mother board running MSDOS6.22 and on various distribution disks ( Microsoft and IBM)

2) FAT uses F8 as the media descriptor - this is reserved for hard disks, it should be F9 for a 720KB 3.5" or F0 for 1.44 so would be correct for an SD partition but not for a floppy disk.

Boot sector is used in 3 ways on RM: a) it defines the physical geometry of the disk - used by the firmware rombios, b) determines if the media is bootable or not - needs E9 or EB 1st byte followed by 'RML$' [RM is happy to work with other disks solong as the 1st byte is E9 or EB, c) as used to define the logical disk characteristics for MSDOS.

I have played with various fields - changing the media descriptor away from F9 -> F8 produces media that it recognised and the directory can be listed on a PC but the contents are wrong. Using F9 the Nimbus and the PC are happy to interchange disks.

Hopefully the new drive will be here in a few days.

Your thoughts?

Peter

------ Original Message ------ From: "Wayne Warthen" @.> To: "wwarthen/FAT" @.> Cc: "z80micro-mc" @.>; "Mention" @.> Sent: Thursday, 2 May, 24 At 23:31 Subject: Re: [wwarthen/FAT] Difficulty with floppy disks (Issue #2)

Hi @z80micro-mc https://github.com/z80micro-mc , Sorry for the slow reply. I have been trying to wrap my head around some of this information and what I might be able to do to improve FAT FORMAT. There are some things I can improve, but some things are built into the FsFat library and I have no control over them.

One last comment. In an earlier message, you mentioned that you thought FsFat was producing a FAT16 formatted floppy. I have looked at this in detail and do not think this is the case. It is a FAT12 format. One other piece of information. In my testing, I am finding that Windows has no trouble with the RomWBW formatted floppy. However, MS-DOS 6.22 definitely does not like it. I suspect the biggest issue is the incorrect values for Sides and Sectors per Track. I propose to change the FAT application to use 2 FAT copies and 224 directory entries. I can also add a warning in the documentation and that formatting FAT floppies is best done on a Windows/DOS machine. Is there anything else you think should be changed (that is possible)? Thanks, Wayne — Reply to this email directly, view it on GitHub https://github.com/wwarthen/FAT/issues/2#issuecomment-2091856414 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64FGJG53COLGJXDLC7TZAK5EDAVCNFSM6AAAAABG46DEMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJRHA2TMNBRGQ . You are receiving this because you were mentioned.Message ID: @.***>

wwarthen commented 5 months ago

Hi @z80micro-mc,

What does a MSDOS6.22 formated 720 KB disk do under FAT on ROMWBW on your system? You said that dos622 does not like a ROMWBW FAT Formatted 720 KB disk.

If you format a 720K floppy under MSDOS 6.22, the floppy is handled fine by RomWBW.

The other aspect upon which you did not comment was the use of F8 for the media descriptor (offset 015H in sector 1 and offset 000 in FAT table). I'll try hacking an RM disk to media type F8 and see what happens. As I previously said the Microsoft distribution and an IBM genuine 720K also use F9 for 720 KB disks.

Ah, yes, I forgot about that. I did look into it. The media byte of 0xF8 used by FatFs is definitely wrong for a floppy. 0xF8 indicates a hard disk. The correct value for a floppy seems to be a matter of debate and I have seen multiple values. The current official Microsoft specification suggests 0xF0 for all removable media. 0xF9 is certainly common and reasonable for 720K disks. So, FatFs is doing it wrong, but I have no ability to control it.

When you have an updated version of FAT I would be happy to test it. I will then also try using FDU to patch the other values (SPT and heads to the correct values).

Great, I intend to post an update later today.

If you patch the 'FAT type message' from 'FAT ' to 'FAT12 ' to be consistent with the actual format, though this is only there for information and not actually used by most systems.

Yeah, I have read that it is informational only. This is another field that I have no control over.

I have problems with 720 KB disks under windows. My later systems do not have an internal Floppy and use an external USB Floppy drive. I have 2 of these both CIpotZIZ: a) With TEAC drive and USB UF001F i/f and b) YE-data drive with YE-Data USB i/f neither of which would appear perform a low level format. The TEAC doesn't like the parameters and although the YE would appear to accept the parameters it does not appear to actual perform the lowlevel format. It only seems to do a Quick format on an already formatted disk and writes its own sector 1 and clears the FAT and directory. They will both read / write to a preformatted 720 disk. They will both low level format a 1.44 Mb disk ok.

These USB Floppy drives are known to have problems formatting 720K. It is annoying, but I don't know what to do about it.
I also have a USB Floppy drive attached to my modern Windows 11 system. I picked the brand specifically because someone posted a message that they found it does format 720K floppy disks. And it does. My brand is eSYNiC, but I bought it years ago. It is listed on Amazon, but shows as out of stock.

I should mention that I strongly recommend doing the low-level format of floppies using FDU on your RomWBW system. This is because it will default to using a 2:1 interleave which is much better for older systems. DOS and Windows currently use a 1:1 interleave.

Depending upon the results it may be easier to restamp sector 1 with the 'amended values' after format, perhaps as part of FAT FORMAT.

You are correct, but need to be honest that I am unlikely to get around to doing this. Very few people using FAT FORMAT are using it for floppy disks. Those who are exchanging data via floppy disks are almost always formatting with the DOS / Windows system. Preparing the floppy on the DOS / Windows system makes more sense in general.

I have ordered another RAW 3.5" 1.44 drive and will see if I get better transferability with this. If I do then it is dig out the Alignment disk and scope and spend sometime recalibrating the drives.

OK, I hope this helps.

Thanks, Wayne

wwarthen commented 5 months ago

1) Zeta 2 does not like floppy disks formatted under dos, it complains of 'missing address mark' I get this on disks formatted on RM Nimbus or on those from Intel based mother board running MSDOS6.22 and on various distribution disks ( Microsoft and IBM)

Unfortunately, it sounds like there is a hardware issue of some kind on your Zeta 2. I have multiple Zeta 2 systems with no trouble reading floppy disks created on DOS 6.22 (or distribution disks).

2) FAT uses F8 as the media descriptor - this is reserved for hard disks, it should be F9 for a 720KB 3.5" or F0 for 1.44 so would be correct for an SD partition but not for a floppy disk.

Yes, you are right. Unfortunately, this is not configurable with FatFs.

Boot sector is used in 3 ways on RM: a) it defines the physical geometry of the disk - used by the firmware rombios, b) determines if the media is bootable or not - needs E9 or EB 1st byte followed by 'RML$' [RM is happy to work with other disks solong as the 1st byte is E9 or EB, c) as used to define the logical disk characteristics for MSDOS.

I have played with various fields - changing the media descriptor away from F9 -> F8 produces media that it recognised and the directory can be listed on a PC but the contents are wrong. Using F9 the Nimbus and the PC are happy to interchange disks.

I not terribly surprised. Older systems relied on the media byte. Over time the media byte was deprecated and newer systems mostly ignore it.

Thanks, Wayne

z80micro-mc commented 5 months ago

Hi Wayne,

Given that FDU formatted disks do not appear to have a PC type boot sector, might I correctly presume that ROMWBW, CBIOS, and HBIOS do not make use of the boot sector parameters?

That the only code that is using the PC boot sector parameters is fsFAT?

Peter

------ Original Message ------ From: "Wayne Warthen" @.> To: "wwarthen/FAT" @.> Cc: "z80micro-mc" @.>; "Mention" @.> Sent: Friday, 3 May, 24 At 18:24 Subject: Re: [wwarthen/FAT] Difficulty with floppy disks (Issue #2)

1.  Zeta 2 does not like floppy disks formatted under dos, it

complains of 'missing address mark' I get this on disks formatted on RM Nimbus or on those from Intel based mother board running MSDOS6.22 and on various distribution disks ( Microsoft and IBM)

Unfortunately, it sounds like there is a hardware issue of some kind on your Zeta 2. I have multiple Zeta 2 systems with no trouble reading floppy disks created on DOS 6.22 (or distribution disks).

  1. FAT uses F8 as the media descriptor - this is reserved for hard disks, it should be F9 for a 720KB 3.5" or F0 for 1.44 so would be correct for an SD partition but not for a floppy disk.

Yes, you are right. Unfortunately, this is not configurable with FatFs. Boot sector is used in 3 ways on RM: a) it defines the physical geometry of the disk - used by the firmware rombios, b) determines if the media is bootable or not - needs E9 or EB 1st byte followed by 'RML$' [RM is happy to work with other disks solong as the 1st byte is E9 or EB, c) as used to define the logical disk characteristics for MSDOS. I have played with various fields - changing the media descriptor away from F9 -> F8 produces media that it recognised and the directory can be listed on a PC but the contents are wrong. Using F9 the Nimbus and the PC are happy to interchange disks. I not terribly surprised. Older systems relied on the media byte. Over time the media byte was deprecated and newer systems mostly ignore it. Thanks, Wayne — Reply to this email directly, view it on GitHub https://github.com/wwarthen/FAT/issues/2#issuecomment-2093457979 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64FMAEPIWUU5I7573JTZAPB5JAVCNFSM6AAAAABG46DEMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJTGQ2TOOJXHE . You are receiving this because you were mentioned.Message ID: @.***>

wwarthen commented 5 months ago

I have published FAT Release v1.1 which changes:

It probably won't help you much though because it does not fix:

Thanks, Wayne

wwarthen commented 5 months ago

Given that FDU formatted disks do not appear to have a PC type boot sector, might I correctly presume that ROMWBW, CBIOS, and HBIOS do not make use of the boot sector parameters?

That the only code that is using the PC boot sector parameters is fsFAT?

Correct. In fact, the first sector of a CP/M floppy does not look anything like a PC boot record. Completely different animal.

Thanks, Wayne