PC-DOS 1.10 and PCem v12

Support and general discussion.
User avatar
omarsis81
Posts: 945
Joined: Thu 17 Dec, 2015 6:20 pm

Re: PC-DOS 1.10 and PCem v12

Post by omarsis81 »

There is no /1 in ver 1.0 because the ONLY disk supported was 160kb
1.10 introduced double sided 320kb and therefore /1
User avatar
mal.sh
Posts: 32
Joined: Wed 08 Jun, 2016 6:12 pm

Re: PC-DOS 1.10 and PCem v12

Post by mal.sh »

omarsis81 wrote:There is no /1 in ver 1.0 because the ONLY disk supported was 160kb
1.10 introduced double sided 320kb and therefore /1
Yes, but Shadower said above that he had IBM-PC DOS 1.00 and used FORMAT command with /1 option. ))
User avatar
omarsis81
Posts: 945
Joined: Thu 17 Dec, 2015 6:20 pm

Re: PC-DOS 1.10 and PCem v12

Post by omarsis81 »

mal.sh wrote:
omarsis81 wrote:There is no /1 in ver 1.0 because the ONLY disk supported was 160kb
1.10 introduced double sided 320kb and therefore /1
Yes, but Shadower said above that he had IBM-PC DOS 1.00 and used FORMAT command with /1 option. ))
I bet it would have worked if you write /1 /64 or whatever
User avatar
mal.sh
Posts: 32
Joined: Wed 08 Jun, 2016 6:12 pm

Re: PC-DOS 1.10 and PCem v12

Post by mal.sh »

omarsis81 wrote:
mal.sh wrote:
omarsis81 wrote:There is no /1 in ver 1.0 because the ONLY disk supported was 160kb
1.10 introduced double sided 320kb and therefore /1
Yes, but Shadower said above that he had IBM-PC DOS 1.00 and used FORMAT command with /1 option. ))
I bet it would have worked if you write /1 /64 or whatever
Done. I've checked it via Hampa "PCE - PC Emulator" and it works with any options.
User avatar
Shadower
Posts: 3
Joined: Sat 18 Mar, 2017 9:26 pm

Re: PC-DOS 1.10 and PCem v12

Post by Shadower »

mal.sh wrote:
Shadower wrote:Hi mal.sh:
Not so expert here speaking... but like you I am looking for the "perfect" emulator.
Just as you did I made a copy of the PC DOS 1.00 original disk image, inserted it in B: and formatted it to 160kB with FORMAT of PC DOS 1.00. Everything worked! Have you tried with 1.00 or only with 1.10?
PC DOS 1.00 seems to work... what do you think?
Thanks for testing PC-DOS v1.00, but I tried only 1.10 version.

What was your PCEm's configuration for that test?
I used a "clean" minimal configuration of IBM PC 5150 allowed by the PCem:

CPU 8088 4.77MHz;
64kB memory (I would rather 16kB, but PCem do not allow);
(I would like a CASSETTE INTERFACE (PCem NOT SUPPORTED???);
2 Floppies 5 1/4 360 kB each (The allowed by PCem);
No HDs;
No CD-ROM;
CGA = Color Graphics Monitor Adapter (SlowVLB/PCI);
No SoundCard;
No JOYSTICK (Joystick1 and 2 = None);
Mouse Microsoft 2-button mouse (serial);
PRINTER?
SERIAL?
KEYBOARD?;
User avatar
Shadower
Posts: 3
Joined: Sat 18 Mar, 2017 9:26 pm

Re: PC-DOS 1.10 and PCem v12

Post by Shadower »

mal.sh wrote:
omarsis81 wrote:
mal.sh wrote:
Yes, but Shadower said above that he had IBM-PC DOS 1.00 and used FORMAT command with /1 option. ))
I bet it would have worked if you write /1 /64 or whatever
Done. I've checked it via Hampa "PCE - PC Emulator" and it works with any options.
That is correct. Probably the parser of FORMAT clean the line after it!. It works with anything. I add /1 but it is not necessary. I rechecked too.
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: PC-DOS 1.10 and PCem v12

