[Freedos-user] COWGOL programming language

[bruce.axtens]

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:

*   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

Bruce.

--

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

[Liam Proven]

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)

[Eric Auer]

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)

[Jon Brase]

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)

[Jon Brase]

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