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=401d, x87 status=
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
