in game "Seal Magic Eye" - graphics error, incorrect videomode

[Corak667]

Describe the bug

Hi. In game "Seal Magic Eye / Moyan Xieshen / 魔眼邪神" (RPG/1994/DOS) there is some graphic error, incorrect videomode. Compared to Dosbox Daum build: Normal (Dosbox Daum): Bad (Dosbox-X):

Game to test: http://coraksoft1.narod.ru/games/RPG/Seal-Magic-Eye-GameTChn.7z

Steps to reproduce the behaviour

Game to test: http://coraksoft1.narod.ru/games/RPG/Seal-Magic-Eye-GameTChn.7z

Expected behavior

No response

What operating system(s) this bug have occurred on?

Windows XP

What version(s) of DOSBox-X have this bug?

latest

Used configuration

No response

Output log

No response

Additional information

No response

Have you checked that no similar bug report(s) exist?

• [X] I have searched and didn't find any similar bug report.

Code of Conduct & Contributing Guidelines

• [X] I agree to follow the code of conduct and the contributing guidelines.

[grapeli]

A long time ago it worked fine in DOSBox-X as well. It broke exactly from this code change a9cab6d.

[grapeli]

Works fine with: dosbox-x -set 'ignore odd-even mode in non-cga modes=true'.

[maron2000]

Based on @grapeli 's findings and https://www.vogons.org/viewtopic.php?t=45808, it seems that odd-even mode should be ignored for mode 13h, which is I believe vga.mode == M_VGA. Maybe @joncampbell123 have some ideas about this?

--- a/src/hardware/vga_memory.cpp
+++ b/src/hardware/vga_memory.cpp
@@ -308,7 +308,8 @@ template <const bool chained> static inline void VGA_Generic_Write_Handler(PhysP
      * 
      * NTS: Real hardware experience says that despite the name, the Odd/Even bit affects reading as well */
     if (chained) {
-        if (!(vga.seq.memory_mode&4) && !non_cga_ignore_oddeven_engage)/* Odd Even Host Memory Write Addressing Disable (is not set) */
+        if (!(vga.seq.memory_mode&4) && !(vga.mode == M_VGA) && !non_cga_ignore_oddeven_engage)/* Odd Even Host Memory Write Addressing Disable (is not set) */
             mask &= 0xFF00FFu << ((rawaddr & 1u) * 8u);
         else
             mask &= 0xFFu << ((rawaddr & 3u) * 8u);

[joncampbell123]

Based on @grapeli 's findings and https://www.vogons.org/viewtopic.php?t=45808, it seems that odd-even mode should be ignored for mode 13h, which is I believe vga.mode == M_VGA. Maybe @joncampbell123 have some ideas about this?

--- a/src/hardware/vga_memory.cpp
+++ b/src/hardware/vga_memory.cpp
@@ -308,7 +308,8 @@ template <const bool chained> static inline void VGA_Generic_Write_Handler(PhysP
      * 
      * NTS: Real hardware experience says that despite the name, the Odd/Even bit affects reading as well */
     if (chained) {
-        if (!(vga.seq.memory_mode&4) && !non_cga_ignore_oddeven_engage)/* Odd Even Host Memory Write Addressing Disable (is not set) */
+        if (!(vga.seq.memory_mode&4) && !(vga.mode == M_VGA) && !non_cga_ignore_oddeven_engage)/* Odd Even Host Memory Write Addressing Disable (is not set) */
             mask &= 0xFF00FFu << ((rawaddr & 1u) * 8u);
         else
             mask &= 0xFFu << ((rawaddr & 3u) * 8u);

The answer is yes... and no. Since odd/even mode isn't supposed to be involved in 256-color mode and it's a bug if you do that, it probably depends on the SVGA chipset.

DOSBox-X added an option to ignore odd/even in 256-color mode because of a 1994 256-byte .COM in the Demoscene that makes a similar mistake with the registers in 256-color mode and correct display requires DOSBox-X to ignore it.

Staging probably doesn't want yet another option so it's probably best to always ignore odd/even mode in 256-color mode. However you shouldn't do it because the display is 256-color mode (you'll probably break the Windows 95 boot logo if you do---that mistake is why the boot logo breaks the text mode underneath when run in DOSBox SVN). Instead, ignore it if the VGA registers concerning video memory access are set up like chained 256-color mode, meaning set to map the low 2 bits of the memory address to which bitplane the byte goes to like 256-color mode.

Now that I bring that up, it would make sense for VGA logic to take an alternate path from the normal logic that applies odd/even mode and I suppose that yes 256-color mode would ignore it.

[joncampbell123]

I just realized I got this confused with the usual conversations I have with DOSBox Staging :)

I'll go ahead and add this to DOSBox-X default on for 256-color mode.

I want to add that odd/even mode should be emulated by default for all other standard VGA modes including 16-color planar because I think that's what standard hardware does and I think odd/even mode might be key to the poorly understood EGA 640x350 4-color planar mode that was reportedly offered by IBM EGA cards that had only 64KB of video RAM.

To explain why, 640x350 16-color mode requires 80350 = 28000 bytes per bitplane. 64KB would mean a maximum of 16KB per bitplane. Note that 640x200 is 80200 = 16000 bytes per bitplane and 320x200 is 40*200 = 8000 bytes per bitplane. Supposedly the 4-color mode was just 2 bitplanes tied together. I think odd/even mode in planar graphics might be key to making such a mode work.

[joncampbell123]

Alright. Here's what I've noticed about the game.

First, you need to add under the [dosbox] section:

ignore odd-even mode in non-cga modes=true

Second, even if the game displays somewhat normally, the random garbled water on the screen when the game starts, and the artifacts when the water animates will remain, unless you also add or set:

machine=svga_et4000

I also notice the files of the game are dated 1993, which is generally when Tseng ET4000 cards were widely popular on PCs. I think this game was written on ET4000 cards and never really tested much on other VGA hardware. It's not too unusual, there's a lot of pre-1994 Demoscene stuff with the same problem.

Whether Tseng ET4000 cards ever pay attention to odd/even in 256-color mode given the odd way they do "chained" 256-color mode compared to normal VGA is another matter I must test.

[joncampbell123]

Reading the link... that would make sense at a hardware level to either do chain 4 (bit 3) or odd/even (bit 2) because doing both at the same time is rather silly.

[joncampbell123]

Latest commit should run it as well as standard VGA. For flawless VGA emulation for this game, use machine=svga_et4000.