[Freedos-user] BIOS

[Marcos Favero Florence de Barros]

Hi,

I was wondering whether one of the reasons why old computers
fail is that the BIOS gets corrupted over time because it is
stored in rewritable media.

Many of the old computers that I'v tried to reuse seem to have
problems in keyboard, floppy and CD operation, which, I believe,
are directly related to the BIOS.

If that is so, then perhaps flashing the BIOS might fix this
kind of problem.


Marcos



--
Marcos Fávero Florence de Barros
Campinas, Brazil



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS

[Mateusz Viste]

In my (limited) experience, old computers tend to be unuseable because 
of a leaking onboard battery that corrodes the copper lines on the PCB 
around it (often that's where the keyboard controller is, which 
translates as 'non working keyboard').

regards,
Mateusz



On 12/14/2014 01:26 PM, Marcos Favero Florence de Barros wrote:
> Hi,
>
> I was wondering whether one of the reasons why old computers
> fail is that the BIOS gets corrupted over time because it is
> stored in rewritable media.
>
> Many of the old computers that I'v tried to reuse seem to have
> problems in keyboard, floppy and CD operation, which, I believe,
> are directly related to the BIOS.
>
> If that is so, then perhaps flashing the BIOS might fix this
> kind of problem.
>
> Marcos

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS

[dmccunney]

On Sun, Dec 14, 2014 at 7:26 AM, Marcos Favero Florence de Barros
 wrote:

> I was wondering whether one of the reasons why old computers
> fail is that the BIOS gets corrupted over time because it is
> stored in rewritable media.

It is, but what actually rewrites that media?  In general, it's
non-volatile memory, and written to only by a BIOS update operation
that reflashes the NVRAM.

> Many of the old computers that I'v tried to reuse seem to have
> problems in keyboard, floppy and CD operation, which, I believe,
> are directly related to the BIOS.
>
> If that is so, then perhaps flashing the BIOS might fix this
> kind of problem.

I've owned an assortment of hardware over the decades.  My hardware
issues have never involved a corrupted BIOS.  The biggest culprit has
been a power supply failure, which can take the motherboard with it.
I've also had an assortment of hard drives go bad.  I have seldom had
a problem that reflashing the BIOS cured.  On the occasions I have
reflashed a BIOS, it was to correct an issue with the BIOS that was
resolved by a manufacturer update, and I was upgrading to a new
version.  The existing BIOS did not simply degrade over time.

> Marcos
__
Dennis
https://plus.google.com/u/0/105128793974319004519

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS

[Felix Miata]

Marcos Favero Florence de Barros composed on 2014-12-14 10:26 (UTC-0200):

> I was wondering whether one of the reasons why old computers
> fail is that the BIOS gets corrupted over time because it is
> stored in rewritable media.

> Many of the old computers that I'v tried to reuse seem to have
> problems in keyboard, floppy and CD operation, which, I believe,
> are directly related to the BIOS.

Might depend on how old is "old". A huge number of motherboards and power
supplies made starting shortly after the turn of the century and for the
following half decade or so were made using capacitors that don't last[1].
Before total failure occurs, all kinds of wierd things can happen or not as
their defects begin manifesting.

> If that is so, then perhaps flashing the BIOS might fix this
> kind of problem.

Unlikely, but possibly.

[1] http://en.wikipedia.org/wiki/Capacitor_plague
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS

[Ralf Quint]

On 12/14/2014 4:26 AM, Marcos Favero Florence de Barros wrote:
> Hi,
>
> I was wondering whether one of the reasons why old computers
> fail is that the BIOS gets corrupted over time because it is
> stored in rewritable media.
>
BIOS is for quite a wile in a FlashROM type of memory, which is only 
re-writeable in a special write mode, which is only done very rarely, 
when in fact you are "flashing" the BIOS. And it is very unlikely that 
this will get corrupted easily. You might confuse this withe the CMOS 
RAM, which is used by the BIOS to hold (and easier change/write to) user 
changable values. But even then, this isn't likely to get corrupt, 
unless you have some rogue programs that are accessing it constantly.

If you have external peripherals fail as you mentioned, it is rather due 
to possibly bad settings (the least likely but not impossible option) or 
IMHO more likely, to connectors or peripheral circuitry going bad...

Ralf

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] bios updating

[tomasz orzechowski]

Hi. I want to flash new bios to my motherboard. Is it safe to use freedos
instead of msdos for bios flashing purposes? Are there any problems with
this?
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] BIOS services

[Hans]

Hi Eric,

You replied some time ago to a user that asked which BIOS services are 
required to support FreeDOS, could you (or anybody else) please list those 
services again. For some reason the link below is no longer valid.

Thanks
Hans
www.ht-lab.com


Hi, the short answer is: YES.
You can run FreeDOS on 8086.

> is it possible that freeDOS work on an embedded system without BIOS?

The answer for that is longer. Searching for "embed" on
http://fd-doc.sourceforge.net/faq/cgi-bin/search.cgi
will point you to:
http://fd-doc.sourceforge.net/faq/cgi-bin/viewfaq.cgi?faq=./incoming/277
which explains which BIOS services you have to provide for a minimal
FreeDOS install (in other words, services which are needed by the kernel
itself - depending on which DOS programs you want to run, you may need
additional BIOS parts loaded).

Note that running FreeDOS on a pre-286 will use a lot of RAM.
Normally, FreeDOS will move most of the kernel to HMA (right
after the first 1 MB) and the FreeCOM shell will use XMS for
swapping, so it only uses a small amount of DOS memory. As your
80186 has no HMA and no XMS, both the kernel and the FreeCOM
command.com shell will have to use DOS memory for everthing,
so I think only 400-500 kilobytes of DOS RAM will be free. On
a 286 system, it is easy to have more than 600 kilobytes free
with FreeDOS. On a 386 with EMM386 or another UMB driver loaded,
you can even use dosdata=umb / loadhigh / devicehigh to get more
than 620 kilobytes of the 640 kilobytes of DOS RAM free.

Of course you will also be unable to do some 386-specific things,
including: emm386, caching, dosfsck, booting from LBA FAT32 drives,
himem (but you can use fdxms instead of himem if you have at least
a 286 or newer processor). If EDIT or KEYB fail on your 80186, try
EDIT 0.7d and MKEYB, which should work even on 8086. Or use no
keyboard driver at all (if you use US keyboard layout). Let us know
if you find other programs which do not work on 80186 processors.

To get started, download the kernel and shell or a minimal boot disk
from http://fdos.org/kernel/ - you should probably not use the big
ISO distros (beta9sr2: 12 MB, Blair's full ISO: 120 MB). But you can
use the ODIN one diskette distro with many preinstalled programs.

Eric

PS: Feel free to add corrections / ideas to the FAQ entry about 80186.




-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] bios updating

[Florian Xaver]

Hi Tomasz,

I didn't have a problem. 

Bye
Flo

El mié, 24-09-2008 a las 13:18 +0200, tomasz orzechowski escribió:
> Hi. I want to flash new bios to my motherboard. Is it safe to use
> freedos instead of msdos for bios flashing purposes? Are there any
> problems with this? 
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___ Freedos-user mailing list 
> Freedos-user@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/freedos-user


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] bios updating

[Eric Auer]

Hi!

> Hi. I want to flash new bios to my motherboard.
> Is it safe to use freedos instead of msdos for
> bios flashing purposes? Are there any problems with this?

Basic answer: The risk is similar in both cases.

Avoid emm386 / jemm386 / jemmex / USB drivers, try
to boot from something simple (floppy? cdrom/dvd?
maybe not USB?) to reduce load on BIOS built-in
USB drivers, maybe even use non-USB keyboard/mouse.

Actually better avoid mouse drivers for flashing
anyway. It might even make sense to avoid HIMEM /
HIMEMX as well and use FreeCOM 0.82pl3 command.com
instead of 0.84 or 4DOS or other modern shells...

Problem with flashing is that your BIOS is in a
state of transition. You just boot DOS to get the
BIOS update file to the BIOS update tool and then
you hope that nothing touches the BIOS or disk or
other hardware any more apart from the tool itself.

The best way to get this is to have no special
drivers (not even BIOS built-in ones) busy and
use a tool which does not access DOS while it
does the actual modifications. That said, most
BIOS flash tools are really simple for any DOS
and flashing should be safe enough as long as
you keep the number of drivers reasonably low,
disable energy saving features (in BIOS and in
FDAPM etc) and do not touch (mouse, network, USB,
keyboard...) the computer in the critical moment.

Eric



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] bios updating

[tomasz orzechowski]

thanks for answers
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS services

[Aitor Santamaría]

Hello,

2008/9/25 Hans <[EMAIL PROTECTED]>:
> a 286 or newer processor). If EDIT or KEYB fail on your 80186, try
> EDIT 0.7d and MKEYB, which should work even on 8086. Or use no
> keyboard driver at all (if you use US keyboard layout). Let us know
> if you find other programs which do not work on 80186 processors.

PLAIN WRONG.
FD-KEYB is supposed to work on 8088 (although not reports yet), where
MKEYB does NOT, because MKEYB relies on some BIOS int15h, that older
BIOSes usually do not have.

EDIT:  there's no reason why EDIT 0.9a shouldn't work, because nothing
was changed about it.

Eric, again recommended the programs you like (or you release)...
Aitor

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS services

[Eric Auer]

Hi Aitor, Hans,

> > a 286 or newer processor). If EDIT or KEYB fail on your 80186, try
> > EDIT 0.7d and MKEYB, which should work even on 8086. Or use no
> > keyboard driver at all (if you use US keyboard layout). Let us know
> > if you find other programs which do not work on 80186 processors.

> FD-KEYB is supposed to work on 8088 (although not reports yet), where
> MKEYB does NOT, because MKEYB relies on some BIOS int15h...

Oops sorry I remembered KEYB and MKEYB exactly the wrong way round!
Thanks for letting us know that EDIT 0.9a is compiled for 8086 :-)
I did not mean to "make your programs bad" - more trying to say
"if X should fail, you could try Y instead"...

Eric

