Re: [Freedos-devel] Why games have bad color in VirtualBox

[C. Masloch]

Hello Eric,

On at 2021-06-17 17:26 +0200, Eric Auer wrote:

while it is great to hear that you are doing a lot of
reading about EGA/VGA programming, I would suggest
that you use DEBUG to try a few things until you find
the first type of palette manipulation which works in
another virtual window but not in VirtualBox. Then
the next step could be trying to find setup changes
which solve the issue in VirtualBox. If none can be
found, the final option would be to patch VirtualBox.




Either that, or use DEBUG to try it out. Of course reading
and comparing source codes is a good starting point, but
EGA/VGA/CGA, as well as VESA/VBE could have some nasty
interactions which are hard to get compatible properly,
which may not be obvious from the source code.

So you can for example say "If I do those I (in) and O (out)
commands in DEBUG, or call this int 10 function, I expect
the palette to change this way and it indeed does in QEMU
or DOSEMU2, but not in VirtualBox" to get a confirmation
of where you suspect the problem to be.

It could also happen that the I/O or INT sequence you
had in mind works in none of the three, because there
are some additional preparatory I/O that you need. So
you can improve your I/O sequence and try again etc.

Note that DEBUG only offers byte-sized input and output.
For word-sized, you would have to write a test app in
any programming language you like to use for that :-)


FreeDOS Debug actually supports word-sized and dword-sized input and 
output, using the IW, ID, OW, and OD commands. My fork lDebug does 
likewise. lDebug additionally allows controlling the debugger through a 
serial port [1], which defaults to COM2 but can be configured for other 
ports too [2]. Further, lDebug allows loading script files using the Y 
command. The serial I/O and script file reading may be useful to test 
VGA output.


Regards,
ecm


[1]: https://pushbx.org/ecm/doc/ldebug.htm#interface-serial
[2]: https://pushbx.org/ecm/doc/ldebug.htm#varserial


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Liam Proven]

On Thu, 17 Jun 2021 at 04:58, Paul Dufresne via Freedos-devel
 wrote:

> I did not check capabilities return by QEMU...
> My vague hypothesis is that the game use VGA functions, rather than VBE 
> function to set palette,
> and that it matters because D0=1... and I make the assumption D0=0 for QEMU.

VBox has 3 different emulated video adapters, IIRC. Tried them all?

But for  super-timing-critical stuff, a VM is not the ideal thing.

And for games, I'd recommend DOSbox over VirtualBox.


-- 
Liam Proven – Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk – gMail/gTalk/gHangouts: lpro...@gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven – Skype: liamproven
UK: +44 7939-087884 – ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Bret Johnson]

I have a really old PC Magazine utility called EGAPALET that at the time was 
called a bit of "gonzo programming".  Normally, EGA (& VGA) only allows 16 
colors at a time on the screen but the color palette is 64 colors.  EGAPALET 
lets you see all 64 colors on the screen at the same time.  It really does some 
low-level, very fast (Assembly Language) programing of the video registers to 
accomplish this.  This program might be a good test for low-level EGA/VGA 
register compatibility.

In addition, this is a good test for computer speed (at least video speed).  
You need to have a really fast video speed to see all 64 colors at once.  If 
your video is not fast enough, you won't see all 64 colors.  In a VMWare 
virtual machine on my relatively fast desktop running Windows 10, I only see 8 
colors (which is the minimum you can see).  On raw hardware on the same 
machine, I see all 64 colors.  On my fairly old laptop (probably about 7 years 
old now) running raw I see about 25 colors (it might do better with an external 
monitor).  Even on my older desktops (386/486 vintage) I was able to see all 64 
colors.

Even though PC Magazine has officially pulled all of their old utilities from 
circulation, you can still find them if you look in the right places.  They 
even used to include the source code for their programs so you could create 
something similar of you wanted.

I'm not sure where this would fall in the discussion of copyright issues given 
PC Magazine's history, but somebody may want to play around with it. 


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Jim Hall]

On Thu, Jun 17, 2021 at 1:09 PM Paul Dufresne via Freedos-devel
 wrote:
>
> vgapal works in VirtualBox ... and DOSEMU2, not tested under QEMU.
>
> I think problematic games run under DPMI (protected mode).
> Might be linked to the problem for VirtualBox not handling color palettes 
> correctly... sometime.
> Will have to look the source code of the games to see how they do... would 
> not be surprised they use Allegro.
>


I've tested vgapal before under QEMU. Works fine there too.


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Paul Dufresne via Freedos-devel]

vgapal works in VirtualBox ... and DOSEMU2, not tested under QEMU.



I think problematic games run under DPMI (protected mode).

Might be linked to the problem for VirtualBox not handling color palettes 
correctly... sometime.

Will have to look the source code of the games to see how they do... would not 
be surprised they use Allegro.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Jerome Shidel]

