[Freedos-user] XIDE Updated; UIDE Support TERMINATED!

[Jack]

Johnson Lam has posted an updated 5-Jun-2015 DRIVERS.ZIP file with a
single XIDE driver, in his "dropbox" at:
<https://dl.dropboxusercontent.com/u/15785527/dos/file/drivers.zip>

XIDE is now a single driver, using a /P switch to request high-speed
"protected caching", also a /X switch to disable overlap of UltraDMA
disk I-O with caching on an "old" or "odd" mainboard requiring this.
XIDE's overlap of UltraDMA disk input with caching is also improved.
Versus UIDE, the 5-Jun-2015 XIDE now offers up to 10% greater speed!

Note also that my support for the old UIDE driver is now TERMINATED,
due to Rugxulo's continuing "MAD Dog!" GRUDGE against me, that began
with his following 17-Mar-2015 post on BTTR:
<http://www.bttr-software.de/forum/forum_entry.php?id=14140>

Rugxulo is "miffed" that I refused to follow his ideas for upgrading
my PC, after SourceForge made virtually "overnight" changes to their
Internet security certificates, which I think was a MISTAKE!But,
Rugxulo went on sending me more ideas, although I asked him at-least
twice to "Send me NO MORE E-Mails"!   If in the above post, he calls
this "arguing" with me, Rugxulo is a LIAR!!   It was only HE who was
intruding on ME, and nothing more!!

Rugxulo now takes EVERY chance he can to ATTACK me, as can be viewed
in all his FD-User and BTTR posts since 17-Mar-2015.   He is correct
in only one thing:  After his having recommended UIDE for years, his
above post is the reason I made the new XIDE a closed-source driver.
My drivers ALWAYS work, as they are always CHECKED by Johnson Lam or
by "Khusraw" (both, if their time allows) before Johnson posts them!
And if, after so long, Rugxulo now thinks he can make my using V6.22
MS-DOS into a FreeDOS driver "issue", Rugxulo is "Blowing SMOKE!" to
make himself look good, and he should be considered only as a FAKE!!

I'll BE DAMNED before I merely "give away" any more of my sources in
the face of Rugxulo's BACKSTABBING!   XIDE will remain closed-source
and I plan NEVER to do any more open-source work:  Too many absolute
FREAKS and "MAD Dogs!" to put-up with!!

Please do NOT address any further UIDE questions/comments to me.   I
now regard it as "defunct", and you now know why.

Jack R. Ellis

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

Re: [Freedos-user] XIDE Updated; UIDE Support TERMINATED!

[Jack]

Mateusz and Eric, my Thanks for your comments, which I respect.   But I
will not accept undeserved attacks on me and my work.   So, my decision
stands, that XIDE and other software from me will now be closed-source.

Re: the REST of what was posted on FD-User today, Sunday 14-Jun-2015:

* I know it's ironic that I spent so many hours trying to help him get
* back on the list ...

MY decision and MY RESPONSIBILITY that I feel SourceForge made a MISTAKE
in their "overnight" Internet certificate changes.   Who is Rugxulo that
I "MUST LISTEN" to his ideas!   I had to tell him TWICE to "STOP sending
me any more E-Mails"!   So he took what was essentially a PRIVATE matter
onto a PUBLIC forum, in his 17-Mar-2015 BTTR post.

In any case, as one can see from my posting on FD-User again, it was not
necessary to upgrade.   I could have ignored all by Rugxulo or "Zangune"
(SourceForge), merely used my "intuition", and I would have been able to
post here again MUCH sooner!

* I can't even officially mirror anything closed source.   This is a
* "Free"DOS mailing list hosted by "Source"Forge, or have you forgotten?

I have not forgotten, and in fact I never asked you to mirror any of
my drivers.   After all of this, I would be absolutely delighted, if
FreeDOS, IBiblio or whoever DID delete every one of my driver files!

* You explicitly told me NOT to mirror your drivers because, unless
* you could directly announce them on freedos-user, that you'd be "done
* with FreeDOS".

Correct, since their are always technical details re: my drivers that
only I can explain.   Without being able to post on FD-User, I cannot
give such explanations, and that says I would be "done with FreeDOS"!

* I (indirectly) was asking rr to either reinstate you or explain
* why not (though he never did).

The above is the first I ever heard of that!   Robert Riebisch of BTTR
did write me that he had begun work at a new job and is very busy.   I
was unable to read an "attachment" he sent, in his inquiry re: getting
me back on BTTR, and I have not heard from him since, just like others
to whom he has not replied.   From my 35 years in software, I am aware
of just how demanding and "mercenary" such jobs can be.

* I (indirectly) was trying to get mvojvodic to test your "newer"
* drivers and report back because they didn't work for me (refused to
* boot on Lenovo 2011 ...

The above is the first I ever heard of that, as well!   Although I was
tired of Rugxulo's never-ending "upgrade-Upgrade-UPGRADE" E-Mails, did
he really believe I would not have listened to a SERIOUS "bug" comment
about a PC-compatible system?   I surely WOULD have!

* (08-Dec-2014) Jim Hall: "I see Jack has got you involved on this too.
* He's becoming very abusive (again) and I find that tiring.   I'm not
* going to put up with it."

ABSOLUTELY the first I ever heard of THAT!   Then why did Jim Hall not
write to ME in December, nor answer at-all the E-Mail which I sent him
last Monday, 8-Jun-2015?   His total lack of response this week is why
I chose to make yesterday's FD-User post, so users WOULD know what was
going on.

* Jack, you didn't want to spend any money to upgrade ...

Absolutely NOT Rugxulo's BUSINESS, whether or not I upgrade!   Who is
HE that I "MUST listen" to his ideas, and what if his ideas proved to
be flatly UNNECESSARY, as I noted above!

** My drivers ALWAYS work, as they are always CHECKED by Johnson Lam or
** by "Khusraw" (both, if their time allows) before Johnson posts them!
*
* Two whole testers?   Out of 8 billion people?   Wow, I'll bet even
* Microsoft is jealous.

They positively SHOULD be!!   Lucho told me in 2008, when I asked how
UIDE compared in speed to his Windows, "You beat THEM, 2 months ago"!
That was long before any of XIDE's upgrades; and XIDE is still only a
5K run-time driver using NO interrupts and providing up to 4-Gigabyte
caches!   Gazillion-byte drivers in "C" were never-Never NECESSARY!!

I shall continue to rely on Johnson's 11 years and "Khusraw"s 8 years
of test results.   They value and comment about my drivers.Others
on BTTR and FD-User almost NEVER say anything.

* Jack ... I hope Jim Hall removes every ounce of work you've ever
* done for FreeDOS.   I hope he deletes it all from "BASE", iBiblio
* mirror, and everything else ...

So do I.   My drivers were not designed solely for FreeDOS but for
any DOS system.   The fact that they DID end up on IBiblio was not
my doing nor really my desire.   Jim Hall is absolutely free to be
rid of every one of my driver files from 2004, any time he wishes!

But I know he will NOT do it, for the same reasons as before:  Jim
is DESPERATE not to lose software that WORKS!   Can anyone imagine
how much SLOWER Free

[Freedos-user] Rugxulo IS A FRAUD!!!

[Jack]

Note the following comments by Rugxulo in this post:


* If you want to try his latest drivers (Mar-18) [sic], grab them from
* his DropBox, but since he doesn't even use FreeDOS (only MS-DOS 6.22),
* I'm not sure if they work at all anymore:

And note the following comments by Rugxulo in this post:


* I hope Jim Hall removes every ounce of work you've ever done for FreeDOS.
* I hope he deletes it all from "BASE", iBiblio mirror, and everything  
else.

Now, note the following comments by Rugxulo in THIS post:


* BTW, I forgot I had Doom 1.9 (shareware) here (circa 1995), so I did a
* quick install (no music, PC speaker sfx). It played just fine for
* several levels, using default extender ... until I quit the game, then
* it crashed/hung/beeped with MCB error.   :-P And that's on a more
* modern machine than yours, of course not running LBACACHE but still
* using ("Mar-05", 2015) XMGR, UIDE, RDISK.

Rugxulo, you are a FRAUD!!   A Charlatan and now a PROVEN FRAUD!!

If you don't think my drivers work any more, and you want Jim Hall to
remove all my work from "BASE" and IBiblio, they WHY ARE YOU STILL USING
XMGR, UIDE, and RDISK??

Because you are a DISGRACE to all humanity, you lousy FRAUD!!

STOP using my drivers, you stinking FRAUD!!   Stop using them NOW, and
NEVER use them again, you wretched FRAUD!!

And "Put your money where your [FOUL] MOUTH is" and get Jim Hall to DELETE
my drivers from IBiblio, EVERY LAST ONE since 2004, you despicable FRAUD!!

STOP using my drivers and GET RID OF THEM ALL from Ibiblio NOW, you  
stinking
FRAUD!!   No matter if you have Jim Hall do it, or do it somehow yourself,
just DO IT NOW, you miserable FRAUD!!

You have made a MOCKERY of this forum by breaking EVERY ONE of its "Rules
For Posting", which I now regard as either a JOKE or a bald-faced SHAM!!
I DO NOT want my work associated with FreeDOS any more, CERTAINLY NOT for
use by a PIG and a "CRACKER" like YOU, you two-bit FRAUD!!

So DO IT NOW!!   STOP using my drivers, ALL OF THEM, if you think they
no-longer work!!   And Get Them All OFF IBIBLIO too!!   They were NOT
written to be used by a pitiful CRETIN like YOU, you FRAUD

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Rugxulo IS A FRAUD!!!

[Jack]

To all on this forum who say "Calmaros" [Lets be calm] etc., read THIS:

In 1975. 1977, 1979, and 1981, I was declared DEAD by my parents, after
a RIDICULOUS and totally WRONG comment from my sister in 1975, and also
over my converting from Judaism to Episcopalianism in 1974.   They died
in 1987 (mother) and 1991 (father), and from their 3rd "death sentence"
in 1979, I chose NEVER to see them again!

Rugxulo went even farther than THEY DID!!

And Jim Hall did nothing -- TOTALLY NOTHING -- to STOP his "Fair-haired
boy"!!

As I know Hall and all of you are DESPERATE to retain UIDE, since your
hopelessly UNDER-performing system may REALLY be worthless without it,
fine:  Keep it!   UIDE may or may-not have the same audio errors noted
on BTTR for the now-dropped XIDE, and other problems might be found in
UIDE over time.

But that is now YOUR problem, not mine.   As I noted to Alain Mouette,
Je suis FINI avec FreeDOS!

I have now asked Johnson Lam NOT to post any MORE of my updates on his
website, not even closed-source .SYS files, which I REFUSE to see used
by FreeDOS (he can offer them PRIVATELY, to DOS users in China)!   The
new drivers are now 20% faster than UIDE, that lacks UltraDMA overlap,
Read Ahead -- ask Eric Auer what that is -- or anything else I may add
later, while UIDE becomes more-and-more OBSOLETE.

But, that too is YOUR problem, not mine -- JE SUIS FINI AVEC FreeDOS!!

And please DON'T EVEN TRY offering further wretched Hearts-and-Flowers
comments to me --

Rugxulo went even farther than MY PARENTS DID!!

So, once more for all the "cheap seats", I AM FINISHED WITH FREEDOS!!!

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

Scott,

I am the author of the UIDE driver for DOS systems.   Eric Auer is
away from E-Mail, for a few days, so I will reply directly to your
thread about "Large drives with 4K sectors" --

First, DOS formatting programs are in effect "stand alone" utility
programs, that can pretty-much do what they like when formatting a
hard-disk.   Easy for them to format 512-byte sectors, 4K sectors,
or whatever.   But --

Second, file I-O done by other DOS programs uses either 24-bit CHS
requests (up through V6.22 MS-DOS) or 48-bit LBA requests (all new
DOS variants including FreeDOS).   The two I-O request schemes are
designed for 512-byte sectors only.   Thus, any program that wants
to do file I-O using new 4K-byte sectors will need MAJOR additions
in the DOS kernel to handle such I-O requests.   This "Ain't gonna
happen!", as some might say in the U.S.A.

Third, although a 48-bit disk logical-block address (LBA) could be
specified, DOS systems have not-yet gone beyond using more than 32
bits of "block count" (i.e. sectors) in a disk directory, limiting
DOS files (and disks!) to 2-TB maximum.   More than that will also
require MAJOR changes to the DOS kernel, and I believe this "Ain't
gonna happen, neither"!   DOS systems, excepting FreeDOS and maybe
EDR-DOS, are NOT under current maintenance, and any kernel changes
to most DOS variants are now only a "dream"!

If you desire to use a DOS system, I suggest you "Think only 2-GB"
drives, maximum.   If your system really NEEDS more than 2-GB, you
may want to consider reserving 2 or more "partitions" on the disk,
the first of which is limited to 2-GB for use with DOS.   I am not
a file-systems expert, so others shall have to tell you if DOS can
allow MORE than one 2-GB partition on the SAME disk.   I doubt it!

Since my own UIDE driver must handle all variants of DOS including
all "old" ones, I have NO plans to update UIDE specifically for 4K
sectors.   If "new" 4K-sector disks can still be handled via "old"
512-byte DOS I-O requests, I shall leave UIDE "as is".   UIDE thus
needs no changes to go above 2-TB, since it does issue all 48 bits
of disk LBA address for any hard-disk read or write command.

Jack Ellis


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

Sorry, in my comments to Scott about large 4K-sector disk drives,
all occurrences of 2-GB should actually be 2-TB (Terabytes)!   As
I often note, "age 65" is S much fun (i.e. NOT!).

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

I shall add my "two-cents worth" to the current philosophical
discussion about 4K sectors as follows --

To me, the most disturbing thing about "modern" PC systems is
their ABSOLUTE LACK of concern for backward compatibility!

We really did NOT need the PCI bus in 1994, except that Intel
wanted to sell PCI chips and thus found ways to discredit and
force out-of-business the VESA bus.

We really did NOT need PCI-X video cards in the past 5 years,
except that somebody [guess who!] desired to sell THOSE chips
too, and so found ways to discredit and force out-of-business
AGP video cards.

We really did NOT need AHCI controllers and all the MONSTROUS
software drivers needed with them, except that "the industry"
again desired us all to "buy something new" and thus increase
the profits in Santa Clara, CA and Redmond, WA.   I still say
a properly-written SATA/IDE driver, without any terribly SLOW
"C" interrupt logic [maybe using an old-friend of mine called
"Horror of Horrors" ASSEMBLY code!], probably COULD have done
a much faster job of hard disk I-O in Windows/Linux!   How do
I say this??   Because in 2008, when I asked Lucho about UIDE
speed v.s. Windows, he replied "You beat THEM, 2 months ago"!

Finally, we really do NOT need mainboard makers [all from one
island in the South China Sea] who support their products for
only a few months, then DROP all such support when their NEXT
"Piece of S***" is ready to be stuffed down our throats!

And now we have 4K sectors for hard-disk drives, which I note
some feel shall ultimately replace 512-byte sectors.   If so,
another step BACKWARD in terms of "user friendliness" for the
poor-old PC industry.Even the AHCI A**holes still provide
some sort of "legacy" or "IDE compatible" mode, for most BIOS
chips and with most mainboards!   If "4K and ONLY 4K sectors"
ever happens, I might just begin cheering for IPads and other
alternatives, then "Sit back and watch!" the PC industry lose
ALL its business, just like IBM lost control of PCs in 1985!!

"In the name of progress" like the Wintel Consortium tries to
make us all believe, the PC industry simply CANNOT get rid of
an I-O format with 30 years of history behind it (or 50+ when
one includes mainframes/minicomputers!) and all that software
expecting to USE such a format!   If hard-disk "firmware" has
become so good that it can allow 64-MB on-board write caches,
then I hope they might ALSO realize it is "more in their best
interest" to continue handling 512-byte sectors, however they
can, and even in-parallel with handling 4K sectors if needed!

I say again:  My own UIDE driver (A) shall NOT include direct
support for AHCI, due to the code-size needed and as "legacy"
IDE handling is part of most AHCI chipsets, and (B) shall NOT
include direct support for 4K hard-disk sectors, since no DOS
system now supports them as well (nor likely ever will)!   If
the PC industry ever tries making this "mandatory", like they
did in "Ramming down our throats!" such things as PCI, PCI-X,
and now God-DAMNED AHCI, I plan to PITCH my entire PC system,
then go into full retirement [or perhaps get an IPad or some-
thing else, ANYTHING else but another damned PC, instead]!

Jack R. Ellis


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

Michael,

You missed my point about backward compatibility, which has been
notoriously ABSENT from the historical events I noted.

> PCI was desperately needed by server class hardware ...

Fine, let them have it.   But why did ORDINARY users have to be
forced into buying newer mainboards, which ONLY had PCI??!!   I
still use a system with 1 hard-disk, 1 CD/DVD drive, 1 diskette
(remember them?) and 1 serial-port modem -- NO damned USB, Fire
Wire, nor other modern GARBAGE needed or wanted!Why in HELL
do I really need PCI, with my configuration??ISA would have
gone on serving me, and others, very well, but it "disappeared"
after 1994.   Need I tell you due to guess-WHO's desire to SELL
CHIPS??!!

> Thank heavens we finally got a real bus.

A "REAL BUS", you say??   If so, then explain to me why, on so
many Intel-based systems, there are so many PCI BRIDGES!!   If
it were a "real bus", there would be only ONE bus, NOT so many
"bridges" to yet-another set of wires for God-Knows-What!   My
guess is that only adds cost and complexity, which an ordinary
user like me might hope to AVOID!