PS: My caches require 386+ because they need XMS: Only fdxms286
which is not extremely stable can provide XMS on 286, and I did
not bother to make caches 286 compatible as they are rare now.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS services

[Aitor Santamaría]

Hello,

2008/9/28 Eric Auer <[EMAIL PROTECTED]>:
>
> Hi Aitor, Hans,
>
>> > a 286 or newer processor). If EDIT or KEYB fail on your 80186, try
>> > EDIT 0.7d and MKEYB, which should work even on 8086. Or use no
>> > keyboard driver at all (if you use US keyboard layout). Let us know
>> > if you find other programs which do not work on 80186 processors.
>
>> FD-KEYB is supposed to work on 8088 (although not reports yet), where
>> MKEYB does NOT, because MKEYB relies on some BIOS int15h...
>
> Oops sorry I remembered KEYB and MKEYB exactly the wrong way round!
> Thanks for letting us know that EDIT 0.9a is compiled for 8086 :-)
> I did not mean to "make your programs bad" - more trying to say
> "if X should fail, you could try Y instead"...

What made you suppose that EDIT 0.9a was not compiled for 8086?

Amongst the different options you have your favourites (JEMM over
FD-EMM, MKEYB over FD-KEYB, etc) and such. What is dangerous is that
you barely say: "these are my favourites", but "these are the ones you
must use". At times, even not being real what you say, as was the
case.

Aitor

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS services

[Eric Auer]

Hi!

> Amongst the different options you have your favourites (JEMM over
> FD-EMM, MKEYB over FD-KEYB, etc) and such. What is dangerous is...

Depends. I prefer to say that you can try using X instead of Y
and it may work better. It may also work worse! It is more about
"trying something else" and not about "trying something better".

However, I must say I do not like JEMM. Here some comparison...

KEYB - many layouts, supports codepage switching, several files
MKEYB - at most dozens of layouts, one file, easy, for 286+ BIOS

HIMEM - classic, works quite okay, focus on compatibility
HIMEMX - Win9x optimized defaults, fixes bugs, less compatibility

EMM386 - classic, some special functionality incomplete
JEMM386 - low RAM footprint, more complete functionality, needs
  more command line options for a "focus on compatibility" config
JEMMEX - HIMEMX and JEMM386 combined into one program, no way to
  use it with another HIMEM or with EMM386-incompatible games etc.

The two JEMM... also support protected mode (driver) plugins but
so far no really cool ones are available. A port of the old XCDROM
and XDMA drivers exists. UIDE is newer but not yet ported :-).

I hope it is clear that the above is mostly a matter of my own
taste and opinion, but I also hope it reflects some of the real
differences between variants. Feel free to discuss wrong parts.

Eric



-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] BIOS update from CD

[Gustavo J Mata]

I need to update the BIOS of a computer with Ubuntu Linux installed. I own a
second computer, an iMac running OS X 10.6.

To the iMac I have  downloaded both the BIOS updater and the  fdfullcd.iso
image.  What I want  to do is create a bootable freedos CD* with the BIOS
updater in it.*

How do I do this?

I'd prefer to use the iMac for this, but I could also use the Ubuntu
machine.

Thanks in advance,

Gustavo J. Mata





-- 
«La ignorancia, aliada con el poder, es el más feroz enemigo que puede tener
la justicia.» (James Baldwin)

Visite mi Blog en Apartaderos 
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS update from CD

[Mike Eriksen]

On Fri, Mar 18, 2011 at 10:20 PM, Gustavo J Mata  wrote:
> I need to update the BIOS of a computer with Ubuntu Linux installed. I own a
> second computer, an iMac running OS X 10.6.
>
> To the iMac I have  downloaded both the BIOS updater and the  fdfullcd.iso
> image.  What I want  to do is create a bootable freedos CD with the BIOS
> updater in it.
>
> How do I do this?
>
> I'd prefer to use the iMac for this, but I could also use the Ubuntu
> machine.

Ubuntu solution: Get the Balder floppy image of FreeDOS:

mount -t vfat -o loop balder10.img superfloppy
Add the imagewriter and the image in the superfloppy folder
umount superfloppy
mkisofs -o superfloppy.iso -b balder10.img balder10.img
Burn the iso.

Mike

> Thanks in advance,
>
> Gustavo J. Mata

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] BIOS update FreeDOS enabled ISO

[Mihai Rusu]

Hi

I recently had to upgrade quite some number of systems with latest BIOS 
versions (to support latest CPU models, RAM speeds, fix annoying bugs 
etc). Some systems have floppy and CDROM, some just one of those. Usually 
the vendor requires a single method, floppy or CDROM (most require 
floppy). But beeing limited to the system hardware I had to improvise a 
lot (booting with Windows installation CDs, switching CDs, flasshing etc).

I want to automate this process, ie to prepare some scripts to quickly 
setup a floppy or a CD, bootable (with FreeDOS) and on which I also copy 
the BIOS upgrade files which I need at that point.

Has anyone did this ? Any problems of using FreeDOS with BIOS flashing 
software ? Anyone has some hints ? (like how to get only the FreeDOS 
kernel and command.com from a FreeDOS distroy, how to make a bootable 
floppy or CD iso from those on linux)

Thanks!

-- 
Mihai RUSUEmail: [EMAIL PROTECTED]
GPG : http://dizzy.roedu.net/dizzy-gpg.txtWWW: http://dizzy.roedu.net
   "Linux is obsolete" -- AST


---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] BIOS, SCSI, 8Gb and TUNS

[Gerry Hickman]

Hi,

I tried some rough tests today with BIOS, SCSI and TUNS. Here's are some 
results.


In an eariler post I said I'd seen drive sizes reported as 8Gb with SCSI 
when the drives are actually much bigger. I thought it was related to 
not using a SCSI driver and BIOS (INT13) reporting wrong size, and Eric 
said it wasn't. I think Eric is right, but my BIOS has been updated 
since I last seen this problem, so it's impossible to say what caused it.


I tested today, FreeDOS Beta9 SR1, but with updated HIMEM and EMM386, 
two physical SCSI drives of 36Gb each on Adaptec 29160N controller. SCSI 
BIOS has both INT13 support enabled, and also INT13 support for drives 
larger than 1Gb enabled. Asus AV333 motherboard, AMD Athlon 2100+


Test1 (this is really two tests):

Load FreeDOS with HIMEM only; first WITH SCSI driver, then WITHOUT SCSI 
driver.


Result1:

Drive size is reported correctly in both FDISK and PQMAGIC in both cases.

However, enter EMM386 and ALL BETS ARE OFF! I mean total meltdown, with 
both FDISK and PQMAGIC saying the drives were not partitioned and giving 
totally crazy readings for disk sizes. The EMM386 line was this:


DEVICE=SPECIAL\EMM386.EXE VDS NOEMS X=TEST /verbose

When I tried to load my SCSI driver after EMM386 and it just hung.

I then tested all the above with UMBPCI and everything worked perfectly.

Testing TUNS:

I now had a stable system, so decided to test loading LBACACHE high, 
both with and without TUNS.


If I don't have UMBPCI loaded, it's a bit silly because LBACACHE won't 
load high, and I don't know if TUNS makes any difference. Output was as 
follows:


DISK 0X80 HEADS 0255 SECTORS 0063
DISK 0X81 HEADS 0255 SECTORS 0063 [DONE]

I then tested with UMBPCI loaded, and told LBACACHE to INSTALLhigh 
without TUNS, it did exactly as it was told (checked mem /c /p), and 
there were no timeouts. It gave the exact same output


DISK 0X80 HEADS 0255 SECTORS 0063
DISK 0X81 HEADS 0255 SECTORS 0063 [DONE]

Here is my FDConfig.SYS file:

;device=special\fdxms.sys
DEVICE=DRIVER\HIMEM.EXE /NOABOVE16 /X
;DEVICE=SPECIAL\EMM386.EXE VDS NOEMS X=TEST /verbose
device=other\umbpci.sys

rem Load the SCSI for 29160N card
;device=other\aspi8u2.sys /d

rem UDMA hard drives
;DEVICE=DRIVER\UDMA2.SYS

DEVICEhigh=OTHER\VIDE-CDD.SYS /D:FDCD

devicehigh=OTHER\ramdrive.sys 4096 512 1024 /e
;devicehigh=OTHER\ifshlp.sys

rem lbacache tuns switch is needed for SCSI and UMBPCI
INSTALLhigh=DRIVER\LBACACHE.COM
SHELL=COMMAND.COM A:\ /E:1024 /F /MSG /P=.\FREEDOS\FDAUTO.BAT

DOSDATA=UMB
DOS=high,UMB
FILES=20
BUFFERS=20
LASTDRIVE=Z



--
Gerry Hickman (London UK)


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS update FreeDOS enabled ISO

[Johnson Lam]

On Wed, 23 Jun 2004 12:32:06 +0300 (EEST), you wrote:

Hi,

Make sure you got exactly same kind of hardware, otherwise you'll
destroy the BIOS and fail to recover.

>Has anyone did this ? Any problems of using FreeDOS with BIOS flashing 
>software ? Anyone has some hints ? (like how to get only the FreeDOS 
>kernel and command.com from a FreeDOS distroy, how to make a bootable 
>floppy or CD iso from those on linux)

I didn't see any problem using FreeDOS, but for safety you don't have
to load memory manager or other programs, just clean boot FreeDOS.

For Award Flash program it have command line support, so you only need
to put the latest BIOS image and supply the correct filename and
parameter in AUTOEXEC.BAT then it'll automatically FLASH the BIOS
after boot.

Don't forget to change the BIOS setting to "Flashable".

If you're not using Award and need to keypress, try find PC Magazine's
"KEYFAKE", it'll pretend to press some key when the program waiting
for input.


Rgds,
Johnson.



---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS update FreeDOS enabled ISO

[Bernd Blaauw]

Mihai Rusu wrote:
Hi
I want to automate this process, ie to prepare some scripts to quickly 
setup a floppy or a CD, bootable (with FreeDOS) and on which I also copy 
the BIOS upgrade files which I need at that point.

