So ..this looks promising ..
So far I have managed to set the C/H/S for my Conner 100mb hard drive manually in the bios as there were no corresponding presets.
..and it does boot ..
Time to dig a little deeper after I've had something to eat..
Found this bios at this link..
http://www.vcfed.org/forum/showthread.p ... CAT)/page2
Had to join to get it ...but flashed the .bin to a 27C512..
..and away we go.....>>>>
I now have an American Megatrends SCAT bios in my build.
Dont know if this is a modded bios at this stage...but looks to be compatible with this motherboard.
So far anyway..
rgds
VS

Hmm ...
Time to give up pushing this beyond 100mb IDE limit think..
This bios is more restrictive than the GW-Gear Bios ..
It doesn't play nice at all with the XT-IDE card in the system.
So pulled it temporarily
The tried hooking up a Seagate ST3120A 103mb hard drive and set the Geometry as required ..
I know the drive is good ....but boot failed with HDD controller failure..
Tried a second controller card ..
Same result.
Basically anything that effectively uses 1024 cylinders causes the system to crap out.
It does look very much like this 100mb IDE limit is set in stone by the mobos hardware.
..not neccessarily a bios issue afterall.
So ..time to give up I think.
Cut my losses and accept that I will need to go SCSI in order that I can use larger hard drives.
I may well build the OS on a bootable 1GB SCSI hard drive and avoid IDE completely ...just using the controller card for floppy control.
I feel like I've come full circle with this...as I sort of had my answer a week ago.
SCSI all the way.
rgds
VS

Did you scroll all the type numbers on this bios with to see which one is larger than 100MB for example 210MB type 22 for example. Don't take for granted.

Once got to 200mb in the new type selection, try a industrial 256MB compact flash. Have to delete and create new partition and format the CF 256MB on same 286 computer after that if the type is 200MB it will be 200MB on 256MB CF.

website link to hard drive type table. These are the examples I'm talking about. Some actually read the bios back and replace few type numbers with new C H S then burn a new firmware with modified bios. 504MB is the max possible with conventional CHS format.

https://www.win.tue.nl/~aeb/linux/hdtypes/hdtypes-3.html

The forumla to get unformatted size based on 512 byte sector is:

512 * C * H * S = in bytes.

The max possible for 286, 386 and 486 bios without translation is 1023 x 16 x 63 then multiply by 512 is about 528MB, but most bios has different C H S which is often max 504MB.
The beauty of IDE design which is will accept any C H S smaller than the actual size of HD regardless of HD's different C H S. It's converted on the fly on the hard drive's controller.
I had done that, remember to keep correct C H S when moving hard drive between vintage computers in order to boot. On newer computer it will only see the created partition if yoiu are putting stuff on a hard drive so you can put it into vintage computer to finish installing stuff.

Very important that you delete and create new partition then format hard drive on the vintage computer like this first, reason for this to able to boot properly.

Secondly, NO NEED to low level format IDE and SCSI drives! Low level format was needed with MFM and RLL, ESDI.

The ESDI was created to able to handle greater than 800MB or so and ESDI controller card tranaslated the C H S on the fly so int 13 keep working and DOS working correctly. This is what IDE is based on! ESDI controller got integrated into IDE chipset on the hard drive to save cost, Compaq was first to use 16 bit IDE first back in the day. The IDE card is dumb, just subset of ISA signals, buffered properly on high quality IDE cards. Generic IDE cards has missing buffering signal ICs.

I had a 1GB ESDI micropolis that did not work even with 24MHz ESDI controller but 800MB Micropolis did.

Cheers, Jason

Thanks for that interesting read Jason ..
I'll have a looksee in the new bios to see if there are 'types' resulting in greater than 100mb ..which there may be ..
I found it interesting that the lists are not standardised ..
My previous GW bios supported the Conner HDD Directly with Type 35 .. C 776 H 8 S 33 ...LZ 775 = 100mb
But the Megatrends bios did not ..and so I had to input the CHS manually in the last 'type 41' ..user space.
Type 35 in this list ..is actually C 1024 H 9 S 17 LZ 1024 = 77mb
rgds
VS

OK back into the AM bios to check the type list ..
There were 4 larger than 100mb

