Add virtual hardware for Hercules MDA support

[RickCHodgin]

Greeting. I'm a low-level systems developer. I would like to create and add a virtual hardware device to support the Hercules Monochrome graphics adapter. It will support text and graphics modes.

Can someone assist and get me started in developing with VirtualBox?

For reference, here's a link to a video demonstrating a hobby OS I wrote years ago that uses the Hercules MDA as a second monitor for kernel debugging. In this video, I demonstrate how it worked with an add-on I wrote for Bochs which simply used a named pipe to send the 32 KB block of memory the Hercules card used for rendering to a second running process called MoMo (MOnochrome MOnitor). I'd now like to write a more dedicated hardware device for VirtualBox.

http://www.3alive.org/scn/misc/2014_02_ ... ugger.mpeg

I have another version of that graphical debugger which can be loaded from the boot sector and runs in text mode. It allows you to single-step through your 16-bit code all the way from the first few bytes of the boot sector to when you enter protected mode.

--
Rick C. Hodgin

[noteirak]

Hello and welcome to the VirtualBox forums!

I have moved your post to the "VirtualBox OSE" and I'll let those with knowledge help you out

[RickCHodgin]

Thank you!

I've been able to download the VirtualBox source and get it to start compiling on Linux Mint. I'm getting this error during the compilation. Am not sure how to correct it as it seems to be requiring something older than I have installed??

Code: Select all

...
Writing htmlhelp.hhp
Writing toc.hhc
kBuild: xsltproc docbook-htmlhelp-formatcfg.xsl  - /home/rick/VirtualBoxSource/VirtualBox-7.0.14/doc/manual/en_US/UserManual.xml
kmk: *** Exiting with status 2
kBuild: javac vboxjxpcom.jar - jxpcomgen.list
warning: [options] bootstrap class path not set in conjunction with -source 5
error: Source option 5 is no longer supported. Use 6 or later.
error: Target option 1.5 is no longer supported. Use 1.6 or later.
kmk: *** [/home/rick/VirtualBoxSource/VirtualBox-7.0.14/src/libs/xpcom18a4/java/Makefile.kmk:219: /home/rick/VirtualBoxSource/VirtualBox-7.0.14/out/linux.amd64/release/obj/VBoxJXpcom-inst-jar/vboxjxpcom.jar] Error 2

-----
So here's my thinking for the interface:
1. Add two checkboxes below the Graphics Controller dropdown on the Display - Screen tab:
[X] Allow monochrome monitor
[X] Hide monochrome monitor until used by OS

2. Create a UI / screen interface to show the monochrome video buffer.

That screen will have its own controls coloring, scaling, and video mode override controls (to allow a visualization of its internal memory block based on user choices, and not just internal port settings, which aids in debugging MDA development).

3. I'll need to monitor hardware ports 03b0h - 03bfh.
4. I'll need to monitor and present data based on linear memory addresses 0b0000h - 0b7fffh for rendering.

Here's some information on the hardware:
Hercules MDA overview
6845 chip details
Hercules Graphics Card on Wikipedia

Entering monochrome or text modes are handled by sending these values into the CRTC index registers. This works on real hardware and is what my OS used to enter text and graphics modes via API:

Code: Select all

mono_text_crtc    db 61h,50h,52h,0fh,19h,06h,19h,19h,02h,0dh,0bh,0ch
mono_grfx_crtc    db 35h,2dh,2eh,07h,5bh,02h,57h,57h,02h,03h,00h,00h

--
Rick C. Hodgin

[RickCHodgin]

Is there anyone here who can help me?

I'm looking for information on where would be the best place to add features to support a Hercules graphics adapter and present the display as a UI window.

[javispedro]

Do you want to fork VirtualBox or to make an extension pack?

I think it would be relative easy to write an extension pack with a virtual device that would just forward data (e.g. via pipes) to a separate program which would show the UI plus screen contents, like what you describe for Bochs.
Have you looked at VBoxSampleDevice ? It's in the VirtualBox source code tarball. It also provides several samples for extension packs, at least one of them also adds a new virtual device (e.g. a ms serial mouse).
That's about as much documentation as there is You're going to have to dig a lot into the source.

You can also take a look at VMusic -- https://git.javispedro.com/cgit/vmusic.git/about/ -- this is an extension pack of mine which adds 3 devices. These 3 devices all use IRQs & (port) IOs. None of them however are doing MMIO (which MDA would require) but you can e.g. read the source for VirtualBox's VGA device to get an idea. in my extpack I am doing a bunch of hacks to be able to build separate from the VirtualBox build system; see the Building section in the readme. I am not sure if these simplify or complicate things, but if they do, feel free to reuse the idea.

Note extension packs have several limitations:
* No Windows host support unless you already have kernel-signing certificates, Linux is fine.
* You cannot change or integrate with VBox UI (as far as I know).

Anyway, I encourage you to try: if you drop the UI modifications, the project sounds simple enough to be doable as a starting point in extending VBox.

[klaus]

My 2c: The proper way for Hercules MDA support would be implementing the appropriate graphics adapter emulation. VirtualBox already has a configurable graphics adapter and HGC would be one more to choose from. This means that putting everything into an extension pack isn't a great option because proper integration needs a few minor VirtualBox API changes (the GUI would pick this up automatically), and those can't be done in an extpack.

Don't take the size (and complexity) of the VGA emulation as a reference, because Hercules is orders of magnitude less complicated (no complicated VGA modes, no 3D, ...).

The text mode part could be probably partly reused because MDA is similar to a basic VGA text mode, just the attributes have different meaning. The graphics mode itself is super simple.

If you plan to contribute your code then you need to pay attention to the contributor information which means you need to have the right to relicence the code which implies "fingers off DOSBox".

