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!