PlayStation Development Network

EDIT:

Edited thread title - seemed more relevant

Download latest version (Beta 8) from this post :-

http://www.psxdev.net/forum/viewtopic.p ... 599#p17599

New name - NXFLASH.. Download Beta 9 from this post

http://www.psxdev.net/forum/viewtopic.p ... =40#p17756




I have tried to build one of the versions of x-flash from source using the source code posted here. Tried all the versions, same issue :-
Tried on two different machines, one using the 16bit compilers and the other on Win98 with the 32bit..

Anyone any ideas?

Maybe the inline assembler doesn't like an implied offset of zero - try changing ($4) to 0($4) to make the zero offset explicit

Worked perfectly!

Thanks Trimesh (have a few wierd EEPROMs.. I was going to see if I could get Xflash to detect them

v1.2 b5 version compiled, with source and makefile.

Only changes are the 6 lines with the suggestions from Trimesh.

We'll have to definitely make an official release with all the needed fixes and adjustments in place sometime. Good to see it being able to be compiled though. That's always a good sign

Think we do need to update it, completely open of course.

Had a further play with this. Modded an old EMS AR clone and added a ZIF slot to make life easier. Then tried a SST39SF020A in a PLCC32 adapter.

Pre-flashed it with Caetla 0.38 and loaded my modified code into the memory card. The flasher worked fine with WC29C020 and a few other supported roms, but didnt work with the 39SF020

Got it to detect fine by adding in the Manufacturer size and FlashID, (0xBF 0xB6) along with the size information. Every time I go to the flash menu, choose a ROM and attempt to flash it crashes with an error (CAETLA - Address Load iirc)

.I will get a screenshot of it and upload the modified code later today), it does write something to the ROM as it wont boot after the attempt.. suppose an idea would be to read that chip and see what differences there are.

There are three settings in the code that I changed.. There is the size (256), block size (tried 128 and 256) and a delay time (tried 10ms/20ms).. could be something as simple as this but not 100% sure.


Anyone help with the block size? Is this page size?

Ill see about getting the latest version into github, so the changes can be tracked easily from the original code. I have also uploaded both the datasheets for convenience.

Ahaaa,, amazing what you find when you read things correctly...

So in the datasheet for the 29EE020 :-
So 262,144/128 (bytes per page) gives you 128 - same as in the source code... but the 39SF020A states..
So it does look like it writes byte by byte.

I have the source code for uniflash which i will look at, which is a DOS based application for BIOS writing and supports lots of different flash types. Its written in Pascal (ughhh), but its fairly easy to see the flash routines in it.

See below :-
SST 39SF020 SST 29EE010

Looks like it might be worth looking at the SST 28SF040, as it supports byte write and sector erase (possibly similar to the flash operation of the 39F020.

Investigation continues

Will work on pushing this to github tonight. Will keep the versioning the same but this can become v1.2 b6 as it has the changes from Trimesh that allowed it to compile.

If anyone has any unsupported flash parts they would like me to try and add, please let me know. I would need to know the ID numbers that xflash displays to code it in.

Thanks

Had a look after the failed write,, seems that it writes one byte per 100h bytes... Ill post the files for comparison later. Tried with different page sizes and that didnt work.

As promised, find attached the attempt to flash the 39SF020..

Writes something every 100h bytes.. so its trying at least. Have also added the source and compiled EXE.. I have added the definitions in for SST39SF020(256k) and the AMD Am29F040 (512k).

Literally emptied the garage looking for 28/29 series flash parts to try.. all already either supported or dead. The only cheat cart I had with a flash rom on it was a TMS28F010A, but unfortunately its dead so cant test it.

If anyone (UK or elsewhere) has any bricked carts they want fixing that arent supported please get in touch.. Can look at adding support or at the very least, get you back up and running as I have a flash programmer.

Cheers

D

So with the 39SF chips I seem to remember it using more address lines for write commands then the older chips. I found a thread on nesdev where it was discussed a little. https://forums.nesdev.com/viewtopic.php?f=9&t=16029

Not sure that is helpful.

Hi,

Thanks for the info, will double check the datasheet and have a read. Very helpful

Update: Just got a clone AR cart that wasnt detected in Xflash - It has a Sanyo branded LE28C1001T. Interestingly Sanyo branded flash parts are just SST.. so usually use the SST Manufacturer/Part ID's.. this one didnt.

Detected as D0 01. Cant find any Flash manufacturer that uses that ID.. so added in as "UNKNOWN 128K".. and just flashed Caetla with Xflash.. worked perfectly . Also, seems the code detects any flash part with the ID A4 as an Xplorer.. so have fixed that too,

Ill get it onto github this weekend.

muramasa wrote: ↑April 5th, 2019, 5:58 pm So with the 39SF chips I seem to remember it using more address lines for write commands then the older chips. I found a thread on nesdev where it was discussed a little. https://forums.nesdev.com/viewtopic.php?f=9&t=16029

Not sure that is helpful.

Thanks for this, very helpful indeed.. helps understand what is happening so thanks for the link.

.. I have had a look at the sources and the datasheets for various flash chips I have on hand.

So the write command addresses from the discussion and the docs of the SST39F and also the SST29EE both show the same addresses - so I am assuming that this isnt an issue as they are the same. I have a Am29F040 that doesnt work - now I know why.

AMD 29F040 29EE020 and 39SF020 When looking at the source for xflash..
You can see there its at ...5555 and 2AAA, whereas some of the other flash devices, namely those by AMD use different addresses (555 and 2AA) Am29F040/AM29vf040.. so thats helped understand why they do not work - not to worry, no carts ever used them).

