Re: [Freedos-user] Freedos 1.1 install errors...

>>> ... With my own testing I found JEMMEX more compatible than XMGR >>> or HIMEMX + JEMM386 in various cases, but on other systems it is >>> different, as Mike mentioned ... >> >> To WHAT "incompatibilities" are you referring?? > > The A20 stuff that Syslinux/Isolinux (and MEMDISK) mess around wit

Re: [Freedos-user] sata drivers for cd, dvd, and hard disk

DROM.SYS or VIDE-CDD.SYS drivers. They do not provide CD/DVD caching (HUGE speed improvement!), nor do they use UltraDMA I-O, present in all CD/DVD drives from about 1999 onward. UIDE does both. Any questions re: UIDE usage/installation/etc., feel free to send me an E-Mail, and I shall be glad to help

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

from about 1985 onward. I suggest you "Have another LONG chat!" with the creators of Virtual Box, who seem to live in their own world and seem to IGNORE a lot of pre-existing PC hardware conventions "Whenever it suits them!". Jack R. Ellis

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

that the writers of VirtualBox "Follow the RULES!" for PC hardware, instead of leaving you and I (perhaps others as well) to make changes in long-established programs just for them!! Jack R. Ellis -- Live Secu

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

; for you, if you must ever use multiple diskettes in VirtualBox with UIDE again, is to issue "CC" if your diskette must be changed. This will "flush" UIDE's cache and prevent the "same diskette" problem from occurring. Jack R. Ellis ---

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

for UltraDMA I-O, which is "Better than nothing!" as we say, but absolutely NOT as fast as its caching routines! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the wa

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

it goes back over a 7K .SYS file! But, I shall find a way! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

(caching) and then again running with UIDEJR (no cache). If there is no speed change, your host likely is doing caching, and you may not need my drivers at all. Jack R. Ellis -- Live Security Virtual Conference Exclu

[Freedos-user] New UIDE/UIDE2 With "VirtualBox" /N5 Switch.

Johnson Lam has posted a new 20-May-2012 DRIVERS.ZIP file with updated UIDE and UIDE2 drivers, on his website at: UIDE and UIDE2 now have a /N5 switch, to disable diskette caching when running with "VirtualBox" or other emulators which do NOT post a disk

Re: [Freedos-user] Virtual floppy change problem

Bertho, >> Given the "high level of responsibility" [Ha-Ha!] taken by the >> VirtualBox creators, it looks as if I will have to add another >> UIDE switch, that disables diskette caching regardless of what >> its other switches tell it to do.  > > Jack,

Re: [Freedos-user] Virtual floppy change problem

>>>> -- UIDE2 has only 16 spare bytes before it goes back over a 7K >>>> .SYS file! But, I shall find a way! >>> >>> No doubt you will. >> >> In fact only 12 bytes, and I required only 11 of them for /N5, so >> UIDE2 still has 1 spare!

Re: [Freedos-user] Virtual floppy change problem

Thanks to you, as well! I get few positive comments about UIDE -- people appear to "take it for granted", I guess -- and I do appreciate your thoughts! Jack R. Ellis -- Live Security Virtual Conference Exclusiv

Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem

unnecessary busses/devices. In any case, no one has ever complained about the speed of UIDE's or UIDE2's initialzation, except when running "VirtualBox"! Also, better if you refer to "UIDE" in general,

Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem

-- UIDE2 has only 16 spare bytes before it goes back over a 7K .SYS file!   But, I shall find a way! > > I've never looked at UIDE closely, but there's "always" room for space > improvement in assembly!! ;-) Maybe you should "look again" at the UIDE.ASM source file! I have "boiled d

Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem

n Why-in-HELL do you suggest any OTHER "possibilities", as in much of your comment above?? >> Also, better if you refer to "UIDE" in general... > > Honestly I am no expert in any UIDE* source, as things > are very packed and rank small size over easy to read &g

Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem

g the above, should damned-well INSIST that "VirtualBox" etc. gets FIXED! I am VERY TIRED of having to add "Band Aids" into my drivers to deal with the FOOLISH errors of OTHERS!! Jack R. Ellis -- Live Sec

Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox U IDE2 init problem

>> The FAT file system is defined by DOS, and I want UIDE/UIDE2 to >> have NO run-time "dependencies" on the DOS system. > > Nice in theory, but unfortunately doesn't work in practice. Sure seems to, since before this thread, UIDE/UIDE2 have "trapped" only BIOS Int 13h I-O requests, and no one has

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

