Re: [Freedos-user] Problem with running FreeDOS on HP Compaq 6720s
get a copy of darik's boot and nuke and erase the hard disk, single pass, no verification. when loading the cd, use only the xms option, NO EMM386! then xfdisk the disk using the default choices, except when it comes to write the partition table, then choose yes. then format the disk using the format command. then try to install it (freedos) again. this has always worked for me. i must add, though, do these steps exactly right, else the whole implementation is broken and you'll have to start over again. you can write me direct if you like, my email appears below. the problem is not insurmountable, it's common with v1.0, and 1.1_test3.iso cd works better at installing system. you can add the other stuff from the 1.0 implementation later. eufdp...@yahoo.com eufdp...@yahoo.com eufdp...@yahoo.com eufdp...@yahoo.com eufdp...@yahoo.com From: Anton Vernigor smm...@gmail.com To: freedos-user@lists.sourceforge.net Sent: Tuesday, October 18, 2011 5:00 PM Subject: [Freedos-user] Problem with running FreeDOS on HP Compaq 6720s Dear all! I’m trying to install FreeDOS (fdbasecd.iso) on a real (not virtual) machine for the first time, and I’ve met some problems. At first I couldn’t install FreeDOS at all, despite it was installed on VirtualBox flawlessly. Installation went well, no errors or warnings, and after the final reboot I got blank black screen with no reaction to any input, only power button could help. It seems it was fixed with another options used while partitioning the disc, but I’m not sure what certain option did the job. But after all I still see some strange behavior in just installed system. If I choose default second option in startup menu (Load freeDOS with EMM386+EMS and SHARE), the screen gets filled with error message, and I still see no reaction on keyboard or trackpad. Screen looks like this. Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: Bad or missing command interpreter: ÉÉÉ Enter the full shell command line: The other strange thing is that first (Load FreeDOS with EMM386, no EMS (most UMBs), max RAM free) or third (Load FreeDOS including HIMEM XMS-memory driver) option in startup menu works normally, as I see (not investigated seriously, but at least it looks so). Fourth option can’t be chosen at all. So as I’m new to this kind of OS I ask where can I read about this problem with second menu option and how can I try to fix it, if it’s possible? Just for now I’ve edited fdconfig.sys to hide menu and use the third option by default, but it doesn’t look like a good solution. What kind of hardware info may be helpful for solving this problem? Thanks! -- 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 -- 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
Re: [Freedos-user] Problem with running FreeDOS on HP Compaq 6720s
Em 18-10-2011 22:34, Rugxulo escreveu: On Tue, Oct 18, 2011 at 5:56 PM, Alain Mouetteala...@pobox.com wrote: Em 18-10-2011 20:33, Rugxulo escreveu: BTW, call me naive, but does that above line even give you any UMB space?? If not (and NOEMS), why use EMM386 at all?? (Just use XMS.) :-/ Other things did not work anly with XMS, among other things emm386 puts the machine in protected mode, this helped something... Eh? That would be weird. Hmmm, now that I think about it, I think CWSDPMI (and/or other DPMI hosts) can't handle fragmented XMS (or hog it all for themselves), so shelled out apps don't have anything to use. Perhaps you're relying on that? In that case, yes, the 4 kb pages help, oddly enough. Otherwise it's not so recommended (esp. since EMS isn't as widely used in most modern DOS apps), as you probably already know, esp. regarding DPMI 1.0 extensions and CWSDPMI r7. And es, you are right, it gave me no UMB, which in that situation is just a minor annoyance. My program is 32 bits so it does not need much lower memory. DJGPP, perhaps? If OpenWatcom, you could (should) try a different extender (DOS/32A or Causeway). I use OpenWatcom, with Causeway. I tried WDOSX and DOS4G but they were not as relyable as Causeway. I guess UMBPCI is out of the question?? Completly, it is hardware dependant and does not behave well on unknown hardware. I tried but could not find a range to exclude that worked and would leave me some UMB :( I find that hard to believe. Basicaly due to lack of time. It was kind of a emergency rescue... But luckily FreeDOS is pretty efficient anyways (at least with XMS available). :) Alain -- 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.
Hi Jack, First of all, let me clear one MISSUNDERSTANDING... The EMM386 that works ok is from Michel Devore, which was extensevely tested by the members of FreeDOS. Most of your answer regards GatesCo product, sory for the confusion About the A20 issue. I used it because I had a very stange 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 adain from the disk. That never happend to me and is completely unheard of... Alain Em 18-10-2011 23:25, Jack escreveu: 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 -- 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.
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.
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, FD-EMM386 is very outdated, yes. But when it was still maintained, updates were often tested by a number of users. With JEMM, it is more like here is an update, enjoy. 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... Thanks for taking the time to read the changelog, can you give some examples of bad FD-EMM386 bugs which were fixed by JEMM? Of course there are zero JEMM bugs fixed by FD-EMM386, but that does not mean that JEMM is by definition free of bugs. I do believe Alain when he says that he did have data loss with the latter - which may not be due to bugs at all, maybe it is just that JEMM makes it easier for the users to shoot their own foot. Which is why I still think that FD-EMM386 also has some pretty nice sides. Even though I would NOT recommend to upgrade to a 5 year old FD-EMM386 for THAT reason. Eric -- 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.
Hi Jack, Bret, Japheth, Alain, others, 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 Nobody suggested to use the EMM386 by MS... By the way, MS does have a lovely little I/O virtualization API which might be much weaker than JEMM VLM, but would still be very welcome for certain drivers. I think the Bret Johnson USB drivers for example could do cool things if JEMM supported that API :-) 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! Examples please - it does not help when Alain says that his customers have burning computers with JEMM and you say you get nightmares from FD-EMM386... There must be something in which BOTH Alain and you are right, and finding that would help to convince Alain to trust JEMM and help to improve it. Because really, I do doubt that JEMM already is perfect... 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 How can JEMM retain code from MS EMM, I would rather assume it retains FD-EMM code? 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 :-! 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... 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. 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... Also, I think some BIOSes give you A20 DISABLED at boot, so ignoring / not touching it at all would not be a very useful choice for most DOS users... In short, I would be happy about a force-on A20 method. (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. XMGR doesn't handle the usually-ignored BIOS calls, any of What makes you think they are usually ignored? Would the BIOS not at least ANNOUNCE that they are ignored, detection-wise? 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 :-) So, why don't we just leave current A20 handling as-is?? See above. Or maybe the KERNEL could do part of the work: Ask the XMS driver to switch ON the A20 as soon as the driver is loaded, but never ask the driver to switch the A20 OFF. Still other DOS apps or drivers MIGHT come up with the bad idea to ask the XMS driver to switch off the A20 again after use... 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!! Depends... 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. This is also useful in the context of BIOSes doing a bad job in implementing 8042 / keyboard style handling of real, PS/2 and USB keyboards already, so for cases where I have to use the slow keyboard-port style A20 method, I would prefer to at least only touch that A20 ONCE. For example if there was a 0.5% chance that USB and/or A20 crash at switching, either in general or after you load DOS USB drivers or whatever. While port 92 A20 handling tends to be more foolproof, there is still another chance that a stupid BIOS messes up when an A20 switch happens at the wrong moment. As said, I say that some people would sleep better when they could tell the XMS driver and/or DOS to switch A20 on and then leave it on :-) Regards, Eric
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Eric, FD-EMM386 is very outdated, yes. But when it was still maintained, updates were often tested by a number of users. With JEMM, it is more like here is an update, enjoy. I can sympathize with Japheth re: testing JEMM, as I have the same problem testing UIDE: Very FEW who DESIRE to test our drivers!! I have reviewed Japheth's Changelog, I believe much of what he had to do changing FD-EMM386 to JEMM386 are Flat-Ass DISASTERS [in FD-EMM386] and I shall continue to AVOID using FD-EMM386... Thanks for taking the time to read the changelog, can you give some examples of bad FD-EMM386 bugs which were fixed by JEMM? Ask, and Ye shall receive!, from the ChangeLog on the JEMM page at www.japheth.de -- 03/27/2007 bugfix: free EMS pages not always reported correctly. bugfix: translation DMA for 16-bit controller (channels 4-7) didn't work. 03/02/2007 bugfix: XMS function 11h (free UMB) always returned an error. 10/07/2006 bugfix: allocating a EMS block with zero pages (int 67h, ah=5Ah, bx=0) returned with AH=0, but did not return a valid DX handle. 09/30/2006 bugfix: VDS functions 03, 04, 07 and 08 may have failed if bit 1 of DX was set (request to copy in/out of DMA buffer) and registers BX,CX were 0. bugfix: 1 kB of DMA buffer may have been inaccessible. bugfix: releasing a DMA buffer of size 1 kB always failed. 09/06/2006 bugfix: writing to ROM page FF000 if ALTBOOT wasn't set caused a crash. 08/25/2006 bugfix: unsupported VDS functions caused a debug display, which didn't work and may have caused corruption of monitor data. 08/23/2006 bugfix: DMA buffer is ensured to begin on a 64 kB physical address boundary. 08/17/2006 bugfix: in VCPI protected mode entry switch to host stack before context is switched. Note that all of the bugfix items listed above are not-long after the final update for FD-EMM386, meaning that Japheth likely inherited them, from his predecessors. So, FD-EMM386 cannot (A) handle a VCPI switch, (B) has DMA-buffer address problems, (C) has VDS function-call problems and (D) has EMS-page problems!! Are those enough examples for you??!! Of course there are zero JEMM bugs fixed by FD-EMM386, but that does not mean that JEMM is by definition free of bugs. Nor can I expect my own XMGR or UIDE to be by definition free of bugs since I am not God! Bugs are a fact of life with software, but what need NOT be a fact is how so many do so little to FIX their bugs!! I do believe Alain when he says that he did have data loss with the latter - which may not be due to bugs at all, maybe it is just that JEMM makes it easier for the users to shoot their own foot. Then why, Eric, does FreeDOS have JEMM/HIMEMX in its Base Software list?? Your comment disparages the very system you support!! ... I absolutely REFUSE using old EMM386 by Gates Co. ... Nobody suggested to use the EMM386 by MS ... Glad to hear THAT, since neither do I!! ... I also want NOTHING to do with FD-EMM386 and anyone who wonders why can read the Revision Notes for JEMM386 ... Examples please ... See above, or read the JEMM ChangeLog yourself if you want more. ... It does not help when Alain says that his customers have burning computers with JEMM and you say you get nightmares from FD-EMM386 ... There must be something in which BOTH Alain and you are right, and finding that would help to convince Alain to trust JEMM and help to improve it. I get NO nightmares from FD-EMM386, since I have never USED it! On working to improve JEMM386, I like it as-is, I trust Japheth to make it better using HIS judgement, and I admit to NOT being enough of a protected-mode programmer to test it properly. We are all specialists in software, and my specialty is device drivers and caching, not protected-mode! 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 How can JEMM retain code from MS EMM, I would rather assume it retains FD-EMM code? Can't say what code JEMM retains or does-not retain. I only said it retains all of EMM386's memory-dection logic, 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