> PCI Express (I'm assuming you meant this, not PCI-X) is mostly
> compatible with PCI at the software level.  The reason for PCI
> Express was the need to reduce pin count and move to what is
> basically a serial interface ...

So why not simply (A) omit using the pins they didn't need, and
(B) specify a currently-UNUSED pin [must have been at least one
of them on an AGP card!] for "what is basically a serial inter-
face"?   And same as above, if a few "play-games FREAKS" really
NEEDED so much video speed, let THEM get new video cards.   But
instead, "guess who" drove AGP and all mainboards which had AGP
sockets out-of-business, and we ALL need to buy new video cards
and new mainboards designed for them!   ABSOLUTELY NO backward-
compatibility, again, though many people like me DON'T NEED any
damned PCI Express or whatever it may be called!   I still "get
by" quite well with only my GeForce-2 AGP card, bought in 1999!
And I bet there are likely many others, like me, who "Dread the
Day" when they are STUCK buying a new video card, since AGP has
effectively "disappeared" now!

> The move to 4K sector sizes has very good technical reasons
> behind it ...

To which I might ALSO say an 8-letter word beginning with BULL!
I have written actual "firmware", and I have friends that wrote
actual HARD-disk "firmware".Along with every improvement to
hard-disk speed has come ever-faster firmware processing chips,
faster on-board memory, and of course better algorithms for USE
of all that.   So why can't such an ever-faster "industry" such
as hard disks continue to process 512-byte sectors even faster,
as well?   Does the REST of the PC industry really need to help
THEM, with all of their super sophisticated on-board hardware??

Or, in fact, could this maybe [... just MAYBE!] be another case
of the Wintel Consortium software BRATS being UNABLE to achieve
their targets, using only their college-professors' and bosses'
much-beloved "C", and it is actually THOSE brats who are asking
for such "help"??

That, in fact, is what all this begins to "sound like", to me!!

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

Scott,

> Consumers (home and business) for the most part buy the bulk of
> their storage on $/GB type of decisions.  Buying multiple lower
> capacity HDDs does not meet this model.

A lot of Internet vendor websites, such as NewEgg, just may prove
you wrong.   Every time I look at NewEgg and others, the "latest-
and-greatest" hard disk has a price premium far WORSE than buying
2 hard disks of 1/2 the size.

> <http://www.anandtech.com/Show/Index/2888>
> "One estimate for 4K sector technology puts this at 100 bytes of ECC
> data needed for a 4K sector, versus 320 (40x8) for 8 512B sectors.
> Furthermore the larger sectors means that larger erroneous chunks of
> data can be corrected (burst error correction), something that was
> becoming harder as greater areal densities made it easier to wipe out
> larger parts of a 512B sector. As a result, the need for the larger
> sector is born."

Absolutely UNBELIEVABLE!!   40-byte ECCs needed for 512-byte sectors??

 From 1976-1978 I worked for a company that made hard-disk controllers,
used on PDP-11 systems to control 80- to 300-MB "washing machine" size
disk drives, all they had 35 years ago.   Our controller used a 56-bit
ECC, i.e. 7 bytes, to detect all errors and correct bursts of up to 11
bits.   35 years ago, PDP-11 drivers (I wrote them, too) did not have,
and didn't need, any better error-correction than that, since the disk
drives WORKED!   Nor (that I know of) were there "spare sectors", etc.

Now, any "modern" 3.5" hard-disk has "spare sector" tracks, and as the
above article notes, they also have 40-bit ECCs to correct "larger er-
roneous chunks of data".   If so, and if all that is really NEEDED for
so-called "modern" hard-disks, I say only this:  WHAT WENT WRONG, from
35 years ago, when such things WERE NOT needed??!!

Given "spare sector" pools and the firmware to use them, I expect that
"modern" hard-disks should be able to get-by with only a 10-bit, maybe
at-most a 16-bit, ECC.   Uncorrectable errors beyond the ECC's ability
should cause the drive to use a "spare" sector.And finally, if too
many "spare sectors" get used, someone at that vendor should "inspect"
their manufacturing processes for disk platters, and FIX IT!

Sad, to me, that so much in electornics/computers is now "pushed" past
a very simple "concept" that was taught to me long ago, which is known
as DIMINISHING RETURNS!!   Given my experience, the need for a 40-byte
ECC with only a 512-byte disk sector is WELL PAST diminishing returns!
And if that is any reason for advocating 4K disk sectors, i.e. to save
such miniscule amounts of track space, the hard-disk "industry" is now
"DUMBER than I thought!!"  [Paul Newman, from the 1989 movie "Blaze"].

Jack R. Ellis


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

Scott,

My apologies ("age 65" again!); in my last post about disk ECC
sizes, I meant to say "10 byte" and "16 byte" ECCs, not "bit".

Jack R. Ellis


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

Zbigniew,

> This reminds me somewhat a "Forth's Dillemma" rant: ...

Which I read, and I do not regard it as any "rant" but a
statement of fact, especially as I suffered the same --

In 1968, when I still did 360/DOS mainframe work, IBM added
job-stack capability for the DOS foreground-1 and -2 tasks,
but they FORGOT most systems had only one card-reader to do
job-stack input!   "Capturing" F1 and F2 job-stacks to tape
or disk was also impossible, as reading past a /& card (end
of job) was an ERROR that "canned" all cards until the next
/& appeared.

So, I read the assembled DOS kernel listing, noted the bits
set by a /& card, and wrote a B-Transient to CLEAR the bits
until a /&& card ("end of stack") was read.Worked fine,
F1 and F2 got a lot more work done, and our nightshift girl
got home 2 hours earlier every night.

The upshot?   3 weeks later, my boss called me in and asked
me to be more "discreet" about any further changes I did to
the 360/DOS system.   I asked why, and he replied "Our S.E.
[systems-engineer i.e. "repairman"] heard about it, and now
they want to re-negotiate our MAINTENANCE contract!".

Within 3 months, and through absolutely NO fault of my boss
or that company, I had my first job in mini-computers.   My
opinion was that, if IBM thought only THEIR people at White
Plains, NY could do systems-programming, and everybody else
in the field ought NOT, then I did NOT need my "destiny" to
be controlled by those a**holes!   And I made that decision
at only age 23!

Your "Forth's Dilemma" is not any sort of "rant" but really
a statement of fact.   I know, since I have "BEEN there and
DONE that!", as we in the U.S.A. might say.

Jack R. Ellis


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

Zbigniew,

>> Your "Forth's Dilemma" is not any sort of "rant" but really
>> a statement of fact.   I know, since I have "BEEN there and
>> DONE that!", as we in the U.S.A. might say.
>
> Well, actually it's not mine - but I've found it interesting,
> and (as I wrote) your opinion brought it back to my mind.
> Yes, maybe "rant" was wrong term indeed (be tolerant to non-native
> speaker ;) - since it was rather memories, and an attempt to make a
> diagnosis of the situation in computer industry.

On that "diagnosis", I absolutely agree with you.   In the U.S.
we have a 2-word phrase that in my opinion perfectly describes
the current PC industry situation -- "It SUCKS!!"

Jack R. Ellis


--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

> There are so many inaccuracies and distortions in the reply that you
> sent, I'm going to assume you are just irritated or in a bad mood.

In fact, I was neither, until reading what you post below.   Once again
you choose only to "pick nits" at the technical examples I mention, but
flatly REFUSE to address my ACTUAL point of NO BACKWARD COMPATIBILITY.

> The world moves on ... it doesn't make sense to support existing
> standards forever.   You can have eternal support, or affordable
> prices, but not both.

What I resent, and have all my time in computers, is that such "existing
standards" are usually supplanted with absolutely NO thought of backward
compatibility.   We are all FORCED to buy new systems ever 2 or 3 years,
whether we like it and have the cash, or NOT, simply because chip makers
want to sell us something "new".   They ARE "sales driven" as I hope you
know, and there are NO sales if people still can find the OLD equipment!

> - Modems have been supplanted by networks thousands of times faster
> - Screens have more real-estate than ever and can be carried in one hand
> - Most machines are SMPs on a chip
> - Hard drives are measured in sizes that used to fill a data center

I still use a 56K modem, still have a 17" CRT monitor, and have a single-
core AMD 3000+ that serves me fine.   Saves me the every-2-or-3-year cost
of buying what OTHERS in the PC industry "think I SHOULD" buy now!   And
I hope my equipment will KEEP ON saving me such cost!

> Most of us like this progress.  While I do enjoy tinkering with my old
> hardware, it's not usable for things that most people need to do today.

Mine still is, and I bet most people's hardware still is.   Perhaps that
is why PC sales took such a HUGE nosedive around 2008.   The world economy
and a lot of bad banks certainly contributed, but I would not be surprised
if many people decided "We really do NOT need new hardware now!", and they
are still using 5+ year old systems, same as me.

> ISA buses were an abomination.   Sorry - that's the bottom line.

Always worked for me, and again, my regret is that someone ELSE flatly TOOK
AWAY even the CHANCE for me to continue using one!

> PCI bridges server a valuable purpose - to decouple segments of the
> extended bus from each other, both for clock speed and management  
> purposes.

If a PCI bridge can do it, why can't an individual DEVICE do it, e.g. look
at bus-timings only when they need to read/write DATA on the bus, which is
equivalent to "decoupling THEMSELVES", without needing a whole bridge chip
to be involved??   Last I heard, any "bus" has a "clock", and if a device
wants to key off of its OWN "clock" for certain functions, let it DO so!!

> I hate to shock you even further, but the PCI bus itself has become so
> standard and ubiquitous that the virtual machines out there like KVM use
> it as an abstraction layer for defining the hardware of the virtual  
> machine!

Their business, not mine, since I have never used a "virtual machine".   I
would rather have a REAL machine, not another software layer.

> The move to serial (point to point) links is driven by the physical
> reality of electrical engineering - it's hard to run signals over
> parallel wires at high speeds and keep them in sync.  You can argue that
> it's not needed; the people needing to push larger and larger amounts of
> data through their systems disagree.

Fine, let the serial busses exist if they must.   But again, NO ONE gave
users any CHOICE about keeping our PARALLEL busses, and again we all had
to buy new hardware, because the industry DENIED us any more old hardware!

> And as is pointed out already, ECC over a 4K sector size is more
> efficient space wise than ECC over 512 byte sectors.  In an incredibly
> cost conscious industry you can't leave that kind of space savings on
> the table.   Do you like cheap storage or 512 byte sectors?

I like both.   But, you convince me that I need not just a spare floppy-
disk, but also a spare hard-disk, too! All your comments convince me
the PC industry will GO ON flatly DENYING me or others ANY SORT of back-
ward compatibility.So if I am, in fact, totally happy with available
disks and don't need 4K-sector types, I had better "stock up" now!Or
just PITCH my PC and accept using an IPad.   Appears a lot of people may
be doing just that!

> I think we can live with the 4KB sectors - it's going to cause a per-
> formance hit, but on modern hardware we have enough to burn.

Thank you for yet another reason why I do NOT want 4K sectors, if that
is so!   Is that how you answer Felix Miata's comment, in this thread,
that 4K sectors will cause more last-block file wastage, i.e. "We have
enough [performance] to BURN"??   We NEVER have any such thing, in my
opinion!!

> And on a final note, just because you fail to see the value in something
> for your own purposes does not mean it is without value, or 'bull'.
> Calm down a little.  You are not the only person on the list to 

Re: [Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

>> "One estimate for 4K sector technology puts this at 100 bytes of ECC 
>> data needed for a 4K sector, versus 320 (40x8) for 8 512B sectors.
>
> Yes, that's about 5% (5,37% to be exact) you'll gain from 4k sectors.

Perhaps a bit more than 5% due to fewer inter-sector gaps.   Since they
are kept small by hard-disk makers, my guess [only a guess] is that the
"gain" in disk capacity from 4K sectors is around 10% at best.

So I agree with "Escape" --

> The question "Is 2,1Tb [or by my guess 2,2-TB] so more capacious than
> 2,0Tb that we want to break compatibility?"

Nonetheless, I plan to at-least "investigate" buying a spare hard-disk.

The PC industry always works from an "All we want is MONEY!!" rule, and
that says only NEW-equipment sales and availability!

I "sense" a HIGH probability that 512-byte sector hard-disks shall soon
VANISH, just as QUICKLY as diskette drives, AGP cards, etc. have done!

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

>> ... but on modern hardware we have enough to burn.
>
> Wasting anything just "because we can afford it" is generally
> a bad idea.

With which I absolutely agree.   But it seems only I wonder how
much farther ahead Windows/Linux might be, if their kernels and
drivers [as a MINIMUM!] HAD in fact been done in assembly code!

>> Most of us like this progress.   While I do enjoy tinkering
>> with my old hardware, it's not usable for things that most
>> people need to do today.
>
> No, you're wrong; it's not usable for bloated software of today,
> not for the things that most people do:
>
> #v+
> "Check out the results! For the functions that people use most often,
> the 1986 vintage Mac Plus beats the 2007 AMD Athlon 64 X2 4800+:  9
> tests to 8!   Out of the 17 tests, the antique Mac won 53% of the
> time! ...

Little surprise to me, after Lucho's 2008 comment that my own UIDE
"beat THEM, 2 months ago!", referring to Windows.   And UIDE still
doesn't use any interrupts, due to ancient "Brand I" chipsets that
UIDE had to support, despite those chipsets' "errata" [i.e. BUGS]!

> ... It can be stated that for the majority of simple office uses,
> the massive advances in technology in the past two decades have
> brought zero advance in productivity".
> #v-

With which I ALSO absolutely agree.   Now, I have a 1-GB AMD 3000+
system, with a 120-MB hard-disk plus other relatively "high speed"
items, in comparison to the 16K (yes, I said KILOBYTE!) mainframes
I began on in 1966.   GUESS what systems did far more USEFUL work!

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Large drives with 4k sectors presenting as 512b?

[Jack]

> My point in the thread is that YOU do not get to choose what is the
> appropriate rate of progress.  Either stock up on spare parts, or move
> along.  Disparaging everybody in the industry who has a different point
> of view is ranting.

I do not call it "progress" when the PC industry flatly DENIES me the
ability to keep using my current system, by making UNAVAILABLE spare
parts of any sort for them.   Now, thanks mainly to your comments, I
am considering BOTH "stocking up" AND "moving on", to something like
an IPad.   I disparage only those in this industry who DENY me such
choice, in the name of their own PROFITS!!

> The second point that you fail to grasp is that it costs too much
> money to maintain backwards compatibility with outdated standards
> past a certain point ...

Tell that to the automobile and other industries in this country, who
have FAR more years' "old stock" than the profit-mongers making PCs!!
I guess it never occurred to PC vendors that FORCING US to have a new
system every 2 or 3 years [or sooner!] is costing them BUSINESS, i.e.
all those people who have ABANDONED traditional PCs for IPads, etc.!

> I never advocated "burning" cycles for sake of burning them.  My point
> there is that if we're looking for function, the hardware will and the
> additional cost of software overhead to keep backwards compatibility
> will probably do what we need.  Once again, it's not our choice -
> if/when 512 byte sectors go away we're going to have to insert extra
> software for compatibility purposes.

Might be simpler just to KEEP 512-byte sectors, as I am almost certain
they could, IF their firmware-engineers were told to do so in "new" 4K
sector disks.   Might also save them a lot of LOST business, for I bet
a "4K and ONLY 4K" decision may cost them a lot of Windows/Linus users
as well, not merely those of us who still use and like DOS.

> ... I'll just ignore you from this point on ...  you just seem to be
> very angry.   The readers of the list can judge for themselves.

Not angry, only trying to make a POINT, that backward-compatibility is
"systematically" AVOIDED in this industry, only to achieve more SALES!

So shall I ignore you, for as one friend has already noted to me, you
certainly seem to be "propagandized" by the PC industry, AND ONLY the
PC industry, into believing only what THEY expect you should believe!

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE

[Jack]

Marcos,

> I also have a couple of questions about UIDE.
>
> Question 1.
>
> Can we continue using the /PM switch with the new release of UIDE?

You can, but it will be ignored!   I deleted the "protected mode"
logic from UIDE in 2010, as the "standard" UIDE using XMS caching
became 96% as fast as the /P and /PM caches, from better handling
of XMS memory.   No further need for the "protected mode" logic!

> Question 2.
>
> Readme.Txt says "Power-saving features such as a 'drive spin-down
> timeout' should be DISABLED".   My setup (AMIBIOS Version 2.5,
> 1997) does not have a feature with that specific name, but it
> does have:
>  Hard Disk Time Out
>
> Is that what I should disable?

Yes.   Hard disk "time-outs" are not part of the ATA disk spec,
and many "laptop" vendors have unusual "schemes" for supporting
them.   So, there is no way I can program UIDE for all of that!

> If so, does this mean that the hard disk must keep running all
> the time if UIDE is used?

Correct, for the reason I note above.

> The setup also has the following:
>
>   Hard Disk Power Down Mode
>   Standby Time Out
>   Suspend Time Out
>
> Are these three also involved?

Yes.   ANYTHING that would cause a hard-disk or CD/DVD drive to
appear "not ready" for extended time spans should be disabled!

> Currently my pertinent FDCONFIG.SYS lines are:
>
>   BUFFERS=4   ; (Recommended by Jack Ellis)
>   devicehigh=C:\FDOS\UIDE\uide.sys /S40

"Looks good to me"!   I recommend "BUFFERS=4", since UIDE caches
all directory sectors it handles, as well as data files.This
performs MUCH better than the DOS "BUFFERS=" command, unless one
can set "BUFFERS=32" or more, which gives a "slight" increase in
speed even with UIDE.   But few systems can spare the HMA memory
for "BUFFERS=32", so using UIDE is the better "bargain"!

Also, do try /S50 or /S100, if you can afford 50-MB or 100-MB of
XMS memory assigned to UIDE.   /S40 sets only 1280 cache blocks,
while the 50/100-MB caches have 1600 cache blocks.   More blocks
gives better directory handling, as there are a LOT of directory
sectors handled by DOS, and extra cache blocks help with them.

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE driver help

[Jack]

James,

I am the author of the UIDE and UIDEJR drivers, and I will try
to answer your questions.

> I am trying to set up support for a cd/dvd drive on my freedos.
> I am using vbox on a mac running freedos as my operating system.

I assume your "vbox" responds the same as a true PC system.   If
it does not, UIDE/UIDEJR may not work, as they "interrogate" the
PCI BIOS to find what controllers and hard-disks are present.

> I want to be able to use my cd/dvd drive on my MacBook pro laptop.
> I have the drivers for UIDE.   I have read the readme file, but it
> is very technical.   I could use some help loading the drivers.

Do note Section 5 of the README file, which gives samples of the
commands needed in CONFIG.SYS, or FDCONFIG.SYS in your case, for
loading UIDE.

> Do I have to edit my config.sys file?

Yes, you do.   At least a command similar to the following must be
added to it, for loading UIDE --

   DEVICE=C:\DRIVERS\UIDE.SYS /S100 /D:MYCDROM

If you want only a basic non-caching driver, you can load UIDEJR
[i.e. "junior" UIDE] using the same type of CONFIG.SYS line --

   DEVICE=C:\DRIVERS\UIDEJR.SYS /D:MYCDROM

The /D: name must be the same as given to SHSUCDX or SHCDX33E (my
equivalent CD/DVD manager), so the two programs can "communicate"
correctly re: the CD/DVD drives they handle.   Also, since UIDEJR
is not a caching driver, it needs no /S cache-size switch.

> Do I put the drivers, that I downloaded on my c: drive?

They can be on any drive or in any directory you like, as long as
the DEVICE= in your command line tells FreeDOS exactly where they
are.

> I could use some help, my goal is to be able to access my cd/dvd
> drive on my mac while in freedos.   Like I could put in a cd and
> then in freedos change to drive a or b or whatever letter is
> assigned the cd drive and access a cd in my MacBook pro cd drive.

If you intend only "occasional" use of CD/DVD files, you may want
to download my latest 10-May-2011 DRIVERS.ZIP file from --

<http://johnson.tmfc.net/dos/driver.html>

Johnson Lam has been my "partner" since 2004 in testing and distri-
buting the drivers, and his above website still "hosts" the drivers
for me.

In the 10-May-2011 DRIVERS.ZIP, the latest UIDEJR.SYS driver takes
only 2032 bytes of memory in its "CD/DVD only" form, loaded as --

   DEVICE=C:\DRIVERS\UIDEJR.SYS /D:MYCDROM /N1

The /N1 switch tells it "No hard-disks" and saves about 1100 bytes
of memory, i.e. it omits disk logic and runs only CD/DVD drives.

The latest UIDEJR is "not particular" re: being loaded with an XMS
manager, e.g. HIMEM or my own XMGR.If an XMS manager is there,
UIDEJR using the above command-line requests 128K of XMS memory as
its I-O buffer.   The buffer is used only when UltraDMA may NOT be
used, as when a DOS program does input to an "odd address" buffer,
etc.   If XMS is unavailable, UIDEJR will handle such "misaligned"
CD/DVD input using old "PIO mode" ["Programmed input-output", i.e.
SLOW!].

The above DEVICE= command always places the driver in "low memory"
i.e. in the original 640K of DOS memory.   If you use  DEVICEHIGH=
instead, the driver can be loaded into "upper memory" beyond 640K.
Doing so requires an XMS manager and either (A) the UMBPCI driver,
which can "map" system "Shadow RAM" into the 640K to 1-MB area, or
(B) one of the "EMM" drivers such as JEMMEX, or the combination of
HIMEMX + JEMM386 or my own XMGR + JEMM386, which can "map" regular
memory into the 640K to 1-MB range.UMBPCI is simpler, but more
limited in functionality (complex subject!), so if you want to use
upper-memory, a better choice is an XMS manager and an EMM driver,
or the "combined" JEMMEX.

"Upper memory" schemes are admittely a lot more complicated!If
you are "new" to FreeDOS, loading UIDEJR just as I show above will
handle your CD/DVD files O.K.

Do remember to load either SHSUCDX, my own SHCDX33E, or MSCDEX, in
your AUTOEXEC.BAT file.   UIDE/UIDEJR are only the "drivers" for a
CD/DVD drive -- Its "file manager" is one of the above 3 programs!
You need to add a line in AUTOEXEC similar to --

   C:\DRIVERS\SHSUCDX.COM /D:MYCDROM /C

The /C switch keeps the driver "where it was loaded", i.e. if into
low-memory, it shall not try to "move" itself to upper-memory, and
vice-versa.And again, the name after /D: must "match" the name
given to UIDE or UIDEJR.   My drivers "default" to  UDVD1  thus if
you give SHSUCDX/SHCDX33E the switch  /D:UDVD1  you needn't have a
/D: switch on the CONFIG.SYS command-line which loads UIDE/UIDEJR.

Anything further, send me a "private" E-Mail, and I shall be happy
to respond!

Jack R. Ellis


--

Re: [Freedos-user] UIDE

[Jack]

Eric,

> Of course DOS will freeze for a short moment when it has to
> wait for a harddisk to spin up again, but as I never had a
> bigger problem than that with power-saving in DOS without
> UIDE, I would like to suggest the opposite of what the UIDE
> readme.txt seems to say at the moment:
>
> Could UIDE be used to configure the power saving timeout of
> your harddisks? The involved IDE/ATA commands are relatively
> simple.   They could be sent to either all disks which, based
> on their self-ID, support power saving, or to one selected
> disk, using any suitable command line syntax for the latter.
>
> Of course UIDE should in addition be able to wait in a safe
> way when it encounters a sleeping disk which has to spin up
> first.   Should be possible with small error handling
> changes ...

The problem is "WHERE" does UIDE or any other driver wait for
a sleeping, i.e. "stand-by" hard disk to awaken again??   The
ATA specs do not make this clear.   Can UIDE simply issue a
drive-select command to the disk and await "ready" for it?
Or, does UIDE actually have to issue a "seek" or "read", and
then retry that command when first it fails??

If you can determine a reliable way for ALL disks to "come out
of stand-by" mode, i.e. at what point UIDE should have a long
time-out value, I can program that.   But, it must be COMMON
to all drives, NO exceptions, or it might cause just as much
TROUBLE as it resolves!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Basic question on UIDE

[Jack]

> All this talk about UIDE prompted me to investigate this tool.
> It looks interesting.   How does the caching work for disk writes?

UIDE uses "Write Through" caching, meaning all output data is written
to disk immediately.   For SATA/IDE disks handled internally by UIDE,
if data fits in one cache block (75% of the time, for 64K blocks used
by larger caches), data is moved to that block and output from there.
UltraDMA is 32-bit and will do I-O from anywhere in memory, so direct
cache I-O is possible.   If output "crosses over" more than one cache
block, data is written from the user output buffer, or from a 64K XMS
buffer if the user's buffer is unsuitable for UltraDMA ("odd address"
etc.), then moved to cache afterward.   For smaller UIDE caches using
less than 64K cache blocks, or when I-O crosses over multiple blocks,
all I-O occurs on the FIRST block (NO "fragmented" reads/writes!) and
UIDE moves data to the required cache blocks later.   Diskettes, SCSI
and other disks, whose I-O is handled by their drivers, cause UIDE to
"call the BIOS" (or a "callback" subroutine for a "user" driver) then
cache data after that call returns to UIDE.

I experimented with "Write Back" caching ("delayed" writes) but never
got it to work, and decided that it needed too many "hooks" into DOS,
e.g. timer, Ctrl/Alt/Del vector, etc.For "Write Through" caching,
UIDE needs to "hook" only the Int 13h vector for hard-disks, which is
more reliable than "snaking through" the whole DOS system as SMARTDRV
or Norton NCACHE2 must do.   There is also a problem of power-failure
whose only "true" solution is a U.P.S. (Uninterruptible Power Supply)
and I shall NOT be the one to "recommend" such things for UIDE users!
Finally, "modern" hard disks all have their own on-board write caches
which pretty-much eliminate the need for a "Write Back" cache -- Note
how fast deleting a large directory now occurs, with or without UIDE,
and you will conclude that the disk write-cache must be "helping" for
many operations!

> I assume that when the cache is full the next sector read in will
> cause the oldest sector to be written out?

Absolutely!   UIDE has a "least-recently-use" (LRU) linked-list which
is part of its cache-block tables, and that list is updated for every
I-O.   When the cache is "full", the cache block at the "tail" of the
list, i.e. the LRU entry, is made "free".   This occurs at the end of
every input or output, so UIDE always has a "free" cache block to use
on the next I-O.   Simpler logic, handling things that way!

> Is there any sort of a timer which will flush the cache to the hard  
> drive periodically?

No, and none is required, as UIDE does not "delay" any writes at all!

> How do you make sure that the RAM cache is written to the disk?

I simply output all data IMMEDIATELY -- NO "delayed" writes at all!

That is both the beauty and the benefit of using only "Write Through"
caching -- NO possibility of data LOSS, due to "waiting too long" and
suffering a power-failure, a "bumbling user" on the keyboard, etc. as
with a "Write Back" cache like SMARTDRV and NCACHE2!   They may still
be a bit faster, for some compiler or database operations.   But UIDE
compensates by being a very FAST "Write Through" cache, using only 5K
of assembly-language (NO wretched "C" here!), with up to a 4-GIGABYTE
cache capacity!   None of the older caches can get that high!

> I poked around in the documentation but did not find this information.

Sorry, the source file for UIDE does say that it uses "Write Through"
caching, but I did not put this in the README, which others will note
is already "technical ENOUGH"!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Jack]

Eric,

I read through and understood all your comments about hard-disk
power management, etc.

My problem is:  I am not-interested in being "the one" who does
power management.   If DOS or the BIOS wants to save power thru
putting disks into "stand-by" mode, let them do it.   UIDE is a
disk "I-O driver", not a power-management tool, and I desire to
keep such things OUT of UIDE's logic!

Re: handling disk drives which ARE in "stand-by" mode, if all I
need to do is allow some more time for them to spin-up, that is
relatively easy.   UIDE's CD/DVD logic currently allows 7 secs.
for spin-up and 3 seconds for track-to-track seeks, which I had
forgotten -- I had not looked at that logic for almost 5 years!

Assuming 7 seconds "should be long enough!" for a hard disk, as
well, I can simply use that value as a timeout during disk I-O,
not the current 400-msec timeout.   Shall "experiment" re: this
idea.   Might cause some "confusion" among UIDE users, who will
now see a 7-second delay in some error handling.   But, if UIDE
needs only a timeout change to handle "sleeping" hard disks, it
might be worth updating only 1 byte in its "DoIO" subroutine!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Jack]

Eric,

>> ... My problem is:  I am not-interested in being "the one" who
>> does power management.   If DOS or the BIOS wants to save power
>> thru putting disks into "stand-by" mode, let them do it...
>
> There is not much to "do" there, as you only tell the disk once
> and then the disk itself does the rest.

"Amen!", so let the user handle this thru the BIOS setup routines
and let the BIOS "tell the disk" what to do during system "boot"!
BIOS vendors have many more programmers than just "me by myself"!

> But it would be good to know from you that UIDE is (as predicted)
> happy to wait a moment for idle disks to spin back up, as that in
> fact does not need any explicit handling by UIDE anyway.

UIDE's CD/DVD logic is "happy to wait" for up to 7 seconds, and I
will look into changing its disk logic from 400-msec to 7 seconds
as well.

> However, I would be happy if UIDE could "do" the sending of the
> idle timer config command to the disk because:  It already does
> raw drive I/O anyway and it already has some command line parser
> anyway so it would only take a few more (non-resident) bytes to
> let UIDE send this command when the user puts the corresponding
> command line option during UIDE start-up. That way, no separate
> tool would be needed which would duplicate existing UIDE logic.

Actually, UIDE has NOT changed any disk-configuration settings by
the BIOS since late 2005, when I "got into TROUBLE" doing so with
some BIOS programs!   UIDE now only "reads" I-O and DMA addresses
for a disk from the BIOS, then "runs" a disk however the BIOS set
it up.   That, also, is something I want to LEAVE up to the BIOS,
as I don't want any MORE trouble by changing BIOS settings again!

>> UIDE is a disk "I-O driver", not a power-management tool, and
>> I desire to keep such things OUT of UIDE's logic!
>
> Yet UIDE already probably does "drive setup" communication with
> the disk for selection of the right communication speed so my
> point is it would be only a small step to make it possible to
> send other drive (e.g. "idle timer") setup commands with it.

No, sir!   UIDE does NOT change any communication-speeds nor ANY
other BIOS settings for disks, not since 2005, as I noted above!

>> relatively easy.   UIDE's CD/DVD logic currently allows 7 secs.
>> for spin-up and 3 seconds for track-to-track seeks, which I had
>> forgotten -- I had not looked at that logic for almost 5 years!
>
> Interesting. So it can in fact report a time-out, but that should
> simply make DOS try again. As FreeDOS tries 5 times, you get much
> more than 3 or 7 seconds in the end, depending on which timeouts
> are used for int 13 functions 0, 2, 3, 42 and 43. Long enough :-)

Any hard-disk function but 2/3/42/43 (reads and writes) is "passed"
to the BIOS, so function 0 would not be so timed-out by UIDE.   Nor
would UIDE ever declare a "timeout" -- CD/DVD errors currently post
only "general error" in such cases, and hard-disk errors would post
only whatever "hardware" error applies to that part of "DoIO" which
noted the timeout, likely a "DMA error" for most cases.   Not a big
problem.   Disk/CD/DVD errors are "few and far between", and people
already know that a lot of DOS programs will only display "Error!",
leaving exactly WHAT error it was for diagnostic programs, etc.!

>> ... Might cause some "confusion" among UIDE users, who will
>> now see a 7-second delay in some error handling.
>
> Good question.   This would only make delays longer for errors that
> would never end without explicit error handling but I understand
> that users could still notice. For example I remember that using
> CompactFlash CF cards with a (purely mechanical) IDE adapter plug
> can have such "hangs" for low quality cards - in particular when
> you combine that plug with a SATA-IDE adapter with cheap chipset.
>
> So I guess such hangs would get longer with longer timeouts, as
> it might take the driver longer to "give up" the access attempt
> and decide to "give the drive a smack of reset" to reactivate it
> no matter whether it is the driver or just DOS which says reset.

If DOS does 5 retries, as you indicate, this would cost the user a
maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any
sort of an indefinite "hang"!I would indicate in UIDE's README
that an actual [rare!] disk "error" may now take that long, before
DOS gives-up on it and reports something to the user.

