If NO IMAGES will be shown, use www.z80.eu/blog instead of blog.z80.eu

Please note also - THIS BLOG ENDS HERE WITH THE LAST ENTRY FROM NOVEMBER 9th 2021.

I have prepared a new blog with wordpress at https://vintagecomputing.info !!!

Thank you.

As you know for sure, LBA (logical block addressing) comes in two flavors, the early 28bit LBA implementation and the later LBA 48bit.
LBA is not implemented for early PCs (but approx. since Intel 80386 CPU PCs raised), and unfortunately also later sold PCs have often only 28bit BIOS support.
This is also mentioned on several web sites in relation with DOS 7.1 aka Windows 95B, Windows 98,SE (ME has a higher DOS number, but is not used standalone).

MS-DOS until Version 7.1 does not support FAT32, which theoretically supports up to 268.435.456 cluster - a cluster is usually a sector; before 4K block drives appeared, a harddisk sector had only 512 Bytes. That means you can use drives up to 2 TeraBytes.

Practically you will reach a lower limit often, 137GB. This limit is NOT related with FAT32, but with Microsoft tools like FDISK and FORMAT (in DOS 7.1) or with the build-in Formatting Routine in modern Windows implementations.

DR-DOS 7.03 with DRFAT32.SYS driver does support also FAT32, and so some unofficial published and modified versions of DR-DOS 7 (e.g. DR-DOS 7.01.06). Unfortunately DR-DOS has still a 2GB limit for the first partition. But give FreeDOS also a try, this will work for sure.

If you want to use larger harddisk drives with DOS 7.1 (at least larger than 64GB), you need a corrected version of FDISK. You will not find the file anymore on Microsoft pages, but to the rescue, archive.org has still them.

Follow the "related link" below to visit the original archived Microsoft page (saved from pkisolutions.com) or search for file "263044usa8.exe" (english) or "263044ger8.exe" (german).

Ontrack Disk Manager can be used with hard disk vendor branding, but it doesn't matter if you own a drive from this vendor.
E.g. if you find >a version 6.03 with "Conner Peripherals" branding<, it can be used with a Seagate drive ;-)

This is the main menu:


And this happens after pressing return:

Remember, existing disk content will be deleted...

And that comes up than:


If successfully installed, booting from hard disk drive looks like this:


If manually (see more below) installed on floppy disk, booting looks like this:


You do not need to have the Disk Manager Driver DMDRVR.BIN loaded while using the main program DM.EXE with a boot floppy disk for installation!

Later on, if you want to boot from diskette for whatever reason, you have to include some files from the Disk Manager diskette.

CONFIG.SYS for a MS-DOS 6.22 boot diskette should be looking like this:
DEVICE=DMDRVR.BIN
DEVICE=HIMEM.SYS
DOS=HIGH
... assuming that the following files must be present on diskette:
DMDRVR.BIN
XBIOS.OVL
HIMEM.SYS
... and of course other, usually used files for a MS-DOS boot diskette.

You SHOULD NOT load DMDRVR.BIN after HIMEM.SYS, but only before !
(see also >here< for an official statement)

Any other additional commands can follow after DOS=HIGH, but must not.

AUTOEXEC.BAT needs no special command, can include just your KEYB command with an appropriate two-letter country abbreviation.

All tests were done using PCem/86Box with an emulated 386DX40 and with Award BIOS, and with the following drive parameter:
User Type 47: 2047 tracks, 16 heads, 63 sectors (~1007 MB)

Interesting fact:

Booting from floppy disk without DMDRVR.BIN and showing partition infos via FDISK results in a 504MB sized drives (which is wrong).
Booting from floppy disk with DMDRVR.BIN (and XBIOS.OVL) shows the correct partition/drive size.

Added later: Disk Manager Version 7.09 and may be also other newer versions will not use DMDRVR.BIN loaded as a device driver, instead, the boot sector of the floppy will be modified to load DDLOADER.BIN. This can be done by using DM.EXE and "Maintenance" tasks.

All big numbers are "Bytes". Nothing else loaded, no keyboard driver a.s.o.