Has anyone did this ? Any problems of using FreeDOS with BIOS flashing 
software ? Anyone has some hints ? (like how to get only the FreeDOS 
kernel and command.com from a FreeDOS distroy, how to make a bootable 
floppy or CD iso from those on linux)
The MKISOFS program can create cd files (ISO9660).
BIOS flashing usually requires to clean boot DOS, so no memory drivers, no 
ramdrives, etc..

procedure is fairly simple:
-download a FreeDOS diskette image.
-mount it on Linux.
-remove everything except kernel.sys/command.com
now put your flash program on the diskette(-image) (Uniflash for example, 
freeware), and the BIOS file.

you now have everything on the disk except a file to automatically start the 
flashing process.
if you want to automate this, create a file a:\autoexec.bat:
@uniflash mybios.rom

make sure you use the correct commandline.
For my motherbord it was:
amiflash 2885v202.rom /a /b /e /c
the cd creation is simple:
-you have the diskette image
-use a MKISOFS front-end program (GUI) to create your cd, and point to the 
diskette image as a boot source.

I'll work on giving a downloadable diskette/cd for the Tyan BIOS that I have.
Much more can be done.
One improvement for example would be to put a copying program on the bootable 
cd, so you can create a bootdisk when inserting an empty diskette
(use the XCOPY tool).

Bernd
---
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
___
Freedos-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

[Gerry Hickman]

Gerry Hickman wrote:

In an eariler post I said I'd seen drive sizes reported as 8Gb with SCSI 
when the drives are actually much bigger. I thought it was related to 
not using a SCSI driver and BIOS (INT13) reporting wrong size, and Eric 
said it wasn't. I think Eric is right, but my BIOS has been updated 
since I last seen this problem, so it's impossible to say what caused it.


After further reading, it seems this kind of thing was originally more 
of a problem with IDE/ATAPI drives, as opposed to SCSI. Here's an 
extract from a page talking about INT13:


http://www.fixup.net/tips/20gb/20gb.htm

--- start here ---

Technical Explanation

In PC, hard drive is accessed via BIOS Interrupt 13 calls.  Old Int13 
routines has limit for 500MB, 8GB or 30GB drives.  An extension to Int13 
has been added to newer BIOS to eliminate the limit.  Therefore, newer 
BIOS has no this limit.  For old BIOS, an overlay program, such as 
MaxBlast II, can be used to load this extension before OS loading, so 
the Int13 calls are translated into extension calls.


Old OSs, including DOS, Win3.xx and NT, were not aware of this extension 
and therefore always need an overlay program to use large hard drives . 
 Newer OSs, including Linux and Win95/98/Me/2000/XP, are aware of the 
extension and do not rely on an overlay to access hard drive after OS 
loading.  Therefore, performance and reliability of an overlay program 
is not an issue once these OSs are started.  However, they do matter 
during OS loading and unloading and that's why some overlay programs 
(such as IBM DM) cause trouble during standby and hibernation.


--- end here ---

--
Gerry Hickman (London UK)


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

[kd4d]

Hi Gerry:

Ah, yes, ...  :-)  Try emm386 without the VDS argument 
and under no circumstances run FreeDOS FDISK unless 
you want to risk an erased partition table.

Thanks for reporting this.  Let us know what happens without
the VDS argument to EMM386!

Mark


> Hi,
> 
> I tried some rough tests today with BIOS, SCSI and TUNS. Here's are some 
> results.
> 
> In an eariler post I said I'd seen drive sizes reported as 8Gb with SCSI 
> when the drives are actually much bigger. I thought it was related to 
> not using a SCSI driver and BIOS (INT13) reporting wrong size, and Eric 
> said it wasn't. I think Eric is right, but my BIOS has been updated 
> since I last seen this problem, so it's impossible to say what caused it.
> 
> I tested today, FreeDOS Beta9 SR1, but with updated HIMEM and EMM386, 
> two physical SCSI drives of 36Gb each on Adaptec 29160N controller. SCSI 
> BIOS has both INT13 support enabled, and also INT13 support for drives 
> larger than 1Gb enabled. Asus AV333 motherboard, AMD Athlon 2100+
> 
> Test1 (this is really two tests):
> 
> Load FreeDOS with HIMEM only; first WITH SCSI driver, then WITHOUT SCSI 
> driver.
> 
> Result1:
> 
> Drive size is reported correctly in both FDISK and PQMAGIC in both cases.
> 
> However, enter EMM386 and ALL BETS ARE OFF! I mean total meltdown, with 
> both FDISK and PQMAGIC saying the drives were not partitioned and giving 
> totally crazy readings for disk sizes. The EMM386 line was this:
> 
> DEVICE=SPECIAL\EMM386.EXE VDS NOEMS X=TEST /verbose
> 
> When I tried to load my SCSI driver after EMM386 and it just hung.
> 
> I then tested all the above with UMBPCI and everything worked perfectly.
> 
> Testing TUNS:
> 
> I now had a stable system, so decided to test loading LBACACHE high, 
> both with and without TUNS.
> 
> If I don't have UMBPCI loaded, it's a bit silly because LBACACHE won't 
> load high, and I don't know if TUNS makes any difference. Output was as 
> follows:
> 
> DISK 0X80 HEADS 0255 SECTORS 0063
> DISK 0X81 HEADS 0255 SECTORS 0063 [DONE]
> 
> I then tested with UMBPCI loaded, and told LBACACHE to INSTALLhigh 
> without TUNS, it did exactly as it was told (checked mem /c /p), and 
> there were no timeouts. It gave the exact same output
> 
> DISK 0X80 HEADS 0255 SECTORS 0063
> DISK 0X81 HEADS 0255 SECTORS 0063 [DONE]
> 
> Here is my FDConfig.SYS file:
> 
> ;device=special\fdxms.sys
> DEVICE=DRIVER\HIMEM.EXE /NOABOVE16 /X
> ;DEVICE=SPECIAL\EMM386.EXE VDS NOEMS X=TEST /verbose
> device=other\umbpci.sys
> 
> rem Load the SCSI for 29160N card
> ;device=other\aspi8u2.sys /d
> 
> rem UDMA hard drives
> ;DEVICE=DRIVER\UDMA2.SYS
> 
> DEVICEhigh=OTHER\VIDE-CDD.SYS /D:FDCD
> 
> devicehigh=OTHER\ramdrive.sys 4096 512 1024 /e
> ;devicehigh=OTHER\ifshlp.sys
> 
> rem lbacache tuns switch is needed for SCSI and UMBPCI
> INSTALLhigh=DRIVER\LBACACHE.COM
> SHELL=COMMAND.COM A:\ /E:1024 /F /MSG /P=.\FREEDOS\FDAUTO.BAT
> 
> DOSDATA=UMB
> DOS=high,UMB
> FILES=20
> BUFFERS=20
> LASTDRIVE=Z
> 
> 
> 
> -- 
> Gerry Hickman (London UK)
> 


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

[Gerry Hickman]

Hi Mark

Ah, yes, ...  :-)  Try emm386 without the VDS argument 
and under no circumstances run FreeDOS FDISK unless 
you want to risk an erased partition table.


Can you clarify; when your partition table became damaged, were you 
running EMM386 at the time, and have you tried it without? Maybe you 
already answered this.


--
Gerry Hickman (London UK)


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

[kd4d]

Hi Gerry:

Yes, I was running emm386.  However, FDISK erased my
(and at least one other) partition table without any
prompt or request at all when only requested to
examine the table.  It's too risky to run the program at
all until that bug is addressed (IMHO).  I believe there
is a development version floating around with that fix.

It is PROBABLY fairly safe to run it without EMM386, but
I do not believe it is worth the risk.  There are other tools
to examine and  manipulate disk partitions that won't 
destroy the partition table when they have been only 
asked to examine it.

Mark


> Hi Mark
> 
> > Ah, yes, ...  :-)  Try emm386 without the VDS argument 
> > and under no circumstances run FreeDOS FDISK unless 
> > you want to risk an erased partition table.
> 
> Can you clarify; when your partition table became damaged, were you 
> running EMM386 at the time, and have you tried it without? Maybe you 
> already answered this.
> 
> -- 
> Gerry Hickman (London UK)
> 
> 
> ---
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

[Gerry Hickman]

Ah, yes, ...  :-)  Try emm386 without the VDS argument 
and under no circumstances run FreeDOS FDISK unless 
you want to risk an erased partition table.


OK I ran the tests again, after taking out VDS everything is working 
normally, FDISK /INFO reports the correct partition sizes and luckily my 
computer still works (I'm typing this message on it).


Regarding LBACACHE TUNS, it's exactly the same as under UMBPCI, it's 
loads high with no problems and no timeouts. Below is the memory map and 
the FDCONFIG.SYS



Modules using memory below 1 MB:

  Name   Total   Conventional   Upper Memory
          
  SYSTEM  14,928   (15K)  9,696(9K)  5,232(5K)
  HIMEM2,544(2K)  2,544(2K)  0(0K)
  EMM386   3,360(3K)  3,360(3K)  0(0K)
  COMMAND  3,984(4K)  2,944(3K)  1,040(1K)
  KEYB 1,760(2K)  1,760(2K)  0(0K)
  SHSUCDX  5,808(6K)  5,808(6K)  0(0K)
  VIDE-CDD 5,024(5K)  0(0K)  5,024(5K)
  RAMDRIVE 1,392(1K)  0(0K)  1,392(1K)
  LBACACHE 7,360(7K)  0(0K)  7,360(7K)
  DISPLAY 11,648   (11K)  0(0K) 11,648   (11K)
  CTMOUSE  3,328(3K)  0(0K)  3,328(3K)
  Free   714,896  (698K)627,008  (612K) 87,888   (86K)

Memory TypeTotal   Used   Free
        
Conventional  638K26K   612K
Upper 120K34K86K
Reserved  266K   266K 0K
Extended (XMS)261,104K   202,303K58,801K
        
Total memory  262,128K   202,629K59,499K

Total under 1 MB  758K60K   698K

Largest executable program size   612K (626,720 bytes)
Largest free upper memory block86K ( 87,616 bytes)
FreeDOS is resident in the high memory area.

-- FDCONFIG.SYS STARTS HERE --

;device=special\fdxms.sys
DEVICE=DRIVER\HIMEM.EXE /NOABOVE16 /X

; rem removed VDS from line below
DEVICE=SPECIAL\EMM386.EXE NOEMS X=TEST /verbose

; rem UMBPCI found to be more stable on every system tested
;device=other\umbpci.sys

rem Load the SCSI for 29160N card
;device=other\aspi8u2.sys /d

rem UDMA hard drives
;DEVICE=DRIVER\UDMA2.SYS

DEVICEhigh=OTHER\VIDE-CDD.SYS /D:FDCD

devicehigh=OTHER\ramdrive.sys 4096 512 1024 /e
;devicehigh=OTHER\ifshlp.sys

rem lbacache tuns switch is needed for SCSI and UMBPCI
INSTALLhigh=DRIVER\LBACACHE.COM
SHELL=COMMAND.COM A:\ /E:1024 /F /MSG /P=.\FREEDOS\FDAUTO.BAT

DOSDATA=UMB
DOS=high,UMB
FILES=20
BUFFERS=20
LASTDRIVE=Z



--
Gerry Hickman (London UK)


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

[Michael Devore]

At 08:23 PM 7/30/2005 +0100, Gerry Hickman wrote:

Ah, yes, ...  :-)  Try emm386 without the VDS argument and under no 
circumstances run FreeDOS FDISK unless you want to risk an erased 
partition table.