> I was about to post bugreport at VirtualBox bugtracker, but decided to > double-check the issue first. On my system floppy images change are > correctly recognized. VirtualBox 4.1.4-3.2.3 OSE OpenSUSE 12.1. The "issue" is that VirtualBox is not posting diskette media-change status in the BIOS da

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

s that are "seen" when VirtualBox runs are INCORRECT! > maybe the real issue is that noone finds the time to do a tiny bit of > debugging the problem but finds a lot of time to write loong > emails To which I shall add:

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

and their media-changes runs fine. As I want to keep UIDE/UIDE2 simple, I shall leave things as-is. If users want to run VirtualBox, they can simply use UIDE/UIDE2 /E which specifies 'hands off those floppies' (like Tom stated above), exactly as the writers of VirtualBox intended! No dis

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

>> UIDE has NEVER ignored if a diskette has change-line support! It >> does in fact check the BIOS data table at 0:48Fh for bit 0 (change >> line for diskette A:) or bit 4 (change line for diskette B:). If >> those bits are off, diskette A: or diskette B: will not be cached. > > That is an inte

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

> It's not impossible to cache floppies, Jack. You just need to do it > differently than you're doing now ... Back in 1980, I told an old friend of mine about a 750K video-driver package which I had seen (written in "C", of course!), and he noted, "They've got

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

> to make a long answer short: > in VirtualBox, 40:8f is 00 > again, clearly stating 'change line is not supported' Maybe for your system, obviously not on Wolfgang's, and who-knows re: other "C"-based systems with NO reason to post a BIOS data-table at 0:400! That is my guess re: what is occurr

Re: [Freedos-user] Virtual floppy change problem

>> You are WRONG, Tom!! > > Is he ? or are you being RUDE, Jack? Tom could have written me privately, before publicly saying UIDE assumes change-line support, but did not. I responded in kind! > Not Tom, but I'd like to learn from /what exact source/ you got the > de

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

> Jack, PLEASE, don't pull yourself up on the "VirtualBox" issue, it is > rather a more general problem. > > You simply rely on the contents of the memory region rather than than > properly query system via INT13. And that isn't adding much to the > logic and

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

Cs and (NOT so "flaky") hardware change lines will continue to run just fine! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threa

Re: [Freedos-user] Virtual floppy change problem with VirtualBox

>> As I just got through noting, in another post, why would the BIOS >> data include diskette change-line flags if they were NOT intended >> to be USED?? >> >> Until someone can positively REFUTE the data offered by the BIOS >> Central data-table list, my opinion is that neither you nor any- >> one

Re: [Freedos-user] checking virtualbox source codes for floppy and pci speed issues

ED bit at 0:048Fh!! How INTERESTING!! NOT including you, Eric, who took the time to "find out" all of the above, but I think there are many God-DAMNED BUFFOONS on this forum who owe ME an APOLOGY Jack R. Ellis

Re: [Freedos-user] checking virtualbox source codes for floppy and pci speed issues

es) runs almost instantaneously, so I see no reason to change THAT logic in UIDE/UIDE2, either! You also MIGHT hear from VirtualBox that their setup of 0:048Fh is in fact CORRECT and some OTHER element of their program is LOSING the byte! I.E. they DID intend diskettes to provide change-line support,

[Freedos-user] UIDE Diskette "Change Line Capability" Tests.

Re: the thread on this forum about how to test if a diskette will support a "media change line", I offer the following: My system has an old 2007 single-CPU Biostar mainboard with a VIA 8237 controller (VIA has now just-about quit offering chipsets!). My BIOS is from Phoenix and is dated 11-Jan-20

Re: [Freedos-user] UIDE Diskette "Change Line Capability" Tests.

THE POINTS! -- that I have listed above!! And do so in private, as after this E-Mail, I will again unsubscribe from FD-User."Jack is right and everyone else is an idiot", "Are you trying to prove yourself smarter than everyone else", plus other such INSULTS will be ENOUGH

[Freedos-user] DISGUSTED With "Pundits"!!

ll again "unsubscribe" from FD-User. And I hope NO ONE expects me to listen to any of its "pundits" ever again!! Jack R. Ellis = Original Message Subject: Problem with the UIDE Cach

Re: [Freedos-user] DISGUSTED With "Pundits"!!

