What's new
By:

ATAPI/IDE ODE Testing

twistedsymphony said:
Testing is going well with the new ODE I think it's mostly working but I'm having a weird issue with SC2 where after the first load it prevents my 256 from loading any other game (including re-loading SC2). electric_monk hasn't been able to reporduce this on his setup unfortunately.
Click to expand...
Isnt becuase the security on SC2 is different than any other 246/256 game and hasnt been reverse engineered yet?
 
msamiullah said:
Isnt becuase the security on SC2 is different than any other 246/256 game and hasnt been reverse engineered yet?
Click to expand...
no, that's not it. it's doing this with the ODE even with original SC2 dongle and memory card.

I'm thinking either something isn't getting properly cleared on the mobo after switching games or something isn't getting properly cleared on the ODE.
 
Hi! :) twistedsymphony

I have an important question :saint:

How do I resolve the issue of losing settings every time I switch games, or the battery draining ?

I wanted to know if this problem could be resolved with a multi-dongle or the new ODE.

I know this is far-fetched. :D
 
AFAIK settings are stored on the mobo, not the dongle nor the IDE device so there is nothing a multi-dongle, nor an ODE could do to fix that.
 
twistedsymphony said:
Testing is going well with the new ODE I think it's mostly working but I'm having a weird issue with SC2 where after the first load it prevents my 256 from loading any other game (including re-loading SC2). electric_monk hasn't been able to reporduce this on his setup unfortunately.

I've also gone through and minimized all of the hdd images and tested most of them. with the minimization I can get 100% of the discs and hdds on a single 256GB thumbdrive, this includes all of the taiko games, racing games, and even satellite games for both 246 and 256.

Most of my testing has been swapped to the newer game set on Archive.org which has much more complete and properly dumped discs and dongles.
I did finally get my Pi selector up and running with this new set and the new ODE but there are two issues:
1. the Pi selector software doesn't handle dongle or drive image names with spaces. I had to tweak two .sh files to include quotes around the file names to get this working
2. the ODE has a line limit on the screen text and many of the new drive image file names push it beyond this limit, so at least the longer files will need to be renamed.

or alternatively the whole new game set can be completely renamed to remove spaces as well.

One Pair of games I've never been able to get running (even without the ODE) is Zoids Infinity and Zoids Infinity EXP
has anyone ever successfully loaded these on a 256? if so I'd like to know what the secret is.
Click to expand...
I will make the change to handle the spaces
Which archive.org collection are you referring to so I can test with it
 
Tonybolony said:
getting more exited for this
Click to expand...
🤣🤣🤣🤣
rocco-siffredi-840x1024.jpg
 
I think ODE testing is nearly done. I passed the torch to @mathewbeall a few weeks ago and he's carrying the testing and verification over the finish line :)

I'll let him chime in on the details if he'd like.

parallel to this I went through an prepped all of the clean dumps from Defor for addition to MAME, no idea when that will be officially added but that will help all these get in sync.
 
Last edited:
twistedsymphony said:
I'm thinking either something isn't getting properly on the mobo after switching games or something isn't getting properly cleared on the ODE.
Click to expand...
Sorry for the very late reply on this and probably anything else. I’ve missed over the last half a year again… Anyway, you’re right on the money on this. Back in the day we used to have advice that anytime you switched a game you should boot the system without a dongle in it and power cycle it a couple times to “clear “what was currently being loaded.

Now that said, what I believe is actually happening behind the scenes is that each game has a different load for the Namco board side FPGA, and because that FPGA is responsible for everything from jam/JVS to IDE operation, mismatches between the version that’s loaded and the game that you’re trying to load will cause the game not to load. Now I’m not sure what the criteria for clearing the FPGA and reflating, but my suspicion is that some games actually either check the version first or simply just flash it anyway on boot, while others, if they find any FPGA code simply just use whatever they find because it sort of seems to work.

Just my observationally based assessment of the situation, I don’t have the technical know how to actually debug the system and see if this is actually what’s going on.
 
If you're interested in the inner workings you can use PS2 memory card tools to read the .bin files. I did so for Dragonball Z during some debugging and also partially just out of curiosity (and for fun I also made my own tool to actually extract the filesystem from the file) and in there you can see a file called "FPGA" which is 126,002 bytes long which seems pretty likely to be an FPGA bitmap that'll get loaded somewhere at runtime.

Other interesting stuff is all the various hardwsare drivers, including the ATAPI drivers for the DVD drive (though sadly not super helpful for me - but there are indications there might be debug logging that could be received with the right tools) and also the main game binary is in the memory card, in DBZ's case at least it's a file called "DBALOAD", if you run 'strings' on it you can see all sorts of interesting stuff - texture names, apparently the game was written in C++ as there's classnames for various skeletons for the 3D models of all the characters, you'll see text for the various attract screens and so on too.

