Some MCGA BIOS notes #5672
iamgreaser
started this conversation in
General
Replies: 1 comment
-
The AX=1130h bug report has been filed as #5673 . Current behaviour is correct for VGA, mostly correct for EGA aside from a couple of edge cases which need to point to gibberish, and notably incorrect for MCGA. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Been messing around with MCGA recently and ended up hitting some bugs in places which required me to obtain a PS/2 Model 30 BIOS and disassemble things.
I'm not sure what kind of issue type this would be filed as, as "there is incorrect behaviour in a niche case, and here is the correct behaviour" doesn't seem to quite fit "here's a set of steps to reproduce this bug". Hence why I've opened this as a discussion.
Comparisons in this post are against commit 2a8ac11, dated 2025-04-28T20:25:24-0700.
I did notice this comment for INT 10h, AH=12h, BL=10h (which was as a result of fixing #1207):
The behaviour here today is correct - the call fails and from what I can tell the registers remain untouched.
However, there are some calls in this category which are handled. If BL is in the set {31h, 32h, 33h, 35h}, then the relevant calls are handled in at least some way. Any other BL value is a no-op.
Note that these calls are somewhat niche...
My understanding of the behaviour from disassembling parts of the IBM PS/2 Model 30 BIOS:
The thing that actually made me go digging, however, was that I was hitting a bug with this... and I'll file a bug pertaining to it:
AH=11h, AL=30h is "Get Font Information". Values other than 03h currently seem to point to garbage.
Now, the exact locations of things seem to be (although this is probably not important):
Unless one does an invalid call, CX and DL are set as per how RBIL documents it (actually directly fetching from the BDA), and not as per IBM EGA adding one to DL.
The bug I am actually hitting here also affects VGA and EGA and probably other things too, although there is an MCGA-specific bug in there as well...
From my testing, 03h and maybe 04h (EDIT: My bad, 00h is also behaving correctly, I didn't realise that 00h is the upper 128 and 01h is the lower 128.) are the only values which work correctly. 00h seems to point to the upper 128 chars of the 8x8 font, 01h seems to point to the 8x14 or 8x16 font, and other values tend to be garbage.
There is also an MCGA-specific bug in DOSBox-X: MCGA bans the use of font 05h. But DOSBox-X's implementation currently bans the use of font 06h instead. I'll track that in the bug report as well.
Anyway, time to write that bug report.
(Sidenote: In my adventures I also found a bug with the monitor types in ega200... but my build was from 2024, and after updating and rebuilding today the monitor type is set to something that doesn't imply the 350-line modes are available. And no, doing the "set the mode then test if it changed" trick does NOT work on an actual IBM EGA BIOS, so I needed to read the monitor type.)
Beta Was this translation helpful? Give feedback.
All reactions