NeoG_ wrote on 2026-07-14, 22:06:

It's a red herring, dd was set to output progress to the terminal so one of the in-flight progress lines was copied and pasted. The final byte count was as expected
... 1474560 bytes (1.5 MB, 1.4 MiB) copied, 177.923 s, 8.3 kB/s

Weird red-herring - it actually sez "1474560 bytes (1.5 MB) copied" - so under Linux, everywhere a transfer command reports the number of bytes copied... It can't be trusted to be the actual number of bytes transferred? (I'm guessing the "progress lines" were generated, not actually copied from anywhere?)

DaveDDS wrote on Yesterday, 00:29:

NeoG_ wrote on 2026-07-14, 22:06:

It's a red herring, dd was set to output progress to the terminal so one of the in-flight progress lines was copied and pasted. The final byte count was as expected
... 1474560 bytes (1.5 MB, 1.4 MiB) copied, 177.923 s, 8.3 kB/s

Weird red-herring - it actually sez "1474560 bytes (1.5 MB) copied" - so under Linux, everywhere a transfer command reports the number of bytes copied... It can't be trusted to be the actual number of bytes transferred? (I'm guessing the "progress lines" were generated, not actually copied from anywhere?)

Not strange, OP had status=progress flag set which is what created the partially copied line. The flag continually writes the block count/speed/time to the terminal so you can track the progress of the command. Anything before the in/out block totals is a progress status line and is not a final count. It's not a red herring as in dd is mis-reporting the block count. It's a red herring as in you are focusing on a line that is akin to saying "98% copied" and not the final byte count.

