You are not logged in.
So I was inspired enough to try to build a Gameboy link cable to PC parallel port adapter, but unfortunately, I don't own a flash cart and so I don't really have any way of testing it.
I've read up on the PanDocs about the link cable transfer protocol. I pretty much understand it. But my question is, how does the game software itself determine if it's going to be the master or slave? I understand how it tells it, by setting the right bit at 0xFF02, but how does it determine which it will be? I need to know this, because I read somewhere the computer should always provide the clock, because if the Gameboy did, the computer might miss a bit because of an interrupt or computer lag or something. So once you go into the cable club and start talking to the lady at the desk, how does the game determine if it's going to be providing the clock, or if the other Gameboy will be?
Another side question I have relating to this is the name selection screens. Since I've learned a lot about keyboard programming, I would kinda like my first assembly project to be adding a keyboard driver to Pokemon (first generation). But unfortunately, I know next to nothing about assembly, although I do know about programming and with a list of opcodes in front of me, I might be able to figure it out. But I know nothing about using a debugger or anything, so I was wondering if someone could help get me started like with a list of offsets or anything that would deal with the name selection screens.
Yeah... hope I'm not biting off more than I can chew...
Edit: Just so you know that I can sorta do things on my own, I see the alphabet that used for the keyboard screen at 0x679E. So I'm guessing around there would be where I would need to start...
Last edited by stag019 (2011-10-14 23:47:45)
You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.
The Link Port does not have a protocol, which is exactly why using it is so hard!
I pretty much understand it. But my question is, how does the game software itself determine if it's going to be the master or slave?
The Link Port not having a protocol is precisely why you're asking this question. The game's I have seen (and that includes Pokémon only to a lesser extent) will usually check if there is activity on the link port, meaning if there is an external clock and data is sent or not. They will then try to synchronize each with each other and pretty much determine the roles of master and slave randomly.
For instance, below is the (unfinished) documented SIO code from the CGB Devil Children games:
The synchronization is done in two steps, after which the game tries to keep synch. Basically, the games expect different incoming data depending on their own clock. Therefore, if both link partners happen to have chosen the same clock, they will clash. This will lead both partners to wait for a random amount of clock cycles before trying to do another serial transfer. (So while technically, a livelock would be possible, it's very improbable to negligible.)
When in synch, the game's code will read IO Mode and determine whether it needs to actively send a package or just provide the data in a specific location in RAM, iirc.
This is supposedly documented in the elusive "Game Boy Development Manual" chapters 4 and 5, see devr's FAQ. Chapter 6 of said manual deals with 2-player hazards and can be found. I have never seen any official documentation regarding 4-player hazards or synchronization tips. But pretty much you have to roll your own protocol and make it so the DMG/CGB is always using external clock once synchronization with the PC has been established. Also notice that it might be feasible to use some error correction codes and techniques instead of some enumeration values (which were used above) so mitigate the possibility of undetected package loss.
I know next to nothing about assembly, although I do know about programming and with a list of opcodes in front of me, I might be able to figure it out. But I know nothing about using a debugger or anything
You might not know that learning ASM and learning how to use a debugger is really much easier than it seem to someone who has yet to try it out. You should use the search function in this site, so you can find some examples of both assembly, that will get you into it, and of debugger usages. Also, considering that you already know some programming language, have you really never debugged a program before? It's all about putting breakpoints on RAM access (read, write or execute), breakpoints on code run and adding conditions to them.
Just mess around with the debugger, like in many things practice is the best way to get good at something.