- Redraw the overlay region only instead of full screen.
- Set up overlay parameters at register writes.
TODO list:
- 24 / 32 bpp desktop support
- Overlay color conversion YUV -> RGB
- Overlay scaling support
- Moved Banshee/Voodoo3 desktop update code to banshee.cc.
- Added desktop / overlay mode testing code for the 16 bpp case.
- Added basic UYUV format decoding for black and white output.
- Only the fullscreen overlay mode is handled in voodoo.cc.
- Reduce BX_ERROR messages when writing to vidProcCfg register.
These issues appear when -Werror=format on 32-bit platforms depending on
the exact definitions of uint64_t and size_t.
It doesn't appear that bochs uses %zu for size_t -- since you support
Windows platforms, unclear if that would work for you. If so, that's
definitely correct rather than the unsigned long cast.
autoconf-based packages conventionally respect the DESTDIR environment
variable rather needing to explicitly override it.
Likewise the distclean target is conventionally named distclean rather
than dist-clean. This change adds a top-level alias to be compatible.
These changes are needed to build bochs on my infrastructure without
having to special case bochs or locally patch it.
Setting VBE memory size to 4, 8, 16 and 32 MB is now possible. Since a memory
size change can also change the number of available modes and the value for
"number of image pages" in the mode info it is required to use the latest
VGABIOS binary.
Related changes:
- Make sure the VBE entry appears at index 1 of VGA extension option list.
- Removed all memory size constants and use BX_VGA_THIS s.memsize instead.
TODO: Remove the static mode info table and create it dynamicly similar to
Banshee and Cirrus.
after checking agains Intel reference decoder (Xed) it shown few mismatches.
The mismatches are not functionally important - some very long instructions with lock prefix would cause #UD (due to badly placed lock prefix) insetad of #GP due to excessive opcode length
Seems like Xed evaluates entire instruction to the end and only then converts it to #UD due to lock prefix
This allows the `usb` option to be used in the `boot:` parameter. Of
course there is not support for booting from a USB, but this allows for
a (probably much) further down the road addition.
This will break the current bios when booting from a network. However,
the bios is already broken in this manner, especially when
`BX_ELTORITO_BOOT` is not defined. The current bios code assumes and
hard codes the BEV entry to 4. However, if the `BX_ELTORITO_BOOT` define
is missing, the BEV will be added to the third entry, not the fourth
entry.
For the BIOS to be updated correctly, things like the following will
need to be updated instead of hard coded to `[4]`.
54961f0326/bochs/bios/rombios.c (L2205)
The following will need to be not hard coded to 4.
54961f0326/bochs/bios/rombios.c (L2253-L2257)
The following will need "usb" added.
54961f0326/bochs/bios/rombios.c (L2102)
The following assumes the next entry will be the fourth entry, not
checking to see if `BX_ELTORITO_BOOT` was defined.
54961f0326/bochs/bios/rombios.c (L10851-L10857)
The following comment will need to be updated.
54961f0326/bochs/bios/rombios.c (L8365-L8371)
As well as a few other fixes and updates.
This PR simply allows the value of '4' (`BX_BOOT_USB`) to be placed in
the boot sequence options, moving the network (`BX_BOOT_NETWORK`) to the
next number.
The boot sequence option still only allows three parameters.
`boot: cdrom, floppy, disk`
or
`boot: cdrom, usb, disk`
I don't think it is necessary to add a fourth.
---------
Co-authored-by: Volker Ruppert <Volker.Ruppert@t-online.de>
The current code would panic if booting from network is selected.
Added two empty items for PCMCIA and USB as a workaround.
FIXME 1: The config interfaces win32paramdialog and wxdialog now showing
two empty lines in combo box.
FIXME 2: The Bochs BIOS can only boot from network if selected in boot menu
(press F12).