Type 9 C 900 /H 15 /S 17 LZ 901 = 112mb
Type 32 C 1024 / H15 / S 17 LZ1024 = 128mb
Type 45 C 917 / H 15/ S 17 LZ 918 = 114mb
and
Type 46 C 1224 /H 15 / S17 LZ 1223 = 152mb

So looks like it too has limitations and 155 mb is that limit ??

So if I am interpreting this correctly I could use a 128mb CF (or indeed any oversized CF card) re-formatted to use type 46 ..thus ...152mb ?
I hope I'm getting closer to understanding
rgds
VS
I'd settle for 504mb ...if only the bios could be modded to support it ..
but that is beyond my abilities.

Thought I'd continue with my backup plan anyway..
Dug out an old Quantum TRB850S scsi HDD ...
Scandisk revealed a couple of bad clusters..but these I knew about having checked it over 6 years ago.
Apart from this the drive is in good shape.
Just formatted and installed DOS6.22 on it without any issues.
Correct me if I'm wrong but drive access time _should_ be quicker with scsi ??
Going down the scsi route with IDE drives turned off in the AMI bios...will give me an 820mb C: drive .
More than enough for the needs of this build I think.
Now ..If I can get the XT-IDE card to play nice I will have at least an easy way to get files in and out of the system.
Only problem is that I have no more scsi hard drives around the 1gb mark ..so if it fails ...nothing to replace it with.
Still a worthwhile addition going forward I think.
rgds
VS

The PCChips (or Triple D Technology) Cotek AMI bios that came with Apolloboy and my M205 didn't have trouble using the native C/H/S inputs for a 2.5 GB WD Caviar (translated, but not LSB, I think) drive and all my 286s that are working (and the booting, but stuck at 512kB MB1212C I have) currently work with my remaining Quantum 170 AT drive.

https://stason.org/TULARC/pc/hard-drives-hdd/ … -SL-IDE-AT.html

I think it's an HP OEM variant of this, exact same CHS and capacity, but no exposed jumper pins. (and I couldn't get it working in a master/slave pair)

It's well within the 528 MB limit, but does use translation as many IDE (and I think some MFM) drives use for more convenient visible geometry. (translated C/H/S = 1011/15/22)

Manually putting those values into the user-defined CHS settings in the BIOS works fine. I'm pretty sure that WD drive we tried 9 years ago was a WD 32500 with 4960/16/63 C/H/S, and the FAT-16B partition used by DOS was suitably limited as well. (I didn't take a screen shot, but that same setting was still saved in the BIOS when I started using that board again last year, and it definitely had 2500 MB in the capacity parameter)

I'm not sure about the other boards, but I suspect that AMI BIOS for the Citygate D60 chipset (used by PCChips/Hedaka under various brands) supports at least up to the 4GB (4032 MB) limit natively and maybe beyond that. There's enough RAM/register space reserved to allow for up to 255 to be saved as the head number and sector number, and 65535 for the cylinder number, so it seems like full 8 and 16-bit integers are used (not truncated to fit into 20 or 24 bits). However, the capacity parameter (calculated by the BIOS automatically) is limited to 16 bits as well, and wraps around (overflows) for any C/H/S combination that over 2^16 (64 MB).

I remember some other (slightly later) BIOSs either refusing to allow illegal/overflow values to C/H/S slots or locking up (requiring reset) immediately after inputting an impossible value (but before any attempt to save to CMOS could be made), but these PCChips bioses seem to just wrap around values if you type an impossible value into the parameter string or defaults to 0 if you key in more digits than the string's limits actually allow. (like more than 5 digits for C, 3 for H, or 3 for S)

So the C/H/S values can at least hold the full 16+4+8 bit ATA specification as well as the 10+8+6 of the PC/XT int13h format. There's also the 22-bit address limit of the original WD IDE LBA specification. I think the last one just specifies a 22-bit value for the logical block to be used by the disk, so as long as the BIOS spits out the 22-bit block to the drive, various user-side values could be input to result in that output. (though for C/H/S, 12+4+6 bits would be convenient, but a literal 22-bit integer could potentially be specified as well: though IDE drives themselves usually provided C/H/S translated LBA values for the BIOS to use, and I'm not sure what the standard for that was, or if there was only a de-facto one)

