AFAIK int 13.8 should work, but otherwise try getting the far pointer stored in int 41 (first HDD) or 46 (second HDD), it should be a block of memory matching the parameter table here: https://wiki.nox-rhea.org/back2root/ibm-pc-ms … rupt_list-41-50

DaveDDS wrote on 2024-12-29, 06:18:

Both FDISK32 and FORMAT fail with "Insufficient memory"!

Try with less free RAM? Or slower CPU, maybe turning off Turbo or disabling cache can help. Some of these errors are due to program bugs and the message is not really what is causing it. Might just be some weird runtime library bug that is affecting those programs, like what some Turbo Pascal executables have.

DaveDDS wrote on 2024-12-29, 06:18:

INT 13h AH=08h comes close... I am able to determine the
cylinders and heads, but sectors/track always seems to come out as 1.

I've never came across it but Wiki says some BIOSes have this particular function bugged. ES and DI need to be set to zero to work around the issue. I use that for my low-level HDD dumper so I added that workaround just in case. I'm assuming you are using 0x80 as the drive number?

A curious thing to note, it seems that BIOS is reporting cylinders - 1, not the value directly. This causes DOS FDISK to never allocate the very last cylinder for the partition. I've only discovered that a few years ago. If you are writing your own tools to handle the partitioning you might want to work around that as well. Or temporarily set cylinders + 1 in BIOS for FDISK, after the partition is created DOS will use those parameters and not BIOS settings.

Deunan wrote on 2024-12-29, 12:57:

>>"Insufficient memory"
Try with less free RAM? Or slower CPU, maybe turning off Turbo or disabling cache can help. Some of these errors are due to program bugs and the message is not really what is causing it. Might just be some weird runtime library bug that is affecting those programs, like what some Turbo Pascal executables have.

I did think if this, and tried writing/running a program which allocated a huge block of far memory,
then tried the command - same result.
I'm testing with real DOS booted within DosBox (which lets you set system memory in megs), so I don't see any way
to reduce conventional memory below 640k ...
I do recall there there were some utilities which would trick the system into thinking it had less memory, but I
don't know of any "off the top" (it has been years since I looked at this stuff) - any suggestions?

>>"INT 13h AH=08h"
I've never came across it but Wiki says some BIOSes have this particular function bugged. ES and DI need to be set to zero to work around the issue. I use that for my low-level HDD dumper so I added that workaround just in case. I'm assuming you are using 0x80 as the drive number?

Well.. clearly I shouldn't work on such "stuff" late at night, I had a rather complex test program which did things like save
all the registers after the INT (so I could see the results of each step)...

This morning I tried just implementing it in a much more straightforward way - and it appears to be reporting sectors correctly!
(my plan was to figure out sectors by trying to read along a track ... but first step was step get cyls/heads and that seems to be reporting
sectors correctly as well!)

A curious thing to note, it seems that BIOS is reporting cylinders - 1, not the value directly. This causes DOS FDISK to never allocate the very last cylinder for the partition. I've only discovered that a few years ago. If you are writing your own tools to handle the partitioning you might want to work around that as well. Or temporarily set cylinders + 1 in BIOS for FDISK, after the partition is created DOS will use those parameters and not BIOS settings.

Yeah, I had pretty much already figured this out... the Phoenix tech ref. I have reports INT13hAH=08h as returning:
"Maximum useable" C/H/S - since C and H are 0 based, this is actually 1 less then the number.
As S is 1 based - this is the actual number.

I have little doubt that the FDISK thing was originally a bug - but later it got dressed up and became a feature...
If you look at the AT drive parameter block spec... the ControlByte has a bit which indicates that there may be a "Defect map" at MaxCyl+1

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

jmarsh wrote on 2024-12-29, 07:01:

AFAIK int 13.8 should work, but otherwise try getting the far pointer stored in int 41 (first HDD) or 46 (second HDD), it should be a block of memory matching the parameter table here: https://wiki.nox-rhea.org/back2root/ibm-pc-ms … rupt_list-41-50

