I am brand new to vDOS, being a long-time user of True Basic programs (my own) in Windows XP. Now I need to convert to Windows 10 but also bring along my True Basic programs.
Programs work find in vDOS EXCEPT when the execution encounters a "mat redim" statement (to re-dimension a vector to size it for a particular data set). Error message says "out of bounds" and stops executing, as if trying to get values beyond the size of the vector. What to do?
With True Basic in vDos this code will generate "Subscript out of bounds" error every time (no matter what the sizes of the DIM or REDIM). But I should add that True Basic error messages are not always accurate. (In all other cases they do reflect actual errors, but not always the particular error specified.)
Yeah, I do use Tru Basic in Windows when I have to. It's just clumsier than in DOS. And the vDos works fine in all other ways, so it would be terrific to solve it.
I had a look at your program. That simple three-liner resulted in a stunning 1,527 FPU instructions called.
And it all makes little sense; many meaningless values are loaded into the FPU registers. For instance -0.67, 2.68, 4294967294, even one of 309 digits. Checked if vDos rounding would be the cause. It isn’t, it only kicks in twice with near infinite values. Disabling rounding doesn’t bring anything. Had a quick look at the last FPU instructions called, that neither revealed anything but also meaningless values being loaded.
It ends for me, BASIC isn’t of much interest to me, while I have no idea what to look for. I’ll send you the 2016.10.01 version, that didn't emulate a FPU processor, so the software routines of True Basic will be used.
Thanks for your several tries to help. I did get your 2016.10.01 transmittal, and will try (Thursday) to see if that's better than the vDos I downloaded publicly in the first place.
(Just FYI, what's really strange to me---and maybe of interest to you---is that DOSBOX handles the REDIM function with no problem at all, whereas vDos chokes on REDIM. I would have just used DOSBOX, but that make programs run unbearably slowly....like maybe 60 seconds just to start running.)
I'm not surprised that the .EXE file I sent was difficult (and quite large). The original test program itself was really short (4 lines), but in order to make an .EXE version, I had to do a "bind" function that integrates the sample program with the whole True Basic system. I realize it's just my ignorance, but that was (is) the only way I know to make a compiled program executable. (Should I have simply re-named the .TRC file as .EXE?)
Thanks Jos for your file transmittal. Interestingly, is solves the REDIM problem, but has a new problem with handline my sevaeral (many) TB programs for graphical presentation. (Such programs, using the vDos file, present screen displays that are just total mis-representations....gibberish. I could send an image if you want.)
So the vDos file you lastly sent solves the REDIM problem, but introduces fatal graphics problems.
Curiously, DOSBOX solves both of thee problems BUT is just erratic in processing time....often just hanging-up on execution, not due to system utilization; it;s just standing still for 10 or 30 seconds.)
Strange that the 2016 version introduced problems with graphics. vDos supports only basic VGA graphics, display modes 0Fh-12h, 640x350-640x480. Not much, if anything at all, has been changed to VGA graphics over the years. Perhaps your program tries to program the display adapter directly for an unsupported mode.
You could consult the DOSBox forum (https://www.vogons.org/viewforum.php?f=31) for the performance issue, maybe selecting another CPU emulation or speed would solve it.