xplorer64 orange

[Nes-player4Life]

I have the undumped orange xplorer (E) 1.067
xkiller doesnt work do to giveio and win 2kpro.

where do we go from here?

[TheGent]

I have the undumped orange xplorer (E) 1.067
xkiller doesnt work do to giveio and win 2kpro.

where do we go from here?

Same as Nes, we have also been unsuccessful in communicating and interfacing on Win98se and Win2000.
Could really do with a way forward here.

[Nes-player4Life]

[danhans42]

Xkiller doesn't work with this Xplorer version or any other of the current xplorer64's.

I have a working solution using a raspberry pi which works with the versions I have listed but there are only three functions on these carts.. loadbin&exec, status and flashupdate.

What are you trying to achieve with your carts?

[Nes-player4Life]

I realize the 1.067 E cart has not been dumped. only the G rom. I'm trying to dump it.

[TheGent]

Xkiller doesn't work with this Xplorer version or any other of the current xplorer64's.

I have a working solution using a raspberry pi which works with the versions I have listed but there are only three functions on these carts.. loadbin&exec, status and flashupdate.

What are you trying to achieve with your carts?

Hey danhans42, dump the bios (Rom) so it can be used to update to rather than using the only dumped German Version.
That is the goal.

Edit: The green label is only a standard version where as this 1.67E Orange like the G is the Pro version allow cheat search function.
So it is inoperative to have the English version along side its German counterpart.

[Nes-player4Life]

Xkiller doesn't work with this Xplorer version or any other of the current xplorer64's.
I have a working solution using a raspberry pi which works with the versions I have listed but there are only three functions on these carts.. loadbin&exec, status and flashupdate.
What are you trying to achieve with your carts?

Hey danhans42, dump the bios (Rom) so it can be used to update to rather than using the only dumped German Version.
That is the goal.

exactly

[danhans42]

You cant do that currently using the cart itself.

The publicly available xplorer bios/roms that are on the carts are not capable of doing so. The xplorer bios doesnt have the functions in it to download from the N64, only upload (as per my previous reply).

the only way it would be possible is to either a)

1. remove the eeproms from the cart and dump them using a programmer. Then combine them back together (xplorer uses a pair of 8bit eeproms so they can be read together for 16bit access). However, this might not be as simple as it seems..

2. write an application for the N64 that will actually dump the BIOS back from the xplorer over the parallel port. However this would require knowledge of how the port it decoded into the N64's cart address space or whatever.

3. Dump the xplorer using a DIY cart dumper of some description - nothing currently exists that specifically supports the xplorer64.

Also, note the dump you mention of the 1.067G - its actually not a proper cart dump. It lacks the correct header etc so should be disregarded.

I have both the versions of the cart mentioned in the readme.. both are equal in what they are capable of which is just flash update/check status and upload&exec - nothing else.

[danhans42]

The other functions that are in xflash are for a much earlier private beta of the software which was never publically released. Tim the xflash author was given this to write the xflash software but the functions never made it into the retail version - probably due to its out of the box abiity to dump a cart and Blaze didnt want the hassle from Nintendo maybe?

He no longer has the beta software or the cart so that is a dead end.

In summary, the only thing xplorer64 is good for is homebrew dev like you can do with a GS.

[danhans42]

In respect to dumpng the eeproms - I have done this but the data seemed to be obfuscated or possibly corrupt. The Blaze guys might have been clever and messed the address lines up to make it difficult to clone or dump the cart? Its something I need to try and revisit.

[TheGent]

Thanks for the reply danhans42 , that is a shame to hear. I did upgrade my Green label to the v1.67G Orange using the xpl64_1067e from nesworld and thinking it was like labeled the E. So that is what sparked this interest.

[Nes-player4Life]

Thank you for the information. I was really hoping to preserve this device. The N64 isnt getting any younger.

Please keep up your work there arent many resorces regarding XP64 on the web.

[TheGent]

Thank you for the information. I was really hoping to preserve this device. The N64 isnt getting any younger.

Please keep up your work there arent many resorces regarding XP64 on the web.

Absolutely. We all wish you all the best with this, and live in hope maybe some day we might have the ability to use more modern OS and maybe USB printer port adapters also.

[danhans42]

Usb printer adapters generally don't work because they aren't proper parallel ports and only support the protocol IEE1284 for printers

I hopefully will make a simple adapter that will achieve what I currently have done with a MCU of some description. However, it's use will be limited on the N64 due to the limited functions in the Xplorer above.

I'll update on here when I get that done.

[danhans42]

Thank you for the information. I was really hoping to preserve this device. The N64 isnt getting any younger.

Please keep up your work there arent many resorces regarding XP64 on the web.

Will do. I assume that to update the Xplorer with the bundled utility it doesn't need a full flash dump, it just writes part of the cart. I did start to look at the disassembly of the update utility but haven't revisited in a long time.

[m0ckery]

In respect to dumpng the eeproms - I have done this but the data seemed to be obfuscated or possibly corrupt. The Blaze guys might have been clever and messed the address lines up to make it difficult to clone or dump the cart? Its something I need to try and revisit.

Hi there :) I’m able to desolder and dump the EEPROMs - would this help or would that possible address line issue cause issues with a successful dump?