Just in case anyone is interested (I'm thinking of making this for myself anyway)

I've been thinking about how to reliably write disk images from an "unknown" system, and I've come up with this:

-Your system has be capable of booting from optical media (CD or DVD)!

I can place all the DOS images I have (at the moment with the new ones from "allbootdisk" it's >25) on a CD, and make that CD bootable with the ImageDisk stand-alone floppy boot.

This boot makes a RamDisk for working storage, has some basic network file transfer ability, and can "see" the DVD it was booted from (so it could access many images without having to transfer them) - and of course has ImageDisk and a number of usefull tools.

Unfortunately the method I used to make a .ISO bootable works by "faking" the floppy to BIOS - so tools like my XDISK (which goes through BIOS) can't work because they wouldn't see the actual floppy.

But... ImageDisk doesn't use BIOS - it "talks" directly to the floppy controller hardware. So... it CAN read/write actual floppy disks even when booted from optical media.

Most DOS boot floppies are simple .IMGs which are raw sector dumps of the DOS formats. ImageDisk being able to handle all kinds of floppy formats (incl non-DOS ones) needs a .IMD which contains records describing the format for each track.

But ... I have a utility "BIN2IMD" which can convert a raw binary dump (like a .IMG) into a full .IMD - You have to tell it things like cylinders, sides, sectors/track, sector size and Interleave to do the conversion - I can provide a .BAT file able to easily converting the common DOS floppy formats (which you can tell by size)

This gives you a CD which you can boot and create any DOS boot disk in the collection.
It would however require and actual physical floppy (with standard PCish Nec765 family compatible floppy controller chip)

Just some thoughts - if anyone is interested I can put it together.

NeoG_ wrote on Yesterday, 00:34:

Not strange, OP had status=progress flag set which is what created the partially copied line. The flag continually writes the block count/speed/time to the terminal so you can track the progress of the command. Anything before the in/out block totals is a progress status line and is not a final count. It's not a red herring as in dd is mis-reporting the block count. It's a red herring as in you are focusing on a line that is akin to saying "98% copied" and not the final byte count.

Fair enough - it seems a fundamentally different way of thinking. When I create a bit of software that continually reports it's progress (perhaps by overwriting a single line on the TTY screen), I always make sure to issue that line at the very end of the operation - so the reported progress is up to date and there's no "partial" progress left on the screen.

Easy enough to do ..

1if (report_progress == ON):
2   report status with "<return>status text" a it updates ... *1
3   output <return> after all processing but before final results are displayed. *1
4   (If you want to avoid redirection - output these to stderr)
5Always:
6  For final results, output "status text<newline>" first *2
7  Report anything else to be in final report.

*1 Technically you could simplify this to just outputting "status information<return>" ... but I generally don't like the cursor to be sitting at the start of a printed line during operation.

*2 As "bytes transferred" only goes up ... the final message it always going to fully overwrite any partial progress which might be on the TTY screen.

And yeah, this is getting off-topic, lets just say it's a matter of preference and leave it at that!

DaveDDS wrote on Yesterday, 00:57:

Unfortunately the method I used to make a .ISO bootable works by "faking" the floppy to BIOS - so tools like my XDISK (which goes through BIOS) can't work because they wouldn't see the actual floppy.

I've seen BIOSes demote the real floppy drive to B: in that situation. What happens if you have two floppy drives? No idea, perhaps that wasn't considered since it would be pretty niche once CD-ROM booting went mainstream.

DaveDDS wrote on Yesterday, 01:31:

Fair enough - it seems a fundamentally different way of thinking. When I create a bit of software that continually reports it's progress (perhaps by overwriting a single line on the TTY screen), I always make sure to issue that line at the very end of the operation - so the reported progress is up to date and there's no "partial" progress left on the screen.

dd probably does this too, it's just that an errant keypress while dd is running could be echoed to the screen and cause you to get an extra line or extra status report like that, while on DOS, such keypresses are buffered and don't get looked at until after the program is done.

jakethompson1 wrote on Yesterday, 01:37:

I've seen BIOSes demote the real floppy drive to B:

I've had systems which did and ones which didn't

Like so many "improvments" - not something you can trust to be there!

jakethompson1 wrote on Yesterday, 01:38:

... while on DOS, such keypresses are buffered and don't get looked at until after the program is done.

When I write something that takes long enough to want ongoing status output - I typically check from time to time for an "abort" key (often Esc) to abort gracefully and ignores anything else. (but of course depends on what key interrupts are supported by OS it's .running under)

In Unix, that would be handled by the shell - e.g. control+c and control+z are intercepted by the shell and handled outside of the application which is running, either pausing it (and allowing for the paused process to be either backgrounded or resumed again) or stopping it.

You can have the application handle character input itself (think SDL applications, or something like vi or nano which captures control codes itself), but it's not the standard Unix way for most utilities ran in the terminal.

megatron-uk wrote on Yesterday, 06:56:

In Unix, that would be handled by the shell ....

Agreed (I suspected these comments would generate "feedback" 😀 )

When I'm developing under a "real" OS - I usually don't bother with handling these things unless there is a reason the particular program should shut-down "gracefully".

I also don't fret-over/half-expect that when a program is forcefully aborted, there may be "droppings" on the screen which may not reflect absolute reality at the time of said forced termination.

What I dislike is programs that complete normally and leave inaccurate information on the screen - I do tend to go out of my way to avoid that.

When I play with BeOS, I use "signal(SIGINT, handle_sigint);".
Because the default keys are Alt + C instead of Control + C, and you can spend some time trying to understand why an app launched from terminal doesn't want to close 😀

Thank you very much for all your responses.

I tried booting from my original MS-DOS 4.01 disk and it gave me the error (it didn't before). So I suspected it was the floppy drive. So I changed the drive, and everything seem to be working just fine. But then, when I tried to execute certain files (like FORMAT, etc), it gave me the same error it gives when there is no disk in the drive... I tried different disks, then the motherboard gave me CMOS and keyboard errors, and now it doesn't even start. So I think the motherboard is messed up. I gave up on this motherboard and will get a new one. All the errors and issues I had probably steam from the faulty motherboard. Thanks again!

DaveDDS wrote on Yesterday, 00:21:

popcalent wrote on 2026-07-13, 17:10:

$ sudo dd if=Dos6.22.img of=/dev/sdc bs=512 conv=fsync status=progress
1471488 bytes (1.5 MB, 1.4 MiB) copied, 162 s, 9.1 kB/s1474560 bytes (1.5 MB, 1.4 MiB) copied, 162.434 s, 9.1 kB/s

And the OP 's command does NOT!

I think this is just an error on the terminal output of dd. The output was showing the progress, and for some reason, at some point near the end, it didn't go back to the beginning of the line. The image file is 1474560 bytes.

I'd check/replace the CMOS battery.
Check all power sipply voltages.
Look for signs of corrosion on the motherboard.
Carefully Remove/Reseat any socker chips a couple times

If you cam get back to trying to boot, try cleaning the drive heads.

It did work, and "magic smoke" hasn't escaoed ,,, might be recoverable.

popcalent wrote on Today, 10:58:

I think this is just an error on the terminal output of dd. The output was showing the progress, and for some reason, at some point near the end, it didn't go back to the beginning of the line. The image file is 1474560 bytes.

I'm not all that famuilier with dd - Seems odd that it wold leave "wrong" information on the screen when no error is reported... but who knows, at least the final number is right.

Looking back at the original post... looks like more than just failure to clean-up ongoing progress messages,
The line with the "wrong" number actually continues with the right number.

1471488 bytes (1.5 MB, 1.4 MiB) copied, 162 s, 9.1 kB/s1474560 bytes (1.5 MB, 1.4 MiB) copied, 162.434 s, 9.1 kB/s

If this were traditional Unix over actual TTYs - I might think that some condition prevented a <carriage return> character from reaching the terminal which prevented it from properly overwriting the previous progress report ... and whatever it was corrupted into wasn't a character that displayed.

But being a PC console, and the precise position of the "lost" character, I more strongly suspect that whomever wrote the particular edition of dd that was used simply forgot the <return> when the "final" progress report was issued (which you wouldn't output unless you had been reporting ongoing status)

Hi, about image sizes..
I remember that some 1,44 MB disk images I've found online were slightly exceeding 1,44MB and couldn't be used in VMs or be written to physical floppy disk.
To fix this, I used WinImage to open the image files and selected 1,44 MB in the format settings and saved.
After this, these 1,44 MB images were legal 1,44MB images.

Jo22 wrote on Today, 12:03:

Hi, about image sizes..
I remember that some 1,44 MB disk images I've found online were slightly exceeding 1,44MB ...

"Standard" DOS/Win 1.44m 3.5" disks are: 80 cylinders x 2 tracks x 18 sectors/track x 512 bytes/sector = 1,474,560 bytes in size

But.. some drives/media can step out an extra cylinder or two, so it was not entirely uncommon to see:
81 x 2 x 18 x 512 = 1,492,992
82 x 2 x 18 x 512 = 1,511,424
83 x 2 x 18 x 512 = 1,529,856
There are tools to create these.

Obviously the more "extra" tracks you try to format, the less likely it is that a given drive/media combination can support it.

...and... it couldn't be relied on to even have 1 extra cylinder on every drive... so it wasn't used in official/distributed disks.

But plenty of individuals had "special" disks for storing their own stuff and of course some of these found their way online!

DaveDDS wrote on Today, 11:04:

I'm not all that famuilier with dd - Seems odd that it wold leave "wrong" information on the screen when no error is reported... but who knows, at least the final number is right.

The flag status=progress shows the actual progress of the dd command during the whole execution. So that is not "wrong" information, that is information that was right at some point during the process before dd finished its execution. Perhaps I inadvertently pressed a key while it was showing the progress and the output did not return to the beginning of the line.

DaveDDS wrote on Today, 11:00:

I'd check/replace the CMOS battery. Check all power sipply voltages. Look for signs of corrosion on the motherboard. Carefully R […]
Show full quote

I'd check/replace the CMOS battery.
Check all power sipply voltages.
Look for signs of corrosion on the motherboard.
Carefully Remove/Reseat any socker chips a couple times

If you cam get back to trying to boot, try cleaning the drive heads.

It did work, and "magic smoke" hasn't escaoed ,,, might be recoverable.

Yeah, the battery is new. I'm using a CR2032 with a battery holder that includes a diode. I just turned it on, and it worked. But then I turned it on again and it was all black and it was beeping. Isn't that a memory error? I don't know, I'm having a lot of issues with this board. I'm not saying I'll throw it away, but I'm working on a project that needs a working 386, and this is an unexpected hassle. I'll try with a different motherboard, and save this one to figure out what's wrong with it in the future.