alexclaudiu2003 wrote on 2023-04-17, 20:07:

I tried with ChatGPT

The hype of AI doesn't mean you can summon Michael Abrash on demand.

leileilol wrote on 2023-04-17, 21:09:

alexclaudiu2003 wrote on 2023-04-17, 20:07:

I tried with ChatGPT

The hype of AI doesn't mean you can summon Michael Abrash on demand.

😁😁😁

Up!

Gave this a quick peek today.

On my Cirrus Logic CL-GD5446, I do also get a black screen. The game is not crashed, as I can press esc key to quit back to DOS.

Mario is known to program a custom video mode directly through the registers. Here is the video mode that I see with MARIO.EXE:

It has a default Mode 13h video width, but nonstandard video with with respect to Mode 13h. Mode 13h would have 414 active video lines, but this has only 363.

However, oddly, when I look at the Pascal source code that can be downloaded there, I was not able to find where it would be programming that 363 video lines height.

I was able to see the following custom VGA register values:

1Set VGA Mode 13h;
23D4h/13h <- 45          // Set virtual screen width to 360 pixels
33C4h/04h <- clear bit 3 // Switch from Chain-4 mode to Unchained mode (Mode X)
43CEh/04h <- clear bit 4 // Disable Host Odd/Even Memory Addressing Mode. Not sure why, since this should already be disabled in Mode 13?
53CEh/06h <- clear bit 1 // Select Even Map (Address A0:=0), although this is ignored, since not in Odd/Even mode?
63D4h/14h <- clear bit 6 // Disable Double-Word Addressing
73D4h/17h <- set bit 6   // Set Byte mode Addressing. This together with the above sets the standard Mode-X Unchained/Planar addressing

That's all I could find. Could not find CRTC register reprogramming values, so if that happens (like it looks like it does), maybe it is somewhere else than in VGA256.PAS.

No idea I'm afraid, but hope that helps nudge it forward.

I downloaded the source, and Borland Turbo Pascal 7.1, and compiled the game from those sources.

Surprisingly, the result of the compilation actually does work on my PC, with the same Cirrus Logic CL-GD5446 card that gave a black screen in the precompiled version.

So I realize there are multiple versions:

1. https://gona.mactar.hu/DOS_TESTS/ provides a download link to MARIO: "Mario - the shareware 1995.08.26". It is a Shareware demo, but has some kind of "Utter Chaos '95" ASCII intro from a crack group added to it. This version gives a black screen on my Cirrus Logic CL-GD5446 card.

1MARIO.EXE: 21,836 bytes. CRC32: 4544A284
2DF.EXE: 66,055 bytes. CRC32: 73FD88E8

2. MARIO.EXE directly from the author's web site: http://www.wieringsoftware.nl/mario/download.html . This version works ok.

1MARIO.EXE: 57,480 bytes. CRC32: 9BA96C89

3. MARIO.EXE that I compiled from the author's source and instructions at http://www.wieringsoftware.nl/mario/index.html . This version works ok. Maybe identical to version 2, except that version 2 has some kind of EXE compression on it as well, to get the small size?

1MARIO.EXE: 164,528 bytes. CRC32: 73157550

I dumped the CRTC (3D4h), Attribute (3C0h), Sequencer (3C4h) and Graphics (3CEh) registers via DOSBox-X in versions 1 vs 2, and recreated those registers on the actual PC with Cirrus Logic, but I was unable to find a difference in the video modes between 1 or 2: they both seem to create the same 328x363 video signal. I wasn't able to reproduce why the screen is black in version 1 either.

Maybe you downloaded your copy from gona.mactar.hu? If you just want to play the game, try downloading the version directly from the author's website since that is different from gona.mactar.hu, and might have a better chance of working. It would be cool to know what's going on with version 1 though, but I was unable to disassemble that - looks like both IDA and Reko at least get confused by the executable. (maybe due to an EXE compressor?)

clb wrote on 2023-09-11, 19:35:

It would be cool to know what's going on with version 1 though, but I was unable to disassemble that - looks like both IDA and Reko at least get confused by the executable. (maybe due to an EXE compressor?)

If you want to keep investigating, I'd try using UNP from https://bencastricum.nl/unp/ to try to decompress it. I don't try to disassemble old software very often, but when I have I think UNP has always worked for me, and I think I first started using it sometime in the '90s.

clb wrote on 2023-09-11, 19:35:

I dumped the CRTC (3D4h), Attribute (3C0h), Sequencer (3C4h) and Graphics (3CEh) registers via DOSBox-X in versions 1 vs 2, and recreated those registers on the actual PC with Cirrus Logic, but I was unable to find a difference in the video modes between 1 or 2: they both seem to create the same 328x363 video signal. I wasn't able to reproduce why the screen is black in version 1 either.

The black screen in the hacked version (DF.EXE, not MARIO.EXE which is a launcher) is caused by the following instructions which performs 16-bit writes to the CRTC register 13h:

1CA0Dh BA D4 03  mov dx, 3D4h
2CA10h B8 13 00  mov ax, 13h
3CA13h EF        out dx, ax
4CA14h 58        pop ax
5CA15h 42        inc dx
6CA16h EF        out dx, ax
7CA17h 4A        dec dx

Some video cards (including the Cirrus Logic GD-5446) doesn't write to port 3D5h if an out dx, ax instruction is used. By replacing both out dx, bx instructions with out dx,al, the screen will be displayed correctly on all video cards.

P.S. Crystal Caves and Secret Agent has a similar issue because of the aforementioned way the offset value is written to the CRTC register 13h.

Edit: Replaced way to fix the black screen issue, the previous one was a quick and dirty solution.

Gmlb256 wrote on 2023-09-16, 02:37:

The black screen in the hacked version (DF.EXE, not MARIO.EXE which is a launcher) is caused by the following instructions which […]
Show full quote

The black screen in the hacked version (DF.EXE, not MARIO.EXE which is a launcher) is caused by the following instructions which performs 16-bit writes to the CRTC register 13h:

Copy code to clipboard

1CA0Dh BA D4 03  mov dx, 3D4h
2CA10h B8 13 00  mov ax, 13h
3CA13h EF        out dx, ax
4CA14h 58        pop ax
5CA15h 42        inc dx
6CA16h EF        out dx, ax
7CA17h 4A        dec dx

Some video cards (including the Cirrus Logic GD-5446) doesn't write to port 3D5h if an out dx, ax instruction is used. By changing mov ax, 13h to mov ax, 2d13h in the offset CA10h and NOPing the second out dx, ax instruction, the screen will be displayed correctly on all video cards.

Isn't the most straightforward fix to replace the out dx,ax instructions by out dx,al, as most likely intended by the programmer? The opcode would be EE instead of EF.

A bug like this can be caused by inexperienced programmers using Borland's Turbo C library: They have outport for word writes and outportb for byte writes. It's easy to forget to add the "b" to the function name to accidentally generate a word instead of a byte write. On the other hand, this disassembly doesn't look like Turbo C generated code, so in this instance the root cause of the inappropriate OUT instruction is likely different.

mkarcher wrote on 2023-09-16, 08:16:

Isn't the most straightforward fix to replace the out dx,ax instructions by out dx,al, as most likely intended by the programmer? The opcode would be EE instead of EF.

Indeed, replacing both out dx, ax instructions with out dx, al is the most straightforward way to fix it as it keeps the selected CRTC register.

Awesome digging, that's definitely it. No wonder trying to repro DOSBox video register state completely missed this scenario.

Updated SNOOP to detect this:

https://github.com/juj/crt_terminator/blob/d3 … CPP#L1023-L1069