You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(60) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(280) |
Feb
(411) |
Mar
(455) |
Apr
(367) |
May
(125) |
Jun
(155) |
Jul
(266) |
Aug
(131) |
Sep
(223) |
Oct
(76) |
Nov
(103) |
Dec
(132) |
2005 |
Jan
(70) |
Feb
(113) |
Mar
(57) |
Apr
(38) |
May
(110) |
Jun
(74) |
Jul
(365) |
Aug
(198) |
Sep
(116) |
Oct
(119) |
Nov
(184) |
Dec
(55) |
2006 |
Jan
(97) |
Feb
(70) |
Mar
(51) |
Apr
(16) |
May
(46) |
Jun
(176) |
Jul
(305) |
Aug
(427) |
Sep
(223) |
Oct
(121) |
Nov
(112) |
Dec
(48) |
2007 |
Jan
(16) |
Feb
(19) |
Mar
(67) |
Apr
(69) |
May
(48) |
Jun
(35) |
Jul
(26) |
Aug
(44) |
Sep
(33) |
Oct
(86) |
Nov
(15) |
Dec
(28) |
2008 |
Jan
(120) |
Feb
(7) |
Mar
(76) |
Apr
(47) |
May
(41) |
Jun
(24) |
Jul
(25) |
Aug
(34) |
Sep
(58) |
Oct
(7) |
Nov
(16) |
Dec
(40) |
2009 |
Jan
(17) |
Feb
(53) |
Mar
(121) |
Apr
(69) |
May
(28) |
Jun
(39) |
Jul
(12) |
Aug
(22) |
Sep
(25) |
Oct
(15) |
Nov
(53) |
Dec
(9) |
2010 |
Jan
(10) |
Feb
(30) |
Mar
(10) |
Apr
(44) |
May
(36) |
Jun
(14) |
Jul
(21) |
Aug
(19) |
Sep
(1) |
Oct
(6) |
Nov
(22) |
Dec
(11) |
2011 |
Jan
(10) |
Feb
(45) |
Mar
(6) |
Apr
(7) |
May
(38) |
Jun
(40) |
Jul
(248) |
Aug
(150) |
Sep
(124) |
Oct
(40) |
Nov
(36) |
Dec
(57) |
2012 |
Jan
(64) |
Feb
(22) |
Mar
(14) |
Apr
(20) |
May
(54) |
Jun
(27) |
Jul
(36) |
Aug
(63) |
Sep
(11) |
Oct
(4) |
Nov
(13) |
Dec
(33) |
2013 |
Jan
(49) |
Feb
(36) |
Mar
(8) |
Apr
(17) |
May
(34) |
Jun
(24) |
Jul
(45) |
Aug
(4) |
Sep
(14) |
Oct
(8) |
Nov
(3) |
Dec
(16) |
2014 |
Jan
(32) |
Feb
(10) |
Mar
(41) |
Apr
(35) |
May
(23) |
Jun
(9) |
Jul
(110) |
Aug
(9) |
Sep
(12) |
Oct
(6) |
Nov
(16) |
Dec
(77) |
2015 |
Jan
(249) |
Feb
(9) |
Mar
(95) |
Apr
(28) |
May
(126) |
Jun
(151) |
Jul
(11) |
Aug
(35) |
Sep
(258) |
Oct
(198) |
Nov
(123) |
Dec
(186) |
2016 |
Jan
(166) |
Feb
(100) |
Mar
(11) |
Apr
(4) |
May
(24) |
Jun
(13) |
Jul
(34) |
Aug
(18) |
Sep
(8) |
Oct
(49) |
Nov
(69) |
Dec
(33) |
2017 |
Jan
(20) |
Feb
(29) |
Mar
(2) |
Apr
(4) |
May
(33) |
Jun
(32) |
Jul
(16) |
Aug
(8) |
Sep
|
Oct
(67) |
Nov
(39) |
Dec
(4) |
2018 |
Jan
(29) |
Feb
(42) |
Mar
(2) |
Apr
(5) |
May
(13) |
Jun
(24) |
Jul
(160) |
Aug
(76) |
Sep
(64) |
Oct
(42) |
Nov
(47) |
Dec
(32) |
2019 |
Jan
(33) |
Feb
(29) |
Mar
(36) |
Apr
(11) |
May
(11) |
Jun
(18) |
Jul
(20) |
Aug
(11) |
Sep
(7) |
Oct
(16) |
Nov
(3) |
Dec
(20) |
2020 |
Jan
(10) |
Feb
|
Mar
(10) |
Apr
(13) |
May
(53) |
Jun
(26) |
Jul
(8) |
Aug
(20) |
Sep
(8) |
Oct
(60) |
Nov
(93) |
Dec
(119) |
2021 |
Jan
(20) |
Feb
(54) |
Mar
(26) |
Apr
(17) |
May
(200) |
Jun
(231) |
Jul
(124) |
Aug
(100) |
Sep
(25) |
Oct
(18) |
Nov
(17) |
Dec
(93) |
2022 |
Jan
(129) |
Feb
(59) |
Mar
(58) |
Apr
(70) |
May
(39) |
Jun
(22) |
Jul
(83) |
Aug
(110) |
Sep
(65) |
Oct
(80) |
Nov
(42) |
Dec
(19) |
2023 |
Jan
(145) |
Feb
(118) |
Mar
(179) |
Apr
(76) |
May
(46) |
Jun
(67) |
Jul
(76) |
Aug
(69) |
Sep
(31) |
Oct
(52) |
Nov
(82) |
Dec
(46) |
2024 |
Jan
(51) |
Feb
(97) |
Mar
(50) |
Apr
(51) |
May
(150) |
Jun
(96) |
Jul
(117) |
Aug
(69) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Eric A. <e....@jp...> - 2024-08-21 21:09:44
|
Hi Ralf, > That is NOT correct. GEMMIS was the interface to allow two (any two) > memory managers to work together, nicely. That is interesting to know, although it sounds like a very specific use case. For classic DOS extenders, VCPI or DPMI are enough. You can load DPMI providers using VCPI, or your OS can directly provide DPMI without having to provide VCPI. Your CAD software apparently needed something more powerful than a DOS extender, given that it had to contain its very own memory manager which then had to cooperate with others. In the case of Windows, I would say multitasking is the main difference between V86MMGR and EMM386, which forces Windows to switch to a built-in memory manager while in 386enh mode, instead of just using/being a DOS extender. > And the issue is not only for Windows, for example, to take over the > memory management FROM EMM386 (or CEMM, QEMM, 386Max, ...) but when > exiting, giving that memory management task and CPU state) BACK to DOS. Sure, you want both aspects if you want GEMMIS. My doubt is about who apart from Windows wanted GEMMIS. Of course I am impressed that your CAD was one of those "whos" :-) Do you have other specific examples of software containing cooperating memory managers, beyond Windows and your CAD? Regards, Eric |
From: Ralf Q. <fre...@gm...> - 2024-08-21 20:52:28
|
On 8/21/2024 1:32 PM, Eric Auer via Freedos-devel wrote: > > Hi Ralf and Steve, > > Our EMM386 has been supporting VCPI for quite a while ;-) better would be "some" VCPI suuport... > > In ancient times, free EMM386 versions without VCPI existed. > Those were not even compatible with DOS extenders or DPMI > hosts (CWSDPMI, DPMIONE etc.) which was quite a limitation. That's why VCPI came into play... > GEMMIS is a different story. It tells Windows that internal > state of EMM386 is structured exactly as Windows expects, so > it can import the state and replace the entire EMM386 in RAM > by something built into Windows itself, on the fly, which it > has to do in 386enh mode. WfW is no fun without 386enh mode, > Win3 was acceptable, Win9x is not even possible without it. > > The easiest and most obvious solution to that problem is to > use the EMM386 for DOS which comes with Windows itself :-) > > But only Windows cares about GEMMIS, no other apps do. That is NOT correct. GEMMIS was the interface to allow two (any two) memory managers to work together, nicely. We had the GEMMIS specs back in those days due to the CAD software that we developed having its own memory manager and running in protected mode (first 80286, then 386), well before "memory managers" and "DOS Extenders" became a thing. And our problem was that clients always ran into problems when they already had a (standard for their version of DOS) memory manager installed. That's why for some time, we worked rather closely with Compaq (one of our reseller in Switzerland at that time was also one of the largest Compaq retailers in Europe) as well as Quarterdeck and Qualitas. GEMMIS was the specs that defined how two memory managers could work along side each other, Windows was the initial case for Microsoft to come up with that specification, in order to have Windows in enhanced mode play along nicely. But there were other applications as well, not only our CAD system. And the issue is not only for Windows, for example, to take over the memory management FROM EMM386 (or CEMM, QEMM, 386Max, ...) but when exiting, giving that memory management task and CPU state) BACK to DOS... Ralf |
From: Steve N. <uso...@bu...> - 2024-08-21 20:34:11
|
On Wed, 21 Aug 2024, Ralf Quint via Freedos-devel wrote: > On 8/16/2024 1:43 AM, Steve Nickolas via Freedos-devel wrote: >> >> Is the EMM386 in MS-DOS 4.x new enough for that? > I haven't specifically looked for that, but given that the source code > released is likely an early version of MS-DOS 4.0, it could be that this is > not included. > At the company that I worked at in 1990 (1985 through 1994 overall), we had a > version of a VCPI compatible CEMM (Compaq's EMS memory manager) provided for > use with Compaq/MS-DOS 3.31, and also in early versions of QEMM and 386Max. > Just looked this actually up, and VCPI was first included by the internal > memory manager of what would become Windows 3.0 (Windows386) and was part of > EMM386.EXE (not .SYS!) released with DOS 5.0. Didn't think so (though see below). > The "secret sauce" to include VPCI might be in the GEMMIS (Global EMM Import > Specification) documentation and that wasn't publicly available back then > (Novell (in)famously didn't get a copy of the specs)... And IIRC we have... it's 386^MAX, right?... which supports it. Such code couldn't be migrated directly into EMM386 without requiring it to get GNU'd, but concepts, perhaps, could. Be nice to have a newer emm386, but that we have anything legitimately is a miracle already. -uso. |
From: Eric A. <e....@jp...> - 2024-08-21 20:33:17
|
Hi Ralf and Steve, Our EMM386 has been supporting VCPI for quite a while ;-) In ancient times, free EMM386 versions without VCPI existed. Those were not even compatible with DOS extenders or DPMI hosts (CWSDPMI, DPMIONE etc.) which was quite a limitation. GEMMIS is a different story. It tells Windows that internal state of EMM386 is structured exactly as Windows expects, so it can import the state and replace the entire EMM386 in RAM by something built into Windows itself, on the fly, which it has to do in 386enh mode. WfW is no fun without 386enh mode, Win3 was acceptable, Win9x is not even possible without it. The easiest and most obvious solution to that problem is to use the EMM386 for DOS which comes with Windows itself :-) But only Windows cares about GEMMIS, no other apps do. So while it would be nice to have something more modern than MS EMM386 to use with MS Windows, you can still use all Windows features by sticking to MS or other closed source EMM386, or by just not loading any EMM386 at all. https://en.wikipedia.org/wiki/EMM386#Overview Regarding licenses, the mentioned Wikipedia article tells us that DOSBOX and 386MAX both support GEMMIS, so we have GPL2 and GPL3 licensed implementations of GEMMIS, which is a lot better than having to rely on ancient MS DOS releases. https://github.com/sudleyplace/386MAX/tree/main/386MAX Look for the OEM_WIN3 case. It affects 45 source files :-/ In particular, "EMM Paging Import" stuff in 9 files matters, but there also is Windows 3 UMB Instance data and more. I believe 386MAX makes itself Win3 compatible on demand: See im particular QMAX_IM2.ASM and QMAX_OVR.ASM which also talks of the Win3 "unusual way in which V86MMGR..." :-p It supports GPIS 1.11 with and GPIS 1.0 without UMB stuff. The problem is that most drivers which are not MS EMM386 and do not want to limit themselves to the very same data structures for state as MS EMM386 used have to calculate structures looking like the MS ones to satisfy Windows. Implementing EMM386 already is very challenging. Adding GEMMIS support will make your code more ugly and complex. Regards, Eric PS: How about just using 386MAX if you prefer open source instead of old MS EMM386 bundled with Windows? Yet another method which avoids having to do huge updates in JEMM386. 386MAX also supports I/O trapping, nice for virtual SB16 style drivers, as MS EMM386 compatible int 2f.4a15 API :-) Be aware that 386MAX has > 200 000 lines of ASM and INC :-o |
From: Ralf Q. <fre...@gm...> - 2024-08-21 19:40:49
|
On 8/16/2024 1:43 AM, Steve Nickolas via Freedos-devel wrote: > Or maybe to implement the VCPI? >> >> Aitor >> > > Is the EMM386 in MS-DOS 4.x new enough for that? I haven't specifically looked for that, but given that the source code released is likely an early version of MS-DOS 4.0, it could be that this is not included. At the company that I worked at in 1990 (1985 through 1994 overall), we had a version of a VCPI compatible CEMM (Compaq's EMS memory manager) provided for use with Compaq/MS-DOS 3.31, and also in early versions of QEMM and 386Max. Just looked this actually up, and VCPI was first included by the internal memory manager of what would become Windows 3.0 (Windows386) and was part of EMM386.EXE (not .SYS!) released with DOS 5.0. The "secret sauce" to include VPCI might be in the GEMMIS (Global EMM Import Specification) documentation and that wasn't publicly available back then (Novell (in)famously didn't get a copy of the specs)... Ralf |
From: <je...@sh...> - 2024-08-16 22:08:24
|
Hi Tom, > On Aug 16, 2024, at 10:33 AM, tom ehlert via Freedos-devel <fre...@li...> wrote: > > Hallo Herr Jerome Shidel via Freedos-devel, > > am Freitag, 16. August 2024 um 12:19 schrieben Sie: > >> Hi Eric, > >> I was having similar issues. So, switched to VSBHDA. Afterwards, I was still experiencing lots of problems and submitted a bug report. But as it turned out, it was user error. I just needed to change the configuration settings and that fixed me right up. > > Now it would be cool if you shared the working configuration and the reason the configuration before filed. > > "I managed to find a solution" mails without presenting the solution is bragging and wasting everybody's time. > > Tom VSBHDA comes with a couple example startup batch files. I only use the one called START.BAT. Originally, it contained the following lines: @echo off rem run vsbhda jload -q qpiemu.dll jload -q jhdpmi.dll lh hdpmi32i -x2 rem set blaster=A220 I7 D1 T3 rem set blaster=A220 I7 D1 T4 set blaster=A220 I7 D1 H5 T6 vsbhda After Japheth told me what I should try, I simply changed that file to the following: @echo off rem run vsbhda jload -q qpiemu.dll jload -q jhdpmi.dll lh hdpmi32i -x2 rem set blaster=A220 I7 D1 T3 rem set blaster=A220 I7 D1 T4 rem set blaster=A220 I7 D1 H5 T6 set blaster=A220 I2 D1 H5 T6 vsbhda /VOL9 And for me at least, it fixed the crashing on both the Acer Aspireone D250-1924 and the Toshiba Satellite P25-S5092. Even though I was getting JEMM exceptions, my problem was most likely caused by an IRQ conflict. Jerome |
From: Jerome S. <je...@sh...> - 2024-08-16 20:33:23
|
Hi Tommy, > On Aug 16, 2024, at 10:34 AM, tom ehlert via Freedos-devel <fre...@li...> wrote: > > Hallo Herr Jerome Shidel via Freedos-devel, > > am Freitag, 16. August 2024 um 12:19 schrieben Sie: > >> Hi Eric, > >> I was having similar issues. So, switched to VSBHDA. Afterwards, I was still experiencing lots of problems and submitted a bug report. But as it turned out, it was user error. I just needed to change the configuration settings and that fixed me right up. > > Now it would be cool if you shared the working configuration and the reason the configuration before filed. I’m not at my machine at present. But, later I will try to remember to do that. > "I managed to find a solution" mails without presenting the solution is bragging and wasting everybody's time. Nah, it is worse than that. I didn’t find a solution. I submitted an issue and begged Japheth for help. He was kind enough to tell me what to do. > Tom > :-) Jerome > > > _______________________________________________ > Freedos-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-devel |
From: Jerome S. <je...@sh...> - 2024-08-16 20:24:17
|
Hi Eric, > On Aug 16, 2024, at 9:48 AM, Eric Auer via Freedos-devel <fre...@li...> wrote: > > > Hi Jerome, > > please be more specific, which games crashed with sbemu for you, I honestly don’t recall. I only did a very little testing on one of my machines. I don’t even remember if it was the P4 or Atom. I was very busy at the time and it was sort-of working. I decided to try again later. When later arrived, I was aware of the VSBHDA fork. Which to my understanding of the documentation, works better with JEMM. So, I decided to try to get that working instead. > on which hardware and with which configuration, with which jemmex > error messages? Initial issues were no sound in some games. Random computer freezing and strangely frequent JEMM exceptions while just using the command line. Most of my testing was in two games. SaysWho and FreeDOM. SaysWho is that simple memory game I made. In part, it was to test the audio driver for my gaming engine. The game will use the PC speaker for sound. However, if an Adlib compatible sound card is present it will use that for audio. As you know, all those old SB cards and many others are Adlib compatible. That game would run and there would be no sound at all. Which meant it saw it was compatible with Adlib, but no sound came out of it. FreeDOM had sound. But, would freeze after a little while. > And which configuration of vsbhda made which of > the games work and which are still not working? Changing the BLASTER environment variable setting for the IRQ fixed it. I think using IRQ 2 instead of the more common default value was the solution. Both of those games now work without issue. I also recommend setting the emulator volume to max when loading it. If not specified, it can be very quiet. Without that setting, when testing on the ACER Netbook, it was barely audible at all. > Maybe you could even share the insight with Phil's Computer Lab? > > Thank you :-) Good to know that you got (most?) things to work :-) Yup, mostly working very well. Since I don’t play games often and to insure there are no conflicts when running the emulator, I don’t have either of the machines that need it for sound boot with the emulator running. If need be, I’ll can just run it later as needed for games. The ACER netbook has very small speakers and is barely worth having sound. The Toshiba P4 is a battleship sized laptop. Or, more accurately a desktop substitute. The audio from it is loud when the emulator running. My 486 notebook does not have a sound card in its docking station at present. My Pentium Pro has an SB AWE64 Gold and does not need the emulator. > Eric :-) Jerome > > >> Hi Eric, >> I was having similar issues. So, switched to VSBHDA. Afterwards, I >> was still experiencing lots of problems and submitted a bug report. >> But as it turned out, it was user error. I just needed to change >> the configuration settings and that fixed me right up. >> :-) >>>> On Aug 15, 2024, at 6:13 PM, Eric Auer via Freedos-devel <fre...@li...> wrote: >>> >>> >>> Hi! I have been watching >>> >>> https://www.youtube.com/watch?v=K6-AlpCEqpc >>> >>> where Phils Computer Lab tests SBEMU with the pre-installed >>> FreeDOS image which you can download from SBEMU's crazii... > > > > > > _______________________________________________ > Freedos-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-devel |
From: tom e. <te...@dr...> - 2024-08-16 14:33:46
|
Hallo Herr Jerome Shidel via Freedos-devel, am Freitag, 16. August 2024 um 12:19 schrieben Sie: > Hi Eric, > I was having similar issues. So, switched to VSBHDA. Afterwards, I was still experiencing lots of problems and submitted a bug report. But as it turned out, it was user error. I just needed to change the configuration settings and that fixed me right up. Now it would be cool if you shared the working configuration and the reason the configuration before filed. "I managed to find a solution" mails without presenting the solution is bragging and wasting everybody's time. Tom |
From: Jim H. <jh...@fr...> - 2024-08-16 14:15:07
|
Jim Hall wrote: > > > > I published an article last week on Both.org about how to convert WordStar files to HTML. > > > > Someone asked me if I could share the code from the article in a GitHub repo. > Rugxulo wrote: > > You forgot to include "sample.ws" (or any other test suite). > Oops, forgot about that (a lot going on lately). I've added SAMPLE.WS and a few others in a 'wordstar' folder. |
From: Eric A. <e....@jp...> - 2024-08-16 13:48:27
|
Hi Jerome, please be more specific, which games crashed with sbemu for you, on which hardware and with which configuration, with which jemmex error messages? And which configuration of vsbhda made which of the games work and which are still not working? Maybe you could even share the insight with Phil's Computer Lab? Thank you :-) Good to know that you got (most?) things to work :-) Eric > Hi Eric, > > I was having similar issues. So, switched to VSBHDA. Afterwards, I > was still experiencing lots of problems and submitted a bug report. > But as it turned out, it was user error. I just needed to change > the configuration settings and that fixed me right up. > > :-) > >> On Aug 15, 2024, at 6:13 PM, Eric Auer via Freedos-devel <fre...@li...> wrote: >> >> >> Hi! I have been watching >> >> https://www.youtube.com/watch?v=K6-AlpCEqpc >> >> where Phils Computer Lab tests SBEMU with the pre-installed >> FreeDOS image which you can download from SBEMU's crazii... |
From: Rugxulo <ru...@gm...> - 2024-08-16 11:04:04
|
You forgot to include "sample.ws" (or any other test suite). On Mon, Aug 12, 2024 at 3:37 PM Jim Hall via Freedos-devel <fre...@li...> wrote: > > I published an article last week on Both.org about how to convert WordStar files to HTML. > > Someone asked me if I could share the code from the article in a GitHub repo. |
From: <je...@sh...> - 2024-08-16 10:19:25
|
Hi Eric, I was having similar issues. So, switched to VSBHDA. Afterwards, I was still experiencing lots of problems and submitted a bug report. But as it turned out, it was user error. I just needed to change the configuration settings and that fixed me right up. :-) > On Aug 15, 2024, at 6:13 PM, Eric Auer via Freedos-devel <fre...@li...> wrote: > > > Hi! I have been watching > > https://www.youtube.com/watch?v=K6-AlpCEqpc > > where Phils Computer Lab tests SBEMU with the pre-installed > FreeDOS image which you can download from SBEMU's crazii. > > At one point, a game crashes with a loop of the following, > some leading 0s omitted by me: > > JemmEx: exception 06 occured at CS:EIP=9689:FF14, ERRC=0 > SS:ESP=D70A:C7D4 EBP=FFFF EFL=33093 CR0=80000013 CR4=200 > EAX=FFFF9002 EBX=FFFF0007 ECX=FFFFFF00 EDX=FFFFF1EC > ESI=40001A EDI=0EFF > DS=0040 ES=FFFF FS=FFFF GS=00D9 [CS:IP]=FF FF FF FF FF FF FF FF > Press ESC to abort program > > JemmEx: exception 06 occured at CS:EIP=9689:FF14, ERRC=0 > SS:ESP=D70A:C7BE EBP=FFFF EFL=33093 CR0=80000013 CR4=200 > EAX=FFFF9002 EBX=FFFF0007 ECX=FFFFFF00 EDX=FFFFF1EC > ESI=40001A EDI=0EFF > DS=0040 ES=FFFF FS=FFFF GS=00D9 [CS:IP]=FF FF FF FF FF FF FF FF > Press ESC to abort program > > and so on, all registers except ESP stay constant and the > video shows a loop of JemmEx messages scrolling through as > the stack pointer goes down while CS:EIP is frozen pointing > to an impossible FF FF opcode. Exc. 06 is undefined opcode. > > As the messages scroll so fast, I am not sure whether each > instance actually shows all lines. The may even be nested? > > Later in the same video, F-117A mgraphic crashes, with far > more readable JemmEx reactions: > >> JemmEx: exception 0C occured at CS:EIP=0360:2A01, ERRC=0 >> SS:ESP=0360:FFEA EBP=0 EFL=33202 CRO=80000013 CR4=00000200 >> EAX=0021 EBX=0 ECX=0 EDX=FFEC ESI=FFFF EDI=01FF >> DS=0350 ES=0350 FS=0350 GS=O2BA [C3:IP]=36 8B 28 36 8B 88 B8 01 >> Press ESC to abort progran >> JemmEx: exception 06 occured at CS:EIP=0000:0108, ERRC=0 >> SS:ESP=0914:10002 EBP=C600 EFL=00033246 CRO=80000013 CR4=200 >> EAX=0 EBX=0 ECX=0 EDX=0 ES1=0 EDI=0 >> DS=0 ES=0 FS=0 GS=0 [C3:IP]=65 F0 00 F0 36 03 00 C0 >> Press ESC to abort program >> JemmEx: exception 0D occured at CS:EIP=D79B:0984, ERRC=0 >> SS:ESP=00D9:08D0 EBP=0 EFL=33093 CRO=80000013 CR4=200 >> EAX=00FF EBX=0 ECX=FF54 EDX=0904 ESI=A8B1 EDI=0 >> DS=00D9 ES=D7A0 FS=0 GS=0 [CS:IP]=67 66 2E 83 3C 9D 4C 04 > ... > > This starts with a stack error first, "mov bp,[ss:bx+si]" > wrapping the end of the first 64 kB of the stack segment, > then an undefined opcode exception apparently caused by an > invalid locked combination saying GS: LOCK: ADD AL,DH etc. > and finally a general protection fault. > > Of course this does not tell much about whether it was > futile to try to abort the program after the first stack > exception, but note how there is no LOOP of exceptions > here, so it gets a lot easier to read the messages :-) > > Thanks to https://www.sandpile.org/ for their tables :-) > > Likewise, the F-19 game also crashes, even with loadfix: > > JemmEx: exception 0D occured at CS:EIP=1025:4142, ERRC=0 > SS:ESP:2025:DAC6 EBP=DAD0 EFL=33282 CR0=80000013 CR4=200 > EAX=0 EBX=FFFE ECX=9BCC EDX=4605 ESI=C88C EDI=0 > DS=2025 ES=46E8 FS=1015 GS=02BA [CS:IP]=89 47 01 89 7F 03 83 C6 > > which is mov [bx+1],ax and again wraps the end of some > 64 kB boundary, but you actually get to read the text > without a loop :-) > > *So now I wonder why JemmEx exception messages sometimes* > *end up in a loop, while usually they do not, luckily.* > > The video features kernel 2043 (2021-05-14) FAT32 Watcom 386, > JemmEx 5.84 02/11/23, QPIEMU, FreeCOM 0.85a 2021-07-10, > UDVD2 (not used, no drive in the shown thin client), > SBEMU (in VIA VT82XX AC97 mode), CuteMouse 2.1beta4, > originally based on the FreeDOS 1.3 distro, it seems. > > It also mentions Aladdin failing to start, with the > message "XMS allocation error.." (sic!) and Lotus 3 > crashing with "Interrupt divide by zero, stack: > D34C 0360 3002 518D ADE8 EB6F EB4A 314A > E8D2 B117 C689 C389 7C80" > > In Sam+Max, audio setup fails with "hdpmi: fatal exit 0007". > In Space Quest 5 adlib works, while emulated SB use hangs. > > Finally, some related GOOD news from this > video: TETRIS CLASSIC is working fine :-) > > It is one of the games mentioned in my > "game compatibility updates?" post as a > game which was NOT working in 2022 :-) > > Cheers, Eric > > > > _______________________________________________ > Freedos-devel mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freedos-devel |
From: Steve N. <uso...@bu...> - 2024-08-16 08:43:09
|
On Fri, 16 Aug 2024, Aitor Santamaría via Freedos-devel wrote: > Hi, > > > On Wed, 8 May 2024 at 04:19, Ralf Quint via Freedos-devel < > fre...@li...> wrote: > <snip> >> What could be however of value is to look at the source for some of the >> "trouble spots". For example, for me, the with FreeDOS supplied memory >> managers always give me a really hard time on real hardware. This >> release comes with the source of EMM/MEMM, which could help to glean >> some insights that could help to solve such memory issues. Or how EMM >> deals with DMA of various hardware, like sound cards, hard drive/floppy >> adapters or network adapters. >> > Or maybe to implement the VCPI? > > Aitor > Is the EMM386 in MS-DOS 4.x new enough for that? -uso. |
From: Aitor S. <ait...@gm...> - 2024-08-16 08:02:30
|
Hi, On Wed, 8 May 2024 at 04:19, Ralf Quint via Freedos-devel < fre...@li...> wrote: > On 5/3/2024 8:54 PM, Steve Nickolas via Freedos-devel wrote: > > Sorry for being a bit late to this "party", but just some quick thoughts. > I am even later... > What could be however of value is to look at the source for some of the > "trouble spots". For example, for me, the with FreeDOS supplied memory > managers always give me a really hard time on real hardware. This > release comes with the source of EMM/MEMM, which could help to glean > some insights that could help to solve such memory issues. Or how EMM > deals with DMA of various hardware, like sound cards, hard drive/floppy > adapters or network adapters. > Or maybe to implement the VCPI? Aitor |
From: Eric A. <e....@jp...> - 2024-08-15 22:14:12
|
Hi! I have been watching https://www.youtube.com/watch?v=K6-AlpCEqpc where Phils Computer Lab tests SBEMU with the pre-installed FreeDOS image which you can download from SBEMU's crazii. At one point, a game crashes with a loop of the following, some leading 0s omitted by me: JemmEx: exception 06 occured at CS:EIP=9689:FF14, ERRC=0 SS:ESP=D70A:C7D4 EBP=FFFF EFL=33093 CR0=80000013 CR4=200 EAX=FFFF9002 EBX=FFFF0007 ECX=FFFFFF00 EDX=FFFFF1EC ESI=40001A EDI=0EFF DS=0040 ES=FFFF FS=FFFF GS=00D9 [CS:IP]=FF FF FF FF FF FF FF FF Press ESC to abort program JemmEx: exception 06 occured at CS:EIP=9689:FF14, ERRC=0 SS:ESP=D70A:C7BE EBP=FFFF EFL=33093 CR0=80000013 CR4=200 EAX=FFFF9002 EBX=FFFF0007 ECX=FFFFFF00 EDX=FFFFF1EC ESI=40001A EDI=0EFF DS=0040 ES=FFFF FS=FFFF GS=00D9 [CS:IP]=FF FF FF FF FF FF FF FF Press ESC to abort program and so on, all registers except ESP stay constant and the video shows a loop of JemmEx messages scrolling through as the stack pointer goes down while CS:EIP is frozen pointing to an impossible FF FF opcode. Exc. 06 is undefined opcode. As the messages scroll so fast, I am not sure whether each instance actually shows all lines. The may even be nested? Later in the same video, F-117A mgraphic crashes, with far more readable JemmEx reactions: > JemmEx: exception 0C occured at CS:EIP=0360:2A01, ERRC=0 > SS:ESP=0360:FFEA EBP=0 EFL=33202 CRO=80000013 CR4=00000200 > EAX=0021 EBX=0 ECX=0 EDX=FFEC ESI=FFFF EDI=01FF > DS=0350 ES=0350 FS=0350 GS=O2BA [C3:IP]=36 8B 28 36 8B 88 B8 01 > Press ESC to abort progran > > JemmEx: exception 06 occured at CS:EIP=0000:0108, ERRC=0 > SS:ESP=0914:10002 EBP=C600 EFL=00033246 CRO=80000013 CR4=200 > EAX=0 EBX=0 ECX=0 EDX=0 ES1=0 EDI=0 > DS=0 ES=0 FS=0 GS=0 [C3:IP]=65 F0 00 F0 36 03 00 C0 > Press ESC to abort program > > JemmEx: exception 0D occured at CS:EIP=D79B:0984, ERRC=0 > SS:ESP=00D9:08D0 EBP=0 EFL=33093 CRO=80000013 CR4=200 > EAX=00FF EBX=0 ECX=FF54 EDX=0904 ESI=A8B1 EDI=0 > DS=00D9 ES=D7A0 FS=0 GS=0 [CS:IP]=67 66 2E 83 3C 9D 4C 04 ... This starts with a stack error first, "mov bp,[ss:bx+si]" wrapping the end of the first 64 kB of the stack segment, then an undefined opcode exception apparently caused by an invalid locked combination saying GS: LOCK: ADD AL,DH etc. and finally a general protection fault. Of course this does not tell much about whether it was futile to try to abort the program after the first stack exception, but note how there is no LOOP of exceptions here, so it gets a lot easier to read the messages :-) Thanks to https://www.sandpile.org/ for their tables :-) Likewise, the F-19 game also crashes, even with loadfix: JemmEx: exception 0D occured at CS:EIP=1025:4142, ERRC=0 SS:ESP:2025:DAC6 EBP=DAD0 EFL=33282 CR0=80000013 CR4=200 EAX=0 EBX=FFFE ECX=9BCC EDX=4605 ESI=C88C EDI=0 DS=2025 ES=46E8 FS=1015 GS=02BA [CS:IP]=89 47 01 89 7F 03 83 C6 which is mov [bx+1],ax and again wraps the end of some 64 kB boundary, but you actually get to read the text without a loop :-) *So now I wonder why JemmEx exception messages sometimes* *end up in a loop, while usually they do not, luckily.* The video features kernel 2043 (2021-05-14) FAT32 Watcom 386, JemmEx 5.84 02/11/23, QPIEMU, FreeCOM 0.85a 2021-07-10, UDVD2 (not used, no drive in the shown thin client), SBEMU (in VIA VT82XX AC97 mode), CuteMouse 2.1beta4, originally based on the FreeDOS 1.3 distro, it seems. It also mentions Aladdin failing to start, with the message "XMS allocation error.." (sic!) and Lotus 3 crashing with "Interrupt divide by zero, stack: D34C 0360 3002 518D ADE8 EB6F EB4A 314A E8D2 B117 C689 C389 7C80" In Sam+Max, audio setup fails with "hdpmi: fatal exit 0007". In Space Quest 5 adlib works, while emulated SB use hangs. Finally, some related GOOD news from this video: TETRIS CLASSIC is working fine :-) It is one of the games mentioned in my "game compatibility updates?" post as a game which was NOT working in 2022 :-) Cheers, Eric |
From: Eric A. <e....@jp...> - 2024-08-15 20:20:45
|
Hi! As Lisa somehow managed to first change her email address, then drop both the old and new address, I am moving an off-list discussion on game compatibility back to the list. Which also is a good thing given that I myself wonder how much compatibility improved since 2022 :-) Her https://gitlab.com/FreeDOS/issue-reporting/-/issues/56 is not exactly useful in current state. It just points to a two year old youtube video which mentions that some games fail in FreeDOS. We had a thread on the mailing list about that video back then: https://sourceforge.net/p/freedos/mailman/freedos-user/thread/SY4P282MB3938F63400CB1FA5BBB955D7880C9%40SY4P282MB3938.AUSP282.PROD.OUTLOOK.COM/ (2022-03-04 to 2022-03-10) Some highlights: - the default config should not be JEMMEX with max UMB, but rather HIMEM, or at least a more humble EMM configuration - back in the time, the default partitioning into piles of FAT16 partitions was rather user-un-friendly - people wondered, and still do, about WfW 3.11 compatibility, so we should make the patched kernel more easily available - there are a number of DSI Accolade games, including Test Drive 2 and Grand Prix Circuit, which all fail in FreeDOS - Carlos T has a large game collection for compat testing! He listed the following as not working in FreeDOS then: * Alone in the Dark 1 and 2 (floppy versions only, CD versions run fine) * Alpha Waves * Empire Soccer * Frontier Elite * Grand Prix Circuit * Test Drive 2 * The Cycles * Tetris Classic * Virtual Chess - Stas mentioned that FDPP improved Test Drive compatibility using https://github.com/dosemu2/fdpp/commit/c6efa7a203c8aafe8da952d6405ad5dfb49fd469#diff-e9118389bd658345f94d54c6159dc16b60454e193c33f16184d4fd5526180329 and that Test Drive must be run from A: to F: not G: to Z: - of course, quite a few games have Runtime Error 200 speed issues. Lisa also made a ticket about KRAPTOR palette issues in Virtual Box: https://gitlab.com/FreeDOS/games/kraptor/-/issues/3 This is a known bug in Virtual Box, not in FreeDOS. She also asked for FreeDOOM 0.13.0 to become available for DOS: https://gitlab.com/FreeDOS/games/freedoom/-/issues/2 Finally, she apparently wonders how to share files between her host windows and the FreeDOS inside Virtual Box. I guess some people here use Virtual Box, so they can answer that, but to be honest, I recommend NOT to use Virtual Box. Just use a VM which is optimized specifically for DOS, there are plenty of those :-) Regards, Eric |
From: Andrew B. <aj...@sp...> - 2024-08-15 00:00:04
|
Hi Bernd, On Wed, 14 Aug 2024 16:37:49 +0200 Bernd Böckmann via Freedos-devel <fre...@li...> wrote: > Hi, > > > Hi Jeremy, hi Bernd, > > is there a decision done what will happen with the "label" problem > > (the labels are written to two different positions) see: > > https://gitlab.com/FreeDOS/issue-reporting/-/issues/31 as this > > problems runs through some more commands if I remember right? > > none that I know of. I think the last one who dealt with the label > stuff was Andrew Bird? Perhaps he knows more... > > A kernel commit was merged on November 10th, 2022: > https://github.com/andrewbird/kernel/commit/106d4cd73b86664776857a4d5e48d106c12bfdcf > > > Bernd > So I have a draft PR open (not ready for merge) on https://github.com/FDOS/kernel/pull/86/commits with that particular commit (which is fine itself), but there are other fixes required in the kernel to fully fix the label problems identified in https://github.com/FDOS/label/issues/17 regarding filename / label collisions. I set out to fix the label problems for both FreeDOS kernel and FDPP was hoping to provide one set of patches that could be applied to each. During my investigation I wrote some label tests for the Dosemu test suite https://github.com/dosemu2/dosemu2/pull/1801/commits and set about fixing the label problems on FDPP first. After much debate a smaller PR https://github.com/dosemu2/fdpp/pull/202 of mine was merged, but this was only possible due to some filesystem fixes that @stsp did for FDPP. With those fixes the label tests now pass on FDPP and I believe the label issue #17 problems would be resolved if the same thing could be done to FreeDOS kernel. The missing bit is that @stsp's changes would need porting to suit FreeDOS. The relevant changes are in the range db77489e0a90adf8b8882b271f1ecc1b94c8de9a to b35072df368579f2a48c45d072ee7fb41c790669 (I'd point you to the commits on Github but it seems to be down), but since I don't understand them fully it would need someone more familiar with fatfs and FreeDOS to do it. If that were done, I'd be happy to rebase and tweak my #86 PR here. Hope that helps, Andrew |
From: <je...@sh...> - 2024-08-14 23:44:42
|
Hi All, > On Aug 14, 2024, at 7:28 PM, Jerome Shidel via Freedos-devel <fre...@li...> wrote: > > Hi All, > > Just was over on GitHub and to submit a bug report on FreeCOM. > Hit submit and got the angry unicorn page. > Hopefully it will be up again soon. > > :-) > > Jerome Github is back up again. So, I was able to post the bug report. https://github.com/FDOS/freecom/issues/107 <https://github.com/FDOS/freecom/issues/107> :-) Jerome |
From: <je...@sh...> - 2024-08-14 23:29:02
|
Hi All, Just was over on GitHub and to submit a bug report on FreeCOM. Hit submit and got the angry unicorn page. Hopefully it will be up again soon. :-) Jerome |
From: Bernd B. <ber...@bo...> - 2024-08-14 14:38:11
|
Hi, > Hi Jeremy, hi Bernd, > is there a decision done what will happen with the "label" problem (the labels are written to two different positions) > see: https://gitlab.com/FreeDOS/issue-reporting/-/issues/31 as this problems runs through some more commands if I remember right? none that I know of. I think the last one who dealt with the label stuff was Andrew Bird? Perhaps he knows more... A kernel commit was merged on November 10th, 2022: https://github.com/andrewbird/kernel/commit/106d4cd73b86664776857a4d5e48d106c12bfdcf Bernd |
From: Darik H. <da...@gm...> - 2024-08-14 14:21:23
|
> is there a decision done what will happen with the "label" problem (the labels are written to two different positions) see: https://gitlab.com/FreeDOS/issue-reporting/-/issues/31 as this problems runs through some more commands if I remember right? Note that DOSBox-X has recent fixes for LABEL bugs that are also in FreeDOS. eg: https://github.com/joncampbell123/dosbox-x/commit/fbd8de0397f84ba65a31a7d599a5b333dfcf3cbe |
From: <per...@gm...> - 2024-08-13 19:50:20
|
Version 1.7 released https://github.com/FDOS/xcopy/releases/tag/v1.7 - really fix timestamp bug (hopefully), delays updating timestamp until after copy complete - fix sourceforge bug# 178, allow switches specified without spaces between them - fix /D:<date> to work skip older files than date even if no file exists at destination On Fri, Aug 9, 2024 at 7:18 PM <per...@gm...> wrote: ... > > A new version of xcopy has been published: > https://github.com/FDOS/xcopy/releases/tag/v1.6 > - fix bug causing timestamps to not always be set correctly (GitHub bug# 8) > - fix bug causing stack corruption on Open Watcom builds (GitHub bug# 7) > - improve free disk space calculation (fix GitHub bug# 10) Jeremy |
From: Fritz M. <fri...@ma...> - 2024-08-13 18:18:25
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi Jeremy, hi Bernd,</div> <div> </div> <div>is there a decision done what will happen with the "label" problem (the labels are written to two different positions)</div> <div>see: https://gitlab.com/FreeDOS/issue-reporting/-/issues/31 as this problems runs through some more commands if I remember right?</div> <div> </div> <div>Fritz / Willi</div> <div> <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Sent:</b> Thursday, August 08, 2024 at 10:11 PM<br/> <b>From:</b> "Eric Auer via Freedos-devel" <fre...@li...><br/> <b>To:</b> fre...@li...<br/> <b>Cc:</b> "Eric Auer" <e....@jp...><br/> <b>Subject:</b> Re: [Freedos-devel] Format 0.92 announce Was: Re: Xcopy 1.5</div> <div name="quoted-content"><br/> Hi Jeremy and Bernd,<br/> <br/> > I published a new version of format to fix the couple bugs reported and<br/> > finally got around to merging a pull request adding 128KB cluster support.<br/> ><br/> > <a href="https://github.com/FDOS/format" target="_blank">https://github.com/FDOS/format</a><br/> ><br/> > (I bumped version from 0.91w to 0.92 since almost out of letters and 128KB<br/> > feature seamed to justify at least a small increase in version #)<br/> <br/> Thank you, that was VERY quick! I had noticed the bug reports,<br/> but had not even started yet checking what caused those bugs,<br/> let alone done anything to fix them :-o<br/> <br/> <a href="https://github.com/FDOS/format/commits/master/" target="_blank">https://github.com/FDOS/format/commits/master/</a> tells me that<br/> you and Bernd have actually fixed several things at once:<br/> <br/> - update Watcom makefile<br/> - add 128 kB cluster size support<br/> - a large change for 0.91w:<br/> <br/> <a href="https://github.com/FDOS/format/commit/ea30eef093f2c2a09fe70ef47e1cabd1a60c93a1" target="_blank">https://github.com/FDOS/format/commit/ea30eef093f2c2a09fe70ef47e1cabd1a60c93a1</a><br/> <br/> which fixes a wrong semicolon in savefs.c line 139, renames the<br/> old turboc and watcomc makefiles, updates the main makefile,<br/> fixes a missing */ in main.c line 695 which nested comments,<br/> makes some main.c Write_System_Files step Turbo C only, corrects<br/> the way init.c sets some char/byte values to 0, fixes some other<br/> comment nesting issues in format.h line 217 and floppy.h line 33<br/> and floppy.c line 1024, drops the locking_invalid_drive label<br/> in driveio.c, updates readme, news and contrib and of course<br/> bumps version numbers to 0.91w everywhere.<br/> <br/> - ignores extended keys when entering volume label to fix<br/> <a href="https://github.com/FDOS/format/issues/3" target="_blank">https://github.com/FDOS/format/issues/3</a><br/> <br/> <a href="https://github.com/FDOS/format/commit/9001f74b1dbd4d419cb4c6f7624726eca59b6afc" target="_blank">https://github.com/FDOS/format/commit/9001f74b1dbd4d419cb4c6f7624726eca59b6afc</a><br/> <br/> This now uses int 21.07 with a smarter macro and an extra check.<br/> <br/> - prints more debug info in debug mode, in particular:<br/> tell being done with file system created,<br/> announce record bad clusters step,<br/> and print which type of FAT we use.<br/> <br/> - fixes a stack overflow to fix<br/> <a href="https://github.com/FDOS/format/issues/4" target="_blank">https://github.com/FDOS/format/issues/4</a><br/> <br/> <a href="https://github.com/FDOS/format/commit/72417d51cb1036e2a49fe125f14e2d0e4ce82b1a" target="_blank">https://github.com/FDOS/format/commit/72417d51cb1036e2a49fe125f14e2d0e4ce82b1a</a><br/> <br/> This just makes fat12_fat[6145] static instead of on-stack,<br/> so FORMAT may need a bit more RAM, but a lot less stack :-)<br/> <br/> - and bumps the version to 0.92 :-)<br/> <br/> The previous LSM version was 0.91v (14 Jan 2006) :-o<br/> <br/> I guess the install.txt could be a bit more verbose on OpenWatcom?<br/> <br/> For those who are curious, few exotic TO-DO remain for FORMAT lovers:<br/> <br/> - add Kitten translations<br/> - debug fat32, mirror, unformat etc.<br/> - clean up sources<br/> - fool-proof filesystem locking<br/> - make safe formatting safer<br/> <br/> The 19 year old BUGS text only lists:<br/> <br/> - add more reaction choices to critical I/O errors<br/> - add specific messages when trying to format CD-ROM, SUBST, remote<br/> - some other bugs seem fixed, but could be re-tested<br/> <br/> Thanks Jeremy and Bernd :-)<br/> <br/> Regards, Eric<br/> <br/> <br/> <br/> <br/> _______________________________________________<br/> Freedos-devel mailing list<br/> Fre...@li...<br/> <a href="https://lists.sourceforge.net/lists/listinfo/freedos-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/freedos-devel</a></div> </div> </div> </div></div></body></html> |
From: Jim H. <jh...@fr...> - 2024-08-12 20:36:49
|
If you've been exploring WordStar since author Robert J Sawyer's re-packaging of WordStar for DOS, you may need to convert your new WordStar files to another format afterwards. WordStar has a very simple file format, so I published an article last week on Both.org about how to convert WordStar files to HTML. https://www.both.org/?p=6898 Someone asked me if I could share the code from the article in a GitHub repo, so I have copied the code and adapted a README.md file here: https://github.com/freedosproject/wshtml It's available under the MIT License. |