[RickCHodgin]

klaus, yes I would prefer to do that. Can you or someone point me to a web page or manual or video or some documentation on where to begin? I'm totally new and completely green to VirtualBox programming. I do have strong low-level skills and can figure it out with some prompting.

The memory access for graphics mode is the only tricky thing. With 32 KB, the MDA has a total of (32768 / 80x25x2) eight standard text pages, with the graphics mode having an interlaced memory access, both of which I already have coded for in my Bochs MoMo implementation. I would also like to allow for a display presentation mode which would allow for higher resolutions, such as 160x50 at a minimum.

I would be the sole author, and I would license it for this use in VirtualBox. It would actually assist me greatly and I would be the first (and perhaps the most) to benefit from it.

Thank you!

[RickCHodgin]

Here's another question:

I've been forced to work on an old DOS-based legacy program recently. In so doing I wasn't content to go back in time and use 80x25 through 80x60, or even 132x25 through 132x60 text modes. So instead, I added a little bit of modern technology into the mix. I was able to modify some of the old DOS tools for which I have source code to enter a more modern graphics mode through VESA BIOS Extensions. I then altered the print screen functions that normally wrote to 0xb8000-0xbffff to then render graphically into the frame buffer using a bitmap font and UNREAL mode where FS and GS point to a flat 4GB memory space.

One existing VBE mode in VirtualBox allows 1600x1200, for example, which, using a 10x18 font, would allow for a 160x66 single screen space, which is far nicer than anything DOS provided. Plus, you can render graphics on it for window borders, or icons, or a mouse pointer.

So now I'm wondering this: How hard would it be to modify and extend the VBE implementation that VirtualBox uses to add new functions which recognize a few new graphics modes including at least 1920x1080, and 1920x1200, if not all the way up to things like 2560x1600, etc. And then, to even go the step further, to extend the API to give it multi-monitor support? A new register would be provided when switching into a mode which specifies the monitor number to reference.

If we could tweak VBE API to initialize multiple displays in VirtualBox, and use full-size modern graphics ... it would be fantastic for non-accelerated basic apps like old DOS programs and hobby OS projects.

[klaus]

I'd recommend starting with looking at some simple device emulations, especially of ISA devices. One which we have purely for this purpose (and to demonstrate how to create an extension pack) is the Bus Mouse emulation at https://www.virtualbox.org/browser/vbox ... ouseSample

Of course this doesn't cover everything but at least you should get the hang of the general code structure and getting IO port handlers registered. You'll need to add the VRAM handling for Hercules which you might be able to borrow partially from the VGA code. Probably not fully because VGA has two VRAM regions, ...

Another complication will be that the BIOS implementation does not currently have code for handling ROM-less graphics adapters such as MDA and CGA. That could be either written from scratch (setting up text mode isn't that much effort, it's mostly a question of graphics adapter detection) or partly extracted out of the VGA BIOS code.

Regarding adding video modes to the VGA BIOS: that's technically quite simple, they're in vbetables-gen.c. The reason for having 1600x1200 max is the old state of this part of the VGA BIOS code base which used just 8MB of VRAM. Could be updated from http://savannah.nongnu.org/projects/vgabios

[RickCHodgin]

klaus, you're a wealth of information.

I looked at vbe.c/h. In looking at the VBE 3.0 Standard, I can see how to add multi monitor support by adding a new enable feature using AX=4F14h (OEM Extensions), and a new input register for AX=4F02h when enabled:

Code: Select all

/** Function 02h - Set VBE Mode
 *
 * Input:
 *              AX      = 4F02h
 *              BX      = Desired Mode to set
>>--- New --->> DX      = Monitor number to set mode on
 *              ES:DI   = Pointer to CRTCInfoBlock structure
 * Output:
 *              AX      = VBE Return Status
 *
 */
 
/** Function 04h - Save/Restore State
 *
 * Input:
 *              AX      = 4F04h
 *              DL      = 00h Return Save/Restore State buffer size
 *                        01h Save State
 *                        02h Restore State
 *              CX      = Requested states
>>--- New --->> DX      = Monitor number to save/restore state on
 *              ES:BX   = Pointer to buffer (if DL <> 00h)
 * Output:
 *              AX      = VBE Return Status
 *              BX      = Number of 64-byte blocks to hold the state buffer (if DL=00h)
 *
 */
 
 /** Additional changes to the returned VBE struct when multi-monitor support is enabled */

I took a look at the code for VGA. It looks about 10x as complex as the MDA code would need to be.

-----
If I wrote a working prototype using a simple C API that could be tested and used as a source code base, is there anyone at Oracle or on a VirtualBox dev team that could integrate it faster? The MDA did provide int 10h BIOS support if it was the only card, so I could emulate those functions as well.

Let me know and I'll code up a full working example (with all source code, test code, and API interfacing) in Windows using Visual Studio.

Thank you for all of your help. I've often thought if I could get involved with people who were doing this kind of development I could really soar because everything I've done up until now has been in isolation learning and coding by myself because I just don't find many people who are interested in coding at these lower levels.

BTW, the operating system I wrote that used my MDA graphics monitor for its kernel debugger had the full VGA and MDA support in 64 KB, and a full 16-bit/32-bit disassembler in another 64 KB. The entire OS kernel and core was less than 200 KB.

[klaus]

Sorry, I can't promise significant dev help (other than sharing knowledge through the forums) at the moment. The dev team is totally booked out with much higher priority tasks, making it impossible to spend significantly more time than the minimal integration effort of a working contribution.

[RickCHodgin]

Sorry, I can't promise significant dev help...

Understood. I appreciate the assistance you've given me thus far. I'll see what I can come up with.