> A++ would read again For all those of us who do not speak "Germanicized" English, would you care to say EXACTLY what-in-HELL the above means?? > Regards from our Bunch of Trolls That Ruin (TM) And "Greetings" to you, Mr. "Junior" Troll (VERY "junior", indeed!). I see you must have learned N

Re: [Freedos-user] DISGUSTED With "Pundits"!!

> I don't know ... Well, Mike, at least you ADMIT to it! > ... but if there was a utility to analyze the tone and content > of messages and rank them I think that a lot of your messages > to this list would be labeled "aggressive/hostile". Tough tomatoes. If you don't like my tone, for which

[Freedos-user] Using UHDD/UIDE In "Protected Mode".

An IMPORTANT note on using UHDD/UIDE, which I felt needed to be posted -- "Protected mode" users (JEMM386, EMM386, etc.) who run UHDD or UIDE should load these drivers with their /F switch. For caches of 80-MB to 1023-MB, /F causes UHDD/UIDE to have 64K cache blocks, not 16K blocks. 64K block

[Freedos-user] New UHDD/UDVD2 -- A "Clarification"!

UHDD into a small cache-only driver. For "CD/DVD only" or other such systems desiring only one cache, UDVD2 can omit /N and simply run on UHDD's cache, as before. Jack R. Ellis -- Learn the latest--Visua

Re: [Freedos-user] New UHDD/UDVD2 -- A "Clarification"!

My apologies -- In my earlier E-Mail today about UDVD2/ UHDD, I meant to say: "For 'CD/DVD only' or other such systems desiring only one cache, UDVD2 can omit /S [not /N] and simply run on UHDD's cache, as before." -- Le

[Freedos-user] UIDE Updates: NOT "Losing My Mind"!

Re: Rugxulo's FreeDOS front-page comment about "Another week, another UIDE update", I want to assure people that, despite now being age 68, I am NOT "losing my mind"! The 20-Aug-13 update was to provide "CD/DVD kiosk" users in Hong Kong (and elsewhere) a way to cache CD/DVD data without loading t

[Freedos-user] New 14-Nov-2013 UHDD/UDVD2 -- Private Caches Deleted.

The "UIDE" drivers have all been updated to 14-Nov-2013, and they are now available from Johnson Lam's "dropbox" at -- In this update, UHDD and UDVD2 no-longer support "private" caches for user drivers. Reasons for this are a bit "involv

[Freedos-user] "LBA" And FreeDOS.

Note on the FreeDOS "main page" that there are comments about FreeDOS offering "LBA" large-disk capability (48-bit disk addressing, not 24- bit "CHS"), which MS-DOS did not have, and which the "main page" says was unavailable except with DOS Windows. NOT quite true! From having written and teste

Re: [Freedos-user] "LBA" And FreeDOS.

recommending that FreeDOS "advertise" or support ANY other DOS variants -- I am simply saying that V7.10 MS-DOS is in fact still available, as at-least the website I note above should prove to you. > It would be fa

Re: [Freedos-user] "LBA" And FreeDOS.

> It's really too bad, though, that MS won't make it official and release > the MS-DOS source as public domain, or at least one of the various > open-source licenses. "Surely you JEST!", my friend [are joking]! "Gates & Co." are charter members of the U.S.A.'s "All we want is MONEY!" brotherhoo

Re: [Freedos-user] "LBA" And FreeDOS.

> The ms-dos7.ht.bg site seems to have been offline since 2010 ... Oh, REALLY?? Sure worked well for me yesterday, 4-Dec-2013, when I got both V7.10 MS-DOS diskettes and checked them! And it also caused me no problems when I accessed the site again, a moment ago!!

Re: [Freedos-user] "LBA" And FreeDOS.

Rugxulo, Re: your recent posts, I will summarize my feeling as follows: "LZ-DOS" and other copies of V7.10 MS-DOS are still available. You may not consider it reliable, and Dennis may have some odd problem accessing it, but that website did give me, on 5-Dec-2013, a work

Re: [Freedos-user] "LBA" And FreeDOS.

t;> And re: your comment that "You can't 'freely' download, modify >> or redistribute any DOS besides FreeDOS", I can only say again >> that the above website most-certainly DID work for me! > > Freely in this contex

Re: [Freedos-user] "LBA" And FreeDOS.

