VOGONS


First post, by serialShinobi

User metadata
Rank Newbie
Rank
Newbie

Hello. I have, after several months, installed DOS 6.22 on a motherboard with a 486 chipset and Plug'n Play BIOS.
Thanks for advice I have been given by this forum.

Now I need help getting my facts in order. I have done some reading but I wonder about the opinions of those here with more experience than I have with the industry of IBM clone PCs.

My Configuration:

It's an ESA TF486 motherboard that has an (Acer) Finali M1487/89 PCI chipset and Award BIOS and Pheonix PnP BIOS. The hard disk is a 1998 Samsung 3.4 GB VG33402a. The IDE interface is a 1997 Promise Ultra33.

MS-DOS 6.22 Install steps:

Using a CF, I had load an image file of a bootable DOS floppy using grub4DOS. Then I partitioned the hard drive drive with command "2/PRI:2048" (courtesy of Computer Hope website). Then "Format C: /S". I used floppy images in virtualbox to install DOS 6.22 and xcopy /S to copy installed OS files to a CF card. I used attrib to be able to copy IO.SYS and MSDOS.SYS from C:\. I booted my DOS 486 from it's hard disk and applied CF card directories I copied from the DOS VM.

I had to use a vboxmanage command from oracle virtualbox to create a vmdk image file assigned to the CF card.This is the only way to transfer files from both the VM *and* the computers of the 1990s. https://youtu.be/1CtwnnqdNRY

and xclusive which prevents windows from blocking access to the CF card https://www.kaufmann.no/roland/dskacl/

I believed that BIOS of DOS days can be very proprietary, with no standard, and a cause of my trouble installing DOS.

Now I think it may have been DOS 6.22 all along. Paraphrasing the 1996 BIOS Boot Specification by Pheonix, et al (attached at end of this post): There are several hardware improvements that handle INT13h routines outside of BIOS.

According to Wikipedia
https://en.m.wikipedia.org/wiki/INT_13H

DOS is a real mode operating system where INT13h is tightly bound to BIOS:

The BIOS typically sets up a real mode interrupt handler at this vector
[INT13h] that provides sector-based hard disk...read and write services using (CHS) addressing.

Also I believe my hardware could boot the new way, outside BIOS. The specification suggests my hard disk is capable of being enumerated within PnP BIOS as a list of (IPL) boot devices. The specification also suggests the option ROM on my promise disk interface is made for use with Plug n' Play and this is why the restrictive BIOS scheme was bypassed.

Could DOS real mode have prevented my configuration from bypassing BIOS? Is Windows 9x and protected mode a reason why my configuration made it so easy to install?

Can a BIOS manufacturer have their own way of booting a hard disk? So a BIOS vendor could handle INT13h in a way differing from other BIOS vendors?

Last edited by serialShinobi on 2023-05-06, 17:32. Edited 23 times in total.

Reply 1 of 8, by Deunan

User metadata
Rank Oldbie
Rank
Oldbie
serialShinobi wrote on 2023-05-06, 15:41:

Hello. I have, after several months, installed DOS 6.22 on a motherboard with a 486 chipset and Plug'n Play BIOS.

I'm not entirely sure what your problem actually is? Is the system not booting DOS?

In general using VMs on modern machine is not the same as running on the real hardware. Preferably you should partition, format and install OS on the target machine from floppies (or floppy emulator) - the DOS bootloader is pretty stupid and it's a pretty much single stage scheme so all the code must fit into 512 byte sector. It's nothing fancy. Although maybe you could use something like GRUB to manage it better.

Point is, yes the INT13h routines are a limiting factor, and the BIOS code in general must be able to propery support HDDs up 8GiB for your particular model to work properly. There were several workarounds for the 504MiB limit before LBA addressing came along - these "LARGE" schemes did CHS translation but those might be incompatible between your motherboard and the VM you've been using. Hence why it's better to use the target machine directly.

Additional cards like extra IDE or SCSI can have their own BIOS extension that are loaded and added to mobo own code - for good and bad (these too can have bugs), so yes, having such a card in a system should help. Another way is to use XTIDE, for example by putting the ROM on a network card and installing that in DOS machine (and you will probably need a network card to make file transfers easier anyway). So there are some options to fix the mobo BIOS limitations but again, this should all be tried first on the real hardware.

Reply 2 of 8, by serialShinobi

User metadata
Rank Newbie
Rank
Newbie

Hello. Thanks for the info you shared. I will be trying XTIDE soon. Very important for someone to use if building an old DOS era machine.

For anyone interested I found a good video: "How to flash XT IDE BIOS and use it with your network adapter."

https://youtu.be/5NRHMTGXd94

So my problem is not that I need help getting my 20+ year old DOS project to function; I got it to work.

But I need to know more about difference between windows 95, DOS, and BIOS during boot up.

There is some lack of understanding that has made it more difficult for me to build a 486.

So BIOS has a limit ~504 MB? You mentioned DOS has a limit of 512 MB.

Somehow DOS and BIOS are not compatible in my situation.