Post by Battler »

omarsis81 wrote:Then, why I succeeded formatting a single sided disk in a 320/360 kb using the /1 parameter?
Because a 320/360 kB image has the second side, therefore when FORMAT attempts to format it, it succeeds.

This is a bug in PC DOS 1.10 FORMAT.COM. The one from 1.00 works fine.
User avatar
omarsis81
Posts: 945
Joined: Thu 17 Dec, 2015 6:20 pm

Re: PC-DOS 1.10 and PCem v12

Post by omarsis81 »

Battler wrote:
omarsis81 wrote:Then, why I succeeded formatting a single sided disk in a 320/360 kb using the /1 parameter?
Because a 320/360 kB image has the second side, therefore when FORMAT attempts to format it, it succeeds.

This is a bug in PC DOS 1.10 FORMAT.COM. The one from 1.00 works fine.
No, I what I did was formatting (in 1.10) a 320/360 image in a 360 drive. Please see the last screenshot posted.
With no additional parameters: ie. FORMAT B: results in a successfully formatted 320 KB disk, with the /1 parameter you get a 160 KB disk.
If it were as you suggest a 320kb image would always format a disk with both sides yielding 320kb, and that's not the case.
/1 in PC-DOS 1.10's FORMAT.COM works fine
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: PC-DOS 1.10 and PCem v12

Post by Battler »

omarsis81 wrote:If it were as you suggest a 320kb image would always format a disk with both sides yielding 320kb, and that's not the case.
First, I don't suggest, I posted solid evidence in the form of an exact FDC command the PC DOS 1.10 FORMAT.COM issues when used with the /1 option, it clearly attempts to format the second side.
Second, nothing prevents there from being 1 side written in the BPB of the boot sector, even though both are physically formatted. Such a disk would still be a valid, DOS would just ignore the other side.
User avatar
mal.sh
Posts: 32
Joined: Wed 08 Jun, 2016 6:12 pm

Re: PC-DOS 1.10 and PCem v12

Post by mal.sh »

Battler wrote:
omarsis81 wrote:If it were as you suggest a 320kb image would always format a disk with both sides yielding 320kb, and that's not the case.
First, I don't suggest, I posted solid evidence in the form of an exact FDC command the PC DOS 1.10 FORMAT.COM issues when used with the /1 option, it clearly attempts to format the second side.
Second, nothing prevents there from being 1 side written in the BPB of the boot sector, even though both are physically formatted. Such a disk would still be a valid, DOS would just ignore the other side.
Ok. PC-DOS 1.10 FORMAT.COM works wrong and PCEm v12.0 FDC's right. :mrgreen:

But I remind about some other evidences:

1) It works fine on PCjs Machines emulator;
2) It works fine on Hampa PCE/ibmpc emulator.

I was assured that it will be checked on original IBM PC 5150. And then I'll put final result here.
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: PC-DOS 1.10 and PCem v12

Post by Battler »

- mal.sh: I posted solid evidence from my logging of what FORMAT.COM sends to the FDC. Other emulators not showing the problem means nothing - in fact PCem also had no problems with it had worse floppy emulation.

Now, however, I am not saying there is no bug in the emulator. I have no idea what happens on a real FDC and floppy drive, if you attempt to format the other side of a single-sided disk. It might actually work.

Edit: In fact, I suspect the FDC FORMAT command, when issued on side 2, would proceed correctly anyway, but the drive would simply spin through the disk failing to write anything, though the FDC wouldn't know about it at all.

Edit #2: Verified now : Indeed, if the FDC FORMAT command is made to just ask for sector ID's and spin the disk but not write anything when a non-existent side is being formatted, PC DOS 1.10 FORMAT.COM works fine. I suspect this is the behavior of real hardware, too.
vbdasc
Posts: 37
Joined: Tue 21 Mar, 2017 10:53 am

Re: PC-DOS 1.10 and PCem v12

Post by vbdasc »

