#3677 - arundel - Tue Mar 04, 2003 11:01 pm
Hi everybody. This is my first post, so forgive me for doing some mistakes. I'm working for quite
some time now on decrypting the send routine Martin used in his xboo.com. I was so lucky to be his
beta tester for the newer versions which support CPUs >100 MHz (credits should be in the readme).
Since I remember even Jeff saying that he doesn't fully understand what Martin actually did I
thought it would be interesting to find out what Martin actually has come up with. I've already
wrote a little 16 bit ASSEMBLER program (uses some 32 bit code) to send and receive a few pieces of
data between PC and AGB, but it's just doing the first one or two data exchange routines. After
that I don't know how the protocol continues.
1) This is from the documentation of the protocol Martin uses, taken from his Gameboy Advance
Technical Info (gbatek.htm).
2) This is a small diagram of the XBOO cable. Thx to the xboo.txt and Randall's AoA 16 BIT EDITION:
I think we can leave out the /GND connection, because it doesn't transfer any data. And we can
leave out the /SELECT PIN, because that is used for the so called Burst Speed Transfer which isn't
mandatory. Martin's xboo.txt says that this cable can be left out without any problems, but with
loosing the Burst Boot ability.
SO LET'S START:
As you can read in the transfer protocol we need to transfer the integer value '6200' to the AGB
until we receive '0000' and not 'FFFF' any longer. Now we have got 4 problems:
1. What kind of value is the AGB expecting? 8, 16 or 32bit?
2. To which LPT PIN do we have to send the data? Either /AUTOLF or /STROBE!
3. Since we know that our little ARM CPU works a lot slower than the average PC CPU we need to
introduce some kind of delay (Martin used waitstates. I think he changed the bits of the data lines
(PIN 2-9) which should take a few ms. But maybe he also used CPU waitstates. Maybe recursion, RDTSC
or interrupts. Who knows.)
4. Does the AGB BIOS routine for transferring data require start and stop bits?
SOLUTIONS:
1. To know which data type the AGB is expecting we need to know which SIO Mode it is using. The
following modes are possible: Normal Mode, Multi-Player Mode, UART Mode, BUS Mode and
General-Purpose Mode. Since the registers which the AGB reads out to find out which mode it should
use (124h, 128h, ...) are all set to 0 I believe the AGB uses Normal Mode. the second reason for
using Normal Mode is the fact that Martin describes in his gbatek.htm that the cable protocol for
Normal Mode uses the PINS /SC, /SI and /SO. All the other Modes additional use the SD PIN. I
believe Martin uses Normal Mode for standard transfer and Multi-Player Mode for Burst Boot
communication, where he has an extra PIN for data transfer (/SD).
2. If we stick to the idea that all the I/O registers are set to 0 it should be obvious that the
transfer type the AGB is expecting is 8 bit, because the register 128h (BIT 12) is set to 0
(0=8bit, 1=32bit).
3. I haven't found an appropriate solution for this problem yet!
4. If all the stuff I wrote above is appropriate then we shouldn't need any start or stop bits.
Martin describes the Cable Protocol for Normal Mode like this: "SC=Clock, SO=Data being send to PC,
SI=Data being received from PC. On SC=low AGB and PC send data to /SO (AGB) and /ACK (PC). On
SC=high AGB and PC receive data from /SI and /AUTOLF. After transfer SC is being kept high." I hope
I got it right, because the on the standard transfer AGB to AGB cable the cables for SI and SO are
switched, so that SO of AGB1 is connected to SI of AGB2 and the other way round also. Quite logical
actually. My output is your input and your output is my input!
I'VE COME THIS FAR:
The little program I've wrote so far outputs '6200' currently in 32bit mode, so I have to change
that. However then it gets back the '0000' from the AGB which means that the Multiboot BIOS routine
sets the AGB to be slave and let's it enter Multiboot Mode. Then however I have a problem with
receiving the 720x, which should be 7201, because the AGB is the only slave to our master (PC). The
problem is that I'm trying to read out the /ACK PIN in order to receive the value. However I don't
know the timing. Since we are working in 8 bit mode I hope to receive the following value: 1110010
(72h). I believe the AGB is using MSB first here. I'm putting this 8 bit value into some register
(al,ah,al,bh, whatever) and comparing it to some data I've defined. But if I'm reading too fast
from the LPT PINS I might get: 11111000 or if I'm reading too slow I might get: 11000000. Of course
I could calculate the exact processing speed at which the AGB and my PC output data, but I don't
know the time the AGB BIOS routine needs to do it's stuff.
Plus I'm not that much of a hardware guru.
If anybody is interested in doing some researches on this matter or already knows a solution for my
problem please drop a note. If everything I wrote is complete crap or if the entire protocol is
already been made public please forgive me and don't flame my pour soul. And please forgive me all
the spelling errors and technical mistakes.
Thx in advance.
P.S.: If anybody wants to have a look at the piece of code I already wrote (~500 lines of asm
code) please drop a note or PM me.
Have phun. :)
some time now on decrypting the send routine Martin used in his xboo.com. I was so lucky to be his
beta tester for the newer versions which support CPUs >100 MHz (credits should be in the readme).
Since I remember even Jeff saying that he doesn't fully understand what Martin actually did I
thought it would be interesting to find out what Martin actually has come up with. I've already
wrote a little 16 bit ASSEMBLER program (uses some 32 bit code) to send and receive a few pieces of
data between PC and AGB, but it's just doing the first one or two data exchange routines. After
that I don't know how the protocol continues.
1) This is from the documentation of the protocol Martin uses, taken from his Gameboy Advance
Technical Info (gbatek.htm).
| Code: |
| Times Send Receive Expl.
-----------------------Required Transfer Initiation in master program ... 6200 FFFF Slave not in multiplay/normal mode yet 1 6200 0000 Slave entered correct mode now 15 6200 720x Repeat 15 times, if failed: delay 1/16s and restart 1 610y 720x Recognition okay, exchange master/slave info 60h xxxx NN0x Transfer C0h bytes header data in units of 16bits 1 6200 000x Transfer of header data completed 1 620y 720x Exchange master/slave info again ... 63pp 720x Wait until all slaves reply 73cc instead 720x 1 63pp 73cc Send palette_data and receive client_data[1-3] 1 64hh 73uu Send handshake_data for final transfer completion -----------------------Below is SWI 37 MultiBoot handler in BIOS DELAY - - Wait 1/16 seconds at master side 1 llll 73rr Send length information and receive random data[1-3] LEN yyyy nnnn Transfer main data block in units of 16 or 32 bits 1 0065 nnnn Transfer of main data block completed, request CRC ... 0065 0074 Wait until all slaves reply 0075 instead 0074 1 0065 0075 All slaves ready for CRC transfer 1 0066 0075 Signalize that transfer of CRC follows 1 zzzz zzzz Exchange CRC must be same for master and slaves -----------------------Optional Handshake (NOT part of master/slave BIOS) ... .... .... Exchange whatever custom data Legend for above Protocol y client_bit, bit(s) 1-3 set if slave(s) 1-3 detected x bit 1,2,or 3 set if slave 1,2,or 3 xxxx header data, transferred in 16bit (!) units (even in 32bit normal mode) nn response value for header transfer, decreasing 60h..01h pp palette_data cc random client_data[1..3] from slave 1-3, FFh if slave not exists hh handshake_data, 11h+client_data[1]+client_data[2]+client_data[3] uu random data, not used, ignore this value Below automatically calculated by SWI 37 BIOS function (don't care about) llll download length/4-34h rr random data from each slave for encryption, FFh if slave not exists yyyy encoded data in 16bit (multiplay) or 32bit (normal mode) units nnnn response value, lower 16bit of destadr in AGB memory (00C0h and up) zzzz 16bit download CRC value, must be same for master and slaves |
2) This is a small diagram of the XBOO cable. Thx to the xboo.txt and Randall's AoA 16 BIT EDITION:
| Code: |
| NAME LPT PIN DIRECTION POLARITY(ACTIVE) AGB
----------------------------------------------------------------------------------- /ACK 10 INPUT 0 /SO (PIN 2) /AUTOLF 14 OUTPUT 0 /SI (PIN 3) /STROBE 1 OUTPUT 0 /SC (PIN 5) /GND 18-25 - - /GND (PIN 6) /SELECT 17 INPUT 0 /SD (PIN 4) |
I think we can leave out the /GND connection, because it doesn't transfer any data. And we can
leave out the /SELECT PIN, because that is used for the so called Burst Speed Transfer which isn't
mandatory. Martin's xboo.txt says that this cable can be left out without any problems, but with
loosing the Burst Boot ability.
SO LET'S START:
As you can read in the transfer protocol we need to transfer the integer value '6200' to the AGB
until we receive '0000' and not 'FFFF' any longer. Now we have got 4 problems:
1. What kind of value is the AGB expecting? 8, 16 or 32bit?
2. To which LPT PIN do we have to send the data? Either /AUTOLF or /STROBE!
3. Since we know that our little ARM CPU works a lot slower than the average PC CPU we need to
introduce some kind of delay (Martin used waitstates. I think he changed the bits of the data lines
(PIN 2-9) which should take a few ms. But maybe he also used CPU waitstates. Maybe recursion, RDTSC
or interrupts. Who knows.)
4. Does the AGB BIOS routine for transferring data require start and stop bits?
SOLUTIONS:
1. To know which data type the AGB is expecting we need to know which SIO Mode it is using. The
following modes are possible: Normal Mode, Multi-Player Mode, UART Mode, BUS Mode and
General-Purpose Mode. Since the registers which the AGB reads out to find out which mode it should
use (124h, 128h, ...) are all set to 0 I believe the AGB uses Normal Mode. the second reason for
using Normal Mode is the fact that Martin describes in his gbatek.htm that the cable protocol for
Normal Mode uses the PINS /SC, /SI and /SO. All the other Modes additional use the SD PIN. I
believe Martin uses Normal Mode for standard transfer and Multi-Player Mode for Burst Boot
communication, where he has an extra PIN for data transfer (/SD).
2. If we stick to the idea that all the I/O registers are set to 0 it should be obvious that the
transfer type the AGB is expecting is 8 bit, because the register 128h (BIT 12) is set to 0
(0=8bit, 1=32bit).
3. I haven't found an appropriate solution for this problem yet!
4. If all the stuff I wrote above is appropriate then we shouldn't need any start or stop bits.
Martin describes the Cable Protocol for Normal Mode like this: "SC=Clock, SO=Data being send to PC,
SI=Data being received from PC. On SC=low AGB and PC send data to /SO (AGB) and /ACK (PC). On
SC=high AGB and PC receive data from /SI and /AUTOLF. After transfer SC is being kept high." I hope
I got it right, because the on the standard transfer AGB to AGB cable the cables for SI and SO are
switched, so that SO of AGB1 is connected to SI of AGB2 and the other way round also. Quite logical
actually. My output is your input and your output is my input!
I'VE COME THIS FAR:
The little program I've wrote so far outputs '6200' currently in 32bit mode, so I have to change
that. However then it gets back the '0000' from the AGB which means that the Multiboot BIOS routine
sets the AGB to be slave and let's it enter Multiboot Mode. Then however I have a problem with
receiving the 720x, which should be 7201, because the AGB is the only slave to our master (PC). The
problem is that I'm trying to read out the /ACK PIN in order to receive the value. However I don't
know the timing. Since we are working in 8 bit mode I hope to receive the following value: 1110010
(72h). I believe the AGB is using MSB first here. I'm putting this 8 bit value into some register
(al,ah,al,bh, whatever) and comparing it to some data I've defined. But if I'm reading too fast
from the LPT PINS I might get: 11111000 or if I'm reading too slow I might get: 11000000. Of course
I could calculate the exact processing speed at which the AGB and my PC output data, but I don't
know the time the AGB BIOS routine needs to do it's stuff.
Plus I'm not that much of a hardware guru.
If anybody is interested in doing some researches on this matter or already knows a solution for my
problem please drop a note. If everything I wrote is complete crap or if the entire protocol is
already been made public please forgive me and don't flame my pour soul. And please forgive me all
the spelling errors and technical mistakes.
Thx in advance.
P.S.: If anybody wants to have a look at the piece of code I already wrote (~500 lines of asm
code) please drop a note or PM me.
Have phun. :)