legal. As I said, I will not argue the legalities, since you indicate that they are "murky" at best when applied to "abandonware" like MS-DOS. I only wanted to give an example of V7.10 MS-DOS still being avail- able for use. Further debate about its availability being "legal

Re: [Freedos-user] "LBA" And FreeDOS.

al in pc after all. A pleasure to know you, dear Lady, after all my dealings on this forum with "legalists" who FAIL to see that I was only giving an EXAMPLE of V7.10 still being available!V6.22 MS-DOS and V4.0 Win/NT also save poor-old retirees li

[Freedos-user] New 12-Dec-2013 UIDE Driver.

Johnson Lam has posted a new 12-Dec-2013 DRIVERS.ZIP update in his "dropbox" at: UIDE now offers a separate CD/DVD cache, with a /C switch, for users with an "old" CD drive requiring limited seeks, to avoid tracking errors and low speed.

[Freedos-user] New 12-Jan-2014 UIDE, With 4 Caches!

Johnson Lam has posted a new 12-Jan-2014 DRIVERS.ZIP file, with an updated UIDE and re-issued UHDD/UDVD2, in his "dropbox" at -- The file is "postdated" 12-Jan-2014 as Johnson is VERY busy at his job, but he has managed to post it early.

Re: [Freedos-user] New 12-Jan-2014 UIDE, With 4 Caches!

plus any "user driver" caches, must total 4-GB or less! Sorry if that disappoints you. ;) >> ... In any case, I wanted to get multi-caching done in UIDE, while >> I still had some ideas about HOW to do it!! > > Enjoy 2014 in good health Jack! Thanks for updatin

Re: [Freedos-user] New 12-Jan-2014 UIDE, With 4 Caches!

re possible, but not all DOS systems work with them -- V6.22 MS-DOS "CHKDSK" CRASHES when RDISK is patched for 4-GB! Jack R. Ellis -- Rapidly troubleshoot problems before they affect your business. Most IT org

[Freedos-user] Updated UHDD/UDVD2 Drivers: Caching Re-Added.

Johnson Lam has posted a new 26-Jan-2014 DRIVERS.ZIP file, with a corrected UIDE and an upgraded UHDD/UDVD2, in his "dropbox" at -- UIDE had an error in its /B "stand alone" driver, which would not ignore CD/DVD media changes as it should.

[Freedos-user] SERIOUS Off-Topic, Part 2 -- U.S. Medicine.

An off-topic addendum to my 2011 post on this forum about U.S. medicine -- Regrettably, I have been diagnosed with a 98% chance of bladder cancer, for unknown reasons excepting bad luck. I was told it needs to be "taken care of" within 3 months, after being detected on 4-Mar-2014.I do not d

[Freedos-user] Off-Topic: Recovering From The HOSPITAL!!

My Thanks to Rugxulo, DOS386, and others on this forum for their good wishes about my prostate surgery. I am told by my surgeon that I have NO cancer, neither bladder nor prostate, and I shall be "with you" for a while longer. But in fact, it was the WORST medical experience of my life! I told

[Freedos-user] Using UIDE/UHDD With FreeDOS.

My "belated" reply to an FD-User post by Bill Haught, dated 2014-07-18 12:36:17 and answered below by Tom Ehlert. I planned to stay silent, but all of the following "BEGS to be addressed!" -- >> As I mentioned earlier, Freedos requires a ATA legacy mode in BIOS, >> which I don't have. > > wrong.

[Freedos-user] New 27-Sep-2014 Drivers -- UHDD Updated.

BAD year for illness re: my surgery in May and re: Johnson Lam having a nasty Flu last week. Johnson is finally O.K., and he has posted a new 27-Sep-2014 DRIVERS.ZIP file with an upgraded UHDD driver, in his "dropbox" at: No changes to t

[Freedos-user] New 19-Oct-2014 Drivers -- Faster UHDD!

Johnson Lam has posted a new DRIVERS.ZIP file, now dated 19-Oct-2014 and with an updated UHDD driver, in his "dropbox" at: No change to any of the other drivers but re-dating them 19-Oct-2014 for consistency, also no change to the /B "sta

[Freedos-user] Clarifications.

ermany, one in the Czech Republic, one in Russia, and one in Illinois, whom I want NOTHING to do with, now and forever! As for Bernd Blaauw's comments about me "putting aside" previous differences ... Jack R. Ellis

[Freedos-user] UDMA Driver Update.

