joncampbell123 / dosbox-x

DOSBox-X fork of the DOSBox project
GNU General Public License v2.0
2.78k stars 381 forks source link

What exactly is the Game Link output? #4038

Open BridgeHeadland opened 1 year ago

BridgeHeadland commented 1 year ago

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

aybe commented 1 year ago

https://github.com/joncampbell123/dosbox-x/blob/master/src/gamelink/README.md

joncampbell123 commented 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.

aybe commented 1 year ago

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.

jwalt commented 1 year ago

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.