Can you clarify; when your partition table became damaged, were you 
running EMM386 at the time, and have you tried it without? Maybe you 
already answered this.


Oh good grief.  EMM386 doesn't have the code or capability to mess with 
disk partitions.  Period.  FDISK was broken in its default behaviors, which 
allowed a simple problem to escalate to meltdown.  This was documented and 
verified, and is being fixed by another FreeDOS developer.   Enough of this 
sort of thing.





---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

[Gerry Hickman]

Hi Michael,

Can you clarify; when your partition table became damaged, were you 
running EMM386 at the time, and have you tried it without?


Oh good grief.  EMM386 doesn't have the code or capability to mess with 
disk partitions.  Period.


But if drive geometry is being misreported or misunderstood under EMM386 
with VDS (which appears to be the case), then my guess is that it would 
be dangerous to run any kind of disk tool while the system is in that 
state? Even writing a file to a disk could cause corruption.


--
Gerry Hickman (London UK)


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

[Johnson Lam]

On Sat, 30 Jul 2005 17:43:04 +0100, you wrote:

Hi Gerry,

>Old OSs, including DOS, Win3.xx and NT, were not aware of this extension 
>and therefore always need an overlay program to use large hard drives . 

That means Win98 FDISK ignore the "INT13 extension".

Thanks for the information.


Rgds,
Johnson.



---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

[Michael Devore]

At 01:08 AM 7/31/2005 +0100, Gerry Hickman wrote:

Oh good grief.  EMM386 doesn't have the code or capability to mess with 
disk partitions.  Period.


But if drive geometry is being misreported or misunderstood under EMM386 
with VDS (which appears to be the case), then my guess is that it would be 
dangerous to run any kind of disk tool while the system is in that state? 
Even writing a file to a disk could cause corruption.


In the same way that a keyboard driver could be dangerous to run with a 
disk tool if there were a bug in it, or if it caused a normally hidden bug 
in the disk tool to activate.


DOS system code is wide open to corruption from any driver or application, 
a situation generally regarded as one of its biggest faults.


Without a system which displays the symptoms -- which I don't have -- it's 
almost impossible for me to say what's going on.  Likeliest candidate for 
causing the problem is that there is still a conflict with some SCSI 
interfaces and an active VDS (4bh) interrupt.  We know that at least one 
SCSI spec directly conflicted with VDS.  However, other candidates cannot 
be ruled out, or even marginalized.





---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS

[Gerry Hickman]

Hi Michael,

My main point was that the FDISK bug may have been _triggered_ by EMM386 
with VDS, and that if he hadn't been running EMM386 his FDISK tests 
would not have caused a bad partition table. You were saying this:


Oh good grief.  EMM386 doesn't have the code or capability to mess 
with disk partitions.  Period.


Hehe, so who knows:)

Anyway, regarding the VDS and SCSI tests, I posted my findings and 
SysConfig earlier in this thread, and can also test the new EMM386 to 
see if there's any change.


--
Gerry Hickman (London UK)


---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
___
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

[Felix Miata]

dmccunney composed on 2021-03-09 17:35 (UTC-0500):

> 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
What is that, a pair of 2GB and a pair of 8GB?
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/


___
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

[tom ehlert]

"Evolution as taught in public schools, like religion,
is based on faith, not on science."

either give us a pointer why you think you must annoy us with that,
or please stop with that (mostly religious) nonsense.



Tom





___
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

[Alvah Whealton]

I'm not annoyed.

Al

On Wed, Mar 10, 2021 at 4:17 PM tom ehlert  wrote:

>
> "Evolution as taught in public schools, like religion,
> is based on faith, not on science."
>
> either give us a pointer why you think you must annoy us with that,
> or please stop with that (mostly religious) nonsense.
>
>
>
> Tom
>
>
>
>
>
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
___
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

[Mercury Thirteen via Freedos-user]

I'll step in for a brief moment to answer this in my own way prior to Felix 
doing so. Sorry, Felix. :)

As to why you must be "annoyed" by anyone else's choice of email signature, I 
would point out the Christo-American concept of free speech. Felix has complete 
freedom to say whatever he wants whether in person or via email signature, just 
as you have complete freedom whether or not to be annoyed by it. It's basically 
the same concept everyone else here applies when reading one of your overly 
dramatic responses; we understand you have freedom to say anything you want, 
and we choose to not let ourselves be bothered with taking it seriously.

And as for the heart of the "nonsense" itself - if you are in fact genuinely 
interested in the subject and not in simply firing off one more snippy email - 
I would start with the works of Dr. Stephen Meyer, Eric Metaxas, Dr. James 
Tour, and John Lennox, Professor emeritus of Mathematics at Oxford University. 
A brief catalog of some of their relevant videos, which may be easier to digest 
than the sum of their published works:

https://www.youtube.com/watch?v=y02a28FrMKs
https://www.youtube.com/watch?v=8FKmIDApbe0
https://www.youtube.com/watch?v=zU7Lww-sBPg
https://www.youtube.com/watch?v=x5tUDJ23Kms
https://www.youtube.com/watch?v=wBio3y0Rrbc

Granted, these fellows aim more generally towards the scientific community as 
opposed to schools, but the same conceptual parallels remain.

*donning my best announcer's voice*
And now, back to you, Felix!
:)

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, March 10, 2021 4:15 PM, tom ehlert t...@drivesnapshot.de wrote:

> "Evolution as taught in public schools, like religion,
> is based on faith, not on science."
> either give us a pointer why you think you must annoy us with that,
> or please stop with that (mostly religious) nonsense.
> Tom
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user___
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

[dmccunney]

On Wed, Mar 10, 2021 at 3:00 PM Felix Miata  wrote:
> dmccunney composed on 2021-03-09 17:35 (UTC-0500):
>
> > 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
> What is that, a pair of 2GB and a pair of 8GB?

Nope.  It has four DRAM slots, and came with 16GB as four 4GB sticks
in those slots.  I replaced a 4GB stick with a 8GB stick to bring it
to 20.  The theoretical maximum for the mobo is 32GB, using  four 8GB
sticks.  I didn't actually need 20GB, but was buying other stuff and
my SO told me I needed to spend more to take advantage of financing
provided by the store brand credit card of the retailer where we
bought it.  Additional RAM was something to toss money at.

One thing I found for 64 bit Windows was an open source RAMdisk
driver.  Right now it has a 512MB RAMdisk dedicated to Firefox browser
cache ()since FF makes it easy to specify where cache is place if you
d0on'\t want it in the profuile direcrtory, but I may experiment with
large volumes for other purposes.  (The macghine the current destop
replaced had 8GB RAM, and I seldome used even half of that.  On ehg
prest machine, for my use cases, I have RAM to burn.)

> Felix Miata  ***  http://fm.no-ip.com/
___
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

[Eric Auer]

Hi everybody,

my impression of "evolution is faith, not science" is that
it is a bit like "my leg is not broken until I believe it"
but actually I rarely read signatures at all, so I have not
even NOTICED Felix' statement until Tom complained about it.

Sure, free speech could let you say almost everything. Still
it is somewhat far fetched to reply to "lots of experts have
investigated evolution" with "that is what YOU believe".

However, as nothing of that is related to the BIOS versus
harddisk question, it kind of feels like a non-issue. Yet
OTHER belief issues have really gotten out of hand in the
last decades, think qanon, antivaxxers, covidiots etc.

If everybody just says "Life is so complicated, everything
merely depends on what you believe", the problem no longer
are people believing questionable things. It is that they
stop believing into actual facts and truths, being way too
busy searching for "the truth they want to hide from us".
I guess we could discuss that in a separate thread. As far
as I am concerned, I still believe the BIOS SATA PATA IDE
question can give us faith-independent excitement as long
as the mail content counts more than the signature :-)

And to add a thought about Christianity: Evolution and
having life on earth at all could be both signs of quite
"intelligent design", so both sides could get some credit.

Cheers, Eric

PS: https://www.smbc-comics.com/comic/simulation-2




___
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

[Felix Miata]

dmccunney composed on 2021-03-10 16:56 (UTC-0500):

> Felix Miata wrote:

>> dmccunney composed on 2021-03-09 17:35 (UTC-0500):

>>> ...It has 20GB RAM

>> What is that, a pair of 2GB and a pair of 8GB?

> Nope.  It has four DRAM slots, and came with 16GB as four 4GB sticks
> in those slots.  I replaced a 4GB stick with a 8GB stick to bring it
> to 20.
Odds are that 32GB capable board features dual channel RAM.
https://en.wikipedia.org/wiki/Multi-channel_memory_architecture

IME when RAM is not used in matched pairs in correct slots in a dual channel
board, RAM speed (memtest86) is cut by nearly half. Did you test RAM speed 
before
and after the change?
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/


