You are not logged in.
Before I begin, I just wanna mention that the Help/Question forum description is rather vague. It doesn't specify if it's for "Pokemon Gen I and II only", "Pokemon only", "Gameboy only", "Pokemon and forum questions", or "other".
But anyways, hopefully, if someone decides to do this for me, it'll be a quick project.
I've built one of these, and it works great both with a test ROM and with LSDj. I've been working on another project that links up to BGB via the TCP/IP link protocol and it does work mostly correctly. However, I want to test a bit more with the actual hardware to make certain the program correctly emulates what happens on the hardware.
So here's where my request comes in. I'd like someone who's actually good at assembly to write a quick test ROM that'll read what byte is sent into the link cable (in slave mode: the keyboard is always the master) and display the hexadecimal value on the screen. It needs to display each subsequent byte next to the last ones instead of overwriting it, since a keyboard can send more than one byte at a time. Once it gets to the end of the screen, it should move all data on the screen up one line and start at the new bottom line. Also according to the Pan Docs, "When using external clock then the transfer will not complete until the last bit is received. In case that the second gameboy isn't supplying a clock signal, if it gets turned off, or if there is no second gameboy connected at all) then transfer will never complete. For this reason the transfer procedure should use a timeout counter, and abort the communication if no response has been received during the timeout interval." Because a keyboard sends data in 11 bit chunks (start/stop/parity bits + 8 data bits), the last few bits won't be received without a timeout or another keystroke sending more bits (which would also cause the next byte to start from the middle of the stream instead of the start). So basically I'd need some sort of timeout. I'd also like to see then, if a timeout occurs, if the bits that transferred are still able to be read (and if so, display that byte on the screen).
I've tried doing this myself a few times, but I'm just not good enough and don't understand low-level programming enough to do it right.
Last edited by stag019 (2015-02-06 10:29:46)
You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.