Re: [Freedos-user] Command succeeded
On Thu, 03 Jun 2021 01:44:01 +0200, Bryan Kilgallin wrote: > "The command didn't complete.", or "The command hung.". No, hang means stop in the middle, so typically it would not then complete. > "or it might complete unsuccessfully (disk is not usable)." > "The command failed." Well, you can say "fail" = "not complete successfully" and be done with it, but then you cannot distinguish between the cases I mentioned (and lots of others also presumably). /Tomas ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Command succeeded
On Wed, Jun 2, 2021 at 7:45 PM Bryan Kilgallin wrote: > > > Something like formatting a disk might not complete (eg hardware > > error) > "The command didn't complete.", or "The command hung.". > > "or it might complete unsuccessfully (disk is not usable)." > "The command failed." If the command returns a status code at all (and as I recall, some DOS programs didn't), the return code would be 0 for normal completion and 1 for anything else. Some commands (on *nix*, at least,) will return codes greater than 1 to give a better idea of *what* anything else was..But what gets returned will vary by program. There is no overall cross platform standard I am aware of for return codes to be adhered to.. *Wanting* more meaningful error messages is one thing. Being able to *get* them is another matter. I would not hold my breath. __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Command succeeded
Tomas: Something like formatting a disk might not complete (eg hardware error) "The command didn't complete.", or "The command hung.". "or it might complete unsuccessfully (disk is not usable)." "The command failed." -- members.iinet.net.au/~kilgallin/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Command succeeded
(This is probably not the right forum for this, but whatever.) On Thu, 03 Jun 2021 00:22:03 +0200, Bryan Kilgallin wrote: > I read "The command completed successfully." This seems to me > programmer-speak, and verbose. Why not simplify that to "The command > succeeded."? Because it might be a lengthy procedure, and it might run to completion without succeeding. Something like formatting a disk might not complete (eg hardware error) or it might complete unsuccessfully (disk is not usable). /Tomas ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Command succeeded
I read "The command completed successfully." This seems to me programmer-speak, and verbose. Why not simplify that to "The command succeeded."? -- members.iinet.net.au/~kilgallin/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Fwd: FreeDOS make better compatibility with DOS games [current status]
Thanks for the info. I will test more combinations and get back. Yes, I have seen the reboot commands, so it should be fine. I try restart after leaving the app, simply from command line. None of the apps provide any docs that they would require OAKCDROM. I guess it will work with other Windows CD drivers as well. I can test more. I guess it will use some native calls to read a specific sectors on a CD. Perhaps somewhere in the header of the disc. Some combination of bit mangling and on UDVD2 it will perhaps throw some exception or return empty data. I don't know if the missing cd error is that the drive is being not detected by this app or that reading specific sectors returns some error. I hear floppy A seek, then it finds the CD drive, verify copy protection and run the app. Even I downloaded Mass Destruction, some updated version for DosBox, it did not run and it did complain about this CD drive as well. Another point against DosBox: I have a second machine with 2x Voodoo 2 SLI. That is very interesting. I did compare Glide wrappers for DosBox and also native OpenGL Geforce renderer in Quake 2 versus native Voodoo Glide. It is strange, but on Voodoo 2 native it looks much better. There is something about the texture filtering. On Geforce everything looks too much sharp. On Voodoo 2, the more far the scene is, the more it is blur. So some wall too far is mory blurry, which quite interesting, it makes it more nice and realistic. It works like some lense in VR. These imperfections make it look more appealing, but it might be subjective. Even DosBox glide wrapper cannot achieve this and it simply redirects OpenGL calls, which results that Geforce will render everything too sharp, like a software renderer. First time in my life I have 5.25'' floppy drive and Voodoo 2. So I enjoy it. I have a job, family and finally can afford the stuff I could not when I was a kid :-). For some kids, who started on Pentium 3, for them DosBox might be fine. But for someone who spent most of his life with 486DX2, 486DX4 and Pentium 1 133Mhz, DosBox does not yield the results that would immersively take me into the game. Also adventure games with Roland SoundCanvas SC-55 (MT-32) sound completely different. I know there are some SF SoundFonts you can load inside DosBox and use some virtual synth to play it, but it is just too much of stuff to set up and too many options and too many different soundfonts versions mixed with Roland+Korg. On long winter nights, I can analyze the differences. But having the real box, you just connect cable and go. That's what I like. Connect cable, hit button, done. Lukas On Wed, Jun 2, 2021 at 4:05 PM Eric Auer wrote: > > Hi Lukas, > > Glad to hear that you found a solution for copy protected games! > I assume none explicitly demanded OAKCDROM? What do the docs say? > > The question will be what exactly OAKCDROM does better than UDVD2, > regarding copy protected games. Not easy to say with closed source. > > But good to know that SHSUCDX works equally well as MSCDEX. > > I think DOS32A generally works better than old DOS4GW these days. > > > Now I need to solve Terminator 2029 from floppy, which gives JEMMEX > > exception. I guess it just needs more memory or something. > > Probably not. Simply try without JEMMEX, only loading HIMEM. > Background info: JEMMEX is HIMEM and EMM386 combined, while > JEMM386 is just EMM386. Most games only need HIMEM, so you > would use neither JEMMEX nor JEMM386. You can also try XMGR, > which is another alternative to HIMEM, if our HIMEM is not > what Terminator 2029 wants. > > Regarding the DN2 problems: Would you say DOSZIP is better? > > > http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/doszip.html > > DOSZIP is also available on our FreeDOS CD, of course. > > > crash exception in DOS32A: warning (9003): real mode interrupt vector > > has been modified: INT 23h. And you will end up in command line. > > That is not necessarily a crash, but a warning about unclean > exit of apps. Many apps even show it for intentional exists. > > > Restarting with CTRL+ALT+DEL a.k.a. WARMBOOT according to your FDAUTO.BAT > > works only sometimes. Mostly after some DOS32A app changing the interrupt > > You mean WHILE you are in DOS32A apps? Or after you leave them? > Does this happen with JEMMEX, JEMM386 or without any EMM386? > > If it only happens with the two EMM386 variants, there are some > command line options for those to influence the reboot strategy. > > Regards, Eric > > > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Fwd: FreeDOS make better compatibility with DOS games [current status]
Hi Lukas, Glad to hear that you found a solution for copy protected games! I assume none explicitly demanded OAKCDROM? What do the docs say? The question will be what exactly OAKCDROM does better than UDVD2, regarding copy protected games. Not easy to say with closed source. But good to know that SHSUCDX works equally well as MSCDEX. I think DOS32A generally works better than old DOS4GW these days. > Now I need to solve Terminator 2029 from floppy, which gives JEMMEX > exception. I guess it just needs more memory or something. Probably not. Simply try without JEMMEX, only loading HIMEM. Background info: JEMMEX is HIMEM and EMM386 combined, while JEMM386 is just EMM386. Most games only need HIMEM, so you would use neither JEMMEX nor JEMM386. You can also try XMGR, which is another alternative to HIMEM, if our HIMEM is not what Terminator 2029 wants. Regarding the DN2 problems: Would you say DOSZIP is better? http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/doszip.html DOSZIP is also available on our FreeDOS CD, of course. > crash exception in DOS32A: warning (9003): real mode interrupt vector > has been modified: INT 23h. And you will end up in command line. That is not necessarily a crash, but a warning about unclean exit of apps. Many apps even show it for intentional exists. > Restarting with CTRL+ALT+DEL a.k.a. WARMBOOT according to your FDAUTO.BAT > works only sometimes. Mostly after some DOS32A app changing the interrupt You mean WHILE you are in DOS32A apps? Or after you leave them? Does this happen with JEMMEX, JEMM386 or without any EMM386? If it only happens with the two EMM386 variants, there are some command line options for those to influence the reboot strategy. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Fwd: FreeDOS make better compatibility with DOS games [current status]
Hi, I got it fixed in FreeDOS! Thanks for explaining the level 1 and level 2 drivers. It helped me. The floppy disc of Windows 98 contains about 4 different CD-ROM drivers. I went with the first oneL OAKCDROM.SYS These are the results: 1) UDVD2 + SHSUCDX = NOT WORKING 2) OAKCDROM + SHSUCDX = WORKING 3) OAKCDROM + MSCDEX = WORKING 4) UDVD2 + MSCDEX = NOT WORKING Regarding FreeDOS installation. I don't remember exactly. The floppy loads the installation manager and then comply something about cannot install on that drive. Even I tried fdisk. I tried to not create any partition. Then I tried to create one primary partition. Then I tried to format partition as FAT32. None of these did help and the installer complain every time. With CD version, it worked out well. Perhaps for CD version I need to download different floppy - I think you have some FreeDOS boot only floppy without installer. I was not able to break the installer with F4 or F8 keys and go straight to console to run CD installation. That would come in handy. So regarding the Mass Destruction game: replacing CD driver is mandatory, but not enough. The original DOS4GW will then complain that it cannot find some file on HDD. Replacing it by DOS32A is the ultimate solution, where everything is working. Remaining bugs: BUG 1) Now I need to solve Terminator 2029 from floppy, which gives JEMMEX exception. I guess it just needs more memory or something. I'm going to retest in Windows 95 DOS mode as well. There are some additional JEMMEX exceptions that need to be solved and are also pointed out in Phil's video. For example Wing Commander or Bioforge. I remember with Bioforge I need tweak my config.sys a lot and make a lot of free memory. But if JEMMEX exceptions tend to happen often, maybe I would need to replace it with some MS-DOS alternative as well. I don't remember if it was HIMEM.SYS or some other file. BUG 2) There are some other things like Dos Navigator (DN2). It is often very slow when switching between shell apps and dos navigator. Norton Commander is much faster. For example editing file in DN2 and saving it will result in crash exception in DOS32A: warning (9003): real mode interrupt vector has been modified: INT 23h. And you will end up in command line. BUG 3) Restarting with CTRL+ALT+DEL a.k.a. WARMBOOT according to your FDAUTO.BAT works only sometimes. Mostly after some DOS32A app changing the interrupt vector, it will make machine unable to restart. Pressing CTRL ALT DEL will result in black screen and hangup. Need to restart using physical RESET button. But this CD-ROM driver was the most significant for me. I'm very happy I found a solution. Thanks to everyone for your time and interest! I can give FreeDOS a bigger chance now :-). I should record some video and prove to others that gaming in FreeDOS is possible, with small one liner fix. Lukas On Wed, Jun 2, 2021 at 2:20 PM Eric Auer wrote: > > Hi! Forwarding a message from Lukas, accidentally sent only to me. > > To already reply to his points: It is a common problem that 486 can > not boot from CD-ROM, but we provide a boot floppy image with the > right drivers to boot your 486 and then start our CD installer :-) > > Note that our installer expects FreeDOS command.com, not others, > as it uses some extended functionality from that. > > You write that you have tried our floppy, but ran into other bugs: > Please explain which bugs you saw. I think Jerome would tell you > to switch to advanced mode while inside the installer to avoid the > bugs, but without knowing WHICH bugs, I cannot say for sure. > > Lukas, please keep us posted about the CD-ROM based games and the > drivers which they do or do not like, e.g. UDVD2, SHSUCDX, JEMM386 > (but remember: the best EMM386 version often is the one which you > do not load at all, unless the game really needs to use EMS). You > can also compare XMGR to HIMEM if any game would dislike our HIMEM, > or use our HIMEM command line options to limit RAM. Some games are > known to fail if they see more than 31 MB of XMS2: /X2MAX32 helps. > > What exactly made DOSBOX bad in playing your 486 games, by the way? > > That OSSC - http://junkerhq.net/xrgb/index.php?title=OSSC - really > is fancy! It upscales SCART, Component or VGA input to HDMI or DVI > using small fractional N/M scaling factors in HARDWARE (an Altera > Cyclone IV FPGA, DVI out chip, analogue I/O chip, CPU/SoC, 110 EUR) > https://videogameperfection.com/products/open-source-scan-converter/ > Common modes seem to be deinterlace and multiplying lines by 2 to 5. > > Of course running 320x240 games on 4k screens is a bit strange, you > have to turn every retro pixel into 108 ultra high resolution ones, > but for those who happen to have 4k screens with bad built-in scalers > it still is a very elegant solution. You should ASK the DOSBOX people > to implement the scaling algorithm of your choice instead of just > telling US how bad DOSBOX looks according to your taste. > > You say you
[Freedos-user] Fwd: FreeDOS make better compatibility with DOS games [current status]
Hi! Forwarding a message from Lukas, accidentally sent only to me. To already reply to his points: It is a common problem that 486 can not boot from CD-ROM, but we provide a boot floppy image with the right drivers to boot your 486 and then start our CD installer :-) Note that our installer expects FreeDOS command.com, not others, as it uses some extended functionality from that. You write that you have tried our floppy, but ran into other bugs: Please explain which bugs you saw. I think Jerome would tell you to switch to advanced mode while inside the installer to avoid the bugs, but without knowing WHICH bugs, I cannot say for sure. Lukas, please keep us posted about the CD-ROM based games and the drivers which they do or do not like, e.g. UDVD2, SHSUCDX, JEMM386 (but remember: the best EMM386 version often is the one which you do not load at all, unless the game really needs to use EMS). You can also compare XMGR to HIMEM if any game would dislike our HIMEM, or use our HIMEM command line options to limit RAM. Some games are known to fail if they see more than 31 MB of XMS2: /X2MAX32 helps. What exactly made DOSBOX bad in playing your 486 games, by the way? That OSSC - http://junkerhq.net/xrgb/index.php?title=OSSC - really is fancy! It upscales SCART, Component or VGA input to HDMI or DVI using small fractional N/M scaling factors in HARDWARE (an Altera Cyclone IV FPGA, DVI out chip, analogue I/O chip, CPU/SoC, 110 EUR) https://videogameperfection.com/products/open-source-scan-converter/ Common modes seem to be deinterlace and multiplying lines by 2 to 5. Of course running 320x240 games on 4k screens is a bit strange, you have to turn every retro pixel into 108 ultra high resolution ones, but for those who happen to have 4k screens with bad built-in scalers it still is a very elegant solution. You should ASK the DOSBOX people to implement the scaling algorithm of your choice instead of just telling US how bad DOSBOX looks according to your taste. You say you dislike having to reconfigure DOSBOX for each game: In Linux, there is Plays on Linux which automatically uses a collection of optimized configs and dependencies for your Windows games in Wine, so I imagine something similar would exist for DOSBOX and DOS games? Regards, Eric @Jerome: The installer will fail somewhere at the end, like 99% or 100%. Even with BASE install. It will say that it failed to copy some package on the drive. Another use case: adding 10 packages from 5 categories in already installed FreeDOS system -> you will get runtime error / out of memory on 486. My previous e-mail without photo: Hi, yes I did use Win 98 floppy. That found my CD-ROM, which is connected to onboard IDE, not to soundcard. Just 486 BIOS did not know CDROM / ATAPI back then. I tried even FreeDOS floppies, but it goes straight to the installer and that installer has some other issues. So that's why I ended with Win98 floppy + FreeDOS CD. But it is impossible to install it on 486. I had to do it on Pentium machine. Today I am experimenting with FreeDOS drivers. Regarding the CDROM drivers, I did not try MS-DOS 6.22 yet. Only MS-DOS 7.1 from Windows 95 and Windows 98. There are some cdrom drivers out of the box that MSCDEX will find the drive. I have plenty of CD and DVD roms. From oldschool NEC, through LG, to Pioneer and Plextor. I have even some installation disks with drivers for these units. So this should be easy to fix. You know, every review is a little bit biased. Yes, a lot of classic DOS games do run in FreeDOS. But only classic DOS games without CD-ROM. If I would make this kind of review, it would be biased towards opposite direction because the percentage of games I have that is not working is much higher. So Arkanoid II on 5.25'' works :-). But Mass Destruction on CD does not work. On the same configuration, with different OS, it works as well. So I'm going to figure out why is that. I tried DOSBOX on my Windows 10 machine. I did not like it at all. Because I played these games on 486 like 10 hours every day. I remember it was not like this. That was the point when I decided to invest hundreds of dollars into retro stuff. DosBox will scale the graphics in a wrong way. It is always like 1024x768 then it will upscale to 4K HDMI display. On the other hand OSSC, the FPGA unit, will scale it naturally. You can even add scanlines for more CRT feel. Sometimes DosBox will feature some GoG update, which will "update" the game to 16:9 instead of the original 4:3. That completely destroys the aspect ratio. For example Jazz JackRabbit does this. So I don't get the feel that I would enjoy playing in DosBox. For a lot of stuff, you need to change dosbox config game by game. For example if you use external MPU-401 device such as Roland SC-55. So instead of messing with hardware, you start messing with software. And as it is my daily job, I want to get rid of it. Also you have the distractions of the internet and notifications. When I boot my
Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]
Hi Jerome, if FDIMPLES is specifically used in advanced mode, where more data has to be processed, I would suggest to consider automatically enabling support for XMS when XMS is found. Do you say that the amount of required RAM does not depend on the number of packages, but on the size of the largest ZIP? How? > FDIMPLES was really only designed to modify the package > list for advanced mode installs. All the the other stuff > it does and restrictions that were added came later. > It’s really not designed to do that. > It really needs to just be redone. That sounds tedious. But please explain in more detail. > What OS let’s you boot a different OS to perform your install? I generally agree, but it is easier for people who do not know how to use a disk image to make our boot floppy, or are simply too lazy because they assume DOS is DOS which may seem plausible. Maybe the installer could test if it runs on FreeCOM and abort with a complaint if it is not? Should be easy enough for users to start FreeCOM and not worth the effort to automate that. And as you say, if people load FreeCOM on top of another shell, maybe even without having XMS drivers, it will severely limit free RAM, so they better update their config and reboot again. Do you require any other FreeDOS specific things apart from FreeCOM? I assume you require working XMS and CD-ROM drivers, but not much else, so people could use other DOS boot disks at their own risk. A good example would be that they already have some DOS on their harddisk and know how to configure it, so they want to use that to run our CD installer manually. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]
Hi Eric, > On Jun 2, 2021, at 6:33 AM, Eric Auer wrote: > > > Hi Jerome, > > thanks for the explanation, but are we talking about DOS > RAM (at most 640 kB) here? Or EMS, XMS, protected mode? FDIMPLES and FDINST are both made for 8086. FDIMPLES is limited to only using low memory (640k). I believe FDINST is as well. But, you’d have to as Mateusz about that. In my opinion, since they both need to do everything they do on an 8086, there isn’t much point adding support for memory over 640k. > In FDIMPLES, FDINST of FDNPKG, and other involved apps? There aren’t any other programs directly involved. When running the FDIMPLES exe, it does everything except the actual install or removal of the individual packages. The OS installer is different. It does not normally use FDIMPLES at all. Package installation there is handles through batch logic, V8Power Tools and FDINST. However, when running the installer in advanced mode, it will run FDIMPLES in a special mode to modify the package list. That is then passed back to the installer and the process above is used. > > How much RAM do you recommend to be free? As much as possible to prevent problems with very large packages. > Could FDIMPLES > shrink before calling FDINST and grow back when it exits? Yes and no. FDIMPLES was really only designed to modify the package list for advanced mode installs. All the the other stuff it does and restrictions that were added came later. It’s really not designed to do that. It really needs to just be redone. > > Note that Lukas had been booting from a Win9x floppy to > run the CD installer, as his BIOS does not boot CD and > he did not use the special installer boot floppy either, > so I expect his context to be rather unusual for the > installer and wonder which parts are likely to fail in > that situation and what could be done to warn the users > or, better, to work with arbitrary DOS boot disks :-) First… What OS let’s you boot a different OS to perform your install? You don’t boot MS-DOS 5.0 and try to run the MS-DOS 6.22 installer. You don’t boot CentOS and try to install Ubuntu. That being said. The primary installer does what it can to try and do it. However, the installer requires FreeCOM. So, if you boot MA-DOS, FreeCOM is loaded by the installer. This would really reduce the amount of free RAM. The installer itself and most of the utilities it uses can get by with fairly low amounts of free RAM. I don’t know off hand what the absolute minimum level of free RAM required for FDINST to be able to install all the packages in BASE or FULL. But, he didn’t say when it actually fails to install. Overall, I think the installer should just completely remove any support for installation under any OS other than FreeDOS. Permitting it under MS, PC or other DOS is rarely tested and probably flakey at best. > > Regards, Eric > > Jerome > > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]
Hello Tom, > On Jun 2, 2021, at 6:35 AM, tom ehlert wrote: > > Hallo Herr Jerome Shidel, > > am Mittwoch, 2. Juni 2021 um 02:39 schrieben Sie: > > > On Jun 1, 2021, at 11:10 AM, Eric Auer wrote: >>> >>> >>> Hi Lukas, >>> […] >>> said it is memory issue and solved also by installing FreeDOS on hard drive in Pentium machine. That's how I did it as well and it works. Even installing a lot of packages on 486, the fdimples will crash with out of memory while browsing packages tree and selecting many packages. >>> >>> That sounds as if FDIMPLES had too little DOS memory free? > >> It is related to memory. However, not really tied to how much free >> memory is available on his machine. > >> Like I’ve mentioned many times before… FDIMPLES is just a front end >> UI. Actual installation and removal of packages is done by FDINST (part of >> the FDNPKG package). > >> For the end user, this isn’t important. However to install some >> really big packages, FDINST requires a lot of low memory. This means >> FDIMPLES has to have a very small memory footprint. > >> FDIMPLES looks simple. However, it correlates multiple pieces of >> data. Something like as little as 1 up to about 8 different metadata >> files and a handful of other data points for each entry. > >> All of that is pulled through something that resembles a >> prioritized cache. As it runs out of memory, it discards less >> important data first then ever more important data until sufficient >> memory is available to complete its current task. > >> Basically with the extreme memory constraints placed on it. >> Sometimes, it gets stuck needing some low importance data and is >> forced to hold onto or keep recaching the same data. > >> Just having FDIMPLES reserve more RAM for itself would fix it. But, >> then insufficient memory would be available to FDINST to install some of the >> really big packages. > >> The current version of FDIMPLES improved this a lot. But, it still >> does happen far to often (like at all). I just need to find the time to >> completely resolve it. > >> With the little RAM it is permitted to consume, I’m often amazed it manages >> to work at all. > > given the fact that FDINST is some sort of glorified UNZIP, you need an > amazing > amount of words to describe the process. > > Tom > The occasional FDIMPLES out of memory crash is not a problem with FDINST itself. Just wanted to explain why the “easy-fix” of just letting it have a little more RAM to resolve the problem is not the best solution. I’d love to let it have more RAM. Not only does that fix this problem. But, it runs much faster while browsing the packages as well. > > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]
Hallo Herr Jerome Shidel, am Mittwoch, 2. Juni 2021 um 02:39 schrieben Sie: >> On Jun 1, 2021, at 11:10 AM, Eric Auer wrote: >> >> >> Hi Lukas, >> […] >> >>> said it is memory issue and solved also by installing FreeDOS on hard drive >>> in Pentium machine. That's how I did it as well and it works. Even >>> installing a lot of packages on 486, the fdimples will crash with out of >>> memory while browsing packages tree and selecting many packages. >> >> That sounds as if FDIMPLES had too little DOS memory free? > It is related to memory. However, not really tied to how much free > memory is available on his machine. > Like I’ve mentioned many times before… FDIMPLES is just a front end > UI. Actual installation and removal of packages is done by FDINST (part of > the FDNPKG package). > For the end user, this isn’t important. However to install some > really big packages, FDINST requires a lot of low memory. This means > FDIMPLES has to have a very small memory footprint. > FDIMPLES looks simple. However, it correlates multiple pieces of > data. Something like as little as 1 up to about 8 different metadata > files and a handful of other data points for each entry. > All of that is pulled through something that resembles a > prioritized cache. As it runs out of memory, it discards less > important data first then ever more important data until sufficient > memory is available to complete its current task. > Basically with the extreme memory constraints placed on it. > Sometimes, it gets stuck needing some low importance data and is > forced to hold onto or keep recaching the same data. > Just having FDIMPLES reserve more RAM for itself would fix it. But, > then insufficient memory would be available to FDINST to install some of the > really big packages. > The current version of FDIMPLES improved this a lot. But, it still > does happen far to often (like at all). I just need to find the time to > completely resolve it. > With the little RAM it is permitted to consume, I’m often amazed it manages > to work at all. given the fact that FDINST is some sort of glorified UNZIP, you need an amazing amount of words to describe the process. Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]
Hi Jerome, thanks for the explanation, but are we talking about DOS RAM (at most 640 kB) here? Or EMS, XMS, protected mode? In FDIMPLES, FDINST of FDNPKG, and other involved apps? How much RAM do you recommend to be free? Could FDIMPLES shrink before calling FDINST and grow back when it exits? Note that Lukas had been booting from a Win9x floppy to run the CD installer, as his BIOS does not boot CD and he did not use the special installer boot floppy either, so I expect his context to be rather unusual for the installer and wonder which parts are likely to fail in that situation and what could be done to warn the users or, better, to work with arbitrary DOS boot disks :-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]
> You see how many subscribers and views Phil has. it's always kind to not only mention 'Phil', but be more specific like "go to Youtube.com, search FreeDOS 1.2 Review - Can it replace MS DOS for retro gaming?" or even give the link directly. https://www.youtube.com/watch?v=zGmCVeAKR4w otherwise you are just trolling. > There are others > like this on Youtube. Everyone from time to time tries FreeDOS for > gaming hoping that this time it will be more modern and efficient > solution for this type of use. Every discussion ends that it does > not work and it is not worth it. And I think end of our discussion will be > similar. if you would watch the video yourself, you would learn that MANY games work right out of the box, and most others work after replacing some files (mostly UDVD2.SYS) with updated versions and skipping EMM386. I'm not sure what you are so loudly complaining about. yes, Phil is right to complain that FreeDOS doesn't distribute some updated components after several years of existence. but that's an entirely different story. Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]
> A lot of games I tried with JEMM386/JEMMEX had some really jarring > issues. They varied from the game gracefully crashing to outright raping > my ears or gradually eroding FAT away. FreeDOS' own FAT repair tools > couldn't help me. Only nuking everything and re-installing and > re-configuring everything. At this point I've included a special GRUB > entry that uses a Linux distro coupled with a custom init script to fix > my FDOS partition. I lost a lot of time and mental wellbeing on these did you ever hear about the concept of BACKUP/RESTORE? Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS make better compatibility with DOS games [current status]
On 01/06/2021 23:55, Lukas Satin wrote: The driver VIDECDD is not working at all. It will not find my CD-ROM drive. Perhaps because 486 bios cannot find the CDROM. But driver such as MSCDEX or SHSUCDX will find the drive. Hi Lukas, MSCDEX/SHSUCDX are not really drivers, they are only a subsystem that talks to the actual driver and presents a "network-like" filesystem to the DOS kernel. Back in the day, each CDROM drive came with a floppy that contained a DOS driver. This DOS driver had to be loaded (via config.sys), and only then MSCDEX (or SHSUCDX) could find it. I think you said earlier that your setup works fine with MSDOS - then perhaps you could use the same driver on FreeDOS, instead of the universal UDVD? MS-DOS does not come with a CDROM driver at all, so I do not know where you obtained your driver from. As for EMM386/JEMM386 - simply do not use it. It is always cleaner to run in real mode anyway. The only difference is that you won't be able to run games that require EMS memory, but I am not sure there are really many games that require EMS memory, usually games are able to use either EMS or XMS, depending on what's available. Finally, if you look for a more basic FreeDOS system, you might want to test SvarDOS. It is a FreeDOS distribution that aims for minimalism and 8086 compatibility, I'd be curious to know how it runs on your "difficult" setup. Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