___
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

[dmccunney]

On Wed, Mar 10, 2021 at 5:31 PM Felix Miata  wrote:
> dmccunney composed on 2021-03-10 16:56 (UTC-0500):
>
> >> dmccunney composed on 2021-03-09 17:35 (UTC-0500):
>
> >>> ...It has 20GB RAM
>
> >> What is that, a pair of 2GB and a pair of 8GB?
>
> > Nope.  It has four DRAM slots, and came with 16GB as four 4GB sticks
> > in those slots.  I replaced a 4GB stick with a 8GB stick to bring it
> > to 20.

> Odds are that 32GB capable board features dual channel RAM.
> https://en.wikipedia.org/wiki/Multi-channel_memory_architecture

Possible.

> IME when RAM is not used in matched pairs in correct slots in a dual channel
> board, RAM speed (memtest86) is cut by nearly half. Did you test RAM speed 
> before
> and after the change?

No.  I simply made sure I had RAM that matched the specs of the other
sticks.  The only difference was that one stick is 8GB instead of
four. I was *not* using RAM of different speeds, and no mismatch was
involved..

I saw *no* negative performance impact, and would have been startled if I did.

> Felix Miata  ***  http://fm.no-ip.com/
__
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

[Felix Miata]

dmccunney composed on 2021-03-11 09:51 (UTC-0500):

> Felix Miata wrote:

>> Odds are that 32GB capable board features dual channel RAM.
>> https://en.wikipedia.org/wiki/Multi-channel_memory_architecture

> Possible.

>> IME when RAM is not used in matched pairs in correct slots in a dual channel
>> board, RAM speed (memtest86) is cut by nearly half. Did you test RAM speed 
>> before
>> and after the change?

> No.  I simply made sure I had RAM that matched the specs of the other
> sticks.  The only difference was that one stick is 8GB instead of
> four. I was *not* using RAM of different speeds, and no mismatch was
> involved..

> I saw *no* negative performance impact, and would have been startled if I did.

By not matching size of pairs, you disable dual channel. You should run 
memtest86
with and without the 4G and 8G sticks to see the difference in print on your 
screen.

A quick test here using MemTest86 V8.3 Free on:

CPU: AMD A10-7850K Radeon R7, 3.7Ghz
motherboard: ASUSTeK model: A88X-PRO
RAM: Mushkin DDR3-2133 XMP, 10-12-12-28, 2 sticks of 4GB each
matched pair RAM speed: 7474 MB/s dual channel
single stick RAM speed: 5943 MB/s not dual channel = 79.5%

CPU: Intel Pentium G4600, 3.6GHz
motherboard: ASUSTeK model: B85M-E
RAM: Crucial DDR4-2400, 17-17-17-39, 2 sticks of 8GB each
matched pair RAM speed: 21.67 GB/s dual channel
single stick RAM speed: 13.92 GB/s not dual channel = 64.2%
RAM: generic DDR4-2400, 17-17-17-39, 2 sticks of 8GB each
matched pair RAM speed: 19.92 GB/s dual channel
single stick RAM speed: 12.07 GB/s not dual channel = 60.6%

My recollection is with DDR2 the difference tended to be bigger, as low as 53% 
for
1 stick compared to dual channel.
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/


___
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

[dmccunney]

On Thu, Mar 11, 2021 at 5:05 PM Felix Miata  wrote:
> dmccunney composed on 2021-03-11 09:51 (UTC-0500):
>
> >> IME when RAM is not used in matched pairs in correct slots in a dual 
> >> channel
> >> board, RAM speed (memtest86) is cut by nearly half. Did you test RAM speed 
> >> before
> >> and after the change?
>
> > No.  I simply made sure I had RAM that matched the specs of the other
> > sticks.  The only difference was that one stick is 8GB instead of
> > four. I was *not* using RAM of different speeds, and no mismatch was
> > involved..
>
> > I saw *no* negative performance impact, and would have been startled if I 
> > did.
>
> By not matching size of pairs, you disable dual channel. You should run 
> memtest86
> with and without the 4G and 8G sticks to see the difference in print on your 
> screen.

NO.

The RAM here is all DDR4, same speed, and the only difference is one
stick is 8GB.  (I may add another 8GB sick at some point, but it won't
be soon.)

When I said I *saw* no performance difference I meant exactly that.

I have a simple attitude about stuff like this: if I cannot*perceive*
the difference in normal use, I don\t *care*. I have better things to
do with the time than spend it running MEMTEST to detect a performance
difference I won't *notice* in use.

My needs are modest, I don't push the envelope on my system, and what
I have is actually overkill for what I  do. My concern is a stable
system that Just Works, and I have one.

I appreciate your concern, but the only reason I ever ran MEMTEST was
if I had a memory fault, and the last time was years back..

> Felix Miata  ***  http://fm.no-ip.com/
__
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

[Felix Miata]

dmccunney composed on 2021-03-11 17:43 (UTC-0500):

> The RAM here is all DDR4, same speed, and the only difference is one
> stick is 8GB.  (I may add another 8GB sick at some point, but it won't
> be soon.)

> When I said I *saw* no performance difference I meant exactly that.

> I have a simple attitude about stuff like this: if I cannot*perceive*
> the difference in normal use, I don\t *care*. I have better things to
> do with the time than spend it running MEMTEST to detect a performance
> difference I won't *notice* in use.

> My needs are modest, I don't push the envelope on my system, and what
> I have is actually overkill for what I  do. My concern is a stable
> system that Just Works, and I have one.

> I appreciate your concern, but the only reason I ever ran MEMTEST was
> if I had a memory fault, and the last time was years back.. 

As fast as DDR4 is, I don't imagine many people can perceive the difference,
especially running text DOS apps. That's why there are tools to measure with. If
you don't want to know that's fine and dandy. As the old saying goes, ignorance 
is
bliss.

The first selection in my boot menus is MemTest86. I swap stuff around a lot.
There's no fun in swapping parts if results can't be measured.
-- 
Evolution as taught in public schools, like religion,
is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/


___
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

[dmccunney]

On Thu, Mar 11, 2021 at 6:48 PM Felix Miata  wrote:
> dmccunney composed on 2021-03-11 17:43 (UTC-0500):
>
> > The RAM here is all DDR4, same speed, and the only difference is one
> > stick is 8GB.  (I may add another 8GB sick at some point, but it won't
> > be soon.)
>
> > When I said I *saw* no performance difference I meant exactly that.
>
> > I have a simple attitude about stuff like this: if I cannot*perceive*
> > the difference in normal use, I don't *care*. I have better things to
> > do with the time than spend it running MEMTEST to detect a
>> performance difference I won't *notice* in use.

> > I appreciate your concern, but the only reason I ever ran MEMTEST was
> > if I had a memory fault, and the last time was years back..
>
> As fast as DDR4 is, I don't imagine many people can perceive the difference,
> especially running text DOS apps. That's why there are tools to measure with. 
> If
> you don't want to know that's fine and dandy. As the old saying goes, 
> ignorance is
> bliss.

I have no reason to *need* to know, which is better still.

I run a few text DOS apps, using DOSBox or vDOS Plus on my Win10
machine. But they are used occasionally.  Most usage is Win64 GUI
apps.  The most used program is my browser, and the production browser
is the current Firefox Quantum release.  (I also have current Firefox
DEveloper Edition and Firefox Nightly versions, mostly to track
development.  I also have current versions of MS Edge and Chrome.  If
I am awake and at the machine, I am usually in Firefox.

Another large application is Calibre, an open source, cross platform
application written in Pyhon, which I use to manage a large eBook
library.

I have other things like an old version of MS Office (but the only
part of that I use is Publisher to do DTP), Libre Offce, and some
other things, but they get run infrequently.

I don't compile large applications from a source tree, or do heavy
image editing in Photoshop, or video editing, and I'm not a gamer who
has a video card (or more than one) faster than my CPU..

What I am trying to imagine is what I might do on the machine where I
would actually *notice* the difference you think might be caused by
the RAM stick size mismatch.

> The first selection in my boot menus is MemTest86. I swap stuff around a lot.
> There's no fun in swapping parts if results can't be measured.

Fair enough.  I got cured of building my own PC from parts.  Current
off the shelf systems are good enough and fast enough that I don't
need to build my own to get performance.

That sort of thing is the reason why I went with Ubuntu as my Linux
distro when I was dual booting.  It did the best job I've seen in a
distro of figuring out what hardware it was being installed in,
configuring itself, and Just Working. I wanted to spend the time
*using* the system, not hacking to *make* it usable.

> Felix Miata  ***  http://fm.no-ip.com/
__
Dennis


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Bios limitation at 8 gb, and new hdd

[sakura kinomoto]

Hi all!
I have a PC 1996 year, and bought a hd
d, Samsung sp0802n, (maybe 2005 year), with 80 gigabites

But my bios can see only (first) 8 gigabites
I am newbie, so, please, tell me, what software can help?
Thanks for any hint!


I love FreeDOS! :)
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash

[Beeblebrox]

I want to update system BIOS using USB Flash. The USB drive has grub2
installed, I use it as a rescue drive & I can add menu items however I
like. I am able to boot into FreeDOS from grub2 this way:
   linux16 (hd0,1)/boot/memdisk raw
   linux16 (hd0,1)/boot/FDOEM.144

When I boot into FreeDOS, only the contents of the mem-loaded image file
(FDOEM.144) are visible. All the tutorials I have found confirm this
behaviour by instructions to add BIOS-update-files into the FDOEM.144 file,
so that the BIOS update files become available in the memory-file
environment.

MY QUESTION: Would it be possible to provide access from the FreeDOS
mem-file environment
to a folder on the USB drive? This way, one would boot into FreeDOS from
grub2, chdir to the folder route defined in the FreeDOS config.sys (?) and
run the dos-biosupdate.exe. If this is possible, one would just copy the
BIOS files into the defined folder and be done with it. Instead, with
current definitions one mnust loop-mount FDOEM.144, copy the BIOS files
into a sub-folder, unmount FDOEM.144 and copy it to the USB drive.

