PC-DOS 1.10 and PCem v12
Re: PC-DOS 1.10 and PCem v12
There is no /1 in ver 1.0 because the ONLY disk supported was 160kb
1.10 introduced double sided 320kb and therefore /1
1.10 introduced double sided 320kb and therefore /1
Re: PC-DOS 1.10 and PCem v12
Yes, but Shadower said above that he had IBM-PC DOS 1.00 and used FORMAT command with /1 option. ))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
Re: PC-DOS 1.10 and PCem v12
I bet it would have worked if you write /1 /64 or whatevermal.sh wrote:Yes, but Shadower said above that he had IBM-PC DOS 1.00 and used FORMAT command with /1 option. ))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
Re: PC-DOS 1.10 and PCem v12
Done. I've checked it via Hampa "PCE - PC Emulator" and it works with any options.omarsis81 wrote:I bet it would have worked if you write /1 /64 or whatevermal.sh wrote:Yes, but Shadower said above that he had IBM-PC DOS 1.00 and used FORMAT command with /1 option. ))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
Re: PC-DOS 1.10 and PCem v12
I used a "clean" minimal configuration of IBM PC 5150 allowed by the PCem:mal.sh wrote:Thanks for testing PC-DOS v1.00, but I tried only 1.10 version.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?
What was your PCEm's configuration for that test?
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?;
Re: PC-DOS 1.10 and PCem v12
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.mal.sh wrote:Done. I've checked it via Hampa "PCE - PC Emulator" and it works with any options.omarsis81 wrote:I bet it would have worked if you write /1 /64 or whatevermal.sh wrote:
Yes, but Shadower said above that he had IBM-PC DOS 1.00 and used FORMAT command with /1 option. ))
Re: PC-DOS 1.10 and PCem v12
Because a 320/360 kB image has the second side, therefore when FORMAT attempts to format it, it succeeds.omarsis81 wrote:Then, why I succeeded formatting a single sided disk in a 320/360 kb using the /1 parameter?
This is a bug in PC DOS 1.10 FORMAT.COM. The one from 1.00 works fine.
Re: PC-DOS 1.10 and PCem v12
No, I what I did was formatting (in 1.10) a 320/360 image in a 360 drive. Please see the last screenshot posted.Battler wrote:Because a 320/360 kB image has the second side, therefore when FORMAT attempts to format it, it succeeds.omarsis81 wrote:Then, why I succeeded formatting a single sided disk in a 320/360 kb using the /1 parameter?
This is a bug in PC DOS 1.10 FORMAT.COM. The one from 1.00 works fine.
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
Re: PC-DOS 1.10 and PCem v12
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.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.
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.
Re: PC-DOS 1.10 and PCem v12
Ok. PC-DOS 1.10 FORMAT.COM works wrong and PCEm v12.0 FDC's right.Battler wrote: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.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.
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.
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.
Re: PC-DOS 1.10 and PCem v12
- 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.
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.
Re: PC-DOS 1.10 and PCem v12
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: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.
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 .
Re: PC-DOS 1.10 and PCem v12
The image remains at 320kbvbdasc wrote: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: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.
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 .
Re: PC-DOS 1.10 and PCem v12
Very well, thanks. But are all of these 320KB overwritten or only the half?omarsis81 wrote:The image remains at 320kbvbdasc wrote: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: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.
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 .
- SarahWalker
- Site Admin
- Posts: 2054
- Joined: Thu 24 Apr, 2014 4:18 pm
Re: PC-DOS 1.10 and PCem v12
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.
Re: PC-DOS 1.10 and PCem v12
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.
Re: PC-DOS 1.10 and PCem v12
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.
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.
Re: PC-DOS 1.10 and PCem v12
- 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.
Re: PC-DOS 1.10 and PCem v12
Alrighty! Crystal clear nowBattler 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.
Re: PC-DOS 1.10 and PCem v12
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.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)
Re: PC-DOS 1.10 and PCem v12
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.
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.
Re: PC-DOS 1.10 and PCem v12
Good. But your theory can be proved only via disassembling the IBM PC-DOS 1.10 FORMAT.COMvbdasc 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.
...
What tool do you recommend for that?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
And I want to remind that 160 KB floppy images works fine with IBM PC-DOS 1.10 FORMAT.com on PCEm v10.1
I'll check that.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.
Re: PC-DOS 1.10 and PCem v12
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 overwrittenmal.sh wrote: Good. But your theory can be proved only via disassembling the IBM PC-DOS 1.10 FORMAT.COM
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.mal.sh wrote: What tool do you recommend for that?
Re: PC-DOS 1.10 and PCem v12
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.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
- 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).
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.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.
- JohnElliott
- Posts: 113
- Joined: Sun 31 Jan, 2016 7:29 pm
Re: PC-DOS 1.10 and PCem v12
I have disassembled the PC-DOS 1.10 FORMAT.COM. Anyone who wants the IDA database, drop me a line.mal.sh wrote: Good. But your theory can be proved only via disassembling the IBM PC-DOS 1.10 FORMAT.COM
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
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
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
Re: PC-DOS 1.10 and PCem v12
Thanks. But can you tell what exactly are conditions to raise the error "Track 0 bad - disk unusable"?JohnElliott wrote:I have disassembled the PC-DOS 1.10 FORMAT.COM. Anyone who wants the IDA database, drop me a line.mal.sh wrote: Good. But your theory can be proved only via disassembling the IBM PC-DOS 1.10 FORMAT.COM
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:
- SarahWalker
- Site Admin
- Posts: 2054
- Joined: Thu 24 Apr, 2014 4:18 pm
Re: PC-DOS 1.10 and PCem v12
Presumably that would be if one of the format commands returns an error.
- JohnElliott
- Posts: 113
- Joined: Sun 31 Jan, 2016 7:29 pm
Re: PC-DOS 1.10 and PCem v12
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:vbdasc wrote:Thanks. But can you tell what exactly are conditions to raise the error "Track 0 bad - disk unusable"?
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"
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
Re: PC-DOS 1.10 and PCem v12
Well, as I promised I've checked PC-DOS 2.00 FORMAT.COM work with 160/180 KB floppy drives.
1) my configuration was:
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:
With the command FORMAT B: I got the next error:
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:
Just LOL )
1) my configuration was:
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:
With the command FORMAT B: I got the next error:
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:
Just LOL )