Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
At 11:02 PM 11/28/2005 -0800, Blair Campbell wrote: I would personally really appreciate the ASM in FreeDOS HELP being a test case, as this assembler won't even compile with Arrow Assembler or the Watcom Assembler (which both use older MASM/TASM syntax, afaik). The only ASM file I found in FreeDOS HELP was conio.asm. It substantially converted with Nomyso 2.0 as-is. There remained three problem areas: local labels in macros, improper bracketing in certain circumstances, and DGROUP group listing. I fixed the local label in macro situation, and the DGROUP problem. The bracketing was made a bit more robust. In doing so, I discovered an error in the original Nomyso 2.0 for EMM386 which fortunately was minor: the _pause macro which isn't used in normal build had a memory reference error, and the very seldom used SB option code translated one line improperly. Neither problem should affect people who would develop with a translated EMM386, but they're fixed now for next Nomyso. The bracket problem highlighted one of the fundamental reasons you can never fully automate the translation process for all MASM/TASM source files .With the line: _ScreenArea EQU DWord Ptr _ScreenOffset translated to: %DEFINE _ScreenArea DWord [_ScreenOffset] things will still fail under NASM for lines like: les di, _ScreenArea Why? Because NASM won't take a DWORD attribute for a 'les' argument, even though it IS a DWORD being used. In fact, I tried different combinations of DWORD, WORD, NEAR, and FAR, and NASM won't take any of them. I think that's a bug in NASM, but I can't figure out what it really thinks it should take as an attribute, so who knows. The three people following to this point might wonder why Nomyso doesn't just eliminate the 'DWord' in the $DEFINE statement and eliminate the problem. Well, you can't automatically do that because the DWORD would be necessary in some cases where you might use the %define'd _ScreenArea, such as: mov eax,_ScreenArea However, because I am insane, I added the ability to fully automate the conio.asm conversion by adding a -x option to Nomyso, allowing post-processing lines with s// regular expressions. Consequently, with the current (unreleased) Nomyso: ./nomyso/pl -x'/(%define\s+.*\s)dword\s+(.*)/$1$2/i' conio.asm nconio.asm conio.asm is fully translated and NASM ready following the problematic DWord purge by that demented 'x' option. NASM -O99 -f obj nconio.asm is happy. I can't say whether the translated conio.asm actually works along with all its C source, but it does assemble without errors. If you want the latest Nomyso immediately for converting conio.asm, let me know. Otherwise I'm going to wait and see if the ATAPICD translation needs any non-major changes to Nomyso before releasing a new public version. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
Michael Devore schreef: At 11:02 PM 11/28/2005 -0800, Blair Campbell wrote: I would personally really appreciate the ASM in FreeDOS HELP being a test case, as this assembler won't even compile with Arrow Assembler or the Watcom Assembler (which both use older MASM/TASM syntax, afaik). Another victim / testcase could be UMBPCI, as it's written in TASM. Either the 1995 version, or Uwe Sieber's current one (sources only available on request) Bernd --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
At 01:27 PM 12/3/2005 -0600, I wrote: The three people following to this point might wonder why Nomyso doesn't just eliminate the 'DWord' in the $DEFINE statement and eliminate the problem. Well, you can't automatically do that because the DWORD would be necessary in some cases where you might use the %define'd _ScreenArea, such as: mov eax,_ScreenArea Correction. The 'mov eax,_ScreenArea' instruction would work without the DWORD attribute because the data size is known through the register size. Other instructions such as 'push _ScreenArea' would not work without the DWORD attribute because NASM doesn't know the size of data to push without it. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
Blair Campbell wrote: Speaking of bugfixes, a person on FreeDOS IRC has mentioned many times that the latest versions of HIMEM/EMM386 won't work with certain hard drives, but will work with others. AFAIR, he also says that NOVDS does nothing to change this. Sorry, but mentioning it on IRC many times with zero technical background is NOT the way to get these things working. This person needs to post on here with exact FDCONFIG.SYS, controller model/firware, hard-drive model, and definition of won't work. For a start we need to know whether they're talking about hard drives or controllers? What we do know is this: 1. HIMEM is rock solid with a huge range of ATA/SCSI/SATA controllers and just about any make of hard drive. 2. EMM386 with SCSI controllers and VDS enabled is completely unusable and should never be tried outside the test lab. 3. EMM386 used with SCSI without VDS appears to work, but no one would trust it in a business production environment, but for testing and home PCs it seems fine. 4. EMM386 with IDE/ATA is probably fine, and anyway if the machine has IDE/ATA it's probably not a very important machine. 5. EMM386 with SATA - I've never tested this. If you have mission critical machines, they'll probably have SCSI and in that case I'd recommend HIMEM with UMBPCI. I've tested this on a huge range of hardware, servers, clients, SCSI, ATA, SATA and I've not seen a single problem. It also gets round some strange issues you sometimes see when the prog don't like prot-mode. One I can think of is Partition Magic under DOS which does not like EMM386 to be loaded, complaining there's only 32Mb of RAM because of it. -- Gerry Hickman (London UK) --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
At 07:15 PM 12/1/2005 +, Gerry Hickman wrote: What we do know is this: 2. EMM386 with SCSI controllers and VDS enabled is completely unusable and should never be tried outside the test lab. What? Completely untrue. More like 2. EMM386 with SCSI and VDS works on all tested systems, but unverified reports are that there are problems with some SCSI setups. 3. EMM386 used with SCSI without VDS appears to work, but no one would trust it in a business production environment, but for testing and home PCs it seems fine. Nonsense. I could make the same claim about trusting DOS itself in a business production environment because of its lack of operating system protection. I realize you personally have had some problems with EMM386 that cannot be duplicated elsewhere, but I would appreciate you not posting things these claims. They are inaccurate and needlessly damaging to proper distribution, use, and testing of EMM386 by endusers. By the way, EMM386 can always give a system more upper memory than UMBPCI. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
On Mon, 28 Nov 2005, Blair Campbell wrote: PS: If the C is ever to be compiled with Watcom C, as Bernd suggested, the global functions in the asm would need to have a _ in front instead of behind, as this is (for some weird reason) the way OpenWatcom does things. I think you have this the wrong way around. The reason is not so weird, as it avoids severe bugs interfacing. The _ is put the other way because the calling convention is different, so just changing the _ isn't enough, you also need to convert stack to register parameter passing. If you want a _ in front with OW, and stack calling conventions, like Turbo C, all you need to do is to decorate the function with _cdecl in the C or H file. Bart --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
At 11:02 PM 11/28/2005 -0800, Blair Campbell wrote: Speaking of bugfixes, a person on FreeDOS IRC has mentioned many times that the latest versions of HIMEM/EMM386 won't work with certain hard drives, but will work with others. AFAIR, he also says that NOVDS does nothing to change this. Possibly one of the SCSI drivers, but without a test machine to see what's in conflict, nothing I can do. All the SCSI drive machines I've been able to test with now work with EMM386. Also, I've found some people allow too many memory areas in upper memory and trash BIOS drivers. Either they I= include too much, or X=TEST can't catch quite everything. Best way to determine if upper memory conflict is present is to temporarily X= the entire upper memory range and see if the problems persist or go away. Then narrow down the range which needs to be excluded. BTW, with NASM, does optimizing EMM386 or HIMEM for newer CPUs result in smaller object files? That would be a coding instruction-based optimization, rather than an assembler style based optimization. I don't think there is all that much above a 386 instruction level which would help HIMEM/EMM386, plus you either ruin 386 compatibility or you get into CPU versioning of the programs, which sounds horribly messy. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] EMM386 2.08/Nomyso 2.0 Available
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files emmx208.zip, EMM386/HIMEM mostly executable package (EXEs compressed via mutant UPX), and emms208.zip, EMM386/HIMEM mostly source package. Nomyso version 2.0 was uploaded to ftp://ftp.devoresoftware.com/downloads/nomyso named nomyso20.zip. nomyso is the newly chosen subdirectory for all Nomyso versions. Version 2.08 of EMM386 is strictly a compatibility release to help ease transition for Microsoft EMM386 setups, increasing the number of identical options allowed in both EMM386 versions. Specifically, EMM386 will now accept NOHI and NOMOVEXBDA without complaint, although these two options are no-op's. That is, the two option do not change behavior on the part of FreeDOS EMM386 because it never performs the actions these options inhibit. In addition, MIN=### is accepted as a synonym for the EMM=### option because, since the EMS/XMS pool-sharing feature was implemented, FreeDOS and Microsoft EMM386 act the same for the two options. Also, a few cosmetic source code cleanups were made to EMM386.ASM for better NASM-conversion via Nomyso. Nomyso has grown considerably from version 1.0 to 2.0 and has moved from semi-toy to useful program status. Nomyso version 2.0 converts EMM386.ASM source to assemble under NASM. Although Nomyso will not automatically convert many MASM/TASM programs, it now stands a decent chance of converting significant parts of a lot of the programs out there, depending on their style and complexity. I anticipate that Version 2.08 of EMM386 is the final non-bugfix release I will create (bugfix versions will continue, as necessary). I've done all the new design and enhancements I want to do, or think are necessary. The ability to assemble and test with NASM may expand the pool of potential developers, although any such changes should still be discussed with -- and need be approved by -- the HIMEM/EMM386 maintainer(s). For my part, on the FreeDOS-related front, I will likely continue work on Nomyso. There is even a faint chance I will someday document advanced HIMEM and EMM386 options and behavior, or heck, maybe clean up that really lame Wikipedia Encyclopedia entry for FreeDOS. The few minor source changes made to EMM386.ASM and NASM-specific notes follow: - EMM386 was sloppy with its case in 6-8 source lines, a fact that was masked by TASM ignoring variable case. NASM is case-sensitive and complained. - NASM does not support PUBLIC/GLOBAL declarations after the variable declaration, so two PUBLIC declarations were moved. - One routine labelled 'pause' was a problem because pause is a recently added CPU opcode (who knew?). Also a macro generated labels of INT1 and INT3, which are consider special CPU opcodes. Changes were made to avoid creating labels which matched valid CPU opcodes. - Although limited macro conversion support is present in Nomyso v2.0, passing a hexadecimal value as a beginning value was causing problems and would have required me to extensively rewrite the macro converter to insert multiple lines and %ifnum's for a mere four source lines in EMM386.ASM. So I got lazy and changed the hexadecimal values to decimal values instead. Note that NASM is slightly less efficient than TASM when generating object code so there will be a slight increase in the EMM386 binary size, although the increase was well under 1%. In fact, NASM is better than TASM at one type of optimization, but not enough to overcome other misses. Also note that it turns out that with the more complex EMM386 source, NASM mirrors the past problems with HIMEM for five, six, and seven passes. Only with eight passes, i.e. NASM -O8 -f OBJ EMM386.ASM, does the OBJ generate properly. To forestall future problems with ever more complex programs, I strongly recommend just using -O99, as is commonly found in NASM builds. 99 passes should be enough, and NASM will stop at the last pass which makes no changes, so it's doubtful anything near that many will actually occur. More information on Nomyso is available at www.devoresoftware.com/nomyso . If any of you have suggestions for an open source application written in MASM or TASM which could use an automatic conversion to NASM, let me know and I'll consider making it the test case for Nomyso version 2.5 or 3.0. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
I anticipate that Version 2.08 of EMM386 is the final non-bugfix release I will create (bugfix versions will continue, as necessary). I've Speaking of bugfixes, a person on FreeDOS IRC has mentioned many times that the latest versions of HIMEM/EMM386 won't work with certain hard drives, but will work with others. AFAIR, he also says that NOVDS does nothing to change this. . If any of you have suggestions for an open source application written in MASM or TASM which could use an automatic conversion to NASM, let me know and I'll consider making it the test case for Nomyso version 2.5 or 3.0. I would personally really appreciate the ASM in FreeDOS HELP being a test case, as this assembler won't even compile with Arrow Assembler or the Watcom Assembler (which both use older MASM/TASM syntax, afaik). BTW, with NASM, does optimizing EMM386 or HIMEM for newer CPUs result in smaller object files? PS: If the C is ever to be compiled with Watcom C, as Bernd suggested, the global functions in the asm would need to have a _ in front instead of behind, as this is (for some weird reason) the way OpenWatcom does things. To get other ASM/C projects to compile with OpenWatcom, I have changed any instances of _function in the asm to _function_, and then used defines in the C source code to append a _ to the opposite side of the function. Just a tidbit. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37alloc_id865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