MS-DOS 1.25 : 642784 english
MS-DOS 2.00 : 628688 english
MS-DOS 2.11 : 630784 english
MS-DOS 3.00 : 616720 english
MS-DOS 3.10 : 616800 english
MS-DOS 3.20 : 609984 english
MS-DOS 3.30 : 600368 english
MS-DOS 3.31 : 599488 english (Compaq DOS, first DOS for partitions > 32MB)
MS-DOS 4.01 : 589488 english
MS-DOS 5.00 : 593392 english, no HIMEM.SYS
MS-DOS 5.00 : 638592 english, with a 386, and with DEVICE=HIMEM.SYS and DOS=HIGH
MS-DOS 6.22 : 592384 english, no HIMEM.SYS
MS-DOS 6.22 : 638416 english, with a 386, and with DEVICE=HIMEM.SYS and DOS=HIGH

MS-DOS 4.01 : 589072 german version (just to see if a different language costs memory)

HIMEM.SYS 2.04 can be loaded on a 386 with MS-DOS 4.01, but there is no DOS=HIGH command, about 2.6KB less memory then (if loaded),
DOS 6.22 without hidden DRVSPACE.BIN file in root directory.

There are no further numbers for comparison of higher DOS versions, because it makes not really sense to load such a version on a very old 8088 PC compatible system.
Also, I do not wanted to compare the free memory numbers for 386 systems and above, with UMB usage you can probably get even more free memory than just with DOS=High.

Because I was still searching for a small hard disk imaging software which can run on a IBM PC/XT also (no need for EMS or XMS, no need for a better processor than 8088), and can be used with a parallel ZIP drive (e.g. with PalmZIP for PC/XTs), but not finding anything useful, I developed my own HDD imaging utility.

So far it does already creating a whole image backup of a HDD, and it compresses also (at least down to about 60% of the original size) the image file chunks which can be created.
That means, on the target media (like a ZIP 100 media), about 160-170MB can be stored, instead of 100MB (remember, it's NOT 100MB in fact, it's about 91MByte).

It requests for exchanging the target media, so you will be able to use subsequently different media disks, instead of saving it first to another HDD (caching it).

See the screenshots I made:

Starting it, choosing the right HDD and size of the target media (parts):


Finishing it, looking for the result:


Unpacking it to uncompressed image parts, and reassembling it to one HDD image file:

(even if you rename the compressed files, the sequence number, which is important for reassembling, is stored within the file header of each file)

Looking for the result:


You can download the 1.3 (still improving it) at "related link" here.

The "unpack" Windows application (to uncompress the saved & compressed imagefile parts to uncompressed imagefile parts but with the help of the Windows command line, running with Windows 10 for example) is now also available >here<. Using the saved image file is tested more than once with PCem for example. And last but not least, I'm working meanwhile also on the topic "restore", means you will be able to restore that saved image back in the future.

To have some new examples for x86 assembler programming, I've created also one sample with a small benchmark program, which should work with old PCs like the IBM PC/XT.
This program, created with an assembler source for MASM 5.10, will measure basically for a defined period of time (5 seconds, or in 1/18.2 sec ticks exactly 91 ticks) how fast one char is displayed with the help INT 10h function 09h (a BIOS function, not DOS related). I was trying to implement it via INT 10h function 0Eh (tty type output), but this was not working because function 0Eh is working only in graphics mode.
I didn't liked to implement it by writing directly into video RAM (beginning at 0B800:0h for CGA, EGA and VGA), because I wanted to avoid screen snow with a CGA.

I tested it with several virtual, emulated PCs (from IBM PC/XT up to a PC with a Pentiumn 233 MMX), and also with some real, existing PCs I had.

Usually, DOSBOX, especially if the cycle value is increased or unlimited, but also even with the default settings, is really fast and things will work really good.

With my sample bench program, this ends up in a surprise !
DOSBOX wasn't the fastest choice. It started very fast, but after a moment, was slowing down drastically with the video output. I didn't try to analyze the reason (by reviewing the DOSBOX source), but it was interesting.

PCem with the emulated Pentium MMX 233 was way faster (~ 982 loops for DOSBOX, ~ 1700 for the emulated PCem v17 PC). I guess I need an explanation why this happens, but I fear emulated PCs (using PCem) with a real BIOS are much better in terms of (text) video output, because there is no caching or memory limit while executing the emulation.

Added later: It depends of the "cycle" value, if the value is above ~4000 (or even "max"), you will get the mentioned effect, if it's the default value of 3000, the effect is almost invisible. But still a strange effect.

See 'related link' for a download possibility of the benchmarking program (with source code). See also my >youtube video<.

I would really, really appreciate some result values from REAL machines. Many thanks for any value in advance. You can use the comment function (at least for about 60 days after posting this) and/or the contact function here.