Sorry, I was unaware that this board does not like "carat" characters for URL addresses. To download the 7-Sep-2007 XMGR, UDMA, and UDVD drivers, use the following URL: http://johnson.tmfc.net/dos/drivers.html - This

[Freedos-user] UDMA Driver Update.

Thanks to the help of Denis Andrianov from Russia, I have found a SERIOUS error in the new UDMA caching driver. It mishandled external-unit numbers and so would not cache more than one UDVD CD/DVD drive correctly. The error in UDMA is now fixed, and the drivers are now updated to a date of 7-Se

[Freedos-user] Congrats to Grech!

My congrats to my good fiend Grech for having "patched" and extended usage of the non-caching XDMA! Those on BTTR who have noted the 50-MB speed of UIDE, and those who have noted privately how UIDE "works everywhere", will truly value a substandard, obsolete driver as a second-choice! And give

[Freedos-user] Congrats to Grech!

> Jack, your email is an obvious troll. If you don't have anything > of substance to contribute, don't try to stir up trouble. Please > stop this. Jim, your comments above are absolutely the most UNFAIR thing I have EVER seen you do.Udo Kuhnt wrote me yesterday, 4-Dec-

[Freedos-user] Congrats to Grech!

> Jack, my fRiend, do you think it is a good idea to make a "federal case" > ... "Federal Case", you say??A phrase rarely heard outside the U.S.A., which refers to the laws we use to prosecute gangsters or racketeers?? With your recent f.iend, that is 2 NEW

[Freedos-user] getting applications working

If you update FreeDOS, in accordance with the update list noted by Eric Auer, do consider adding the UIDE or UIDEJR driver, also XMGR and RDISK if desired. They are avail- able from , also from other Internet sources. UIDEJR is a "basic" hard-disk and CD

Re: [Freedos-user] getting applications working

>> I guess this means we'll be able to drop the old sets of >> PCI UDMA drivers and cdrom-drivers as well, though I can >> remember using some of them to get a more stable pci-bus >> set up. (more initialisation done than standard PCI by >> BIOS) > > Interesting, but using BIOS is more compatible,

[Freedos-user] UIDE.SYS

rite code in its BIOS chip, this scheme uses little time and achieves almost the same caching performance as a mainboard controller. On your system with "add on" cards, do note if UIDE declares any "

[Freedos-user] Updated 9-Jun-2009 UIDE/ UIDEJR Available.

Johnson Lam has posted a new 9-Jun-2009 DRIVERS.ZIP file on his site at . The UIDE and UIDEJR drivers can again be run without any XMS memory for "ancient" PC systems. The drivers now set a "UIDE$" or UIDEJR$" driver name when if CD/DVD units are found, so autoloader scripts do not get their /

[Freedos-user] Updated 9-Jun-2009 UIDE/ UIDEJR Available.

Sorry, in my previous post about UIDE/UIDEJR, I meant to write " ... when NO CD/DVD units are found ..."! -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables

Re: [Freedos-user] UIDE.SYS

"DOS386" wrote: > Thanks for the explanation ... UIDE won't see the PCI addon > card since it uses BIOS INT $13 to search for disks ... but > does anything prevent UIDE from searching for IDE/ATA/SATA > stuff using PCI BIOS, and assigning it to a "free" INT $13 > disk number specified in commandl

Re: [Freedos-user] UIDE.SYS

>> Such disks would have to be "installed" into DOS ... > > OK, so it's trivial to add them into INT $13 and make > available for WDE disk editor, IDEcheck, NTSC4DOS and > other "DOS-independent" tools based on INT $13, but DOS > won't see them for a known design fault of itself ... > what IMHO cou

Re: [Freedos-user] UIDE.SYS

> You can easily register drives AFTER boot, without giving them > int 13 interfaces, using the well-documented and well-working > DOS block device interface. Disk editors are not very widespread > but NTFS4DOS (NTSC is a television thing) and disk caching might > be a reason why providing int 13

Re: [Freedos-user] UIDE.SYS

DOS386 wrote: > I haven't asked for adding block-device to UIDE, just > non-BIOS disks support, and I don't need it too _badly_ > since I have none by now. Non-BIOS disk support for caching already exists in UIDE, in its "external entry" logic which can be conditionally- assembled into the drive

Re: [Freedos-user] UIDE.SYS