Thanks, I had thought of this ... But I had assumed that this would point to the drive type table in ROM and that user
defined drive types would not have values - The tech. ref I have doesn't go into a lot of detail, but it does say the values
for the user defined drives are stored in CMOS RAM with no mention of copies in directly accessible RAM.
Some (admittedly very simple) tests I did suggested that these tables are in ROM.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

DaveDDS wrote on 2024-12-29, 13:52:

I do recall there there were some utilities which would trick the system into thinking it had less memory, but I
don't know of any "off the top" (it has been years since I looked at this stuff) - any suggestions?

I'm not familiar with PC DOS and its tools, is FDISK32 a real-mode program or something that executes with a DOS extender? If the latter then try limiting HIMEM memory to or below 16 MiB.
For memory below 640k allocating a big chunk of it should be enough to lower the available amount. BIOS also sets the RAM size into its variables area - so that DOS knows how much there is. You could try messing with that. I don't really remember the exact address and the book I need is at another location.

There is also a guide here on VOGONS: Revisiting PC-DOS 7.1.
It says you need to run the FDISK32 with /MBR first, did you? I suppose an MS-DOS partition table could be tripping it somehow.

DaveDDS wrote on 2024-12-29, 13:52:

This morning I tried just implementing it in a much more straightforward way - and it appears to be reporting sectors correctly!

All's well that ends well. Note that while you can read the HDD parameters from RAM, where BIOS copies it for easier access, some BIOSes have an option to move that area to the end of 640k region, stealing about 1k from DOS memory. And also SCSI controllers will obviously not set anything there and only support HDD access via int 13h extensions. Which BTW have their own bugs.
There is a HDD table in the ROM but these settings are also copied to RAM, just as if you were to enter them for the user-defined type 47. So there is no need to do anything with that ROM table, in fact it can be incomplete or a bit different on some earlier machines.

Deunan wrote on 2024-12-29, 15:38:

I'm not familiar with PC DOS and its tools, is FDISK32 a real-mode program or something that executes with a DOS extender? If the latter then try limiting HIMEM memory to or below 16 MiB.

Yeah, I don't know PCDOS nearly as much as MS - I've only used it a couple times for deployable floppy disk images.
But i'd like to use it and get to know it more ... which is where hard drive prep. kinds becomes needed

and ... I don't much like the name "FDISK32" ... suggests to me that it's not just a simple conventional memory
program .. which seems odd since PC and MS dos share much background and MS FDISK "just works" in 640k.

This is one of the big reasons I'm considering creating my own PARTITION/FORMAT tool.

For memory below 640k allocating a big chunk of it should be enough to lower the available amount. BIOS also sets the RAM size into its variables area - so that DOS knows how much there is. You could try messing with that. I don't really remember the exact address and the book I need is at another location.

My compiler has "alloc_seg()" to allocate far memory I've tried allocating blocks down to where there's <256k free, and didn't
find something that worked. This unfortunately allocated memory from the bottom up - IIRC the tool I once used made the amount
of memory DOS saw smaller, effectively "consuming" it from the top-down.. I don't know if this would matter.

There is also a guide here on VOGONS: Revisiting PC-DOS 7.1.
It says you need to run the FDISK32 with /MBR first, did you? I suppose an MS-DOS partition table could be tripping it somehow.

FDISK32 (and FORMAT) both never even get to the point where they access the disk - "Insufficient memory".

And, yes I've tried this with fully initialized and accessible drives (Where I can DIR them and access files on them - obviously
a good MBR).

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Some more "interesting" information...

The PCDOS that IBM gave away free in the ServerGuideScriptingToolkit is
version 7.1

I have a full set of PCDOS 7.0 install disks - so I installed it on a spare
drive ... somewhat painful as the disks are 1.8M XDF format, which ment I
had to use a real DOS system with a real floppy drive.

FDISK(not called FDISK32 in 7.0) and FORMAT work fine.

