Newer X-Flash Builds

[danhans42]

Will be released later this week.. Squaresoft74 has kindly agreed to do some testing for me so will make sure everything works before making public.

IMG_18062019_091834_(640_x_480_pixel).jpg

NXFLASH is built on the source of XFLASH which was written by Tim Schuerewegen some time ago. It allows you to flash/backup cheat cartridges such as the Xplorer/Xplorder/AR/GS etc.

Shadow from PSXDEV.net managed to get in touch with him and he found the source code for it.

I wanted to add extra features and serial compatibility to it and support more flash parts so I decided to give it a new name - it basically means 'next xflash'. I believe it needed a new name as the original author may no longer want to be associated with it and to save confusion about client side tool compatibility.

In order to run NXFLASH you will need a way to execute it on a console. I will not cover that here as plenty of guides are out there for mastering bootable PlayStation discs and booting them. Alternatively, you could execute it using your usual code upload method (catflap/psxexe/psxserial etc.).

NXFLASH also has a Python3 based client for uploading/downloading data. It has been tested on Python 3.7 on both Linux and Windows 10.

Features :-
Dump cart EEPROM via Serial
Dump PSX BIOS via Serial
Clear Buffer
Flash cart EEPROM via Serial
increased screen width to 640px (from 512).
Increased size of Flash From CD Browser - 16 roms displayed and wider interface.
Xplorer comms support with xkiller (unchanged from XFLASH)

Its currently working really well, every cart I have flashed with in testing has worked 100%.

To accompany nxflash, there is a tool called nxflash.py (original huh?). Its written in Python 3.x and needs pyserial. The tool allows upload of ROM, and download of ROM and BIOS. It also has support for PSXSERIAL/Unirom v6 if you need to send the EXE to PSX that way.

In essence, that means you can flash your console easily without using a CD other than PSXSERIAL.

nxflash.py examples :-
Upload ROM - 'python nxflash.py -ur /dev/ttyUSB0 caetla038.bin'
Download ROM - 'python nxflash.py -dr /dev/ttyUSB0 ar_backup.bin'
Download BIOS -'python nxflash.py -db /dev/ttyUSB0 scph1002.bin'
Upload EXE to PSXSERIAL - 'python nxflash.py -run /dev/ttyUSB0 greentro.exe'
Its very simple tool, with hardly any exception handling and will overwrite files without prompt, so be careful!

Full documentation and the release will be on GitHub https://github.com/danhans42/nxflash

Would like to hear from people who have unsupported flash types so can see about adding support for them.

Will hopefully have it released by the weekend, just want to make sure its working for others before release.

[danhans42]

Squaresoft74 has kindly done some testing for me, and the results are very promising.

Need to fix some minor issues and implement a few suggested options and will get a release out shortly.

[rama3]

That sounds great, the name is really good as well!

I have a soft bricked Datel card here to try this out on. The original xflash didn't support the EEPROM, but xflash might.
I suppose it'd be best to build and use a serial cable to go with it.

[danhans42]

If it's not supported it probably still isn't. Can you drop me a PM with the details of the EEPROM and will get the part onto my to-do list?

If you can let me know the mode number of the EEPROM, and also what xflash detects (unknown followed by two hexadecimal number)
If you are in a position to test I can work with you to get it working.
Thanks

[danhans42]

Latest version on Github..

https://github.com/danhans42/nxflash

nxflash.py - pythion based client is also included - I recommend reading the info on the github repo.

Current Issues

Currently does not support the dual banked Xplorer FX ( 2x SST29EE020 PLCC32 ), if you have one of these carts please do not flash it as you may not be able to recover.

Also, the support for xkiller/LPT connection is still there but unsupported. It should work fine but I do not have a PC set up currently with WIndows that I can test this on.

If you find any little quirks (display not centred etc), please drop me a DM or raise an issue on github and I will sort it.

Next Version

As well as fixing any issues in the current version I will be looking to add the following features to the next release.

EXE loading via SIO (psxserial compatible) - implemented and working, need to pretty up the screens with some nice colour bars as seems to be fashionable for this kind of tool.

Xplorer ROM Version - Courtesty of RomProd v2.0 from Sicklebrick over on psxdev - I have been testing loading the EXE to a flash ROM on Xplorer cartridges. Works well.

More EEPROMs support

Enjoy.

And if anyone in the UK has a Xplorer FX dual ROM version they wouldn't mind parting with for R&D, please drop me a DM.