>> But, if UIDE needs only a timeout change to handle "sleeping"
>> 

Re: [Freedos-user] UIDE vs drive power management spin down timers

[Jack]

Eric,

> I have not yet seen a desktop BIOS which implements this, alas [disk
> spin-down timeouts, etc.].  I do have an adware DOS tool for it,
> showing a splash screen for a BBS or similar when you run it and of
> course bigger than needed, but free.

Desktop BIOS routines are usually not-interested in saving power thru
spin-down timeouts or other such "tricks".   Laptop BIOS routines ARE
interested, since their power is limited when using batteries.   Thus
it is mainly laptops we address here, and their BIOS routines DO have
the needed hard-disk logic.

>> Actually, UIDE has NOT changed any disk-configuration settings by
>> the BIOS since late 2005, when I "got into TROUBLE" doing so with
>> some BIOS programs!   UIDE now only "reads" I-O and DMA addresses
>
> Interesting, but which trouble did which setting cause?

With a few BIOS routines back in 2005 (maybe obsolete, now), setting
any UltraDMA mode OTHER than what the BIOS set did not work!   To be
safe, I got RID of such mode-set logic in my drivers, back then.

>> Any hard-disk function but 2/3/42/43 (reads and writes) is "passed"
>> to the BIOS, so function 0 would not be so timed-out by UIDE.   Nor
>> would UIDE ever declare a "timeout" ...
>
> Why not? There is an error code (0x80) defined for that in int 0x13.

Note in my drivers' UltraDMA "DoIO" subroutine, it is always waiting
for either controller/drive ready or DMA end.   If those "events" do
not occur, hard to tell if the controller/disk has failed or if they
just "took too long".I have assumed a disk will finish I-O in at
most 400 msec, and if not, it was a hardware failure, not a timeout.
So, I have never used BIOS code 080h.   Same "situation" even if the
"DoIO" timeout becomes 7 seconds, to handle disk spin-up.   No way I
can know if the hardware failed, so I doubt I can use code 080h.

>> If DOS does 5 retries, as you indicate, this would cost the user a
>> maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any
>> sort of an indefinite "hang"!
>
> What I meant is that when the disk is in a state where only a reset
> can make it continue, the driver will wait 7 seconds. If it is in a
> state where nothing will make it continue (e.g. un-hotplugged it?),
> DOS will take 35 seconds until it displays an error message. In the
> 7 second case, the user will in the worst case see a delay of 7 sec
> plus the time needed to spin up, but more likely only the always-
> present delay caused by the time needed to spin up.

Understood, if in fact DOS issues a drive-reset on any error.   Also,
note that my drivers do NOT allow "removable" or "hot-pluggable" HARD
disks, since I cannot be sure all DOS kernels can handle media-change
"events" in their HARD-disk logic!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE vs drive power management spin down timers

[Jack]

Eric et al,

Johnson Lam has done his usual QUICK posting of my latest
UIDE/UIDEJR (since 2004 he has been THE BEST "partner" in
my driver work!) in the 14-May-2011 DRIVERS.ZIP file, now
available on his website at --

<http://johnson.tmfc.net/dos/driver.html>

The 14-May-2011 UIDE and UIDEJR now allow 7 seconds for a
hard-disk request to complete, just like CD/DVD requests.
This should give a "spun down" disk drive enough time for
a "spin up" and should be a great help to "laptop" users.
Only 2 bytes of timeout values changed, one in "DoIO" and
one in the Identify Drive init logic -- "Not too shabby"!

Also, UIDEJR is 96 bytes smaller in memory, in /N2 "disk-
only" form, by discarding all CD/DVD "entry" logic, which
the 10-May driver didn't do.   UIDEJR is now minimum-size
in all configurations and offers more controllers/drives,
HMA loading, and many bugs fixed v.s. XDMA/XCDROM/GCDROM.
The new UIDEJR is much better for a small-driver user!

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Jack]

Alain,

> I just foud how to make it work (kind of...)
>
> I boot normally, single-stepping, loading all *except UIDE*, than I do:
>SET COMSPEC=C:\COMMAND.COM   (it's the same)
>C:
>DEVLOAD A:\DOS\UIDE.SYS /D:CDROM
>
> it loads, and I can access drive C:, but if I access A: it locks just
> the same, with the HardDisk led on.
>
> ==>> so, imho, the drive A: is disapearing when UIDE is loaded. It looks
> like an interaction between the BIOS boot driver that creates A: for the
> CD boot image and UIDE :(

I wrote UIDE to be a "standard" system driver, not a "CD boot" driver,
and I was unaware that BIOS "CD boot" drivers set the CD to be used as
the A: drive.   How they do this, and what hardware access schemes are
used, are unknown to me.   So, I am not surprised that the BIOS "boot"
driver conflicts with UIDE, if both run on the same system.

If you still want to use UIDE (or UIDEJR) in your CD download process,
you can load it as follows --

DEVICE[HIGH]=C:\DOS\UIDE.SYS /N2

The /N2 switch tells UIDE not to handle any CD/DVD drives, thus you do
not need a /D: switch either.   This should allow your "boot" A: drive
to go on being used.After users have downloaded all they need from
your CD, they can then change UIDE to handle regular files from the CD
by getting rid of /N2 and re-adding a /D: device name.

Jack R. Ellis


--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] New 16-May-2011 UIDE (Etc.) Available.

[Jack]

Johnson Lam has posted a new DRIVERS.ZIP file dated 16-May-2011
onto his website at --

<http://johnson.tmfc.net/dos/driver.html>

The XMGR, UIDE, and UIDEJR drivers are all corrected so they do
not "call" any run-time subroutines during their initialization
procedures.   Thus, newer CPUs with a "large" code cache cannot
fetch run-time driver code into the CPU cache, before that code
has been initialized!

This is similar (but not identical) to the "bugs" fixed in UIDE
on 25-Apr-2011.   I believe I "Got ALL of them!", this time!

I know the drivers seem to work O.K., and I agree with Eric and
others that a "long jump", etc. will flush a CPU code cache (at
least in part!).   Nonetheless, I prefer to be SAFE and prevent
such possible problems by having correctly-written logic!

Jack R. Ellis


--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem with UIDE

[Jack]

Alain et al,

>> I do need as much conventional memory as I can get, and even the it is a
>> tight fit...
>>
>> So everyone belives that
>>   JEMM386 X=TEST NOEMS
>> is safer? if so, I will change...
>
> My point was that ACPI tables (and/or too aggressive searching by FD
> [J]EMM386?) makes it necessary to either avoid X= I= or use both with
> "=TEST". At least, from my limited experience, that's the case. It's
> worth a try, at least, but who knows honestly.   :-P

For the record, I use V6.22 MS-DOS (compatible with my equally
old V4.0 Windows/NT!), and I have always loaded JEMM386 with a
NOEMS command.   No problem!   Seems to work O.K., as I expect
it should, since I run no "VERY old" EMS programs!

In your case, if "conventional" memory is a concern but upper-
memory is not, you can try loading JEMM386/JEMMEX like this:

DEVICE=C:\DOS\JEMM386.EXE I=B000-B7FF X=C800-EFFF NOEMS

This specifically tells JEM386/JEMMEX to "map" upper-memory in
only the "monochrome video" (black-and-white) graphics area at
B000h thru B7FFh, which nobody uses now due to COLOR displays!
All other upper-memory address space, C800h thru EFFFh, is NOT
used, due to the X= and NOEMS commands.This gives you only
32K of upper-memory, but it may be SAFER than I=TEST, etc.

Also, as you can see Lucho doing in his "boot" diskettes, what
about providing users the CHOICE of loading JEMM386/JEMMEX, or
UMBPCI?   Although UMBPCI cannot run on "absolutely" all chip-
sets and mainboards, it has never "failed" me or others in its
memory-test procedures.   Might SAVE your CD "boot" scheme, on
a system that otherwise cannot use JEMM386/JEMMEX.

Jack R. Ellis


--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] **NO** Problem with XMGR, **NOR** with UIDE!!

[Jack]

I am getting VERY TIRED of responding to FALSE problems about my
drivers!!

Last month, an entire thread on this forum was labelled "Problem
with UIDE", when that actually was FALSE!   The problem was only
a device-driver conflict, and it took several posts here to note
UIDE was being run WITH some unknown CD-ROM "boot" driver!   And
after all that, the thread CONTINUED to use the heading "Problem
with UIDE", which it WAS NOT!!

In that thread, near its end, we also have the post noting --

> I managed to make a Boot CD that works almost in all machines.
> The only one that is not working is "Virtual PC 2007".   It
> locks uppun execution of JEMM386 from a CD image.   XMGR is
> used because it is required by UIDE.

That is totally FALSE!   UIDE does NOT specifically demand using
XMGR and will run just fine with MS-DOS HIMEM, Japheth's HIMEMX,
or any other correctly written "XMS manager" driver.   UIDE only
requires that SOME driver -- it DOES NOT care which one! -- sets
up the necessary XMS memory for UIDE to use as its cache!!

And today, I note the following new post, in the same thread now
labelled "Re: [Freedos-user] Problem with XMGR (was: UIDE)" --

> On one machine I got a strange XMGR problem:
> On first try, XMGR (with /B) reports "cannot determine A20 method"
> and does not load, repeating it immediately (without /B) it loads
> with "A20 allways on".  Sorry, these are aproximate messages, the
> machine is 2 hours from here and another person was there.  I did
> this double load, by singlestepping and saying "No" to jemm386.
> On the same machine Himem.exe worka just fine, using "A20 allways
> on"

As anyone can see in the XMGR.ASM source file, NONE of the above
messages will be displayed by XMGR, as none of them EXIST in its
source!   XMGR is also written to use (A) no "A20 line" handling
if it sees "A20" already on at load-time, (B) IBM PS/2 "Port 92"
handling of "A20", or (C) old-style "Keyboard port" handling for
the "A20" line as its normal default.

XMGR will never -- I say again, NEVER! -- display that it cannot
determine which method to use for handling the "A20" line!   One
of the above 3 methods is ALWAYS present, on today's PC systems!
The many "strange" schemes for handling "A20" (which made MS-DOS
HIMEM.SYS end up over 30K bytes long!) are long since "obsolete"
and no-longer in use, as far as I know.   And "as far as I know"
is pretty good, since there have been FEW (legitimate!) problems
with XMGR for a long time!

XMGR can display "NOTE:  A20 line found on!", if that is so when
the driver loads.   But, it CANNOT display "A20 allways on", and
the use or non-use of its /B switch does NOT affect which method
for handling "A20" will be used.   Obviously, the PC system does
not change, between XMGR'S "boot" and its final loading in upper
memory, so it is FOOLISH to think that /B could have any effect!

If the message "cannot determine A20 method" is being displayed,
I quite strongly suggest that it is coming from SOMEWHERE ELSE!!
Maybe, that other system "2 hours away" was in fact using MS-DOS
HIMEM at that time, since as I recall HIMEM could display such a
message, if all its miserable 30K of init logic "gets confused"!
Or, maybe some other program or driver -- but NOT XMGR!!

I am SORRY, if people don't like hearing all this from me -- But
there are those who need to be A BIT MORE POSITIVE re: problems,
before they so-quickly RUSH to call them "Problem with UIDE", or
"Problem with XMGR", or problem with anything BUT their own lack
of reliable-and-true information ABOUT their problems!!!


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] "Test" UIDE Available, For VirtualBox.

[Jack]

Apologies for my "late" response re: UIDE v.s. VirtualBox.   Had to have
my (infected!) gall-bladder removed, 25-Jun-2011.   NASTY episode, and I
am still recovering and "moving a bit slow" on driver work!   Re: recent
EDR-DOS forum posts, I say the same as our author Mark Twain once did --
"The rumors of my demise are greatly exaggerated"!

As I have noted, UIDE is designed to run real "hardware" PC systems, not
software "emulators".   Full-and-complete emulators like VMWare cause no
problems.   But, from the error reports, VirtualBox seems not to emulate
ATA "Identify Device" commands (gives long timeouts!) and may not handle
all EDD BIOS requests (gives "EDD BIOS data ERROR" messages!).   UIDE is
written to "match" EDD BIOS disk I-O addresses with those same addresses
 from its PCI controller scan.   Only the PCI BIOS "knows" which UltraDMA
addresses it assigned to each controller.   If such a "match" fails, any
affected hard-disks are IGNORED, as UIDE cannot use UltraDMA for them!

With VirtualBox, or other similarly "incomplete" emulators which prevent
UIDE's hard-disk setup logic from succeeding, UIDE can use its "call the
BIOS" logic instead, like it does for diskettes and for any non-SATA/IDE
disks that may be in use.   I am assuming VirtualBox does NOT affect how
the normal BIOS disk I-O routines operate, which would be truly IDIOTIC!

So, I have added a /E ("emulator") switch to UIDE and UIDE-S.   /E makes
the drivers "call the BIOS" on every hard disk I-O request.   This means
UIDE can "go around" most of its hard-disk setup logic and simply assume
the BIOS "knows what it is doing" with disk drives.   CD/DVD drives that
were never part of the PC BIOS still require UIDE's setup logic to work,
or they will not get "detected" and used.   /E causes a minor speed loss
(5% or less) in UIDE's cache speed, due to calling another "driver" (the
BIOS) and since disks will be unable to use UIDE's XMS cache buffers for
direct I-O.   But, unlike /N1 which totally ignores hard disks, /E still
allows hard-disk data to be cached after BIOS I-O requests, and it ought
to let VirtualBox run O.K. with UIDE and UIDE-S.   I don't use and don't
want VirtualBox, so I must let users tell me if /E works as intended.

But, one BIG problem -- Many "El Cheapo" BIOS programs (including mine!)
have no DOS "Virtual Data Services" logic that tells a driver the 32-bit
address of I-O buffers.   When a DOS system uses protected-mode (JEMM386
etc.), no VDS logic says the BIOS can only do slow "PIO mode" transfers!
On my system, using JEMM386 and UIDE /E, file copies run 6 times slower,
even with UIDE's cache trying to help!   Since I don't live in Taiwan or
speak Mandarin, there is little I can do re: how mainboard makers design
their (wretched) BIOS programs.   Thus, users who require VirtualBox and
desire to run UIDE /E with it should avoid enabling protected-mode, when
possible, to prevent serious "El Cheapo BIOS" speed losses!

I have sent an updated 22-Jul-2011 DRIVERS.ZIP file to Johnson Lam, with
the /E switch added in UIDE and UIDE-S, for Johnson to test.He is my
"partner" in these drivers (and a better software "tester" than me!), so
the latest UIDE will not be "official" until he accepts it.   Johnson is
unavailable this weekend, so anyone who wishes to try the new UIDE /E on
a "test basis" can E-Mail me, and I will send you the file.   Do give me
an E-Mail address for you that accepts .ZIP files -- GMail and others do
NOT accept them, due to spammers/abuse!   My complete E-Mail address is:

   gykazequios "at" earthlink "dot" net

Also, Japheth tells me VirtualBox has been updated, and his XDMA32 "JLM"
driver is now O.K. with JEMM386 and the new VirtualBox release.None-
theless, I still intend to offer UIDE /E for all users, as there may yet
be other "emulator" problems, and since using "call the BIOS" logic with
hard disks could be valuable in other "odd" cases as well.

Jack R. Ellis



--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Weird UIDE.SYS (FreeDOS 1.1 Test) behavior under VirtualBox

[Jack]

Juan,

> Upgraded to VirtualBox 4.1, used the settings you said, and UIDE loads  
> fast
> now. (And CD access still works.) But I don't get an EDD error, I get  
> this:
>
>> UIDE, 6-16-2011. 5-MB Cache, CD/DVD name is FDCD0001.
>> No V2.0C+ PCI, BIOS I/O only!
>> CD0: IDE0 Secondary-master, VBOX CD-ROM, PIO.
>
> My UIDE command line is:
>
> DEVLOAD /Q %dosdir%\BIN\UIDE.SYS /D:FDCD0001 /S5 /N1
>
> Is that the expected behavior?

No, actually this is WORSE behavior!

Starting about 1994 with V2.0C of the PCI BIOS, there is a request
drivers can issue which returns "PCI " in the CPU EDX-register, to
say that a V2.0C or later PCI BIOS is in fact present.   When UIDE
does a scan for UltraDMA controllers on the PCI bus, it expects to
find this "PCI " value.   If not, UIDE assumes NO such controllers
are present, meaning no hard-disks nor CD/DVD drives use UltraDMA!

Note in your UIDE messages above that your CD drive is now a "PIO"
device, not an "ATA-33" drive (33-MB UltraDMA speed) like before!

I do not use and do not want VirtualBox, after all its problems as
users have noted on this list!However, if you do want to go on
using it, I would seriously "gripe" to Oracle (or its maintainers,
whoever they might be!) that if VirtualBox now FAILS a 17-year-old
test for the PCI BIOS, they need to DO SOMETHING about it, QUICK!

Jack R. Ellis


--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] "Test" UIDE Available, For VirtualBox.

[Jack]

Bernd,

Re: UIDE accepting only certain cache sizes, this is true
only for caches below 80-MB.   UIDE allows 5, 15, 25, 40,
or 50-MB caches, also ANY cache from 80-MB up to 4093-MB!
Disregarding its /F switch, the regular UIDE can thus set
64K-byte cache blocks with an 80-MB+ cache, which reduces
the amount of "math" and init logic needed.   For smaller
caches I use 8K to 32K cache blocks, and their parameters
come from UIDE's "CachSiz" table.   To keep the table not
too large, I settled on only the small-cache sizes listed
above.

Except for minimal "boot" systems, like yours and Lucho's
multiboot diskette, I recommend a minimum of 250-MB cache
to handle todays' LARGE "Windows" files.   Copying a 100-
MB file will take 200-MB of UIDE's cache space (input and
output), and some cache space must remain for directories
so the NEXT disk operation does not have to re-read them.

Having to "discard" DOS directories, to make room for new
data files, is the main loss of speed when using UIDE, so
users should allocate as large a UIDE cache as possible.

Jack R. Ellis


--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE /E For VirtualBox Now "Officially" Released.

[Jack]

As noted earlier by Rugxulo, Johnson Lam has now posted
the 22-Jul-2011 DRIVERS.ZIP file on his website at:

http://johnson.tmfc.net/dos/driver.html

Thus, the new UIDE and UIDE-S, with their /E "emulator"
switch for use by VirtualBox, are "officially" released
and users need not E-Mail me directly for the files.

Users who had been running UIDE /N1 (no hard-disks), to
avoid VirtualBox problems, can now try UIDE /E instead.
/N1 causes UIDE to totally ignore all hard-disks, while
/E does permit hard-disk data to get cached, after UIDE
"calls the BIOS" to do disk I-O.   This is much better!

Jack R. Ellis


--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] "Test" UIDE Available, For VirtualBox.

[Jack]

Eric,

>> Having to "discard" DOS directories, to make room for new
>> data files, is the main loss of speed when using UIDE ...
>
> A cache might already "know" that the directories are more
> useful because they are accessed more often ...

I did not want to add such logic in UIDE, because I dare not
"trust" that each DOS variant works the same.   At run-time,
UIDE uses exactly one "system resource", the Int 13h vector.
This makes it "generic" and lets it run on all DOS variants.
I do not even use interrupts ("polling" only) since some old
Intel chipsets with "errata" (bugs!) had interrupt problems!

> ... Also, you do not have to cache data on the first write,
> you can wait until it is read again before caching it ...

This would also add code in UIDE (a table of "pending cache"
disk output areas), that I do not want to include.   At 5.5K
of run-time code, 4.6K of which can be "stashed" in the HMA,
UIDE is rather efficient as-is, and I want to keep it so.

> ... Another question is how often people copy 100-MB files
> on "non-Windows" DOS systems and whether it bothers them
> that doing so, with a small cache, will "flush out" useful
> data such as FATs and directory data from the cache,
> temporarily reducing speed.

I "got into" device drivers back in 2003 because I still use
V6.22 MS-DOS to backup/restore my Windows/NT system.   I bet
many folks use DOS as a "simple" (and cheap!) backup/restore
system for Gawd-AWFUL Windows, rather than spending money on
some equally Gawd-AWFUL Windows application program!   File-
copy speed in such operations still matters to me, and since
memory is now ludicrously cheap, why not USE it for a cache?

> PS: Best wishes for your speedy operation recovery ...

Thanks!   I am "up and about", but food with high fat levels
still HURTS when I eat it, due to "less" digestive fluids in
my system!   The Doc says it can take 18 months to "get used
to this", so I must simply be patient.

Jack R. Ellis


--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Using /E And Other UIDE Options.

[Jack]

Santiago,

> Is there any specific order for UIDE options?
> I am using the lastest UIDE (07-22-2011) wtih this options:
>
> C:\DEVLOAD\DEVLOAD /H C:\UIDE\UIDE.SYS /E /H /S:15 /D:MYCDROM
>
> Under VirtualBox, I am having the same problems when detecting
> the hard disk as the previous UIDE version.

Apologies for my "late" reply to the above, as I was busy last
weekend.   Rugxulo's reply was right, there is no : (colon) in
a /S switch, only the number of megabytes desired for the UIDE
cache.   Only the UIDE /D: switch uses a colon, to be the same
as that switch in SHSUCDX or SHCDX33E.

Also, there is no "order" needed by UIDE's switch options, and
you can specify them in whichever order you like.   Be advised
that most switches, once they are set, cannot be "un-set".   I
did not believe "un-setting" UIDE switches was necessary.

Re: UIDE /E "not detecting" your hard disk, note that /E makes
UIDE "go around" (avoid) its normal EDD-BIOS disk setup logic.
So, using /E, you will not get a message describing the "type"
of unit each hard-disk is, nor what ATA-xxx speed it will use.
However, you SHOULD get "Disk run by the BIOS:  1." or greater
if your system uses more than one hard-disk.   This means UIDE
was told by the BIOS how many hard-disks are present, and UIDE
will then "call the BIOS" to do I-O requests for them.   Hard-
disk data is still cached by UIDE, even with its /E switch!

Jack R. Ellis


--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FD 1.1 Bootfloppy Problems

[Jack]

JPT,

> tried the floppy to partition and format the hardisk.
> It works if I choose not to load any drivers, i.e. --
> 1 - Install FreeDOS ...
> 3 - Dont load any drivers at all
>
> In the other cases, I get crashes.
> 1 - Using default settings results in a JemmEx
> errormessage after loading the kernel ...
> 2 - Using alternative xms memory manager (xmgr)
> results in invalid opcode after loading the kernel.
>
> This is the hardware:  P3-800, Asus Cubx board,
> Intel i440BX chip, 384MB of RAM, Network 3Com 3c905b

Ah, "good old" Asus, who AREN'T what they used to be, as I
know from my prior Asus mainboard and MANY service-related
E-Mails (both English ones from me, and Mandarin ones from
my partner Johnson Lam) that all went totally UNANSWERED!!

VERY unusual, for XMGR to fail!   I would need to see your
exact CONFIG.SYS file.   If you use XMGR, I assume you are
also loading JEMM386 (not JEMMEX!) with XMGR, or you would
get some message from JEMMEX that an XMS manager (XMGR) is
already loaded!

XMGR cannot by-itself display an "Invalid Opcode" message.
This must be coming from JEMM386.

Also, only UMBPCI or the "EMM" driver (JEMM386, EMM386, or
JEMMEX when it is used) will "examine" the system and find
the upper-memory addresses (Ah to Eh) which can be
used.   XMGR examines only for XMS memory, 10h and up,
and relies on the "EMM" driver to deal with upper-memory.

So, my opinion is that your system likely has some area in
the upper-memory address range that "confuses" JEMM386 and
is causing your problem.

You can try running UMBPCI followed by XMGR, with NO "EMM"
driver, as I show in Section 5 of the README file for XMGR
and UIDE.   This leaves your system in "real mode", not in
"protected mode" as with the "EMM" drivers, so you may not
be able to run some protected-mode application programs.

But this lets UMBPCI "examine" the system for upper-memory
instead of the "EMM" driver.   UMBPCI, and XMGR in its XMS
memory tests, both have a somewhat more modern memory-test
scheme than the JEMM drivers, which desired to stay "fully
compatible" with the scheme used in the original EMM386.

So if XMGR + UMBPCI "survive" loading on your system, this
usually denotes an upper-memory "examination" problem with
JEMM386/JEMMEX.   You may then need to use specific I= and
X= commands in loading the JEMM drivers, to "avoid" memory
areas that cause trouble!

In any case, do post your actual CONFIG.SYS file, so I and
Japheth can see exactly what you are doing.

Jack R. Ellis


--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FD 1.1 Bootfloppy Problems

[Jack]

Bernd,

My apologies -- Hadn't noticed that I was in fact responding
to "old news"!

Jack R. Ellis


--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] IMPORTANT "Off Topic" -- U.S. Medical Costs!!

