Xplorer/Xploder Communication Protocoll (Upload File)

BIOS, Controllers, Memory Cards, Serial I/O, Parallel I/O, etc.
Post Reply
patrickvogt
Interested PSXDEV User
Interested PSXDEV User
Posts: 7
Joined: May 03, 2013
Location: Germany
Contact:

Xplorer/Xploder Communication Protocoll (Upload File)

Post by patrickvogt » August 25th, 2014, 8:56 am

Hi,

I recently build a litte cable and tool to sniff on the communication between my old Win98-PC and the Xploder. The result was basically what is on Martin Korths site (Link: http://problemkaputt.de/psx-spx.htm#che ... sxplorerio).

I tried to implement the protocoll (on Linux using the basic 'outb' and 'inb' system calls (which needs root access), see upload.zip) by using the following 'protocoll/handshake' to determine if the byte was sent successfully (again from Martin Korths site):
== To send a byte to psx ==
out data to psx
set printer select line high
wait for ack from psx to go high
set printer select line low
wait for ack from psx to go low
Unfortunately, this doesn't work for me. When I try to use X-Killer after my program was executed the X-Killer will always get a timeout. So I guess something is working, but it is not fully working.

Did anyone implement this protocoll to send a byte / upload a bin file into the memory via the xplorer/xploder? Do I need to set some special options of the port, e.g. synchronous mode?

Thanks in advance
You do not have the required permissions to view the files attached to this post.

patrickvogt
Interested PSXDEV User
Interested PSXDEV User
Posts: 7
Joined: May 03, 2013
Location: Germany
Contact:

Post by patrickvogt » August 28th, 2014, 6:10 am

Hi,

so I switched to something easier: Freeze and Unfreeze of the PSX. The code in the attachment contains a Linux program (needs to be executed as root) to Freeze and Unfreeze the PSX while playing a game using the Xploder.

My Xploder (Basic) has the V2 Rom and the bytes for freeze are 0x57, 0x4C and for unfreeze you do a 0x57, 0x52.

So the protocoll/handshake to send a byte definitely works.

I think the problem with the file upload is the length field. I guess it should be longer than the 3 bytes (perhaps 4 bytes, although you only need 3 bytes to specify a length within 0...2MB), so in my case (see upload.zip above) the xploder expected probably 0x006800XX bytes (where XX is represents the first real data byte) instead of the wanted 0x006800 bytes. I have to investigate this further. X-Killer and Xlink will timeout because they do a negotiation/initialization with the Xploder. So if the xploder is still in the "want to receive data bytes" mode it doesn't want to do any negotation.
You do not have the required permissions to view the files attached to this post.

User avatar
sickle
Verified
C Programming Expert
C Programming Expert
Posts: 257
Joined: Jul 17, 2013
I am a: Chocolate-fueled pug fetish robot.
Location: Scotland

Post by sickle » January 25th, 2016, 7:41 am

Ahoyhoy, sorry for the late reply.
You're probably fumbling with the weird Ack patterns Xplorer uses which can be a bit of a pain in the tits.

Maybe try looking in the CatFlap source code?
http://www.psxdev.net/forum/viewtopic.php?f=69&t=367

I used that source to build the following test code into an arduino using the same XpAck functions:

doByte(byte inByte){
outByte = inByte;
goHi()
XpAck1()
goLow()
XpAck2()
}

void backAck(){

int in1,in2,in3;
in1 = XpAck1();
goHigh();

in2 = XpAck1_N();
goLow();

in3 = XpAck1();
goHigh();

XpAck1_N();
goLow();

//XpAck2_N("lh5");

returnByte=( ((in1&0x30)<<2) | (((~in2)&0x80)>>2) | ((in2&0x30)>>1) | (((~in3)&0x80)>>5) | ((in3&0x30)>>4) );
}

//Reset the pins
setTheBits(0);

//Begin Upload
doByte( 0x57 );
doByte( 0x53 );

//addr 80024444, where we'll upload to
doByte( 0x80 );
doByte( 0x02 );
doByte( 0x44 );
doByte( 0x44 );

//length
doByte( 0x00 );
doByte( 0x00 );
doByte( 0x00 );
doByte( 0x14 );

//zero out the t0 register
doByte(0x26);//byte 1 xor t0,t0
doByte(0x40);
doByte(0x08);
doByte(0x01);

//Loads BFC0 into the upper part of t0 (BFC0****)
doByte(0xC0); //lui t0,$BFC0
doByte(0xBF);
doByte(0x08);
doByte(0x3C);

//Adds 0 to t0 (lower half = ****0000)
doByte(0x00); //addiu t0,0
doByte(0x00);
doByte(0x08);
doByte(0x25);

//jumps to the register t0's address (BFC00000) which resets the machine
doByte(0x08); //jr t0
doByte(0x00);
doByte(0x00);
doByte(0x01);

//Some zero bytes required after the jump
doByte(0x00); //nop
doByte(0x00);
doByte(0x00);
doByte(0x00);

doByte( 0x02 );//02
backAck();

doByte( 0x68 ); //68
backAck();

backAck();
backAck();


//Then jump to our new bytecode
doByte( 0x57 );
doByte( 0x0F );

//The address we specified before
doByte( 0x80 );
doByte( 0x02 );
doByte( 0x44 );
doByte( 0x44 );

User avatar
Greg
Verified
Serious PSXDEV User
Serious PSXDEV User
Posts: 101
Joined: Sep 09, 2013
PlayStation Model: SCPH-7501
Location: Port-au-Prince, HAITI

Post by Greg » January 25th, 2016, 1:20 pm

sicklebrick wrote: ...
Maybe try looking in the CatFlap source code?
http://www.psxdev.net/forum/viewtopic.php?f=69&t=367
...
]
Or CatFlap for linux ;)
http://www.psxdev.net/forum/viewtopic.php?f=60&t=737
1 x SCPH-7501, 2 x SCPH-7001, 2 x SCPH-5501
1 x Pro Action Replay with "Dual Rom Mod", ROM 1: Caetla, ROM 2: UNIROM
1 x Xplorer V2 with Caetla
1 x GameShark V2.1
1 x GameShark Pro V3.0
1 x CommLinkUSB
1 x XLinkUSB

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » July 7th, 2016, 1:41 am

