I tried using OpenAI to help out with the disassembly. Some stuff works brilliantly. Others things not so well. It'll often contradict its earlier answers. Also there're some problems with the models. The one I was using 3 days ago worked better than what I have now. The original model is no longer available or something
..
I've found part of the MIP map loader. The place where it calculates the size of the previous MIP map is here:
000766ed 0f af c1 IMUL param_1 ,param_3 (this is effectively imul eax, ecx)
The whole block:
000766e4 89 43 0c MOV dword ptr [EBX + 0xc ],param_1
000766e7 8b 4b 30 MOV param_3 ,dword ptr [EBX + 0x30 ] // horizontal resolution * 2
000766ea 8b 43 38 MOV param_1 ,dword ptr [EBX + 0x38 ] // vertical resolution
000766ed 0f af c1 IMUL param_1 ,param_3
000766f0 83 c0 03 ADD param_1 ,0x3
000766f3 c1 e8 02 SHR param_1 ,0x2
000766f6 89 43 2c MOV dword ptr [EBX + 0x2c ],param_1
000766f9 8b 6b 0c MOV EBP ,dword ptr [EBX + 0xc ]
000766fc 8b 43 14 MOV param_1 ,dword ptr [EBX + 0x14 ]
000766ff 0f af c5 IMUL param_1 ,EBP
In fact this block is used for all textures and not just MIP maps. Need to do more digging, but that's a job for tomorrow.
With the Rendition edition I get:
2025/8/30|10:53:33.985 Read from file V : DENVER\ 110_16th.MIP: 8192 bytes (2000)
2025/8/30|10:53:33.999 Read from file V: DENVER\ 110_16th.MIP: 8192 bytes (2000)
2025/8/30|10:53:34.126 Read from file V: DENVER\ 110_16th.MIP: 8192 bytes (2000)
2025/8/30|10:53:34.138 Read from file V: DENVER\ 110_16th.MIP: 8192 bytes (2000)
2025/8/30|10:53:34.150 Read from file V: DENVER\ 110_16th.MIP: 7006 bytes (1B5E)
which suggests it gets confused about the file size. This mip map has an odd number of vertical pels (128x147). I wonder if this is the problem. I'm going to try to mip reduce this one file to see if it works. All the other files are read correctly, down to the last byte.
[edit] Nope, back to the disassembly.
Do you think the track limit of the game is a hard limit set within the EXE somewhere, that we could change to allow for more tracks in a single install at a time? Sorry in advance if this has been discussed before.
(08-31-2025, 05:22 PM)Tjerk Wrote: [ -> ]Do you think the track limit of the game is a hard limit set within the EXE somewhere, that we could change to allow for more tracks in a single install at a time? Sorry in advance if this has been discussed before.
The track limit is hard coded. There is a build in this thread with the limit partially removed at startup. The game starts up with upto 63 tracks, but navigating beyond the 30th track crashes the game because the memory allocation (to store track info) hasn't been increased. That will be fixed shortly. I'm working on icr2's memory limit restrictions for custom tracks at the moment. Will move onto the track limit and aspect ratio stuff once I'm done with this.
Ghidras less useful for this. I have to make the game dump everything the dosbox virtual cpu is doing (massive massive files) and try and work out what went wrong. Thanks to chatgpt I've isolated some of the memory allocation routines. Still haven't hit the actual error yet.
(08-31-2025, 08:37 PM)sharangad Wrote: [ -> ]Ghidras less useful for this. I have to make the game dump everything the dosbox virtual cpu is doing (massive massive files) and try and work out what went wrong. Thanks to chatgpt I've isolated some of the memory allocation routines. Still haven't hit the actual error yet.
Have you seen Ghidra LX loader?
https://github.com/yetmorecode/ghidra-lx-loader
(09-01-2025, 02:03 AM)samsepi0l Wrote: [ -> ] (08-31-2025, 08:37 PM)sharangad Wrote: [ -> ]Ghidras less useful for this. I have to make the game dump everything the dosbox virtual cpu is doing (massive massive files) and try and work out what went wrong. Thanks to chatgpt I've isolated some of the memory allocation routines. Still haven't hit the actual error yet.
Have you seen Ghidra LX loader? https://github.com/yetmorecode/ghidra-lx-loader
I'm using that with Ghidra, my large file editor and OpenAI. I've tracked down the source of the memory allocation error. There's a hash map based heap which fails to return a memory block when loading full fat Denver. I'm trying to increase the heap size without success. Ghidra can't see some parts of memory because they're in dynamically allocated segments. The execution trace will show all that with physical dosbox-rendition addresses.
The hash map for the heap lives at memory address 0x002939D8. This is a literal.
This indexes a pool of size 0x76C0 bytes = 30,400 bytes in total, divided into 7,600 4-byte slots which lives at protected mode address 0x0000EC94. This isn't the actual texture heap. It looks like each mip map level takes up an entry and there are only 800 in total, which suggest a texture object limit of 800. This isn't constrained by the amount of texture RAM, but rather the number of individual mip maps. 800 comes from (0x76C0/0x26 (size of each entry)). When loading a track this includes every single car in the carset and everything in the .TRK/.3DO file itself. Other elements might use up entries as well, I'm not sure yet. Increasing this *should* maybe fix things.
I think someone had a theory (@checkpoint10?) that there was a limit to the number of total mipmaps.
You have to understand Denver was my first real big track project. There are lots of things I would probably do different and better if I did it again. Before Denver I had only done Tamiami and Sanair which were only partial builds of much easier tracks and Denver was a complete build of a much bigger track. I'm sure there are things I did in my ignorance that are not optimal for your tool. If I redid all of the things I did "wrong" back then I would never have the time for new projects though right? Since then I have made so many other tracks and I think each has improved after this.
(09-01-2025, 04:11 AM)samsepi0l Wrote: [ -> ]You have to understand Denver was my first real big track project. There are lots of things I would probably do different and better if I did it again. Before Denver I had only done Tamiami and Sanair which were only partial builds of much easier tracks and Denver was a complete build of a much bigger track. I'm sure there are things I did in my ignorance that are not optimal for your tool. If I redid all of the things I did "wrong" back then I would never have the time for new projects though right? Since then I have made so many other tracks and I think each has improved after this.
It's not a failing of yours or the tracks. It works fine in software rendered cart.exe and windy. I'm using it because I know it won't load without mipmap reduction on the Rendition edition. It *should* just work.
ENVER\ 110_16th.MIP