[Jack]

Re: my 25-Jun-2011 gall-bladder removal, the hospital has
finally sent a $960 bill for my "co-pay" (amount not paid
by my medical insurance company).   I sent a check today.

The hospital finance lady told me there is not a discount
if I pay cash (as expected), as my bill had been adjusted
"down" thru my insurance company -- by $37,000!!   I then
asked what my total bill was:  Over $49,000 which did not
include separate bills by all doctors involved!!

If I had no medical insurance, the hospital would bill me
the full $49,000 with only a 20% discount if I paid cash,
and I know the doctors would have "Had me for lunch" too!
If they can work for 1/4 that amount if "guaranteed" pay-
ment by insurance firms, how can they "RIP OFF" uninsured
people like that??   The answer, of course, is that a lot
of uninsured folks in the U.S. do NOT pay medical bills!!
Small wonder, given the above!!   And in 2005, when I had
prostate surgery (only $18,000, a "bargain" after my June
surgery!), I asked that hospital's people why they charge
so much.   "Because we CAN charge so much"!!

I have these two SERIOUS comments for all on FD-User:

1) If you do not live in the U.S.A., visit here, and find
yourself sick, do your BEST to get back on an airplane
and be treated in your own countries, NOT HERE!!

2) If you do live in the U.S. and do not have any medical
insurance, GET some, REAL QUICK!!

A $49,000 hospital bill, for only a gall-bladder removal.
One can only wonder what such U.S. WHOREHOUSES charge the
uninsured for cancer or a heart-attack!!

Jack R. Ellis


--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE Performance -- Small Caches DO Work O.K.!

[Jack]

For years, I have told people to use as much cache as
possible with UIDE, to handle today's large files and
still "leave space in the cache" for DOS directories.

Today, Tuesday 23-Aug-2011, I ran "experiments" using
a driver equal to UIDE-S, with a new 10-MB cache size
of 1280 8K-byte data blocks.   I never liked the 5-MB
cache that some users MUST have (only 640 blocks, not
enough data!) so I chose to try a 10-MB "tiny" cache.

I ran my usual test of copying a 635-MB video drivers
CD to disk.   With my regular 500-MB UIDE cache, this
test takes around 124 seconds, plus-or-minus about 2.

With only the 10-MB cache, the test took 128 seconds,
merely 4 seconds more!   I checked 25, 50, and 100-MB
caches as well, and none suffered in speed from being
small-sized!   Each performed as well, maybe a "hair"
better in some cases, as the 10-MB cache!

So, it seems I may have been "All wet!" (misinformed)
re: UIDE's cache performance v.s. cache size.   Users
may want to check this on their systems, maybe across
a variety of applications.   And I expect there are a
few "large file" systems which do need larger caches.

But, it now seems that "casual" users of DOS and UIDE
need NOT worry re: using only a 25/50/100-MB cache --
They do seem to perform a LOT better than I expected!

Jack R. Ellis


--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE Drivers Updated, "New" UIDE2.

[Jack]

Johnson Lam has posted an updated 9-Sep-2011 DRIVERS.ZIP file, on his
website at , which contains a "new"
UIDE2, also updates to the other UIDE drivers.

UIDE2 uses old-style "protected mode" caching, that was in UIDE until
August, 2010.   Try as I may, I simply cannot get the current all-XMS
UIDE to run any faster in protected-mode (JEMM386 etc.).   All of its
cache tables are in XMS memory.   This requires a slow Int 15h "trap"
thru JEMM386, to "fetch" any XMS data.Absolutely NOT any fault of
JEMM386, but due to Intel's too-complex 80386+ protected mode scheme!

UIDE2 sets its binary-search table in memory beyond the driver, which
avoids 50% of XMS accesses and saves time -- fewer Int 15h "traps" in
protected-mode.   As it uses more HMA or memory for its search table,
UIDE2 does have cache-size limits, noted in the UIDE2.ASM file.   But
it is still up to 5% faster for protected-mode, and so UIDE2 is "Back
in service!" for users who run JEMM386/EMM386 etc.

I was also "unhappy" about UIDE-S running only 4 CD/DVD drives, since
there may be a few "CD copier" PCs with up to 6 CDs.So, UIDE2 and
UIDE-S now handle up to 6 CD/DVD drives!   Any users who in fact have
7 or 8 CD/DVD drives can still use the "full" UIDE or the non-caching
UIDEJR, which will run up to 8 CDs/DVDs (UIDEJR with its /U8 switch).

UIDE2 and UIDE-S are still 7.5K-byte .SYS files, for "boot" diskettes
or other space-limited systems.   UIDE2 also handles the /N3 "No XMS"
switch and sets the "UIDE$" default name if no CD/DVD drive is found.
So, UIDE2 can be run with FreeDOS "automatic loader" scripts on their
distribution CDs.   (Not possible for UIDE-S, which now "barely fits"
into 7.5K!).


--
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT 
space for its ease of implementation, lower cost, and increased 
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Upgraded UIDE2 and UIDE-S Available!

[Jack]

Johnson Lam has posted an updated 23-Sep-2011 DRIVERS.ZIP file, with all
UIDE drivers improved, on his website at --



UIDE-S now runs 30 BIOS disks/diskettes and 8 CD/DVD drives, and it also
sets the "UIDE$" default name when no CD/DVD drives are found, making it
more "identical" to the full UIDE.FreeDOS "autoloader" scripts could
now use UIDE-S, if they can otherwise deal with XMS memory.   I am still
unable to "fit" /N3 switch logic (87 more bytes) in a 7.5K-size UIDE-S!

UIDE2 now leaves the entire 4608-byte driver (exactly 4.5K!) in upper or
DOS memory, when its /HL switch is given.   /HL thus allows a 280-MB HMA
cache for V7.10 MS-DOS and 425-MB+ for other DOS systems -- My own V6.22
MS-DOS can set 600-MB reliably (used to CRASH above 585-MB)!   The 25-MB
larger cache may help V7.10 MS-DOS users, and perhaps others, who want a
"faster" cache for protected mode.   UIDE2 is also back to 34 BIOS units
and 8 CDs/DVDs, "same as UIDE" like before!

UIDE and UIDEJR have "minor" size reductions, and all other drivers have
merely been re-dated to 23-Sep-2011 for consistency, as always.

I hope protected-mode users like the new UIDE2.   Except for differences
in doing "protected caching", it is now "identical" to UIDE in features,
still fits in a 7.5K file, and UIDE2 is one of my best drivers ever!


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] New UIDE Drivers -- Common "Core" Logic.

[Jack]

Johnson Lam has posted a new 30-Sep-2011 DRIVERS.ZIP file on
his website at .

The UIDE, UIDE2 and UIDE-S drivers can now be assembled from
the UIDE.ASM source file, using a  /dPMDVR  switch for UIDE2
and a  /dMINDVR  switch for UIDE-S ("protected" or "minimum"
options).   The three caching drivers now have common "core"
logic, and each runs 10 controllers, 34 BIOS disks/diskettes
and 8 CD/DVD drives.   A lot less "upgrade work" for me with
only 1 source file, also a bit more "reliability" for users!

XMGR, RDISK, and UIDEJR (quite "different" and still has its
own source file!) are unchanged, and are merely re-dated for
consistency, as always.

Note:  By error, the UIDE2.ASM source may still be included,
in the 30-Sep-2011 DRIVERS.ZIP file.   UIDE2.ASM is obsolete
and should no longer be used -- It shall be deleted soon!


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Tom's "ALWAYS Good" Ideas!

[Jack]

Re: Tom Ehlert's help, Eduardo Casino replied --

> A big THANKS to you.   Optimising the memcpy routines
> was my next objective, so you saved me a lot of fun ;)

Tom's ideas are "ALWAYS good"!   Maybe half of my UIDE
drivers has been much hard work, but the other half is
Tom's suggestions in 2003 of (A) using XMS memory as a
buffer for UltraDMA I-O which is misaligned or crosses
a 64K boundary, and (B) using "free" HMA space to save
upper/DOS memory and putting much of my drivers there!
Tom is often quiet in the background, but when he DOES
speak, it MATTERS!

Jack R. Ellis


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] New 7-Oct-2011 UIDE Drivers, Fixing A "BUG" In The "EDD BIOS"!

[Jack]

Johnson Lam has posted an updated 7-Oct-2011 DRIVERS.ZIP file on
his website, at .   The
site still has a "Last Update" date of 9-30, but the files which
download ARE dated 10-07-2011 and have been verified O.K.

This update is not more driver improvements but fixes a "BUG" in
some of the "EDD BIOS" logic being used today!

Daniel Nice noted that on 3 of his 5 systems, a USB memory stick
declared to the BIOS as a "hard disk" caused the UIDE drivers to
"duplicate" his last actual hard disk!   He found the "EDD BIOS"
is NOT updating the "DPTE" pointer for a "USB stick" disk -- The
BIOS declares 30 bytes of EDD data, but in fact returns only 26,
leaving the last actual hard-disk's "DPTE" pointer still there!!
This is clearly an ERROR in the BIOS, that needs to be CORRECTED
by those ["children", usually!] who create BIOS programs!

Daniel suggested a "workaround" of setting the "DPTE" pointer to
all-ones before UIDE issues Int 13h AH=048h.   That worked fine!
The UIDE drivers can again handle all "real" SATA/IDE hard disks
without getting confused when USB-stick "disks" are also in use.

Users should upgrade immediately to the 7-Oct-2011 UIDE drivers,
if (A) their system BIOS lets "USB memory sticks" be declared as
"hard disks" and (B) their system also has one or more REAL hard
disks attached!

Many Thanks to Daniel, who in fact did all my "Leg Work!" in his
analysis and resolution of this Bad BIOS "BUG"!


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FDAPM

[Jack]

I run a 15-year-old Windows/NT V4.0, "backed up" (and restored
occasionally!) by a 17-year-old V6.22 MS-DOS.   My system is a
"flat" desktop (not a "tower") with its power-supply fan and a
13-CFM extra fan, thanks to my old 85-watt AMD 2100 CPU.   TOO
MUCH, so now I have a 45 watt AMD 3000+, which never goes over
40 degrees centigrade with its "stock AMD" CPU fan, the power-
supply fan, and my "extra boy" on the back of the case.

With the above hardware and software, I HAVE NEVER had any DOS
or Windows/NT program cause overheating, merely from my system
"sitting there" and no-matter WHAT "idle loop" was being used!
I have absolutely NO "power management" software, and all BIOS
options to "control" power are disabled or turned-off!Even
with my "hot running" 2100+, it never got over 60-C, far below
AMD's 85-C design limit for those 10-year-old chips!

Absolutely NO "self respecting" computer, or computer program,
should at-all REQUIRE using "FDAPM" or any equivalents!   What
has happened to Industrial RESPONSIBILITY, i.e. making systems
that RUN, WITHOUT requiring such "Band Aid" power software??!!

In my opinion, and "laptop" OR NOT, any computer that DOES get
too hot just "sitting there" is a HOPELESS piece of TRASH that
should be sent back for a REFUND (if possible!), or should get
the solution that "DOS386" voiced on this forum (in one word!)
about my ATROCIOUS medical bills, 4 months ago:  KALASHNIKOV!!


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE Drivers Updated, UIDE-S Eliminated!

[Jack]

Johnson Lam has posted a new 16-Oct-2011 DRIVERS.ZIP file on
his website at .

In it, UIDE has again been reduced down to a 7.5K-byte file,
same as UIDE2, for "boot" diskettes and other systems having
limited space.So, UIDE-S is no longer needed, and it has
been eliminated!   UIDE2's performance is also improved, and
all other drivers have merely been re-dated to 16-Oct-2011.

To get UIDE below 7.5K, I had to delete its /M switch./M
saved only 256 bytes of HMA, "not enough" to matter, as UIDE
uses only 4336 bytes of HMA in all cases.   Even poor MS-DOS
V7.10 (short on HMA due to long-filename and Win95/98 logic)
still has 9100+ bytes of free HMA, and a "BUFFERS=4" command
in CONFIG.SYS can reduce what the kernel needs!   Most other
DOS systems have MUCH more free HMA and should be no problem
if loading UIDE with a /H switch.   UIDE can be re-assembled
with "SBUFSZ equ 256", if anyone absolutely requires its 256
byte binary-search buffer (runs maybe 1% slower)!

The UIDE2 driver now runs a "hair" faster for protected-mode
users, due to re-adding the old "ScnD" subroutine which uses
a "scasw" command (not a full binary-search) in deleting old
cache-table entries.   "ScnD" is used with UIDE2's /H or /HL
switches, as its HMA caches are small enough for such logic.
Large caches in upper/DOS memory still use the current UIDE2
"SrchD" routine, for better speed with bigger search tables.

The "UIDE" caching drivers now consist of only --

1) The UIDE.ASM source file (assembles both drivers).
2) The UIDE.SYS driver for up to 4-Gigabyte caches.
3) The UIDE2.SYS driver for "fast" caches in protected-mode.

I hope such a "simplification" is of benefit for UIDE users!


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Undeserved Comment Re: EMM/JEMM, "A20", Etc.

[Jack]

I am DISMAYED by some of the recent comments on this board
regarding "old EMM386" v.s. JEMM386/JEMMEX, the "A20" line
etc.!

First, I use and recommend JEMM386/JEMMEX with my UIDE and
other drivers.   I absolutely REFUSE using "old EMM386" by
Gates & Co. because it has (A) Never-fixed BUGS in its VDS
logic, (B) FAR too much "Custom Crap" for wretched Win/311
as anyone can "see" in its 1.8-MB of source files, and (C)
is a 125- or 130K driver that "eats" FAR too much run-time
memory!   "It sucks!" in short, and I view UIDE "lucky" to
be able to use its OWN UltraDMA, instead of what Gates and
all his "flunkies" left us with as "DMA" when they DROPPED
MS-DOS in 1995!   I also want NOTHING to do with FD-EMM386
and anyone who wonders why can read the Revision Notes for
JEMM386, to view all of what Japheth had to do BEFORE poor
old FD-EMM386 worked even "plausibly" as the new JEMM386!

Re: JEMM386/JEMMEX failing on some systems, this is likely
due to "modern" address spaces that the JEMM drivers can't
detect.   But Japheth once told me that he CHOSE to retain
all of EMM386's memory-detection logic, so his drivers are
"compatible" with what Gates & Co.'s [never updated] TRASH
will do!So, do you really expect EMM386 will do a much
better job of detecting memory??   I would NOT!!   If some
system has a "problem" loading JEMM386, or loading EMM386,
its user MUST "experiment" with the I= and X= commands, to
selectively include/exclude address areas, until a desired
EMM driver DOES load successfully!   Never-was, and never-
will-be a "fully automatic" PC system, and sometimes a few
experiments loading drivers (mine included) are NECESSARY!

Finally, it is a bit "LATE in the game!" to be thinking of
new schemes for handling the "A20" line.   My own XMGR has
exactly 4 methods:

  (A) IGNORE "A20" if it is found "enabled" when XMGR loads
   i.e. the DOS kernel turns it on forever.
  (B) Use keyboard-port logic if /PN was given.
  (C) Use port 92h i.e. IBM PS/2 logic if /PA was given.
  (D) "Ask the BIOS" if port 92h logic is there, if neither
  /PA nor /PN is given.

XMGR doesn't handle the usually-ignored BIOS calls, any of
the "ancient" Compaq, H/P, ATT 6300 or other 1990s-vintage
schemes to handle "strange A20 logic" (all of which caused
Gates & Co. HIMEM.SYS to reach 30K!), etc.Except for a
"bug" in its port 92h logic, back in 2009, nobody has ever
"complained" to me that XMGR's "A20" logic was inaccurate,
inadequate, etc.!

So, why don't we just leave current "A20" handling as-is??
For 99.44% of us, it works fine!   Any "strange" system on
which it does not work usually needs TROUBLE-shooting, NOT
yet-another new "A20 handling" scheme!!


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, "A20", Etc.

[Jack]

Alain,

> First of all, let me clear one MISUNDERSTANDING ... The EMM386
> that works ok is from Michael Devore, which was extensevely
> tested by the members of FreeDOS.
>
> Most of your answer regards Gates & Co. product, sorry for the
> confusion

NEITHER a "misunderstanding", NOR any "confusion", at least not
in MY mind!   Do note what I posted AFTER my comments about the
EMM386 drivers from my [obviously] "much adored" Gates & Co. --

>> ... I also want NOTHING to do with FD-EMM386 and anyone who
>> wonders why can read the Revision Notes for JEMM386, to view
>> all of what Japheth had to do BEFORE poor old FD-EMM386 worked
>> even "plausibly" as the new JEMM386!

"Extensively tested", you say??   If so, and given that the last
FD-EMM386 upgrade is still dated 27-Aug-2006, then how would you
explain all the updates, in Japheth's "Changelog" for his JEMMEX
and JEMM386 drivers, that are dated AFTER 27-Aug-2006??!!

Also, note that JEMM386/JEMMEX are now part of the FreeDOS "Base
Software" list, while FD-EMM386 is no-longer so included.

I have reviewed Japheth's "Changelog", I believe much of what he
had to do changing FD-EMM386 to JEMM386 are "Flat-Ass DISASTERS"
and I shall continue to AVOID using FD-EMM386, just like I would
avoid the PLAGUE!!

> About the A20 issue.   I used it because I had a very strange
> problem:  After a crash (with only XMS) the machine never booted
> again from the disk!!!   I had to boot once from a CD and reboot
> again from the disk.   That never happened to me and is completely
> unheard of ...

I suggest that a lot of other things besides the "A20" line could
have caused such a problem.   In my opinion, you need quite a bit
more "evidence", BEFORE you can fault the "A20" line only because
your crash appeared to occur "with only XMS"!!

Jack R. Ellis


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, "A20", Etc.

[Jack]

In my previous post about FD-EMM386 being changed to JEMM386, and
to be perfectly clear, those "Flat-Ass DISASTERS" I noted are not
at ALL in JEMM386 but are in FD-EMM386 and had to be CORRECTED by
Japheth!   Sorry for any confusion caused by me -- JEMM386/JEMMEX
ARE the "EMM" drivers of choice, in my opinion!


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, "A20", Etc.

[Jack]

 i.e.,
its METHODS are the same, no-matter what actual CODE it uses.

> If JEMM mimicks MS, then that could explain why JEMM is harder
> to tame than FD-EMM for the user as AFAIR, FD-EMM tried to have
> quite cautious detection :-!

Can't say there, either, as I avoid FD-EMM386 like the PLAGUE!

> You know my conclusion - EMM drivers are just not suited for
> one size fits all boot disks. But this is a pity and I would
> be happy if some EMM driver could eventually prove me wrong.

Good luck waiting for one!   But, why wait -- Why not recommend
that users who create "boot" diskettes DO NOT include any "EMM"
driver in such "boot" activities??   If a "boot" diskette is to
get a system RUNNING, and maybe copy-over added files to use if
the system boots from a hard-disk, WHO NEEDS an "EMM" driver in
a diskette "boot"??   I use UMBPCI/XMGR on my own diskettes and
have NEVER required an "EMM" driver when they "boot" my system!

>> Finally, it is a bit "LATE in the game!" to be thinking of
>> new schemes for handling the "A20" line.   My own XMGR has
>> exactly 4 methods:
>>(A) IGNORE "A20" if it is found "enabled" when XMGR loads
>> i.e. the DOS kernel turns it on forever.
>
> If you mean FreeDOS: No the kernel does NOT turn on the A20,
> it asks the XMS driver to do that.  But it would be NICE if
> the driver could explicitly switch A20 ON and THEN does not
> touch it any more ...

You are BADLY misinformed!   Make a copy of Lucho's old "boot"
diskette (from the COMBOOTF.EXE file on Johnson Lam's website)
and "boot" from it using Lucho's "Option 5", which is FreeDOS.
Would you care to GUESS the first message XMGR will give you??
Something like "NOTE:  A20 line found on!", maybe??!!   And if
XMGR is the first actual DRIVER loaded, then what-else BUT the
FreeDOS kernel is hard-enabling "A20"??!!   A "Hairy Thunderer
or Cosmic Muffin", perhaps??!!

> In short, I would be happy about a "force-on" "A20 method".

Glad to hear that, since your own FreeDOS is already DOING so!

>> (B) Use keyboard-port logic if /PN was given.
>> (C) Use port 92h i.e. IBM PS/2 logic if /PA was given.
>> (D) "Ask the BIOS" if port 92h logic is there, if neither
>> /PA nor /PN is given.
>
> Fair enough.   I hope the BIOS is reliable for the detection.

So do I, as such calls were defined by Gates & "Flunkies" about
20 years ago!

>> XMGR doesn't handle the usually-ignored BIOS calls ...
>
> What makes you think they are usually ignored?  Would the BIOS
> not at least ANNOUNCE that they are ignored, detection-wise?

Knowing the "children" on that island in the South China Sea
who write BIOS programs, I doubt any BIOS would make such an
announcement.   "C" is the "top language" for their masters,
who are all "cheap" anyway, thus TRAINEES get most BIOS work
since it tends to be "Horror of HORRORS" ASSEMBLY-language!!

Why do I say such calls are usually ignored?   Because XMGR
has NEVER supported them, and no one has ever "complained"
to me that the "A20" BIOS calls SHOULD be supported!   One
more "nice idea" by Gates & Co. that I expect nobody uses!

> In any case, BIOS calls tend to do (B) or (C) anyway, just in
> a slower way, so you are right to ignore those calls, and the
> ancient stuff as well, of course :-)

Of course!

>> So, why don't we just leave current "A20" handling as-is??
>
> See above.   Or maybe the KERNEL could do part of the work ...

The kernel already IS doing part of the work!   Try ALL of the
options on Lucho's "boot" diskette"!   You will find that only
MS-DOS and PC-DOS are not hard-enabling "A20", when they load.
DR-DOS, the Russian PTS-DOS, ROM-DOS, and FreeDOS all DO hard-
enable "A20".

To use an old U.S. phrase, "Don't MESS with success!" [and the
word "mess" is the polite 4-letter word!].

> Note that my suggestion is NOT related to Alain's "I had
> vague problems and think A20 changes help".   It is more
> my GENERAL suggestion - namely that we should stop switching
> around a dusty rusty address gate line.  Let's just make SURE
> at boot that the gate is OPEN, then keep it like that. As an
> OPTION for the command line of any XMS driver, for example ...

I disagree.   MS-DOS and PC-DOS have good reason for NOT hard-
enabling "A20" that the other kernel designers have forgotten.
There ARE still a few programs which use their OWN enables and
disables of "A20", and those programs FAIL if the line MAY NOT
be switched-off or switched-on!   I do not recall exactly what
programs they are, but I DO recall that the LOADFIX program in
MS-DOS and Windows specifically "remedies" one such problem!

Given that, I am NOT in favor of adding such a hard-enable for
"A20" in my XMGR driver.   If other XMS managers offer such an
option, I hope their users "Know what they are doing!" if they
use that option!!   [And "Know what they are doing" has become
just as problematical as some of the "A20" issues themselves!].

Jack R. Ellis


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Ciosco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, "A20", Etc.

[Jack]

>
>> Glad to hear that, since your own FreeDOS is already DOING so!
>
> I'm wondering about what JEMMEX does different, as it does work
> for me, while others find it trashing their system and/or data.

Not "my department" -- Ask Japheth.

>> ... Such [BIOS "A20"] calls were defined by Gates & "Flunkeys"
>> about 20 years ago!
>
> Never underestimate BIOS writers for their spaghetti code ...

I do NOT "underestimate" them, I rather call them the BLOODY FOOLS
they DESERVE to be called!   Starting with Gates & Co., who SHOULD
have made CD/DVD logic go directly into the BIOS instead of making
a separate "MSCDEX" with its pack of [lousy!] add-on drivers, back
about 1988!!   Imagine how much farther-along PC systems might be,
if many "All we want is MONEY!" decisions [i.e. "cheap" solutions]
HAD NOT been made, and just-a-bit more THOUGHT had been applied!!

>> The kernel already IS doing part of the work!   Try ALL of the
>> options on Lucho's "boot" diskette"!   You will find that only
>> MS-DOS and PC-DOS are not hard-enabling "A20" when they load ...
>
> So some drivers can't cope with buggy BIOS/kernels with regard
> to A20 (and E820) ?

I did NOT say that, either -- I only replied to Eric's suggestion
about the kernel handling "A20" by saying most of them already DO
handle it!   Perhaps "mistakenly", since there ARE still programs
which will "not like" kernels that hard-enable "A20", as I noted!
One of the reasons why I choose to REMAIN with V6.22 MS-DOS, even
despite my many-other thoughts about Gates & "Flunkeys" -- He and
all his F's in fact DO handle "A20" as their XMS specs recommend!

Jack R. Ellis


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, "A20", Etc.

[Jack]

Alain,