I get by with fact my motherboard, though it has a chipset for 486 has PnP 1.0 and a single PCI slot. I have a PCI interface with an option ROM and support for Plug n' Play. Plug n' Play 1.0, my controller, my controller's option ROM, and my hard drive are all mentioned in early draft of the BIOS Boot specification v1.2 of 1995.

I also used a VM and copied C:\DOS from the VM using a CF card and createrawvmdk vboxmanage command.

By the way how is it that the virtual machine could wind up addressing bytes in a way that is unpredictable when it comes to addressing for on a real PC with 1990s hardware?

But I need to address the lack of understanding about why these older machines had parts so incompatible? The vendors had all the information when manufacturing a PC with parts, third party. They were the OEM vendor advertising some brandless box and monitor in the back of computer shopper.

Last edited by serialShinobi on 2023-05-10, 16:50. Edited 2 times in total.

Reply 3 of 8, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

your problem is using VM's to setup a CF image that done via LBA when the motherboard is using CHS.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 4 of 8, by serialShinobi

User metadata
Rank Newbie
Rank
Newbie
BloodyCactus wrote on 2023-05-10, 16:48:

your problem is using VM's to setup a CF image that done via LBA when the motherboard is using CHS.

Yes, so is DOS pre-LBA? Wasn't there a time just prior to 1995 where LBA was supported by DOS if the support was in BIOS? So do could use an LBA disk if BIOS was LBA aware.

I am very interested in DOS around that time before 1995. Maybe even after 1995 during a time when they were phasing out DOS but supporting users of DOS...arming them with newer hardware that was still compatible.

Reply 5 of 8, by maxtherabbit

User metadata
Rank l33t
Rank
l33t

MS-DOS 7 and onward are LBA-aware

Reply 6 of 8, by serialShinobi

User metadata
Rank Newbie
Rank
Newbie
maxtherabbit wrote on 2023-05-10, 17:19:

MS-DOS 7 and onward are LBA-aware

So MS-DOS 6.0 didn't just use BIOS for an addressing scheme? But in v7.0 the software developers went with the newer addressing that would permit hard disks larger than 512MB?

Did someone have to give up CHS so they could have LBA? And so BIOS vendors got sketchy with CHS? It became a incompatible mess to support CHS? And DOS was the victim? The OS could get to the bytes on the hard disk as long as BIOS could...but everyone had their own patented algorithm to support CHS as LBA took the forefront?

Reply 7 of 8, by Jo22

User metadata
Rank l33t++
Rank
l33t++

It's just numbers.. CHS refers to the original model, in which Cylinders, Heads and Sectors corresponded with physical properties of the fixed-disk in the MFM/RLL era.
That's what's now being referred to as P-CHS (physical). But even by the end of the 80s, sector translations were used by ESDI/IDE HDDs internally. So they used L-CHS (Logical).

On PC platform, up to 504MB can be addressed that way, by moving numbers for C/H/S around. The BIOS allows up to 1024 cylinders, 16 heads, 63 sectors.
Neither the HDD nor the BIOS really care if the values are "correct". It's possible to use fake values, as long as they are the same and within the limits of both of them ("it's just numbers").

Then, in the early-mid 90s, there were other translation schemes occuring. Like E-CHS (Extended CHS aka LARGE) which supported up to 7 or 8GB by extending the number of heads.
Up to this point, we're pretty much using standard int13h BIOS functions still, which MS-DOS 5/6 do make use of.

When LBA came along, there was a need to extend the old int13h functions, because the registers could no longer hold larger numbers.
That's when we ended up with "Extended int13h" functions (or "int13h Extentions"), which DOS7 and Windows 9x can understand.

So it's not about CHS vs LBA so much, but about int13h and extended int13h support in BIOS and software.
MS-DOS 7 and up are "LBA aware" and can use HDDs larger than 8GB, though in practice, DOS 7.1 is needed due to FAT32 support.

https://en.wikipedia.org/wiki/INT_13H
http://web.inter.nl.net/hcc/J.Steunebrink/bioslim.htm

PS: There's also a difference between DOS 7.x and Windows 9.x: DOS relies entirely on the drive geometry the BIOS does report back.
Windows 9x, the GUI, does use its own drivers to determine drive geometry after booting up (like esdi_506.pdr).
That's when things can get messy. If DOS 7.x sees a small HDD (as reported by BIOS), but Windows asks the HDD directly via driver and eventually sees a big HDD.

Edit: What also comes to mind is "LBA sectors".
If I understand correctly, LBA has an direct-adressing "mode" in which LBA sectors are being continuous.
It's not so important to our vintage hobby, maybe.

Edited. Edited.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 8 of 8, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

mostly i was alluding to the fact that disk images written using LBA then put into a PC mapping them as CHS usually does not work. mostly its about CHS machines aligning things to cylinders, often how it uses the first track purely for the mbr and starting partitions from the next cylinder, where in LBA they do not, so often the mbr gets fubar'd. you have to take care when using LBA in vm's going to a chs machine. I believe fdisk in linux can use lba and have you set where the chs values lie (Ive dont this for CF cards for my tandy 1000sx), and mounted the image in dosbox and built it that way.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--