Also, is there any code in SDK that simply allows you to boot a CD? I kind of wanted to add a boot from CD option to this but I am struggling to find anything that boots from CD using the system.cnf

Thanks

[Squaresoft74]

Many thanks for this new release.

Current Issues

Currently does not support the dual banked Xplorer FX ( 2x SST29EE020 PLCC32 ), if you have one of these carts please do not flash it as you may not be able to recover.

I may also want to advertise that, for some reason, current version behave strangely when performing the FX detection when using a regular Xplorer.

If it's one with 1 x SST 29EE020-150-4C-NH 256K


A single FX check is performed and the cartridge is properly identified as a regular Xplorer.

If it's one with 1 x SST 29EE020-120-4C-PH 256K


A second FX check is performed outputing weird ID values (possibly based on currently flashed rom ?) but then the cartridge is still properly identified as a regular Xplorer.

I'll check if xkiller/LPT connection still works fine with my Win98 laptop asap.

[danhans42]

Hi Squaresoft,

Thanks for the testing on the test versions. I have that particular version of the regular xplorer and it does throw up those checks so will investigate those.

I have managed to source an old Toshiba Satellite machine so will be able to do tests with the parallel cable quite easily.

[danhans42]

Hi All,

Bit of an update. I don't know if this feature will remain or not but have managed to shoehorn PSX-EXE loading from SIO into xflash. I had to move the internal data buffer for loading ROMS to a higher memory location to get it working, and it currently only seems to work with EXE's at around 1mb.

Not only that, but rather than being stuck at 115200bps, I have got it working at 345,600bps... so its really fast! I also wanted to bake it into a ROM so it could instaboot, which is now working thanks to sickebricks romprod.

See the video below :-

[BBvideo=560,315]https://youtu.be/uyUpVIl4-oQ[/BBvideo]

[Dedok179]

Cool. I need it.

[Administrator]

How'd you get it going at 345,600 bps? LameGuy64 tried but it was unstable.

[danhans42]

Lol, I changed the baud rate.. that's it... Just changed the speed in the define for BPS in the hitmen source. It also ran at 230400, but wouldnt work at 200000..

I don't understand it, I tried myself in the past. I can only assume it's the simplicity of the graphics routine used or the fact that I'm using a genuine FTDI cable. Last time I tried it was with a clone and didn't work. It's using the same routines as hitserial except it doesn't report the size etc..

I haven't tried it with the sio dumping/upload functions yet, bit it never worked consistently with those and the old FTDI cable.

[Squaresoft74]

Great work as usual !

[danhans42]

I have put the changes I made to hitmen serial into a standalone EXE. The source is embarrassing but it does the job .

https://github.com/danhans42/sioload/

Selectable baud rate 115,200 or 345,600. Simple Python3 client included.

Source included.

Enjoy

[rama3]

The slower clock not working is probably a clock divider issue somewhere in the UART chain.
Not all hardware works well at all possible / standard baud rates.
345600 is 115200*3, 115200 being a very common value, so that should work

[danhans42]

My thoughts exactly which is why I went that way. I had a similar issue years ago on an STM32 I was targetting. 430600 definitely doesn't work on the Playstation reliably.

[sickle]

Oh man, this is so cool!
I've started doing a similar thing with UniROM (C rewrite, with some chunks from XFlash, dropping parallel support), but pacing myself... just taking it slowly. Got an absolute pile of carts sat in a box, so we should definitely compare notes at some point.
Anyway this is great and super useful, cheers

[danhans42]

Yeah definitely. Keep in touch.

After talking with Squaresoft74 over on the discord, I am currently adding PAR2 detection and dumping/flashing so it correctly changes bank.

Also, siocons sioload now runs at 1036800bps. Silly fast,

[sickle]

Yeah definitely. Keep in touch.

After talking with Squaresoft74 over on the discord, I am currently adding PAR2 detection and dumping/flashing so it correctly changes bank.

Also, siocons now runs at 1036800bps. Silly fast,

Ah! That's nuts.
Both ways?
You got it working with non-genuine FTDIs at that speed btw?

[danhans42]

Sorry typo - I meant sioload not siocons.

I actually need to check that haha. I left all the flashing upload/download functions at 115,200 in nxflash just to be safe.

[rama3]

So an MBit? That's often the point where some chips fail, some cables are too long, data gets corrupted in some cases.
If the PSX works with it, then advise to keep the serial connection short and use a good and short USB cable as well.
It should be fine then