[Freedos-devel] making himemx and jemmex more foolproof on old bios versions
Hi experts, some interesting observations about an old 486 PC in the thread with Dimitris about "Which freedos on 486" on freedos-user... His BIOS answers with AH=86h, carry=UNCHANGED to int 15.e801, also leaving AL unchanged. So it seems to be a good idea to STC before INT 15 when doing the 15.e801 call :-) Note that AH=86 is a common failure code for int 15 functions. I would also suggest to, in addition, treat AH=UNCHANGED as failure. Another issue is that RBIL says for this call that if AX=BX=0, one should use CX and DX as memory size info instead. However, DOSEMU only sets AX and BX and returns CX=DX=0 while FreeDOS HIMEMX and JEMMEX both look ONLY at CX and DX, without even checking for AX and BX! Luckily DOSEMU also supports the two other int 15 calls for memory info afair, but it seems tricky that DOSEMU and FreeDOS disagree about 15.e801, no? Also, it is interesting that the FreeDOS drivers say that if CX is not 3c00 (the max value) then DX must be treated as 0. This sounds like "memory hole below 16 MB means end of RAM"? Finally, JEMMEX and HIMEMX both say "if CX plus scaled DX < 64 then fall back to 15.88", which is a somewhat weird way to say "if CX and DX are both 0". RBIL writes about int 15.88 versus the carry flag: > the standard BIOS only returns memory between 1MB and 16MB; use AH=C7h > for memory beyond 16MB > not all BIOSes correctly return the carry flag, making this call > unreliable unless one first checks whether it is supported through > a mechanism other than calling the function and testing CF Interestingly, JEMMEX and HIMEMX decide to trust int 15.88 even if it leaves carry unchanged: They CLC before int 15. I think it would be a good idea to check if AH=80, 86 or 88 after the int 15 call even if carry is not set, as all those values would be possible return values if int 15.88 failed. What is confusing: JEMMEX works on the mentioned 486, while HIMEMX does not work, not even with /NOABOVE16 and /X, why? Regards, Eric PS: In theory, int 15.c7 would also be a possible call to get info about memory beyond the first 16 MB without 15.e??? BIOS support, but that would only help for a very specific group of PS/2 machines identified by int 15.c0 - not very useful. PPS: The same PC also fails to boot from FAT32 with any SYS newer than 2.6, so SYS apparently sees LBA support while it does not really boot later? See freedos-user, still ongoing. Unclear regarding SYS 3.6e /FORCE:LBA and /FORCE:CHS options. -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] making himemx and jemmex more foolproof on old bios versions
I looked at int 15h lately, int 15h is not supported on older BIOS versions but every BIOS has it in the time called now. :) Error code 86h means "function not supported" and if you get 80h it means "invalid command" Op woensdag 20 juli 2016 heeft Eric Auer het volgende geschreven: > > Hi experts, > > some interesting observations about an old 486 PC in the thread > with Dimitris about "Which freedos on 486" on freedos-user... > > His BIOS answers with AH=86h, carry=UNCHANGED to int 15.e801, > also leaving AL unchanged. So it seems to be a good idea to > STC before INT 15 when doing the 15.e801 call :-) Note that > AH=86 is a common failure code for int 15 functions. I would > also suggest to, in addition, treat AH=UNCHANGED as failure. > > Another issue is that RBIL says for this call that if AX=BX=0, > one should use CX and DX as memory size info instead. However, > DOSEMU only sets AX and BX and returns CX=DX=0 while FreeDOS > HIMEMX and JEMMEX both look ONLY at CX and DX, without even > checking for AX and BX! Luckily DOSEMU also supports the two > other int 15 calls for memory info afair, but it seems tricky > that DOSEMU and FreeDOS disagree about 15.e801, no? > > Also, it is interesting that the FreeDOS drivers say that if > CX is not 3c00 (the max value) then DX must be treated as 0. > > This sounds like "memory hole below 16 MB means end of RAM"? > > Finally, JEMMEX and HIMEMX both say "if CX plus scaled DX < 64 > then fall back to 15.88", which is a somewhat weird way to say > "if CX and DX are both 0". > > RBIL writes about int 15.88 versus the carry flag: > >> the standard BIOS only returns memory between 1MB and 16MB; use AH=C7h >> for memory beyond 16MB > >> not all BIOSes correctly return the carry flag, making this call >> unreliable unless one first checks whether it is supported through >> a mechanism other than calling the function and testing CF > > Interestingly, JEMMEX and HIMEMX decide to trust int 15.88 > even if it leaves carry unchanged: They CLC before int 15. > > I think it would be a good idea to check if AH=80, 86 or 88 > after the int 15 call even if carry is not set, as all those > values would be possible return values if int 15.88 failed. > > What is confusing: JEMMEX works on the mentioned 486, while > HIMEMX does not work, not even with /NOABOVE16 and /X, why? > > Regards, Eric > > PS: In theory, int 15.c7 would also be a possible call to get > info about memory beyond the first 16 MB without 15.e??? BIOS > support, but that would only help for a very specific group > of PS/2 machines identified by int 15.c0 - not very useful. > > PPS: The same PC also fails to boot from FAT32 with any SYS > newer than 2.6, so SYS apparently sees LBA support while it > does not really boot later? See freedos-user, still ongoing. > Unclear regarding SYS 3.6e /FORCE:LBA and /FORCE:CHS options. > > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > -- Project founder and developer of BirdOS by FeatherCode -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] making himemx and jemmex more foolproof on old bios versions
Hi, I think at this point a comparison should be done with Microsoft's version on this machine to see if any differences can be detected. Also, I would run Microsoft's OS in the emulator to see On Wed, Jul 20, 2016, 3:34 PM Maarten Vermeulen wrote: > I looked at int 15h lately, int 15h is not supported on older BIOS > versions but every BIOS has it in the time called now. :) > > Error code 86h means "function not supported" and if you get 80h it means > "invalid command" > > > > > Op woensdag 20 juli 2016 heeft Eric Auer het > volgende geschreven: > > > > Hi experts, > > > > some interesting observations about an old 486 PC in the thread > > with Dimitris about "Which freedos on 486" on freedos-user... > > > > His BIOS answers with AH=86h, carry=UNCHANGED to int 15.e801, > > also leaving AL unchanged. So it seems to be a good idea to > > STC before INT 15 when doing the 15.e801 call :-) Note that > > AH=86 is a common failure code for int 15 functions. I would > > also suggest to, in addition, treat AH=UNCHANGED as failure. > > > > Another issue is that RBIL says for this call that if AX=BX=0, > > one should use CX and DX as memory size info instead. However, > > DOSEMU only sets AX and BX and returns CX=DX=0 while FreeDOS > > HIMEMX and JEMMEX both look ONLY at CX and DX, without even > > checking for AX and BX! Luckily DOSEMU also supports the two > > other int 15 calls for memory info afair, but it seems tricky > > that DOSEMU and FreeDOS disagree about 15.e801, no? > > > > Also, it is interesting that the FreeDOS drivers say that if > > CX is not 3c00 (the max value) then DX must be treated as 0. > > > > This sounds like "memory hole below 16 MB means end of RAM"? > > > > Finally, JEMMEX and HIMEMX both say "if CX plus scaled DX < 64 > > then fall back to 15.88", which is a somewhat weird way to say > > "if CX and DX are both 0". > > > > RBIL writes about int 15.88 versus the carry flag: > > > >> the standard BIOS only returns memory between 1MB and 16MB; use AH=C7h > >> for memory beyond 16MB > > > >> not all BIOSes correctly return the carry flag, making this call > >> unreliable unless one first checks whether it is supported through > >> a mechanism other than calling the function and testing CF > > > > Interestingly, JEMMEX and HIMEMX decide to trust int 15.88 > > even if it leaves carry unchanged: They CLC before int 15. > > > > I think it would be a good idea to check if AH=80, 86 or 88 > > after the int 15 call even if carry is not set, as all those > > values would be possible return values if int 15.88 failed. > > > > What is confusing: JEMMEX works on the mentioned 486, while > > HIMEMX does not work, not even with /NOABOVE16 and /X, why? > > > > Regards, Eric > > > > PS: In theory, int 15.c7 would also be a possible call to get > > info about memory beyond the first 16 MB without 15.e??? BIOS > > support, but that would only help for a very specific group > > of PS/2 machines identified by int 15.c0 - not very useful. > > > > PPS: The same PC also fails to boot from FAT32 with any SYS > > newer than 2.6, so SYS apparently sees LBA support while it > > does not really boot later? See freedos-user, still ongoing. > > Unclear regarding SYS 3.6e /FORCE:LBA and /FORCE:CHS options. > > > > > > > -- > > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > > patterns at an interface-level. Reveals which users, apps, and protocols > are > > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > > reports.http://sdm.link/zohodev2dev > > ___ > > Freedos-devel mailing list > > Freedos-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/freedos-devel > > > > -- > Project founder and developer of BirdOS by FeatherCode > > > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports.http://sdm.link/zohodev2dev > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://s
Re: [Freedos-devel] Bug in Freecom
> FreeCom allows this command: "COPY CON" confirm > After that I can write text which echoes after enter in next line and > it can't be interrupted nor with CTRL-Z worx for me ... can be interrupted with CTL-Z -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bug in Freecom
Yeah,copy CON works for me as well.It works in the 1.2.1 Distro as well.Could it be a TSR you have running or something? On Thu, Jul 21, 2016 at 1:18 AM, dos386 wrote: > > FreeCom allows this command: "COPY CON" > > confirm > > > After that I can write text which echoes after enter in next line and > > it can't be interrupted nor with CTRL-Z > > worx for me ... can be interrupted with CTL-Z > > > -- > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning > reports.http://sdm.link/zohodev2dev > ___ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel > -- What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