[fraser125]

The "obfuscation" isn't what you think. Each chip is 8-bit interface, on a 16-bit bus. So you take a byte from each dump to make 16-bits. Once that is done take 32-bits from the merged file and see if it's a MIPS instruction.

Luckily there are only 2 different ways it can go together.

I dumped 4 EEPROMs from the shark wire and there are 4 different ways it could go together.

[m0ckery]

The "obfuscation" isn't what you think. Each chip is 8-bit interface, on a 16-bit bus. So you take a byte from each dump to make 16-bits. Once that is done take 32-bits from the merged file and see if it's a MIPS instruction.

Luckily there are only 2 different ways it can go together.

I dumped 4 EEPROMs from the shark wire and there are 4 different ways it could go together.

Interesting! Would this cause issues with a raw dump of each eeprom and burning it directly to another eeprom to try in another cart for example?

[fraser125]

If the new roms are 8-bit drop in replacement the only concern is putting the chips in the right position.

[m0ckery]

If the new roms are 8-bit drop in replacement the only concern is putting the chips in the right position.

I was planning on labelling which chip goes where and labelling the dumps accordingly. Would be a good way to possibly revive corrupted carts and such :)

[danhans42]

The "obfuscation" isn't what you think. Each chip is 8-bit interface, on a 16-bit bus. So you take a byte from each dump to make 16-bits. Once that is done take 32-bits from the merged file and see if it's a MIPS instruction.

Luckily there are only 2 different ways it can go together.

I dumped 4 EEPROMs from the shark wire and there are 4 different ways it could go together.

I am already aware of how 2x 8bit ROMS are arranged on a 16bit bus. I have dumped them and used various tools to merge them and the data is not legible which lead me to my statement above.

The start of the dump should follow some sort of arrangement as per a standard N64 cart header (media flag etc) but does not. Which lead me to believe there is something else wrong or somehow my EEPROMs some how were corrupted when removed.

My next step on this was going to be write a cart dumper to dump them in situ as it just seems easier.

[danhans42]

xp64_romdump.zip

have a go yourself :) These are the dumps I made (several times) of an 1.067E cart.

If you look towards the back end of the dumps 0x18000 onwards - this is where I would have expected to find the cheat list usually but if you look its a bit of a mess. I actually checked the data lines to ensure they were correct as they do not run through the CPLD for the EEPROM, they are in the correct order. I would assume these dumps to be corrupt

[m0ckery]

xp64_romdump.zip

have a go yourself :) These are the dumps I made (several times) of an 1.067E cart.

If you look towards the back end of the dumps 0x18000 onwards - this is where I would have expected to find the cheat list usually but if you look its a bit of a mess. I actually checked the data lines to ensure they were correct as they do not run through the CPLD for the EEPROM, they are in the correct order. I would assume these dumps to be corrupt

Thanks for sharing that dump - i've had a look through and there is nothing recognizable which is strange! I'm really tempted to remove my EEPROMs and dump them but I might wait until I get a second unit first lol - let me know if i can be of any use :)

[danhans42]

No problem. Yeah I am pretty sure they are just "rubbish" which is a shame. You can kind of make out blocks of data in roughly the correct locations but other than that its just unreadable.

I actually have 4 Xplorers, 1 dead, 1x v1.00 and 2x v1.063. Might do the same but do not really want to sacrifice another cart if I can help it :)

[danhans42]

in fact f**k it I will do it.. its in the name of science right? :)

If anyone here wants to talk about this a bit more im on discord #n64brew & #psxdev generally - feel free to message me

[danhans42]

Just dumped another Xplorer64 (v1.063E) - very very similar output

My conclusion is that there is more to this than meets the eye - my dumps are correct there is just something else going on

[Nes-player4Life]

great news!

@TheGent check it out

[m0ckery]

XPLORER_U2_U3_Gent.zip

Hi @danhans42,
@TheGent sent his his green label xplorer64 which has corrupted firmware. I've dumped them and attached as it may be partially useful somehow. I've now socketed the chips on his board and reflashed the eprom's with your dumps - the board is still dead. (The red light is still functional and responds to button presses/long press to reset to boot 1)

TheGent's board might be a different variant to yours as the eproms are located at U2/U3.

[Nes-player4Life]

https://github.com/jgazeley/n64cartreader
Is a new cartridge dumper that is open. Perhaps codecan be added to it so it reads the xplorer64.

[RWeick]

Hey all,

I’ve solved the mystery of the Xplorer 64 firmware scrambling, and also fully implemented dumping and programming them with the Sanni Open Source Cart Reader - you can now revive dead Xplorer 64’s. Here’s the work, including good dumps of previously undumped carts: https://github.com/RWeick/FCD-0003.1S-Xplorer64

https://github.com/sanni/cartreader

And I codeveloped a tool to modify the code list of the Xplorer 64 rom file once you’ve extracted it: https://github.com/LibreShark/hammerhead

[RWeick]

DanHans42, I've unscrambled the firmware that you linked above. It's version 1.000E revision 1773 and I didn't have that one yet, thank you! Unfortunately it is corrupted, your chips seem to have erased portions of themselves individually.
Xplorer64 1.000E 1773.zip

TheGent, unfortunately your firmware is fully corrupted.