22-bits could be split up as 10+4+8 or 12+4+6 for 22 bits, and I'd assume it's one of those two given 28-bit LBA used 16+4+8. And I think the 2GB cap limit setting on older hard drives uses ... or it's possible some BIOSes actually support a 24-bit LBA output from 12+4+8 or 14+4+6 or something like that. (the latter fits into the 8GB limit parameters Windows/DOS has, but that's a separate issue itself)

However, the BIOS code actually used to access/communicate with a hard drive controller might have additional constraints, as does the IDE specification itself, and sector values above 63 will be invalid at the very least, and probably further limits on either the Cylinder count or Head count as well. It might support the full 255 heads (as some translation mapping uses) or only the 16 of the original IDE specification.

It may have also been necessary to enable the 2GB capacity limiting jumper on that 2.5 GB drive if the BIOS natively only decoded 22 bits of address, but the nominal C/H/S values didn't need to be set any differently for that mode and the BIOS still reported the calculated capacity. (but limited the accessible partition to 2048 MB) That or the cap limit jumper didn't even need to be set as the partition for DOS was already at the 2 GB FAT-16B limit. (and I don't think I want to spend $20-30 on another one of those exact drives to try it out ... though I could at least try a larger drive with 16384/16/63 along with a 2GB partition and try with and without the cap limit jumper: I already tried an 8GB FAT-32 partition on a 1992 AMI 486 BIOS and it didn't work, but not 2GB in FAT-16 or 32)

