Hi, On Fri, May 16, 2014 at 8:05 PM, Dinosaur <j...@tubejoiners.com> wrote: > Hi All > > Long time user of FreeDos on CFC in Industrial environment. > Long time user of FreeBasic in the same environment. > Retired and experimenting with a new device.
Yes, I recognize your nickname from FreeBASIC's forum. > Have recently purchased an 86Duino in the form of EduCake. > Basically an x86 with breadboard on top. > Fairly new product using a Vortex86Ex processor. Okay, but sadly I don't have one (and wouldn't really know what to do with it if I did). I'm not sure I'm much help for you here. > I am having difficulty running programs in this environment. > Basically: > if I load CWSDPMI and run say Edlin32.exe it works (or appears to) > If I dont load CWSDPMI and run Edlin16.exe it works (or appears to) Was Edlin32 compiled with DJGPP (etc)? If it's OpenWatcom (like I vaguely recall), then I wouldn't try that. CWSDPMI is not meant to be OpenWatcom-compatible (no extended int 21h stuff, only pure 32-bit DPMI). But that's not really your main issue here, so .... > Loading CWSDPMI and running a FreeBasic (Dos) compiled two line program it > generates an exception. > Division by Zero. > Print "Hello World" > End Try running as clean a setup as possible. Disable as much stuff as you can. You don't even necessarily need XMS. And make sure you run CPULEVEL (or similar) to show us what it says. In fact, try running a similarly simple program made via FPC (GO32v2) or GCC (DJGPP), just for comparison. (I'm assuming kernel 2040 from FD 1.1 here. Oh, and latest stable FBC 0.90.1.) > Compiling this program with PB7 (16 bit Dos) and running it, > doesn't create any exceptions but no message printed. Presumably that doesn't try to use the FPU at all. > Now I have dealt with this processor before on Industrial CPU boards, and > have not had this problem. It has an integrated FPU, right? As far as I can tell, it does (though I know some semi-related Vortex processors did not). http://www.86duino.com/wp-content/uploads/2013/11/Vortex86EX_A9123_V14_86duino.pdf > Autoexec.bat (the relevant bits) > @echo off > SET dosdir=C:\FDOS > set PATH=%dosdir%\bin > set NLSPATH=%dosdir%\NLS > set HELPPATH=%dosdir%\HELP > set temp=%dosdir%\temp > set tmp=%dosdir%\temp > > SET autofile=C:\autoexec.bat > alias reboot=fdapm warmboot > alias halt=fdapm poweroff > > MODE com4:9600,N,8,1,P > ctty com4 > C:\FDos\Bin\DosLFN.com I wouldn't always load DOSLFN by default, some programs conflict. BTW, your message (below) indicates a very slightly older version. Doubt that makes a difference, but you never know. http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/doslfn/0.41/doslfn041c.zip > C:\FDos\Bin\cwsdpmi.exe The app itself should run this automatically every time you start it. It's in the "stub", you don't need to run it manually. It could run into obscure problems later. Besides, here it isn't loaded permanently ("-p"), so it's only temporarily for one run anyways, hence redundant. > C:\FDos\Bin\LBACache Below, you seem to only be using 2 MB cache anyways. Not even worth enabling, almost. > Bootup detail. > DOSLFN 0.41 (haftmann#software & jmh 12/2011): loaded consuming 11776 bytes. > LBAcache disk read cache for XMS + 386, E. Auer <e...@coli.uni-sb.de> > XMS allocated: 2.00 MB, driver size with tables and stack: 7427 bytes. > > C:\> > The exception in 32bit protected mode. > C:\>test > Exiting due to signal SIGFPE > Division by Zero at eip=0000401d, x87 status=0000 Floating point stuff ... yuck. Your best bet may be trying to run it under GDB, and see where it's stopping. > Can sks give me some direction here please. All I know is that FBC isn't very concerned with compatibility for obscure machines. In particular, I'm sure you've noticed their unwillingness to care about older machines without FPUs, much less newer clones that (apparently) don't work the same as official Intel cpus. In other words, their RTL always assumes an FPU is present. This was a minor gripe to some of us a few years ago, but they weren't interested in fixing it. I ended up manually patching DOS386's FBMD5 (locally only) to not need it, but even that was only possible due to him avoiding certain language features (double-precision floats). Even that wasn't crucial since emulation worked okay (in limited testing). If none of the other attempts seem to work, you could try "set 387=n" and then "set EMU387=c:\djgpp\emu387.dxe" (or whatever the setting is, it's been a while since I tried), and see if the emulation works better. You may have to grab this from DJGPP proper as FBC (AFAIR) only included libemu.a. Okay, well, if you're compiling the test program from the actual machine, you could just link with that lib and hope it works. (WMEMU is another option if that doesn't work, but my hopes would be getting dimmer and dimmer at that point.) ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