Eric Auer wrote: > as your driver already has built-in caching, UIDE does > not need to "make" int 13 device numbers for non-BIOS > devices ... I assume you mean its ability to cache devices other than its own SATA/IDE devices, by using UIDE's "external call" routines, and I agree with you. A

[Freedos-user] "Peace and Quiet"!

! I am changing RDISK from a .SYS to a .COM file, which will then allow a user specified drive letter when loaded thru the AUTOEXEC.BAT file. [Not possible in CONFIG.SYS, a "long story" why!].Anything else I can think of, I will do! If I can do all that, so can

[Freedos-user] Updated RDISK.COM Available.

The RDISK driver is now a .COM file and has been improved. RDISK can still be loaded as-before from CONFIG.SYS, or it can now load from AUTOEXEC.BAT and by user command without needing DEVLOAD. When loaded by AUTOEXEC or later, RDISK can now accept the /:[letter] switch specifying a desired drive

[Freedos-user] Over 4-GB for FreeDOS, Etc.

>> On 14-Aug-2009 13:13, MegaBrutal wrote: >> Who ever needs a 64-bit version of DOS, especially if you need >> to emulate an entire processor while achieving it? 32-bit is >> just fine. I don't know why would anyone switch to 64-bit for >> DOS since people don't even use the advantages out. Of

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

> On Fri, 14 Aug 2009 11:43:17 -0700, Bernd Blaauw wrote: > > I don't know if it's easier or harder to do, but maybe best approach is > twofold : > 1) First 4GB handled traditionally for programs, ramdisks, diskcaches >etc. > 2) Ramdisk driver that can handle all memory beyond 4GB and leaves

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

>> On 14-Aug-2009 21:18, Jack wrote: >> ... But, if we are to "cook up" a new scheme to handle memory beyond >> 4-GB, why limit it only for RAMdisk usage? If the XMS drivers/ >> handlers support such "large" memory, EVERYBODY could use it! > &

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

> On Fri, 14 Aug 2009 15:57:55 -0700, Eric Auer wrote: > > Hi Jack, > >> Re: using memory over 4-GB in DOS, the best way to AVOID many new >> "custom" programs is to raise the capacity of XMS drivers... > >> 1) A change to the XMS request which determine

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

t load them BEFORE Windows - or of course use > the XMS via the normal XMS copy function instead of using > raw protected mode access. As any RAMDISK will in the end > send and receive data via DOS memory, the XMS copy works > per

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

Eric, Sorry, in my last post I meant to say "Int 15h AH=87h" move- memory requests, not "AH=80h". Jack R. Ellis -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day

[Freedos-user] Over 4-GB For DOS -- Etc.!!

Japheth, I noted your reply to Eric Auer on FD-User re: the idea of over 4-GB for DOS, in which you wrote: > PAE paging most likely isn't needed, the simpler approach > "32-bit paging with 4 MB pages" should do as well. What is this?? I have seen the Intel specs for PAE memory but I did not se

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

ll > be a light-enough Windows-replacing environment and work with your > streaming recorder program. Why don't you just run DeepBurner under Win/XT or whatever current Gates & Co. Windows variant you prefer.Remember, "You cannot have it all", and there just MIGHT be

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

t; by a SYSTEM driver AGAINST being re-mapped, moved-around... > > I know I know. My cache also locks memory because it feels bad > to have the data of a disk cache swapped out to a disk... :-p. > That probably also holds for UIDE, now that I think of it... A-solutely!! >>

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

32-bit buffer address. I would NOT rely on other "Virtual DMA" options if using MS-DOS EMM386, since they still FAILED in 2004 when Lucho and I created the first UDMA driver! Jack R. Ellis -- Let Crystal R

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

d? I am an MS-DOS user, and maybe I should not comment here. But as far as I know, FD-EMM386 is no-longer maintained. Also, if you look at the BIG list of changes made by Japheth, in going from FD-EMM386 to JEMM386, then you may not want FD-EMM386, until it gets MANY of those changes! As for a

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

need this.However, NOTE that there is a DIFFERENCE between such "temp"/"working" files and a cache.A RAMdisk holds ALL of such files. A first-in first-out cache may have to DISCARD some sectors of the files when OTHER data must be cached.So the RAMdisk is quite-a-

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

as to discard > data and unless you neglect the overhead that it takes > the cache to "notice" this when reading/writing data ;-) A cache THAT big defeats its pwn purpose, which is to use a SMALL amount of RAM memory to speed-up a much LARGER disk!! UIDE is limited to 2-GB, whi