>> In creating JEMM386, Japheth did not merely improve things!   He
>> made FD-EMM386 RUN PROPERLY!
>
> Finaly you agree with me!   Michael Devore's emm386 was tested very
> very much by the members of FreeDOS and Michael fixed ALL issues.

I DO NOT agree with you, and HE DID NOT fix all issues!   As far as
I know, the many "bugfix" items I noted in my E-Mail to Eric REMAIN
in FD-EMM386!   They were fixed ONLY when Japheth did so within his
own JEMM386, and FD-EMM386 itself remains NEVER-UPDATED!!

> Michael started with something, I don't remember what.   But he
> grew so much disgusted with these fights that when the last issue
> got fixed, he *disapeared*

Read the FD-EMM386 source file, to see what he started with.

You should more-correctly say "When the last issue HE KNEW ABOUT
got fixed, he *disappeared*"!   If that were not so, then like I
noted to Eric, HOW do you explain all those "bugfix" items which
Japheth had to address LATER??!!

But, "Have it your way", Alain!   If you wish to continue with a
5-year-old FD-EMM386 that has known BUGS and is NO-LONGER on the
"Base Software" list for FreeDOS, then "You go right ahead!" and
use FD-EMM386.   As for me and quite a lot of others, I will use
JEMM386, which I consider to be FAR superior and always WILL be!

Jack R. Ellis


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, "A20", Etc.

[Jack]

Jeffrey,

>> As for me and quite a lot of others, I will use JEMM386,
>> which I consider to be FAR superior and always WILL be!
>
> What exactly are the advantages of JEMM386?

1) Under current maintenance, not "abandoned" like FD-EMM386.
2) Many never-fixed FD-EMM386 "bugs" ARE fixed in JEMM386, as
you can read in the JEMM ChangeLog at .
3) Part of the FreeDOS "Base Software" list, meaning "Cleverer
minds than me!" value JEMM386 above FD-EMM386, for FreeDOS.

> Is there a noticeable difference over FD-EMM386 if I am only
> using EMS for ramdisks/drivers?

If you mean the very-old Lotus/Intel/Microsoft "Expanded Memory"
then I cannot comment, as I have never used actual "EMS" memory.

If by "EMS" you actually mean XMS memory, there should be little
performance difference, as the XMS driver handles allocation/use
of that memory.

> Are the bugs dependent on hardware?

Most are not, but a few are.   Read the JEMM ChangeLog, then you
can decide which hardware-dependent problems might have affected
its "predecessor" FD-EMM386.

Jack R. Ellis


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] 4th-Grade English.

[Jack]

It is VERY TIRESOME, having to respond to posts on this board with
"I DID NOT say ..." or "I DO NOT agree ...", when one's REAL words
are either "misunderstood" or often TWISTED for some other agenda!

Many such "replies" would cause their writers to FAIL, QUICKLY, in
almost all U.S. High-School "Debate" classes, from NOT speaking to
the "POINT" of whatever the original post was!

Is it REALLY true, that (A) using 4th-grade English [age 9 level],
(B) proof-reading SEVERAL times before making posts, and (C) doing
all possible to be CLEAR, are now NOT-ENOUGH on boards like this??

Or does the U.S. "Slept Thru High-School" DISEASE [as so many here
took GREAT SPORT in achieving!] now afflict not just OUR last 2 or
3 whole generations of total idiots, but EVERYBODY world-wide??

COME ON, People!!   DO NOT "twist" posts to suit your OWN agendas!
PAY ATTENTION to the "POINT" of what people try to post, both here
and elsewhere!!   And DO realize you just might have to "WAKE UP!"
 from such teenage "slumber", and USE YOUR BRAINS, now-and-then, to
UNDERSTAND what is obviously "technical" data, not just "Tee-Hee!"
babbling from "Slept Thru" BRATS!!

"Sorry, but THERE IT IS!!", as the British might say!


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] 4th-Grade English.

[Jack]

> [1] Not everybody on the list is a native English speaker.

True.   But I know enough to differentiate between (A) language
problems which I correct, as you can see if you compare Alain's
original post to my answer, and (B) "missing" or "changing" THE
POINT of posts on boards like this!   It was (B) that I decided
to address earlier today.

> [2] You need to calm down.  The tone of many of your postings
> is borderline hostile.

"Tough Tomatoes" [with "Tomatoes" our polite word].   I reserve
the right to decide for myself if a mild or strong "tone" might
help my readers GET THE MESSAGE!   Given all in recent threads,
I felt my comments and "tone" were NEEDED!   "Hostile" or other
such labels from you ("politically incorrect" is my #1 favorite
by the label-slappers!) can simply be ignored.   After all, one
simply has to live-with "modern" society, doesn't one??


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, "A20", Etc.

[Jack]

ven though JEMM386 actually is better than FD-EMM386 and a
> lot more up-to-date and maintained.

Again, "Not my department", especially as I know only enough about
protected-mode to get my "real mode" XMS move logic running within
XMGR and UIDE.   Ask Alain.

>> ... Why not recommend that users who create "boot" diskettes DO
>> NOT include any "EMM" driver in such "boot" activities??
>
> I totally agree with your recommendation.

"Yahoo"!   Or "Yay-hoo!" depending on what U.S. state hatched you!

>> Would you care to GUESS the first message XMGR will give you??
>> Something like "NOTE:  A20 line found on!", maybe?
>
> The FreeDOS kernel only switches A20 by calling HIMEM/XMGR, so if
> XMGR finds A20 to be already on, then the BIOS probably did that.

I really DOUBT IT, or else why do MS-DOS V7.10, MS-DOS V6.22 that I
still use, and PC-DOS in fact NOT give me the same message!   Maybe
you need to look "a little DEEPER" into the FreeDOS kernel!

>>> In short, I would be happy about a "force-on" "A20 method".
>
>> Glad to hear that, since your own FreeDOS is already DOING so!
>
> It is not, but probably it should ...

"Baloney!" [polite "B" word], as I just noted above!

>>>> XMGR doesn't handle the usually-ignored BIOS calls ...
>
>> Why do I say such calls are usually ignored?   Because XMGR
>> has NEVER supported them, and no one has ever "complained"
>
> That simply means that all modern systems support port 92 and
> or keyboard controller style A20.   It does not mean that BIOS
> calls for switching A20 would be broken in BIOS.

I never said or implied the BIOS calls WERE at-all "broken"!
I simply said that it appears nobody USES them, for the same
reason you note:  "Keyboard" or "Port 92h" logic works fine.

> Proves your point that using the BIOS to manipulate A20 is not
> necessary, nobody has yet reported non-BIOS to cause problems.

Agreed, and I can "save" adding all that logic into XMGR!
"Hallelujah!", and "Saints be Praised!" [take your pick]!

>> The kernel already IS doing part of the work!   Try ALL of the
>> options on Lucho's "boot" diskette"!   You will find that only
>> MS-DOS and PC-DOS are not hard-enabling "A20", when they load.
>> DR-DOS, the Russian PTS-DOS, ROM-DOS, and FreeDOS all DO hard-
>> enable "A20".
>
> The FreeDOS kernel contains no 8042, port 92 or int 15.24 style
> A20 manipulation code (or it would be very well hidden) so the
> only A20 work of the kernel are calls to XMS driver functions
> number 5 and 6. Maybe an obscure side-effect of something else
> distorts your measurement? The boot menu used by Lucho might
> enable A20 but the MS / PC DOS kernel then disabled it again?

REALLY doubtful, since when I do NOT use Lucho's "boot" diskette
I get the SAME results!   I suggest you need to investigate your
"very well hidden" comment, above!

> I still cannot find *how* the FreeDOS kernel would enable A20
> before XMS drivers are loaded ...

If I had to "guess", I suggest you investigate whatever logic
"burns up" all HMA space for DOS "buffers".   FreeDOS HMA is
not available for drivers like my UIDE until after AUTOEXEC
is run!   That is why I tell FreeDOS users to run your DEVLOAD
[in AUTOEXEC] to load UIDE, if they want to load UIDE into HMA
space.   SOMETHING is enabling "A20" in the FreeDOS kernel, and
it does NOT happen, no-matter WHAT loading scheme I use, with
MS-DOS or PC-DOS!   "Look a bit further!", my friend!

>> ... Given that, I am NOT in favor of adding such a hard-enable
>> for "A20" in my XMGR driver.   If other XMS managers offer such
>> an option, I hope their users "Know what they are doing!"
>
> As all options, the user has to decide whether to use that, yes.

How carefully you avoid my "problematical" comment!

Jack R. Ellis


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] 4th-Grade English.

[Jack]

Mark,

> The way this post has degenerated I think demonstrates exactly what the
> original poster was trying to say ... Logic and analysis should be able
> to be demonstrated regardless of the language abilities of the poster.

My error, to have titled this thread "4th-Grade English", which did get
peoples' attention, but in the wrong way.   THANK YOU for your insight,
in the same sense as Captain Armstrong [in your 1980s "Anzacs" series],
who initially addressed his all-volunteer platoon by saying, "You shall
be treated as intelligent adults"!

Jack R. Ellis


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDos4Kids (and Kids-at-heart)

[Jack]

Andrew,

> I anticipate replacing the dying and clunky old hard-drives for SD
> cards on a 44-pin IDE adapter for better performance and improved
> efficiency.   I imagine that the recent improvements with FreeDOS'
> EIDE would facilitate a hardware upgrade like that - am I
> understanding that correctly, please?

I am the author of the UIDE disk/CD/DVD caching driver, and I assume
your reference to "EIDE" is in fact addressing the UIDE driver.

I have not tested UIDE with "SSD" disks, nor has anyone commented on
such testing.   FreeDOS users are often "Charlie Poor-Boys" with not
enough extra money for such "luxury" equipment.   The best I can say
is that you should "test" UIDE on your systems using SSD disks.   If
they "respond" the same as normal hard-disks, including all PCI init
functions, UIDE should "pick them up" and run them O.K.

If not, only a minor loss, as SSD disks are so fast that they really
should not need caching.   You can then run UIDE with its /N1 switch
which causes it to ignore hard-disks but continue to cache diskettes
and CD/DVD drives.   They need caching, for they are otherwise SLOW!

Jack R. Ellis


--
RSA® Conference 2012
Save $700 by Nov 18
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDos4Kids (and Kids-at-heart)

[Jack]

>> On the topic of wear leveling I would go with the DOM products, as
>> they are designed as hard drive replacements.  It's pretty easy to
>> burn up FLASH so wear leveling is important.
>
> FWIW, they claim that FLASH has unlimited read capability, but is  
> limited in the number of writes.  So, at least theoretically,  
> wear-leveling should only come into play when writing to disk.  To  
> extend the life of the system, you should try to do as much as you can  
> in RAM (like using RAM disks for temporary files, etc.) and minimize  
> writes as much as possible.  This is true for "regular" hard drives as  
> well.

Absolutely UNBELIEVABLE to me that FLASH devices are used AT ALL in
hard-disk replacements!!   Last I knew, FLASH devices are writeable
only about 10,000 times.   That is a LOW number of writes for disks
if one considers DIRECTORY updates that any DOS system will do VERY
often!!   Even using an old "Write Back" (delayed-write) cache like
SMARTDRV, or Norton NCACHE2, I doubt that writes could be minimized
enough to make limited-life FLASH device "disks" worth their cost!!

If the DOM products have normal RAM chips (not FLASH types) and are
as "compatible" with IDE controllers as everyone seems to say, then
my next "hard disk" purchase shall be another actual HARD disk or a
DOM module if necessary, NOT any sort of FLASH type!   Allows me to
stay with UIDE, which may not use delayed-writes but takes only 944
bytes of upper/DOS memory [plus a bit of "invisible" HMA] and gives
me up to 4-GB caches!   Try to get even 1-GB using any "Write Back"
cache, and I have 5 words for you:  "Good LUCK -- You'll NEED IT"!!


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDos4Kids (and Kids-at-heart)

[Jack]

Mike,

> Most modern flash devices have cells that are writable at least 10
> times that - 100,000 cycles is the minimum you will find.   Better
> devices have even higher cycle counts.

Glad to hear, but I would still prefer a hard-disk whose lifetime is
measured in "years", not in "cycles".

> DOM products have FLASH in them - Nobody said anything about DRAM.
> If they had DRAM they would have to be continuously powered.

Sad how a simple "battery" is not included in such devices, so maybe
low-power DRAM could be used for faster writes and longer lifetimes.

> Products like Disk on Module that are designed as hard drive
> replacements usually have better wear leveling capability than
> standard USB "thumb drives", as the directory meta data update issue
> is well known.  SSDs take this to another level by "over provisioning"
> which means including more capacity than is advertised so that they
> will have enough spare capacity to make it to their rated lifetime.

I have never used any sort of "solid state" memory devices to replace
a hard disk, so the whole thought of "wear leveling" is a bit foreign
to me.   With hard disks, one just "uses them", with no need or worry
about such techniques, for their 3- or 5-year lifetime.Maybe hard
disks could last better, using a cache or other "access minimization"
schemes -- But knowing how manufacturers make such disks last EXACTLY
their "warranty period", I really doubt it!

> For applications where fast access is required nothing can beat a
> FLASH based device.  Part of the equation there involves unit life;
> if you use a FLASH based device in an environment with lots of writes
> then you expect to be replacing it on an accelerated schedule.  The
> write and read throughput is far above what a conventional spinning
> disk can provide, although the capacities are far smaller.

Shall stay with hard disks, then.   On my home "desktop" system, I am
NOT concerned about absolute speed (not with UIDE, anyway!) nor power
consumption, but I AM still "concerned" over all noted in this thread
re: FLASH-disk "cycle limits"!   For me, and I expect a LOT of others
like me, a "garden variety" $40 hard disk should do just fine WITHOUT
any such "concerns"!

Jack R. Ellis


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDos4Kids (and Kids-at-heart)

[Jack]

Eric,

>> Sad how a simple "battery" is not included in such devices, so maybe
>> low-power DRAM could be used for faster writes and longer lifetimes.
>
> Batteries are usually limited to high-end products ...

Get them down into LOW-end products, and I might be more interested!

> Hard disks also come in variants for 24/7 use and those for PC.

Nice to know, but may not be necessary.   My 2003-2006 Maxtor disk ran
exactly for its 3 years.   My 2006 Western Digital is now over 2 years
PAST warranty and giving absolutely NO ill effects, likely due to UIDE
that I did not HAVE till late 2006.   Not just UIDE, but your LBAcache
or ANY constantly-used disk caching program should help make "regular"
PC hard disks last a LOT longer!

>> But knowing how manufacturers make such disks last EXACTLY
>> their "warranty period", I really doubt it!
>
> I also doubt that they would last that long if HEAVILY used,
> maybe just okay for the manufacturers to replace those which
> are used more than predicted and thus break during warranty.

"We may never know", since even I did not realize how far beyond its
3-year warranty my W.D. disk drive is, till AFTER I wrote the above!
"Heavily used" may no-longer exist, if UIDE or LBAcache are present!

>> if you use a FLASH based device in an environment with lots of writes
>> then you expect to be replacing it on an accelerated schedule.
>
> The "lots" should probably be "LOTS" there: As mentioned earlier
> in this thread, SSD already ship with extra capacity. They keep
> track how often which area is used and just use fresh areas when
> they predict or sense some area to be over-used. Different from
> harddisks, over-used areas are not lost for reads but for writes
> so data is normally never lost, just the capacity decreases ...

Hard disks almost NEVER "lose" data, as their firmware does much
the same as you note above:  If a sector/track/whatever seems to
be getting unreliable, the disk assigns the area to an alternate
and copies its date there, while it still can!   Only if a hard-
disk runs OUT of alternate areas does it then start posting REAL
errors to us "outsiders"!

> Also, the sweet spot for SSD sizes, price wise, is 60 to 500 GB
> at the moment, much closer to 1 Euro per GB than to two ...

Last I heard, a Euro was about $1.33, meaning that a 120-GB hard
disk for only $40 (30 Euros) is far more of a bargain.   Each of
my "30 Euros" buys 4-GB of hard disk, not less than 1-GB of SSD!

>> NOT concerned about absolute speed (not with UIDE, anyway!)
>
> With the sizes of UIDE that you run, you could actually boot from
> DVD and then use a RAMDISK, which big UIDE caches are similar to.

I could, but I prefer a hard-disk that need not be copied up to a
RAMdisk each time I boot.   In fact, I do NOT run any "huge" UIDE
cache -- I actually run a special variant of UIDE2 using a 500-MB
cache, since my system has only 1-GB memory.With V6.22 MS-DOS
(19.5K of free HMA re: no FAT32, Win95/98 or long-filename Krud),
most of my driver and its search table for 500-MB "fits" into the
HMA, and I get a faster UIDE2-style driver for only my normal 944
bytes of upper-memory!

>> nor power consumption
>
> SSD are similar in power consumption to 2.5 inch harddisks ...

Nice to know, but does not matter for people like me, who have a
"desktop" system with a virtually "unlimited" 400W power-supply!

>> but I AM still "concerned" over all noted in this thread
>> re: FLASH-disk "cycle limits"!
>
> There seem to be some notorious SSD models which just break down
> completely, but as far as I could tell, none of those was due to
> exhausted flash write cycles. It rather seems to be weak firmware
> (we both know that firmware is no quality market today) ...

"Sucks!" is the "operative" word, there!

Re: the rest of your comments, I agree, SSD/FLASH/"whatever" hard
disk replacements have their advantages, but at present, the cost
of REGULAR hard disks makes SSDs a "niche" market only.   Perhaps
if SSD costs drop (a LOT!), and most such "reliability" issues go
away (COMPLETELY!), they may replace most traditional hard-disks.
But, Seagate "et al" keep making their drives cost less, too, and
so I expect to "live out MY life" [age 66 now] using a HARD disk!

Jack R. Ellis


--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS boot problem

[Jack]

Wayne,

> I just installed FreeDOS on a newly created FAT32 partition on my SATA
> HD.   The other partitions are in NTFS and running Windows/XP.   Since  
> FreeDOS doesn't see XP it didn't edit my boot.ini.  I have been trying
> to code it myself with such things as:
>  
> C:\FDOSBOOT.BIN="FreeDOS"
> D:\FDOSBOOT.BIN="FreeDOS"
> X:\FDOSBOOT.BIN="FreeDOS"
> multi(0)disk(0)rdisk(0)partition(1)\FDOSBOOT.BIN="FreeDOS"
> multi(0)disk(0)rdisk(0)partition(2)\FDOSBOOT.BIN="FreeDOS"
> multi(0)disk(0)rdisk(0)partition(3)\FDOSBOOT.BIN="FreeDOS"
>  
> without any luck ... I also tried to use partition logic to rewrite my
> MBR, but since it is a SATA drive, it is not supported.
>  
> Can anyone help either with code for boot.ini or with a tool that will  
> rewrite my mbr???   PLZ?

I am the author of the UIDE driver, which is now part of the FreeDOS
"base software" list (Thanks again, Jim Hall!).   I still use an old
V4.0 Windows/NT (1996) -- Saves me $250 every 6 months, and prevents
having to put-up with Gates & Co.'s latest collection of new "bugs"!

Win/NT loads itself using a "multi(0)..." statement in BOOT.INI with
a similar format as you show above.   Win/NT does this using its own
boot sector, that becomes the "master" boot sector for all hard-disk
"boots" (power-up, "pushbutton reboot", etc.).   As Win/NT installs,
it "discovers" that MS-DOS (mine is still V6.22 from 1991!) was also
present, so it copies the original DOS "boot" sector to a file named
BOOTSECT.DOS, which is the sector it loads when you select a line in
BOOT.INI that begins with "C:\" (i.e. you want to "boot" from DOS).

I have never used any later version of Windows, and so I do not know
if they allow MULTIPLE lines in BOOT.INI that do not begin with some
"multi(0)..." data, i.e. multiple choices for booting "DOS" systems.
If they do, "Fine and Dandy"!   If not, you may be STUCK with only a
single  C:\="FreeDOS"  statement in your BOOT.INI file!

You need to "examine" your Win/XP system to see if it does include a
BOOTSECT.DOS file.   To do this, you might need to reinstall MS-DOS,
then install Win/XP after that, since "my nose" is telling me Win/XP
may NOT create BOOTSECT.DOS if it finds no MS-DOS (and not FreeDOS!)
as it installs!   Gates & Co. are "famous" for such unfriendly items
in their software!   If you have no MS-DOS, try to find Wengier Wu's
V7.10 MS-DOS "boot" diskette files, on the Internet -- Many users in
China, and I, use Wengier's files, and they run O.K.   If installing
some variant of MS-DOS, followed by your Win/XP, does NOT give you a
BOOTSECT.DOS file, Gates & Co. have "gone over" to some other scheme
than what I have in Win/NT, and I cannot be of help you!

If Win/XP does in fact create a BOOTSECT.DOS when it finds a "legit"
copy of MS-DOS loaded first, you then need to copy the FreeDOS "boot
sector" (512 bytes only!) into BOOTSECT.DOS for Win/XP's "boot" use.
I use an old Norton DISKEDIT to "extract" the DOS boot sector -- You
may need some other "scheme" to write the DOS boot sector to a file,
then copy it over to BOOTSECT.DOS as above.

I would be EXTREMELY "cautious" about loading Win/XP first, and then
"cold loading" FreeDOS on top of it!   This may make FreeDOS overlay
the actual Win/XP "boot" sector -- NOT what you want!   But it seems
the REVERSE, installing FreeDOS followed by Win/XP, might cause THEM
to overlay the FreeDOS "boot" sector with THEIR "own"!   So you need
to have a "saved" copy of the FreeDOS "boot" sector, install Win/XP,
and then overwrite their BOOTSECT.DOS (if present!) with the "saved"
FreeDOS "boot"!

Complex, but it "Works for me!", and has for 15 years!   Gates & Co.
may not have designed a "general purpose" multi-boot for Windows/NT,
but with some "knowledge and research", any DOS can be made to work!

I hope this helps you!

Jack R. Ellis


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] FreeDOS Memory

[Jack]

>> 1. Would like to ask how much memory does FreeDOS support, e.g. 4 GiB?
>
> Yes you'll be limited to a maximum of 4GB if you have 4GB or more. In
> practice this maximum could be anywhere between 2GB and 4GB (usually
> 3.3GB or 3.5GB) due to PCI chipset device mapping into the top of memory.

On older or "uncomplicated" mainboards, PCI should not take that many
addresses.   And yes, no one ever vioced any "serious" interest about
more than 4-GB of memory, so Japheth and I never pursued it in HIMEMX
or XMGR.   Can be done, but it requires "strong" agreement on all the
conventions used for the two drivers to access over 4-GB of XMS.

>> 2. Does it faces 640 KiB limitation as MS-DOS, e.g. Do I have to "load
>> high" drivers to save on conventional memory?
>
> yes. To access beyond 640KB load a driver (XMGR, HIMEMX, whatever) to
> access extended memory (XMS).

In fact, one needs an XMS driver (XMGR, HIMEMX, MS-DOS HIMEM, etc.) and
an "upper-memory provider" driver (JEMM386, MS-DOS EMM386, etc.).   The
"combined" JEMMEX can also be used.   If one uses only "real mode", the
UMBPCI driver can enable "Shadow RAM" (BIOS usage) as upper-memory, and
XMGR can then "provide" that memory to DOS.   No need for "EMM" drivers
in that case, but note that UMBPCI may not run with all newer chipsets.

The main point is that an XMS driver by-itself does NOT "provide" upper
memory to the DOS system.   This is done by the "EMM" driver, or by the
specific UMBPCI/XMGR combination.   [If XMGR does not find "Shadow RAM"
enabled by UMBPCI, it works the same as HIMEMX/HIMEM and "waits" for an
"EMM" driver to enable conventional upper-memory].


--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] UIDE.SYS delays boot process in VirtualBox

[Jack]

>> Anybody has an idea how to solve this with free software? Would the  
>> eltorito.sys driver help?
>
> Wasn't the solution to enable IO APIC or something like that? So a
> different enabled chipset.
>
> ELTORITO.SYS can help, but only if you configure the VM to start with
> booting from CD, after which you boot from harddisk.

I have never used "El Torito" as I have no CD boot disks (only diskettes)
on my system, so I have no idea if "El Torito" helps or not.

> Loading UIDE at runtime instead of boottime is also possible, in some
> theoretical CDROM.BAT for example ...

Doubtful this would help at all, since UIDE is going to do exactly the
same checks of the PCI bus for CD/DVD drives, whenever it gets loaded.