I am just starting to experiment with xplorer carts on real hardware, and want look closer at the parallel port stuff, too. I've downloaded the CatFlap source code... but somehow didn't find the transfer functions in it... it should somewhere use those 57h,53h (upload) and 57h,0Fh (jump) values, but where? Can somebody point me on the file/function that's doing that stuff?

Well, that's just a getting-started problem. The things that I am actually looking for are:
- How is the upload checksum calculated?
- What other functions are there? There should be also a download function... and probably lots of other functions?
- How is EXE uploading implemented? Just as upload+jump? Or is there some extra function for that purpose (ie. something that does also initialize stack pointer and stuff as when booting an EXE from CDROM)?

Oh, and is there any other source code for the xplorer parallel port stuff? Or documention for the xplorer's parallel port protocol that does cover above questions?

I'm planning to add some basic "Upload EXE via Xplorer" function in next no$psx update. Until I get that working, I've downloaded the patched xlink95 and xkiller versions, so I should have some software for testing the upload stuff... but they are both windows gui programs, and they are looking more colorful than comfortable to me. Are there some commandline based upload tools somewhere? Like xlink or xkiller DOS versions, or catflap binary version (I can't compile the source code myself)? And/or other utilities for xplorer carts that I am not aware of yet. A download page with all official & inofficial xplorer utilities would be nice!

User avatar
Shadow
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » July 7th, 2016, 3:54 am

Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » July 7th, 2016, 7:06 am

Thanks, but that PSEXE.ASM source file looks more like Comm-Link stuff for PAR (with port 300h,310h,320h,330h).
I can't see any Parallel Port code for Xplorer in it (with port 378h,278h,3BCh, and with those 57h,53h values).

User avatar
Shadow
Verified
Admin / PSXDEV
Admin / PSXDEV
Posts: 2670
Joined: Dec 31, 2012
PlayStation Model: H2000/5502
Discord: Shadow^PSXDEV

Post by Shadow » July 7th, 2016, 7:28 am

Okay. I'll send you a highly confidential file. However, before I do so, please respond to my emails regarding the K1 register, CD-ROM triple buffering system and the PSX kernel since I have been trying to contact you for several months, and have even made a generous PayPal donation to you in the past. I would mostly appreciate a Skype chat with you directly (text), a Telegram chat (text), a chat via IRC (text also) or any other instant messaging/text chatting program you would like to use, since it's easier than emailing back and forth. Please send me a PM with your information. Thanks NO$CASH.
Development Console: SCPH-5502 with 8MB RAM, MM3 Modchip, PAL 60 Colour Modification (for NTSC), PSIO Switch Board, DB-9 breakout headers for both RGB and Serial output and an Xplorer with CAETLA 0.34.

PlayStation Development PC: Windows 98 SE, Pentium 3 at 400MHz, 128MB SDRAM, DTL-H2000, DTL-H2010, DTL-H201A, DTL-S2020 (with 4GB SCSI-2 HDD), 21" Sony G420, CD-R burner, 3.25" and 5.25" Floppy Diskette Drives, ZIP 100 Diskette Drive and an IBM Model M keyboard.

User avatar
Greg
Verified
Serious PSXDEV User
Serious PSXDEV User
Posts: 101
Joined: Sep 09, 2013
PlayStation Model: SCPH-7501
Location: Port-au-Prince, HAITI

Post by Greg » July 7th, 2016, 1:18 pm

CatFlap and PSEXE.ASM use the Caetla protocol and commands, that i'm not sure, but may be different from the native Xplorer protocol and commands, here are Caetla's commands: http://www.psxdev.net/forum/viewtopic.p ... etla#p6849 of course you need to have caetla flashed on the xplorer cartridge.
1 x SCPH-7501, 2 x SCPH-7001, 2 x SCPH-5501
1 x Pro Action Replay with "Dual Rom Mod", ROM 1: Caetla, ROM 2: UNIROM
1 x Xplorer V2 with Caetla
1 x GameShark V2.1
1 x GameShark Pro V3.0
1 x CommLinkUSB
1 x XLinkUSB

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » July 10th, 2016, 6:40 am

Ah, okay, Catflap supports the Xplorer hardware - but only if one has (previously) installed Caetla instead of the original Xplorer firmware on it. And Shadow's highly confidental source code file turned out be something for Datel carts, unrelated to the Xplorer.

So, I've reverse-engineered the Xplorer protocol myself by disassembling v1.091/german (oldest known xplorer version) and v4.52/english (newest known version, apart from some slightly newer localizations for japan/spain).

Code: Select all

  GetByteByAddr32    Tx(57h,02h,Addr32), Rx(Data8)
  SetCop0Breakpoint  Tx(57h,08h,Addr32,Mask32,Ctrl32)
  NEW: RawExecute    Tx(57h,0Fh,Addr32, Call(Addr)
  NEW: FillVram      Tx(57h,12h,Xloc32,Yloc32,Xsiz32,Ysiz32,FillValue32)
  NEW: GetVram       Tx(57h,13h,Xloc32,Yloc32), Rx(Data[800h])
  NEW: GetSetIrqMask Tx(57h,14h), Rx(OldIrqMask16), Tx(NewIrqMask16)
  NEW: SetVram       Tx(57h,15h,Xloc8,Yloc8,Data[800h])   ;with X/Y'loc div32
  AddCheatCode       Tx(57h,41h,Addr32,Data16), Rx(Index8)
  DeleteCheatCode    Tx(57h,44h,Index8)
  GetMem             Tx(57h,47h,Addr32,Len32), Rx(Data[Len]), TxRxChksum
  Lock/Freeze        Tx(57h,4Ch)
  Release/Unfreeze   Tx(57h,52h)
  SetMem             Tx(57h,53h,Addr32,Len32,Data[Len]), TxRxChksum
  TurboGetMem        Tx(57h,54h,Addr32,Len32), RxFast(Data[Len]), TxRxChksum
  Dummy              Tx(57h,57h), Rx(47h)
  SetMemAndExecute   Tx(57h,58h,Addr32,Len32,Data[Len]), TxRxChksum, Call(Addr)
  GetByteByAddr24    Tx(57h,67h,Addr24), Rx(Data8)
The five "NEW" commands exist in v4.52, but not in v1.091. I don't know in which exact version they have been invented, but they aren't too useful, and using them would be just stupid because it would smash backwards-compatibility with v1.091.

All 16bit/24bit/32bit parameters are transferred MSB first.

The "Rx" and "Tx" functions seem to work just as described in the "xplorer.pdf" file (in the "xplorer.zip" file at http://www.murraymoffatt.com/playstation-xplorer.html ). NB. that .pdf does also include a schematic of the cartridge (though missing stuff like SRAM), and (buggy) descriptions for "upload" and "jump" functions; the "upload" (SetMem) function is claimed to use 24bit length, with incorrect checksum description, and the "jump" (RawExecute) function is described more or less okay - but isn't supported on older Xplorers, so it would be ways better to use SetMemAndExecuted (which should also work with Length=0 in case of needing a raw execution call without upload).

The "TxRxChksum" part (for SetMem/GetMem) works as so:

Code: Select all

  Tx(chkMsb), Rx(chkMsb), Tx(chkLsb), Rx(chkLsb), Rx("OK" or "CF" or "BG")
The 16bit checksum is all bytes in Data[Len] added together. The two final response bytes should be "OK"=Okay, or, if the transmitted chksum didn't match, either "CF"=CheckFail (for SetMem/SetMemAndExecute) or "BG"=BuggedCheck (for the two GetMem/TurboGetmem functions).

The "RxFast" function (for TurboGetMem) works a bit different as normal "Rx", it seems to rely on parallel port /ACK signal to trigger the PC's parallel port IRQ flag (which can be polled, without literally needing to execute the IRQ as interrupt).

The only really useful function is "SetMemAndExecute", it's very slow, but at least it can be used to upload some small binary to take over the MIPS cpu, and then one could implement some better/fast transfer mechanism and do whatever one wants to do.
One nasty issue is that "SetMemAndExecute" doesn't flush the code-cache before calling the uploaded code. Only way around that problem seems to be to try to upload the code to some memory location that is assumed to be not currently cached, and then to flush the cache as soon as possible from within the uploaded program code.

patrickvogt
Interested PSXDEV User
Interested PSXDEV User
Posts: 7
Joined: May 03, 2013
Location: Germany
Contact:

Post by patrickvogt » July 10th, 2016, 7:57 pm

Sorry, I didn't check the thread regularly in the last months. So one of my guess was correct, it seems that the length value has to be 32bits/4bytes. Cannot remember if I ever tried that two years ago, but with the last answer by Martin, I think that this would also not work without the correct checksum handling at the end.

I have to say I am not a hardware guru but could the NEW commands be added for this X-Assist thingy which was introduced with the XPLODER/XPLORER Professional. It will be plugged into the LPT port of the XPLODER/XPLORER.

Image

It allows to find cheat codes without a PC. You just press some of the buttons (-1, +1, lower, greater) and it will analyze the memory for values which changed according to your button press (decreased by 1, increased by 1, decreased by some value, increased by some value). So you can find a cheat code for unlimited health or ammo with this X-Assist thingy.

The corresponding ROM would then be V2.19 PRO Xploder Professional and should contain those commands aswell.

== EDIT ==
But when I think about it: It very unlikely since this X-Assist thingy should be a more passive device and it also doesn't have anything to do with the Video RAM.

I think the later versions of the XPLODER/XPLORER could take a screenshot from the playstation while the game was executed. Maybe this was the reason for the addition.

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » July 13th, 2016, 5:00 am

Yeah, none of the commands seems to be useful for the X-Assist thing, but the command list doesn't contain any further commands. Oh, wait, the command list can be found by searching for the "sub r3,r2,2h / setb r2,r3,66h" opcode pair that checks for the command number to be in range the 02h..67h, and, there appear to be two such command lists: One for code relocated to RAM at 001A0000h and up, the other one used for code in EEPROM at 1F00000h and up.
So far I've disassembled only the EEPROM command list. The RAM command list seems to contain about a dozen of extra commands, but it's obviously for the Xplorer GUI, since it can't possibly coexist with games which may use the RAM at 001A0000h for their own purposes; so the RAM commands can't be used for X-Assist. Maybe there's a third command list elsewhere for use with X-Assist. Or theoretically, the X-Assist could upload it's own MIPS functions to the PSX, but I would doubt so.

Oh, and the Xkiller software includes a "Reset" function which I haven't yet figured out how it works. It's no real hardware reset (it doesn't work if a game disables IRQs or replaces the Kernel IRQ handler by custom code). And there's no Reset command (at least not in the EEPROM command list). I am having 2-3 ideas how it might work - but I haven't nailed it down yet.
NB. a real hardware reset would be some must-have mod when actually using the xplorer for testing homebrew code on real hardware so one could re-upload the exe at any time even if the software has crashed or disables IRQs. I think one could just wire the spare /INIT signal (on DB25 parallel port) to the /RESET signal (on PSX expansion port) via a cheap 1N4148 diode.

And, some additions to the "xplorer.pdf" file: The "send a byte to psx" function looks correct, but the "get a byte from psx" function contains lots or errors:
- the first "set printer select line high" step is nonsense - just remove that step
- the other four "set printer select line low/high" should do just the opposite (low instead high, and vice-versa)
- the fixed/dummy bits in the last 4bit group aren't actually fixed ("high on slct" is correct for r4.52, but on r1.091 it's actually "low on slct", and maybe other firmware revisions use even different settings - so better don't rely on those dummy bits to have specific values.

There are also 1-2 mistakes in the schematic, and a bunch of missing bits & signals...
- EEPROM.pin1 is NC on 256Kx8 chip (however it is wired to A18 for use with 512Kx8 chips).
- EEPROM.pin30 is A17 from GAL.pin21 (not from PSX.A17), accordingly GAL.pin21 is EEPROM.A17 (not A14).
- Boards with solder pads for TWO EEPROMs are leaving A18 not connected on the 2nd EEPROM (but do connect A18 to the first EEPROM, so one could either use one 512K chip or two 256K chips).
- DB25.pin15./ERR is VCC via 0.47ohm (installed only on carts with SRAM, intended as supply for the X-ASSIST thing).
- SRAM (if any) is wired to GAL.pin17 (/CE), 74373.Q6 (A17 or CE2), 74373.Q7 (A18 or NC), other SRAM pins are wired straight to D0-D7, A0-A16, /RD, /WR.
- Existing boards seem to have 128K SRAM (if any), so SRAM A17/A18 aren't actually used (unless a board would have 512K SRAM), however, for 128K SRAMs one should switch SRAM CE2 (aka A17) high.
- VCC is 5V, derived from a 7805 voltage converter (with 7.5V used as input).

Or, more detailed, here are the whole pinouts for all logic components:

Code: Select all

Xplorer Pinout GAL20V8 (generic array logic)
  1  IN0  (DB25.pin17./SEL)
  2  IN1  (PSX.pin14.A0)
  3  IN2  (PSX.pin48.A1)
  4  IN3  (PSX.pin15.A2)
  5  IN4  (74373.pin15.Q5)
  6  IN5  (PSX.pin4./EXP)
  7  IN6  (74373.pin12.Q4)
  8  IN7  (PSX.pin26.A16) (EEPROM.pin2.A16) (SRAM.pin2.A16) (10000h)
  9  IN8  (PSX.pin60.A17)                                   (20000h)
  10 IN9  (PSX.pin27.A18) (EEPROM.pin1.A18 or NC)           (40000h)
  11 IN10 (PSX.pin30./RD)
  12 GND
  ---
  13 IN11 (GND)
  14 IN12 (/SWITCH_ON)
  15 IO   (74373.pin11.LE)
  16 IO   (PSX.pin6.D0)
  17 IO   (SRAM./CE.pin22)
  18 IO   (EEPROM2./CE.pin22) (for 2nd EEPROM chip, if any)
  19 IO   (EEPROM1./CE.pin22) (for 1st EEPROM chip)
  20 IO   (NC)                       (reportedly has wire?)
  21 IO   (EEPROM.pin30.A17)         (reportedly A14 ?)
  22 IO   (74245.pin19./E)
  23 IN13 (PSX.pin64./WR) (SRAM.29, EEPROM.31)
  24 VCC
Note: The 28pin PLCC GAL has same pinout as the 24pin chip, but with four NC 
pins inserted (at pin 1,8,15,22, whereof, there is a wire routed "through"
pin 8, so that pin isn't literally NC).

Xplorer Pinout 74373 (8bit tristate latch)
  1  /OE (GND)
  2  Q0  (DB25.pin13.SLCT)
  3  D0  (PSX)
  4  D1  (PSX)
  5  Q1  (DB25.pin12.PE)
  6  Q2  (DB25.pin11.BUSY)
  7  D2  (PSX)
  8  D3  (PSX)
  9  Q3  (DB25.pin10./ACK)
  10 GND
  11 LE  (GAL.pin15.LatchEnable)
  12 Q4  (GAL.pin7)
  13 D4  (PSX)
  14 D5  (PSX)
  15 Q5  (GAL.pin5)
  16 Q6  (SRAM.pin30.A17 or CE2)
  17 D6  (PSX)
  18 D7  (PSX)
  19 Q7  (SRAM.pin1.A18 or NC)
  20 VCC

Xplorer Pinout 74245 (8bit bus transceiver)
  1  DIR (GNDed)
  2  D7  (PSX)
  3  D6  (PSX)
  4  D5  (PSX)
  5  D4  (PSX)
  6  D3  (PSX)
  7  D2  (PSX)
  8  D1  (PSX)
  9  D0  (PSX)
  10 GND
  11 D0  (DB25.pin2)
  12 D1  (DB25.pin3)
  13 D2  (DB25.pin4)
  14 D3  (DB25.pin5)
  15 D4  (DB25.pin6)
  16 D5  (DB25.pin7)
  17 D6  (DB25.pin8)
  18 D7  (DB25.pin9)
  19 /E  (GAL.pin22)
  20 VCC

Xplorer Pinout 7805 (voltage regulator)
  1 5V   (VCC)
  2 GND  (GND)
  3 7.5V (PSX.pin18,52)

Xplorer Pinout SWITCH (on/off)
  OFF  NC
  COM  PAL.pin14 (with 10K pull-up to VCC)
  ON   GND

Xplorer Pinout DB25 (parallel/printer port)
  1  In  /STB  (NC)
  2  In  DATA0 (74245.pin11)
  3  In  DATA1 (74245.pin12)
  4  In  DATA2 (74245.pin13)
  5  In  DATA3 (74245.pin14)
  6  In  DATA4 (74245.pin15)
  7  In  DATA5 (74245.pin16)
  8  In  DATA6 (74245.pin17)
  9  In  DATA7 (74245.pin18)
  10 Out /ACK  (74373.Q3)
  11 Out BUSY  (74373.Q2)
  12 Out PE    (74373.Q1)
  13 Out SLCT  (74373.Q0)
  ---
  14 In  /LF   (NC)
  15 Out /ERR  (VCC via 0.47ohm) (installed only on carts with SRAM)
  16 In  /INIT (NC)
  17 In  /SEL  (GAL.IN0.pin1)
  18..25 GND   (Ground)

User avatar
nocash
Verified
PSX Aficionado
PSX Aficionado
Posts: 541
Joined: Nov 12, 2012
Contact:

Post by nocash » July 28th, 2016, 3:02 am

Now I've also disassembled the command set in "Menu" mode...

Code: Select all

  GetByteByAddr32       Tx(5702h,Addr32), Rx(Data8)
  OldMenuBuReadFile     Tx(5703h), TxFilename, RxDataFFEEh
  OldMenuBuDeleteFile   Tx(5704h), TxFilename
  OldMenuBuWriteFile    Tx(5705h), TxFilename, TxFiledata
  OldMenuBuGetFileHdr   Tx(5706h), TxFilename, Rx(00h,00h), RxTurbo, Rx(02h)
  OldMenuBuOpenEvents   Tx(5707h)
  SetCop0Breakpoint     Tx(5708h,Addr32,Mask32,Ctrl32)   ;Menu: Dummy?
  OldMenuBuCopyFile     Tx(5709h), TxFilename  ;to other memcard
  OldMenuBuFormat       Tx(570Ah,Port8)
  OldMenuBuGetStatus2x  Tx(570Bh), Rx(Stat8,Stat8)  ;\different in old/new
  NewMenuBuGetStatus1x  Tx(570Bh,Port8), Rx(Stat8)  ;/
  MenuGetSetFlag        Tx(570Ch), Rx(Flag8)   ;get old flg, then set flg=01h
  NewMenuBuReadSector   Tx(570Dh,Port8,Sector16), Rx(Data[80h])
  NewMenuBuWriteSector  Tx(570Eh,Port8,Sector16,Data[80h])
  NewRawExecute         Tx(570Fh,Addr32)                 ;call Addr
  MidMenuBuggedExecJump Tx(5710h,ORra32,ORgp32,ORsp32,pc32) ;aka r31,r28,r29,pc
  MidMenuSendComment    Tx(5711h,Len8,AsciiMessage[Len])
  NewMenuFillVram       Tx(5712h,Xloc32,Yloc32,Xsiz32,Ysiz32,FillValue32)
  NewGetVram            Tx(5713h,Xloc32,Yloc32), Rx(Data[800h]) ;32x32pix
  NewGetSetIrqMask      Tx(5714h), Rx(OldMask16), Tx(NewMask16) ;Menu: Dummy
  NewSetVram            Tx(5715h,Xloc8,Yloc8,Data[800h]) ;X/Y=div32 ;32x32pix
  NewMenuGetFlgAndOrVal Tx(5716h), Rx(00h, or 01h,Val32)             ;  NewMenuGetTwoValues   Tx(5717h), Rx(Val32,Val32)                   ;
  NewMenu...            Tx(5718h), ...                               ;
  NewMenuGet2kGarbage   Tx(5719h,Dummy32), Rx(Garbage[800h])         ; whatever
  NewMenuGetSomeValue   Tx(571Ah), Rx(Val32)                         ;
  NewMenu...            Tx(571Bh,Data[4])  ;similar to 5763h         ;
  NewMenuNoLongerSupp.  Tx(571Ch)    ;probably WAS supported someday ;/
  GameAddCheatCode      Tx(5741h,Addr32,Data16), Rx(Index8)
  MenuReBootKernel      Tx(5742h)              ;jumps to BFC00000h
  GameDelCheatCode      Tx(5744h,Index8)
  GetMem                Tx(5747h,Addr32,Len32), Rx(Data[Len]), TxRxChksum
  Lock/Freeze           Tx(574Ch)
  OldMenuBuGetDirectory Tx(574Dh), RxTurbo
  MenuTestDB25Handshake Tx(574Eh), ...
  MenuOptimalGetMem     Tx(574Fh,Addr32,Len32), RxFaster(Data[Len]), TxRxChksum
  OldMenuGetWhatever    Tx(5750h), RxDataFFEEh                       ;-whatever
  Release/Unfreeze      Tx(5752h)
  SetMem                Tx(5753h,Addr32,Len32,Data[Len]), TxRxChksum
  TurboGetMem           Tx(5754h,Addr32,Len32), RxFast(Data[Len]), TxRxChksum
  MenuSetMemAndBurnFirm Tx(5755h,Addr32,Len32,Data[Len]), TxRxChksum ;burnFlash
  GetStateGameOrMenu    Tx(5757h), Rx(47h=Game, or 58h=Menu)
  SetMemAndExecute      Tx(5758h,Addr32,Len32,Data[Len]), TxRxChksum ;call Addr
  NewMenu...            Tx(5763h,Val32)    ;similar to 571Bh         ;-whatever
  GetByteByAddr24       Tx(5767h,Addr24), Rx(Data8)
  NewMenuBuggedExecJump Tx(577Ah,ORra32,ORgp32,ORsp32,pc32)  ;formerly 5710h
  NewMenu...            Tx(57C7h,Val32,Len32,Data[Len])  ;to flash ? ;-whatever
Function names starting with "Game/Menu" and/or "New/Mid/Old" are working only in Game/Menu mode, or only in New/Old xplorer firmware versions (new commands exist in v4.52, old commands exist in v1.091, mid commands exist in v2.005, but neither in v1.091 nor v4.52, unknown when those new/mid/old commands have been added/removed exactly, in which specific versions).

Command 5710h and 5711h have been a nasty surprise (after having disassembled the whole "Old" and "New" code, it turned out that utiities like xlink dos version used those extra commands which are supported by neither Old nor New firmwares (haven't checked if there are more such commands, but at least that two commands are important because some utilities rely on them). The newer firmware has 5710h renumbered to 577Ah, no idea why that was done, unless it's been for anti-backwards-compatibility purposes. And weirdly, both 5710h and 577Ah are bugged (ORing the old GP, SP, RA register values with the incoming parameters, rather than just MOVing the parameters to GP, SP, RA).

And all that mess about using different non-functional "Execute" commands wouldn't have been required at all, because 5758h did exist & worked best in all versions, but unfortunately the utilities are using 5710h or 577Ah instead of the "standard" 5758h function. So for exampe, xlink/dos works only with firmwares like v2.005, but not with v1.091 or v4.52, which can be quite frustating since users are forced to find out "which tools work with which firmware versions" by themselves.

User avatar
sickle
Verified
C Programming Expert
C Programming Expert
Posts: 257
Joined: Jul 17, 2013
I am a: Chocolate-fueled pug fetish robot.
Location: Scotland

Post by sickle » August 4th, 2016, 12:30 pm

nocash wrote: ...
And all that mess about using different non-functional "Execute" commands wouldn't have been required at all, because 5758h did exist & worked best in all versions, but unfortunately the utilities are using 5710h or 577Ah instead of the "standard" 5758h function. So for exampe, xlink/dos works only with firmwares like v2.005, but not with v1.091 or v4.52, which can be quite frustating since users are forced to find out "which tools work with which firmware versions" by themselves.
Kinda sad it's taken 20 years to get solid confirmation on this one but good to know I wasn't just going mad :D

danhans42
BANNED
BANNED
Posts: 329
Joined: Nov 28, 2012

Post by danhans42 » October 19th, 2018, 8:51 pm

I know this is digging up an old thread (sorry), just my intereest in this seems to get re-ignited every six months or so.

How feasable would it be to implement the above like greg did with xlinkusb but for the standard firmware? I have been having a look at was thinking that with it being designed for a parallel port, could we not say hook up a i2c/spi IO expander (MCP23S17) or a PCF8585 etc and then communicate with it using a microcontroller or RaspberryPi?

I would be kind of cool to get this wrapped into a library or something, that could be easily ported to other MCUs such as the ESP/STM32 so we can load EXE's over LAN/Ethernet/USB/Bluetooth or whatever.

Is anyone genuinely interested in this at all? Could be a community effort given some of the intelligence we have around here.

Post Reply

Who is online

Users browsing this forum: Baidu [Spider] and 2 guests