omarsis81 wrote:With no additional parameters: ie. FORMAT B: results in a successfully formatted 320 KB disk, with the /1 parameter you get a 160 KB disk.
But the log of FDC commands posted by Battler definitely indicate that there were issued commands to format at least some tracks on the second side... Just for the record, can you test again FORMAT B: /1 on a 320KB image? It would be interesting to know:

1. Whether after the format the image size is still 320KB.
2. And if it is, then how many bytes of the image get overwritten by FORMAT? To check this, you can start with 320K zeroes in the image, and compare the pre-formatted and post-formatted images with the DOS command FC /B .
User avatar
omarsis81
Posts: 945
Joined: Thu 17 Dec, 2015 6:20 pm

Re: PC-DOS 1.10 and PCem v12

Post by omarsis81 »

vbdasc wrote:
omarsis81 wrote:With no additional parameters: ie. FORMAT B: results in a successfully formatted 320 KB disk, with the /1 parameter you get a 160 KB disk.
But the log of FDC commands posted by Battler definitely indicate that there were issued commands to format at least some tracks on the second side... Just for the record, can you test again FORMAT B: /1 on a 320KB image? It would be interesting to know:

1. Whether after the format the image size is still 320KB.
2. And if it is, then how many bytes of the image get overwritten by FORMAT? To check this, you can start with 320K zeroes in the image, and compare the pre-formatted and post-formatted images with the DOS command FC /B .
The image remains at 320kb
vbdasc
Posts: 37
Joined: Tue 21 Mar, 2017 10:53 am

Re: PC-DOS 1.10 and PCem v12

Post by vbdasc »

omarsis81 wrote:
vbdasc wrote:
omarsis81 wrote:With no additional parameters: ie. FORMAT B: results in a successfully formatted 320 KB disk, with the /1 parameter you get a 160 KB disk.
But the log of FDC commands posted by Battler definitely indicate that there were issued commands to format at least some tracks on the second side... Just for the record, can you test again FORMAT B: /1 on a 320KB image? It would be interesting to know:

1. Whether after the format the image size is still 320KB.
2. And if it is, then how many bytes of the image get overwritten by FORMAT? To check this, you can start with 320K zeroes in the image, and compare the pre-formatted and post-formatted images with the DOS command FC /B .
The image remains at 320kb
Very well, thanks. But are all of these 320KB overwritten or only the half?
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: PC-DOS 1.10 and PCem v12

Post by SarahWalker »