With regards to the FPGA file there's also a file that looks like a driver to load the FPGA, and macOS even recognises it as a Playstation 2 I/O module:
ACFPGALD: ELF 32-bit LSB PlayStation 2 IOP module, MIPS, MIPS-I version 1 (SYSV)
The DBALOAD executable does include mention of this driver but all I did was run strings on it, I haven't tried reverse engineering it or anything, that's much more work ;)
 
defor said:
Sorry for the very late reply on this and probably anything else. I’ve missed over the last half a year again… Anyway, you’re right on the money on this. Back in the day we used to have advice that anytime you switched a game you should boot the system without a dongle in it and power cycle it a couple times to “clear “what was currently being loaded.

Now that said, what I believe is actually happening behind the scenes is that each game has a different load for the Namco board side FPGA, and because that FPGA is responsible for everything from jam/JVS to IDE operation, mismatches between the version that’s loaded and the game that you’re trying to load will cause the game not to load. Now I’m not sure what the criteria for clearing the FPGA and reflating, but my suspicion is that some games actually either check the version first or simply just flash it anyway on boot, while others, if they find any FPGA code simply just use whatever they find because it sort of seems to work.

Just my observationally based assessment of the situation, I don’t have the technical know how to actually debug the system and see if this is actually what’s going on.
Click to expand...
This makes a lot of sense to explain some "weird" behavior as I was doing all my testing - for the MOST part, things worked well going from game to game - which holds the RST down when programming dongle and loading the disc. Sometimes - regardless of what I tried - it just wouldn't load up - either blank screen, or the blue error screen. After a hard reboot - at least 10 seconds off, the load works.
 
I wonder if there's dongle image/game that we could identify that does good clean up to temp load after problematic games.
 
twistedsymphony said:
I wonder if there's dongle image/game that we could identify that does good clean up to temp load after problematic games.
Click to expand...

It happened relatively little for me with all my testing.... interesting idea, but it would make game switching take a lot longer. I almost think that the hard power down wipes out the FPGA vs the reset button, which I don't think does (based on anecdotal behavior).

But yeah - IF we could do a very small dongle load that would wipe out the FPGA load, and then do the selected game, that could make it more reliable - although would double up dongle writes - I assume there *is* some finite total limit for those.

Matt
 