Still remains, why wont the 39SF work... the investigation continues

Put on Github.. https://github.com/danhans42/xflash/

Awesome work here, can't believe the old xflash seeing some nice updates!

Nice to see some work on Xflash, keep it up !
As a suggestion about your todo list on your github:

Remove Xplorer Parallel routines (does anyone use xkiller anyway?)

Please don't ! I'm still using it to dump cartridges.

No worries, I will leave it be.

If you get any carts that show "UNKNOWN FLASH", can you let me know the ID numbers it reports and what model flash it is? I can look to getting extra carts added (would be a great help).

Thanks for taking into account.
I do have a few bootleg cards, will check them asap and will let you know.
Could you provide compiled binaries of your progress in this topic (can't build them here for now) ?

I also have an Xploder/Xplorer/X-Terminator romset from either original (decrypted) FCDs or own dumps if you ever want to make a disc having them later.
And also a few other dumps from my bootleg cartridges.

*EDIT1*
It seems your current posted build doesn't like hotswap if uploaded on my modded Xplorer (flashed with NO$CASH Kernel Clone Expansion ROM Version).
It seems to freeze when performing the hotswap.

On the other hand works fine if uploaded on an unmodded Xplorer (flashed with original rom).

I'll try with nocash bios clone on an unmodded cartridge just to make sure what's causing the freeze when hot swapping.

*EDIT2*
Ok same with unmodded cartridge, comes from the bios.
I'll stick with original Xplorer rom for upload and hotswapping

Will post cartridges infos later.

Thanks for the feedback.

Interesting regarding the hotswap.. which version of xflash were you using when the hotswap worked okay? Also, when you say hotswap are you hot swapping the ROM or the whole cartridge?

I haven't actually changed any of the core code, just added some flash part in and an extra if clause when doing the cart detection which wouldn't cause this to happen so my initial thoughts are that its something that was added in the later beta versions.

I will build all the older versions when I get time so we might be able to isolate the issue and will also see if I can replicate it myself... support for some extra ROMs was added over time and it may be part of the ROM/GAL detection code that makes it freeze when you hotswap.

I will post compiled versions on here as and when features are added and tested.

Thanks

Your Xflash build wasn't the cause of the freeze i had.
Sorry if i made it sound like that.

Usually i'm using kHn's Cheat Engine Compilation disc for my cartridges needs.
(It also contains old Xflash and a bunch of cartridge dumps).
Booting the disc on a mod chipped console, so no custom bios involved here.

To test your build i uploaded it to the console via my Xplorer(s) using no$psx.
(i'm not using PSXserial, too slow for my exe testing needs).

The freezing issue came from the fact that i was using NO$CASH Kernel Clone Expansion ROM version on my Xplorer and removing the whole cartridge might not be expected, hence the whole system crash/freeze.

I wasn't aware that would cause issue when using the kernel clone.

Using instead an original Xplorer rom and removing the whole cartridge once Xflash is uploaded and running isn't a problem on the other hand and all good for hotswapping.

Now I understand, sorry for the misunderstanding.

That makes sense now, that will be down to the fact that the cart is constantly in use as its a replacement for the on board BIOS.

I used to find a similar issue with my cart that I use for development.. if you remove a EEPROM/Cart whilst the PlayStation is still in Caetla/Unirom the system will hang but if I execute xflash, and then remove the cart/EEPROM it works fine.

my other thought is to rename this project something else whilst still crediting xflash and its authors so its not confusing for the end user with loads of different versions about.

Just make sure you have the means to recover from a bad flash if flash testing.