Jim, 

> On Jun 17, 2021, at 12:52 PM, Jim Hall  wrote:
> 
> On Thu, Jun 17, 2021 at 11:21 AM Jerome Shidel  > wrote:
>> 
>> Hi,
>> 
>> A while back Jim did a nice article on DOS text mode colors.
>> 
>> I asked him why he didn’t cover VGA text mode pallets for customizing them.
>> 
>> This led to the creation of a simple tool to demonstrate altering the text 
>> mode colors to whatever RGB value you want on VGA systems.
>> 
>> https://fd.lod.bz/repos/current/pkg-html/vgapal.html
>> 
> 
> 
> That is indeed a neat little tool. When I wrote that article, I didn't
> realize you could change the text palette. Very neat to experiment
> with this tool. :-)
> 
> Also: I rewrote and expanded on that other "text colors" article, and
> it's today's article in the month-long series:
> https://opensource.com/article/21/6/freedos-sixteen-colors 
> 
> 
> (But I didn't mention palettes in this one, either.)

I don’t blame you for not mentioning it. 

It really is a whole new can of worms. Kinda like custom text mode fonts.

Perhaps something that belongs in a different article.
 
Like maybe the types and progression of video cards.

Or, maybe something on the differences between EGA and VGA. 

Or, who knows… All kinds of possibilities. 

:-)

Jerome





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Ralf Quint]

On 6/17/2021 9:52 AM, Jim Hall wrote:

On Thu, Jun 17, 2021 at 11:21 AM Jerome Shidel  wrote:

Hi,

A while back Jim did a nice article on DOS text mode colors.

I asked him why he didn’t cover VGA text mode pallets for customizing them.

This led to the creation of a simple tool to demonstrate altering the text mode 
colors to whatever RGB value you want on VGA systems.

https://fd.lod.bz/repos/current/pkg-html/vgapal.html

While that article has some relation to (Free)DOS, I think the whole 
discussion about how VirtualBox (or others) are handling VGA register 
compatibility should rather be moved into their respective support forums.


just my 2c,

Ralf



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Jim Hall]

On Thu, Jun 17, 2021 at 11:21 AM Jerome Shidel  wrote:
>
> Hi,
>
> A while back Jim did a nice article on DOS text mode colors.
>
> I asked him why he didn’t cover VGA text mode pallets for customizing them.
>
> This led to the creation of a simple tool to demonstrate altering the text 
> mode colors to whatever RGB value you want on VGA systems.
>
> https://fd.lod.bz/repos/current/pkg-html/vgapal.html
>


That is indeed a neat little tool. When I wrote that article, I didn't
realize you could change the text palette. Very neat to experiment
with this tool. :-)

Also: I rewrote and expanded on that other "text colors" article, and
it's today's article in the month-long series:
https://opensource.com/article/21/6/freedos-sixteen-colors

(But I didn't mention palettes in this one, either.)


Jim


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Paul Dufresne via Freedos-devel]

That said, I am at least partially wrong.



Changing colors works in VirtualBox, QEMU and DOSEMU2.



color 0 is black, this is the default color for text mode.



In Debug:

-o 3c8,0

-o 3c9,0

-o 3c9,0

-o 3c9,ff

Change the black to blue.

(out 3c8,0 choose color 0, then first value at 3c9 is red=0, next green=0 then 
blue to the max).



It is a bit more complicated than I thought/said.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Eric Auer]

Hi!

I vaguely remember that you could do "copper bars" in DOS by
quickly changing DAC mask or similar registers, not sure which.

Is any of that working in any simulator? Or is it one of the
few things which only work with real hardware? :-)

The idea is to change colors at different moments during the
screen refresh timing :-)

Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Jerome Shidel]

Hi,

A while back Jim did a nice article on DOS text mode colors.

I asked him why he didn’t cover VGA text mode pallets for customizing them.

This led to the creation of a simple tool to demonstrate altering the text mode 
colors to whatever RGB value you want on VGA systems.

https://fd.lod.bz/repos/current/pkg-html/vgapal.html 


:-)

Jerome___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Paul Dufresne via Freedos-devel]

More precisely, the default DAC Mask ( i 3c6 in debug) is:

QEMU: FF

DOSEMU2: FF

VirtualBox: 00



VirtualBox default mask of 0 and the fact that it cannot be changed, 

could well explains changing colors directly does not work.

(as I believe a mask of 0 make it not change any colors when changing colors)___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Paul Dufresne via Freedos-devel]

I think I understand what is happening.

First, an extract from: 
https://www.phatcode.net/res/224/files/html/ch34/34-05.html