> Alternatives are creating and using an ISO file:
> OMI.EXE D: C:\FDBOOTCD.ISO
>
> Or replacing the CD-driver by the closed-source generic OAKCDROM.SYS or
> VIDE-CDD.SYS drivers [http://www.opus.co.tt/dave/indexall.htm].

I do NOT recommend any of the older "generic" drivers, since none of them
have UltraDMA logic, and none use file/directory caching.   Omitting both
of these items will cause CD/DVD transfers to run 3 or 4 times slower!

Also, a "generic" driver normally uses only "Legacy IDE" device addresses
and cannot "see" a controller whose addresses might be assigned by PCI to
other values.   This is true for VIDE-CDD, OAKCDROM, my "old" XCDROM, and
about all other "generic" CD/DVD drivers.

Note also that GCDROM/XGCDROM (BAD "hacks" of XCDROM!) "claim" to support
other addresses, but in fact they have PROBLEMS!

> Jack's UIDE.SYS driver performs chipset initialisation which is
> apparently still implemented in a buggy way in the VirtualBox software.

No other way possible for UIDE!   CD/DVD drives are not part of the BIOS,
so UIDE must "detect" them by (A) finding all SATA/IDE controllers on the
PCI bus, then (B) examining each controller's device slots for "ATAPI CD"
drives.

If some of the VirtualBox "chipset" options exhibit LONG delays when UIDE
issues an "Identify ATAPI Device" command, VirtualBox needs to get FIXED!


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Re : Support for 4k byte sectors

[Jack]

For what it is worth, my "take" on 4K-byte (or other-than-512
byte) sectors for DOS systems is very-much the same as Eric's
and I shall "reply" to some comments from one of his posts --

> Also depending on your BIOS, you could have a limit of at
> most 2^28, 2^32 or 2^48 sectors per disk ...

Not a problem for a "driver", as drivers usually assume the
programs doing I-O will not try to access PAST the end of a
disk!   The disk directory controls how much data shall get
read/written, and the disk driver "takes its orders" from a
DOS system.

Absolute disk size is only a problem when specific HARDWARE
commands are needed with different sizes.   In the SATA/IDE
world, there is only 28-bit or 48-bit LBA addressing, and a
48-bit drive can accept 28-bit commands.   Thus, in my UIDE
driver, I issue 28-bit commands for up to 28-bit addresses,
while I issue 48-bitters for larger addresses.   Runs fine!

> ... There also is a DOS UIDE cache-and-driver.  For example
> LBACACHE is one of the tools which assumes 512 bytes/sector
> and uses only the first 2^32 sectors which is 2 TB for 512
> bytes/sector.

As noted above, UIDE (also UIDE2 and UIDEJR) handles 48-bit
"LBA" addressing, if any DOS system were ever to give it an
Int 13h AH=42h/43h "LBA" block with addresses so large.   I
depend on the DOS system to determine if this is necessary,
as UIDE does physical I-O only, not "logical" directory I-O
where the 32-bit directory limit is of concern.Only the
48-bit "LBA" address limit matters to me and my drivers.

> By the way - a DRIVER could interface with any disk with
> any sector size and then just provide an int13 or int25/26
> interface with 512 byte "sector" size for data transfer to
> DOS. For transfers which do not access (aligned) blocks of
> 4 kB size, performance will be worse than native, and you
> cannot boot from such a disk, but at least this would WORK
> and you could even have a driver as part of the boot chain
> before DOS is loaded, just as Ontrack / Ezdrive MBR-loaded
> drivers which added LBA support to PCs without a LBA BIOS,
> decades ago. Making the KERNEL sector size of DOS 4 kB has
> the side effect of BUFFERS also being 4 kB each - wasting
> 3.5 kB in each buffer when you access a 512 byte / sector
> disk with such a kernel.

I agree with much of the above.   Changing DOS, and all user
apps, for any "new" sector size at THIS late date would be a
"Cast-Iron BITCH", in my opinion!   [U.S. expression for BAD
wives/girlfriends, who are usually made of "softer" items!].

For the moment, UIDE supports only 512-byte sectors, same as
LBACACHE and almost every other DOS hard-disk driver.   But,
if "new" 4K-byte sector schemes provide a RELIABLE means for
a drive to tell its driver what sector size is in use, I can
change UIDE to detect that size!   Not-much help for booting
or with "independent" programs like FDISK, etc.But, Eric
is correct:  Changing only the DOS disk driver to accomodate
large sector sizes, then letting the driver "interface" with
the existing DOS system at 512 bytes/sector, would be a HUGE
"simplification" of this entire issue!


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Re : Support for 4k byte sectors

[Jack]

Eric,

>> ... I issue 28-bit commands for up to 28-bit addresses,
>> while I issue 48-bitters for larger addresses.   Runs
>> fine!
>
> I meant if the BIOS only sees the first 2^N sectors and
> the partition table describes more than that, UIDE will
> probably not modify the BIOS-reported disk size:  So on
> one side, UIDE could help DOS to access more of a disk
> than the BIOS, but on the other, that might be unsafe...

Once again, UIDE is written to be a "physical" disk driver.
It has absolutely NO logic that interrogates for drive size
during init, and it simply "takes orders" from DOS re: what
physical sectors it reads or writes.   Any idea that a disk
is limited to 128-GB, 2-TB, etc. is "unknown" to UIDE -- it
simply handles up to 8-GB using 24-bit "CHS" commands or up
to (8-GB * 8-GB) using 48-bit "LBA" commands.

My intent with UIDE was to write a driver at the "physical"
level, so it is NOT-at-all dependent on any DOS constraints
which may differ between MS-DOS, FreeDOS, DR-DOS, etc.   By
depending on only (A) Int 13h and (B) 48-bit LBA addresses,
and NOTHING else, UIDE is thus "DOS independent"!

> PS: LBACACHE does treat access beyond 2^32 sectors as a
> flush event and will not cache the additional sectors.
> Of course MBR based partitions cannot go > 2^32 either.

Why is a "flush" needed?   LBACACHE should work the same as
UIDE, i.e. it "takes orders" from the DOS system about what
sectors to read/write.If current 32-bit DOS directories
cannot store info about files past 2-TB, LBACACHE shouldn't
EVER get a read/write request for sectors above that limit,
unless the DOS system has CRASHED!

> PPS: What do you think about using Ontrack/Ezdrive style
> load-before-kernel drivers to map from 4k to 512 sectors?

No experience with such drivers.   OnTrack never worked for
me, same as it did not for many others.   I see 2 problems:
(A) It adds another level of software complexity which many
users will not understand, and (B) it might still require a
BIOS that handles 512-byte sectors, so the "special" driver
can be read initially!   Actually, I agree with other posts
in this thread that 512 byte sectors at-least for "booting"
shall be with us for a long time, so "special" drivers seem
to be unnecessary!   Let the 512-byte sectors handle "boot"
until UIDE/LBACACHE are loaded, then more-efficient 4K-byte
sectors (or whatever) can be supported using those drivers.


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Re : Support for 4k byte sectors

[Jack]

Re: 4K sector sizes, I realized today that UIDE, UIDE2,
and UIDEJR likely will NOT be affected at all --

1) DOS has a 64K-byte limit for read/write requests, in
fact 127 sectors of 512 bytes (the "UIDE" drivers do
accept 128).   Since 4K-byte sectors "fit" into this
limit, no physical-level driver changes are needed.

2) All 3 "UIDE" drivers do ONLY physical block I-O  and
"know nothing" about directories, file systems, etc.
The drivers remain "DOS independent", i.e. they just
read/write sectors "at the orders" of the DOS system
and user programs.   MUCH simpler and a LOT smaller!

3) UIDE/UIDE2 require, and UIDEJR can set, a 64K buffer
in XMS memory for "misaligned" or other I-O unsuited
to UltraDMA.   Since DOS cannot do more than 64K I-O
at a time, no change to the "UIDE" drivers' UltraDMA
buffering is needed.

4) UIDE/UIDE2 set cache blocks of varying sizes, 8K for
a 5-MB cache, up thru 64K for an 80-MB+ cache.   So,
the drivers have enough cache blocks in all cases to
be effective, in handling both directory sectors and
data files.   4K disk sectors "fit" evenly, into any
UIDE/UIDE2 cache-block size same as 512-byte sectors
do.   So UIDE/UIDE2 will need NO changes for caching
the larger disk sectors!

About all that MAY be needed in the 3 "UIDE" drivers is
some init logic to "select" using 4K-byte sectors, if a
hard-disk demands this (FOOLISH if so, in my opinion!).

Assuming "boot" or FDISK/FORMAT problems are dealt with
as required, my comment about 4K-byte sectors is "Bring
'em on"!   The 3 "UIDE" drivers will run fine with them
and so "regular" DOS I-O should not be any problem!

[In the U.S.A., we have an old engineering "joke" known
as the "K.I.S.S. Principle", whose letters denote "Keep
it SIMPLE, stupid!".   Less and less of a JOKE, as time
goes by and computers become unjustifiably COMPLEX!   I
and the "UIDE" drivers still OBEY the "KISS Principle",
insofar as is possible!].


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Re : Support for 4k byte sectors

[Jack]

To set the record straight on caches and on UIDE --

>> Can you recommend any free int 13 or block device based delayed/
>> pooled write caching software?   As far as I can remember, all
>> "modern" (LBA compatible, given disk sizes on current PCs)
>> implementations of this are commercial.
>
> I don't know of any, but there's definitely a need for one.  I normally  
> don't use caches at all, but when I need one it needs to be a  
> write-delay cache and I use MS SMARTDRV.  I actually don't like SMARTDRV  
> very much (it uses too much memory and requires a reboot to uninstall),  
> but I have it and it works OK.

I agree with the above -- "Write Back" (delayed-write) caches usually are
"commercial", as they require a LOT of work and must be sold for a price.
And I too absolutely HATED "SMARTDRV" -- Takes the most memory but caches
the LEAST amount of data for it!   I used Norton NCACHE2 for years, which
is also a "memory hog", but not as bad for the amount of data it handles.

> I don't find write-through caches like LBACACHE and UIDE to provide  
> enough speed benefit to be very helpful (though they might increase disk  
> life to some degree).  In addition, LBACACHE and UIDE are INT 13h caches  
> instead of INT 21h caches (like SMARTDRV is), so they don't work with  
> all disks (including USB and SCSI).  When I really need to increase disk  
> access speed (a big problem in some VM's), I copy my commonly-used  
> utilities and batch files to a RAM disk.

No "cache" will ever compete with a RAM disk.   RAM is always faster than
disks with their seek/rotational latencies and their much slower transfer
rates.   But I dispute your comment about "Write Through" caches offering
not-enough speed benefit, and I bet all "VERY happy!" users of UIDE might
argue with you, as well.

There is a REASON why "Write Back" caches are all so large -- they demand
MANY "hooks" of a non-generic type into a DOS system, to handle Ctrl/Alt/
DEL and other events that require a "flush" of sectors not-yet written to
disk.   UIDE only needs to "hook" the Int 13h vector to do its functions.
Also, UIDE is not just an Int 13h cache -- It CAN still be called by user
drivers which desire its caching, though I am sadly aware that no one has
ever done this.   DOS driver development, or enhancement, isn't done that
much any more.

I did everything possible to make UIDE a FAST "Write Through" cache.   It
integrates caching with UltraDMA I-O for disks/CDs/DVDs; it can do direct
UltraDMA to/from cache buffers to save time; it uses a binary-search when
looking for cached data blocks (NOT "hashing", which breaks-DOWN in speed
at about a 35%-40% full search table); and it is only 5.2K (UIDE) or 4.5K
(UIDE2) of assembly-language, as I REFUSE to have God-forsaken "C" in any
SYSTEM driver as important as UIDE is!!

But, if you wish to continue giving-up 40K+ for SMARTDRV, 80K+ for Norton
NCACHE2 or however-many K for other "Write Back" schemes, feel free to do
just that!   I and others will continue using the 944-byte UIDE/UIDE2 and
will be "VERY happy!" with the speed increase we DO get, from doing so!

[And if there are still those who do not understand how UIDE/UIDE2 manage
to require only 944 bytes of upper/DOS memory, just call it "Sorcery"!!].


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Re : Support for 4k byte sectors

[Jack]

> I knew this would provoke a comment from you, Jack.

Yes, you always were a "provoker", weren't you, Bret?

> The purpose of a cache is to put as much data in RAM as it can, so that  
> the disk is accessed as little as possible.  It's true that the cached  
> data does eventually get written to disk, and that part is slow.  From a  
> speed perspective, though, a well-designed cache can be competitive with  
> a RAM disk.

Exactly why I designed UIDE to have all the features I noted before, along
with using only 944 bytes of memory (and some HMA which nothing but MS-DOS
HIMEM ever used before) and using XMS for its cache tables and cache data.
Try to find any "Write Back" caches that do so much, for so little memory!

> The advantage of a write-delay cache is that that the writing can be  
> done when the system is "idle" (a simple form of multi-tasking).  The  
> end result is that even though disk writes actually take the same amount  
> of time they always did, the SYSTEM actually runs much faster.  In my  
> experience and opinion (and it is only an opinion), write-through caches  
> don't provide enough speed benefit to be very helpful, and I don't use  
> them.

Well, we remain on different sides of a fence!   I say "Write Through"
caches provide a LOT of benefit, especially UIDE which can cache up to
4-GB of data!   Assuming only 2.5 or 3-GB is assigned to UIDE, one can
have 500-MB+ for a nice RAM disk like my RDISK offers, and so one gets
"The best of both worlds":  A (big!) RAM disk for "fast" files, plus a
(big!) cache for "ordinary" disk files.   UIDE/RDISK handle GIGABYTES,
not KB or MB like too many other never-upgraded "RAM disk" and "Write-
Back" cache programs!   You can KEEP all those "old guys", and I shall
continue to do the BEST possible in UIDE/RDISK, for a LOT less memory!

>> There is a REASON why "Write Back" caches are all so large -- they
>> demand MANY "hooks" of a non-generic type into a DOS system ...
>
> Yes, write-delay caches are MUCH more complicated than write-through  
> caches.  But, they also provide MUCH more practical benefit, IMO ...

How I just DETEST "Internet" abbreviations, which are always such LAZY
and/or BAD English!   But "FYB", "IMO" it is rather IMPRACTICAL to use
so much system memory in SMARTDRV/NCACHE2/etc.   DOS is in fact memory
limited, and if I can have 90% the benefit of most "Write Back" caches
for 90% LESS memory by using UIDE, THAT seems a little more PRACTICAL!

> Even with that being said, I don't use SMARTDRV all the time.  I only
> use it in certain situations when it provides noticeable benefit, and
> in those particular situations a write-through cache doesn't help.

Why not just use UIDE all the time?   You would get UltraDMA I-O rather
than whatever your BIOS currently does, and I bet your NET system speed
would be greater, from having SOME type of cache "active" at all times!

> Also, FWIW, you can disable write-delay caching in SMARTDRV if you want,  
> in which case it works sort of like UIDE or LBACACHE (except that it  
> will also _natively_ work with non-INT 13h disks like USB and SCSI), but  
> at the expense of requiring more memory.

SCSI disks are rarely seen on PCs, due to their high disk and controller
cost.   USB disks are also rarely seen, since they are not-yet reliable,
nor in many cases are they fast-enough to replace hard disks.   SATA/IDE
"own" the hard-disk market and probably will for a LONG time.   So, I am
not-at-all "bothered" by UIDE handling only Int 13h disks, especially as
it still CAN be called by other drivers to cache THEIR disks, as well!


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] USB/ASPI to DOS, 4K sectors.

[Jack]

> Jack has his own private reasons for not being a fan of ASPI, thus his
> UIDE driver (PCI IDE/SATA storage and optical disk driver) doesn't
> implement nor hook into ASPI.   I'm not aware of opensource CD-writing
> software that doesn't require ASPI.

Not entirely true -- UIDE can call "Int 13h" drivers for all types of
hard-disks, and upon return from their drivers, UIDE will cache their
read/write data, as well.   If a SCSI disk has such a software driver
or even a BIOS chip on its interface card that handles Int 13h calls,
UIDE will "cache" such disks.

What UIDE will NOT permit is handling any BIOS units flagged as being
"removeable"!!   One CANNOT be certain all DOS variants will handle a
"media change" (new disk) within their Int 13h coding, which was done
at a time when Int 13h hard-disks really were "HARD"!   As I will NOT
have UIDE get "blamed" for an older DOS system failing to "flush" its
disk buffers on media-changes, UIDE will NOT handle "removeable" hard
disk drives!   That includes USB types!

My "private" reasons for not liking ASPI are many --

1) ASPI is too complex.  Whatever happened to a SIMPLE interface that
provides read/write and perhaps format commands only??   All other
functions are rarely used by disks and should be diagnostic-only.

2) ASPI is mainly for SCSI drives, which are expensive, same as their
$200+ controller cards.   You get IDE for nothing, last I heard.

3) In 1998, I came back to California to take a job at Adaptec, after
4 years in Utah, only to find that the man who would have been "my
boss" hadn't cleared my paperwork before offering me the job, i.e.
I had NO job!!   Absolutely UNETHICAL, and INEXCUSABLE, and I have
had nothing to say for that man, nor for Adaptec, from then on!

If the idea of doing drivers for USB is still "open", why NOT write a
simple Int 13h driver that handles disk reads/writes only, instead of
"obeying" the full SCSI/ASPI set of rules simply because they ARE the
so-called "rules"??

In 1980, an associate of mine "took one look" at a 750K video package
[done in "C" of course!], and he noted "They've got GUTS calling THAT
a 'driver'"!!   I have precisely the same feelings about a lot of the
software for using USB, thus far.

Something simpler/Better/SMALLER for USB disks and CDs/DVDs really is
NECESSARY, people!   Until we get it, I plan to avoid all USB devices
like the PLAGUE!


--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] UIDE Update Coming -- DISGUSTING Implications!!

[Jack]

A "Heads Up" (warning) message to all users of UIDE and UIDE2 --

Some time ago, I considered "Read-Ahead" for UIDE/UIDE2.   But effective
Read-Ahead requires knowing file sizes, to prevent reading too FAR ahead
and losing time!   File sizes demand DOS calls, and I want UIDE/UIDE2 to
remain "generic" (no DOS calls) and continue to use only Int 13h.

In any case, I did revise the drivers' "UdmaIO"/"DoDMA" routines, to put
more setup logic in "DoDMA" so it could be an "internal driver" for Read
Ahead.   This created a "bug"!   For disks, the "SetAdr" subroutine that
detects "64K UltraDMA boundary" crossings is now being called BEFORE the
"IOLen" byte count is set for requests!   "SetAdr" must know that count!
CD/DVD requests, and the non-caching UIDEJR driver, were not affected.

Easy to fix, simply re-arrange UIDE/UIDE2's logic to what it was before.

However, what this "bug" IMPLIES has left me rather DISGUSTED!

I shall NOT believe that all DOS kernels/programs do disk I-O using only
perfectly-aligned buffers with no "64K UltraDMA boundaries"!   Many such
kernels/programs were written BEFORE 1994, when UltraDMA was thought-up!
So, the only way recent UIDE/UIDE2 drivers could run O.K., without users
seeing a LOT of data errors, is that "64K UltraDMA boundaries" NO-LONGER
EXIST!   Newer DMA controller chips likely increment all 32 address bits
after DMA byte/word transfers, not just the LOWER 16 bits as in the 1994
Intel "Bus-Master" Specs.   That was what created such "64K boundaries"!

And NOBODY in Santa Clara, California nor in Redmond, Washington told ME
one word about all this, that UIDE need no-longer "worry" about UltraDMA
boundaries!   This despite comments about UIDE "showing up" all the time
on MSN and others of their "forums"!

So, pardon me, if I am really left DISMAYED and DISGUSTED by the current
"computer industry", that PROVES all-the-time how they only want DOS and
efforts like ours to just "go away"!   Small wonder, that my computer is
unchanged past 2006, and my software is unchanged past 1994 V6.22 MS-DOS
and 1998 V4.0 Windows/NT.I too can play their little "go away" game,
or as my late Mother might have said, "So SCREW them"!!!

I have the "bug" fixed in my personal drivers, and I shall soon issue an
updated DRIVERS.ZIP file through Johnson Lam's website, when he recovers
 from another type of "bug" called the FLU!

--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] New UIDE Available -- "64K Boundaries" Fixed.

[Jack]

Johnson Lam has posted a new DRIVERS.ZIP dated 24-Feb-2012 on
his website at .

In it, UIDE and UIDE2 are corrected so that they again handle
"64K UltraDMA boundaries" properly.   A user I-O buffer which
crosses-over a 64K address boundary will cause the drivers to
move output data to, or input data from, their own XMS buffer
which is aligned with NO boundary and will handle actual I-O.

Like I wrote before on this forum, note that I "suspect" this
problem may affect only "old" year-2000 and earlier chipsets,
since the previous UIDE/UIDE2 have not given any "big number"
of data errors for users!   But I want the UIDE drivers to be
compatible with ALL UltraDMA controllers, so they are fixed!

Also, UIDE/UIDEJR are a bit smaller and UIDE2 is MUCH smaller
due to my "experiments" in writing a 7K-byte version of UIDE2
for my "backup/restore" diskettes.   My run-time driver logic
is "good", but my driver initialization logic is often "quick
and dirty" since it disappears after the driver loads!   That
has now been remedied, very much so in UIDE2!

A minor error -- I "date stamped" XMGR/UIDEJR in the files on
Johnson's website to 2-24-2011, not 2012!A "typing error"
by me, which Johnson shall correct.   XMGR/UIDEJR do show the
year "2012" in their title messages, and they do work fine!


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] New UIDE -- Website Correction!

[Jack]

In my previous post about the new 24-Feb-2012 UIDE/UIDE2
drivers, I mistyped Johnson Lam's URL with an extra "s"!
The correct URL for the new drivers is --



My apologies -- "Age 66 is SO much fun!" as I often say!


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Problem after updating to FreeDOS 1.1 with writing of environment variables.

[Jack]

Mark,

> Yep, just tried Rdisk and it works as expected (when loaded from
> Autoexec.bat), I can assign a known drive letter and then not have
> to "faff around" trying to locate the ramdisk using findtdsk.exe.
>
> I don't think rdisk was around in 2003 when we set up our stuff
> originally, which I why we went tdsk route.

I am the author of RDISK, also UIDE and XMGR.   Glad you like RDISK,
which I wrote in 2009 in response to Johnson Lam (my "partner" in my
DOS activities), who noted HE "did not like" any of the available
RAM disk drivers, either.   So I did a "simpler" driver for him, and
that is how RDISK came to be!

> Interestingly thou, Rdisk suffered the same problem, that tdsk had,
> in that we stored the ramdrive disk letter in an environment variable
> %RAMDRIVE% and our watcom app used a GetVar to retrieve it ...

Not sure if this is a "driver" problem.   If you wish, send me an
E-Mail in private with more detail, and if RDISK can be improved,
I shall do so.

> One last question, all these memory managers and such, is there a
> recommended set for a modern PC?

I definitely recommend either JEMMEX (as you are using) or JEMM386
with a good XMS manager, either HIMEMX or my own XMGR.   The other
"EMM" drivers are all NOT under current maintenance, and many have
never-fixed bugs!!   Japheth works hard to keep his "JEMM" drivers
current and bug-free, so they are the ones to use.

JEMMEX alone should work fine for most people.   If you don't need
any protected-mode features nor any "extra" upper-memory (B000h to
B7FFh, i.e. the old "monochrome video" area) that must be "mapped"
by an EMM driver, you can first run UMBPCI, then load my own XMGR.
XMGR can "read" the UMBPCI memory blocks and load itself directly
into upper-memory.   XMGR also has "I-O Catcher" logic to "catch"
and execute diskette I-O (also hard disk I-O until UIDE loads) in
upper-memory, since UMBPCI's "Shadow RAM" upper memory will not do
any DMA!   "Serious" game fanatics prefer UMBPCI/XMGR, as they are
slightly faster from not using protected-mode, and many DOS games
are written for real-mode speed.   Except for JEMMEX by itself, or
UMBPCI + XMGR, other memory-manager drivers are usually unneeded.

> At the moment, my fdconfig.sys looks like:
>
> DEVICE=A:\JEMMEX.EXE
> SHELL=A:\COMMAND.COM A:\ /E:512 /P
> DOS=HIGH,UMB
> DOSDATA=UMB
> FILES=20
> BUFFERS=20
> LASTDRIVE=Z
> DEVICEHIGH=A:\UIDE.SYS /S40 /D:CDROM1
>
> and the start of my Autoexec.bat looks like:
>
> LH A:\RDISK.COM /S50 /:Y
> A:\FREEDOS\SHSUCDX /QQ /D:CDROM1,Z
>
> Any pointers or help optimizing it further would be appreciated.

Looks good to me!   My only comment is that if you always use the
FreeDOS system, you may want to delay loading UIDE until AUTOEXEC
runs, in which case you will have to load UIDE with --

   DEVLOAD /H A:\UIDE.SYS /S40 /D:CDROM1 /H

DEVLOAD, maintained by Eric Auer, can load .SYS drivers during the
AUTOEXEC.BAT file (normally, they load during CONFIG.SYS).   In my
example line, the first /H tells DEVLOAD to load UIDE "high", i.e.
in upper-memory, and the second /H tells UIDE to use free HMA space
for most of its driver logic.   That will save you about 4300 bytes
of upper-memory.   FreeDOS does not make HMA available for drivers
until AUTOEXEC runs, thus the reason for "delaying" UIDE's loading.