Or it could be that the BIOS stores 16-bits of cylinder data, but ignores the upper 4 bits, so that 2.5 GB drive had 4960 cylinders turn into 864 or 865 (depending how the 12-bit integer is normally interpreted: ie 4096 or 4095) and 16/63 H/S for 425.25 or 425.75 MB actually visible. (and given the limited amount of space actually used in the DOS partition we tried out, that limit wouldn't have been obvious at the time)

I'm not totally sure how the LBA value is used by the disk controller, but it might be possible to input incorrect C/H/S values with BIOS limits and real LBA drive limits both in mind to get useable address space. (like on this 2.5 GB drive, ~2 GB could be useable if the bios supports 12+4+6 C/H/S addressing and the 4095 or 4096 was input as the C value)
The same wrap-around would result if the BIOS uses 10+4+8 bits and ignores the upper 6 bits of Cylinder data. (wraps to 0 every 1024 increments)

I'll have to do more experimenting to work out what's actually happening with these BIOSes.

The articles I've found (and wikipedia) either mention the 22-bit IDE specification without further details, or don't mention it at all.

Also, given so many drives stuck to the 16 head and 63 cylinder constraint while expanding head count beyond 1024 and standard large disks (over 8 GB) report 16383/16/63 geometry, it seems like there was some sort of 24-bit LBA constraint at some point with 14+4+6 bit limits. (that could've even been related to drive-controller side limitations, like wanting to limit address storage to 3 8-bit integers or a single 24-bit word, especially if a Microprocessor or DSP with native 24-bit registers and/or data words was used ... or something like that; I think several popular DSPs worked at 24-bit precision)

Some articles mention BIOSs with a 12-bit Cylinder field limit, but don't go further and connect this up with the 22-bit IDE LBA spec (it fits in nicely as 12+4+6 bits).

Or the 24-bit limitation comes from the IBM int13h disk format using a 24-bit field (10+8+6 bits for 1024/255/63 C/H/S) so the 14+4+6 bit C/H/S layout makes sense, though goes beyond the 22-bit LBA IDE spec. (but might also be the lowest common demoninator layout that got rolled into the 28-bit LBA standard's 16+4+8 bit standard and corresponds to the correct bit-shift-translation data for what DOS sees through the BIOS)

I'm still not sure what that means for old BIOSs and how they actually split out address data to the drives, but for what I'm seeing with these AMI BIOSes with 16+8+8 bit integers actually stored in CMOS (or other NV) memory, it must be storing more bits than needed and clipping/truncating unused ones and also padding out missing ones so the bit-shift-translation works out properly. (so the 16+8+8 bit fields get stored as such by the BIOS, but gets read/used/shifted as 14+4+6-bit values automatically for IDE/ATA disks and must also have provisions for older disks with other int13-compatible geometries ... maybe it defaults to 10-8-6 bits when the Cylinder value is 1024 or smaller, and switches to 14-4-6 if C > 1024, while others further restrict the latter case to 12-4-6 bits to conform to the 22-bit LBA)

As for articles/references See:
https://www.tldp.org/HOWTO/Large-Disk-HOWTO-4.html
http://philipstorr.id.au/pcbook/book4/eide.htm
https://en.wikipedia.org/wiki/Logical_block_a … g#Enhanced_BIOS
https://en.wikipedia.org/wiki/Logical_block_a … #CHS_conversion

I have a 640 MB and 1GB drive that I can test later on, too, but haven't so far. (or tried only the 640MB one a while back, but it got formatted at the wrong capacity by DOS 5.0 and I need to reformat it ... it had had a working Linux Red Hat install on it when I got it, and that probably screwed with things even more)

I still haven't gotten that MB1212C AMI BIOS dumped, but I'll try to get that to you when I have it.

Or maybe a simpler and more practical suggestion based on the above:

take any old IDE/PATA drive you have that's 8GB or smaller and has C/H/S parameters listed, plug them into the user-defined drive option in the BIOS, plug them in and see if it works.

Probably better if you pre-format, partition, and install DOS on a newer machine first, or wipe it. (I think file systems other than FAT and beyond FAT16b might confuse these BIOSs, so either a blank/unformatted drive or one formatted to FAT16b would work better)

But you could always just try any old drive without pre-formatting it and see if DOS can detect it ... though formatting it in a faster/modern machine would also be way faster than on a 12 MHz 286. (also less likely to go wrong, I'd think)

This sort of trial and error is basically what I had in mind for doing myself when I have the time/opportunity (to answer some of the unknowns and guesses I made in the previous post). So if you beat me to it, all the better.

I'm actually tempted to get another one of those 2.5 GB Caviar drives to re-create the set-up from 9 years ago, but I don't think I want to spend around $20 on one like the ebay listings have.

Hi KK ..
glad your're ok ..and active..
Been a bit quiet not hearing from you recently.
Thanks for all the additional info and links ..though a lot of it went swiftly over my old head..🤣
Did you take a look at the link I posted earlier ..where I got my compatible AMI bios ?
The zip was labelled biostar mb-1212c
..which may well be the same bios as yours ..
I have tried hooking up drives larger than 100 mb using geometries manually inputted ..
Like the Seagate St3120A ...and even this refused to allow boot ...but then it did require a cyl count around 1024...which might be why it failed with 'controller failure' meassage..
rgds
VS

For 120A That's 107MB formatted. These vintage hard drives was unformatted size.

I would use 990 x 10 x 17 and delete partitions and start over the partition and format with a dos boot disk.

I would try 1023 x 12 x 17 too. Delete partition and start over. I heard some bios has a problem using 1024 due to funny interactions, and is best way is 1023.

https://stason.org/TULARC/pc/hard-drives-hdd/ … -SL-IDE-AT.html

Cheers,

Yep ..thats sort of the impression I was getting ..
regardless of hard drive type ...1024 was to be avoided as it caused issues I couldn't explain.
rgds

Can you type in custom perimeters?

Issue happens if you are trying to prepare the IDE hard drive on newer computer, then the CHS will be incorrect unless you use a whatIDE utilty on both 286 and newer computer to see what CHS is really is?

SD/CF to ide CHS setup

IF you are trying to use windows 98se DOS on 286, that also will not work. Needs to be 3.xx, 5.0 through 6.22.

Cheers,

I've run into the issue of some drives in the 600-8GB range that do not list precomp or landing zone values, but leaving them at 0 may not work necessarily either and the documentation online doesn't always seem to help.

The solution seems to be the same one used for Compact Flash media: find a board old enough to report all the geometry values in the BIOS but also have a functioning auto-detect feature.

I kept getting corrupt/nonfunctioning DOS 5 installs (and also failures to boot the original Linux Redhad install the previous user had left on it) when manually inputting the C/H/S values on the drive.

https://stason.org/TULARC/pc/hard-drives-hdd/ … -ATA2-FAST.html

Stason also doesn't list the precomp or LZ values, but I finally just tried auto-detect in my OPTI 495 486 board and it successfully sorted that out. WP= 65535 LZ= 1244

Maybe this is standard convention for drives with no explicit WP and LZ? (max 16-bit unsigned integer value for WP and LZ = cylinder count) In which case the auto-detect method wouldn't be necessary.

Oh and here's some screenshots of the AMI BIOS in my board that I'd meant to post a while ago. It may be the same date and revision as yours, but probably has the same feature set regardless.

I also noticed on a Suntac board I've been testing that there's page-mode and interleave support for DRAM, but you need multiple banks of RAM installed for the latter to work. This may be a feature supported on a number of other boards but not user configurable. (with that particular Suntac board, it gives actual T-states for DRAM cycle time settings as well, rather than the vague Wait-State number: also interestingly, enabling page mode and/or bank interleave had much more impact on performance than reducing the DRAM cycle times)

So if a board runs faster with 2 or more banks installed, it's probably got bank interleave support. Not the same thing as modern systems using 2 or more channels for RAM, but the same sort of physical installation deal as far as having matched banks of RAM.

Having EMS enabled might also impact performance on some systems. It seems like it might slow things down slightly on my Hedaka 988, but I'm not sure. (enabling XMS or loading DOS high didn't hurt things, though I know on these 2 D60 boards, overclocking stability is worse with DOS loaded high: tend to crash with A20 errors) Though given the sort of mixed speed performance the D60 boards have, I'm thinking they have page-mode support but also some moderate wait states added somewhere. (the slowest boards probably have neither page-mode or bank interleave support, and I'm thinking my OPTi 486/386 OPTi 495 falls into that category given the abysmal DRAM bandwidth tests as well as sub-286 level performance with all the caches turned off ... but I do have the full 32MB installed in there and maybe it's a weird cases where having fewer banks populated does better)

This does also make me wonder how much faster some of these late 286 boards could go with some cache added. (I've seen just one 286 board with cache sockets listed on the Stason and it's a big, full-AT board of some sort that looks like it's from the early 386 days)

OTOH, I also discovered 20 MHz on those D60 boards runs Wing Commander 1 at just about the proper speed (all the cinematics and music seem correctly timed and in-game rendering only gets slowdown with tons of stuff going on). So I imagine the fastest chipsets at 12-12.5 MHz would still be usable at least and probably just about right at 16-16.7 MHz. I'd thought 25-33 MHz was closer to the sweet spot there, but maybe that's using slow 386 chipsets as the standard. (my Opti board with a 486 DX4 installed actually runs too slow at 25x3 MHz with all cache off, 33 is about right and 40 is slightly too fast; I haven't tried with DX2 or x1 486 or a 386 or DLC)

Then again, maybe that OPTi board also put more effort into faster DMA performance or something. (maybe reserving some of the RAM access slots for ISA/VESA bus masters) The ISA video performance at least seems to be quite good.

So formatting that 2.5 GB Seagate drive I got also worked, but both it and the 640 MB Quantum drive get formatted to 504 MB DOS partitions and fdisk sees those partitions as using the entire disk. (though they do work as 504MB drives)

I assume this is the typical 504/528 MB BIOS limit that only allows DOS to see/access the first 1024 cylinders, though I'm not sure the BIOS is strictly limited to that. (prior to reformatting the 640 MB drive, the full capacity showed up in Fdisk, as 2 non-DOS partitions plus a 64 MB DOS partition from an install attempt I made) So formatting multiple 504MB or smaller FAT16 partitions on a newer machine might work, or might report correctly and then not actually boot or read properly due to lack of BIOS translation. (I haven't gone that far, yet)

I assume we just used a 504MB partition back with that old 286 install and WD Caviar 2.5GB drive.

The XT-IDE cards as well as older (ie 90s era) IDE interface cards with BIOSes onboard also work around the motherboard BIOS limitation, I think, but the software-side workaround used utilitized to format larger disks by bypassing the BIOS and doing their own IDE to DOS (int13, ie XT disk format) translation.

EZ Drive or Ontrack were popular programs used for that.

http://www.vcfed.org/forum/archive/index.php/t-48285.html
^
This thread might help.

OTOH, I thought I'd gotten 512MB CF cards working via auto-detect, but after formatting and installing DOS 5, attempting to boot locks up after printing a couple characters. (very much like the attempts to use the 640MB drive with the incorrect precomp+LZ parameters, but not printing 'Li' this time)

So maybe auto-detect is reporting the wrong geometry. (C/H/S P/LZ = 993/16/63 65535/993)

The 1992 AMI 486 BIOS in the Opti board also has a disk formatting utility, which seems to work but then fails to produce something DOS-5 will accept, at least for the CF cards.

What I read in this thread didn't help my specific problem thus far, though it did make me wary of boot sector viruses. (I did use that BIOS utility to format the CF card before even using Fdisk, so that's probably not an issue here either)

I always put 65535 in precomp section, no needed, IDE and CF takes of this themselves. No need to input landing zone. Leave it 0 or 65535.

Cheers,

Actually that CF card reported as 995 cylinders, not 993.

Another one of the same (apparent) model from the same lot I got off ebay reports 1011/16/63 and after formatting that one it does boot DOS.

Using the BIOS utility on the first one again, but set to 1011 cylinders just ended up with an error when it reached cylinder 995, so it seems only 995 are actually accessible.

I also assume these old BIOSs at least do translation for the default selection of disks. None actually goes above 504MB, but they do have cylinder counts beyond 1024, like the 152 MB drive with 1224/15/17 CHS.

I might try using the FORMAT command on that problem CF card instead of using the DOS setup utility to format it.

Or maybe I'll have to use scandisk to check for bad sectors if some of the flash blocks have gone bad in this one.

pentiumspeed wrote on 2020-04-15, 17:15:

I always put 65535 in precomp section, no needed, IDE and CF takes of this themselves. No need to input landing zone. Leave it 0 or 65535.

I'd think old, smaller IDE drives with explicit precomp and LZ values would still used/need those at least.

Also, using the FORMAT command seems to have solved the problem. (the 995 cylinder flash disk boots fine, now)

I've also been using a single disk 1.44 MB version of DOS 5.1, if that makes any difference. (I think I mistakenly said 5.0 several times previously as well)

Delete partitions. Not trying to format again and again after CHS layout is changed.

pentiumspeed wrote on 2020-04-15, 22:03:

Delete partitions. Not trying to format again and again after CHS layout is changed.

I believe I used Fdisk to delete the partition after each of my failed DOS install attempts. The setup utility recognized an unformatted drive and proceeded to ask whether it should be formatted, then did a reboot before formatting. Doing it that way led to just the letter 'J' printing and then hanging at boot. (though using this same procedure didn't present a problem with the CF card with reported 1011 cylinders)

I never completely formatted the 995 cylinder drive at the incorrect C/H/S values as the BIOS's format utility hit an error at the 995th cylinder, and reverted to the auto-detect 995 value after that. (this was after 2 failed format+install attempts at the auto-detected value) But, following the apparent confirmation that the 995 cylinder value was correct, I used FDISK to remove the partition again and instead of running through setup immediately after that, I used FORMAT instead.

There may also be some artifact related to the single-disk implementation of the DOS setup I'm using, but I'm not sure.

And it's not 5.1. It's 5.00, but I could've sworn I'd seen it identified as 5.1 somewhere in the system or installer text.
MS DOS 5.00 Single Disk.

Though I should try 3.31 at some point since it uses less conventional memory when DOS is loaded low. (for systems without simultaneous EMS+HMA support or for any chipsets that seem less stable with DOS loaded high: since using just the HMA shouldn't require a 286 protected mode handler/switch routine, it must be the A20 gate that's sensitive there or A20 gate + A20 handler code + individual CPU stability quirks) Also obviously relevant to 8088/8086 systems without HMA access in any mode, though some of those might have UMA support which DOS 5 adds some features for.

The EMS vs XMS configuration and A20/UMA stability issue may be relevant to the C&T MB1212C board as well, but I can't test any of that myself currently.

Could you get an IDE card that accepts larger hard drives?