The DAC Mask
"There’s one register in the DAC that I haven’t mentioned yet, the DAC Mask 
register at 03C6H. The operation of this register is simple but powerful; it 
can mask off any or all of the 8 bits of pixel information coming into the DAC 
from the VGA. Whenever a bit of the DAC Mask register is 1, the corresponding 
bit of pixel information is passed along to the DAC to be used in looking up 
the RGB triplet to be sent to the screen. Whenever a bit of the DAC Mask 
register is 0, the corresponding pixel bit is ignored, and a 0 is used for that 
bit position in all look-ups of RGB triplets. At the extreme, a DAC Mask 
setting of 0 causes all 8 bits of pixel information to be ignored, so DAC 
location 0 is looked up for every pixel, and the entire screen displays the 
color stored in DAC location 0. This makes setting the DAC Mask register to 0 a 
quick and easy way to blank the screen."

So, I believe the DAC MASK is the thing that allows you to programmatically 
choose if the colors are 6 bits or 8 bits, if the controller
report capabilities D0=1.

We know, VBOX and DOSEMU2 both support 8 bits colors, while QEMU only supports 
6 bit colors.

If I output 3c6,0:
  QEMU: no change
  VBOX: no change
  DOSEMU2: clear screen

For QEMU, it is not dramatic, because it is limited to 6 bit colors. [still not 
ideal]
DOSEMU2: do the right thing.
VBOX: should handle the mask, because this is the way the 8 bit colors can be 
set.
[it is unclear what is the default value of the mask]

That said, I did not try more, to change colors.





___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Eric Auer]

Hi Paul,

while it is great to hear that you are doing a lot of
reading about EGA/VGA programming, I would suggest
that you use DEBUG to try a few things until you find
the first type of palette manipulation which works in
another virtual window but not in VirtualBox. Then
the next step could be trying to find setup changes
which solve the issue in VirtualBox. If none can be
found, the final option would be to patch VirtualBox.

> In 
> https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Graphics/DevVGA.cpp
> 
> For write: line 616-640: no 0x3c6 between 0x3c5 and 0x3c7.
> 
> For read: line 503-507, no 0x3c6 between 0x3c5 and 0x3c7.
> 
> Might compare with what dosemu2, or qemu does, to see if they do something 
> about 0x3c6.

Either that, or use DEBUG to try it out. Of course reading
and comparing source codes is a good starting point, but
EGA/VGA/CGA, as well as VESA/VBE could have some nasty
interactions which are hard to get compatible properly,
which may not be obvious from the source code.

So you can for example say "If I do those I (in) and O (out)
commands in DEBUG, or call this int 10 function, I expect
the palette to change this way and it indeed does in QEMU
or DOSEMU2, but not in VirtualBox" to get a confirmation
of where you suspect the problem to be.

It could also happen that the I/O or INT sequence you
had in mind works in none of the three, because there
are some additional preparatory I/O that you need. So
you can improve your I/O sequence and try again etc.

Note that DEBUG only offers byte-sized input and output.
For word-sized, you would have to write a test app in
any programming language you like to use for that :-)

Regards, Eric




___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Paul Dufresne via Freedos-devel]

Ok, a few minutes ago, I had no idea about which I/O ports were related to 
colors...

and now, I begin to suspect what could be wrong in VirtualBox code,

that is it seems to ignore port 0x3c6 (mask register)... which is said:

"in normal use, should be 0xff"...



In: https://bos.asmhackers.net/docs/vga_without_bios/docs/palettesetting.pdf

they explains how to directly manipulate colors...



In 
https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/Graphics/DevVGA.cpp

For write: line 616-640: no 0x3c6 between 0x3c5 and 0x3c7.

For read: line 503-507, no 0x3c6 between 0x3c5 and 0x3c7.



Not sure how much I am on the right track with that.



Might compare with what dosemu2, or qemu does, to see if they do something 
about 0x3c6.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Eric Auer]

Hi Paul,

> I was thinking... I think DOSEMU2 execute program in VM86 mode.

Only if it is a real mode program. If it is a protected
mode program, it uses protected mode. DOSEMU2 has DPMI.

> That way, direct IN/OUT generate an interrupt that
> can be intercepted to emulate hardware.

Yes. This is how most emulators emulate hardware, because
you would not want your emulator to mess up your real VGA.

Actually even MS EMM386 has an interface to register
for notification when IN/OUT happens. This is used by
some "SoundBlaster compatible" PCI soundcards to trap
attempts to access a classic SoundBlaster 16 and let
some driver shipped with the PCI soundcards create an
illusion of having an ISA soundcard. Unfortunately,
JEMM386 does not yet support that interface, but some
drivers can use VM86 themselves to simulate a SB16,
without needing help from MS EMM386. In all cases,
EMM386 puts DOS inside a VM86 task, because it has
to run in protected mode itself (to "simulate" EMS,
which originally was an ISA add-on hardware, and UMB)
which is why some games only run if EMM386 is NOT on.