You may also want to give UIDE more than just 40-MB of XMS for its
cache.   The "rule" I recommend, where possible, is to allocate 3
times the size of your largest cached file, i.e. if your system may
have to handle up to 100-MB files, then a 300-MB cache works fine:
100-MB to cache the "input" file, 100-MB to cache its "output" copy
during file copies, and 100-MB for directories or other files to be
SAVED while a big file-copy is going on!   If 300-MB is too much or
if your largest file is used only "occasionally", make the cache 3
times the size of your largest "most used" file.   This scheme will
avoid UIDE having to discard directories, to make space for a large
"new" file in its cache, which slows it down a bit when those disk
directories ultimately need to be re-read!

Finally, unless your WATCOM application requires them, you may want
to use BUFFERS=4, or at most BUFFERS=10, in your CONFIG.SYS file.
WIth UIDE present, there is no further need for a large number of
DOS buffers.   UIDE does a much better caching job than the old DOS
buffers, and by reducing your buffer count, you may save enough HMA
space to put UIDE "up there" in the HMA, as well!

Best wishes,

Jack R. Ellis


--
Virtualization & Cloud Management Using Capacity Pla

Re: [Freedos-user] Problem after updating to FreeDOS 1.1 with writing of environment variables.

[Jack]

Mark,

> Thanks, after using all the excellent advice so far, I am **ALMOST** back
> up and running, the environment variable problem has been worked around,
> and I have taken onboard the memory saving advice (have about 470k of
> conventional memory, which should be ample, how much did billyboy say we
> wouln't need anything more than?).
>
> Problem is, now the ghost process is crashing with a read error from the
> DVD, which I know don't contain any errors.   Could this be related to me
> using UIDE.SYS rather than our previous driver (oakcdrom.sys)?  Is there
> anything I should be aware of?  Or any way to help diagnose the error?
>
> My config and autoexec now look like:
>
> Config:
>
> DEVICE=A:\JEMMEX.EXE
> SHELL=A:\COMMAND.COM A:\ /E:512 /P
> DOS=HIGH,UMB
> DOSDATA=UMB
> FILES=20
> BUFFERS=4
> LASTDRIVE=Z
>
>
> Autoexec:
>
> DEVLOAD /H A:\UIDE.SYS /S511 /D:CDROM1 /H
> LH A:\RDISK.COM /S10 /:Y
> A:\FREEDOS\SHSUCDX /QQ /D:CDROM1,Z

I agree with Bernd Blaauw's comments today, that perhaps a "basic" UIDE
will help you resolve your "Ghost" problems.   In general, you may want
to go back to your "original" CONFIG/AUTOEXEC files, then put in all of
our "advice" one line at a time.   This may help to positively find the
problem.

I have never worked with "Ghost", but if it is an "old" DOS program, it
may be dependent on exactly WHICH areas of XMS memory are in-use and so
available for it.   There are two more UIDE switches you can "test", to
see if this is so:  /R15 and /R63.They "reserve" 15-MB and 63-MB of
XMS memory.This will make UIDE load itself after the first 16-MB or
64-MB of memory (the first 1+ MB is the DOS system plus its HMA space).
Certain "Sound Blaster" cards did only 24-bit DMA and so cannot use any
memory beyond 16-MB.   Certain other "game" programs were NEVER updated
to the V3.0 XMS Specification (up to 4-GB of memory) and still use only
V2.0 XMS logic (64-MB maximum).   So, UIDE's /R15 and /R63 switches are
intended to "accomodate" such ancient hardware/software!

If a line-by-line "re-update" of your CONFIG.SYS and AUTOEXEC.BAT fails
to determine the "Ghost" problem, do try UIDE with /R15 and /R63 as the
last resort.   Worth a try!

Also, I do not completely agree with Bernd about problems caused by the
use of "UMBs" (upper-memory blocks).   There are a few drivers not able
to "detect" various parts of upper-memory:  JEMM386/JEMMEX still do the
"old" Microsoft tests for compatibility (newer "odd peripherals" memory
sometimes confuses them), and a few of the newer chipsets might not-yet
be supported by UMBPCI.   But, once "detected" and put into use through
JEMM386/JEMMEX/UMBPCI, upper memory should NOT be your problem.

> I have a small update on my original email (I haven't had a chance to
> try the items below).  When I run Ghost, the CD drive is listed twice,
> once via it's drive letter and once via it's ATAPI direct access.
> Access via drive letter fails repeatably.   Access directly works.
> I don't know if that sheds any light on things.

This late E-Mail MAY be telling me there is a "driver CONFLICT" between
UIDE and whatever "Ghost" I-O logic may be present.   If so, you should
try UIDE with its /N2 switch, which asks UIDE not to run CD/DVD drives.
If this eliminates your "Ghost" problem, then (A) you need to disable
the "Ghost" I-O logic and run your CD/DVD drives only through UIDE, or
(B) vice-versa, i.e. you must load UIDE with /N2 to avoid your "Ghost"
errors.   NOT any "fun", either way, I know!   But, I have never used
"Ghost" and do not know what its writers do in running CD/DVD drives!

Best wishes,

Jack R. Ellis


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] New 7-Mar-2012 UIDE, Etc. -- UIDE2 Under 7K!

[Jack]

Johnson Lam has posted a new 7-Mar-2012 DRIVERS.ZIP
file with a much smaller UIDE2, on his website at:



The UIDE2 driver, for faster speed with a protected
mode system (JEMM386/JEMMEX etc.), is now less than
7K bytes in size!   To achieve this, I needed to do
two changes in UIDE2 -- (A) It will now run 30 BIOS
disks/diskettes rather than 34, and (B) it will not
handle the /N3 "No XMS memory" switch.   Otherwise,
UIDE2 is the same as before.

Few PC systems have 30 BIOS units; most DOS systems
allow drive letters A: to Z: and so can handle only
26 units!   Also, Bernd Blaauw recently asked which
driver, UIDE or UIDE2, he should use in his FreeDOS
"autoloader" scripts.   I answered "UIDE", as it is
more versatile, will handle up to a 4-GB cache, and
will always have /N3 for FreeDOS support.   So, the
two new changes in UIDE2 should not affect anyone.

Only slight changes to UIDE (assembled via the same
source file as UIDE2) and no changes to XMGR/RDISK.
UIDE2 should help "boot" diskettes users and others
whose systems need to save file space.   Also, I am
again back to only a single UIDE.ASM source file --
My own "XIDE" driver (based upon UIDE2) is now GONE
and all of its features have been "folded into" the
new UIDE2!


--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] New 7-Mar-2012 UIDE, Etc. -- UIDE2 Under 7K!

[Jack]

> I don't know, how for the others - but for me no UIDE* driver works
> together with JEMMEX 5.75 (it breaks immediately at the very start).
> Not sure, should it work with XMGR - it won't break, but "mem /c/p"
> reveals nothing with name UIDE* in memory.

Can you be more specific about how the driver "breaks"??   Does it
display its "title" message and controller/device data, or does it
simply crash??   Let me know.

Jack R. Ellis





--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] New 7-Mar-2012 UIDE, Etc. -- UIDE2 Under 7K!

[Jack]

Zbigniew,

For your info, I tested the latest 7-Mar-UIDE2 with the latest
V5.75 JEMMEX on "my own" V6.22 MS-DOS, on V7.10 MS-DOS, and on
FreeDOS.   The latter 2 tests were done using the systems from
Lucho's 2008 "boot" diskette.Every system on that diskette
runs with an "old" 4DOS, and the FreeDOS kernel Lucho used was
2035, the latest available back in 2008.

I had absolutely NO problems on my system.JEMMEX was using
"I=B000-B7FF I=Test X=TEST", and it ran fine.My system has
an old AMD3000+ (socket 754!), with a 5-year-old BIOSTAR main-
board and 1-GB of RAM.   Has run perfectly for 5 years.

I must conclude that the problems you are seeing, using JEMMEX
and UIDE2, are NOT caused by those drivers.

Jack R. Ellis


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

> Problem (seems to be) solved.   Formerly I was using a line:
>
> INSTALLHIGH=C:\FDOS\BIN\UIDE2.SYS
>
> ...and this gave problems.   When I replaced INSTALLHIGH with
> DEVICEHIGH -- there are no problems anymore.
>
> I thought, that INSTALL and DEVICE keywords are synonyms for
> fdconfig.sys file, since I was very long time using various
> combinations, like e.g.:
>
> DEVICE=C:\FDOS\BIN\JEMMEX.EXE (DEVICE for EXE-file)
> INSTALLHIGH=C:\FDOS\BIN\XMGR.SYS (INSTALL for SYS-file)
>
> ...and it "just works" with no problems whatsoever - unfortunately,
> not in UIDE*-s case.   But now I see, there must be some difference
> indeed., and for *.SYS files should be DEVICE, and for COM/EXE -
> INSTALL.   The opposite can work, but doesn't have to.

I had a LONG set of comments for you, but I will save them.   The
"DEVICE" command requires a .SYS file, but can be used for a file
with a .SYS "header" at its start, e.g. RDISK.COM and JEMMEX.EXE.
As far as I know, the "INSTALL" command is absolutely NOT for any
"pure" .SYS files!   If you want to load a .SYS file after CONFIG
has been run, use a DEVLOAD command in your AUTOEXEC.BAT file.

UIDE/UIDE2/UIDEJR are .SYS files, and always will be, as the need
for loading them later by DEVLOAD seems to be limited to FreeDOS,
that does not provide HMA space for drivers before CONFIG.SYS has
been run.   Other DOS systems DO make HMA available during CONFIG
and so I see no-big-need for the UIDE drivers to load later or be
unloaded, despite the many "unload" FREAKS in this world!They
are hard SYSTEM drivers -- Why, after using UltraDMA and caching,
would anyone ever WANT to "unload" such a driver??!!


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

Zbigniew,

>> Why, after using UltraDMA and caching,
>> would anyone ever WANT to "unload" such a driver??!!
>
> Well, yes, this is the question.

Do tell THAT to all the "unloadable driver" FREAKS, who
have "beset me" in past years about making UIDE unload!

I am glad that you are "on the air" (running O.K.) with
the UIDE drivers!   You can decide if your system works
best using UIDE (goes up to 4-GB caches) or using UIDE2
(about 5% faster with protected-mode).   In either case
do try loading them in AUTOEXEC.BAT with --

   DEVLOAD /H C:\...\UIDE2.SYS /S511 /H /D:CDROM1

Using DEVLOAD permits the driver to keep only 928 bytes
of data, entry/exit routines and stack in upper-memory.
All else, including UIDE2's binary-search table, can be
moved into unused HMA space and run from there.As I
noted before, the FreeDOS kernel doesn't make HMA space
available to drivers until AUTOEXEC is run, so you must
use a DEVLOAD command in AUTOEXEC, if you want UIDE2 to
run with FreeDOS from the HMA.   Then, you will be able
to "amaze" friends with your only 928-byte disk/CD/DVD/
caching driver -- Just tell them you know a "Sorcerer"!

Best wishes,

Jack R. Ellis


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

Zbigniew,

Forgot to mention in my last post that if you do run
UIDE2 in HMA space with /H, you must limit the cache
to about 325-MB, and with /HL to about 420-MB, since
FreeDOS does not have as much "free HMA" as my V6.22
MS-DOS does.   Unlike V7.10+ MS-DOS, "old" V6.22 has
no FAT32 nor "long filename" logic limiting its HMA!

The UIDE driver has no such HMA limits, as it places
its binary-search table in XMS memory.

Jack R. Ellis


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

Zbigniew,

> But personally I can't see a reason to dispose of such "low footprint"
> driver "on the fly"; that's why I wrote "this is the question".

Understood, and I do agree with you!   XMS and HMA usage were both
suggested to me by Tom Ehlert in 2003, when I wrote my first UDMA.

> Yes, I'm going to use UIDE2 rather than LBACACHE exactly because it
> takes less memory. BTW: there are many (of course, it's very good to
> have a choice :) drivers for similar purposes available for FreeDOS
> now;  it would be useful, if the creators made one day some kind of
> comparison table, which one of them can do better for in which
> situations. E.g. JEMMEX - or HIMEMX/JEMM386? If the latter - when?

Now that JEMMEX is available, HIMEMX + JEMM386 and XMGR + JEMM386 are
"historical curios" only, and JEMMEX should be preferred.   As to the
caching drivers, LBAcache may still be a hair faster than even UIDE2,
since LBAcache has all its tables in "real" memory, while UIDE2 still
has its main cache-data table in XMS (LBA address, unit number, block
count for each cache block).   LBAcache and UIDE/UIDE2 all use "Write
Through" caching (no "delayed" writes) and thus are small.   A "Write
Back" cache such as SMARTDRV or Norton NCACHE2, does do writes with a
delay, so that if the same block is written 2 or 3 times in sequence,
as with compilers and data-bases, the cache saves time by writing the
"last" data over a 0.5 to 1-second time frame to the disk.   They are
FAR more complicated, as they need "hooks" on more of the DOS system!

For most of us, I feel UIDE with its 1400 bytes of extra logic beyond
the actual "driver", 800 for UIDE2, is a more reasonable caching idea
and provides fully-adequate speed, especially as both can do UltraDMA
directly to/from the actual XMS cache buffers!   That saves time that
a "Write Back" cache, with separate drivers, might not be able to do!

>> Just tell them you know a "Sorcerer"!
>
> "Wizard" is a better fit ;) - "Sorcerer" means the evil kind.

Not always:  King Arthur's "Merlin the Magician" is usually portrayed
as a "Good Guy", and it is him I usually have in mind.   If I want to
be seen as a bit more "evil", I say "Witch Doctor" or "Hoodoo Man"!!

Best wishes,

Jack R. Ellis


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

Zbigniew,

>> Now that JEMMEX is available, HIMEMX + JEMM386 and XMGR + JEMM386 are
>> "historical curios" only, and JEMMEX should be preferred.
>
> That was my guess: "maybe some of them can be even seen as 'obsolete'
> by now".

All still work O.K., however JEMMEX saves all possible 640K memory for
use by DOS programs.

I have saved XMGR for "real mode" users who run UMBBCI first, followed
by XMGR.   In that case, XMGR is able to "read" UMBPCI's table of UMBs
and can load there directly, which also uses 0 low-memory like JEMMEX.
UMBPCI cannot "map" the B000h-B7FFh space ("black and white" graphics,
that no one uses any more) into upper-memory.   But DOS games players,
and others who want real-mode speed (like me!), normally get over 128K
upper-memory, which is O.K. for our needs.So, UMBPCI + XMGR is the
only useful "old" configuration -- Most users should run JEMMEX alone.

> Actually, it was a bit surprising to me, that I still need a software
> cache, while using hardware, which - like for DOS requirements - is
> really very fast. Unfortunately, using no caching at all, I noticed
> pauses (3-4 seconds), that occur although not to often, but frequently
> enough to be irritating (the controller's LED is on at that time).
> Well, perhaps the NVIDIA SATA isn't the best fit for DOS.

Not NVIDIA's or other chip makers' problem.   Memory speeds continue to
"Reach for the MOON!", while the actual bit-rate coming from a disk has
remained much more constant at about 33-MB/sec.   Higher transfer rates
like 3-GB and 6-GB simply permit much-faster "burst rates" from a disk,
but sooner-or-later one must actually READ data from it, and it is that
reading that remains slow.

DOS also retains its single-sector directory handling, designed back in
the early 1980s, when memory was EXPENSIVE and buffers were kept small.
Even with BUFFERS=nn in CONFIG.SYS, DOS still writes directory sectors,
then could re-read that sector again, like when deleting multiple files
 from one directory.   With UIDE/UIDE2, most reads come from XMS memory,
and writes of the SAME sector usually only "update" the write caches in
modern hard-disks, so that deleting 1000 files from a disk "appears" to
take little-more time than deleting 10 files!   Not-much I can do for a
big file-copy, as the data must be moved "sometime", but for repetitive
directory-sector operations, UIDE and disk write-caches do help, a LOT!

>> For most of us, I feel UIDE with its 1400 bytes of extra logic beyond
>> the actual "driver", 800 for UIDE2, is a more reasonable caching idea
>> and provides fully-adequate speed, especially as both can do UltraDMA
>> directly to/from the actual XMS cache buffers!   That saves time that
>> a "Write Back" cache, with separate drivers, might not be able to do!
>
> I agree, thanks for providing such nice thing. :)

My Thanks, and my apologies to all that this 66-year-old "Dodo Bird" was
not able to "think up" such an idea before about 2008!!

>>>> Just tell them you know a "Sorcerer"!
>
> ... In conclusion: "wizard" writes extraordinary drivers - "sorcerer"
> creates e.g. very interesting... viruses. ;)

Since I am not from Russia nor from India, please do NOT "associate" me
with viruses!   Anyway, many Thanks for your "extraordinary" word!

>> Forgot to mention in my last post that if you do run
>> UIDE2 in HMA space with /H, you must limit the cache [..]
>
> Thanks, I think, that it could be worthy to add this comment to
> UIDE's readme.txt.

I keep my README.TXT file small, as Johnson Lam must have it translated
into Chinese for many of his users in Hong Kong and mainland China.   I
do have all comments about UIDE2 at the start of the UIDE.ASM source.

Best wishes,

Jack R. Ellis


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

>> Actually, it was a bit surprising to me that I still need a software
>> cache ... Well, perhaps the NVIDIA SATA isn't the best fit for DOS.
>
> DOS doesn't use SATA anyways (AFAIK), only IDE compatibility mode.
> It would be even slower without UDMA or a software cache.   As to
> why you need it, it's because (quoting Martin Reiser) "Software
> gets slower faster than hardware gets faster".   Also known as
> "What Intel giveth, Microsoft taketh away."

Intel "giveth" NOTHING, and followeth only "All we want is MONEY!",
same as Gates & Co.!   In my opinion, absolutely NO excuse for AHCI
that a better-written Windows driver could NOT have solved, but for
Intel as-always wanting to sell-Sell-SELL new chips!   Back in 2008
I asked Lucho how my (then) relatively-new UIDE driver "fared" v.s.
Windows, as he ran both DOS and Win/XP, and Lucho replied "You beat
THEM 2 months AGO"!!   At-least Intel does not "sucketh" like Gates
Co. does!!

Re: SATA, it does not offer an "IDE compatibility" mode, as it uses
all the same commands as IDE.   Only its drive cables are different
and NOT its "software interface"!   AHCI is the one using a totally
DIFFERENT command protocol, so it does need and have an "IDE compa-
tibility" mode on most mainboards and in most BIOS routines.

As I have noted, (A) AHCI is USELESS for DOS, as DOS does "One at a
time" I-O and cannot make use of AHCI's much-touted "Native command
queuing", and (B) AHCI is RIDICULOUSLY complex, the obvious results
of it being designed by a [MISERABLE!] "ANSI committee" which tried
to satisfy EVERYBODY and in the end satisfied NOBODY, as-usual!   I
have REFUSED to implement actual AHCI in UIDE/UIDE2, and I shall do
so for as long as "IDE compatibility" mode exists -- I have NO wish
to double my drivers' I-O logic and so reduce their cache capacity,
"Por NADA!" [for NOTHING], since DOS can never use AHCI queuing!

> But actually even DOS software gets slower and bloatier over time. I
> hate to bring up DJGPP, one of my favorite things, but take a look at
> CC1.EXE (C compiler proper) over the years, quite a difference!!! And
> don't forget the differences in x86 families (and software
> optimizations) and L1/L2/L3 cache sizes (among a billion other
> things). It all heavily varies (and GCC has both pros and cons).

Hardware improvements like those you mention will never "hurt" any
existing software, only make it faster.   As for poor-old "C" com-
pilers, which ALSO try to satisfy everybody and end-up satisfying
NOBODY, maybe you can understand why I prefer assembly-language!
No "constraints" on what code you generate, except your own!!


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

>> I have saved XMGR for "real mode" users who run UMBBCI first, followed
>> by XMGR.   In that case, XMGR is able to "read" UMBPCI's table of UMBs
>> and can load there directly, which also uses 0 low-memory like JEMMEX.
>> ...
>
> Unless you need EMS, you don't truly need JEMMEX itself ...

JEMMEX/JEMM386 also allow VCPI/DPMI to be used, they allow "mapping" of
upper-memory addresses into UMBs that UMBPCI cannot do (e.g. B000-B7FF)
and they can be the "one provider" of upper-memory required by FreeDOS,
which does NOT add-up the memory found by both UMBPCI and HIMEMX/JEMMEX
(MS-DOS V6.22 and V7.10 WILL do this).   Many other reasons, I am sure,
for using JEMMEX/JEMM386.

> ... Last I checked, I don't think it would let you run XMS only unless
> you did "NOEMS", and even that still left you in V86 mode ...

ANY usage of JEMMEX/JEMM386 is GOING to "leave you in V86 mode", since
by definition THAT is the "protected mode" used by any "EMM" driver to
protect the system from errant DOS programs!   Actual "protected mode"
is much less restricted, and that is NOT what an "EMM" driver uses nor
what Intel INTENDED them to use when handling 16-bit DOS applications!
In 16-bit "real mode" i.e. true DOS, you can "play whatever games" you
like.In 32-bit "protected mode", you can "play games" only in YOUR
program areas.   In "V86 mode" as when an "EMM" driver runs an old DOS
program, you will "TRAP" real QUICK to the "EMM" driver" on almost ALL
instruction sequences EXCEPT commands "legitimate" for up to an 80386+
CPU to execute "on its own"!

As for your "NOEMS" comment, I cannot be certain, but I think you need
to CHECK THIS, once again!

> Nowadays, it does seem most DOS software is either real-mode or 32-bit
> DPMI, though some XMS creeps in too ...

Use of XMS is irrelevant, 32-bit DPMI is also irrelevant.   WHO CARES,
since using or not-using an "EMM" driver in fact gives you exactly TWO
choices for running a DOS system:  16-bit "real mode", or "V86" mode!!

>> DOS also retains its single-sector directory handling, designed back in
>> the early 1980s, when memory was EXPENSIVE and buffers were kept
>> small.
>
> Two of the biggest hurdles to using DOS software often seem to be
> memory management and file system quirks. I know there are other minor
> things too, but those are the ones that seem to come up a lot. But
> with DPMI and FAT32, that's fairly moot, thankfully.

How do either DPMI or FAT32 "affect" single-sector directory handling
by DOS??   Do they "magically" RE-program DOS to handle more than ONE
directory sector at a time??   I think NOT!!   Until someone DOES so,
DOS directory handling will still use SLOW "1981 style" single-sector
I-O, and only a cache like LBAcache or UIDE/UIDE2 will help!


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

>> DOS doesn't use SATA anyways (AFAIK), only IDE compatibility mode.
>
> It's still much faster than the hardware, that I was using in
> 1991.   The HDD itself has quite large hardware cache (16 MB -
> incredibly large space compared to 640 KB).

Hard-disks have come a long way.   In 1994, I paid $350 for a 350-MB
hard disk that as I recall had NO write cache.   Now, under $100 can
get me about 250-GIGABYTES with at-least a 16-MB write cache!   Most
"IDE commands" used in 1994 can still be used, only a few were added
since then to support 48-bit LBA addressing (not 28-bit, like then).

>> But actually even DOS software gets slower and bloatier over time.
>
> Maybe I wasn't clear enough in my writing: that pauses occur, for
> example, even when I've got to save just edited autoexec.bat - then
> we're talking about 2 KB (or so) text file.   Not sure but my guess
> is "hardware problem".

Maybe not:  I still use a 1986 "WordStar" editor, the only one I ever
had "time to learn" well.   It is VERY slow at the end of an edit, my
guess being that only THEN does it "rename" my previous file with the
.BAK suffix, then finishes output of my NEW file, then it deletes all
its "temporary" files!   Perhaps your editor does a LOT of such work,
whenever you finally "output" a new edited file.


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

> I noticed that pauses while using "edit" shipped with FreeDOS
> - can it really be that slow when saving edited file?

Try using "EDIT" shipped with V6.22 or V7.10 MS-DOS, which I
find is "not too bad"!


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

> Unless you need EMS, you don't truly need JEMMEX itself.  Last
> I checked, I don't think it would let you run XMS only unless
> you did "NOEMS", and even that still left you in V86 mode.

To test this, I change the first few lines of my CONFIG.SYS file
which are --

   DEVICE=C:\BIN\UMBPCI.SYS
   DEVICE=C:\BIN\XMGR.SYS /W
   DOS=HIGH,UMB
   REM DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF X=C800-EFFF NOEMS

Normally, I "remark out" (REM) JEMM386 and use it only for UIDE/
UIDE2 testing.   After editing, my CONFIG.SYS file began with --

   DEVICE=C:\BIN\XMGR.SYS /B
   DOS=HIGH,UMB
   DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF I=CC00-DFFF
   DEVICEHIGH=C:\BIN\XMGR.SYS