Most likely writes to the second side will just be ignored on a real machine, as long as nothing tries to read them back. PCem does try to prevent you from formatting a .img file to a different size (as it's not really supported by the format), but it sounds like that's going wrong here.
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: PC-DOS 1.10 and PCem v12

Post by Battler »

I did say that above.
Edit #2: Verified now : Indeed, if the FDC FORMAT command is made to just ask for sector ID's and spin the disk but not write anything when a non-existent side is being formatted, PC DOS 1.10 FORMAT.COM works fine. I suspect this is the behavior of real hardware, too.
User avatar
omarsis81
Posts: 945
Joined: Thu 17 Dec, 2015 6:20 pm

Re: PC-DOS 1.10 and PCem v12

Post by omarsis81 »

If I'm not misunderstanding the original issue, it is not the behavior of the second side.

The problem arose when placing a 160kb disk (image) on a 360kb drive and issuing the FORMAT (with no parameters, just FORMAT B:) command under IBM PC DOS 1.10.

It gives an error on PCem, while I *guess* it should work on a real 5150.
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: PC-DOS 1.10 and PCem v12

Post by Battler »

- omarsis81: Please learn to read and pay attention. When formatting an 160k disk with PC DOS 1.10 FORMAT.COM, it still attempts to format the second side. On real hardware, this will go through without errors even on a single-sided floppy (the written bytes will just not be written anywhere pretty much since there's no magnetic surface on the other side), but the emulator will incorrectly abort the FDC FORMAT command with error when it's called on the other side with an inserted 160k image.
User avatar
omarsis81
Posts: 945
Joined: Thu 17 Dec, 2015 6:20 pm

Re: PC-DOS 1.10 and PCem v12

Post by omarsis81 »

Battler wrote:- omarsis81: Please learn to read and pay attention. When formatting an 160k disk with PC DOS 1.10 FORMAT.COM, it still attempts to format the second side. On real hardware, this will go through without errors even on a single-sided floppy (the written bytes will just not be written anywhere pretty much since there's no magnetic surface on the other side), but the emulator will incorrectly abort the FDC FORMAT command with error when it's called on the other side with an inserted 160k image.
Alrighty! Crystal clear now :)
vbdasc
Posts: 37
Joined: Tue 21 Mar, 2017 10:53 am

Re: PC-DOS 1.10 and PCem v12

Post by vbdasc »

Battler wrote:On real hardware, this will go through without errors even on a single-sided floppy (the written bytes will just not be written anywhere pretty much since there's no magnetic surface on the other side)
IMHO, this is wrong. Apparently, the one-sided 5.25 inch diskettes are identical to the two-sided ones, with the only difference that their second side is not tested by the manufacturer and may exhibit defects. But they surely have magnetic coating on both sides and even have working track 0 if they are to work correctly under DOS, as I will explain later in another post. There are multiple links about this over the internet; If this was not true, then the so called "flippy" disks wouldn't exist.
vbdasc
Posts: 37
Joined: Tue 21 Mar, 2017 10:53 am

Re: PC-DOS 1.10 and PCem v12

Post by vbdasc »

I think I might have some idea what is going on, on both real hardware and PC-em v12. Of course, it's only my own theory, so it can or can't be correct :)

The manual for PCDOS v1.1 says that FORMAT (without /1 , at least) checks if the drive and/or diskette are double sided. If both are, then the diskette is formatted as 320K, if either the drive or the diskette is single-sided, then 160K are formatted. But how does FORMAT perform these checks? As I wrote above, the single-sided and double-sided diskettes are usually indistinguishable (without looking at the label, that is). Likewise, the single-sided and double-sided drives are very similar. The only difference I could think about is that in single-sided drives, the HEAD SELECT signal from the controller is left unconnected, and as a consequence all disk accesses intended for the second side actually execute on the first one.

Having all this in mind, I think that the most logical thing FORMAT could do to perform this check is as follows:

1. Issue FORMAT TRACK on BOTH sides on cylinder 0;
2. Write something on the (Cylinder 0, Head 0, Sector 1); write something different on (C0, H1, S1);
3. If either write fails, abort with error "Track 0 bad";
4. Read (C0, H0, S1) and compare with what was written there in Step 2 to determine if the drive is double-sided;

After the check, FORMAT takes the existence of /1 parameter into consideration and proceeds to write the logical format accordingly.

Now we see that, as Battler said, FORMAT v1.1 is indeed buggy:

The bug is that the /1 parameter is checked AFTER the check for the single/double side, while the more logical thing would be to check it BEFORE; as a consequence the (very rare) single-sided disks that have no working track 0 on the second side are unformattable and unusable in double-sided drives under PC-DOS v1.1 .

However, this bug is very unlikely to be observed, for as I've said, such diskettes are VERY RARE. Thus, IBM were unable to notice it.

Everything I wrote above is for the real hardware case; In PC-em v12 the difference is perhaps that the aforementioned VERY RARE scenario becomes common and easily observed (the 160K image simulates exactly that).

P.S. Therefore, the easiest way to work around this bug as a PC-em user is to convert the floppy images from 160K to 320K/360K before using them :)

P.P.S. It would be interesting to check with later versions of DOS (PC-DOS v2.0 for example) if this bug was noticed and fixed.
User avatar
mal.sh
Posts: 32
Joined: Wed 08 Jun, 2016 6:12 pm

Re: PC-DOS 1.10 and PCem v12

Post by mal.sh »

vbdasc wrote: ...

Having all this in mind, I think that the most logical thing FORMAT could do to perform this check is as follows:

1. Issue FORMAT TRACK on BOTH sides on cylinder 0;
2. Write something on the (Cylinder 0, Head 0, Sector 1); write something different on (C0, H1, S1);
3. If either write fails, abort with error "Track 0 bad";
4. Read (C0, H0, S1) and compare with what was written there in Step 2 to determine if the drive is double-sided;

After the check, FORMAT takes the existence of /1 parameter into consideration and proceeds to write the logical format accordingly.

...
Good. But your theory can be proved only via disassembling the IBM PC-DOS 1.10 FORMAT.COM
vbdasc wrote: P.S. Therefore, the easiest way to work around this bug as a PC-em user is to convert the floppy images from 160K to 320K/360K before using them :)
What tool do you recommend for that?
And I want to remind that 160 KB floppy images works fine with IBM PC-DOS 1.10 FORMAT.com on PCEm v10.1
P.P.S. It would be interesting to check with later versions of DOS (PC-DOS v2.0 for example) if this bug was noticed and fixed.
I'll check that.
vbdasc
Posts: 37
Joined: Tue 21 Mar, 2017 10:53 am

