Forum > Other

GRDEMO.PAS runs when compiled with i8086, but triggers runtime 216 in Go32v2


I know this is an odd bug report, but I am rather impressed that GRDEMO.PAS from waaay back in 1985 from Turbo Pascal 4.0 even compiles in modern FreePascal 3.2.0.  You FreePascal devs really deserve a pat on the back for retaining such backwards compatibility in the language, I do not believe any other programming language has such backwards compatibility, let alone being very cross-platform.

Okay, so I am able to compile and run GRDEMO.PAS by only making very minor changes to the original source, such as video modes not in the modern Graph unit, Pointer types, and the ColorPlay procedure as it was only programmed with a max of 16 colours in mind.  It runs in i8086 real-mode with VGA/VGAHi, but also runs in a whooping 1024x768 resolution, well over the intended resolution of the era.  I believe ColorPlay should work if color depth is set to 16.  If the color depth is set higher than 16, the redraw is incredibly slow as Borland did not use a back buffer.

Now, if I compile GRDEMO.PAS against the more supported Go32V2 target, it no longer supports real mode resolutions, and actually closes DOSBox for some reason...  In order to use GRDEMO.PAS at all with Go32V2, a VESA resolution needs to be selected.  Now, here's the problem.  If I set it to detect, or manually choose say 1024x768x16, it will display the status page in that selected resolution, but as soon as it tries to run the next Graph unit test, I receive a Runtime 216 error.

I am planning on troubleshooting it myself when I have more time, perhaps commenting out additional tests.  The next test that should be running is PutPixelPlay...  So, maybe the Graph unit's implementation of PutPixel in Go32v2 has a bug where it tries to access memory it shouldn't.

Although I do not expect any help with resolving this, I thought I'd post this here just to show how awesome the backwards compatibility of FreePascal is against even Turbo Pascal 4.0 code.  Oh, and that the i8086 target has really exceeded my expectations!  Great Job on the new target!

It could be that it's a difference between 16-bit and 32-bit. The Go32V2 target is essentially a 32-bit target, while the i8086 one is much closer to TP.

Then again I've just tested the demo in Windows and it works more or less with the default Graph unit (though that thing could really use some improvements) and rather well with the PtcGraph unit... So maybe it could indeed be a problem with the Go32v2 Graph unit...

Note also that it might be a gimmick of DOSBox. To be absoultely sure you should test it on real hardware or a more thorough emulator; say, QEmu, VirtualBox or alike.

Or the VESA driver's 32-bit support....

I didn't expect as many responses on this, but thank you for all your input.  I am thinking of trying to run the 32-bit version in QEMU running DOS 6.22 to see what happens, as it can't just crash and close QEMU like it did with DOSBox, so I may actually get an error of sorts.  If I do see an error when in QEMU, I'll be sure to post back here what it is, and see if I can figure out why running this in 32-bit mode is causing it to crash.  But, I am very grateful for the i8086 port to exist now, as it allows programs such as this which may not run in 32-bit mode to be ported to a more modern Pascal compiler for those who may need it.

I still cannot say this enough though, Great work on keeping such awesome backwards compatibility!  Try going from Python 2.x to Python 3.x...  It seems going from Turbo Pascal 4.0 to FreePascal 3.2.0 is easier.  :o


[0] Message Index

Go to full version