XMGR loads first in /B "boot" mode, then after JEMM386 enables
upper-memory, XMGR loads again and "moves" to upper-memory, as
was my original "scheme" for it to save 640K DOS memory.   The
JEMM386 driver is told to "map" the B000-B7FF monochrome video
area and from CC00-DFFF as upper-memory.   My video BIOS takes
up to CBxx, and I wanted to avoid E000 up so JEMM386 could use
it as an "EMS page frame".

Did not try this on FreeDOS, but on my "old" V6.22 MS-DOS, the
edited CONFIG.SYS file "booted" with NO "gripes or groans"!!

Rugxulo, I REALLY think you should check AGAIN running JEMM386
without "NOEMS" -- worked fine for me!


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

>> Rugxulo, I REALLY think you should check AGAIN running JEMM386
>> without "NOEMS" -- worked fine for me!
>
> In the past I always had EMM386 enabled, and it worked fine. In fact,
> some apps explicitly needed EMS and/or EMM386. But nowadays, FreeDOS
> is so good at keep low RAM free that I don't need UMBs for average
> stuff, esp. not DJGPP/DPMI things, so I would only do "JEMM386 LOAD"
> and "UNLOAD" at runtime if needed (rarely).

Never HEARD of "loading and unloading" JEMMEX/JEMM386, which in fact
never DID work properly with MS-DOS EMM386 (or maybe they found very
early that UNLOADING it was DANGEROUS!!).   Same as I noted for UIDE
and UIDE2, why would you EVER want to unload the "JEMM" drivers, for
they take so little memory and are thus "invisible" in normal use??

> My point was that JEMMEX is basically just HIMEMX + JEMM386 bound
> together, and you can't just load at runtime (if XMS already enabled)
> because it only uses its own XMS manager built-in. So while it saves a
> few kb of space by combining them, it's slightly less useful if you
> don't want EMS or UMBs (and/or have a very rare app that refuses to
> run under V86 mode). Also I very vaguely remember some apps in the old
> days not working correctly with NOEMS.

Such apps ought to be RETIRED, if they are so "incompatible".   And if
anyone truly HAS a serious "need" for unloading JEMMEX, they should be
using HIMEMX + JEMM386 (or my own XMGR + JEMM386), since in that case,
unloading at-least JEMM386 can be done a LOT more easily!ought to use

> Long story short:  heh, 30+ years of compatibility can be a pain. But
> it's much easier to use (for me) than the alternatives.   ;-)

Actually, only about 15 years of compatibility, since the first EMM386
did not appear until about 1990, and 386MAX was around only from 1988.
But, I agree:  For most people, JEMMEX is "The Lazy Man's Way" to have
"V86 protected mode" on a DOS system -- Only ONE extra driver needed!


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

>> Intel "giveth" NOTHING, and followeth only "All we want is MONEY!",
>> same as Gates & Co.!   In my opinion, absolutely NO excuse for AHCI
>> that a better-written Windows driver could NOT have solved, but for
>> Intel as-always wanting to sell-Sell-SELL new chips!
>
> In fairness, not every person is truly as diligent, intelligent, and
> experienced as you are.   So while "in theory" somebody could rewrite
> Windows drivers or whatever to be 10x faster or smaller or better,
> it's probably just wishful thinking ...

My Thanks for your personal compliments, but I still DO believe there
MUST be someone at Intel or Microsoft who COULD have done a better job
with SATA/IDE, rather than simply "throwing up their hands" (all maybe
3000 of them!!) and saying "We need more HARDWARE"!   Or, it really IS
an "Intel conspiracy" to sell more chips; wouldn't be the first time!!

>> ... and (B) AHCI is RIDICULOUSLY complex, the obvious results of
>> it being designed by a [MISERABLE!] "ANSI committee" which tried
>> to satisfy EVERYBODY and in the end satisfied NOBODY, as-usual!
>
> Yes, unpopular standards by committee are no better than no standard.
> But sometimes compromise is all you can get. You win some, you lose
> some.

Note that I said "RIDICULOUSLY complex", and as above, I have REASONS
for believing "No AHCI at ALL" could have been made to WORK!

>> Hardware improvements like those you mention will never "hurt" any
>> existing software, only make it faster.
>
> Not always the case, sometimes software misunderstands or interacts
> badly with more RAM or faster cpu.   Also the timings for cpu
> instructions change, so what was once faster (e.g. 186 optimizations
> [ENTER, LEAVE] vs. 8086) is now "comparatively" slower (to its
> counterpart, e.g. 2.5 times slower).

"Rare" circumstances.   They have occurred, but I doubt that Intel
allows such situations very often.

> It's true, assembly will always win, but few are willing to go that
> far ...

Absolutely "known" in the 1980s or 1990s, when U.S. colleges virtually
"gave up" on finding ENOUGH "Slept Through High-School" BRATS with 1/2
a brain, that might even be CONSIDERED for assembly-language software!
THAT, and ONLY that, is why most U.S. colleges now teach only "C"!   I
used to joke about their college degrees being "B. S. Chicken. Sh**.";
not-much of a JOKE, any more!!


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

>> JEMMEX/JEMM386 also allow VCPI/DPMI to be used,
>
> VCPI, yes, but not DPMI, you don't (necessarily) need EMM386 for that.

Same for VCPI, I suppose -- There are "subroutine packages" that set up
VCPI for a user application, if needed.

>> they allow "mapping" of
>> upper-memory addresses into UMBs that UMBPCI cannot do (e.g. B000-B7FF)
>
> Yes, if you can use it or "need" it. However, a 32-bit DJGPP app or
> pure real mode "conventional memory only" usually doesn't.

But, there are a LOT of us who do not use DJGPP and yet COULD use a bit
more UMB space, to load more/bigger drivers etc.

>> and they can be the "one provider" of upper-memory required by FreeDOS,
>> which does NOT add-up the memory found by both UMBPCI and HIMEMX/JEMMEX
>> (MS-DOS V6.22 and V7.10 WILL do this).   Many other reasons, I am sure,
>> for using JEMMEX/JEMM386.
>
> FASTBOOT and VME are good reasons, but I don't run a lot of EMS-based
> software these days, so I don't enable EMM386 by default anymore.

Nor do I use JEMM386 in everyday work, as I run a "pure" V6.22 MS-DOS
and do not need the extra features.   I am only saying that you ought
not so-quickly "dismiss" the idea of using an "EMM" driver.   They DO
have their uses!

>> ANY usage of JEMMEX/JEMM386 is GOING to "leave you in V86 mode", since
>> by definition THAT is the "protected mode" used by any "EMM" driver to
>> protect the system from errant DOS programs!
>
> Not much protection. DPMI is (usually but not always) ring 3, which is
> better than ring 0 VCPI. Sure, DJGPP is rock solid (thanks to good
> work by CWS), but other stuff isn't so kind, hence EMM386 rarely helps
> there (in my limited experience).

Thus far, I have been absolutely UNABLE to "break into" a V86 system,
which I might LIKE to do, so UIDE/UIDE2 are a bit faster from needing
NO "Int 15h Ah=87h" XMS move "traps" when V86 is active.   The level
of protection provided by "V86 mode" sure looks SOLID enough, to me!

> EMM386 only exists for backwards compatibility with EMS-using
> software, and it was easier to implement due to the 386's MMU
> (or whatever, I don't understand the details).   Sure, EMM286
> exists in rare cases, but it's not as good.

I must DISAGREE:  EMM386 may have been written for "EMS" memory
but it EVOLVED into Microsoft's protected-mode provider and was
NEVER merely a "backwards compatibility" EMS handler!

>> In 16-bit "real mode" i.e. true DOS, you can "play whatever games" you
>> like ... In "V86 mode" as when an "EMM" driver runs an old DOS program
>> you will "TRAP" real QUICK to the "EMM" driver" on almost ALL command
>> EXCEPT commands "legitimate" for up to an 80386+ CPU to execute "on
>> its own"!
>
> It depends on a billion factors.   Cpus these days are very complex.
> (Don't take this the wrong way, I know way less than you do, just
> saying, it's a mess.)

ONly a FEW factors, since a "protection trap" is a "PROTECTION TRAP!"
for any AMD CPU as well as for Intel CPUs!   All vendors "watch" this
type of compatibility VERY closely, which is why I have NO qualms re:
buying an AMD CPU.   They are usually less expensive and WORTHWHILE!!

>> How do either DPMI or FAT32 "affect" single-sector directory handling
>> by DOS??   Do they "magically" RE-program DOS to handle more than ONE
>> directory sector at a time??   I think NOT!!   Until someone DOES so,
>> DOS directory handling will still use SLOW "1981 style" single-sector
>> I-O, and only a cache like LBAcache or UIDE/UIDE2 will help!
>
> Well, that's basically what I meant ...

Glad to hear THAT!!

> In a way, it's a great idea (and one that PatV often mentioned) to
> bring DOS into the 21st century, but it basically means rewriting
> everything, which is very very unlikely to happen. (Kickstarter,
> anyone?) Tons could be improved (and I'd expect compatibility to be a
> top goal, too). However, I know I'm dreaming here, it won't happen.

I don't think it is as NECESSARY at you think!   Back in 1988, I saw an
MS-DOS V3.3 system running EIGHT tasks using an old Quarterdeck type of
multi-tasking, and that was on a VERY-old 80386!   DOS could still WORK
for people (quite-well using drivers like UIDE as Lucho confirmed to me
in 2008) if only they USE it properly, and aren't "Sold down the river"
by Intel and Microsoft into buying "new" systems!   I began my software
career in 1966 at The Bank of California in San Francisco, who had only
2 IBM 1460s and one 1401, each with only TAPES (no disks!) and only 16K
of memory!   Yes, I meant 16,000 7-bit bytes, since memory was TERRIBLY
expensive in 1966!   Any you know what??   Those "poor old" 16K systems
did a LOT more work than my current 1-GB system will EVER do!   We need
NO more "hardware", CERTAINLY NOT any damned 64-bitters having 64-GB of
memory, when in fact Intel/Microsoft never REALLY learned to use 32-bit
or even 16-bit systems all that well!   Same for DOS -- USE IT a little
BETTER, and maybe it CAN do the job, EXACTLY as it is now!!


--

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

Eric,

>> Thus far, I have been absolutely UNABLE to "break into" a V86
>> system ...
>
> VCPI is there to share protected mode, not to keep you outside.

I was discussing "V86", not VCPI.   But in my opinion, requiring
VCPI goes a bit too far, since I now have "XMS only" methods for
UIDE/UIDE2 that are fast-enough for caching purposes.   In real-
mode, my drivers make only "A20 enable/disable" calls to the XMS
manager and do their own "unreal mode" XMS moves.   In protected
mode, the drivers do only "Int 15h AH=87h" move-memory requests,
an "old" BIOS call which is now "trapped" and handled by JEMM386
or whatever "EMM" driver is active.   I have NO further interest
in VCPI nor in other "schemes", that now would only "add CODE"!!

> But indeed while you are in V86, you have limitations. Running
> your stuff in protected mode with HELP of VCPI would fix this,
> but it is annoying to need TWO strategies - while there is no
> V86, it is easy to have unlimited access and faster than even
> shared protected mode with V86.

"Might fix this", as the current XMS-only UIDE has not received
any complaints related to its speed!   VCPI also requires a 4K-
byte block for its initialization, which is almost as big as my
entire driver!   NO, Thank-You!

> You can also "break" EMM386 itself by patching it in RAM but
> I do not see why that would be good for you.

"Forgetting" EMM386 and its miserable 130K size, I have NO wish
to do "patches" on it, on JEMMEX/JEMM386 (an insult to Japheth,
which I will NOT do!), nor to ANY "front line" programs I might
ever write!   Time has taught me "The BEST Way!" for UIDE/UIDE2
is to use only "standard" schemes, the simplest of which proved
to be XMS memory only!

>>> EMM386 only exists for backwards compatibility with EMS-using
>>> software ...
>>
>> I must DISAGREE:  EMM386 may have been written for "EMS" memory
>> but it EVOLVED into Microsoft's protected-mode provider...
>
> I disagree again - EMM386 got the VCPI extension so Windows and
> EMM386 can cooperate instead of being in the way of each other ...

My intent above was to show Rugxulo that EMM386 is NOT "solely" an
"EMS" driver, not as it evolved.   You are free to quote its extra
features, like VCPI.   I hope you see I am NOT-interested in VCPI,
or DPMI, or anything but "regular" XMS, as that is the only system
feature besides Int 13h on which my run-time drivers now "depend".

Best wishes,

Jack R. Ellis


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

Rugxulo,

>> Nor do I use JEMM386 in everyday work ... I am only saying that you
>> ought not so-quickly "dismiss" the idea of using an "EMM" driver.
>> They DO have their uses!
>
> Yes, but not necessarily for EMS ...

Obviously not, as there are few actual "EMS memory" applications still
around and worth using.   When I say "EMM" driver, I refer to JEMM386/
JEMMEX or equivalents like EMM386/QEMM/386MAX/etc., which all provide
DOS support for protected-mode and its features.

>> I must DISAGREE:  EMM386 may have been written for "EMS" memory
>> but it EVOLVED into Microsoft's protected-mode provider ...
>
> MS doesn't even support EMS at all in NTVDM these days --

Sad, that they flatly abandoned their own MS-DOS, and so EMM386 is still
130K of mostly-obsolete trash.   JEMMEX saves about 100K, due to Japheth
having "paid attention, where Microsoft now pays NO attention to EMM386!

> I know there are a few minor quirks, but yes, AMD deserves high praise
> for its products.

I agree.   My AMD CPU is unable to do a backward "MOVSD" ("D" bit set) if
both move addresses do not start on 32-bit boundaries; runs SLOW and gives
data errors!   So, UIDE2 does only a 16-bit "MOVSW" in backward mode which
is O.K. at the point I use it.   Otherwise, a few "rumors" which I respect
in UIDE/UIDE2, but really NO serious problems using an AMD CPU.

>>> In a way, it's a great idea (and one that PatV often mentioned) to
>>> bring DOS into the 21st century ...
>>
>> I don't think it is as NECESSARY at you think!
>
> It's not necessary at all, but when the current crop of computers die
> out, we will buy new ones, and they will be less compatible, etc. etc.
> So eventually everything dies. It's kinda crappy, I don't really like
> it. Can't we just have some stability? No, apparently not. It's all a
> chase after the wind. (And don't tell me about Windows or Linux, they
> aren't stable, lots of "barely" old software doesn't work anymore.)

I agree entirely.   What would we do without computer "salesmen"??!!

>> We need NO more "hardware", CERTAINLY NOT any damned 64-bitters
>> having 64-GB of memory, when in fact Intel/Microsoft never REALLY
>> learned to use 32-bit or even 16-bit systems all that well! ...
>
> I agree, but nobody else does ... Pperhaps you should read what
> Niklaus Wirth had to say back in 1995, "Plea for Lean Software".
> Unfortunately, it seems that nobody listened.

I did read Wirth's comments, and he is essentially correct, although he
LOST my attention by making his project specific for his needs, e.g. it
includes an object-oriented language (YECCH to me, even more than "C").
And I agree, nobody listened -- Microsoft had to continue "feeding" its
1500 Win/NT programmers and its maybe 500 DOS programmers at that time!
They remind me of the old Jason Robards and Barbara Harris movie titled
"A Thousand Clowns"!

Best wishes,

Jack R. Ellis


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers

[Jack]

 We need NO more "hardware", CERTAINLY NOT any damned 64-bitters
 having 64-GB of memory, when in fact Intel/Microsoft never REALLY
 learned to use 32-bit or even 16-bit systems all that well! ...
>>>
>>> I agree, but nobody else does ... Perhaps you should read what
>>> Niklaus Wirth had to say back in 1995, "Plea for Lean Software".
>>
>> I did read Wirth's comments, and he is essentially correct, although
>> he LOST my attention by making his project specific for his needs,
>
> Well, the big problem is that there are too many derivatives, and it's
> hard to get it booting (at least for me).   Also, yeah, it pretty much
> assumes you do everything its own unique way ...

Never knew a "college professor" who thought any differently!!

>> ... e.g. it includes an object-oriented language (YECCH to me, even
>> more than "C").
>
> In fairness, Oberon is basically very very similar to Modula-2, so the
> OOP stuff is very minimal and completely optional ...

Glad to hear that, but it changes little re: my opinion of Wirth's system.

>> And I agree, nobody listened -- Microsoft had to continue "feeding" its
>> 1500 Win/NT programmers and its maybe 500 DOS programmers at that time!
>> They remind me of the old Jason Robards and Barbara Harris movie titled
>> "A Thousand Clowns"!
>
> Too big for their britches, perhaps.   Too focused on money, too trendy.
> But what can you do, that's what sells.

Not to ME, it doesn't!   I shall KEEP my 5-year-old AMD 3000+ with its only
1-GB of "regular SDRAM" (not SDRAM2 or SDRAM3) for as long as I can.   Runs
fine for me, has for 5 years, and saves me all that MONEY v.s. being forced
by Intel/Microsoft into buying what THEY think I should buy, same as my old
1994 V6.22 MS-DOS and 1996 V4.0 Win/NT have also saved me a LOT of money!

In my day-to-day life, I follow a simple rule:  If somebody has to write or
E-Mail me a letter, call me on the telephone, or worst-of-all come knocking
on my door, WHATEVER they are "pushing" I absolutely DO NOT want!   I "paid
attention" in school and thus can make MY OWN decisions re: what to buy and
when!   Same thoughts about my computer -- Intel and Gates & Co. will NEVER
"push" me into buying their latest (usually high-cost) "trend" items!   Sad
how more people do not see things this way and get "Sold down the river" so
often!   We need such things like AHCI and "Vista" like we need the PLAGUE!


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] VERY Funny "Off Topic" --

[Jack]

VERY funny "off topic", overheard today, which I just HAVE to share --

What does a U.S. Age-20s "Slept Thru High-School" type, too old to say
"The dog ate my homework!!", try to tell our apartment manager re: why
he cannot help with his girlfriend's 3-week late rent??

"The ATM ate my check!!"

A valuable lesson, as I know little of the U.S. language "BratSpeak"!!


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] New 23-Mar-2012 UIDE/UIDE2 -- Minor SIze Reduction.

[Jack]

Johnson Lam has posted a new DRIVERS.ZIP file, now dated
23-Mar-2012, on his website at:



The UIDE and UIDE2 drivers now use only 912 bytes of upper-
or DOS memory with their /H switch!To do this, UIDE now
runs 30 BIOS units (was 34) same as UIDE2, and the logic in
both to handle caching requests from other drivers has been
revised to save space.   See the UIDE.TXT file, for details
about this.

No change to the other drivers, and the update for UIDE and
UIDE2 is only for convenience, not a "bug fix".   Thus far,
no one has needed 30 BIOS units or has called my drivers to
do user-driver caching (regrettably).   So, this update for
UIDE/UIDE2 should not affect anyone.

Johnson's website may still display 7-Mar-2012 as its "Last
Update", but the files now available ARE dated 23-Mar-2012,
and Johnson will correct this when he can (very busy!).


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Long-term survival of FreeDOS

[Jack]

> This topic is not about DOS vs other operating systems, or the fact
> that users tend to gradually abandon DOS. It's about the survivability
> of DOS vis-a-vis hardware ... What will happen with future development
> of the hardware architectures?

Cannot answer on all subjects, but re: disk/CD/DVD drivers, I am NOT
overly optimistic!   Intel/Microsoft want us all to "buy into" AHCI,
and they may have started "ordering" mainboard vendors to omit SATA/
IDE logic from their BIOS routines.   If this becomes the "de facto"
standard, UIDE and other DOS drivers will NOT be able to run!   I am
hoping mainboard vendors WILL see the need (despite such "orders" by
"the industry") to retain SATA/IDE compatibility modes.   Otherwise,
the long-avoided "Bloody NIGHTMARE" of adding AHCI in UIDE will have
to be done, and quickly!

> Related questions are: how adaptable would the (Free)DOS codebase
> prove, in the event of this happening?  How much manpower would be
> required to recode/adapt (Free)DOS to the new needs?  In short,
> could DOS survive such a situation?

Aside from the kernel and drivers, the DOS codebase should survive,
as long as 80x86 commands can be executed.   If support for them is
dropped, NO amount of manpower will save DOS, since EVERYTHING will
have to be rewritten in that event!


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Jack]

>> actually I would not even OFFER a boot menu item to skip loading the
>> XMS driver at all: You cannot even boot the install CD / USB on old
>> pre-XMS PC.
>
> Probably a bad idea for compatibility reasons, unless you offer multiple  
> choices for which XMS manager to install.  E.g., I have a computer where  
> JEMM doesn't work at all, but some of the others (including MS  
> HIMEM.SYS) do.

Have you tried explicit "I=-" and "X=-" commands with
JEMM386/JEMMEX??   Both of them were designed to use "ancient" EMM386
memory detection schemes, for compatibility reasons.   However, newer
devices and/or BIOS routines may require that JEMM386/JEMMEX are told
to "avoid" their upper-memory address areas.

Re: loading with no XMS driver, that can still be a useful diagnostic
scheme, and I continue to permit UIDE/UIDEJR (but no-longer UIDE2) to
be run in such a configuration.


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Long-term survival of FreeDOS

[Jack]

On Tue, 10 Apr 2012 22:16:50 -0700, Ralf A. Quint  wrote:

> At 01:13 PM 4/10/2012, Jack wrote:
>> Cannot answer on all subjects, but re: disk/CD/DVD drivers, I am NOT
>> overly optimistic!   Intel/Microsoft want us all to "buy into" AHCI,
>> and they may have started "ordering" mainboard vendors to omit SATA/
>> IDE logic from their BIOS routines.
>
> Do you have a source for this statement?
>
> Sorry, but this completely contradicts the latest "Ivy bridge"
> chipset just released, which includes 6 SATA/eSATA ports...
>
> http://www.theregister.co.uk/2012/04/10/intel_7_series_chipsets/
>
> http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/z75-z77-express-chipset-brief.pdf
>
>
> Ralf
>
>
> --
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> ___
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user



--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Long-term survival of FreeDOS

[Jack]

Ralf,

Apologies for my previous "reply", which was not a reply, only my having
hit Opera's "send" button by error!

>> Cannot answer on all subjects, but re: disk/CD/DVD drivers, I am NOT
>> overly optimistic!   Intel/Microsoft want us all to "buy into" AHCI,
>> and they may have started "ordering" mainboard vendors to omit SATA/
>> IDE logic from their BIOS routines.
>
> Do you have a source for this statement?

No, I do not.   However, having seen the way Intel forced VESA and
AGP out-of-business (to name only two), one can "expect" Intel has
its guns aimed against SATA, as well, in favor of AHCI.   Intel is
in business to sell-Sell-SELL new chips, after all!

> Sorry, but this completely contradicts the latest "Ivy bridge"
> chipset just released, which includes 6 SATA/eSATA ports...

Well, I would say "Saints be Praised"!   Perhaps I am not the only
one who regards AHCI as a big waste-of-time.   Or money -- Is this
new Intel chipset intended to be a "low cost" model?   I will wait
to see if Intel later releases an "Ivy Bridge" that uses AHCI, and
if so, which one (SATA or AHCI) "prevails" in the marketplace.

Jack R. Ellis


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Freedos 1.1 install errors...

[Jack]

> ... With my own testing I found JEMMEX more compatible than XMGR or
> HIMEMX + JEMM386 in various cases, but on other systems it's different,
> as Mike mentioned ...

To WHAT "incompatibilities" are you referring??

Be advised of the following --

1) JEMMEX/JEMM386 use "old" memory-test schemes, to remain compatible
with that never-updated 130K atrocity known as MS-DOS EMM386!   If
using the JEMM drivers, specific "I=-"/"X=-" lines
may be needed to avoid "new-style" areas of memory -- "I=Test" and
"X=Test" might not be enough.

2) "XMGR + JEMM386" or "HIMEMX + JEMM386" should give nearly the same
results for available memory.   HIMEMX may find about 9K more, for
it allows use of certain ACPI areas, while XMGR does not.   But 9K
bytes is not a big difference, given today's 4-Gigabyte systems!

3) "UMBPCI + XMGR" may well give far bigger differences in the memory
it finds for use, since in this case UMBPCI "detects" upper-memory
and XMGR then uses what UMBPCI found.   I did not write UMBPCI but
I believe its memory-test algorithms ARE rather different than the
ones used in JEMM386/JEMMEX.

4) "UMBPCI + XMGR + JEMM386" can also be used, when one allows UMBPCI
to scan for "normal" upper-memory (C8000h-Eh) and only desires
JEMM386 to "map" the B-B7FFFh monochrome video space for extra
upper-memory.   But NOTE that this will NOT work using FreeDOS, as
FreeDOS allows but ONE upper-memory "provider" and will not add-up
the memory found by UMBPCI and JEMM386.MS-DOS V6.22 and V7.10+
allow multiple "providers" and will do such an add-up.


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user