Re: [Freedos-user] FreeDOS 1.3-RC3 News / 8086 compatibility
Hi, On Mon, May 25, 2020 at 11:04 AM Jerome Shidel wrote: > > > On May 25, 2020, at 10:12 AM, Eric Auer wrote: > > > > I guess you could save some disk space by merging some of the > > tools into fewer, more versatile tools, due to cluster sizes? > > Sure, I “could do that”. But, I’m not going to. For two main reasons. > > FIrst, loading and unloading everything for each and every call > will really slow things down even more. > > Second, they are designed to cooperate with each other. But, be > completely independent from each other. So, lets say you have a boot > floppy and all you need is to test if it a 286 or 386. All you need is to > stick the 2.8k vinfo program on there and not drag the rest of the stuff > along for the ride. I've mentioned ARK.EXE before (for combining small .COM files), IIRC it's GPLv2: * https://www.sac.sk/download/pack/ark101.zip However, it's probably not that big of a deal. > Not an issue, The main USB/CD installer requires a 386 (do to the use of some > external utilities, like grep). Find me a consumer 386 that did not ship with > EGA compatibility. Requiring a 386 is not really a problem either. USB was not > around and our CD drivers require a 386 as well. Xgrep is 8086 asm code, and it works well. But it has quite different (less?) features than the bloated (useful!) DJGPP GNU grep. > Maybe zip has a reason to want a 286. But, IDK. Unlikely, but I haven't checked. I presume you mean 186 here. It might be a compiler (PEBKAC) error of whoever built it (same as with old NASM 0.98.39 16-bit, built for 186). I don't recall any 286 pmode builds of Info-Zip at all. There was at least one, maybe two, 16-bit Zip builds (Small model?), but they ran out of memory quickly. Better than nothing but not perfect. Most people just use the DJGPP (386+) build (LFNs!). > As for unzip. I can’t see a good reason for requiring a 386. > Mateusz’s FDINST unzip’s packages just fine and is supposed > to be 8086 compatible. Don't know which exact binary (or version) of Unzip you're referring to here. P.S. Thanks for your efforts. Keep up the good work. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS 1.3-RC3 News / 8086 compatibility
Hi, > On May 25, 2020, at 12:25 PM, Mateusz Viste wrote: > > On 25/05/2020 17:29, Jerome Shidel wrote: >> I wouldn’t get anything lower than a 286 to Run the current kernl86.sys. > > Svarog86 is a FreeDOS distribution that uses the kernl86.sys. Works on my > 8086 with no troubles, although it has a few things turned off (for memory > saving, not 8086 compatibility). > > Mateusz version 2042? Good to know it can work. Wonder if one of the options is the culprit. Anyhow, not really my area(s) of focus. IDK. Just know, I couldn’t get anything in PCem less than a 286 to work with the stock kernl86.sys :-) ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS 1.3-RC3 News / 8086 compatibility
On 25/05/2020 17:29, Jerome Shidel wrote: I wouldn’t get anything lower than a 286 to Run the current kernl86.sys. Svarog86 is a FreeDOS distribution that uses the kernl86.sys. Works on my 8086 with no troubles, although it has a few things turned off (for memory saving, not 8086 compatibility). Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS 1.3-RC3 News / 8086 compatibility
Hi Eric, > On May 25, 2020, at 10:12 AM, Eric Auer wrote: > > > Hi Jerome, > >> I thought you knew [that V8 means V8 Power Tools] Anyhow... > > Me maybe, but some who are interested in floppy distros not yet ;-) > >> They are a set of command line utilities written in assembly that >> can provide a Text based User Interface (TUI) and other... > > I guess you could save some disk space by merging some of the > tools into fewer, more versatile tools, due to cluster sizes? Sure, I “could do that”. But, I’m not going to. For two main reasons. FIrst, loading and unloading everything for each and every call will really slow things down even more. Especially, on things like QEMU on the PI where disk speed is horrible to begin with. Second, they are designed to cooperate with each other. But, be completely independent from each other. So, lets say you have a boot floppy and all you need is to test if it a 286 or 386. All you need is to stick the 2.8k vinfo program on there and not drag the rest of the stuff along for the ride. > >> several text features it can do that require an EGA or better card. >> Then there are some that are just easier without needing to support >> sub-EGA cards. I could list the exact features it uses that require EGA > > That actually would be quite interesting :-) And I wonder whether > the installer could degrade gracefully when EGA is not available, > for example skip some fancy decorations but keep interacting :-) Not an issue, The main USB/CD installer requires a 386 (do to the use of some external utilities, like grep). Find me a consumer 386 that did not ship with EGA compatibility. Requiring a 386 is not really a problem either. USB was not around and our CD drivers require a 386 as well. > >> Thats an easy one. It doesn’t boot. > > Which version exactly does not boot on 8086 and which version > and options of SYS have you used? Which messages are shown? > >> "it hangs after printing C: HD1, Pri stuff" > > While the person testing made sure to use a 8086 compiled binary? Latest 2042 Kernl86.sys and accompanying SYS. More like what options didn’t I try. IDK, may have missed one. When I say did not boot, I mean it did not boot. I don’t mean it crashed. All it did was sit there, no output. If you are interested, you can try to get it work in there. But, I spent almost two full days playing around with PCem. I’m done with that. I’ve got other things needing done. > >> Why does Zip support 286, but Unzip needs a 386? > > A very good question! In general, I think unzip is > also likely to need sufficient RAM. I believe some > of our installers use zip libraries instead of the > info-zip command line tool, but I do not remember > which CPU and RAM requirements the installers had. Maybe zip has a reason to want a 286. But, IDK. As for unzip. I can’t see a good reason for requiring a 386. Mateusz’s FDINST unzip’s packages just fine and is supposed to be 8086 compatible. > >> Why keyb need a 286, it’s a keyboard mapper? > > For a small distro, I would rather suggest MKEYB. > But I have not checked whether that works on 8086? But, may need options only available in keyb. I personally use neither and only vaguely familiar with them, > >> Why does ctmouse need a 286? > > Let me check... Those actually were planned as compile > time options: You can select whether 286/386 with pusha, > popa and shift by constant number of bits are available > or not, but at closer inspection, count2x.mac fails to > omit one shr ah,4 for the 8086 case :-p > > If you like, I could send you a suggested set of 8086 > compatible sources you could compile and try out :-) > >> It was required for most CGA and up games on our old 8086 clone. > > How is that possible when it has not worked on 8086 yet? My old man had used a Logitech Serial mouse on his Laser XT Turbo (4/8mhz 8086, PC XT Clone) It’s been a long time, maybe the CGA games were keyboard only. But, I don’t honestly recall if stuff like Wheel of Fortune and the like used a mouse. But, you pretty much needed it to play any of those 320x200 VGA games (Police Quest, Kings Quest, Leisure Suite Larry, etc) So, there should be mouse support for 8086 & 80286. > >> Why does FDAPM have no support at all for < 286. > > I have tried to avoid non-8086 instructions outside > functions which only a 386 would have anyway, so my > intention was that FDAPM just has no effect on older > PC because neither BIOS nor hardware support APM on > those, but it should not crash. Did it crash for you? No. It just complained and quit. But, there a lots of things (like reboot), that it could do on an 8086 that are sometimes useful. Just because it couldn’t do everything it does on a 386, doesn’t mean what could be done on a 286 or 8086 wouldn't be appreciated. > >> Why does dosfsck need a 386? > > Now THAT is easy to answer: For FAT12 and FAT16, you > should use CHKDSK. Porting DOSFSCK to 32-bit DOS is > mainly for FAT32 audi
Re: [Freedos-user] FreeDOS 1.3-RC3 News / 8086 compatibility
May 25, 2020 5:30 PM, "Jerome Shidel" wrote: > I agree and have said several times, Emulation is not Hardware. > > I wouldn’t get anything lower than a 286 to Run the current kernl86.sys. > > But, as I said, the one tester in the IIRC had been running it on the NEC v30 > w/a 80186. Did a CPU > swap. And it would crash on boot. > > So, IDK. I don’t have an 8086 to test it. I have a Pentium Pro (i686) and may > still have a > 486/DX2-66 Notebook in the attic. But, don’t know if it is still up there or > if it works. Neither, > suitable for testing 8086 compatibility. Whenever I find a way to get my 1512 repaired I'll be happy to test. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS 1.3-RC3 News / 8086 compatibility
Hi, > On May 25, 2020, at 11:02 AM, Deposite Pirate wrote: > > I wouldn't be too confident that PCem does not have bugs. I've played a lot > with it recently because my 1512's monitor needs to be repaired and I have > yet to find somewhere I can get that done. There are several things that > don't work with PCem's 1512 emulation that should. I couldn't get a 720k > floppy to work as drive B with the required DRIVPARM and DRIVE.SYS settings, > and I know for a fact that this is possible because I've seen it work as > expected on a real 1512. Then the GEM that comes with the 1512 system > floppies just doesn't work with PCem either so there must be a problem in the > video code. There are other weird things that I noted that happen with PCem > that would not happen with a real 1512. Current FreeDOS indeed doesn't work > with PCem emulating a 1512. But I have FreeDOS 0.9 installed to a MFM hard > drive on my real 1512. And it does work. I used it with PLIP to transfer > stuff on it because I had no other computer with a 360k/1.2M drive. And it's > definitely not a NEC V30 CPU in there but an AMD 8086. I agree and have said several times, Emulation is not Hardware. I wouldn’t get anything lower than a 286 to Run the current kernl86.sys. But, as I said, the one tester in the IIRC had been running it on the NEC v30 w/a 80186. Did a CPU swap. And it would crash on boot. So, IDK. I don’t have an 8086 to test it. I have a Pentium Pro (i686) and may still have a 486/DX2-66 Notebook in the attic. But, don’t know if it is still up there or if it works. Neither, suitable for testing 8086 compatibility. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS 1.3-RC3 News / 8086 compatibility
I wouldn't be too confident that PCem does not have bugs. I've played a lot with it recently because my 1512's monitor needs to be repaired and I have yet to find somewhere I can get that done. There are several things that don't work with PCem's 1512 emulation that should. I couldn't get a 720k floppy to work as drive B with the required DRIVPARM and DRIVE.SYS settings, and I know for a fact that this is possible because I've seen it work as expected on a real 1512. Then the GEM that comes with the 1512 system floppies just doesn't work with PCem either so there must be a problem in the video code. There are other weird things that I noted that happen with PCem that would not happen with a real 1512. Current FreeDOS indeed doesn't work with PCem emulating a 1512. But I have FreeDOS 0.9 installed to a MFM hard drive on my real 1512. And it does work. I used it with PLIP to transfer stuff on it because I had no other computer with a 360k/1.2M drive. And it's definitely not a NEC V30 CPU in there but an AMD 8086. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS 1.3-RC3 News / 8086 compatibility
Hi Jerome, > I thought you knew [that V8 means V8 Power Tools] Anyhow... Me maybe, but some who are interested in floppy distros not yet ;-) > They are a set of command line utilities written in assembly that > can provide a Text based User Interface (TUI) and other... I guess you could save some disk space by merging some of the tools into fewer, more versatile tools, due to cluster sizes? > several text features it can do that require an EGA or better card. > Then there are some that are just easier without needing to support > sub-EGA cards. I could list the exact features it uses that require EGA That actually would be quite interesting :-) And I wonder whether the installer could degrade gracefully when EGA is not available, for example skip some fancy decorations but keep interacting :-) > Thats an easy one. It doesn’t boot. Which version exactly does not boot on 8086 and which version and options of SYS have you used? Which messages are shown? > "it hangs after printing C: HD1, Pri stuff" While the person testing made sure to use a 8086 compiled binary? > Why does Zip support 286, but Unzip needs a 386? A very good question! In general, I think unzip is also likely to need sufficient RAM. I believe some of our installers use zip libraries instead of the info-zip command line tool, but I do not remember which CPU and RAM requirements the installers had. > Why keyb need a 286, it’s a keyboard mapper? For a small distro, I would rather suggest MKEYB. But I have not checked whether that works on 8086? > Why does ctmouse need a 286? Let me check... Those actually were planned as compile time options: You can select whether 286/386 with pusha, popa and shift by constant number of bits are available or not, but at closer inspection, count2x.mac fails to omit one shr ah,4 for the 8086 case :-p If you like, I could send you a suggested set of 8086 compatible sources you could compile and try out :-) > It was required for most CGA and up games on our old 8086 clone. How is that possible when it has not worked on 8086 yet? > Why does FDAPM have no support at all for < 286. I have tried to avoid non-8086 instructions outside functions which only a 386 would have anyway, so my intention was that FDAPM just has no effect on older PC because neither BIOS nor hardware support APM on those, but it should not crash. Did it crash for you? > Why does dosfsck need a 386? Now THAT is easy to answer: For FAT12 and FAT16, you should use CHKDSK. Porting DOSFSCK to 32-bit DOS is mainly for FAT32 audience and proper checking of such partitions can need several megabytes of RAM. There is no support for checking FAT32 partitions on older computers, sorry. Actually I expect DOSFSCK to run out of RAM for larger partitions even on common 386 RAM sizes. I remember even booting Windows 95 on a 386 took roughly 10 minutes when I put the harddisk of a 486 into a 386 PC and started in safe mode :-p About Format: Regarding FORMAT for 360k: I believe that some people with actual 360k drives have tried it, so maybe this is just an issue with QEMU or PCem behaving in ways not expected by FORMAT? Of course it would be nice to improve the ability of FORMAT to work even there, so feel free to send FORMAT /F:360 /4 /D logs. You could also try /1 one-sided and /8 8-sector formats for fun. Use /4 for 360k in 1.2M drives, no /4 for 360k drives. See the FORMAT /z:longhelp descriptions :-) Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