> It is a bit unclear how QEMU/VirtualBox works... I have
> read, that newer CPU emulate a full CPU.

Emulators for complete computers such as QEMU and VirtualBox
indeed tend to emulate the full CPU, so apps can believe that
they could do whatever they want. However, this STILL allows
you to catch IN/OUT attempts and simulate hardware :-)

You can also do this with CPU virtualization assistance,
but again, emulators ALWAYS emulate part of your hardware.

If they have DOS users as target audience, the hardware will
include VGA and SoundBlaster 16 and similar. If the goal is
to run Windows 10 inside a window on your Apple, then your
emulator is NOT likely to emulate things needed by DOS games.

Eric



___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Paul Dufresne via Freedos-devel]

I was thinking... I think DOSEMU2 execute program in VM86 mode.

That way, direct IN/OUT generate an interrupt that can be intercepted to 
emulate hardware.



It is a bit unclear how QEMU/VirtualBox works... I have read, that newer CPU 
emulate a full CPU.

But I don't know the details... and how much they can intercept direct I/O 
while showing the program to be in real mode,

rather than in VM86 mode.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Mercury Thirteen via Freedos-devel]

This wouldn't be the first thing VirtualBox doesn't implement fully/correctly. 
Another notable omission is the "direct" mode of creating sound by writing 
values straight to a SoundBlaster-compatible card; VirtualBox only supports DMA 
transfer for sound.

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

‐‐‐ Original Message ‐‐‐
On Thursday, June 17th, 2021 at 8:56 AM, Paul Dufresne via Freedos-devel 
 wrote:

> DOSEMU2 seems to report itself almost exactly as VirtualBOX, that is:
> VBE 2.0, D1=0:VGA compatible D1=0, D0=1:DAC is fixed with 6 bit by primary 
> color
>
> This destroy my hypothesis about games USING VGA Set palette function...
> rather than the VBE one (AL=9... had wrongly written AH=9 in previous mail).
> Because games works fine about palette in DOSEMU2.
>
> So the new hypothesis is: VirtualBox does not handle correctly direct 
> manipulation
> of VGA palette registers, although claiming VGA compatibility would suggest 
> it should.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Paul Dufresne via Freedos-devel]

DOSEMU2 seems to report itself almost exactly as VirtualBOX, that is:

VBE 2.0, D1=0:VGA compatible D1=0, D0=1:DAC is fixed with 6 bit by primary color



This destroy my hypothesis about games USING VGA Set palette function...

rather than the VBE one (AL=9... had wrongly written AH=9 in previous mail).

Because games works fine about palette in DOSEMU2.



So the new hypothesis is: VirtualBox does not handle correctly direct 
manipulation

of VGA palette registers, although claiming VGA compatibility would suggest it 
should.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Paul Dufresne via Freedos-devel]

QEMU, AX=4F00 INT 10h (Return VBE controller information) reports itself as 
version 3.0.
So I use http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf

Capabilities:
D0=0 DAC is fixed width, with 6 bits per primary color
D1=0 Controller is VGA compatible
D2=0Normal RAMDAC operations
D3=0 No hardware stereoscopic signaling

So D0=0, as I was expecting for QEMU.


___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Why games have bad color in VirtualBox

[Paul Dufresne via Freedos-devel]

I have checked, https://www.virtualbox.org/ticket/4777

and it seems there is no bug... today. (bug was reported 12 years ago)



I am using doc at:

https://web.archive.org/web/20081211174813/http://docs.ruudkoot.nl/vbe20.txt



VBox, return VBE 2.0, so it does support AH=9 to set/get palette.

And I verified that it does it in text mode.

The author say that capabilities is 1, and that it means it does not support 
VGA.

I confirm capabilities, is 1 (first byte is 1, other are 0).

This means:

" The Capabilities field indicates the support of specific features in
 the graphics environment. The bits are defined as follows:

D0 = 0 DAC is fixed width, with 6 bits per primary color

    = 1 DAC width is switchable to 8 bits per primary color

D1 = 0 Controller is VGA compatible

 = 1 Controller is not VGA compatible
 

D2 = 0 Normal RAMDAC operation


    = 1 When programming large blocks of information to the
RAMDAC use blank bit in Function 09h. i.e. RAMDAC
recommends programming during blank period only.
 D3-31  = Reserved"



So D0=1 means DAC width is switchable to 8 bits per primary color

And D1=0 which means VGA compatible.



I suspect when D0=1 it is more important to use VBE AH=9 to get/set palette 
rather than the VGA function:

https://fd.lod.bz/rbil/interrup/video/100b_bh01.html



I did not check capabilities return by QEMU...

My vague hypothesis is that the game use VGA functions, rather than VBE 
function to set palette,

and that it matters because D0=1... and I make the assumption D0=0 for QEMU.___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel