Re: [Freedos-user] UDVD2 drivers not starting on UTM MacOS - help needed
Hi Knedlik! If I assume that UTM is some sort of virtual environment and assume that either way, you primarily need CD/DVD access during install, which means after booting from the install CD/DVD itself, then I would recommend that you try using the ELTORITO driver instead. This uses generic BIOS support, while the UDVD2 driver is for IDE/ATAPI/SATA, which means that AHCI controllers are not natively controlled. On PC, you can try to configure them to SATA instead of AHCI mode, but maybe Mac OS, UEFI or EFI or UTM does not offer this choice? Regards, Eric I wanted to take a look again at FreeDOS, but when I install it using UTM on my MacBook Pro (Entry level M1), I’m not able to use the package manager due to UDVD2 and thus the entire CD-ROM system not working. If you have any ideas, help will be greatly appreciated. Thanks in advance, ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Writing date and time into log file
Hi! If you use the FreeCOM version of command.com which ships with FreeDOS, you could be able to use some magic extensions such as that option for SET which stores the output of a command in an environment variable, or some magic pre-defined environment variables, or DATE and TIME extensions, but I am away from my DOS setup, so I cannot look up the details. Maybe some experienced FreeCOM user can help out :-) Apart from that, 4DOS and the various little helpers mentioned in this thread already can help. Regards and a nice end of the year to everybody :-) Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ISO repack reduces size by 10%
Hi! Please describe that "normalizing" process which makes the source codes inside the distro packages behave like a solid archive. If you remove them from the ZIP and add a TAR of the sources to the ZIP instead, you would get that type of result, but it would mean that the install process will have to be modified significantly. Also, you would need temp storage for the TAR because DOS has fake pipes. 2,586,758,742 bytes, original total ZIP size 2,535,458,056 bytes, after `advzip -k -p -z -3 ` ... But normalizing the source code that is bundled in distro packages is where the big savings happen because it makes the most compressible part of the archive behave like a solid 7Z file. ... The advzip output is indeed compatible with both pkunzip-2.04g and pkunzip-2.50 running on a DOS machine with one megabyte of memory. The way AdvanceCOMP checks and retains metadata is satisfying. If you run advzip on the entire FreeDOS collection, then you'll notice a non-trivial number of malformed and/or corrupt ZIP files. You mean they were already malformed before you recompressed them? Can you provide a list of those damaged ZIP files to us? Thanks! Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Bootable FreeDOS CD for BIOS flashing
Hi! I think for BIOS flashing, a good way would be to start with a minimal boot floppy image, you can find that online for FreeDOS. Or use one with more apps on it and remove some of them to make space. Then, you mount or open the image with a free tool (depends on the OS, in Linux you can use mtools as user or actually mount the image if you are admin, as well as using any of various other methods) to add the BIOS flash tool and BIOS file to it. Next, you use the boot floppy image to make a CD or DVD bootable in emulation mode. Most BIOS variants support booting from 1.2, 1.44 and 2.88 MB floppy images and a variety of CD/DVD writing tools let you specify an image if you select that you want to make a bootable CD/DVD. The advantage is that you will not need any CD/DVD drivers which could interfere with the BIOS flash process, or any other drivers apart from those that the flash too might be needing. And of course keyboard drivers, if you like. For many cases, you can use the small MKEYB to cover popular layouts without needing additional data files. The disadvantage is that the booted DOS "floppy" will be read-only and that it will not have access to the rest of the CD unless you also put the CD drivers on the "floppy". You could probably also work with MEMDISK and a Linux style boot menu instead of the pure BIOS floppy image boot method. This will allow compressed floppy images and writing, but of course any changes will be lost as soon as you reboot the PC, because the floppy image is never updated by MEMDISK. Changes only exist in RAM. Also, MEMDISK again is a bit like a driver, so it can interfere with your flash tool. Of course, the best way would be to have a BIOS which supports loading a BIOS file from any connected drive's root directory, including USB sticks, without having to boot anything from those, but a BIOS which is too old to boot from USB will also be too old to have that feature. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] ISO repack reduces size by 10%
Hi Jerome and Darik, 1. Unzip each FDN package. 2. Further unpack each ZIP and 7Z source file. 3. Zip+Store each SOURCES/* tree like it has LFN. 4. Rezip each FDN package like usual. 5. Optimize each package with AdvanceCOMP. I suggest a much shorter algorithm: Simply apply advzip with the "recompress" option to the ZIP files :-) Without unpacking them and zipping them again etc. Also, the advcomp/advmame tools can be configured to put extreme effort in compression, but from my experience with advpng, you already get most of the possibe disk space reduction at medium settings :-) It is interesting that you also got savings with arj and bz2-zip, but ZIP in the DOS compatible variety (people with ancient PKZIP may enjoy the ability to unzip without having to use INFOZIP) I would not "overdo" things. Also, UNZIP can work on old hardware with low RAM, which LZMA or BZIP style algorithms do not necessarily offer. As far as I remember, there may have been a license issue behind not using RAR, but others may know more on that point. You can do mass-recompression of ZIP files with advzip with your favorite shell (BASH for example) so it does not take much effort to recompress the whole repository once. I propose to use ZIP -o on each file afterwards to reset the timestamps to the newest timestamp of the contents, though! Of course before this is done on the whole repo, somebody with PKUNZIP2 has to volunteer to tell us whether an example advzipped ZIP is still fully compatible. As far as I remember, this was one of the design goals of advcomp, so I am optimistic. About the diskette edition: One question probably is whether you want to use DOS from floppy or whether you want to install it to harddisk. In the latter case, you could just put everything into one tar or 7z with global (not per-file) compression applied to have the smallest number of install disks, but you would have less flexibility that way. And with floppy, it is better when a broken sector only lets installation of one of many zips fail instead of a whole install. However, I do not think that ANYBODY has drives with less than 360k capacity. In particular, the last time I touched a PC with 360k-only drives, it did not have any harddisk, so you would not need any type of installer to run there either. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] UHDD update! FDAPM update! Feedback please :-)
Hi Liam, very good point! Here is some background info on the tools :-) FDAPM is the FreeDOS answer to MS DOS "POWER EXE", so it can be a resident tool to help you to save energy and keep your CPU cool by reducing activity while DOS is idle. It also has features such as power off, reboot, suspend, throttle CPU speed etc. and a separate DPMS screen saver tool bundled. While a bit of APM, ACPI and low-level calls are supported, compatibility varies a lot so features depend on your luck. UHDD has two core features: It is a disk cache and a driver to accelerate data transfer for fixed disks (harddisks and SSD and similar). However, because it has been co-developed with the CD/DVD/etc. driver UDVD2, the latter is able to share the cache functionality of UHDD. This means if you use UDVD2 as CD/DVD driver and UHDD as harddisk cache, you additionally get the feature of having a CD/DVD cache :-) Contents of both CD/DVD and fixed disks will then share the same XMS memory for cache contents. Given that you can set the UHDD cache size to anything from a few megabytes to a few gigabytes of RAM, the cache is a lot more powerful than my classic LBACACHE which only supports fixed disks. Both caches also support floppy, by the way. While LBACACHE is only a cache, UHDD contains various other ingredients to speed up working with your fixed disks significantly :-) Note that I also have the classic CDRCACHE: Unlike Jack's UHDD, you can connect CDRCACHE between any low-level CD/DVD driver and any filesystem driver such as SHSUCDX or MSCDEX. So while CDRCACHE only allows small caches of at most a few dozen megabytes, it lets you add caching functionality to third party drivers such as ELTORITO or AHCICD: See https://rloewelectronics.com/ for AHCICD. I recommend to ship the FreeDOS distro with UHDD and UDVD2, as well as optionally ELTORITO and CDRCACHE, because caches help a lot to get a fast system and a fast install process in particular on real hardware. UDVD2 supports IDE ATAPI and classic SATA CD/DVD drives. For SATA in AHCI mode, you can use AHCICD, which is now free software with sources, but not yet under open source license. Sadly, the inventor is dead. His son set his legacy free. The ELTORITO driver is a small wrapper for BIOS-supported CD/DVD/... access: You can only use it for the very CD/DVD you have booted from and it has limited features, but it works for all CD/DVD drives from which you can boot. On many computers, you can set your SATA controllers to classic mode in BIOS setup and then use UDVD2 and UHDD together to get very efficient CD/DVD access, which is important because CD/DVD can take a long time to gather file contents in random access scenarios such as copying many small files around or running an installer. Without a cache, those drives are only fast for few, large files and watching or listening to large multimedia tracks etc. I hope this answers some questions :-) Thanks for testing! Regards, Eric I don't know if you realised, but you have mentioned UHDD several times without ever, that I have seen, saying what it is, what it is for, how it works or how to use it. I think you just assume everyone knows... ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] UHDD update! FDAPM update! Feedback please :-)
Hi! To add a bit of clarification: https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ellis/uhdd/2021-10-30/uhdd_2021-10-30.zip The updated UHDD is only 5 kB, the current UDVD2 is less than 4 kB. So the size difference compared to using only UIDE is very small now, with UIDE being 7 kB in size. However, UHDD has new features such as Read Ahead or DMA Caching Overlap, giving you extra speed compared to UIDE. So to get all features, it is best to use the powerful pair of UHDD and UDVD2 for your disk speed, CD/DVD/... and disk and CD/DVD cache needs. For the latter, make sure that UHDD is loaded first, so UDVD2 can detect the already active disk cache: This gives you one unified cache for all drives, both fixed (harddisk/SSD) and optical (CD/DVD etc.) with between a few MB and several GB of cache size - see the docs :-) Regards, Eric PS: Also check out RDISK and XMGR for small-in-memory RAMDISK and HIMEM (XMS/HMA) style drivers by Jack. It is often possible to have part of the drivers in HMA, further reducing DOS memory use. See the docs for more. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] fdbox version v0.0.1
Hi Diego,
I think Jim is just trying to encourage FDBOX to add features :-)
Tom is right that FDBOX as it is now is not yet really useful.
Why does it matter whether FreeCOM or FDBOX run on Windows,
Linux or Apple? You can run DOS on all of them, using either
a DOS emulator or a virtual PC which can boot FreeDOS :-)
Also, you can run powerful shells such as BASH on Windows,
Linux or Apple and each of the operating system already
ship with more powerful shells and file managers etc.
So if it is important for you that FDBOX runs on all major
operating systems, you suddenly get a lot more competition.
Powerful open source file managers and shells already have
been ported to the big operating systems, so it usually is
the DOS version which they are missing, not the Windows app.
This means there is less competition when it comes to cool
modern open source apps for DOS, while Windows users already
have everything they like.
As DJGPP already is one of the compilers you use, you may
want to write a DOS port of existing cool Linux apps. The
new MPXPLAY update would not exist without all the fancy
codec libraries from the Windows Linux open source world :-)
I appreciate that the code follows valgrind and clang :-)
As you already use cool busybox concepts, how about making
a DOS port of a recent version of busybox or minibox? :-)
If you love continous integration (automated compiles and
compatibility checks for each change upload) then you may
like contibuting to the DOSEMU2 project. The use that and
cross-compilation from Linux etc.
It has (will?) a better command line editor, history searching like
bash.
How well does it compete against 4DOS and, well, BASH?
You can pass arguments for commands after the file name ("del /f *.txt"
vs
"del *.txt /f"), you can add several files to all commands ("del 1.txt
2.txt *.tx1"). The "type" command can also print line numbers. The
"del"
command has the same functionality of "deltree". "copy" will display
progress on large commands. "ren" and "move" are effectively aliases on
this shell.
Sounds like reasonable additions to backport to FreeCOM under
the condition that it does not break MS DOS batch file syntax
compatibility. Some things may already be supported by FreeCOM
that you were not yet aware of? It tends to do more than MS DOS.
I don't understand, there is new software written for MSDOS/FreeDOS
and you are unhappy? ;-)
Developers for DOS are rare, so Tom may prefer improvements for
existing DOS software instead of first investing in the overhead
of creating completely new apps with similar target audiences?
Regards, Eric
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New MPXPLAY media player version
Hi! Forwarding from the BTTR forum - note that some source code still contains the following header, which could be problematic: "Please contact with the author (with me) if you want to use or modify this source." Also note that in the announcement quoted below, I have removed changes which only affect the Windows version. So depending on whether you use the DOS, Windows or other versions, you can get even more cool things by updating :-) I am not sure whether the DOS version also uses the new FFmpeg library. Either way, check out the update. Still plays audio even on AC97 and HDA in DOS :-) Regards, Eric http://mpxplay.sourceforge.net/ Mpxplay DOS console portable versions Mpxplay v1.66 DOS/32 October 24. 2021 with DOS32A extender (inc. TCPIP by SwsSock library) Mpxplay v1.66 DOS/4G October 24. 2021. with DOS4G v2.61 extender with DLL handling and TCPIP (ftp/http) Mpxplay is a commander-style console audio player for DOS and Win32 operating systems, developed in OpenWatcom C v1.9 AAC,AC3,AIF,APE,ASF/WMA,AVI,FLAC,FLV,MKV/WEBM,MP2,MP3,MP4/MOV,MPC,MPG/VOB, OGG,TS,WAV,W64,WV and CD player/ripper (with plugins: DTS,MOD,OPUS,SPX) for DOS operating system for SB Live/Audigy,CMI,ENS,ICH,IHDA,VIA,SB16,ESS,GUS,WSS and SB Pro compatible soundcards from PDSoft (Attila Padar, Hungary) diffs between v1.66 and v1.65 -modifications/new: -updated FFmpeg library from 4.3.1 to 4.4.0 -demultiplexing error and event handling (at stop, eof) (ffmpdemux.c, in_ffmpg.c) -crash if stream has not found in the file (ffmpstrm.c) -DVB: durations of programs if database is not up to date (no valid events) (using fix/fake 1 sec) (drv_dtv.c) -next file selection (ctrl-enter) is saved and restored by mpxtabs.ini (startup.c, mpxplay.c, playlist.c) -startup has a more precise play-status restoring (after exit from stop mode) (mpxplay.c) -http/dvb: streams are not (re)open at program (re)start or at skip in pause/stop mode (just selected as new/next file) (mpxplay.c, diskdriv.c, drv_dtv.c, drv_http.c) -DOS: added new PCI ids to Intel HDA soundcard driver (Intel CometLake/Alderlake chips) (sc_inthd.c) -bugfixes/modifications/general: -OGG: corrected metadata reading at large contents (eg: album art picture), editing of such OGG files is rejected (unsupported yet) (in_ogg.c, tagging.c) -OGG/Vorbis: close (dealloc) of incorrect streams (info.c, sharbook.c) -APE: decoder fixes to avoid crash at some files (unbitnew.c) -MKV: automatically ignore/skip unknown stream formats (select/play the supported one) at multiply audio streams (ff_mkv.c) -CDW (CD-A): added 10 sec timeout for read (to not drop read too early at CD spin up), better directory (CDW filelist) loading at FFmpeg, improved play stability (drv_cd.c) -more stable commander dialogs (eg: F3 + skip + ESC + playstart) (diskfile.c) -index editing (F4): additional range check (limit range to start of prev, end of next index entries) (fileinfo.c) -empty config strings loading (not reloading default values after clearing string-type config fields) (control.c) -buffer block size init at playing (starting with non enter key) (mpxinbuf.c) -ftp[es]: improved functionality and stability (drv_ftp.c, tcpcommon.c, dll_load.c) -termination (with ESC) of textfile load and (ssl) connection retry (diskdriv.c, tcpcommon.c) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] UHDD update! FDAPM update! Feedback please :-)
Hi everybody, while we got a lot of feedback about the malfunction of the monthly reminder mail, there has been almost none about the FDAPM and UHDD updates recently. So please check out those new driver versions and share your experiences :-) "Jack Ellis has released an updated UHDD driver. The new version uses mostly caching logic for noncached work, saving 650+ bytes! UHDD.SYS is now less than 5K, for "boot" diskettes etc. All UHDD features, switches and cache speeds remain unchanged. The "/B" noncached UHDD, not often used, is about 300 bytes larger than before. We've mirrored the new release on the FreeDOS files archive at Ibiblio, in the uhdd/2021-10-30/ directory. Thanks Jack!" https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ellis/uhdd/2021-10-30/uhdd_2021-10-30.zip This means you now get a very powerful driver while spending very little disk space. To underline the improvement, Jack has stopped working on UIDE: You can no longer use the excuse that UHDD plus UDVD2 would be too large, because they are no longer large and they clearly have more power than UIDE :-) Please add UHDD to the distro "base" category and move UIDE to the extra/bonus category, to keep UIDE only for reference. I guess https://www.bttr-software.de/forum/board_entry.php?id=18304 which is about compiling MPLAYER in DOS being slow should have used UHDD to make the process a lot faster ;-) About FDAPM, ECM writes: https://www.bttr-software.de/forum/board_entry.php?id=18399 Announcement - FDAPM extended I extended Eric's FDAPM some, mostly based on my TSR example. To quote the blurb on my website: The power savings utility for FreeDOS, originally by Eric Auer. Extended to use IISP headers, an AMIS multiplexer, and to provide the UNLOAD command, with the advanced deinstallation method. Note that I tweaked the TSR installation a bit, but I did not perform a total conversion to my optimal installation method. I also did not implement my TSR's option switches such as /N install new even if already installed) and /X= (try a specific AMIS multiplex number first). As is, it assumes that there is only ever one instance of the resident FDAPM. And the check for a resident program still uses the old POWER services on the traditional multiplex interrupt 2Fh. Only the newly added UNLOAD command searches for the resident using the Alternate Multiplex Interrupt 2Dh. The repo and a release file for download are available at https://pushbx.org/ecm/web/#projects-fdapm. (End of Announcement) I guess it woudl be cool to also extend FDAPM to support ACPI tables larger than 64k, by looking at overlapping 64k snippets, so in case ECM is reading this: Thank you for considering the idea in your next FDAPM update :-) Note that FDAPM does various things for POWER compatibility, but improved TSR load/unload support certainly has advantages, so thanks for the IISP / AMIS / UNLOAD stuff :-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Fwd: Extended FDAPM
Hi all, Jim noticed that ECM has extended FDAPM, which I was not aware of, so I suggest that you folks test this and provide feedback :-) The top item on my own FDAPM wishlist would have been to make it work with data structures > 64 kB, as far as I am concerned simply by working in overlapping chunks until all data got digested. Regards, Eric PS: Please also test UHDD. It is now so small that you have no excuses to use UIDE. Just use UHDD with UDVD2, much better :-) "Announcement - FDAPM extended" https://www.bttr-software.de/forum/forum_entry.php?id=18399 I extended Eric's FDAPM some, mostly based on my TSR example. To quote the blurb on my website: > The power savings utility for FreeDOS, originally by Eric Auer. Extended to use IISP headers, an AMIS multiplexer, and to provide the UNLOAD command, with the advanced deinstallation method. Note that I tweaked the TSR installation a bit, but I did not perform a total conversion to my optimal installation method. I also did not implement my TSR's option switches such as /N (install new even if already installed) and /X= (try a specific AMIS multiplex number first). As is, it assumes that there is only ever one instance of the resident FDAPM. And the check for a resident program still uses the old POWER services on the traditional multiplex interrupt 2Fh. Only the newly added UNLOAD command searches for the resident using the Alternate Multiplex Interrupt 2Dh. The repo and a release file for download are available at https://pushbx.org/ecm/web/#projects-fdapm. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
Hi! While this has nothing to do with MKEYB, Tom is absolutely right about command.com: The more common version of FreeCOM uses XMS to swap, which is faster and available on almost every computer of 2021 FreeDOS fans. But there also is the alternate KSSF style swapping without XMS, which works similar to your description of what MS DOS 3.3 did AND which has been available for years. I would not call KSSF experimental, I would just call it rarely used, because most users do have XMS drivers loaded :-) As you remember, I even suggested that our config / autoexec menu should make sure to load the non-XMS FreeCOM for the boot option "do not load XMS drivers" because that will make a big difference in how much memory is free for apps. For all other boot menu choices WITH XMS, the default FreeCOM with XMS swap of course remains the best choice :-) Also, to get back to MKEYB: It is tiny both in RAM and on disk and the lack of support for automated codepage magic is perfectly okay for me. As said, I could simply write a small batch script to load MKEYB along with the proper font for codepage switches and you can simply unload MKEYB without a reboot, so this even works on the fly. But as mentioned, it is good to have choice, so people are of course welcome to use the full featured FreeDOS KEYB instead of MKEYB for some extra functionality. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
Hi Bret, When you don't like the message, you shoot the messenger? What we're talking about here is a much larger issue than the Euro symbol -- the Euro symbol is just a specific example we can use to discuss the larger issue. I disagree. It is not unusual that text displays with weird chars in DOS while you use a different font than intended, which fixes itself once you change to the proper codepage. It also is common that people load a sensible font and keyboard combination at boot, but even the less common case of wanting to switch later can easily be covered with a few little batch scripts. This even works with MKEYB by using the /U uninstall option (alas not mentioned in our HTMLHELP yet?) and then installing the new MKEYB instance :-) So while large Unicode OS may have more elegant solutions here, even there you would probably never get a message that you are trying to type a character not defined in the current font. You just get some placeholder or no character instead. And in DOS you simply get the wrong character, until you change to the right font, but you still may WANT to type that character, because you KNOW that you can later view the text in the correct font. There is no need for keyboard drivers to educate users about such things using popups. Actually even Unicode LESS in LINUX annoys me with having opinions about which characters are text and which are control chars, which may vary depending on my OWN intended use of the viewed files. So at the risk of repeating the obvious: While it is possible to construct some problems to justify your desired powerful solution, this feels extremely over-designed from my view as Non-US DOS user. DOS has very few config files and it is unlikely that users get lost when trying to update them. If you want to address a REAL problem in FreeDOS, help making our installer handle harddisk sizes above 2 GB without having to rely on the ridiculous "feature" of FDISK to chop the first 48 GB of your disk into 24 tiny slices and drop the rest, because FDISK has no FAT32 support in auto-partitioning yet and the installer seems to consider this good enough for tiny virtual PC, ignoring real PC. THAT would be a real, reported problem that bothered REAL FreeDOS users. As opposed to convoluted optimization for the very limited use case of wanting to auto-generate keypresses without recording them first, or users who want Clippy to pop up and change keyboards or fonts for them. I admit that this is a problem in a different programming language, but feel invited to write a partition wizard in Assembly language if you do not want to write C code for FDISK patches ;-) Thanks! Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] MKEYB related stuff
Hi! now they will generate 213 with AltGr+E, whatever the codepage. with a proper codepage, this will look like €. Again, you're misunderstanding the problem. You shouldn't just automatically generate an ASCII 213 no matter what the Code Page is -- you should only generate an ASCII 213 when that's the Euro character on the Code Page currently in use. ASCII 213 is the Euro character on some Code Pages (like 858) but not on others (like 437 & 850). There That sounds like a lot of effort to disable a key binding while the user is not using the right font. Maybe they actually are aware of the difference and still want to type the character which will become visible as Euro sign even while they are in another font for the moment? are also Code Pages where there is a Euro character but it's not ASCII 213. To be fair, it's unlikely that a user would be using anything other than 437, 850, or 858 with a GR keyboard, but you just can't assume that ASCII 213 is always the Euro character even with those three Code Pages. By definition, anything above 127 is not ASCII, so it will depend on the codepage. Still, it is extremely rare that people use more than one codepage on the same system AND have identical characters with different byte values depending on which codepage they use AND have keyboard drivers which support both BUT want to switch on the fly instead of using a boot menu option or a simple batch script to go to one of the codepage/layout combinations. The real solution for the whole mess would probably be to use Unicode and graphical fonts with a few 1 or more glyphs, but that would also be a very unlikely choice for DOS users ;-) So while I can confirm that it is possible to design a problem to which your plan would be a solution, I still have big problems with the question "Will any user apart from yourself need anything even remotely as flexible as your planned inter-driver config signals?" Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DOS was dead...
Hi Felix, The "usual distro" of the day would be Ubuntu, with MINT being a spin-off and with lightweight variants such as Xubuntu or Lubuntu which default to install less heavy graphical things than the normal Ubuntu. MATE also is just yet another variant. https://distrowatch.com/ has a "ranking" of top 100 distros, and cataloging of those and others. Today Ubuntu is down to 6th. #1, #3 & #4 are Debian/Ubuntu-based, with Debian #7. That actually is a ranking of how often people have read about the various distros on distrowatch. Which I consider a website for advanced users, usually those which are bored by everybody using Ubuntu without checking alteratives ;-) I have actually peeked at distrowatch while composing my mail to check whether I have forgotten something big, but my impression was not that some of the non-Ubuntu distros in the top 10 would be easy for beginners and having a big user base which would be useful when people have questions. Of course Ubuntu is a "candified" version of Debian, but that is exactly why I am not using "raw" Debian. It took effort to use Debian in the old days where it took less effort to use Ubuntu. Today it takes effort to remove a bit of the bloat from Ubuntu, unless you just shrug it off, so I guess both are equally bad in their own ways. Not sure what your problem with deletion in graphical file managers is. Mine, in Ubuntu, just has to context menu items for that. One "move to trash", one "delete". So I can use whichever I prefer for the selected files. My first choice has not been named here, and is not a Debian derivation. Is it OS/2? Or is it one of the Linux distros? Which? Regarding the bloat: Sure, I have used fvwm variants for a long time almost 20 years ago and was happy to have a simple start menu based on a text config file. But it does not actually annoy me that even the most basic Ubuntu variants with lxde as user interface have a start menu which can be edited by clicking a menu. It is still reasonably lightweight. Xfce adds a bit of extra comfort. I agree that the defaults of Gnome, Unity and KDE are so complex that they slow down old computers. Yet I think "just do a default install of lubuntu or xubuntu" is better advice for those without experience with Linux than "do a text mode bare debian install". Of course, tastes do differ and there are plenty of Linux flavor specifically for people who want very low load for their hardware (small RAM, few files). I really miss information about system requirements on distrowatch. It only mentions default CPU type and typical install size in megabytes, while flooding me with version numbers of dozens of included packages which seems to be more important for their readers. For the top 10 in terms of distrowatch page views: MX 1.5-1.9 GB (KDE, Plasma, Xfce, Deb, i386/x86_64/armhf) Manjaro 1.9-2.7 GB (Gnome, KDE, Plasma, Xfce, Pacman/Snap, x86_64) Mint 1.8-2.0 GB (Cinnamon, Mate, Xfce, Deb, x86_64/i686) Pop! OS 2.2-2.7 GB (Gnome, Deb, x86_64, fewer filesystems) EndeavourOS 1.9-2.0 GB (Xfce, Pacman, aarch64/x86_64 etc.) Ubuntu 0.9-2.9 GB (Gnome, Deb, amd64/arm64/ppc64el/s390x) Debian 0.3-3.7 GB (Gnome, Deb, many CPU architectures) Elementary OS 1.4-1.5 GB (Pantheon, Deb, x86_64) Fedora 0.5-2.0 GB (Gnome, rpm, aarch64/armhfp/x86_64) openSUSE 0.14-4.3 GB (Gnome, KDE Plasma, Xfce, rpm, x86_64/i686/ppc64) Deb, Pacman, rpm and Snap are different app package formats. KDE, Plasma, Gnome, Cinnamon, Mate and Xfce are GUIs. Note that all Ubuntu variants make it easy to install the other GUIs, they are just listed by their defaults. Pantheon also is a GUI, only mentioned for Elementary. Most distros use LibreOffice, Debian also lists Calligra, KOffice and GOffice. I guess it is easy to install those in most other distros and/or remove LibreOffice there. Looking at the size, openSUSE probably has an option to easily install a text-only minimal version. You would not shrink a typical Linux that much by just dropping Office. Same for the smallest Debian or Fedora install sizes. Xubuntu is like Ubuntu, but with Xfce GUI: 1.7-1.8 GB x86_64. Lubuntu is the same, but with Lxde: 1.8-1.9 GB x86_64. Kubuntu, with KDE Plasma, is larger: 2.6-2.7 GB x86_64. Older versions also supported i686. As you see, many distros use Deb package formats. Ubuntu recently drifts towards snap, which bundles apps with their dependencies, which feels very bloated to me compared to the classic approach where packages just trigger installation of dependencies and dependencies are shared system-wide. Pacman is Arch Linux style, rpm is RedHat/Fedora/SUSE. Snap can be added to Arch, Fedora, openSUSE and Manjaro but has been criticized for being monopolized by Ubuntu vendor Canonical: Packages are distributed only by them. Deb (from Debian) packaging and rpm are real classics, so you get many apps for a Linux based on those :-) Sorry about the off-topic ;-) Eric ___ Freedos-use
Re: [Freedos-user] Floppy fetish search
Hi everybody, I don't need the actual floppies - but I'd love to have a photo of them. Interesting thought :-) Might take a moment, but good idea. I also like the hard blue plastic boxes in which Inmac sold the floppies. In the meantime, my offer has grown by 20 small 3.5 inch diskettes, as well as various storage boxes for big and small diskettes. Actually one can use those for 5.25 inch diskettes to organize CD or DVD, in case some of you likes a bit of a retro touch :-) Also, I have another nostalgia problem: After making copies of a few relevant pages, I think I should finally get rid of my German MS-DOS 4.01 and Windows 3.1 handbooks. Any good ideas for ritual destruction? Or is anybody still interested in that old stuff? ;-) Harald, thank you for your offer to extract data from my CP/M floppies! Going through the link list from Rugxulo, I found out that both cpmtools and 22DISK offer dozens of possible formats, but to my surprise, none of them seemed to work?? However, *AnaDisk* is able to check which types and numbers of sectors exist on each track of a floppy and assuming that using Win98 as host OS was acceptable, it manages to extract a confusing pile of sectors from each of the CP/M floppies. I still have to figure out whether there is sense in that data or whether I should rather seek help from Harald and his special hardware. For now, I will pause attempts to extract the floppy contents more thoroughly until new ideas pop up or until I find out that AnaDisk missed too much of the contents. Apparently the floppies were 40x8x1 or 40x8x2 with 512 bytes per sector, often with some un-numbered sectors here and sectors with data errors there? While almost all MS DOS formatted floppies still worked well - after 35 years! At the risk of only being able to read, but not reliably write or format 360k disks in the future, I still plan to *throw away* my 360k drive and keep only the 1200k drive (just in a drawer). Nobody seemed to want the 360k drive or my second 1200k drive yet ;-) Cheers, Eric PS: I also still have the original MS-DOS 4.01 floppies, but prefer to use the original MS-DOS 5.00 diskettes in 3.5 inch in case any need for any MS-DOS should ever arise again in the future. And there is Win 3.1! ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Floppy nostalgia: Drivparm and driver (and fastopen)
Hi everybody, as mentioned, I plan to get rid of the old MS DOS 4.01 handbooks, but before, I have copied the pages about drivparm and driver sys. Apparently, the config sys command and device driver simply serve to override (or provide) the drive type and geometry data which you would normally get from the BIOS, unless it is 100 years old. The difference between command and driver is that the latter can handle parameters for drives which would not exist at all according to the BIOS while the former just changes parameters of already existing BIOS diskette (or tape, in theory) drives. I think we could add some extra power to our config sys processing to turn BOTH into built-in config sys commands and become a little bit more complete as MS DOS replacement. However, has ANYBODY ever felt the need for either of the two?? My guess is that you would need a very old or very broken BIOS or very non-standard hardware to have any advantages from the feature. Given that 22DISK proudly lists 100 (in registered version > 400) CP/M formats it can read, I can imagine that DRIVPARM and DRIVER actually were useful in the 1980s, but would anybody like something like that today for their hobby or museum hardware? Thoughts please :-) Regards, Eric PS: I also looked at the manual item about FASTOPEN - it works only for harddisks and caches directory entries in one or optionally two ways, but I fail to understand the optional one. The idea seems to be that opening x:\a\b\c\d\e\f\g.txt needs many harddisk seeks for finding all the directories in the chain, so FASTOPEN caches them. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Floppy fetish search
Hi users :-) While sorting through some old stuff, I have collected: Circa 30 classic 5.25 inch 360k floppy disks, half of which were not yet formatted, but are formatted now Circa 9 classic 5.25 inch 1200k floppy disks, also empty and formatted And I have found that I have no mainboard which still understands 360k drives in the BIOS, so I have a PC10 360k floppy drive left over and will keep one of my two 1200k floppy drives here. Costs for all the above: Basically zero, but it would be nice to pay the postage. Would be nice to keep the things in use instead of throwing them to the waste. In addition, I have found a small number of floppy disks in CP/M format, which are very likely readable using some of the drives here, but I do not know HOW to read them, software wise. I cannot even use dd to make a diskimage, probably different sector sizes? So if anybody would like some of the empty disks or that PC-10 360k drive (I think you can make music by connecting drives to microcontrollers ;-)) please let me know. Also, if anybody can help me to extract the data from those CP/M floppies, I would be happy, too! Please let me know when you are interested in any of the above or would like to help. Thank you! Cheers, Eric (Germany) PS: I also have some fancy 5.25 inch boxes for storing 10 floppies each, made from plastic. Probably nice for mailing the floppies around. PPS: I have a LARGE amount of non-empty 360k disks, too, but am too lazy to format them, so I just copied their contents and plan to throw those away soon, after all. Next, I will be processing some of my old 1.44MB disks. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] brix. the game freezes.
Iyi günler Hitsumo, Jim and others, note that I write "hardware" and not hardware: Virtualbox simulates a NEW computer, but dosemu2 and dosbox simulates an old computer. So I mean simulated, not real, hardware. This is availble more easily :-) I BELIEVE that Brix worked for me on FreeDOS long ago when my hardware really included an ISA SoundBlaster: But it is too long ago to remember which tricks I needed to use Brix. I do remember that I have played Brix, it is a nice game. In general, most of my DOS activities in the early 2000s used FreeDOS, because I prefer open source, but I can not exclude the possibility that I have used some MS DOS parts in that time, in case FreeDOS did not have own versions. Today, I would normally use dosemu2, but for a change, here is a log of how Brix crashes dosemu 1.4.0.8 -C -Dawe -O ... "Using CPU emulation because vm.mmap_min_addr > 0." Indeed: cat /proc/sys/vm/mmap_min_addr 65536 Near the end of the dosemu log, before it crashes, I get: Page fault: Page fault: writewrite instruction to linear address: 0x0001c9a1 instruction to linear address: 0x0001c9a1 CPU was in CPU was in user mode user mode Exception was caused by Exception was caused by non-available page non-available page VFLAGS(b): 0100100010 EAX: 3a3a3a3a EBX: b7d67405 ECX: 0001 EDX: 0001c9a2 VFLAGS(h): 00010202 ESI: 0001 EDI: 00a35d60 EBP: 00a35cc0 CS: 0073 DS: 007b ES: 007b FS: GS: 0033 FLAGS: IF RF IOPL: 0 OOPS : ef 89 42 f3 89 42 f7 89 42 fb -> 88 42 ff 8b 44 24 08 5b c3 66 Program=sigsegv.c, Line=375 EIP: 1c91:0123 ESP: 2cfc:0fb6 VFLAGS(b): 0 0010 0110 EAX: 01040606 EBX: ECX: 0001 EDX: 022c VFLAGS(h): 0206 ESI: EDI: 0012 EBP: 0fbc DS: 1c91 ES: 1c91 FS: 0298 GS: c453 FLAGS: PF IF RF VM VIF IOPL: 0 STACK: 91 1c 2c 02 00 00 00 00 00 00 -> c7 01 06 08 80 07 de 0f 00 00 OPS : b0 f0 ec 0a c0 78 fb 8a c4 ee -> c3 52 8b 16 30 00 80 c2 0e 2a c3 1c91:0123 ret Which is odd, because neither the ret nor the address seem to be too complicated for the classic DOSEMU 1.4 CPU emulation? When taking the risk to use the real CPU: echo 0 > /proc/sys/vm/mmap_min_addr ... then Brix does work in dosemu 1.4 :-) However, when I enable PC speaker sound in the game, things get stuck in the sound blaster access (which is enabled by default). You can see the details in the logs, but they end with: 22c < 14 SB: DSP command 0x14 accepted SB: Read 0x80 from DSP Write Buffer Status Register 22c > 80 SB: Read 0x7a from DSP Write Buffer Status Register 22c > 7a 22c < 93 SB: DSP parameter 0x93 accepted for command 0x14 SB: Read 0x79 from DSP Write Buffer Status Register 22c > 79 22c < 3 SB: DSP parameter 0x3 accepted for command 0x14 SB: 8-bit DMA output starting DMA: processing controller 1, channel 1 SB: Starting to open DMA access to DSP (Single-Cycle mode) SB: Sampling rate is 1 Hz SB:[Linux] DMA blocksize set to 2048 (8,8) SB:[Linux] Get Free Fragments (32, 32) I think dosemu tries to write to a socket with no receiving process. You can disable soundblaster output by starting the game as: BRIX1 /nosb Interestingly, the PC speaker sound does not work then, but that might be a side-effect of the stuck other dosemu instance while testing :-p When playing as BRIX1 /nosb in DOSEMU 1.4 the game works completely, but without sound. It even works with /nosb in the dosemu CPU emulation, also with no audible sound, not even from the emulated PC speaker. So what do we learn from this? DOSEMU 1.4 has problems with how BRIX uses the Sound Blaster! It even crashes in CPU emulation mode and "only" hangs when using your real CPU - which you can only do on 32-bit operating systems. If you want to play the game, use BRIX1 /nosb If you want to help finding out more about the problem, try to use BRIX1 with soundblaster sound in DOSEMU 2.x and enable full logging or even dosdebug. Looking forward to read about it :-) I do NOT think that Brix itself has a problem with FreeDOS. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] why isn't anyone answering my question? - host filesystem access inside emulators
Hi Jim and AM, 1. FreeDOS cannot read NTFS. However, there are non-open-source tools for DOS in general which let you access files on older NTFS filesystems, for example Avira NTFS4DOS from 2007, may access Windows 2003 or older filesystems. FreeDOS can read variations of the FAT filesystem, including FAT32. Note that in spite of the name ExFAT is not a variation of FAT and therefore not supported by DOS! Microsoft is just using the old popular name for something completely new in this context. 2. An operating system running inside a PC emulator like VirtualBox cannot access the direct hardware of the machine. This means that it does not even matter whether FreeDOS can access NTFS at all: What you need is a way to make a selected directory of your Linux or Windows box visible inside the emulator. With Dosemu (better: Dosemu2) for Linux, this is supported in a DOS specific way, avoiding the need for DOS drivers, but for more "complete" emulators such as VirtualBox or VMWare, you will also need drivers on the DOS side. For example for VMWare, there is VMSMOUNT: http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/vmsmount.html For Windows, you probably want to use dosbox, which is more a simulation of a DOS PC than a simulation of a PC, so it can directly simulate the existence of Windows files at any drive letter of DOS. As Jim wrote, QEMU can create a simulated harddisk which contains the files of an arbitrary Linux directory, so in that case, like with Dosemu and Dosbox, you will not need any drivers on the DOS side :-) [for qemu, use...] -drive file=fat:rw:/home/jhall/dos Regards, Eric I have a desktop computer running a Linux distro. In this LInux distro I have installed VirtualBox, and in this VirtualBox I have installed Freedos. The virtual Freedos is running fine. However I can't figure out a way to allow the virtual Freedos to access the different partitions of the hard drive (for example an NTFS partition that contains my personal data), as well as any USB flash drive. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] How to set up fdconfig.sys and autoexec files for a driver?
Hi! Problem is, fdconfig.sys and autoexec.bat seem really complicated... For questions about the boot config menu system, check the HTMLHELP: http://help.fdos.org/en/index.htm http://help.fdos.org/en/hhstndrd/cnfigsys/menu.htm You can also read this using the same name tool at the DOS prompt :-) A good way of learning about the menu is reading and understanding some example autoexec and config files which should be available on FreeDOS related websites. I do not remember specific ones, though. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Now it gets odd Re: FreeDOS workaround for hidden IDE controller?
Hi again, I used CloneDisk to rip a RAW image of the booting DOM with FreeDOS. Mounted that with Qemu. Booted Qemu with the FreeDOS install image and installed FreeDOS to the image copied from the DOM. Then I used CloneDisk to write that image back to the DOM. "Missing Operating System". Then maybe the real PC and QEMU were configured to use different drive geometries: For example QEMU supports LBA, but maybe your real PC BIOS did not support LBA or did not have it enabled? Have you tested whether things still booted in QEMU before you cloned the image back to the DOM? When in doubt, you can always skip the SYS step during FreeDOS install to keep most booting parts as they were in the previous raw image. Also, a "missing operating system" message can be a symptom of bad XMS, EMS or UMB driver configurations: Those might break proper disk access as soon as the driver loads or as soon as XMS / EMS / UMB are actually used. And when file access fails in the middle of config / autoexec, you may get messages complaining about missing files, while the files actually are still there. Things you can try: 1. Boot from floppy and SYS the DOM again. 2. Use F5 / F8 to skip all / part of the drivers to see if they caused your problem in their current configuration and 3. Check your PC BIOS and QEMU settings regarding LBA support and CHS geometries for the DOM to see whether they match nicely. You can also tell SYS to use or avoid LBA manually, but that should only be needed in exotic situations. Regards, Eric -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Now it gets odd Re: FreeDOS workaround for hidden IDE controller?
Possible explanation: The FreeDOS USB boot thing has a harddisk- style bootable disk image and the BIOS of your computer has some compatibility issue with the drive-renumbering caused by booting from USB and/or from using a "harddisk" boot image. A possible solution would be to use a FreeDOS boot FLOPPY or floppy image. As you are able to use the MS DOS one, you will be able to use a FreeDOS one as well :-) As far as I can tell, you do not need a large install, just the "usual DOS stuff", so you can use some floppy distro like Ruffidea or Brezel or similar. You could even use the always-fresh automated build floppy images, but those will have almost no tools and drivers included: They simply are provided for having the freshest kernel online in bootable form. Maybe the other freedos-user fans can suggest a nice image :-) Regards, Eric I found an "MS-DOS 7.1" boot floppy image and *this one* had no problems booting the S30 with a USB floppy drive, wiping the DOM and creating a fresh partition with FDISK, then rebooting and using format c: /s NOW it's booted to a DOS prompt from the DOM. So I'll try FreeDOS again.. Nope. Same as before. Screen full of No Fixed disks present, followed by a prompt to repartition D:, but it cannot touch it. Does the Lite USB install make a log file to diagnose why it's not working? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS workaround for hidden IDE controller?
Some thoughts... The storage is an IDE Flash Disk, AKA Disk On Module. It has a 44 pin female header connector, same electrical interface as a 2.5" IDE hard drive. They're available dirt cheap in sizes from 64 megabytes to 2 gigabytes, not so cheap in 4 and 8 gigabytes... You can also use a compact flash (CF) card with a purely mechanical adapter (CF can speak IDE interface language). They are cheap but I think DOM can do more I/O transactions per second. Another idea: Instead of EMS, you could use good old XMS to make a big ramdisk and then copy everything there on boot. Assuming that you do not plan to modify files on the machine - modifications would be lost each time when you shut down or reboot without copying data back from the ramdisk to the flash disk. The ramdisk would be as fast as the EMS library of G files in your old software, but would not need EMS. In my opinion, XMS drivers are more "tame" to use compared to EMS drivers. If your old software supports EMS 4.0, then you would not need a 64k page window. This is what the NOEMS option of EMS drivers does: It skips the creation of the window. Software which understands version 4.0 of EMS can still use EMS without needing a large fixed window. With DOS in HMA and drivers (if safe and not too fragmented) in UMB, you will have a lot of low memory available. So depending on how large those G-Code files are, things should be okay. Note that you can use UMBPCI to have raw UMB without the hassles of configuring EMS right. Also, UMBPCI is still maintained for support of many mainboard types. Regards, Eric DOS or FreeDOS, I just want to get the thing to boot off the IDE flash module and run with as much EMS memory as it can. The software I need to run is made to run on anything with DOS, and EMS, and a serial port, all the way back to the 5150 IBM PC. Don't need any XMS, it loads the G-Code files into EMS, if available. Otherwise it uses whatever low memory is available and files too large to fit must be cut up with the splitter/linker utility. Hopefully the WYSE Sx0 series thin client's memory map isn't all fragmented up like circa 1995 and newer laptops. They don't have a large enough contiguous RAM space to put the 64K EMS paging window. If this can be made to work I'll write up a how-to so other PLM2000 CNC mill owners can setup a tiny controller box and ditch the big PC. The control computer does zero computing of things like curves. It just sends G-Code to the mill and monitors return communications for encoder counts, limit switch activation and stop messages from exceeding torque limits. The servo controller in the mill does the heavy lifting. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS workaround for hidden IDE controller?
Hi Greg, I don't need anything complicated for DOS, just configuring the 128 meg RAM for as much EMS as possible because the old software I want to run uses EMS not XMS, and USB support for reading files from flash drives. Getting the Realtek AC97 sound and Realtek LAN working would be nice, but not required. This depends on what you want to do with the sound. IF the old software has the possibility to change drivers, you could make it use AC97. IF if can only support soundblaster: Well, AC97 is not soundblaster, so only special tools which simulate a sb16 and then send the sound to ac97 in the background would help. Regarding realtek LAN, rtl8139 and similar were classics, so DOS drivers are available for those. Assuming that you want a packet driver, that is. If your software involves something like Win3, things are different, also regarding the sound. For EMS, you can try JEMMEX, JEMM386 and other free drivers or the classic drivers from microsoft, ibm, quarterdeck etc. In all cases, you will have to read the docs and carefully select the right command line options to get a stable system with much EMS but without conflicts in the UMB range or similar problems. One aspect often is selecting the right A20 mechanism and the right mechanism to get memory area listings from the BIOS. Everything theoretically autodetectable, but incompatible surprises exist. Regards, Eric -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New year a
From: "E. Auer" Hi everybody, just a quick mail to wish you a happy new year and forward some news from Jack - for those who have a really old PC. Jack made a 2016-12-15 driver update: One-Time ONLY update of the 5-Mar-2015 drivers provided from SourceForge IBiblio. Changes are: * XMGR/UHDD now do real-mode XMS moves O.K. on an 80386 CPU. * UHDD's overlap and binary-search buffer have been deleted. * UHDD adds 10-MB and 20-MB cache sizes for smaller systems. * UHDD adds a /G switch for older DOS games that require it. * The /R switch for RDISK, UHDD and UDVD2 has been improved. * The UIDE driver is dropped and shall not be maintained nor updated any further. Use UHDD and UDVD2 instead. The catch is that the drivers are only available from him on request, not distributed on websites. Cheers, Eric -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user --- Internet Rex 2.29 * Origin: capcity2.synchro.net - 502/875-8938 (1:2320/105.99) --- * BgNet 1.0b12 = CCO * KY/US * 502/875-8938 * capcity2.synchro.net --- Synchronet 3.15a-Linux ListGate 1.3 * Capitol City Online - Frankfort, KY - telnet://capitolcityonline.net -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New year and new drivers
Hi everybody, just a quick mail to wish you a happy new year and forward some news from Jack - for those who have a really old PC. Jack made a 2016-12-15 driver update: One-Time ONLY update of the 5-Mar-2015 drivers provided from SourceForge IBiblio. Changes are: * XMGR/UHDD now do real-mode XMS moves O.K. on an 80386 CPU. * UHDD's overlap and binary-search buffer have been deleted. * UHDD adds 10-MB and 20-MB cache sizes for smaller systems. * UHDD adds a /G switch for older DOS games that require it. * The /R switch for RDISK, UHDD and UDVD2 has been improved. * The UIDE driver is dropped and shall not be maintained nor updated any further. Use UHDD and UDVD2 instead. The catch is that the drivers are only available from him on request, not distributed on websites. Cheers, Eric -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeCom: Wrong DIR behavior on empy disks.
Hi dos386, >> ... or all the other date formattings > > No point of existence ;-) I hope zou do not think that about other countries as well... >> German dd.mm. hh:mm 1.000,00 for COUNTRY >> than BIOS default US QWERTY) are totally different > > I prefer to keep things simple (QWERTY, "@" and "\" discoverable) > and convenient (-MM-DD HH:MM:SS) - no need for messing > up eveything. Anyone has a clue how many permutations of timestamps > or keyboard exist at all ? In any case, I don't need more than ONE > ;-) Keyboard very many, date / time very few. I think your preferred style is either "what the American default is anyway" or maybe a small variant, if default has am/pm. So I am sure you can find a setting with date and time style of your taste in the kernel. And I am sure that you need no drivers for keyboard or fonts, because you already like the BIOS default settings for those :-) Eric -- 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.0 installation... very instable?
Hi JPT, > - freedos 1.1 successfully installed. Nice :-) > Was 3x128 + 1x256 = 640, but recognized only 384 MB. This might... Indeed odd. > - CPU clock rate too high for a lot of old dos software? > Do you think clocking down to below 500 Mhz might help? If your hardware supports ACPI, starting from newer socket 7 / pentium 3 afair, you can use FDAPM SPEEDn where n is a digit to throttle the system a bit. This halts the CPU and/or clock for N our of 8 time slices in hardware (e.g. 1/32768 seconds long) but for fast systems, it will just make games jumpy, not smoothly reduce the speed. Also, strong throttle makes things behave sluggish as it hinders timely IRQ handling. More modern methods such as reduction of clock and voltage together are not supported by FDAPM yet and often only allow a few speed steps. For example AMD cool n quiet might support only 100%, 80% and 40%. More old methods such as single stepping through all code can have compatibility problems and will waste a lot of CPU performance and energy in general... In the modern virtual computer case, you sometimes simulate the whole CPU anyway, so you already do waste host CPU performance but can use any speed. > Bart says so for his network boot floppy. Odd suggestion though ;-) > - A20 stuff... > especially the XMS/EMS driver loading seems to fail often. > I have in mind that A20 has to do something with EMS oder XMS or UMB? A20 only has to do with HMA, DOS=HIGH and with XMS. Many EMS drivers permanently switch the A20 on, or at least keep it on (should be default set by BIOS during boot) and then just simulate A20 switching. Also, switching off the A20 is only needed for some obscure old software while not accessing HMA, so if you have to revert to a setting (HIMEMX has quite many) which "solves" the A20 problem by keeping the A20 always on, you should be fine nevertheless. I agree that apart from XMGR, HIMEMX and similar can be an alternative. Try NOT to load any EMS / UMB driver (JEMM386, EMM386 etc) before you solve the XMS / HMA problem (HIMEM, XMGR...). A special case is JEMMEX which combines both "HIMEM" and "EMM386" in one driver, so you should NOT load HIMEM / XMGR before JEMMEX, or at least need not load them 1st. > And, A20 is some hack using the keyboard controller. > Since I attached an USB keyboard to a USB switch, for easily > switching > between computers... could this be a problem The USB itself no, but the fact that the BIOS tries to make the USB keyboard look like PS/2 by faking some keyboard controller activities, maybe yes... > - This time I partitioned and formatted the drive before booting the > installer. Very good idea and works well with GPARTED and other tools. > btw, the fdisk program contained on the floppy sucks. I agree, it mainly tries to look and feel like MS FDISK. > created a bad partition layout. have to move partitions now... > what about xfdisk instead? XFDISK is an idea :-) > - install Freedos 1.1T3 > Ran through in almost no time, wow! > I got the same error message from Jemm, but pressing ESC continued > booting the installer. Still sounds evil. I hope the installer can work without JEMM. > So where do you suggest to continue? Should I jump to the 1.0 > installer? If you want a big pile of software, you can manually unzip more packages from the 1.0 CD-ROM into your DOS directory, or use a more elegant "package install or update" tool which does almost the same but in addition automatically checks dependencies and runs post install batch scripts (not many packages use those). > or should I install manually? Could you point me to a tutorial for > manual install, or is it just "unpack anywhere", as we are used Basically yes, but it is often better to unpack things from the distro into the same DOS directory and keep the subdirectories structured the way they are in the zip files. > - network > its a 3c905b. It should work using the NDIS driver included with > Barts > Network Boot Disk. Does it work with freedos out of the box or do I > have > to do this manually using this wiki page? That 3com series sounds classic, so I assume there will be a direct packet driver on crynwr which does not need NDIS/ODI. The freedos.org page also links nice pages about networking. > > http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Networking_FreeDOS_-_NDIS_driver_installation > > Which cards are known to be working? Got a few Realtek based > somewhere... Classic NE2000 compatible RTL80x9 and 100mbit/s RTL8139 cards work nicely with DOS drivers and the PCI config is plug n play for the driver. Not plug and play in the sense that DOS will automatically find the driver for you, just in the sense that the driver needs almost no command line options :-) > - pascal compiler freepascal, 32 bit, available for dos > - maybe basic compiler or interpreter freebasic, 32 bit, compiles, available for dos, has qbasic mode. > - maybe fortran compiler, if the old software has to be r
Re: [Freedos-user] FreeCom: Wrong DIR behavior on empy disks.
Hi Bernd, Dos386, > I'd like to see -MM-DD (with dashes) and without COUNTRY. ... or Japanese MMDD as Bernd mentioned ... >> makes sorting files by date so much easier. > > :-) ...or all the other date formattings: You can just set your country depending on your taste. As long as you do not use nlsfunc, nothing will try to make your keyboard or font Japanese. Simply pick a place where date, time and number formats match your taste, e.g. German dd.mm. hh:mm 1.000,00 for COUNTRY even if your LANG setting for strings, DISPLAY fonts (if any) and keyboard layout (if any other than BIOS default US QWERTY) are totally different ;-) Eric PS: Note that COUNTRY also influences the "yes no characters" and currency sign and a few other things... Some countries even have a slightly specific collate order (e.g. how to sort accented chars). -- 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