Hoping I made sense here...
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[Bernd Blaauw]

Op 9-2-2013 12:18, sakura kinomoto schreef:
> Hi all!
> I have a PC 1996 year, and bought a hd
> d, Samsung sp0802n, (maybe 2005 year), with 80 gigabites
>
> But my bios can see only (first) 8 gigabites
> I am newbie, so, please, tell me, what software can help?
> Thanks for any hint!

You might want to purchase a PCI IDE controller, its an add-in card that 
has its own firmware for harddisks and thus doesn't rely on the system 
BIOS. Hopefully your BIOS allows to boot from add-in cards if they have 
their own system ROM firmware.
[ 
http://en.wikipedia.org/wiki/BIOS_Boot_Specification#BIOS_Boot_Specification 
]

Something like this:
http://www.amazon.com/Syba-Combo-SATA-Card-SY-VIA-150/sim/B002GHBVSA/2

The software route would be a DDO
( http://en.wikipedia.org/wiki/Dynamic_Drive_Overlay ) but I don't know 
if these programs are freely available or only for sale (like Ontrack's 
old DDO software). Usually ends up giving lots of trouble when disk 
maintenance programs are running.


Bernd

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[Marco Achury]

On DOS this is a normal limitation.

There a program "Ontrack Disk Manager" that help you to format big
partitions.

You can left 1 or 2 partitions for DOS (8 Gb each) and the remaining
disk you
can use it with another operating system.

-- 
--
+-+-+-+-+-+-+-+
Marco A. Achury
Tel: +58-(212)-6158777
Cel: +58-(414)-3142282
Skype: marcoachury
http://www.achury.com.ve



El 09/02/2013 06:48 a.m., sakura kinomoto escribió:
> Hi all!
> I have a PC 1996 year, and bought a hd
> d, Samsung sp0802n, (maybe 2005 year), with 80 gigabites
>
> But my bios can see only (first) 8 gigabites
> I am newbie, so, please, tell me, what software can help?
> Thanks for any hint!
>
> 
> I love FreeDOS! :)
> --
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>


--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[sakura kinomoto]

Thank you, Marco Achury!

how can I install ontrack disk manager, without floppy? (my floppy device is 
broken)

(I download it by link http://old-dos.ru/dl.php?id=4602  )
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[Eric Auer]

Hi! Returning to the list... So you have tried:

> 1: Different disk managers (SpfDisk, Partition Magic, Power Quest,
> Fdisk, Fdisk in BasLinux(it can create partitions on all hdd,
> but can not mount it)

SPFDISK has this menu option "setup support FAT32"
which you can enable. Also, when you edit partitions,
you can use "modify ID" and use values 0c to 0f:

0c is FAT32 with LBA
0e is FAT16 with LBA (for smaller partitions)
0f is extended with LBA (like 05 but with LBA)

The point about extended partitions is that you have
at most 1 of them among the first 4 (primary) partn
and they in turn contain further partitions.

Note that normally after changing partition ID
or any other property, you have to format that
partition again and the contents are lost, but
you already know that from earlier experience.

I do not know baslinux, but you may want to try some
Linux GPARTED boot disk... That lets you graphically
modify partitioning, in some cases even modify in a
way which does not cause content loss.

> 2. Changing Bios settings: LBA, cylinders/heads/...

If your BIOS actually mentions LBA, then you will not need
Ontrack or similar software, because the BIOS already has
LBA support inside :-)

Regards, Eric

PS: The FreeDOS kernel supports both FAT32 and LBA.


--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[Felix Miata]

On 2013-02-09 16:04 (GMT+0100) Eric Auer composed:

> 0f is extended with LBA (like 05 but with LBA)

I'm pretty sure no OS on the planet requires extended type 0x0F to use LBA, 
except

Win95b
Win98
WinME

If you use none of above WinDOS, there's no use in using the non-standard 
0x0F type instead of the standard 0x05. Some partitioning tools will behave 
differently if the type is 0x0F instead of 0x05.

Most operating systems pay no attention to the extended type anyway. They 
just read the table entries to see where partitions start and end, though 
some read the type byte as a switch as to whether to investigate whether 
access might be provided, such as a drive letter, and subsequent attempt to 
read filesystem and mount appropriately. Linux doesn't seem to care about the 
type byte once a filesystem has been installed on a partition.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[Bob Schwier]

Hey neat.  I used Ontrack Disk Manager back in the eighties.
bs





 From: Marco Achury 
To: sakura kinomoto ; Discussion and general questions 
about FreeDOS.  
Sent: Saturday, February 9, 2013 6:59 AM
Subject: Re: [Freedos-user] Bios limitation at 8 gb, and new hdd
 

On DOS this is a normal limitation.

There a program "Ontrack Disk Manager" that help you to format big
  partitions.

You can left 1 or 2 partitions for DOS (8 Gb each) and the
  remaining disk you 
can use it with another operating system.

-- 
--
+-+-+-+-+-+-+-+
Marco A. Achury
Tel: +58-(212)-6158777
Cel: +58-(414)-3142282
Skype: marcoachury
http://www.achury.com.ve 

El 09/02/2013 06:48 a.m., sakura kinomoto escribió:

Hi all!
I have a PC 1996 year, and bought a hd
d, Samsung sp0802n, (maybe 2005 year), with 80 gigabites But my bios can see 
only (first) 8 gigabites
I am newbie, so, please, tell me, what software can help?
Thanks for any hint! 
I love FreeDOS! :)
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list Freedos-user@lists.sourceforge.net 
https://lists.sourceforge.net/lists/listinfo/freedos-user 


--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[john s wolter]

BS,

Don't forget the FAT-16 limit of 514 or was that 504 MBytes.  Somehow this
issue keeps being asked.  Maybe we are not doing enough to explain it
clearly.

Cheers,
John S Wolter

On Sat, Feb 9, 2013 at 6:24 PM, Bob Schwier  wrote:

> Hey neat.  I used Ontrack Disk Manager back in the eighties.
> bs
>
>   --
> *From:* Marco Achury 
> *To:* sakura kinomoto ; Discussion and general
> questions about FreeDOS. 
> *Sent:* Saturday, February 9, 2013 6:59 AM
> *Subject:* Re: [Freedos-user] Bios limitation at 8 gb, and new hdd
>
>  On DOS this is a normal limitation.
>
> There a program "Ontrack Disk Manager" that help you to format big
> partitions.
>
> You can left 1 or 2 partitions for DOS (8 Gb each) and the remaining disk
> you
> can use it with another operating system.
>
> --
> --
> +-+-+-+-+-+-+-+
> Marco A. Achury
> Tel: +58-(212)-6158777
> Cel: +58-(414)-3142282
> Skype: marcoachuryhttp://www.achury.com.ve
>
>
>
> El 09/02/2013 06:48 a.m., sakura kinomoto escribió:
>
> Hi all!
> I have a PC 1996 year, and bought a hd
> d, Samsung sp0802n, (maybe 2005 year), with 80 gigabites
>
> But my bios can see only (first) 8 gigabites
> I am newbie, so, please, tell me, what software can help?
> Thanks for any hint!
>
> 
> I love FreeDOS! :)
> --
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.http://p.sf.net/sfu/sophos-d2d-feb
> ___
> Freedos-user mailing 
> listFreedos-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freedos-user
>
>
>
>
>
> --
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>
>
>
> --
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[Ralf A. Quint]

At 05:33 PM 2/9/2013, john s wolter wrote:

BS,

Don't forget the FAT-16 limit of 514 or was that 
504 MBytes. Â Somehow this issue keeps being 
asked. Â Maybe we are not doing enough to explain it clearly.


There is no FAT-16 limit of 504MBytes.
There was such a limitation in the original/ealy 
INT13h BIOS calls, which allowed for maximal 1024 
cylinders (x 16 heads x 63 sectors x 512 
bytes=528482304 bytes = 504MBytes). Later BIOS 
version allowed for up to 4095 cylinders, which 
increased the addressable disk size to 2GB.


FAT16 partitions for DOS can be up to 2GB (32KB x 
65524 clusters), Windows NT 4.0 could create and 
access FAT16 partitions of up to 4GB using 64KB clusters...


Ralf  --
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[TJ Edmister]

FAT16 can handle a 2GB partition (4GB partition can be created with  
Microsoft's FORMAT but support seems to be buggy)

The ~500MB limit was actually a 1024 cylinders limit (CHS addressing) with  
older BIOSs. One workaround for this at the time was to divide down the  
number of cylinders to keep it under 1024 and increase the number of heads  
reported to DOS. Eventually we maxed out at 255 heads, hence the ~8GB  
limit.

On Sat, 09 Feb 2013 20:33:11 -0500, john s wolter  
 wrote:

> BS,
>
> Don't forget the FAT-16 limit of 514 or was that 504 MBytes.  Somehow  
> this
> issue keeps being asked.  Maybe we are not doing enough to explain it
> clearly.
>
> Cheers,
> John S Wolter
>
> On Sat, Feb 9, 2013 at 6:24 PM, Bob Schwier   
> wrote:
>
>> Hey neat.  I used Ontrack Disk Manager back in the eighties.
>> bs
>>
>>   --
>> *From:* Marco Achury 
>> *To:* sakura kinomoto ; Discussion and general
>> questions about FreeDOS. 
>> *Sent:* Saturday, February 9, 2013 6:59 AM
>> *Subject:* Re: [Freedos-user] Bios limitation at 8 gb, and new hdd
>>
>>  On DOS this is a normal limitation.
>>
>> There a program "Ontrack Disk Manager" that help you to format big
>> partitions.
>>
>> You can left 1 or 2 partitions for DOS (8 Gb each) and the remaining  
>> disk
>> you
>> can use it with another operating system.
>>
>> --
>> --
>> +-+-+-+-+-+-+-+
>> Marco A. Achury
>> Tel: +58-(212)-6158777
>> Cel: +58-(414)-3142282
>> Skype: marcoachuryhttp://www.achury.com.ve
>>
>>
>>
>> El 09/02/2013 06:48 a.m., sakura kinomoto escribió:
>>
>> Hi all!
>> I have a PC 1996 year, and bought a hd
>> d, Samsung sp0802n, (maybe 2005 year), with 80 gigabites
>>
>> But my bios can see only (first) 8 gigabites
>> I am newbie, so, please, tell me, what software can help?
>> Thanks for any hint!
>>
>> 
>> I love FreeDOS! :)
>> --
>> Free Next-Gen Firewall Hardware Offer
>> Buy your Sophos next-gen firewall before the end March 2013
>> and get the hardware for free! Learn  
>> more.http://p.sf.net/sfu/sophos-d2d-feb
>> ___
>> Freedos-user mailing  
>> listFreedos-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/freedos-user
>>
>>
>>
>>
>>
>> --
>> Free Next-Gen Firewall Hardware Offer
>> Buy your Sophos next-gen firewall before the end March 2013
>> and get the hardware for free! Learn more.
>> http://p.sf.net/sfu/sophos-d2d-feb
>> ___
>> Freedos-user mailing list
>> Freedos-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>
>>
>>
>>
>> --
>> Free Next-Gen Firewall Hardware Offer
>> Buy your Sophos next-gen firewall before the end March 2013
>> and get the hardware for free! Learn more.
>> http://p.sf.net/sfu/sophos-d2d-feb
>> ___
>> Freedos-user mailing list
>> Freedos-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freedos-user
>>
>>