I made a bootable 7.0 floppy, read it into an image, then booted it under DosBox
(same setup as I've been testing PCDOS 7.1 in)

FDISK and FORMAT worked fine!

I then copied FDISK.COM and FORMAT.COM to a copy of the PCDOS 7.1 image I've
been testing with.

FDISK works fine! FORMAT almost works, but /S says it "can't write boot sector"
(but the drive does format).

Not sure why it can't write the boot sector, as the disk was partitioned with
the same FDISK that I used under 7.1 (where it could write the boot sector).
Presumably the same layout - only difference is the PCDOS version itself.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

I wonder if that copy of the PCDOS is somehow broken if it makes the tools behave like this? DOS has its own software interrupts as a HAL to read/write physical sectors, but these I think require already formatted media. So I would guess these tools use int 13h natively. Perhaps the kernel modifies that interrupt and makes this is what trips the tools? I'm just out of ideas.

EDIT: Try running FDISK32 and FORMAT32 from 7.1 under PCDOS 7.0 - see what that does.

Deunan wrote on 2024-12-30, 17:11:

I wonder if that copy of the PCDOS is somehow broken if it makes the tools behave like this? DOS has its own software interrupts as a HAL to read/write physical sectors, but these I think require already formatted media. So I would guess these tools use int 13h natively. Perhaps the kernel modifies that interrupt and makes this is what trips the tools? I'm just out of ideas.

I was beginning to think the same thing.... All these files are directly from the IBM ServerGuideTools CD... but
I do recall that at least one minor command was broken in that it checked for the wrong DOS version... something
like that wouldn't have made it into a production DOS release...

This all may be kinda moot - In searching around, I just discovered that Microsoft has released MSDOS 4.0 (complete with it's
source code) under the MIT license... I've not used 4.0 before, but it seems close enough to 5.0 (my fav and the one I still use
on my various DOS machines) that I might just switch to it for anything I might want to deploy.

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Deunan wrote on 2024-12-30, 17:11:

EDIT: Try running FDISK32 and FORMAT32 from 7.1 under PCDOS 7.0 - see what that does.

FORMAT seems to work. FDISK32 doesn't give the "Insufficient memory" error, but always reports "Invalid parameter".
I've not found anything that causes it to go further.

I have a set of PC DOS 7.x manuals, including the tech manual. Lots of references to FDISK, but no mention of FDISK32!

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal

Did you try the boot disks from Lucas here: https://www.betaarchive.com/forum/viewtopic.php?t=40304
Link https://www.ibm.com/support/pages/ibm-serverg … on-version-1307
They are probably no different than what you made for 7.1. Sorry cannot help much cause never messed with PC Dos much.
for archive purposes http://web.archive.org/web/20160311025324/htt … ocid=MIGR-53564

Horun wrote on 2025-01-01, 03:27:

Did you try the boot disks from Lucas here: https://www.betaarchive.com/forum/viewtopic.php?t=40304 Link https://www.ibm.com/sup […]
Show full quote

Did you try the boot disks from Lucas here: https://www.betaarchive.com/forum/viewtopic.php?t=40304
Link https://www.ibm.com/support/pages/ibm-serverg … on-version-1307
They are probably no different than what you made for 7.1. Sorry cannot help much cause never messed with PC Dos much.
for archive purposes http://web.archive.org/web/20160311025324/htt … ocid=MIGR-53564

I was unable to get the one from ibm.com, it just hangs - I don't know if it's not working/obsolete - or: I note the the link on that one is FTP,
and I *think* I've gotten files that way, but perhaps CHROME on this system can't deal with it correctly - It doesn't give an error, just appears
to do nothing while showing "FTP..." at the bottom of the screen.

I was able to get the one from web.archive (it's a direct reference to the .ZIP), and it's exactly the same (byte for byte compare)
as the one I already have - but thanks!

I actually first obtained "ServerGuide Scripting Toolkit" on optical media (CD or DVD - don't recall which) directly from IBM ...
but I must of given it away at some point, as I don't seem to have that one anymore - hopefully these downloads have the
same content)

[so far I'm quite liking MS-DOS 4.00 (recently released under MIT license) - not only is it "officially free", but it's closer than PC-DOS 7.1
to MS-DOS 5 which I use on a daily basis, supports the larger drives like 5 etc. I really don't need the fancier features of newer ones, long
filenames etc. I just sometimes want to deploy custom tools and be able to provide a bootable environment, so people who don't have a
basement full of DOS machines can still make use of them if required]

Dave ::: https://dunfield.themindfactory.com ::: "Daves Old Computers"->Personal