Re: PC-DOS 1.10 and PCem v12

Post by vbdasc »

mal.sh wrote: Good. But your theory can be proved only via disassembling the IBM PC-DOS 1.10 FORMAT.COM
It could be additionally confirmed (or debunked) if Battler posts a log of all FDC commands accessing the second side, not only one as he did :) Or if omarsis81 tells us just how much of his 320KB image file gets overwritten :)
mal.sh wrote: What tool do you recommend for that?
Something homebrewn. Years ago, I wrote such a tool, which helped me to use 160K/180K/320K images under VirtualPC, but unfortunately I lost it. It should the very easy and quick to write, though.
User avatar
omarsis81
Posts: 945
Joined: Thu 17 Dec, 2015 6:20 pm

Re: PC-DOS 1.10 and PCem v12

Post by omarsis81 »

http://www.winimage.com/

The best tool for floppy image management
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: PC-DOS 1.10 and PCem v12

Post by Battler »

mal.sh wrote:And I want to remind that 160 KB floppy images works fine with IBM PC-DOS 1.10 FORMAT.com on PCEm v10.1
And as the one who worked on the floppy code together with Sarah Walker for PCem v11, I told why that is. In PCem v10 and v10.1, the FDC FORMAT command was barely implemented, and did not sanity checks on the parameters being passed to it. That was corrected for v11, but now the sanity checks seem to be too strict.

