Open BridgeHeadland opened 1 year ago
This was added by someone else's pull requests who has an interest in this code.
I do have a question though: Does the Game Link protocol allow extensions?
Perhaps DOSBox-X could announce over the Game Link protocol when DOS starts, what DOS kernel allocations are where, where the first link of the MCB allocation chain is, notifications when a program is run, notifications when the DOS program allocates and frees memory via INT 21h, etc. Information that would allow the other end to track the desired code and data dynamically instead of assuming memory locations.
You have to understand that unlike NES and SNES ROMs, memory allocation and layout are not fixed in any way.
Let's ping the author of this feature!
@jwalt
This was added by someone else's pull requests who has an interest in this code.
I do have a question though: Does the Game Link protocol allow extensions?
Perhaps DOSBox-X could announce over the Game Link protocol when DOS starts, what DOS kernel allocations are where, where the first link of the MCB allocation chain is, notifications when a program is run, notifications when the DOS program allocates and frees memory via INT 21h, etc. Information that would allow the other end to track the desired code and data dynamically instead of assuming memory locations.
You have to understand that unlike NES and SNES ROMs, memory allocation and layout are not fixed in any way.
Game Link is a pretty low level protocol. It has three parts: The basic functionality allows reading out fixed addresses provided by the client, nothing more. Then there is optional exchange of the frame buffer/input control so that the game can be played inside a Game Link client window (thats what the output setting enables). Finally there is a shared memory segment that contains the entire live DOS memory for direct access. It seems it is rarely used, but it is there.
Regarding extensions: I think that question is moot. It would be easy to define magic memory addresses using the original protocol, something in a range that no DOS computer ever used, e.g. 0xd05b0000-0xd05bffff, and return various DOSBox values/events for those. But: I tried exactly that, and it didn't make anything noticeably easier or more stable, because there are so many variables influencing memory layout. For some programs it would help, but those also work perfectly with the reference memory layout from the README.
To expand on the final point: DOS games are sensitive to any change in memory layout -- so far so expected. Unfortunately, some games (e.g. Ultima 1) even change memory layout with the length of the environment variables, and there is no way for DOSBox to see this, this happens inside the executable. Later DOS games use dynamic memory allocation extensively, effectively putting "interesting" values at different places each time they run. Clients could access the shared memory and scan it to find a suitably unique anchor value, relative to which desired addresses are. This a technique that The All-Seeing Eye does for the Eye of the Beholder series. Unsurprisingly, it is not perfect either.
So no amount of DOS information will solve the memory address problem in general. The best I came up with is to mimic the reference implementation as good as possible so that existing game profiles continue working. There is no single solid solution.
Question
Game Link isn't in the config files as a output value, and I can't get it to work either. I don't know if it doesn't work for me because of my usual, specific configuration, or if it's an initialized value that doesn't work yet. Game Link as an output value appeared only now in current developer builds under the menu bar, at least in 64-bit Visual Studio builds (for Vista+/ARM).
Have you checked that no similar question(s) exist?
Code of Conduct & Contributing Guidelines