Last edited:
uyjulian said:
I already RE'd ACFPGALD; it is in ps2sdk now.
Click to expand...
Ah, but the interesting question everyone is discussing here (and would take too much time) is how each separate game actually interacts with that driver, like do they all just slam it in every boot, or do they gate it on the first boot NVRAM check (which I think occasionally fails? This could occur if the game fails to notice it's invalid, like if multiple games use the same checksum or other means to verify the content). This could also be informed by looking at the actual FPGA on the board and seeing if it's a RAM or a flash device, since in the latter case they should in theory be limiting the number of writes to prevent the device wearing out too fast. Some FPGAs can also report their fabric checksum but that might be a bit of a newer thing.

Another interesting comparison I/somone could do fairly quickly would be to just look at the hash of every FPGA file on all the memory card images I have lying around. As a total guess I'd expect some games use the same FPGA bitmap (if they came from the same/related teams/etc.) but it'd be interesting to know how much it varies.
 
Very unscientific using my little test PS2 card reader and `find`:

Code: 
find . -name \*.bin -exec ls {} \; -exec PS2MemoryParser {} \;|grep -e memcards -e " FPGA"
./246_memcards/zoidsinf-b3900076a.bin
2004/06/19  16:55            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./246_memcards/tekken4-tef3verc.bin
2001/09/05  13:36            126002 FPGA                             00000000 8e5380693dff7349d2d442c1e95891cdda7e0677
./246_memcards/soulcl2b-sc21vera.bin
2002/07/08  22:41            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./246_memcards/timecrs3-tst1vera.bin
2003/03/27  16:25            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./246_memcards/timecrs3e-tst2vera.bin
2003/04/16  09:17            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./246_memcards/bldyr3b-br3-dongle.bin
2010/03/28  13:34            126002 FPGA                             00000000 6e494eb8af876a09f6ec5adcb51c6be6e2912dd3
./246_memcards/wanganmr-wmr1vera.bin
2009/04/02  16:07            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./246_memcards/scptour-scp1vera.bin
2002/03/22  12:12            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./246_memcards/tekken4a-tef2vera.bin
2001/08/09  01:28            126002 FPGA                             00000000 8e5380693dff7349d2d442c1e95891cdda7e0677
./246_memcards/qgundam-qg1vera.bin
2006/04/12  15:29            126002 FPGA                             00000000 8e5380693dff7349d2d442c1e95891cdda7e0677
./246_memcards/cobrata-cbr1verb.bin
2005/12/13  14:05            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./246_memcards/wanganmd-wmn1vera.bin
2001/12/17  11:21            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./246_memcards/zgundm-zga1vera.bin
2003/09/09  11:40            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./246_memcards/vnight-vpn3verb.bin
2001/03/19  17:04            126002 FPGA                             00000000 6e494eb8af876a09f6ec5adcb51c6be6e2912dd3
./246_memcards/rrvac2-rrv2vera.bin
2001/05/03  01:10            126002 FPGA                             00000000 6e494eb8af876a09f6ec5adcb51c6be6e2912dd3
./246_memcards/soulclb2-sc23vera.bin
2002/07/12  14:29            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./246_memcards/gundzaft-sed1vera.bin
2005/07/15  11:28            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./246_memcards/netchu02-npy1verb.bin
2002/04/16  14:21            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./246_memcards/fateulc-fud1vera.bin
2008/05/22  16:27            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./246_memcards/sukuinuf-in2vera.bin
2007/01/24  15:37            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./246_memcards/dragchrn-dc001vera.bin
2004/12/13  12:50            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./246_memcards/fghtjam-jam1vera.bin
2004/09/29  10:02            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./246_memcards/soulcl2a-sc22vera.bin
2010/05/02  16:12            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./246_memcards/prdgp03-pr21vera.bin
2003/10/16  17:12            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./246_memcards/rrvac-rrv3vera.bin
2000/12/05  09:46            126002 FPGA                             00000000 6e494eb8af876a09f6ec5adcb51c6be6e2912dd3
./246_memcards/gsd-gsd1vera.bin
2006/07/07  13:37            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./246_memcards/tekken4b-tef1vera.bin
2001/07/30  08:04            126002 FPGA                             00000000 8e5380693dff7349d2d442c1e95891cdda7e0677
./246_memcards/taiko7-tk71.bin
./246_memcards/sbxc-bax1vera.bin
2008/03/19  15:33            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./246_memcards/soulclb3-sc31001-na-a.bin
./246_memcards/taiko8-tk81001-na-a.bin
./246_memcards/soulclb3a-sc31002-na-a.bin
./246_memcards/rrvac1-rrv1vera.bin
2000/11/20  08:31            126002 FPGA                             00000000 6e494eb8af876a09f6ec5adcb51c6be6e2912dd3
./246_memcards/zgundmdx-zdx1vera.bin
2004/08/24  13:21            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./246_memcards/tekken4c-tef1verc.bin
2001/08/22  15:49            126002 FPGA                             00000000 8e5380693dff7349d2d442c1e95891cdda7e0677
./246_memcards/fateulcb-fates-dongle.bin
2010/04/25  16:45            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./256_memcards/yuyuhaku-dongle.bin
2006/09/04  15:40            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./256_memcards/superdbz-db1verb.bin
2005/12/03  10:32            126002 FPGA                             00000000 8e5380693dff7349d2d442c1e95891cdda7e0677
./256_memcards/gdvsgd-gvs1vera.bin
2008/03/04  14:18            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./256_memcards/tekken51b-te53verb.bin
2005/02/24  15:03            126002 FPGA.256                         00000000 090ee43d46cf57596d6577bc39f05153ee5c60eb
./256_memcards/taiko10-t101001-na-a.bin
./256_memcards/kinniku2-kn2vera.bin
2007/06/11  16:18            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./256_memcards/kinniku-kn1vera.bin
2006/02/21  09:11            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./256_memcards/timecrs4-tsf1002-na-a.bin
2006/11/28  16:06            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./256_memcards/zoidiexp-b3900107a.bin
2006/11/15  11:25            126002 FPGA                             00000000 6150a42ab237e5bcc2ac8317ba7a6b7ee9bda1dd
./256_memcards/tekken5d-ted1vera.bin
./256_memcards/taiko9-tk91001-na-a.bin
./256_memcards/gdvsgdnx-gnx1001-na-a.bin
2009/02/06  12:24            126002 FPGA                             00000000 a88b399a8209815fea4dd2a2fd8690580cb27887
./256_memcards/tekken51-te51verb.bin
2004/12/08  10:05            126002 FPGA.256                         00000000 090ee43d46cf57596d6577bc39f05153ee5c60eb

Looks like some games don't come with any FPGA binary, but there are plenty of games sharing the same bitmaps.
 
electric_monk said:
Ah, but the interesting question everyone is discussing here (and would take too much time) is how each separate game actually interacts with that driver, like do they all just slam it in every boot, or do they gate it on the first boot NVRAM check (which I think occasionally fails? This could occur if the game fails to notice it's invalid, like if multiple games use the same checksum or other means to verify the content). This could also be informed by looking at the actual FPGA on the board and seeing if it's a RAM or a flash device, since in the latter case they should in theory be limiting the number of writes to prevent the device wearing out too fast. Some FPGAs can also report their fabric checksum but that might be a bit of a newer thing.

Another interesting comparison I/somone could do fairly quickly would be to just look at the hash of every FPGA file on all the memory card images I have lying around. As a total guess I'd expect some games use the same FPGA bitmap (if they came from the same/related teams/etc.) but it'd be interesting to know how much it varies.
Click to expand...
What I can tell by looking at acfpgald only is that there is no version or other sort of FPGA-targeted check before sending the bitstream to the FPGA using purely the address lines (data lines are fixed to zero).
 
You must log in or register to reply here.
Back
Top