The game cannot run on Ati Radeon video cards and Windows 98 or Me. it opens without an image. Can it be fixed?
The source code can be found here: http://www.wieringsoftware.nl/mario/source.html
I tried with ChatGPT to edit VgA256.pas from Mode 13h, 320x200 256 colors to VESA mode, but no succes. Vga256.pas is too long.
Last edited by alexclaudiu2003 on 2023-04-18, 08:19. Edited 1 time in total.
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.
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?)
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.
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.
Gmlb256wrote 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:
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.
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.
clbwrote on 2023-09-11, 19:35:I downloaded the source, and Borland Turbo Pascal 7.1, and compiled the game from those sources. […] Show full quote
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.
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?)
There is no "working" version for modern systems. Freezes with a black screen upon being executed in DOS, and needs hard system reset to recover from. Even a freshly compiled from TPC 7 source code version doesn't work. I've tried it, as well as modifying the Pascal code to stick to a strict 320x200 video mode. The code uses undocumented VGA tricks (for buffering and speed) which are broken in Intel onboard video BIOSes of DOS on modern systems (anything from Core2duo on up).
I don't have the programming knowledge to be able to re-write or modify the source to not do these tricks with the VGA. Incidently, the author's other DOS games (Sint Nicholaas, Super Angelo, Charlie the Duck I and II, and his driving game Super Worms) do NOT have this "freeze" problem on modern systems. They run flawlessly. But the source code isn't available for any of those games. If it were, we could probably "patch" Mario to work with the VGA routines used in those other games. (This is evident in Super Angelo, which works perfectly in bare metal DOS, and which author Wiering admits shares lots of code with "Mario".)
Somebody should edit that compatibility list, in regards to that Mario game. There is no point in keeping that "Shareware Version", which is really an incomplete demo; when there is a "Full version" available at Mike Wiering website (http://www.wieringsoftware.nl/mario/download.html ).