I'm trying to better understand why ICR2 sometimes (rarely and somewhat randomly) crashes back to the dosbox CLI. I am part of a small community of folks that dedicate a lot of their time to this game. (personally I spend months building tracks and content for it).
I am motivated to learn assembly and try and figure this out- but I am having problems getting started. I was considering maybe reaching out to someone who knows more that could maybe teach me, or even sortof be "hired" to do this. Mostly I am interested in becoming self sufficient.
Thank you for your reply. I am well aware of the tutorial as this is one of the channels I religiously watch this game being played on. I have no problems getting the game running, however we randomly experience these kinds of crashes from time to time and I believe it is a bug that is present in the original game that seems to show up more often in home-made content. I am trying to learn more about how the game works by studying assembly code and doing some reverse engineering but I'm sure there are more people qualified than me.
A divide by zero can happen for a number of reasons. A system that is "too fast" is a common cause, so rather than cycles=auto (the default) or cycles=max, try a fixed number like cycles=10000 or cycles=20000 for a 1996 game. Another important thing to try is core=normal, as there is a small chance the divide error results from using the dynamic core.
A divide by zero can happen for a number of reasons. A system that is "too fast" is a common cause, so rather than cycles=auto (the default) or cycles=max, try a fixed number like cycles=10000 or cycles=20000 for a 1996 game. Another important thing to try is core=normal, as there is a small chance the divide error results from using the dynamic core.
Interesting. My dosbox config has:
1[cpu] 2# core: CPU Core used in emulation. auto will switch to dynamic if available and 3# appropriate. 4# Possible values: auto, dynamic, normal, simple. 5# cputype: CPU Type used in emulation. auto is the fastest choice. 6# Possible values: auto, 386, 386_slow, 486_slow, pentium_slow, 386_prefetch. 7# cycles: Amount of instructions DOSBox tries to emulate each millisecond. 8# Setting this value too high results in sound dropouts and lags. 9# Cycles can be set in 3 ways: 10# 'auto' tries to guess what a game needs. 11# It usually works, but can fail for certain games. 12# 'fixed #number' will set a fixed amount of cycles. This is what you usually 13# need if 'auto' fails (Example: fixed 4000). 14# 'max' will allocate as much cycles as your computer is able to 15# handle. 16# Possible values: auto, fixed, max. 17# cycleup: Amount of cycles to decrease/increase with keycombos.(CTRL-F11/CTRL-F12) 18# cycledown: Setting it lower than 100 will be a percentage. 19 20core = auto 21cputype = auto 22cycles = auto 23#cycles = fixed 80000 24cycleup = 10 25cycledown = 20
I don't experience the crash as much as others. I built this computer in 2013 and it was fast at that time. However it seems that most of the time these crashes are reported on home-brew tracks that were made for the game using tools that were (I believe) tools made by the original authors. One of my fellow community members is having this more often and I would love to know if the info you posted might help. The problem for him is that he streams this game live, and for example the crash happened to him today after 2 hours of working on a race at a track I spent 6 months building from scratch. I was hoping that if I could learn assembly it would help me understand why this is happening. It's been a while (25-30 years) but I believe we had this same crash (although infrequent) back when I was a kid with a real dos machine as well.
The error message includes the CS:IP, so you can look at the divide instruction at that address in the DOSBox debugger and trace back to try to understand how the exception happens. However, it could be a frustrating process for someone just starting to learn assembly.
BTW, I forgot to mention trying to run the game with the DOS32A extender instead of the included DOS4GW extender -- it may not work at all, or it may actually solve the problem.
The error message includes the CS:IP, so you can look at the divide instruction at that address in the DOSBox debugger and trace back to try to understand how the exception happens. However, it could be a frustrating process for someone just starting to learn assembly.
BTW, I forgot to mention trying to run the game with the DOS32A extender instead of the included DOS4GW extender -- it may not work at all, or it may actually solve the problem.
I will keep this in mind. I also want to learn assembly so that I can make changes to the way the game works. I have been reading about it and I need to educate myself.