- vbdasc: I know that when it errored on Track 0, it attempted to format Side 1 of Track 0 three times from what I recall, before failing with error, and it did not try to format Side 0 at all. And as I said, after making the FDC FORMAT command on a non-existent side a NOP that just asks for sector ID's but writes nothing, FORMAT.COM no longer errors, which makes it clear it only attempts the FDC FORMAT command on Side 1, and not also the FDC WRITE DATA command (which would fail with error because of being unable to find a sector ID).
P.P.S. It would be interesting to check with later versions of DOS (PC-DOS v2.0 for example) if this bug was noticed and fixed.
It was fixed in PC DOS 2.0 but that introduced a different bug in that it always executes the FDC FORMAT command with 9 sectors per track even when formatting 160/320 kB and writing the correct values to the BPB. This is perfectly valid on a real drive as DOS (and possibly also other OS'es) will only care about the sector per track count written in the BPB and not about how many sectors there actually are on the track, but it causes PC DOS 2.0 FORMAT.COM to fail to format an inserted 160/320 kB image due to the emulated FDC FORMAT command doing a sanity check on the sector count. PC DOS 3.0 fixes that and correctly formats 160/320 kB floppies by passing 8 sectors per track to the FDC FORMAT command.
User avatar
JohnElliott
Posts: 113
Joined: Sun 31 Jan, 2016 7:29 pm

Re: PC-DOS 1.10 and PCem v12

Post by JohnElliott »

mal.sh wrote: Good. But your theory can be proved only via disassembling the IBM PC-DOS 1.10 FORMAT.COM
I have disassembled the PC-DOS 1.10 FORMAT.COM. Anyone who wants the IDA database, drop me a line.

The program's divided very clearly into two modules: the first 2k are the machine-independent bit, dealing with parsing options and transferring the system file, and the remainder is the machine-specific part that actually does the formatting. In the latter part...

Code: Select all

seg000:0A10 loc_0_A10:                              ; CODE XREF: format_do+15↑▒
seg000:0A10                 mov     byte_0_CDF, 1	;Head
seg000:0A15                 mov     byte_0_CDE, 0	;Cylinder
seg000:0A1A                 mov     byte_0_CE1, 0	;Format failed indicator
seg000:0A1F                 mov     byte_0_CE3, 0FFh	;Media ID
seg000:0A24                 mov     byte_0_CE4, 9	;Sectors for boot sector+FATs+root directory
seg000:0A2A                 test    byte_0_976, 2      ; Single-sided?           
seg000:0A30                 jz      loc_0_A3D
seg000:0A32                 mov     byte_0_CE3, 0FEh
seg000:0A37                 mov     byte_0_CE4, 6                          
seg000:0A3D loc_0_A3D:                              
seg000:0A3D                 mov     dx, offset asc_0_C49	;"Formatting..."
seg000:0A40                 call    sub_0_C41	;Print string
The formatter then formats cylinder 0 head 1, followed by cylinder 0 head 0.

Code: Select all

seg000:0A5C loc_0_A5C:
seg000:0A5C                 mov     dh, byte_0_CDF	;Head
seg000:0A60                 mov     ch, 0			;Cylinder
seg000:0A62                 call    sub_0_AEC		;Format the track
seg000:0A65                 jnb     loc_0_A78		;Format was successful
seg000:0A67                 call    sub_0_B12		;If disc was readonly, abort
seg000:0A6A                 cmp     byte_0_CE2, 0	;Out of retries?
seg000:0A6F                 jnz     loc_0_A5C
seg000:0A71                 mov     byte_0_CE0, 1	;Format failed
seg000:0A76                 clc 
seg000:0A77                 retn
seg000:0A78 loc_0_A78:                    
seg000:0A78                 mov     byte_0_CE2, 3	;Retries back up to 3                                
seg000:0A7D                 dec     byte_0_CDF		;Decrement head                                 
seg000:0A81                 jz      loc_0_A5C		;If it is now 0, format cyl 0 head 0                              
seg000:0A83                 inc     byte_0_CDF                               
It then verifies both these tracks. If it can't verify head 1, it switches to the single-sided format:

Code: Select all

seg000:0A8C loc_0_A8C: 
seg000:0A8C                 mov     dh, byte_0_CDF	;Head
seg000:0A90                 mov     ch, 0			;Cylinder
seg000:0A92                 call    sub_0_B09		;Verify track
seg000:0A95                 jnb     loc_0_ABA		;Verify OK
seg000:0A97                 call    sub_0_B12		;If error was 'read only', abort
seg000:0A9A                 cmp     byte_0_CE2, 0	;Retry count
seg000:0A9F                 jnz     loc_0_A8C
seg000:0AA1                 cmp     byte_0_CDF, 0	;Cylinder 0 head 0 unusable?
seg000:0AA6                 jnz     loc_0_AAF           
seg000:0AA8                 mov     byte_0_CE1, 1	;Format failed
seg000:0AAD                 clc
seg000:0AAE                 retn                                             
seg000:0AAF loc_0_AAF:
seg000:0AAF                 mov     byte_0_CE3, 0FEh	;Cylinder 0 head 1 is unusable	
seg000:0AB4                 mov     byte_0_CE4, 6		;Switch to the single-sided format
seg000:0ABA loc_0_ABA:   
seg000:0ABA                 cmp     byte_0_CE3, 0FEh	;Formatting one side?
seg000:0ABF                 jz      loc_0_AD1			;If so, track 0 verified OK
seg000:0AC1                 mov     byte_0_CE2, 3		;Set retry count to 3
seg000:0AC6                 inc     byte_0_CDF			;Formatting two sides, so verify head 1
seg000:0ACA                 cmp     byte_0_CDF, 1		
seg000:0ACF                 jz      loc_0_A8C                 
vbdasc
Posts: 37
Joined: Tue 21 Mar, 2017 10:53 am

Re: PC-DOS 1.10 and PCem v12

Post by vbdasc »

JohnElliott wrote:
mal.sh wrote: Good. But your theory can be proved only via disassembling the IBM PC-DOS 1.10 FORMAT.COM
I have disassembled the PC-DOS 1.10 FORMAT.COM. Anyone who wants the IDA database, drop me a line.

The program's divided very clearly into two modules: the first 2k are the machine-independent bit, dealing with parsing options and transferring the system file, and the remainder is the machine-specific part that actually does the formatting. In the latter part...

...

The formatter then formats cylinder 0 head 1, followed by cylinder 0 head 0.

...

It then verifies both these tracks. If it can't verify head 1, it switches to the single-sided format:
Thanks. But can you tell what exactly are conditions to raise the error "Track 0 bad - disk unusable"?
User avatar
SarahWalker
Site Admin
Posts: 2054
Joined: Thu 24 Apr, 2014 4:18 pm

Re: PC-DOS 1.10 and PCem v12

Post by SarahWalker »

Presumably that would be if one of the format commands returns an error.
User avatar
JohnElliott
Posts: 113
Joined: Sun 31 Jan, 2016 7:29 pm

Re: PC-DOS 1.10 and PCem v12

Post by JohnElliott »

vbdasc wrote:Thanks. But can you tell what exactly are conditions to raise the error "Track 0 bad - disk unusable"?
This is one of the places where the division between machine-independent and machine-dependent parts of the code shows up quite clearly. The message comes from the machine-independent part:

Code: Select all

seg000:0203 loc_0_203:
seg000:0203                 call    sub_0_B3A			; Format the disc
seg000:0206                 jb      loc_0_1FB			; If carry is set, report "Format failure"
seg000:0208                 cmp     ax, 0				; If AX is nonzero, there are bad sectors
seg000:020B                 jnz     loc_0_210          
seg000:020D                 jmp     loc_0_2DC			; Otherwise it worked
seg000:0210 loc_0_210:                             
seg000:0210                 cmp     bx, word_0_CE4		; Is BX less than the number of sectors needed
seg000:0214                 jge     loc_0_21E			; for directory and FAT?
seg000:0216                 mov     dx, offset asc_0_7FA	; Report "Track 0 bad - disk unusable"
seg000:0219                 call    sub_0_436			; Display message
seg000:021C                 jmp     loc_0_1FB			; Report "Format failure"
It looks to me as if the machine-independent part is expecting sub_0_B3A to return the number of the first bad sector. In fact, what sub_0_B3A does is:

Code: Select all

seg000:0B3A                 mov     byte_0_CE2, 3		; Retry count
seg000:0B3F                 cmp     byte_0_CE1, 0		; Error indicator
seg000:0B44                 jz      loc_0_B53
seg000:0B46                 mov     byte_0_CE1, 0		; If it was set, reset it...
seg000:0B4B                 mov     bx, 0                              
seg000:0B4E                 mov     ax, 8				; and say there are 8 bad sectors starting at 0.                         
seg000:0B51                 clc                              
seg000:0B52                 retn            
The flag at byte_0_CE1 gets set by the earlier subroutine (sub_0_9F4) that formats track 0, if either a format or verify operation failed.
User avatar
mal.sh
Posts: 32
Joined: Wed 08 Jun, 2016 6:12 pm

Re: PC-DOS 1.10 and PCem v12

Post by mal.sh »

Well, as I promised I've checked PC-DOS 2.00 FORMAT.COM work with 160/180 KB floppy drives.


1) my configuration was:

Image

2) 180 KB PC-DOS 2.0 image file (I downloaded it from here) was mounted to Drive A.
160 KB image file was mounted to Drive B.

5) When I tried the command FORMAT B:/1 I got such error:

Image


With the command FORMAT B: I got the next error:

Image


6) Then I mounted 180 KB image file to Drive B.

With FORMAT B:/1 command I got NO error.

With the command FORMAT B: I got the next error:

Image

Just LOL )
Post Reply