uhm our cga4 mode (vid mode 5 which is screen 1)

They use to read the input from the screen using:
int 10 ax=0x0800

We don't support this call for non text modes.so the returned data is rubbish. (cga4 is graphicial mode for dosbox)

Qbix wrote:

uhm our cga4 mode (vid mode 5 which is screen 1) […]
Show full quote

uhm our cga4 mode (vid mode 5 which is screen 1)

They use to read the input from the screen using:
int 10 ax=0x0800

We don't support this call for non text modes.so the returned data is rubbish. (cga4 is graphicial mode for dosbox)

Ah, well, that explains! However, it doesn't show up as unsupported call in the debugwindow, so I didn't figure it was a problem. Of course, I think you should support this call, as I want to use GWBasic 😀. Shouldn't be to difficult, it's a simple bitmap compare basically (or does the BIOS use some buffer to put the characters in?), but I can see it hasn't got priority...

JAL

well to be honest I don't know

I for one would find the buffer idea much simpeler to compare 😀
as you need to compare the fonts in memory I think (those int 43 and 1f vectiors). not sure if that is "simple" to do. if you take in account color and xorring.

I doubt it's done that way, as the calls would no longer return correct results if you use graphics functions or memory accesses to draw pixels across the text. I would think it more likely that the text information would be mirrored in another part of video memory or something, but I really don't know.

yeps. at b000 should be some space left to store it.
but I think somebody with a real cga or good vga card can test it. by searching the videomemory. after writing some stuff to it. (using int 10 calls)

Anyway dosbox can offcourse mirror the data even in it's own memory as oposed to emulated memory. little harm done. (I mean 1 screen of 80x25 characters....= 200 bytes...)

2000 bytes 😀)

Still, I remember reading on another thread that the BIOS really did do the buffer compare and that simply using the "LINE" command to screw up the text did make it impossible for BASIC to read back the data. A quick test confirms this. See screenshot. (GWBASIC run under real DOS).

Note also that in graphics mode, BASIC doesn't change the background colour for the text that is printed next, but changes the screen background colour by altering DAC entry 0. Apparently, what the BIOS routine need therefore do is simply read the screen and check only zero values and non-zero values from the result of a GetPixel routine.

Interesting. Does it recognize colored text? What about custom fonts?

It recognises coloured text just fine. It just seems to test for zero/nonzero, because changing any of the white pixels to another colour doesn't cause an error. Changing any of the black pixels does. (Note: obviously I don't actually mean "colour" here, but "DAC index").

Check out the attached image. The space was "turned into" a hyphen and the "d" has a cyan pixel.

Qbix wrote:

Anyway dosbox can offcourse mirror the data even in it's own memory as oposed to emulated memory. little harm done. (I mean 1 screen of 80x25 characters....= 200 bytes...)

Or could just compare the output buffer, instead of the emulated graphics memory, although this might raise other interesting issues...

JAL

well I will see if can write a function to do so tommorrow or so. shouldn't be that hard.(although a bit slow 😀

try this patch.
it contains some debugging stuff for me checking some other stuff, but
I tried it at least screen 1

It works in screen 1 (320x200x2b) and screen 2 (640x200x1b), not in the EGA mode, though (which is pretty obvious since there are no entries in the switch/case block). I tried simply adding "M_EGA16" and that works fine with my tests.
The results seem to be identical to using GWBASIC under plain DOS, being precisely the same as in my test above.

One unrelated thing I did notice is that Ctrl-Break is not caught under DOSBox, so there is no way to stop

110 print "Hello world!"
220 goto 10

hmm will add ega and maybe vga to it. (with some warning message orso)

Break, yeah never got to handle it. it's again some weird multi-layered system. (handled by the bios, checked regularly by dos. doing weird things)
Oneday... it's on my to do list.

Along with Pause/Ctrl+NumLock I hope... 😀