This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DOS/16M Error: [30] Program must be built -AUTO for DPMI

I trying to re-compile a very, very, very old Project written for the Archimedes Compiler Version 4. It was created by an employee that is no longer with the company. The Target CPU is a Siemens 80535, an enhanced 8051 CPU, and a single 27C512 EPROM. When I run the MAKE File it calls C:\arch4\bin\c-51 (an .EXE file dated 11/14/1990!). I am trying to compile in a DOS window in Windows 2000. I am told that the orignal programmer used a DOS window in Windows 3.0 for compiling. Any help in how to prevent the "DOS/16M Error: [30] Program must be built -AUTO for DPMI" ERROR Message? This Embedded application has no idea what DOS/16M or DPMI is and could never use that functionality.

  • Back in the 1990's, most embedded compilers used a DOS extended to get additional memory to use for optimizations.

    Make sure that the DOS box enables XMS & EMS memory for the MAKE program you are running.

    Another thing is to check that the MAKE program allows XMS/EMS use by the programs it calls.

    BTW, that version of Archimedes was NOT developed by Keil.

    Jon

  • Get a DOS boot floppy, if you only need to do it once.
    For example, http://www.freedos.org

    - mike

  • Jon,

    I looked for any property for the DOS Window under Win 2000 to control XMS and/or EMS and I found nothing.

    I think it is just the opposite. I think that the C-51.EXE is NOW detecting DOS/16M DPMI under Windows 2000 and is NOW displaying the error that the program must be built with -AUTO. It is C-51.EXE taht is displaying the error Message not the Make File Utility. If I just type "C-51" from the C:\ARCH4\BIN\ sub-dir I get that DOS/16M Error Message. I think I need to set an Enviroment Variable to tell C-51 to NOT use EMS, XMS or DOS/16M DPMI.

  • Have you added the -AUTO option to the C-51 command line to see what happens?

    Jon

  • Jon,
    Yes, I did. It gives the exact same error message. Weird, Huh? I found a Manual for this product and it talks about "DXT" files for Expanded Memory Extended Memory support. I also found a C51NODXT.EXE that does not generate the DOS16M Error Message when typed at the command line. It displays all command line options when run from the command line which might indicate that it can compile under WIN2000. What an adventure this has become. I reallly didn't want to change the Make File or the Compiler or any Options since the Target system is at the Customers location in another State. So, if this creates an invalid .HEX file it will be impossible to debug. I wanted to make a "simple" software change, re-compile, burn the eprom and fed-ex to customer. "Simple" - now thats funny! :-)

    Greg

  • Mike,

    Great Idea!
    I have a Dell notebook.
    I will check it out to see what that involves. Can I stil access (compile from) my C Drive after booting fron Free-DOS ?

    Greg

  • OK, just one more thing. Have you created a PIF file for running the MAKE program?

    If you haven't, I'm pretty sure there is no EMS or XMS.

    In Windows 2000, click on START - HELP and select the Index Tab. Then, enter EMS or XMS. Instructions for adding EMS/XMS to a DOS program are there.

    I'd definitely try that first. Especially if things were running under Windows 3.x.

    Jon

  • If it's NTFS, you are in trouble. If FAT32, recent freedos versions support it. A Win98 rescue floppy could do the job (with FAT32), if you have one of them around.

    - mike

  • Mike,
    The solution was to run c-51.exe in a c:\windows\system32\COMMAND.EXE (MS-DOS Prompt) window and NOT a c:\windows\system32\CMD.EXE (Command Prompt) window. The CMD.EXE file is different enough from the COMMAND.EXE file to cause the DPMI Error in old DOS applications.

  • Are you sure that's COMMAND.EXE and not COMMAND.COM?

    COMMAND.COM is the original, MS-DOS, 16-bit command interpreter, complete with 640K limit, etc, etc - that's why it needs an extender;
    CMD.EXE is the Win-NT 32-bit command interpreter - a completely different animal (although it provides many of the same commands)

    "This Embedded application has no idea what DOS/16M or DPMI is and could never use that functionality."

    The error has nothing to do with your embedded application - it is being generated by the DOS/16M kludge;
    DOS/16M is complaining about your compiler, and suggesting that you rebuild the compiler executable!

    "'Simple' - now thats funny! :-)"

    Unfortunately, this sort of thing is almost inevitable when trying to run ancient DOS apps on modern Windows - especially where the nastier aspects of EMS, XMS, etc are involved... :-(

  • Andy,
    Yes, you are correct, it is the COMMAND.COM file. I remember that file from the old DOS days (Command.com, Autoexec.bat, Config.sys) I never thought I would be compiling a program using command.com in the year 2003! :-)

    Yes, CMD.EXE and COMMAND.COM are different enough to cause the C-51 compiler to work on one but not the other. I didn't even know command.com was hiding in c:\winnt\system32\ sub-dir on my Windows 2000 computer. It makes a MS-DOS Icon while CMD.exe makes a C:_\ Icon shortcut. I learn something new every day.

    I can also get the Compiler to run under cmd.exe if I use this "command /c c-51 ..."

    I am so happy that it works!

    Greg