Re: [Freedos-user] Over 4-GB for FreeDOS, Etc.

K are in fact handling FILES, NOT sectors addressed ONLY by their LBA addresses as done in UIDE! That dependency on a directory, and on FILES in its directory, are what make every DOS RAMdisk driver a FILE handler FIRST, and a sector handler only as a SECONDARY result, in my opinion! You are free

[Freedos-user] RAM disks & jokes (Was: 4 GB for FD etc.)

quot;grandstanding", and trying-to-make-a-name-for-yourself on this forum, at someone ELSE'S expense, NOT mine -- My apoligies to all others on FD-User, but as I have felt for years about the many "Slept Thru High-School" BRATS in t

[Freedos-user] UIDE Question.

"Maybeway36" and Geraldo -- I am the writer of UIDE. To answer your "confusion" about the UIDE driver, the following may be of help -- UIDE is meant to be a "Universal IDE" driver for hard-disk and CD/DVD drives. It enables UltraDMA logic for SATA or IDE disks and CDs/DVDs, which some older B

Re: [Freedos-user] UIDE Question.

In my previous UIDE comments the word "P-R-E-S-E-N-T" was truncated by whatever forum software is in use to the word "S-E-N-T"!! I have NEVER seen such a thing occur in E-Mail or forums before! Please understand that what seems to be "S-E-N-T" should be read as the words "At p-r-e-s-e-n-t". S

[Freedos-user] Inaccurate 10-Jun-2010 UIDE Announcement.

The announcement on the main FreeDOS webpage of the new 10-Jun-2010 UIDE driver is inaccurate. There is no speed improvement in the latest UIDE. That was achieved in the previous 19-May-2010 release. The BTTR webpage noted as detailing the new 10-Jun-2010 UIDE is also incorrect and details only

[Freedos-user] Vitoria(supplying CCTV security equipment) www.vitoriasz.com

Madam, Nice to introduce myself and our company to you! I'm Jack from Vitoria Video Technology(Shenzhen) company. Our company's headquarters is in Shenzhen PR China. And Vitoria also has subsidiary company in S?o Paulo, Brazil and Honkong. It's manufacturing factory is loca

[Freedos-user] Vitoria(supplying CCTV security equipment) www.vitoriasz.com

introduce myself and our company to you! I'm Jack from Vitoria Video Technology(Shenzhen) company. Our company's headquarters is in Shenzhen PR China. And Vitoria also has subsidiary company in S?o Paulo, Brazil and Honkong. It's manufacturing factory is located in Shenzhen, PR

[Freedos-user] "Test." -- does that come from FreeDOS?

I've been trying to update the BIOS on my wife's Dell Inspiron 17 5721 laptop using FreeDOS. I've tried to do this with FreeDOS 1.0, 1.1, 1.2, and 1.3rc2, each time with the same result. What happens is this: after setting up FreeDOS on a USB stick using its .img file (and adding the BIOS executab

Re: [Freedos-user] "Test." -- does that come from FreeDOS?

I suspected as much. Dell support, of course, runs and hides when it comes to any issue outside the Microsoft ecosystem. So, no joy there. Thanks for your time and prompt reply, Tom. On Mon, Jan 6, 2020 at 1:30 PM tom ehlert wrote: > Hallo Herr Jack Browning, > > am Montag, 6. Janua

[Freedos-user] Command Line Parsing

I've noticed a difference in command line parsing between FreeDOS and PC-DOS. Both FreeDOS and PC-DOS put the command line, starting with the character after the executable, in a buffer at offset 0x80 in the PSP. The behavior difference I see with FreeDOS is if the first non-blank character aft

Re: [Freedos-user] Help Using FreeDOS1.1

At 08:46 AM 7/11/2014, panyong wrote: Hi, I  installed FreeDOS1.1 on Parallels , and i want to install some software on the list http://www.freedos.org/software/ I¡¯ve tried to use a browser , but there is no on freedos . I've  also tried using the usb-flash-disk to share a file , but i fail ag

Re: [Freedos-user] On to FreeDOS 2.0...

Nick Warren wrote: > You know what would be really awesome in FreeDOS? multitasking. There > are no open source multitaskers for DOS. They used to have some programs > that did that a long time ago, but they were all proprietary. When I say > "multitasking", I don't mean "task switching" like in

<    1   2   3   >