12-30-2024, 09:52 AM (This post was last modified: 12-30-2024, 09:59 AM by samsepi0l.)
I'm starting a separate thread dedicated to better understanding the crashes we sometimes get. I'm posting some screenshots here as well. I have been somewhat been trying to be self-taught to better learn assembly and reverse engineering and I recognize some of the terminology here as related to the stack and the registers.
I hope tjerk or wolfpd don't mind, but I cross-posted these pictures to the vogons forum.
I will also like to say, it looks like to me, that Jake's crashes at Denver were preceded by a warp very briefly. So it looks like there was impact with something before the crash (a split second). My crash at Portln89 did not have a warp, and I didn't hit a wall (I actually play with damage=off). I had just slightly gone over one of the curbs (like I normally do) in the portland 89 front stretch chicane.
Interesting chat I had with chatGTP40 - I colored my font RED.
can you help me understand what a "exception 00h" is?
GPT-4o mini
"Exception 00h" typically refers to a specific type of exception or interrupt in computer systems, particularly in the context of x86 assembly language and operating systems. In this context, exceptions are events that disrupt the normal flow of execution in a program, often due to errors or specific conditions.
In the x86 architecture, exceptions are often categorized by their interrupt vector numbers. The "00h" (or 0 in decimal) exception is usually associated with a "Divide by Zero" error. This occurs when a program attempts to divide a number by zero, which is mathematically undefined and leads to an exception being raised by the CPU.
When a "Divide by Zero" exception occurs, the operating system typically handles it by terminating the offending program and may provide an error message to the user. In some cases, the operating system may also log the error for debugging purposes.
If you have a specific context or system in mind where you encountered "Exception 00h," please provide more details, and I can give you a more tailored explanation.
I get this error from time to time when playing the game "indycar racing 2" by papyrus. It is a dos game that I play in a emulator called dosbox. As you said when it crashes with this error it does give me a screenshot of what look to me like variables, or some kind of assembly code related information. Unfortunately I don't understand much about assembly code- but I think some of these relate to the stack and registers.
GPT-4o mini
The "Exception 00h" error you're encountering in "IndyCar Racing 2" while using DOSBox is indeed indicative of a "Divide by Zero" error, which can occur for various reasons in older games, especially when running in an emulator. Here’s a breakdown of what might be happening and how to approach it:
Possible Causes
Game Logic Error: The game may have a bug that leads to a division by zero in certain situations, such as specific race conditions or configurations.
Emulation Issues: DOSBox, while generally reliable, may not perfectly emulate the original hardware or software environment, leading to unexpected behavior in some games.
Configuration Settings: Certain settings in DOSBox (like CPU cycles, memory settings, or graphics settings) might affect how the game runs and could lead to errors.
Understanding the Error Output
The output you see when the game crashes, which includes registers and stack information, is useful for debugging. Here’s a brief overview of what some of these components mean:
Registers: These are small storage locations in the CPU that hold data temporarily. Common registers include:
EAX, EBX, ECX, EDX: General-purpose registers.
ESP: Stack pointer, which points to the top of the stack.
EBP: Base pointer, often used to reference function parameters and local variables.
Stack: The stack is a region of memory used for storing temporary data, such as function parameters, return addresses, and local variables. When a function is called, a new stack frame is created, and when it returns, that frame is removed.
Troubleshooting Steps
Check for Patches: Look for any patches or updates for "IndyCar Racing 2" that might fix known bugs.
Adjust DOSBox Settings: Experiment with different CPU cycle settings, graphics settings, or sound settings in DOSBox. Sometimes, lowering the CPU cycles can help with stability.
Run in Compatibility Mode: If you have access to a Windows version of the game, try running it in compatibility mode for older versions of Windows.
Use a Different Emulator: If the problem persists, consider trying a different DOS emulator, such as DOSBox-X, which may have different compatibility features.
Conclusion
While the assembly code and register information can be complex, the key takeaway is that the "Exception 00h" error is likely due to a divide by zero condition triggered by the game or the emulator. By adjusting settings and looking for patches, you may be able to mitigate the issue. If you're interested in learning more about assembly language or debugging, there are many resources available that can help you understand the basics.
The problem with this situation is that the game is 30 years old and is basically abandonware. If I was able to load the EXE with a disassembly tool like GHIDRA, would the output help? This problem would happen from time to time back when I had the game on a real DOS machine as well. I think it is a bug that was never addressed by the developers
GPT-4o mini
Given that "IndyCar Racing 2" is an older game and likely considered abandonware, using a disassembly tool like Ghidra could indeed provide valuable insights into the game's code and help you understand the cause of the "Exception 00h" error. Here’s how you might approach this:
Using Ghidra for Disassembly
Load the Executable: You can load the game's executable (EXE) file into Ghidra. The tool will analyze the binary and provide a disassembled view of the code, which can help you identify where the error might be occurring.
Identify the Division Operations: Look for division operations in the disassembled code. In x86 assembly, division is typically performed using the DIV or IDIV instructions. You can search for these instructions to find potential locations where a division by zero might occur.
Check for Zero Divisors: Once you locate the division instructions, examine the code leading up to them to see how the divisor is being set. You’ll want to trace back to see if there are any conditions under which the divisor could be zero.
Analyze the Call Stack: If the disassembly includes function calls, you can analyze the call stack to see what functions are being executed when the error occurs. This can help you understand the context in which the division by zero happens.
Look for Input Handling: Since the game may be influenced by user input or game state, check how the game handles inputs and state changes. Bugs in input handling could lead to unexpected values being used in calculations.
Limitations
Complexity: Disassembling and analyzing assembly code can be quite complex, especially if you’re not familiar with assembly language. It may take time to understand the flow of the program and identify the root cause of the error.
Lack of Documentation: Since the game is old and likely has no official documentation, you may need to rely on your own analysis and possibly community resources or forums where others have discussed similar issues.
Community Resources
Forums and Communities: Look for retro gaming forums or communities where enthusiasts discuss old games. Others may have encountered the same issue and could have insights or even patches.
Modding Communities: Sometimes, modding communities for older games can provide unofficial fixes or workarounds for bugs.
Conclusion
Using Ghidra to disassemble the game's executable could help you identify the source of the "Divide by Zero" error. While it may require some effort and familiarity with assembly language, it could lead to a better understanding of the bug and potentially help you find a workaround or solution. If you do decide to go down this path, consider documenting your findings, as they could be valuable to others who encounter the same issue.
I don't have any knowledge in this stuff. But looking at the error messages and your conversation with ChatGPT, I would start with the following questions.
There are address references in the first and last row of the message. Are they referencing to an address in the EXE or in the CPU (or probably in the track data, because the path after the message is the track folder)?
What does TSF32 mean?
12-30-2024, 05:44 PM (This post was last modified: 12-30-2024, 06:02 PM by Pavel 69.)
It's just a small chance that Dos32a may solve our problem. Because it also can crash with divide by zero errors (https://www.vogons.org/viewtopic.php?t=83065&start=120)
It's all depend from data that actual game sends to extender. I think something happens with cars latitude data when car leave/enter track sections. Maybe with wrong latitude value car is send outside trk surface, no suface underneath - it's zero. Then maybe physics calculations go wrong there.
12-30-2024, 05:59 PM (This post was last modified: 12-30-2024, 06:16 PM by samsepi0l.)
Pavel 69 Wrote:It's all depend from data that actual game sends to extender. I think something happens with cars latitude data when car leave/enter track sections. Maybe with wrong latitude value car is send outside trk surface, no suface underneath - it's zero. Then maybe physics calculations go wrong there.
Interesting. One time on original papy Belle Isle I was warped outside of the track surface- but it didn't catch me and bounce me back into the boundary of the track like you normally see when this happens. Instead, I was able to drive. It was like an infinite plane. I hit the max speed my wings would let me (which was 186mph I remember) and when I started steering the car I could hear the tires continue to squeal like it was sliding. There was no 3do to view so it was like driving on air but the physics felt the same even know I couldn't see. After a short time I ended up blowing a tire simply from wearing them out this way. Maybe this is a strange example, but do we really have any other data to say there's nothing on the outside of the wall?
This isnt a fix to the problem, however I began exploring "Dosbox X" today. This is a modern fork of dosbox which has tons of extra features, specifically "Save States"
I was skeptical save states would work with icr2, but at first glance it actually seems to! I bound a button to the save state (there is an option to shut off the dialog box) and can save state while driving. I can then load that state back and resume exactly where I was. So it is plausible to save mid-race and be able to resume if there is a game crash.
It seems like you need to load ICR2 again first before you load the state or else audio (or maybe other things) wont work.
I want to try more testing to see if it will actually properly save the results of a race and everything if using a 'saved' race state, but it would give a lot of confidence in doing a longer race if every stint I can save it.
Let me know if anyone else test and has any findings!
01-01-2025, 04:13 PM (This post was last modified: 01-01-2025, 04:15 PM by samsepi0l.)
(01-01-2025, 08:10 AM)jxeboy Wrote: ......I began exploring "Dosbox X" today. This is a modern fork of dosbox which has tons of extra features, specifically "Save States"
I tried dosbox-x but only really with gp2. The thing that turned me off is it ran too slow with gp2.
I won't get into details, but gp2 has "stretchable time" per track which is controlled with something that we call magic-data. (Think of it like tinkering with a tracks track.txt.) This was not the problem though. I was not the only person who found this though: https://github.com/joncampbell123/dosbox-x/issues/3211
(I made a comment on the site and that was about a year ago- no update on it)
I haven't given icr2 a good test in dosbox, but how are your frame rates? Is it as fast as ECE?
If we can get dosbox-x working well with icr2, I might install 2 different emulators. Dosbox-x for icr2, and ECE for Gp2.
I did a little testing with it and performance seems on par with what I was getting in ECE. I had to do some Joystick adjustments as there is a deadzone and non-linear setting applied by default.