attach the program ?
(you must be a registered user to be able to do that)

here is attachment...

another simple program:

1rem this example printing numbers 1 - 20.
2cls
3rem define integer variable x
4defint x
5for x = 1 to 20
6print "-", x
7next x
8print "press any key..."
9while not instat
10wend

Heheh, this is really funny 😀. Seems like Turbo Basic is using the copro even for integers, and the copro emulation is faulty somehow. Cannot explain the strange numbers otherwise. Does everyone have the same faulty sequence?

1-7, 16, 36, 80, 176, 384, 832, 1792, 983040, 1099511627776, ...

(damn, why doesn't DOSbox have a copy/paste function for textscreen?)

JAL

yes i do.
will analize it.

it seems to use fxtract which i didn't add yet.

I think I saw similar behaviour before - when using a sample application TCalc which was available in some old DOS Turbo/Borland C/C++ compilers from Borland (it is a simple spreadsheet). It runs ok in DOSBOX but is basically unusable because of this behaviour.
Since it was just a sample program for C/C++ compiler, I did not think it important- but it may be now usefull for testing.

BTW: so far in all cases when this bug appeared it was with Borland products (Turbo Basic, that TCALC I mentioned was from some Turbo or Borland C, I would not bet myself that it is not Turbo Pascal as well). It may be quite widespread, but it was more or less ignored up to know since it does not concern games...

Mirek

well i added it. not entirely correct.
so if somebody could provide which uses 0 and negative values as well

I have tried it on that mentioned sample program TCalc from BC++ 3.1 and there is no change. So maybe it is a different bug. Well, I upload it here anyway if somebody wants to test.
It is a sample spreadsheet application from Borland C++ 3.1. I can upload sources in C++ if necessary.
Just try to enter any number (well, just 0 works).

Mirek

well values of 6 numbers work fine

odd. will put it in my todo list.

edit: it seems the loading of 64 bits isn't going exactly as anticipated.

quite puzzled. as i can't see anything wrong with it at first sight.

@Mirek:
in
fpu_instructions.h:
static void FPU_ST80(PhysPt addr,Bitu reg)
change one of the lines to this:
Bit64s mant80final= (mant80 << 11);// | LONGTYPE(0x8000000000000000);

the calculater does a push(zero)
write that number to memory. replace memory with number typed
load as 64 bit integer.

I'm not sure if this the complete fix.
I will have to test in on a real fpu to see what it writes write away zero in 80 bit.

Yes, TCalc works with the above mentioned fix.
IMHO it is logical that 0 should be represented by zeroed bytes (but it is just my guess, I did not check any referece how 80 bit numbers are really implemented in FPU).

Mirek

okay commited the fix.

i was a bit confused about the implied bit by smaller variants.

Might still be not entirely correct but dosbox can load it's own stored numbers fine 😀

is fix ready ?

next version will have the fix.