--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[Rugxulo]

Hi,

On Sat, Feb 9, 2013 at 9:04 AM, Eric Auer  wrote:
>
> I do not know baslinux, but you may want to try some
> Linux GPARTED boot disk... That lets you graphically
> modify partitioning, in some cases even modify in a
> way which does not cause content loss.

BASIC Linux is old and meant for old computers. The OP said 1996 cpu
but doesn't specify what. Probably a 586 or older. IIRC, it uses a
2.2.x kernel. Better would be to grab old ZipSlack (Slackware 11),
which at least uses 2.4.x and can also run atop FAT partition.

Basically, your best move would probably be to install FreeDOS and
something else like Linux (or maybe FreeBSD, more minimal by default),
which can access the rest of the hard drive without any problems
(since it doesn't use the BIOS). Even if it's just to copy back and
forth between your FAT partition / DOS setup, it would probably be
easier (unless you want to dig up OnTrack, not recommended, but maybe
it works okay for you).

P.S. Another interesting thing to play with (though it doesn't
circumvent the partition size problems, it has its own) is DOS-Minix
2.0.4, which boots atop DOS and (IMHO) is fun to play with
occasionally. And/or OctaOS or similar, if you're just bored to death.
  ;-)

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[john s wolter]

I knew there was a limit but I had not recalled the BIOS aspect.  The idea
of 64k clusters seems a bit large to me.  FAT-32 and NTFS are more
efficient.

Cheers,
John S Wolter

On Sat, Feb 9, 2013 at 8:58 PM, TJ Edmister  wrote:

> FAT16 can handle a 2GB partition (4GB partition can be created with
> Microsoft's FORMAT but support seems to be buggy)
>
> The ~500MB limit was actually a 1024 cylinders limit (CHS addressing) with
> older BIOSs. One workaround for this at the time was to divide down the
> number of cylinders to keep it under 1024 and increase the number of heads
> reported to DOS. Eventually we maxed out at 255 heads, hence the ~8GB limit.
>
>
> On Sat, 09 Feb 2013 20:33:11 -0500, john s wolter <
> johnswol...@wolterworks.com> wrote:
>
>  BS,
>>
>> Don't forget the FAT-16 limit of 514 or was that 504 MBytes.  Somehow this
>> issue keeps being asked.  Maybe we are not doing enough to explain it
>> clearly.
>>
>> Cheers,
>> John S Wolter
>>
>> On Sat, Feb 9, 2013 at 6:24 PM, Bob Schwier 
>> wrote:
>>
>>  Hey neat.  I used Ontrack Disk Manager back in the eighties.
>>> bs
>>>
>>>   --
>>> *From:* Marco Achury 
>>> *To:* sakura kinomoto ; Discussion and general
>>> questions about FreeDOS. 
>>> 
>>> >
>>> *Sent:* Saturday, February 9, 2013 6:59 AM
>>> *Subject:* Re: [Freedos-user] Bios limitation at 8 gb, and new hdd
>>>
>>>
>>>  On DOS this is a normal limitation.
>>>
>>> There a program "Ontrack Disk Manager" that help you to format big
>>> partitions.
>>>
>>> You can left 1 or 2 partitions for DOS (8 Gb each) and the remaining disk
>>> you
>>> can use it with another operating system.
>>>
>>> --
>>> --
>>> +-+-+-+-+-+-+-+
>>> Marco A. Achury
>>> Tel: +58-(212)-6158777
>>> Cel: +58-(414)-3142282
>>> Skype: marcoachuryhttp://www.achury.**com.ve <http://www.achury.com.ve>
>>>
>>>
>>>
>>>
>>> El 09/02/2013 06:48 a.m., sakura kinomoto escribió:
>>>
>>> Hi all!
>>> I have a PC 1996 year, and bought a hd
>>> d, Samsung sp0802n, (maybe 2005 year), with 80 gigabites
>>>
>>> But my bios can see only (first) 8 gigabites
>>> I am newbie, so, please, tell me, what software can help?
>>> Thanks for any hint!
>>>
>>> 
>>> I love FreeDOS! :)
>>> --**--**
>>> --
>>> Free Next-Gen Firewall Hardware Offer
>>> Buy your Sophos next-gen firewall before the end March 2013
>>> and get the hardware for free! Learn more.http://p.sf.net/sfu/**
>>> sophos-d2d-feb <http://p.sf.net/sfu/sophos-d2d-feb>
>>> __**_
>>> Freedos-user mailing listFreedos-user@lists.**sourceforge.nethttps://
>>> lists.**sourceforge.net/lists/**listinfo/freedos-user<http://lists.sourceforge.net/lists/listinfo/freedos-user>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --**--**
>>> --
>>> Free Next-Gen Firewall Hardware Offer
>>> Buy your Sophos next-gen firewall before the end March 2013
>>> and get the hardware for free! Learn more.
>>> http://p.sf.net/sfu/sophos-**d2d-feb<http://p.sf.net/sfu/sophos-d2d-feb>
>>> __**_
>>> Freedos-user mailing list
>>> Freedos-user@lists.**sourceforge.net
>>> https://lists.sourceforge.net/**lists/listinfo/freedos-user<https://lists.sourceforge.net/lists/listinfo/freedos-user>
>>>
>>>
>>>
>>>
>>> --**--**
>>> --
>>> Free Next-Gen Firewall Hardware Offer
>>> Buy your Sophos next-gen firewall before the end March 2013
>>> and get the hardware for free! Learn more.
>>> http://p.sf.net/sfu/sophos-**d2d-feb<http://p.sf.net/sfu/sophos-d2d-feb>
>>> __**_
>>> Freedos-user mailing list
>>> Freedos-user@lists.**sourceforge.net
>>> https://lists.sourceforge.net/**lists/listinfo/freedos-user<https://lists.sourceforge.net/lists/listinfo/freedos-user>
>>>
>>>
>>>
>
>
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Bios limitation at 8 gb, and new hdd

[Felix Miata]

On 2013-02-09 17:53 (GMT-0800) Ralf A. Quint composed:

> There was such a limitation in the original/ealy
> INT13h BIOS calls, which allowed for maximal 1024
> cylinders (x 16 heads x 63 sectors x 512
> bytes=528482304 bytes = 504MBytes).

In reading about the binary sizes such as this, you'll find incorrect use of 
MB to mean megabytes is common:

528482304 = 504MiB = 528.482304MB

The common misuse leads to other values sometimes seen in the range between 
504 & 528, not the least of which are various partitioning tools and disk 
space reports.

http://physics.nist.gov/cuu/Units/binary.html
http://wintelguy.com/gb2gib.html
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash

[Антон Кочков]

Hello!
You can try to use flashrom (http://flashrom.org) utility for that.
See download link http://ra.openbios.org/~idwer/flashrom/dos - version
for DOS
Best regards,
Anton Kochkov.


On Sat, Aug 24, 2013 at 8:10 PM, Beeblebrox  wrote:
> I want to update system BIOS using USB Flash. The USB drive has grub2
> installed, I use it as a rescue drive & I can add menu items however I like.
> I am able to boot into FreeDOS from grub2 this way:
>linux16 (hd0,1)/boot/memdisk raw
>linux16 (hd0,1)/boot/FDOEM.144
>
> When I boot into FreeDOS, only the contents of the mem-loaded image file
> (FDOEM.144) are visible. All the tutorials I have found confirm this
> behaviour by instructions to add BIOS-update-files into the FDOEM.144 file,
> so that the BIOS update files become available in the memory-file
> environment.
>
> MY QUESTION: Would it be possible to provide access from the FreeDOS
> mem-file environment
> to a folder on the USB drive? This way, one would boot into FreeDOS from
> grub2, chdir to the folder route defined in the FreeDOS config.sys (?) and
> run the dos-biosupdate.exe. If this is possible, one would just copy the
> BIOS files into the defined folder and be done with it. Instead, with
> current definitions one mnust loop-mount FDOEM.144, copy the BIOS files into
> a sub-folder, unmount FDOEM.144 and copy it to the USB drive.
>
> Hoping I made sense here...
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash

[Rugxulo]

Hi,

On Sat, Aug 24, 2013 at 11:10 AM, Beeblebrox  wrote:
>
> I want to update system BIOS using USB Flash. The USB drive has grub2
> installed, I use it as a rescue drive & I can add menu items however I like.
>
> When I boot into FreeDOS, only the contents of the mem-loaded image file
> (FDOEM.144) are visible.
>
> MY QUESTION: Would it be possible to provide access from the FreeDOS
> mem-file environment to a folder on the USB drive?

You can instead use an entire bootable USB disk of FreeDOS via RUFUS
(or similar). Maybe you have a specific reason to only use GRUB2 here,
but otherwise I think RUFUS is easiest.

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash

[Rugxulo]

Sorry, forgot the URL:

http://rufus.akeo.ie/

On Sat, Aug 24, 2013 at 2:53 PM, Rugxulo  wrote:
>
> On Sat, Aug 24, 2013 at 11:10 AM, Beeblebrox  wrote:
>>
>> I want to update system BIOS using USB Flash.
>
> You can instead use an entire bootable USB disk of FreeDOS via RUFUS

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash

[Beeblebrox]

Thanks for the input
My reason for using grub (or the boot-loader method) is because I find the
concept of having an entire bootable usb of 1Gb used only for booting BIOS
utilities and used <1% in capacity rather silly.
By using grub, one can fully load the USB as a "rescue disk" with all sorts
of tools (like aida, ranish, rescuedisk, NT-passwd-recover, inquisitor,
etc, etc). If the same concept can be achieved with a bootloader other then
grub, that would be fine also - but I have come across anything else which
can smoothly handle iso-loopback like grub can.
Regards.


On Sat, Aug 24, 2013 at 10:53 PM, Rugxulo  wrote:

> Hi,
>
> On Sat, Aug 24, 2013 at 11:10 AM, Beeblebrox  wrote:
> >
> > I want to update system BIOS using USB Flash. The USB drive has grub2
> > installed, I use it as a rescue drive & I can add menu items however I
> like.
> >
> > When I boot into FreeDOS, only the contents of the mem-loaded image file
> > (FDOEM.144) are visible.
> >
> > MY QUESTION: Would it be possible to provide access from the FreeDOS
> > mem-file environment to a folder on the USB drive?
>
> You can instead use an entire bootable USB disk of FreeDOS via RUFUS
> (or similar). Maybe you have a specific reason to only use GRUB2 here,
> but otherwise I think RUFUS is easiest.
>
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash

[Beeblebrox]

On 8/25/13, Eric Auer  wrote:
>
> Hi Rugxulo, Zaphod ;-)
>
> Personally, I would not want to access USB while flashing: In
> that sense, using a virtual boot floppy in RAM feels safer, so
> my preference would also be GRUB. Note that you can make that
> virtual floppy 2.88 MB instead of 1.44 MB, how much space will
> you need to put your BIOS update on it?
> Eric

Hi Eric,
2.88 MB would be enough spacewise probably. However, one must create
the virtual floppy for each BIOS by writing the BIOS file/folder into
the FDOEM.144 file so that it is accessible from inside the ram-based
floppy. This is the part I don't like so much as it must be done for
each BIOS separately.
Instead, if the virtual-floppy was able to access at least one device
externally (folder, address, etc) then it would be as simple as
copying the BIS files to that location. The folder/address in question
does not have to be user-variable, a hard-coded, fixed location would
be fine as well.
Regards.

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash

[Beeblebrox]

This tutorial seems to be showing how to do exactly what I am talking
about: http://www.novell.com/coolsolutions/feature/3612.html
At the very bottom, the author states:
"his gave me the disk geometry and highlighted that there was a 0.2GB FAT
device on /dev/sda1 - my pen drive. Then mount /dev/sda1 /mnt/jazzdrive"
I downloaded 
ke386f32.zipfor
this but failed to get this to boot through grub. I probably made a
mistake setting it up on grub.
Q1: Would booting into ke386f32 indeed provide the functionality (mount a
partition) I have been describing?
Q2: If yes, how what are the steps to get this kernel image to boot from
grub2? Is there a link describing the how-to?
Regards.
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] BIOS update with FreeDOS + grub2 on USB Flash

[Eric Auer]

Hi!

> http://www.novell.com/coolsolutions/feature/3612.html

This tutorial is from 2006... It describes how to use some Windows
tool for making a stick bootable with DOS after providing FreeDOS
files to use for that... Still a valid method to do, but does not
mean that a specific kernel version has some magic properties ;-)

> Q1: Would booting into ke386f32 indeed provide the functionality (mount a
> partition) I have been describing?

No. To also answer the previous mail: When you boot DOS from a
bootable RAMDISK, no USB access is needed while flashing. USB
is complicated for drivers so I think it is better like that.

If you want to access USB from DOS, you have two options: Let
the BIOS be the driver or load a driver in DOS. For the first,
it is often sufficient to boot from the USB stick with legacy
support enabled in the BIOS setup... For the latter, try the
http://bretjohnson.us/ drivers or http://www.dosusb.net/ but
note that the second driver is shareware: Without license, I
think the driver only demo-works for a while after each boot.

Note that loading USB drivers in DOS takes the USB chip out
of the hands of your BIOS! So if you were using BIOS legacy
support, the USB keyboard / mouse / stick support used for
booting will STOP working at the moment when you load a DOS
driver. Of course you can load a DOS USB keyboard / mouse /
stick driver next, but the switch can still cause troubles.

When you booted from a bootable RAMDISK via grub or similar,
you may get away with this: DOS has the driver on a ramdisk,
so it does not have to touch your stick at the moment when
the driver is loaded... I would still say that it is better
NOT to load USB drivers while booting from USB. Although it
is nice to load them after booting from harddisk etc. :-)

Talking about legacy support: The obvious thing to do is to
have a FAT32 partition on your stick. Or format the whole
stick (unpartitioned) as FAT32, although I believe it is a
bit better to use partitions. Use LBA, to avoid issues with
the CHS "geometry" that the stick does not really have and
about which DOS, BIOS and boot tools might disagree. Flag
the partition as bootable, of course...

You also need a DOS boot sector: You could boot DOS, then
use SYS on the stick. In some cases, you can also use SYS
of FreeDOS after booting Windows, if you already have that.
There are also dedicated Linux tools for that, such as the
Loadlin-based Makebootfat or my sys-freedos-linux script,
a Perl script which uses the NASM assembler and the source
code of some FreeDOS boot sectors. There are also several
Windows based tools for the same purpose. You should find
some explanations and discussions for all of them on the
web. I remember that you disliked the idea of having the
WHOLE stick formatted for DOS: Of course you can have the
stick split into multiple partitions and use a boot menu
(grub, grub2, loadlin, syslinux, grub4dos, ...) to make
the choice whether to boot the DOS partition or something
on one of the other partitions on the stick. Some of them
CAN directly boot FreeDOS kernels - read the manuals. In
the general case, just SYS the DOS partition and tell the
boot menu to boot the whole partition, not just a kernel.

I guess Bernd and Rugxulo can give more explanations :-)

Thanks! Regards, Eric



--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
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)

[Jon Brase]

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 n

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

[Eric Auer]

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

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

[Liam Proven]

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)

[Jon Brase]

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)

[Liam Proven]

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)

[dmccunney]

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)

[Liam Proven]

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)

[dmccunney]

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&T kit
when AT&T was in the computer business, and an AT&T 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)

[Jon Brase]

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)

[Jon Brase]

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)

[Jon Brase]

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)

[dmccunney]

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)

[Liam Proven]

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)

[Liam Proven]

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)

[Liam Proven]

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&T kit
> when AT&T was in the computer business, and an AT&T 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&T 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 i

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

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)

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

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

[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

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]

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)

[Jon Brase]

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 opt

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

[Adam Nielsen via Freedos-user]

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

[Freedos-user] BIOS with broken UDMA needs DOS disk driver loaded before JEMMEX

[Eric Auer]

Dear DOS users,

via the BTTR DOS forum and Jack I received the following warning:

Some mainboards have a BIOS with faulty UDMA in V86 mode support!

This CPU mode is used to run "DOS compatible" tasks in Windows or
certain virtual environments such as Dosemu for Linux, but it is
(importantly) also used by all EMM386-style DOS drivers, such as
JEMMEX: With such drivers, the presence of EMS memory hardware is
simulated by moving DOS into a V86 task.

When the BIOS fails to support UDMA (memory block copy and block
copy between memory and I/O devices) properly in V86, attempts to
transfer disk data can fail or end up at the wrong places in RAM.

DOS disk drivers could potentially test if your BIOS is buggy, but
it will not always be possible to do that without causing a crash.
In the BEST case, the driver could conclude that no UDMA will work.

In the WORST case (!), the BIOS itself defaults to UDMA disk access
and crashes as soon as you enter V86 mode. In that case, you will
be FORCED to load a driver like XHDD or UIDE before loading JEMMEX
to protect your BIOS from its own stupidity. Unfortunately, it is
not unlikely at all that if you have a bug, you have it worst case!



To avoid crashes, it is important to LOAD DISK DRIVERS BEFORE EMM
(if your BIOS is affected by such bugs). For example, load XHDD in
your boot process before you load JEMMEX. If you disk driver is
using XMS (for example as cache) you can of course not use JEMMEX
as your XMS driver, but have to load a separate XMS driver before
the cache, as JEMMEX has to be loaded after the disk driver...



Some drivers can use HMA space provided by XMS drivers (as HIMEM)
if no UMB space (provided by EMM386 and similar) is available, but
in general, many drivers only support UMB, so your amount of free
DOS memory is reduced if you have to delay the loading of EMM386.

Jack recommends to load HIMEMX then UIDE then JEMMEX: That way, the
UIDE driver can use the HMA and HIMEMX + UIDE will use circa 3.5 kB
of low DOS memory together. If you only load UIDE and then JEMMEX,
UIDE would need 4.5 kB of low DOS memory and would miss early XMS.

An even more advanced suggestion by Jack is to load XMGR /B instead
of HIMEMX, then UIDE, then JEMMEX, then XMGR again, but without /B,
which allows XMGR to regain 2 kB of memory as soon as JEMMEX is on.

Note that FreeDOS by default does not give drivers access to HMA
space at all inside config.sys, so you would have to delay those
driver loads to autoexec - other DOS variants are more flexible.

Regards, Eric



PS: When you boot Windows or Linux, the protected mode disk drivers
of the operating system are usually activated BEFORE any V86 tasks
get the chance to try to access the disk. This is why the BIOS bug
can go unnoticed - only DOS will suffer, other systems don't care.

PPS: LOWDMA (ships with UMBPCI) and the TUNS option of LBACACHE are
other examples of driver workarounds for BIOS and hardware problems.


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user