Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
Hi Jon, Very intriguing. What makes you so certain it's a HPA as opposed to just reducing the disk capacity? My understanding was that HPA areas were used for internal drive housekeeping, or perhaps for manufacturer diagnostics, but since by definition the host can't see it (otherwise it wouldn't be "host protected") it seems surprising it would make the HPA available to the system. One way to confirm this would be to try writing to the boot sector (e.g. by creating some partitions) and then moving the drive to one of the PCs where it works normally. If you can see the partitions on the PC where the SSD works normally then you will know it is not a HPA, however if you can create one set of partitions on the working PC and an entirely different set of partitions on the 130MB BIOS and neither overwrites the other, well then that may well be some weirdness with the HPA. The reason I mention it is because to my knowledge all drives can have their capacity limited via IDE commands, and it sounds to me like this is what is happening rather than any trickery with HPAs. > Since this doesn't occur on a machine with a newer BIOS, I think that the > adapter is picking up on something the old BIOS is doing and is trying to > "help" by telling the drive to set a temporary HPA. Once that happens, the > drive under-reports its size to software that can handle the actual size, > and refuses reads/writes to LBA values in the HPA. You should be able to confirm this theory with a procedure like so: 1. Power up the drive as normal in the 130MB PC. 2. Without removing the power cable, unplug the data cable and connect it to a newer PC where it works normally, ideally one that is already on and supports hot-swap so there is no bus reset required. 3. If the SATA adapter or drive is responsible for returning the 130MB capacity after being switched into some compatibility mode, the drive should appear as 130MB on the new PC as well as it will already be in this mode when connected to the machine. Of course if you plug it into the newer PC but then have to reboot it to get it to detect the drive it may reset it and it goes back to normal, so here's an alternative procedure: 1. Remove the drive's data cable so the 130MB BIOS can't send it any messages, then power on the machine. 2. Boot Linux but pause it at the bootloader (e.g. GRUB), before the kernel starts. 3. Plug in the disk's data cable. 4. Resume booting the Linux kernel. It should reset the IDE bus and detect the drive, without the BIOS having interfered. Without hdparm you could use use "fdisk -l /dev/hda" or "dmesg | less" or similar just to check what capacity came up. The first procedure should confirm or rule out the drive or adapter being switched into a 130MB mode by something, while the second should confirm or rule out whether the BIOS is the one causing this to happen. If it still shows up as 130MB after the second procedure then the BIOS isn't to blame as it wasn't involved in that test, and if it shows up as full capacity in the newer machine after the first procedure then the SSD and adapter would seem to be playing no part in this. This would leave only the IDE chipset in question, which although unlikely, the PCI SATA card would help answer that. > I have various such drives. The BIOS *is* a problem, but there's something > going on beyond *just* the BIOS being a problem: Very interesting - one list of hard drive limits doesn't even list 130MB or 1.3 GB as a problem! https://tldp.org/HOWTO/Large-Disk-HOWTO-4.html > I think the next thing I'll try for the older machine is Liam's > suggestion of > a PCI SATA card. If that works, I'll probably just use the IDE/SATA adapter > I already have on the newer machine where I know that it works without > issue. Let us know how you go, I'd be interested to hear the results. Cheers, Adam. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/13/21 5:42 AM, Adam Nielsen via Freedos-user wrote: As I said before, I suspect what's happening is that the adapter is detecting something that the BIOS is doing while trying to figure out the capacity of the disk, and "helpfully" setting up an HPA on the drive (and doing so so aggressively that all but a thousandth of the capacity of the disk is lost). It wouldn't be a Host Protected Area (HPA) as that by definition is an area the host (PC) can't access under normal conditions. The thing is, an HPA can be either "permanent" or "temporary" (the former case is the default power-on capacity of the drive until the HPA is next resized, the latter lasts only as long as the drive remains powered). I suspect in this case that the adapter is detecting that the BIOS is struggling with the disk size, and "helpfully" setting up a very small HPA on the disk. Each time an the IDE standard was changed to work around a limitation, the standard dictated what to set in the "old" variables which typically were the maximum value possible. So if you plug in a 200 GB disk, a PC with a 504MB limit will see a 504MB disk, a system with a 137GB limit will see a 137GB disk, etc. So the device wouldn't have to do anything special to support an old BIOS. That is indeed what *should* be happening, but I don't think it is. 1) The BIOS in this machine has a 504 MB limit for manually configured drive geometries, but will autodetect some larger geometries (up to a limit I've not yet determined. Often a disk will be detected at something larger than 504 MB but smaller than 8GB, and for most disks, it's different, but generally smaller than the actual size of the drive). However, the autodetected size of the drive in question is only 130 MB. It might, however, have gotten these fixed values wrong. Since modern systems ignore all the obsolete capacity fields if newer ones are present, they wouldn't notice any mistake. But if your system is looking at one of the old capacity fields and seeing the wrong values, perhaps this is why. That could easily be the case for the BIOS, but past kernel version 2.5 Linux is supposed to ignore BIOS information and get the size of the disk directly from the disk. All the Linux kernels I've tried to boot are 2.6 kernels. And the kernel isn't subject to any of the old BIOS limitations, so when it asks the disk it should be asking for the newer capacity fields, and should be getting the full size of the disk. This is indeed what happens when the disk is plugged in to a machine with a newer BIOS. The same applies to OnTrack: it's entire reason for existence is to get disk size information from the disk directly and to intercept BIOS calls for access to large disks that the BIOS would mishandle. So there is no reason it should be seeing the same crippled total disk size that BIOS sees unless the disk (or the SATA adapter) is lying about the total size of the disk. Since this doesn't occur on a machine with a newer BIOS, I think that the adapter is picking up on something the old BIOS is doing and is trying to "help" by telling the drive to set a temporary HPA. Once that happens, the drive under-reports its size to software that can handle the actual size, and refuses reads/writes to LBA values in the HPA. I imagine a diagnostic program might be able to do some probing for IDE devices and show what values are reported by which fields. On a newer machine, hdparm shows CHS values totaling to 8 GB, and LBA values totaling to the correct size of the disk. On the machine in question, I haven't been able to get a Linux instance with hdparm available booted (the Debian installer CD I'm booting from doesn't have hdparm, and the Linux instance I'm trying to bring up on disk won't boot). These also bypass the BIOS and talk to the hardware directly. I used HWINFO to diagnose an issue on a PC once where a drive wasn't visible, and it turned out the PnP ICU I was using had moved the IDE port to the tertiary spot which the BIOS didn't support. So that one definitely bypasses the BIOS as it could see the drive on the 3rd IDE controller the BIOS didn't know about. The machine has 40 MiB of RAM installed. I notice that all three boards show a maximum capacity of 128 MiB of RAM. If I could ever find compatible RAM, that's a tempting option. Is it 72-pin RAM, in pairs? Most Pentium boards were. Although it's becoming less common, it still comes up pretty regularly on eBay where I am. Curious how you get to 40 MB if it's in pairs though as it's not a power of 2, unless it's 48 MB and the video adapter is stealing 8 MB for itself or something like that. One of my replies to Liam has some links to motherboards that are candidates to be the one in this machine, with the 40 MB configuration given as 4M * 36 on the first two banks and either 1M * 36 on the 3rd and 4th, or 2M * 36 on the third. Unless I buy an entirely new optical drive, that will at least stay on IDE, as all the SATA
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/12/21 2:59 PM, Eric Auer wrote: Hi Jon, actually I do not expect "drivers" like OnTrack, Ez Drive etc. to mess with host protected areas. It's not OnTrack that I think is messing with the HPA, it's the SATA <-> IDE adapter. Because when I boot from the OnTrack installation floppy, I find that the disk in question shows up with a reported *physical* (not paritioned) size of 130 MB. This is the same size that a Linux Live CD shows for the disk, even though the kernel version on the disk is recent enough that it only pays attention to what the disk tells it and completely ignores reported BIOS values. So I have two software packages (Linux and OnTrack) which are known to ignore the geometry that BIOS gives them and ask the disk directly (that's the entire *point* of OnTrack), and both of which are known to be able to handle disks (much) larger than 130 MB, and both are reporting the same bogus disk size as BIOS is giving (whereas Linux, at least, gives a correct size for the drive with the same adapter on a machine whose hardware and BIOS are about 5 years newer). My conclusion, then, is that some sort of pathological interaction between the BIOS and the adapter is happening that's causing the adapter to set an HPA on the drive, with the result that the drive reports a bogus capacity when Linux/Ontrack gets control of the machine and starts querying the drive for its size, and also refuses I/O to addresses beyond the HPA limit. Most likely, I think is that the adapter is seeing a certain pattern of ATA commands from the drive that indicates to it that the BIOS is having trouble with the size of the drive, and is "helpfully" setting an HPA to cripple the drive down to whatever it thinks the BIOS can handle (which turns out being less than the biggest drive geometry the user can manually set in BIOS, which is in turn less than the biggest geometry the BIOS can auto-detect). ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
> As I said before, I suspect what's happening is that the adapter > is detecting something that the BIOS is doing while trying to figure > out the capacity of the disk, and "helpfully" setting up an HPA on > the drive (and doing so so aggressively that all but a thousandth of > the capacity of the disk is lost). It wouldn't be a Host Protected Area (HPA) as that by definition is an area the host (PC) can't access under normal conditions. Each time an the IDE standard was changed to work around a limitation, the standard dictated what to set in the "old" variables which typically were the maximum value possible. So if you plug in a 200 GB disk, a PC with a 504MB limit will see a 504MB disk, a system with a 137GB limit will see a 137GB disk, etc. So the device wouldn't have to do anything special to support an old BIOS. It might, however, have gotten these fixed values wrong. Since modern systems ignore all the obsolete capacity fields if newer ones are present, they wouldn't notice any mistake. But if your system is looking at one of the old capacity fields and seeing the wrong values, perhaps this is why. I imagine a diagnostic program might be able to do some probing for IDE devices and show what values are reported by which fields. These also bypass the BIOS and talk to the hardware directly. I used HWINFO to diagnose an issue on a PC once where a drive wasn't visible, and it turned out the PnP ICU I was using had moved the IDE port to the tertiary spot which the BIOS didn't support. So that one definitely bypasses the BIOS as it could see the drive on the 3rd IDE controller the BIOS didn't know about. > The machine has 40 MiB of RAM installed. I notice that all three > boards show a maximum capacity of 128 MiB of RAM. If I could ever > find compatible RAM, that's a tempting option. Is it 72-pin RAM, in pairs? Most Pentium boards were. Although it's becoming less common, it still comes up pretty regularly on eBay where I am. Curious how you get to 40 MB if it's in pairs though as it's not a power of 2, unless it's 48 MB and the video adapter is stealing 8 MB for itself or something like that. > Unless I buy an entirely new optical drive, that will at least stay > on IDE, as all the SATA optical drives in the house are in use by > other computers. OTOH, the prospect of actually being able to boot > the thing directly from optical is enticing. You can get IDE/SATA converters quite cheaply. I bought a few of these ones as they cost me under $5 each including shipping, and they are bidirectional, allowing IDE drives to plug into SATA controllers, but also allowing (one) SATA drive to plug into an IDE controller: https://www.aliexpress.com/item/4000263683410.html You don't have another old IDE drive larger than 130 MB you could plug in just to rule out the BIOS as the problem? It really sounds to me like the SSD is just reporting the wrong values. Does the manufacturer have any configuration programs you can use? Many drives can have their capacity reprogrammed to work in environments where a specific size is required (e.g. an existing RAID array) so experimenting with that could be an option. Cheers, Adam. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
Mar 12, 2021 7:30:03 PM Liam Proven : >Caveat: you might find that it only has enough tag RAM in its L2 cache to >cache 64MB of RAM. >This was quite common in early Pentium boxes. Finding tag RAM these days is... >unlikely, I suspect. I'm not holding my breath about finding RAM of any kind for this machine. >In my testing, adding more RAM past 64MB actually slowed down machines without >enough tag RAM. So that would probably slow it down under DOS/Win95, but under Linux total memory usage on the machine tends to be around 120 MiB, so an upgrade to 128 MiB would greatly reduce pressure on swap, which can only improve performance. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On Fri, 12 Mar 2021 at 20:56, Jon Brase wrote: > > As far as I can tell, OnTrack partitions the disk as part of installing its > translation scheme. Yup, I think so. Haven't used it this century, TBH. > So I have an existing disk, and took an image of each partition on it with > partimage(1). > > I got my new SSD+adapter, partitioned it (with blank partitions), blasted the > partition images to the new partitions, and expanded the filesystems to fill > the > partitions. And then ran into trouble with no more than the first 130 MB of > the SSD > showing up when booted in this machine (it's fine in another IDE machine > that's > ~5 years newer, which is the machine I used to do the imaging). Really, at > least Linux > *should* have been booting at that point, because kernel versions as recent > as what > I'm using are *supposed* to ignore the information that comes from the BIOS > on drive > sizes. So I beat my head against the wall trying to get that working, gave > up, and decided > to nuke everything to the ground and start over with OnTrack. Then it turned > out that > even OnTrack doesn't see more than the first 130 MB of the disk, which makes > me really > suspect that more than just BIOS is involved (as the entire point of OnTrack > is to work > around BIOS limitations). As I said before, I suspect what's happening is > that the adapter > is detecting something that the BIOS is doing while trying to figure out the > capacity of the > disk, and "helpfully" setting up an HPA on the drive (and doing so so > aggressively that all > but a thousandth of the capacity of the disk is lost). Augh! :-( This does sound nasty. I had a quick look around for PCI (as in, _not_ PCI-e) SATA controllers. There seem to be plenty around the $15-$25 mark. Whether that would be affordable and worthwhile for you, only you can judge. I found a tiny handful of ones that explicitly say that they have a BIOS but they tend to be a lot more expensive. It's the sort of thing you _might_ pick up super-cheap on eBay or something. > The case is marked as an AST Bravo MS P/75. The information I can find on > that online suggests it has one of the following two mainboards: Aha! I used to have one of its kin, an AST Premmia. It was a dual Pentium 100 box; I ran NT 4 Server on it, running an external RAID in a huge SCSI-2 cabinet containing 7 * full-height 5.25" SCSI hard disks + 4 CD-ROMs. It was a very cheap server, and very robust for many years. > The machine has 40 MiB of RAM installed. I notice that all three boards show > a maximum capacity of 128 MiB of RAM. If I could ever find compatible RAM, > that's a tempting option. Caveat: you might find that it only has enough tag RAM in its L2 cache to cache 64MB of RAM. This was quite common in early Pentium boxes. Finding tag RAM these days is... unlikely, I suspect. In my testing, adding more RAM past 64MB actually slowed down machines without enough tag RAM. N.B. tag RAM is not the same as cache RAM; it's part of what controls the cache. Upgrading the cache (e.g. with a COAST -- cache-on-a-stick -- module) normally did _not_ upgrade the tag RAM. > It has a riser with 2 ISA slots and a PCI slot on the left side, and an ISA > and a PCI on the right. The ISA slots on the left side are occupied with an > ethernet card and a soundblaster. The PCI slot on the left looks like it may > be fouled by the ethernet card, there's not a lot of space between it and the > ISA slot above, and I'm not sure if I could actually fit a card into that > slot without it coming into contact with the ethernet card. The slots on the > right side are free. > Unless I buy an entirely new optical drive, that will at least stay on IDE, > as all the SATA optical drives in the house are in use by other computers. > OTOH, the prospect of actually being able to boot the thing directly from > optical is enticing. Well, there are PCI SATA controllers with an IDE channel too... https://www.amazon.com/Rosewill-RC-212-Controller-Supports-non-RAID/ https://www.amazon.com/VT6421A-3-Port-SATA-Raid-Controller/dp/B000YMJ6ZE/ I have also read that some SATA-EIDE converters work in both directions, sometimes set with a jumper. So maybe you could use the one you already have, IIUIC, to attach a PATA optical drive to a SATA port... :-/ -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
Hi Jon, actually I do not expect "drivers" like OnTrack, Ez Drive etc. to mess with host protected areas. They just redirect attempts to access the disk by BIOS to their own code, which modifies the BIOS call parameters. Which is why OS which access disks without using the BIOS have to be configured to do suitable transformations themselves (e.g. Linux offset boot parameter) or use suitable drivers made for the specific OS in question. But you make a very important point about the transparency of the process. In the days when DOS was normal, you could probably get everything converted during the driver install process get away with it. But as soon as you have a system with 2-99 operating systems on disk, it is A LOT easier to first install the "driver" BEFORE you install any of your operating systems at all. Because otherwise, even if you take partition images and everything, you WILL end up with having to do elaborate tuning to get things to boot again. Boot managers tend to be RATHER sensitive about where and on which disk geometry the system that you want to boot is. So if you install a "driver" which changes that or even shifts everything to another offset on the disk, you will have to have some serious explaining to do until the boot process cooperates with you again. Then it's a lot easier to start with the "driver" and then install the OS of your choice later. You may still backup your files as files or in tarballs, not as disk/partition images, to add them to the freshly reinstalled OS later. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
Drat, sent my reply to Dennis only (again... :-/); resending to the whole list. On 3/10/21 5:31 PM, dmccunney wrote: I can't agree. We are not in the single-user, single tasking DOS days when one thing was going on at a time. At any moment, there are a number of things going on in a current consumer computer. Some of them will be OS routines, and some will be programs. Users may well start a program that will take time to do what it does (like compile code to create an executable,) push it into the background, and do other things in the foreground. Yes, but the point is that the user tends to have trouble finding enough for the machine to do. There may be an audio program so they can listen to music while they do things like work on code in an editor, or review documentation, and a download manager or a torrent client uploading/downloading in the background. While writing this e-mail with Rhythmbox playing in the background, my system load average has remained below 1, with significant amounts of time below 0.4. On a four-core machine, that means any given core is only spending 10%-25% of its time with a process scheduled. The human is the slowest component in the chain, but waiting for the human is *not* the only thing that machine will be doing. Not the only thing, but still the primary thing. I have occasionally started long running processes and gone to bed, assuming they would be domn in the morning. I'm out of the loop, but the machine is not in a wait state. It's still doing work. As have I. But most of the time I don't have such things for it to do. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/11/21 4:37 AM, Liam Proven wrote: Also, IIUC, you are trying to access _existing_ partitions? No, I do not think a disk manager will help you there. Disk managers bypass the BIOS restrictions by remapping or translating disks' real values, but they do not just fix the problem. Once you have a disk manager installed, I think you will need to create _new_ partitions after getting a DiskMgr working, using whatever translated scheme it creates. As far as I can tell, OnTrack partitions the disk as part of installing its translation scheme. So I have an existing disk, and took an image of each partition on it with partimage(1). I got my new SSD+adapter, partitioned it (with blank partitions), blasted the partition images to the new partitions, and expanded the filesystems to fill the partitions. And then ran into trouble with no more than the first 130 MB of the SSD showing up when booted in this machine (it's fine in another IDE machine that's ~5 years newer, which is the machine I used to do the imaging). Really, at least Linux *should* have been booting at that point, because kernel versions as recent as what I'm using are *supposed* to ignore the information that comes from the BIOS on drive sizes. So I beat my head against the wall trying to get that working, gave up, and decided to nuke everything to the ground and start over with OnTrack. Then it turned out that even OnTrack doesn't see more than the first 130 MB of the disk, which makes me really suspect that more than just BIOS is involved (as the entire point of OnTrack is to work around BIOS limitations). As I said before, I suspect what's happening is that the adapter is detecting something that the BIOS is doing while trying to figure out the capacity of the disk, and "helpfully" setting up an HPA on the drive (and doing so so aggressively that all but a thousandth of the capacity of the disk is lost). However, saying all that: I do not see any info about what the host machine is. The case is marked as an AST Bravo MS P/75. The information I can find on that online suggests it has one of the following two mainboards: A) https://stason.org/TULARC/pc/motherboards/A/AST-RESEARCH-INC-Pentium-BRAVO-MS-P-75-221478-F01.html B) https://stason.org/TULARC/pc/motherboards/A/AST-RESEARCH-INC-Pentium-BRAVO-MS-P75-202759-111-2.html However, the actual layout of the board in the case is more like this (given as Bravo MS/MS-T/MS-L): C) https://stason.org/TULARC/pc/motherboards/A/AST-RESEARCH-INC-Pentium-BRAVO-MS-MS-T-MS-L-PENTIU.html C), interestingly, is not supposed to run at 75 MHz (that page shows jumper settings for 60, 66, 90, and 100 MHz), but software running on the physical board (not the blueprint :-) ) detects the CPU as running at 75 MHz. The machine has 40 MiB of RAM installed. I notice that all three boards show a maximum capacity of 128 MiB of RAM. If I could ever find compatible RAM, that's a tempting option. It has a riser with 2 ISA slots and a PCI slot on the left side, and an ISA and a PCI on the right. The ISA slots on the left side are occupied with an ethernet card and a soundblaster. The PCI slot on the left looks like it may be fouled by the ethernet card, there's not a lot of space between it and the ISA slot above, and I'm not sure if I could actually fit a card into that slot without it coming into contact with the ethernet card. The slots on the right side are free. If it is new enough to have PCI slots, then a SATA controller with a BIOS of its own should, in theory, bypass all this nightmare. Citation with model recommendations: https://www.vogons.org/viewtopic.php?t=62958 A firmware-equipped SATA controller (i.e. not some cheap thing that just adds additional ports and is not bootable) will appear to the PC as a SCSI controller and its firmware will take over the INT13 BIOS calls for disk access completely. If you do decide to go that route, though, I advise _against_ mixing SATA and EIDE/PATA disks. Let the SATA controllers' firmware take over completely and do not use the motherboard's EIDE channels at all. Unless I buy an entirely new optical drive, that will at least stay on IDE, as all the SATA optical drives in the house are in use by other computers. OTOH, the prospect of actually being able to boot the thing directly from optical is enticing. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On Wed, 10 Mar 2021 at 17:51, dmccunney wrote: > > I had a Unix machine at home before I got the XT clone. I was Tech > Support Manager for a small Unix systems house that resold AT kit > when AT was in the computer business, and an AT 3B1 joined the > family. [...] I have heard of the 3B1, 3B2 etc., but never actually seen hardware. The anti-monopoly breakup of "Ma Bell" was about the time I entered secondary school. Over in the British Isles, AT were a very minor, little-known foreign company with no real influence and I am not sure that they sold hardware at all. The European computer industry very much went its own way in the 1980s and American companies were just one among many vendors. Commodore and Atari were significant, but Tandy (Radio Shack) were not. I never was a TRS-anything outside of shop display units in Tandy stores. I think they were just too expensive. Similarly I read articles praising Apple for the first sub-US$1000 home computer, but since that was twice the price of a used car, they were way too expensive for the UK market and I don't think I personally knew anyone with an Apple home computer. Sinclair Research with its sub-GB£100 home computers made the splash here. These machines were affordable to ordinary families, costing just a month or two of disposable income. Apple computers cost most of a year's disposable income. > As of DOS 2.X, > MS adopted a hierarchical file system, tree structured directories, > I/O redirection and other Unix concepts, but implemented thyem very > differently.) True. MS did have a dual-OS strategy at one point: Xenix for the high end, DOS for the low end, but it never panned out. There's a lot of disinformation about why they picked the forward slash for switches and the backslash for directories. The truth is that it was from DEC TOPS-10 and nothing to do with CP/M. http://www.os2museum.com/wp/why-does-windows-really-use-backslash-as-path-separator/ > After looking at an assortment of freeware and shareware versions of > Unix commands, I bought a commercial package called the MKS Toolkit. [...] Heard of it. Never saw it. I work for a Linux vendor, and I've been using xNix since 1988 and SCO Xenix 286, but I've never been a fan of xNix. Mainly because I am not a programmer and I never liked C. Did you ever look at Coherent? For the time it was the most impressive xNix for PC-compatibles. It's open source now. > [...] When I was booted into the Korn > shell, you had to dig a bit to discover you *weren't* on an Honest-to > $DEITY Unix machine. (And I was able to craft an equivalent of the > Unix lp print spooler using the DOS print command and Korn shell > scripts and aliases.) Very impressive! > Right. You were in the UK. I'm aware of the stuff you ran, but never > have a chance to play with it here. Yup. It goes both ways. PCs never caught on over here until Amstrad made the first affordable clones -- the PC 1512 and PC 1640. These were about 1986 or so. https://en.wikipedia.org/wiki/PC1512 They were something like ¼ of the price of American clones such as Compaq, which meant that these were expensive business computers. Amstrads were just about affordable as quite expensive home computers. My Archimedes came out a year later and was so much faster than an Amstrad that it could run a PC Emulator entirely in software and still give usable performance. I ran tools like QuickBASIC on mine, and did real work on it. It had about the performance of a 2-3MHz 8088, but with a *very* fast hard disk (as the Acorn OS was caching it underneath). So a 1987 Acorn was in the region of 20-30× faster than a 1986 PC clone. And yet Acorn failed and the PC thrived. It's all about the apps and always was. Acorn's CPU, the ARM, is of course now the best-selling CPU in the world, the basis of the new "Apple Silicon" Macs and Microsoft is still trying to get Windows to run *well* on it. > Er, the OS might actually reside on ROM chips, but I assume there was > at least some RAM usage when calling OS functions. The OS might be in > ROM, but OS routines would need scratch space in RAM. Oh, yes, absolutely. But it meant that a 1MB machine was entirely usable and you got _most_ of that meg for your own apps. You could even have a RAMdisk in part of that 1MB and still have a usable amount of space. > (And the DR DOS variant of DOS originated from requests by Digital > Research customers for a ROMmable DOS. MS had not seperated code > space and data space, so MSDOS c0uld not be put in ROM. DR DOS could.) I did not know that! I knew it was ROMmable but not that this was the genesis of DR DOS. Thanks! > I have OS/2 here, but never got to install it on anything. OS/2 was > technically superior to Win3.1, and could still be found in kiosk > applications not that long back. I had OS/2 Warp on a specialized > telephony server at an employer. It was a black box. It just ran. > If it hung, reboot it. I never had to dig into OS/2 itself. It was and is
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On Thu, 11 Mar 2021 at 00:32, dmccunney wrote: > > On Wed, Mar 10, 2021 at 5:07 PM Jon Brase wrote: > > On 3/9/21 4:35 PM, dmccunney wrote: > > > As a general rule, consumer machines are I/O bound, not compute bound. > > > The CPU spends most of its time in an idle loop waiting for stuff to > > > be read from/written to disk. > > > > Actually, as a general rule, on a consumer machine, both the CPU and the > > disk spend most of their time waiting for user input to give them > > something to do. Disk waits are nothing compared to the eternity between > > the keystrokes of a fast typist, and that's if the user is neither away > > nor lost in thought. > > I can't agree. We are not in the single-user, single tasking DOS days > when one thing was going on at a time. Agreed. Way back in the mid-1990s I ran the testing labs for one of the UK's largest computer magazines, PC Pro. (Known as "PC @uthority" in Australia.) I organized a labs test of PCs with Win NT 4. This really showed which manufacturers knew their stuff. In the Pentium 1 era, Intel really advanced the art of motherboard chipsets. Its old 82430 "Neptune" chipset for the 5V Pentium (60MHz & 66MHz) was very conventional. The 82430 FX "Triton" chipset for the 3.3V Pentium (75/90/100/120/133MHz) was a revelation. Its EIDE controller, the PIIX chip, could do busmastering I/O, allowing the disk drives to use DMA to put data into RAM. A device driver was supplied on floppy. On Win9x this made little difference because its limited kernel could not overlap I/O. But on NT, even with 1 CPU, it was very different. Without the busmastering driver, each disk access used programmed I/O. NT booted as slowly as 9x. With the driver, when NT booted, you could *hear* when the kernel started executing. Disk access went from tick-tick-tick, tick-tick, tick-tick-tick-tick, to bzt-bzzzt-bzzt-bzt. Once the driver triggered, not only did disk access get quicker, but the CPU could get on with something else while it occurred. So your PC booted noticeably faster -- it took minutes off a long boot sequence -- and you could continue to use the PC even under very heavy disk load. It's not just a question of the CPU sitting waiting any more, although that's true, it does. But with a modern OS with a pre-emptive kernel, it can queue up a bunch of I/O commands and then leave that particular I/O subsystem to its own devices (literally!) and go off and do something else while the subsystem does the work and puts the data direct into RAM without CPU intervention. Now that multicore CPUs are standard this is even more important. One core can be doing a virus scan while another core is doing a spellcheck and another core is servicing the UI so your PC still responds to you. To measure it, for example, one can set a program transcoding a video file, which running standalone would take say 10min, and then run a script that puts Photoshop through its paces for about 10min. On a system without DMA I/O, with both tasks running, they will take on the order of twice as long. With DMA I/O, a background task will only slow the foreground task by a few %. For me, as someone who used to do benchmarking for a living, this was one of the biggest advances I ever saw in personal computing since the 1980s, and it went almost totally unnoticed in the industry as a whole -- sadly a lot of folk writing about computing in the 21st century lack training, scientific literacy, and a basic understanding of statistics and ideas like a significant or insignificant difference. I've seen websites making buying recommendations based on measuring external sources' bar charts with a ruler, when they did not notice that the Y axis did not begin at zero. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On Wed, 10 Mar 2021 at 22:37, Jon Brase wrote: > Unfortunately, it's not working. OnTrack sees the same ultra-small capacity > for the drive as the BIOS and Linux see on that machine. It picks up the > other 40 GB 2.5" PATA drive, but the SSD + Adapter can't be extended from > what the BIOS sees to the actual size of the drive. I even tried a different > SSD on the adapter, and got almost the exact same crippled size (130 MB), so > I don't even get to test if Linux's offset parameter works, even OnTrack > isn't seeing the full drive size. > > My working theory at this point is that the adapter is detecting that it's > working wtih an old BIOS and "helpfully" setting up a temporary Host > Protected Area on the drive, after which it refuses to acknowledge that any > area after the 130 MB mark even exists until poweroff. I haven't been able to > boot an environment that has hdparm(8) available, so I haven't been able to > test this. OK, I was alarmed by the mention of "SSD + adapter" so I went back and reread the root message. (I can't go back 2 months because I only just re-subbed to the list after a decade (!) away.) But it's a SATA-to-PATA adapter? That introduces an extra layer of complexity to the question. :-( Also, IIUC, you are trying to access _existing_ partitions? No, I do not think a disk manager will help you there. Disk managers bypass the BIOS restrictions by remapping or translating disks' real values, but they do not just fix the problem. Once you have a disk manager installed, I think you will need to create _new_ partitions after getting a DiskMgr working, using whatever translated scheme it creates. Therefore I would backup the data on the existing drive onto another machine, perhaps a networked one; zero the disks, or at least their first 1kB or so, to erase any exiating partitions; try to create _new_ partitions with the DiskMgr's translation in effect; then copy the data back. (If this includes a bootable OS, then e.g. boot from a Linux live medium, CD or DVD or USB, and connect to the machine with the backups over the network and use Linux to restore the data onto the newly-repartitioned machine. However, saying all that: I do not see any info about what the host machine is. If it is new enough to have PCI slots, then a SATA controller with a BIOS of its own should, in theory, bypass all this nightmare. Citation with model recommendations: https://www.vogons.org/viewtopic.php?t=62958 A firmware-equipped SATA controller (i.e. not some cheap thing that just adds additional ports and is not bootable) will appear to the PC as a SCSI controller and its firmware will take over the INT13 BIOS calls for disk access completely. If you do decide to go that route, though, I advise _against_ mixing SATA and EIDE/PATA disks. Let the SATA controllers' firmware take over completely and do not use the motherboard's EIDE channels at all. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On Wed, Mar 10, 2021 at 5:07 PM Jon Brase wrote: > On 3/9/21 4:35 PM, dmccunney wrote: > > As a general rule, consumer machines are I/O bound, not compute bound. > > The CPU spends most of its time in an idle loop waiting for stuff to > > be read from/written to disk. > > Actually, as a general rule, on a consumer machine, both the CPU and the > disk spend most of their time waiting for user input to give them > something to do. Disk waits are nothing compared to the eternity between > the keystrokes of a fast typist, and that's if the user is neither away > nor lost in thought. I can't agree. We are not in the single-user, single tasking DOS days when one thing was going on at a time. At any moment, there are a number of things going on in a current consumer computer. Some of them will be OS routines, and some will be programs. Users may well start a program that will take time to do what it does (like compile code to create an executable,) push it into the background, and do other things in the foreground. There may be an audio program so they can listen to music while they do things like work on code in an editor, or review documentation, and a download manager or a torrent client uploading/downloading in the background. The human is the slowest component in the chain, but waiting for the human is *not* the only thing that machine will be doing. I have occasionally started long running processes and gone to bed, assuming they would be domn in the morning. I'm out of the loop, but the machine is not in a wait state. It's still doing work. _ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/9/21 4:35 PM, dmccunney wrote: As a general rule, consumer machines are I/O bound, not compute bound. The CPU spends most of its time in an idle loop waiting for stuff to be read from/written to disk. Actually, as a general rule, on a consumer machine, both the CPU and the disk spend most of their time waiting for user input to give them something to do. Disk waits are nothing compared to the eternity between the keystrokes of a fast typist, and that's if the user is neither away nor lost in thought. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/10/21 10:50 AM, dmccunney wrote: The fascinating bit for me is that the distinction between RAM and disk is steadily blurring. Things like nVME make it possible to have what works like RAM but is non-volatile storage whose content will survive a reboot. We are just scratching the surface here. I don't think this will make as much difference as people often think. Remember, we've been there before: Core memory was non-volatile, and some of the really early machines had drums for main memory, but systems that were born on architectures with storage that was 100% physically non-volatile still ended up with a distinction between logically volatile working memory and logically non-volatile long term storage, and were thus able to transition to volatile transistor RAM with minimum fuss. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
Accidentally responded to Liam instead of the whole list, resending. On 3/9/21 3:40 PM, Liam Proven wrote: On Tue, 9 Mar 2021 at 22:28, Jon Brase wrote: On 3/3/21 7:30 AM, Liam Proven wrote: Yes. Use a disk manager. It will install a tiny overlay before the OS boots and that will allow you to use arbitrarily-large disks without problems. (Probably not with Linux, but with DOS, Win9x, OS/2 and maybe even NT). Actually, it looks like, through kernel 2.5., Linux explicitly detected and worked with both OnTrack and EasyDrive. Since that version, it has a tunable offset parameter that can be set appropriately for either one by the user (63 sectors for OnTrack, 1 for EasyDrive). All other avenues seem to have failed, so I may well be going that route next. That is actually quite impressive! I did not know that. Thanks for the info. Once installed, it's a good, simple, easy solution. I used to use them a lot back in the day (late 1990s, roughly.) Unfortunately, it's not working. OnTrack sees the same ultra-small capacity for the drive as the BIOS and Linux see on that machine. It picks up the other 40 GB 2.5" PATA drive, but the SSD + Adapter can't be extended from what the BIOS sees to the actual size of the drive. I even tried a different SSD on the adapter, and got almost the exact same crippled size (130 MB), so I don't even get to test if Linux's offset parameter works, even OnTrack isn't seeing the full drive size. My working theory at this point is that the adapter is detecting that it's working wtih an old BIOS and "helpfully" setting up a temporary Host Protected Area on the drive, after which it refuses to acknowledge that any area after the 130 MB mark even exists until poweroff. I haven't been able to boot an environment that has hdparm(8) available, so I haven't been able to test this. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On Wed, Mar 10, 2021 at 10:10 AM Liam Proven wrote: > On Tue, 9 Mar 2021 at 23:37, dmccunney wrote: > > > > On my old XT clone, I had a replacement 10mhz motherboard with a NEC > > v20 CPU. The V20 was compatible with the Intel 8088, but had better > > microcode, for a cheap 5% speedup. It had 640K RAM and two Seagate > > ST-225 MFM HDs. I got it an AST- 6Pak K addon card that added another > > megabyte of RAM. AST software let me make 512MB of the RAM a RAMdisk, > > 256K a dick cache, and he oter 256K could be EMS for apps that could > > use it. (I made the RAMdisk first in my PATH, and put frequently used > > apps like LIST there, and set TEMP and TMP to point to it so things > > that honored that would use the RAMdisk for temp files. It sped up > > Zipping stuff a treat. A freeware utility could map unused video RAM > > to DOS. I used a Hercules video card, so 64K were available to be > > mapped to DOS, and the machine booted reporting 704K DOS RAM. > > Performance was acceptable, thank you. > > That sounds like a *very* seriously tricked-out XT-class machine! Wow! I had fun with it. I had a Unix machine at home before I got the XT clone. I was Tech Support Manager for a small Unix systems house that resold AT kit when AT was in the computer business, and an AT 3B1 joined the family. The 3B1 was the beefier sibling of the UNIX-PC, an early attempt at a single user Unix workstation. It had a 10mhz Motorola 68010 CPU, with up to 4MB RAM (mine had 3.5MB) and a 72MB MFM HD. It ran Unix System V Release 2. There was a well crafted GUI called FACE that could be used on the mono console (and a character mode version that could run on attached terminals. The keyboard had a variety of special keys that did things when pressed. One of the things I wanted was compatibility between apps I used on the 3B1 and on the PC. I was able to compile Daniel LAwrence's MicroEMACS "out of the box" for the 3B1, and had fun writing an ME macro that examined KB input and would do the appropriate things when I pressed one of the special keys. Because I started as a Unix guy, I wanted to make the XT clone look as much like a Unix machine as possible. (I also got my SO a 3B1, and she thought DOS was a brain damaged Unix. Well, yes. As of DOS 2.X, MS adopted a hierarchical file system, tree structured directories, I/O redirection and other Unix concepts, but implemented thyem very differently.) After looking at an assortment of freeware and shareware versions of Unix commands, I bought a commercial package called the MKS Toolkit. The toolkit was a product of Mortice Kern Systems in Canada. They were consulting engineers who wrote it originally for internal use, and released it as a product when it was sufficiently developed. It became the tail that wagged the dog, and their principal business. The toolkit implemented full versions of all Unix commands that made sense in a single user, single tasking environment. The selling point for me were complete versions of the Unix vi editor and Korn shell. (The Korn shell had everything save asynchronous background processes because DOS didn't *do* that.) Installed in fullest Unix compatibility mode, when the PC was booted, CONFIG.SYS got processed. It loaded the RAMdisk, cache and mouse drivers that were common to everything. But instead of COMMAND.COM as a boot shell, the Toolkit's INIT.EXE was loaded. INIT printed Login: on my screen. Enter a userid and (optional) password and INIT called LOGIN. LOGIN looked for the ID in a Unix compatible /etc/passwd file. IF it found a match, it changed to whatever directory was specified as that ID's home directory, and ran whatever was specified as the ID's shell I had IDs that ran the Korr shell, vanilla COMMAND.COM, 4DOS, and DesqView. Exit those programs and INIT was reloaded. I could switch environments *without* rebooting. When I was booted into the Korn shell, you had to dig a bit to discover you *weren't* on an Honest-to $DEITY Unix machine. (And I was able to craft an equivalent of the Unix lp print spooler using the DOS print command and Korn shell scripts and aliases.) The Toolkit stayed in use when I got a 386 and started running Win 3.1. The shell for Win3.1 was Program Manager, but you could substitute something else. What was used was defined in the SYSTEM.INI file. I had custom SYSTEM.INI files to run different shells, and Toolkit IDs that copied them over the real one so Win3.1 ran the one I wanted to use. But because Win3.1 was a multi-tasking shell on top of DOS, I could choose not to run it, and boot into COMMAND.COM, 4DOS, DV, or the Korn shell. Lots of fun while it lasted. > MS OSes were always a work thing for me. My own computers went > Sinclair -> Amstrad PCW (the last new CP/M computer) -> Acorn > Archimedes. Right. You were in the UK. I'm aware of the stuff you ran, but never have a chance to play with it here. > For £800 – probably under $1500 at the time – I had an 8MHZ RISC >
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On Tue, 9 Mar 2021 at 23:37, dmccunney wrote: > > On my old XT clone, I had a replacement 10mhz motherboard with a NEC > v20 CPU. The V20 was compatible with the Intel 8088, but had better > microcode, for a cheap 5% speedup. It had 640K RAM and two Seagate > ST-225 MFM HDs. I got it an AST- 6Pak K addon card that added another > megabyte of RAM. AST software let me make 512MB of the RAM a RAMdisk, > 256K a dick cache, and he oter 256K could be EMS for apps that could > use it. (I made the RAMdisk first in my PATH, and put frequently used > apps like LIST there, and set TEMP and TMP to point to it so things > that honored that would use the RAMdisk for temp files. It sped up > Zipping stuff a treat. A freeware utility could map unused video RAM > to DOS. I used a Hercules video card, so 64K were available to be > mapped to DOS, and the machine booted reporting 704K DOS RAM. > Performance was acceptable, thank you. That sounds like a *very* seriously tricked-out XT-class machine! Wow! MS OSes were always a work thing for me. My own computers went Sinclair -> Amstrad PCW (the last new CP/M computer) -> Acorn Archimedes. For £800 – probably under $1500 at the time – I had an 8MHZ RISC computer with 1MB of flat unsegmented RAM in 1989. And none was used for the OS, because it ran from ROM chips. When my Archimedes died, I got a 486DX 50MHz notebook -- not a DX/2, just DX -- and I ran OS/2 2.0 on it. Even though it only had 8MB of RAM, it ran well. > The current desktop uses a quad core Intel i5 CPU and 3.5 ghz, with an > automatic turbo mode to 3.9 ghz. It has 20GB RAM, and boots and runs > from a 256B PAnasonic SSD. Performance is lovely. There are faster > machine out there, but since I'm not doing things like heavy video > editing or compiling a large application from a source tree, it's > moare tyhan adequate for what I do. That is a pretty good spec! O_o Yes, I find that since the point at which quad-core CPUs were affordable, performance no longer matters much. I buy used kit if possible, mostly laptops now, according to things like keyboard quality and screen resolution. So long as it has, say, a Core i5 and enough RAM or the RAM is cheap to add, it will do. I still have some Core 2 machines in use; they're fine for light use, despite being over a decade old. Koomey's Law has truly supplanted Moore's Law now. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On Tue, Mar 9, 2021 at 4:41 PM Liam Proven wrote: > Installing a CPU upgrade in an old PC was rarely worth the hassle, but > if you replaced a small hard disk (especially if compressed with > DoubleSpace or something) with a big more modern one, and maxed out > the RAM, the performance improvement was often very gratifying for a > relatively small spend. As a general rule, consumer machines are I/O bound, not compute bound. The CPU spends most of its time in an idle loop waiting for stuff to be read from/written to disk. More RAM is one speedup - it allows the OS to do a better jo9b of caching disk access. A faster disk is another. On my old XT clone, I had a replacement 10mhz motherboard with a NEC v20 CPU. The V20 was compatible with the Intel 8088, but had better microcode, for a cheap 5% speedup. It had 640K RAM and two Seagate ST-225 MFM HDs. I got it an AST- 6Pak K addon card that added another megabyte of RAM. AST software let me make 512MB of the RAM a RAMdisk, 256K a dick cache, and he oter 256K could be EMS for apps that could use it. (I made the RAMdisk first in my PATH, and put frequently used apps like LIST there, and set TEMP and TMP to point to it so things that honored that would use the RAMdisk for temp files. It sped up Zipping stuff a treat. A freeware utility could map unused video RAM to DOS. I used a Hercules video card, so 64K were available to be mapped to DOS, and the machine booted reporting 704K DOS RAM. Performance was acceptable, thank you. The current desktop uses a quad core Intel i5 CPU and 3.5 ghz, with an automatic turbo mode to 3.9 ghz. It has 20GB RAM, and boots and runs from a 256B PAnasonic SSD. Performance is lovely. There are faster machine out there, but since I'm not doing things like heavy video editing or compiling a large application from a source tree, it's moare tyhan adequate for what I do. > Liam Proven __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On Tue, 9 Mar 2021 at 22:28, Jon Brase wrote: > > > On 3/3/21 7:30 AM, Liam Proven wrote: > > Yes. Use a disk manager. It will install a tiny overlay before the OS > > boots and that will allow you to use arbitrarily-large disks without > > problems. (Probably not with Linux, but with DOS, Win9x, OS/2 and > > maybe even NT). > > Actually, it looks like, through kernel 2.5., Linux explicitly > detected and worked with both OnTrack and EasyDrive. Since that version, > it has a tunable offset parameter that can be set appropriately for > either one by the user (63 sectors for OnTrack, 1 for EasyDrive). All > other avenues seem to have failed, so I may well be going that route next. That is actually quite impressive! I did not know that. Thanks for the info. Once installed, it's a good, simple, easy solution. I used to use them a lot back in the day (late 1990s, roughly.) Installing a CPU upgrade in an old PC was rarely worth the hassle, but if you replaced a small hard disk (especially if compressed with DoubleSpace or something) with a big more modern one, and maxed out the RAM, the performance improvement was often very gratifying for a relatively small spend. In one friend's machine, I did this _and_ an IDT WinChip CPU upgrade. The old boot HDD I retained but made drive D: and put the Windows swapfile on it. This was a small faff as it was a low-profile Dell and there wasn't a suitable 2nd HDD bay. I improvised with cable ties and duct tape. Later on he bought a new box and gave it to his dad. His dad had a friend around to install a new program on it or something trivial and got curious about the drive arrangement. A message was relayed from friend to father to son to me: "whoever upgraded your son's old PC for him _really_ knew what he was doing! I've never seen an old 486 perform so well, so I opened it up. Tell your son's mate that he did the neatest, tidiest and most comprehensive upgrade I've ever seen!" So, that was nice. :-) -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On 3/3/21 7:30 AM, Liam Proven wrote: Yes. Use a disk manager. It will install a tiny overlay before the OS boots and that will allow you to use arbitrarily-large disks without problems. (Probably not with Linux, but with DOS, Win9x, OS/2 and maybe even NT). Actually, it looks like, through kernel 2.5., Linux explicitly detected and worked with both OnTrack and EasyDrive. Since that version, it has a tunable offset parameter that can be set appropriately for either one by the user (63 sectors for OnTrack, 1 for EasyDrive). All other avenues seem to have failed, so I may well be going that route next. Jon Brase ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
On Wed, 3 Mar 2021 at 13:11, Jon Brase wrote: [...] > when I input a manual drive size, I indeed get the 504 MiB limit (it resets [...] > Any ideas? Yes. Use a disk manager. It will install a tiny overlay before the OS boots and that will allow you to use arbitrarily-large disks without problems. (Probably not with Linux, but with DOS, Win9x, OS/2 and maybe even NT). OnTrack's version is now freeware: https://www.philscomputerlab.com/ontrack-disk-manager.html There are alternatives such as EZDrive: https://www.philscomputerlab.com/western-digital.html More info: https://www.rigacci.org/docs/biblio/online/firmware/diskmgr.htm Just be careful using boot disks -- you need the disk manager on your boot disks too. Boot from a non-disk-manager disk and writing to the drive *will* corrupt it. -- Liam Proven – Profile: https://about.me/liamproven Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
Hi Jon, sounds as if your BIOS has various issues with large drives indeed :-o Have you tried the usual workaround software which installs a "driver" in the actual MBR and shows the geometry-sanitized rest of the drive as if it were the drive? There even are Linux kernel options to correct for the sector number offsets caused by that, because of course Linux does not need that driver. Dynamic Drive Overlay, EZ Drive, something Ontrack are keywords which come to mind - not sure, though. Do I understand you correctly that the hardware originally is IDE-only, so your converter is to connect SATA drives to your IDE mainboard? Having a 1024x16x63 504 MB limit is quite evil, even worse than 8 GB or 128 GB limits. Must be a rather old BIOS. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)
Two months later... On 12/22/20 7:11 AM, Eric Auer wrote: (I've rearranged Eric's original posting somewhat because responding to this paragraph makes for a good introduction to where I am now it was originally towards the end of his e-mail) You could get yourself a converter to connect SATA drives (SSD or mechanical) to your IDE computer: I think SATA will stay available for a long time and you can always use the first 504 (528) MB even without extra drivers or BIOS fixes. I ended up going with a SATA SSD on a SATA/IDE converter, plus a a magnetic IDE disk (both in 2.5" form factor). But here's where things get weird, as I've discovered while trying to get everything working: when I input a manual drive size, I indeed get the 504 MiB limit (it resets CHS counts greater than 1024/16/63 to 1 as soon as I hit enter). If I put in a larger drive, fully partitioned and tell BIOS to auto-detect CHS, the machine chokes on it (and, as I recall, if you manually enter an incorrect CHS count, it rejects the drive). If I put in a larger drive with a single small partition, the machine accepts the drive, and *may* autodetect it with more cylinders/heads than it will allow me to enter manually (though not necessarily up to the full capacity of the drive), and then if I partition the drive on another machine, it will continue accepting the drive. The size corresponding to this auto-detected CHS count does not seem to match the size of the drive, the size of the partition used during the initial auto detection, or any of the classical drive size limits (504 MiB, 8 GiB, etc). For the 40 GiB magnetic swap drive I went with, this size is somewhere over a gigabyte. For the 128 GiB SSD, however, it actually detects with *less* than the number of cylinders/heads it allows me to enter manually (only 123 MiB!). All of the partitions I'm migrating over are larger than 123 MiB, so it breaks (MS/Free)DOS, Win95, and Linux, 'cause DOS can't handle it's partition not being accessible to BIOS, and GRUB can't load Win95 or Linux. What's worse, when I boot the system off a Debian install CD, Linux seems to believe BIOS as to the disk size, and treats any attempt to access anything beyond that as an I/O error. Parted refuses to even display the partition table on either disk. Linux fdisk does somewhat better, it displays both partition tables, and displays the correct size of the 40 GiB magnetic disk, but only shows a 123 MiB size, and gives warnings about the partitions that extend beyond 8 GiB until I use expert mode to give it CHS counts that correspond to the actual size of the disk. Hi! If you say you have a 512 MB BIOS limit, your limit probably is 512 * 63 * 16 * 1024 bytes, in other words a limit in the number of "heads" (those do not relate to actual surfaces). This is the manual configuration limit in BIOS for the machine. Are you sure FreeDOS is affected when you use LBA? Note that the limit is only 504 * 1024 * 1024 bytes, so depending on how you count the 512 MB for the first partition, you might already be beyond the limit. Since my last writing, I actually had a look at the contents of the partition again, and the DOS partition was actually significantly bigger than 504 MiB (still well under a GiB), but even MS-DOS hadn't been giving trouble on the original disk (both MS and FreeDOS exist on that partition). And of course you could consider updating your BIOS to fix the "528 MB" problem, or install a MBR-installed workaround such as ontrack / ezdrive :-) I wonder if UHDD could help you, too, as long as the boot files are in the first 504 MB. I know of one person that worked for the manufacturer that might know where I could find a BIOS update for the machine, but I'm not holding my breath (BIOS date is 1995, and the manufacturer is defunct). I have two theories about what's happening under Linux: either the drive/SATA adapter is detecting that it's dealing with an old BIOS and actively crippling itself to present the BIOS with a geometry it can deal with, so that once Linux is booted on that machine the drive is actively refusing reads/writes beyond the 123 MiB mark, or else Linux is getting the drive size from BIOS (possibly via Grub) at boot and is taking the BIOS value at face value and refusing to touch any part of the disk beyond that. In the first case, maybe there's something that can be done to make the drive/adapter not cripple itself (hdparm -N looks promising if that's the issue). In this case I might be able to get DOS / Win95 working on the SSD (if the drive isn't reporting a ridiculously small capacity, then the BIOS autodetect might give me a workably big space for my FAT partitions, and Linux will get the full real size of the drive and have the rest of the space to itself). In the second, I imagine there has to be some kernel command line switch that can be passed to tell Linux "BIOS is completely unreliable, ask the drive directly how big it is". In this case I'm
