VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've built a little wrapper to allow interrupt 10h in my emulator to be hooked to a BIOS using the standard addresses (C000:3 entry point and the interrupt after all the Dosbox ROMs(character fonts and misc data)). The entry point handler simply sets the interrupt 10h vector in the IVT. The interrupt 10h vector points to a little procedure which executes an 'internal call' into the BIOS_int10 function in my emulator (using special opcode 0xFE /6, like Dosbox does).

Interrupt 10h handler:
https://bitbucket.org/superfury/x86emu/src/9e … t10.c?at=master

The callback generator/execution:
https://bitbucket.org/superfury/x86emu/src/9e … ger.c?at=master
It seems to run fine partway, but after detecting the CPU&VGA, it hangs.

It also seems to use 40x24x16 text mode instead of 80x24x16 text mode?

Anyone knows what's going wrong here?

Last edited by superfury on 2015-12-27, 17:11. Edited 1 time in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++

Anyone knows if there's an error in the interrupt 10h emulation? It looks like the entry point executes correctly(there's output on the screen, whereas without the ROM installed, no output is visible at all (the Turbo XT BIOS v2.5 programs the VGA assuming it's a CGA). I know it works fine using a IBM VGA BIOS.

First, why is the video mode 0/1 set(40x25 16-color text mode)? Is there an error in the mode detection?

Second, why does the BIOS stop running after giving the information on the installed graphics card? Is there an error in it or the resulting registers after return of the write/read character function call? Does one of the functions return invalid values? (It's partially based on Dosbox's int10 emulation.)

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 2 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've updated my latest source code with correct responses that were unimplemented:

https://bitbucket.org/superfury/x86emu/src/89 … t10.c?at=master

- Improved video interrupt cursor Start/End values.
- Added unwritten registers of light pen (unimplemented on VGA).
- Improved return values on retrieving the active display page.
- Added CF error on invalid video interrupt function number.

Even with those fixes, the Generic Turbo XT BIOS v2.5 still won't get past the VGA detection (probably executing an infinite loop for some reason). The IBM VGA BIOS will run without problems.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 3 of 6, by vladstamate

User metadata
Rank Oldbie
Rank
Oldbie

Is it possible it is reading 3BA/3DA port outside INT10h and therefore it does not detect bit changes so it goes on an infinite loop? Is TURBO XT BIOS only interacting with the card via INT 10h calls?

Regards,
Vlad.

YouTube channel: https://www.youtube.com/channel/UC7HbC_nq8t1S9l7qGYL0mTA
Collection: http://www.digiloguemuseum.com/index.html
Emulator: https://sites.google.com/site/capex86/
Raytracer: https://sites.google.com/site/opaqueraytracer/

Reply 4 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++

A little log of what it's doing during that time:

The attachment debugger.log is no longer available

Made using the emulator's debug function.

The screen capture at this time:

The attachment capture-4.zip is no longer available

Anyone can see if something's going wrong here?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 5 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've optimized the interrupt 10h handler a bit (mainly changing stuff that's executed during initialisation (BIOS entry point at C000:0003)). The default video mode is also changed from 0(40x25x2) to 3(80x25x16). The output is correct now. Only thing that still goes wrong is output past the bottom of the screen(instead of scrolling up by 1 row the bottom row is overwritten) and cursor settings (wrong character scanline). Also any output past the VGA info of the BIOS (explained earlier) doesn't display for some reason (It's probably still executing correctly, as it starts booting after some time).

When MS-DOS reaches the bottom charater row, it starts overwriting that row over and over for any output instead of scrolling the window up. The cursor also is at the wrong character scanline and at the wrong column for some reason.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 6 of 6, by superfury

User metadata
Rank l33t++
Rank
l33t++

I've fixed the scrolling issues when using the teletype output (interrupt 10h function 0xE) and scrolling windows up/down. MS-DOS now works properly when scrolling text up. I've also fixed the cursor according to some manuals (Horizontal position is increment by 1, not 2(actual VRAM addresses). Also the cursor start and end scanline are translated from the specified range (0-7) to the actual range (0-scanlines per character)).

I've noticed that Ultima 6 goes wrong when starting the game, loading strange pallettes (looks like a CGA palette?)? Maybe pallette loading goes wrong for some reason (might have something to do with this custom video BIOS having unset pointers to VGA structures when required by the game)?

I've also noticed that for some reason, output past the VGA section of the BIOS (before starting any option ROMs and booting) writes to video page 4 (BH=4) with page 0 being active (as by an earlier function function AH=05h call)? Anyone knows something about this?

https://bitbucket.org/superfury/x86emu/src/63 … t10.c?at=master

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io