Re: [Freedos-user] BIOS weirdness with SATA/IDE adapter (was IDE <-> CF adapters)

[Jon Brase]

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] COWGOL programming language

[dmccunney]

On Sat, Mar 13, 2021 at 2:38 AM  wrote:
>
> Please forgive me if someone has already noted this, but yesterday I came 
> across another programming language which targets DOS and ultimately may be 
> able to be used to compile on DOS. Despite the odd name (COWGOL) is does seem 
> to be a totally serious, useful language. It can be found at 
>  and lists the following as things in 
> its favour:

Yet Another Programming Language.  I haven't seen this one before.
Added to my list, and thanks.

> a properly type safe, modern language inspired by Ada
> the compiler is written in itself and is fully bootstrapped
> a table-driven, easy to port backend (the 80386 backend is 1.2kloc with no 
> other compiler changes needed)
> tiny: the 80386 Linux compiler binary is 70kB (including ELF overhead) The 
> 8080 CP/M compiler 58kB (split across two executables)
> fast: on my PC it’ll compile itself in   80ms.
> global analysis: dead code removal and static variable allocation, leading to 
> small and efficient binaries

It may have been inspired by Ada, but I suspect ancestry in Algol.

An old friend with a PhD in Computer Science (who once worked for BB
and helped build DARPANet) talked about an optimizing Algol compiler
he encountered.  It was self hosted, and written in Algol.

You compiled the source, and got a slow compiler that generated slow
code. You compiled the source again with that compiler, and got a slow
compiler that generated fast code.  Compile a third time with *that*
compiler, and you got a fast compiler that generated fast code.

I think the Ada inspiration was the basis for table-driven, with a
compiler that separated from end analysis from back end code
generation.  That's pretty normal now, with GCC and LLVM both using
the strategy.

No recursion and no floating point will be blockers users need to keep
in mind, but being able to build for 8bit micros like the 8080, Z-80,
and 6502 is a definite plus..

Being able to host the compiler on those architectures is a laudable
goal, but I think most folks will happily cross-compile on a PC,
simply for speed.

> Bruce.
__
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)

[Adam Nielsen via Freedos-user]

> 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)

[Jon Brase]

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