search

vonmillhausen / sf2000

Information regarding the SF2000 handheld console
https://vonmillhausen.github.io/sf2000/
244 stars 13 forks source link

Some updates #15

Closed nummacway closed 5 months ago

nummacway commented 5 months ago

Hi there. Thank you for compiling all the information. I got a GB300 (which does not feature an arcade section, you might want to add that) and would like to make a few remarks on your game list:

vonmillhausen commented 5 months ago

Hi @nummacway! Thanks for the very detailed feedback! Let me take the main bits of it in turn:

a GB300 (which does not feature an arcade section, you might want to add that) [...] The following games are not on the GB300 and you might want to mark them in your list

I fell in love with the SF2000 when I first saw it (around about a year ago at this point - sheesh, time flies!) because of its nostalgic horizontal form-factor. I had bought retro gaming handhelds before it, but always in a vertical form-factor. There were lots of rumours flying around, and as the first units started being delivered to folks who were active in Discord, I saw the same questions being asked over and over. So I decided to start documenting findings that were being reported in Discord, just for my own purposes (I hadn't bought my own unit yet, and wanted to make sure I'd recorded the important details for when I did) - that's how my document started.

Since then, many other devices have joined the "frog family" - devices that appear to use very similar hardware and software, but with various tweaks; the DY12, the DY14, the DY19, the Q19, the Y2, the SG800, the SF900, the 8BitKing, and of course, the GB300. Out of all of them, my heart still belongs to the SF2000 - that's the only one I'm personally interested in owning and documenting. As such, I currently have no plans to document anything to do with the GB300, nor any of the other members of the frog family, beyond the brief mention in the FAQ section of my document (where I do also mention I won't be documenting it).

However, as you point out, there does seem to be some interesting differences between the stock image for the GB300 vs. the stock image for the SF2000 - not only the ROM differences you pointed out, but also (I believe) they changed the fake names of all of the resources files. Hopefully someone out there might have the same drive and determination I had for the SF2000, and will put together an information resource catered to the GB300 - maybe yourself? It seems like you've already generated some great data about the GB300's ROM set! All I can tell you is that it won't be me.

I'm also hoping someone out there will feel the urge to document the current multicore builds - adcockm has put together a really excellent read-me which is included with the official releases, but I see questions almost daily on Discord asking about how to add ROMs, how to get the dynarec gpSP core working, etc., so some additional documentation that folks could be pointed to would probably be valuable. Again though, won't be me - I feel I've done my bit already 😅

The image in Pokemon Glazed is actually RGB565, it's just too big (346x500)

Indeed! As is probably obvious, the HTML and CSV data I have for the stock ROM set was machine generated, not hand-written. I wrote a Python script to go through all of the .zxx files in the stock image, and pull out all of the interesting data from them. The Thumbnail data too long (possibly BGRA instead of RGB565); thumbnail display likely corrupt, game may not load message is presented when the thumbnail data in the .zxx file is too long (more about that in another reply below); this is usually because whoever put the ROM set together used BGRA images instead of RGB565, but not always - hence my use of the word possibly in the message 😃

HotBlood - ice Hockey.zfc is misspelt in the HTML list. There's actually two spaces after the dash, which aren't properly escaped in the HTML file and therefore omitted.

Technically it's not misspelled; if you view the source of the HTML list (as in, the actual source, not the HTML as interpreted by your browser via "Inspect" or similar), you'll see the double space is correctly in the data; it's just that the W3C decided that multiple adjacent spaces should be collapsed when displaying text on the web, which is great and useful is most contexts, but not in all (like this one). Theoretically I could make it display correctly by encoding the data using HTML entities (e.g.,  ) - but honestly, the Python script that generated the data was super quick-and-dirty. Could that script be improved to handle things like random double spaces in the file names? Sure! Did I want to spend the time finding every last weird thing that Data Frog had done with their dodgy ROM set for a script I was probably ever only going to run once? Not really. Take it as a personal failing on my part 🤣

Your CRC32 hashes lack leading zeroes, which I think they should have.

Good catch! The Python script which generated the data used binascii.crc32 to generate the CRC32 hashes, specifically via this call:

crc32 = f'{binascii.crc32(zip_data):x}'

The :x formatting string is what's truncating the leading zeros. I've made a note to change this to :08x and re-run the script at a future date, that should make all of the CRC32 data 8 characters long 👍

180 of the 225 MD thumbnail errors are fixed in the GB300 (I'm suprised by the fact that this is exactly 80%, is your list actually correct?)

It is indeed correct! The format of the .zxx files is specific and well-known - it should be the raw binary data of an RGB565 image (the thumbnail), followed immediately by an obfuscated ZIP file containing the ROM. The SF2000's OS is hard-coded to expect a thumbnail that is 144 pixels wide and 208 pixels tall in RGB565 format - that's 29,952 pixels total, with each pixel represented by 2 bytes in the RGB565 data, giving a total image size of 59,904 bytes. This gives the offset for the start of the ZIP data a very specific location within a well-formed .zxx file; so if the ZIP data doesn't start at that location, then the thumbnail data is definitely malformed. The Python script I wrote checks the offset of the ZIP data within the file, and reports if it's later or earlier in the file than expected (i.e., if the thumbnail data is over- or under-sized) - so yes, all those MD ROMs in the stock SF2000 image do indeed have incorrect thumbnail data. Most of them have the correct dimensions, but use BGRA instead of RGB565... they just really messed up the creation of their MD ROMs for the SF2000 🤷

I suspect Data Frog (or the contractors that built their firmware for them) knew that this was likely to happen; from what I hear, the code to actually read ROMs from the obfuscated ZIPs inside the .zxx files searches for the obfuscated ZIP header from the end of the file backwards - so the OS should deal with .zxx files properly no matter how borked the thumbnail data within them is.

You might want to check SF2000's recent firmware if all 225 are still broken.

The ROM set in the official images provided by Data Frog (as hosted on their very slow file server) never changed* between the initial mid-March image that shipped with the first units received, and the 1.71 image (the last one they officially released). It's possible other vendors of the hardware put different ROM sets on the devices they sold - but the official Data Frog images never changed their ROM sets for the SF2000.

(*I say "never changed"; there were two tiny changes between 1.5 and 1.7.1. First, a save file for "Pokemon - Emerald Version" was accidentally left in the GBA folder for 1.7.1; and secondly, the CRC32 for "cthd2003.zip" in the arcade BIN folder changed, although the CRC32s of the files contained within that ZIP file remained identical, so it appears to just have been metadata changes within the ZIP file itself, not impacting its contents.)

There are still 45 issues in the GB300. Funnily, it applies to mostly sports simulations. The following files are still bugged in the GB300 because they are indeed RGBA8888 [...] All SF ROMs are different in the GB300. However, files that were duplicates in your list are still duplicates in the GB300.

That's interesting - some someone somewhere along the manufacturing or supply chain decided to fix things up a bit! I'm amazed to be honest that given all of the different manufacturers of retro emulation devices, with all of the random ROM sets they supply with their devices, that they never banded together and just used their own shared pool of known good ROMs. I mean, it's not that hard to find verified complete ROM collections online!

Final Knockout is fixed. You might want to check SF2000's recent firmware.

Alas no; the copy of Final Knockout.zsf included in the 1.7.1 firmware image is identical to the copy included with 1.5, the firmware version the HTML and CSV data was generated against. As I say, interesting that fixes made it in to images for other "frog family" devices that never made it back to the SF2000!

The GB300 lacks some games. This causes Tadpole to break it, except for the GBA section, which is identical.

I have nothing to do with Tadpole's development; but there was a mention in the Tadpole development thread in the Retro Handhelds Discord server that some development work had started on adding proper support for the GB300's ROM lists. That was back in January though, and there've been no updates since then - you might want to hop into that Discord server, and go into the Tadpole Development thread within the data_frog_sf2000 channel, and chat with the devs directly 👍

I'll leave this issue open, and will mark it as closed whenever I update the stock ROMs HTML and CSV data with the eight-character CRC32 data.

nummacway commented 5 months ago

Thank you for much for your extensive answer.

I've got one more question: Why is PCE missing from the ROM list? I checked the first 35 files' CRC32s (take from the ZIP header) in No-Intro and they all matched. Even the filenames exactly matched the No-Intro name, just without the stuff in brackets (region, Wii Virtual Console flag, version).

Since then, many other devices have joined the "frog family" - devices that appear to use very similar hardware and software, but with various tweaks; the DY12, the DY14, the DY19, the Q19, the Y2, the SG800, the SF900, the 8BitKing, and of course, the GB300.

Didn't know there we so many. Just after writing my post, I stumbled upon the 8BitKing (the one without the display) and was surprised that while it does seem to have a TF slot, it can only run SF, PCE, GB and GBC. But it's already strange that the GB300 lacks the arcade section. Comparing the ones you named and the ones I found myself now, the GB300 and SF2000 seem to be the best value for money. I just wanted one that can be customized in some way and plays GBA.

However, as you point out, there does seem to be some interesting differences between the stock image for the GB300 vs. the stock image for the SF2000 - not only the ROM differences you pointed out, but also (I believe) they changed the fake names of all of the resources files. Hopefully someone out there might have the same drive and determination I had for the SF2000, and will put together an information resource catered to the GB300 - maybe yourself? It seems like you've already generated some great data about the GB300's ROM set! All I can tell you is that it won't be me.

Interesting. I just checked snbqj.uby because the GB300 does not support German and the file was way too big for a few strings. Result: RGB565, 640x480. Showing Blue UI, TV setup with PAL selected. BTW there is only one font file on the GB300.

So yeah, I could do a lot of documentation about the GB300. But I'm not sure if there's actually a need for a separate document. Given that Resources files seem to be different, maybe there is a need. I can also create tools for doing stuff like Tadpole does, but they'd likely be Windows-only then. Maybe it's a good idea to ask on Discord.

I'm also hoping someone out there will feel the urge to document the current multicore builds - adcockm has put together a really excellent read-me which is included with the official releases, but I see questions almost daily on Discord asking about how to add ROMs, how to get the dynarec gpSP core working, etc., so some additional documentation that folks could be pointed to would probably be valuable. Again though, won't be me - I feel I've done my bit already 😅

First of all, I'm hoping multicore will come to GB300.

Indeed! As is probably obvious, the HTML and CSV data I have for the stock ROM set was machine generated, not hand-written. I wrote a Python script to go through all of the .zxx files in the stock image, and pull out all of the interesting data from them. The Thumbnail data too long (possibly BGRA instead of RGB565); thumbnail display likely corrupt, game may not load message is presented when the thumbnail data in the .zxx file is too long (more about that in another reply below); this is usually because whoever put the ROM set together used BGRA images instead of RGB565, but not always - hence my use of the word possibly in the message 😃

It is indeed correct! The format of the .zxx files is specific and well-known - it should be the raw binary data of an RGB565 image (the thumbnail), followed immediately by an obfuscated ZIP file containing the ROM. The SF2000's OS is hard-coded to expect a thumbnail that is 144 pixels wide and 208 pixels tall in RGB565 format - that's 29,952 pixels total, with each pixel represented by 2 bytes in the RGB565 data, giving a total image size of 59,904 bytes. This gives the offset for the start of the ZIP data a very specific location within a well-formed .zxx file; so if the ZIP data doesn't start at that location, then the thumbnail data is definitely malformed. The Python script I wrote checks the offset of the ZIP data within the file, and reports if it's later or earlier in the file than expected (i.e., if the thumbnail data is over- or under-sized) - so yes, all those MD ROMs in the stock SF2000 image do indeed have incorrect thumbnail data. Most of them have the correct dimensions, but use BGRA instead of RGB565... they just really messed up the creation of their MD ROMs for the SF2000 🤷

On GB300, all the 45 broken MD thumbnails are 144x208, just RGBA. Glazed is the only one with a different resolution. They still work, though.

The ROM set in the official images provided by Data Frog (as hosted on their very slow file server) never changed* between the initial mid-March image that shipped with the first units received, and the 1.71 image (the last one they officially released). It's possible other vendors of the hardware put different ROM sets on the devices they sold - but the official Data Frog images never changed their ROM sets for the SF2000.

Okay. It's really strange to me that the SF2000 seems to be the better version of the GB300, but fixes made for the GB300 didn't make it to the SF2000. I wonder who made the GB300.

That's interesting - some someone somewhere along the manufacturing or supply chain decided to fix things up a bit! I'm amazed to be honest that given all of the different manufacturers of retro emulation devices, with all of the random ROM sets they supply with their devices, that they never banded together and just used their own shared pool of known good ROMs. I mean, it's not that hard to find verified complete ROM collections online!

Was there anything about the SF files that they actually needed to fix? Because now the ROMs mismatch against No-Intro.

I checked why myself now with a few examples (King's Quest V, Ninja Turtles 2 and 3), and they are only header changes ranging from 0x06 to 0x0F (starting from 0x00). 0x07 to 0x0F are zeroed. Only King's Quest also changes 0x06 from 0x40 (the same as in the other two) to 0x43. Maybe I should try to get the SF2000 firmware. I can use my server which has plenty of time and no 24-hour disconnect.

vonmillhausen commented 5 months ago

You're very welcome!

I've got one more question: Why is PCE missing from the ROM list?

The SF2000 stock firmware has no support for PC Engine - that was something that was only added to multicore. The "seven simulators" (their marketing term) supported by the stock SF2000 are GB, GBC, GBA, NES, SNES, MD and arcade - no PC Engine. The only stuff I didn't include in my stock ROM list data sheets is arcade; that stuff can be so messy in terms of ROM set versions, and also adcockm had already done incredible work detailing the arcade stuff specifically, I didn't see a need to repeat their work.

I checked the first 35 files' CRC32s (take from the ZIP header) in No-Intro and they all matched. Even the filenames exactly matched the No-Intro name, just without the stuff in brackets (region, Wii Virtual Console flag, version).

Sounds like a bit more care and attention was put into the ROM changes for the GB300 than was for the original SF2000 set!

Didn't know there we so many. Just after writing my post, I stumbled upon the 8BitKing (the one without the display) and was surprised that while it does seem to have a TF slot, it can only run SF, PCE, GB and GBC. But it's already strange that the GB300 lacks the arcade section. Comparing the ones you named and the ones I found myself now, the GB300 and SF2000 seem to be the best value for money. I just wanted one that can be customized in some way and plays GBA.

Yeah, there's a whole bunch of them! I haven't really looked into it, as it's just not my cup of tea, but I believe some of the TV sticks that run variations of the frog family firmware might have better hardware internals? There's a thread in the Retro Handhelds Discord that's dedicated to the sticks... I'm happy enough with my original froggy 😄

Interesting. I just checked snbqj.uby because the GB300 does not support German and the file was way too big for a few strings. Result: RGB565, 640x480. Showing Blue UI, TV setup with PAL selected. BTW there is only one font file on the GB300.

There you go then! I had indeed heard that they'd mixed up all the names again on the GB300 firmware - the same names, but just used for different files. I guess that's your proof! I guess theoretically someone could put together a mapping of SF2000 <-> GB300 file names, that could be used to do things like help convert themes between the devices, etc. - although I suspect in the long-run, just having a common firmware that works on the two devices would be the way to go. My understanding is the stumbling block there is the different display panel and controls - the firmware is hard-coded to talk to the specific hardware that's supposed to exist.

So yeah, I could do a lot of documentation about the GB300. But I'm not sure if there's actually a need for a separate document. Given that Resources files seem to be different, maybe there is a need. I can also create tools for doing stuff like Tadpole does, but they'd likely be Windows-only then. Maybe it's a good idea to ask on Discord.

I would say absolutely check out the Retro Handhelds Discord server; that's where a lot of the dev talk for these devices happens. If anything cool for the GB300 happens in the future, it's highly likely to be talked about there first. Specifically check out the threads in the data_frog_sf2000 channel!

On GB300, all the 45 broken MD thumbnails are 144x208, just RGBA. Glazed is the only one with a different resolution. They still work, though.

Oh well, at least they fixed some of them! 😅

Okay. It's really strange to me that the SF2000 seems to be the better version of the GB300, but fixes made for the GB300 didn't make it to the SF2000. I wonder who made the GB300.

"Better" is in the eye of the beholder; or in this case, the hands. I think the most important difference between the two devices is form-factor - horizontal vs. vertical - as that has the greatest impact on comfort actually using the device. Some folks prefer one, some folks prefer the other. Only after that should you consider things like the display, the controls, etc.. If your GB300 makes you happy, and if you use it to play games, then you made the right choice for you!

And yes, it's fascinating to see the little changes that go on between all the frog family devices. There was some communication directly with Data Frog themselves, and their rep said that the firmware on the SF2000 is made for them by an external contractor - so presumably this external contractor is the one that actually owns the firmware, and creates builds for whatever hardware vendors like Data Frog put out. I don't believe the details of that contractor have ever been publicly announced, and I don't suspect they ever will. It's even hard enough to work out some times who the original hardware manufacturer is!

Was there anything about the SF files that they actually needed to fix? Because now the ROMs mismatch against No-Intro.

Well, there's the ones with broken thumbnails for a start. Plus there's plenty of ROMs in the default SF2000 collection that don't match any good known dump (according to No-Intro), so who knows if they're hacked or corrupt in some way, etc.. Plus Final Knockout.zsf is just plain broken. Beyond that, not all of the SNES or GBA games they included actually play well on the hardware - they could "fix" that by testing the games they put on, and removing those that don't play at decent frame rates or with sound issues. There's always ways these things could be improved! (Ideally, they wouldn't come with ROMs at all - but alas, the firmware's game lists are hard-coded and the stock ROMs are required to make the categories function, regardless of what the manual says!)

Maybe I should try to get the SF2000 firmware. I can use my server which has plenty of time and no 24-hour disconnect.

In my own painful experience, a lot of time the connection is just dropped from the Data Frog side... and they use a temporary UUID with each download, so resuming stops working after a while. Good luck to you though, with perseverance it is possible to get the files downloaded from them!

nummacway commented 5 months ago

You're very welcome!

I've got one more question: Why is PCE missing from the ROM list?

The SF2000 stock firmware has no support for PC Engine - that was something that was only added to multicore. The "seven simulators" (their marketing term) supported by the stock SF2000 are GB, GBC, GBA, NES, SNES, MD and arcade - no PC Engine.

Oh, I didn't know the GB300 could do anything the SF2000 can't do (stock-firmware-wise).

I would say absolutely check out the Retro Handhelds Discord server; that's where a lot of the dev talk for these devices happens.

I think I'll ask there.

Okay. It's really strange to me that the SF2000 seems to be the better version of the GB300, but fixes made for the GB300 didn't make it to the SF2000. I wonder who made the GB300.

"Better" is in the eye of the beholder; or in this case, the hands.

I can understand you. My hands hurt a bit after an hour of smashing the A button in Pokémon Ruby. And the GB300 isn't that much different from my GBC which worked better back in the days.

Was there anything about the SF files that they actually needed to fix? Because now the ROMs mismatch against No-Intro.

Well, there's the ones with broken thumbnails for a start. Plus there's plenty of ROMs in the default SF2000 collection that don't match any good known dump (according to No-Intro), so who knows if they're hacked or corrupt in some way, etc.. Plus Final Knockout.zsf is just plain broken. Beyond that, not all of the SNES or GBA games they included actually play well on the hardware - they could "fix" that by testing the games they put on, and removing those that don't play at decent frame rates or with sound issues. There's always ways these things could be improved! (Ideally, they wouldn't come with ROMs at all - but alas, the firmware's game lists are hard-coded and the stock ROMs are required to make the categories function, regardless of what the manual says!)

I noticed that with Advance Wars. The American version works okay (AW1) to quite okay (AW2, included with Chinese main menu), especially if there is no dialogue. The European ones just suck. Even though the American AW2 works better than the American AW1, the European AW2 is even worse than the European AW1 (included) which is already very bad. So they could have included both American versions and it would at least be playable. I wonder why the European versions perform so badly, because these games are really simple and I don't think there's a PAL and NTSC version of the GBA, as it's an isolated device not to be connected to anything. The European AW games don't get better on TV, no matter if you choose PAL or NTSC. Charging the GB300 does not affect the Composite signal and I believe the output is in native 640x480, which is why the images are bigger than needed for the internal display. I that possible? Plugging in the cable during bootup led to a frozen menu though.

I believe all GBA games that feature "3D" don't really work. Of the five Need for Speed titles, only Porsche and Underground 2 even get past the language selection.

I wonder why they removed the international Pokémon games in the GB300's GBC section and never included the international GBA games.

Maybe I should try to get the SF2000 firmware. I can use my server which has plenty of time and no 24-hour disconnect.

In my own painful experience, a lot of time the connection is just dropped from the Data Frog side... and they use a temporary UUID with each download, so resuming stops working after a while. Good luck to you though, with perseverance it is possible to get the files downloaded from them!

Oh yeah, I noticed that. It worked relatively fast during in the European morning, but then stopped very close to the end, with no way to continue. Maybe all people re-downloading is a reason why it's so slow! 🤣

nummacway commented 5 months ago

So I published this: https://nummacway.github.io/gb300/

vonmillhausen commented 5 months ago

Oh, I didn't know the GB300 could do anything the SF2000 can't do (stock-firmware-wise).

Yeah, they're a little different - but as far as I'm aware, it's mostly just a software thing. CPU and memory are the same, as far as I know - just the display panel, lack of "analog" stick, and I believe the GB300 doesn't have the little antenna for wireless controller support? I could be wrong on that last bit!

I can understand you. My hands hurt a bit after an hour of smashing the A button in Pokémon Ruby. And the GB300 isn't that much different from my GBC which worked better back in the days.

The SF2000 was my first horizontal handheld, and I have to say, it's one of the most comfortable I own!

I noticed that with Advance Wars. The American version [...] I wonder why the European versions perform so badly [...]

That's interesting! On the SF2000, quite a few of the ROMs that have both US and European releases have the European version included on the device, and testing showed that many times, the European version works better with the stock emulator versions. For example, the device includes the European version of Mario Kart for SNES, which runs (albeit a bit slowly); the US version of the game has terrible graphical corruption once you get to a race, and then freezes.

no matter if you choose PAL or NTSC

I think that might just alter the video signal output by the device - I don't think it alters emulation speed at all. I tested my SF2000 with a PAL CRT, and got proper colour video output under PAL mode, and only greyscale under NTSC... that's what usually happens with an NTSC signal on that particular CRT.

Charging the GB300 does not affect the Composite signal

That might vary from device to device - or maybe it's something the GB300 fixes. My SF2000's video out gets very noisy when you try charging at the same time.

I believe the output is in native 640x480, which is why the images are bigger than needed for the internal display. I that possible?

That's certainly the case on the SF2000 - the device's OS runs at 640x480 internally, even when outputting to the internal 320x240 display panel - it's why the stock image assets all feature aliasing on the internal display compared to the actual full-sized art assets. The SF2000 outputs a 576i video signal - at least, that's what the capture card I connected mine to picked it up as. Lots of folks report that the outer edge all the way around is cropped off when using the A/V out, and that's what I saw too on the CRT I mentioned above, and on an LCD TV I have here. Only the cheap capture card I have got the full video signal correct, without cropping.

I believe all GBA games that feature "3D" don't really work. Of the five Need for Speed titles, only Porsche and Underground 2 even get past the language selection.

Yeah, the stock version of gpSP doesn't have dynarec enabled, and the CPU just isn't up to the task of running the heavier titles properly. Some problems are also caused by the stock SF2000 firmware not being able to find a legitimate GBA BIOS, despite it being on the card - you can read more about that here. I don't know if it's the same on the GB300 or not!

I wonder why they removed the international Pokémon games in the GB300's GBC section and never included the international GBA games.

Maybe the fear of Big N is starting to reach the Chinese pirates too 🤣

Oh yeah, I noticed that. It worked relatively fast during in the European morning, but then stopped very close to the end, with no way to continue. Maybe all people re-downloading is a reason why it's so slow! 🤣

Maybe! I know it took me many, many tries to get stuff finally downloaded from them... so good luck to you if you're still trying yourself! 🍀

So I published this: https://nummacway.github.io/gb300/

Fair play! I've added a link to it in the update I made today 👍

nummacway commented 5 months ago

First, one more thing: Do you think a web-based tool for extracting the screenshot from a save state makes sense? So people can take screenshots by abusing the save states.

Oh, I didn't know the GB300 could do anything the SF2000 can't do (stock-firmware-wise).

Yeah, they're a little different - but as far as I'm aware, it's mostly just a software thing. CPU and memory are the same, as far as I know - just the display panel, lack of "analog" stick, and I believe the GB300 doesn't have the little antenna for wireless controller support? I could be wrong on that last bit!

Dunno. I'm yet to open the GB300.

I can understand you. My hands hurt a bit after an hour of smashing the A button in Pokémon Ruby. And the GB300 isn't that much different from my GBC which worked better back in the days.

The SF2000 was my first horizontal handheld, and I have to say, it's one of the most comfortable I own!

I noticed that with Advance Wars. The American version [...] I wonder why the European versions perform so badly [...]

That's interesting! On the SF2000, quite a few of the ROMs that have both US and European releases have the European version included on the device, and testing showed that many times, the European version works better with the stock emulator versions. For example, the device includes the European version of Mario Kart for SNES, which runs (albeit a bit slowly); the US version of the game has terrible graphical corruption once you get to a race, and then freezes.

At least they are different PAL/NTSC versions, so they are technically different. But for Advance Wars, I don't get it. But yeah, we probably won't know.

no matter if you choose PAL or NTSC

I think that might just alter the video signal output by the device - I don't think it alters emulation speed at all. I tested my SF2000 with a PAL CRT, and got proper colour video output under PAL mode, and only greyscale under NTSC... that's what usually happens with an NTSC signal on that particular CRT.

I think I missunderstod your "A/V Output" section here. I thought it impacted the actual performance, but it's just the output, right?

I believe the output is in native 640x480, which is why the images are bigger than needed for the internal display. I that possible?

That's certainly the case on the SF2000 - the device's OS runs at 640x480 internally, even when outputting to the internal 320x240 display panel - it's why the stock image assets all feature aliasing on the internal display compared to the actual full-sized art assets. The SF2000 outputs a 576i video signal - at least, that's what the capture card I connected mine to picked it up as. Lots of folks report that the outer edge all the way around is cropped off when using the A/V out, and that's what I saw too on the CRT I mentioned above, and on an LCD TV I have here. Only the cheap capture card I have got the full video signal correct, without cropping.

On the small screen (800x480px, 5", 16:9) I bought from AliExpress 10 years ago (I think my first or second purchase there ever), NTSC is noticably more clipped than PAL.

But an NTSC signal cannot be 576i I think, because NTSC is supposed to always be an M-standard signal which is limited to 525 rows (480 of which are visible). So if it's really 576i, older NTSC TVs shouldn't be able to deal with it. And your PAL TV will think: "Oh, it's just 576 visible rows like my PAL signal! I can do that."

I believe all GBA games that feature "3D" don't really work. Of the five Need for Speed titles, only Porsche and Underground 2 even get past the language selection.

Yeah, the stock version of gpSP doesn't have dynarec enabled, and the CPU just isn't up to the task of running the heavier titles properly. Some problems are also caused by the stock SF2000 firmware not being able to find a legitimate GBA BIOS, despite it being on the card - you can read more about that here. I don't know if it's the same on the GB300 or not!

I tested The Minish Cap and the main menu did not work on the GB300 by default. Copying that file (which is in the same location) fixes it. But it does not improve the performance of Advance Wars. I need to get this into my document, because that's important even though it's not a difference.

Oh yeah, I noticed that. It worked relatively fast during in the European morning, but then stopped very close to the end, with no way to continue. Maybe all people re-downloading is a reason why it's so slow! 🤣

Maybe! I know it took me many, many tries to get stuff finally downloaded from them... so good luck to you if you're still trying yourself! 🍀

I was able to download that file - during the European evening.

So I published this: https://nummacway.github.io/gb300/

Fair play! I've added a link to it in the update I made today 👍

Thanks! I'm happy people on Discord liked it too.

vonmillhausen commented 5 months ago

First, one more thing: Do you think a web-based tool for extracting the screenshot from a save state makes sense? So people can take screenshots by abusing the save states.

I actually already made something like that for the SF2000, you can find it here. It was written to allow for experimenting with SF2000 save-state data; when you give it a save-state, it gives you the screenshot and the internal (zipped) state data. Ultimately it never really proved useful, as save-states created on the device are architecture dependent, and so would only ever work on other MIPS devices... but it does at least provide access to the screenshots!

Dunno. I'm yet to open the GB300.

There's probably tear-down videos or screenshots online if you look around.

I think I missunderstod your "A/V Output" section here. I thought it impacted the actual performance, but it's just the output, right?

To the best of my knowledge, the PAL/NTSC output switch in the device's menu only impacts the A/V signal being sent from the output jack, and doesn't alter emulation performance at all. At least, the testing I did with my SF2000 on my PAL CRT, there was zero difference (other than the usual NTSC compatibility stuff) between either when testing US and EU versions of games for SNES and MD - the games themselves behaved exactly as they always did on the internal display of the device, it was just the output video signal that changed.

But an NTSC signal cannot be 576i I think, because NTSC is supposed to always be an M-standard signal which is limited to 525 rows (480 of which are visible). So if it's really 576i, older NTSC TVs shouldn't be able to deal with it. And your PAL TV will think: "Oh, it's just 576 visible rows like my PAL signal! I can do that."

TV stuff isn't my strong suit, so you could well be right. It's been so long now since I did my testing, it's possible it only worked with my capture card when in PAL mode (it was one of those super-cheap "easycap" devices, and is super picky about what you feed it).

I tested The Minish Cap and the main menu did not work on the GB300 by default. Copying that file (which is in the same location) fixes it. But it does not improve the performance of Advance Wars.

Sounds about the same as with the SF2000 - the BIOS was important for Minish Cap, but didn't seem to fix other games that had issues (either performance related, or that locked up like "Harvest Moon: (More) Friends of Mineral Town", which freezes after you enter all of your character data at the start of the game (there was a workaround for this one, which involved making an in-game save on a different device after starting the game, and then loading that save on the SF2000).

I was able to download that file - during the European evening.

Excellent! Enjoy doing ROMset science on it! 🧑‍🔬

nummacway commented 5 months ago

Thanks. Do you happen to have a stock GBA rom that requires the BIOS?

I added key mapping info to my document. Do you want to update your editor? Note that you cannot really request GB300 users to upload that file - they don't initially have it. They must assign a non-standard key first.

vonmillhausen commented 5 months ago

Thanks. Do you happen to have a stock GBA rom that requires the BIOS?

I don't; I know Minish Cap doesn't work properly without it, but that wasn't one of the stock ROMs. I know Friends of Mineral Town wasn't fixed when the BIOS path was corrected, so its issues aren't (entirely) tied to the BIOS. I know there was some homebrew ROMs that didn't run properly without the official BIOS, and did afterwards, but those aren't stock obviously.

I added key mapping info to my document. Do you want to update your editor? Note that you cannot really request GB300 users to upload that file - they don't initially have it. They must assign a non-standard key first.

I don't, to be honest with you - I don't have a GB300 for testing, and as I said before, my interest lies solely with the SF2000. However, like all of my other tools, my key-mapping tool is public domain - so if you'd like to make a GB300-specific key mapping tool, by all means feel free to take mine and modify it as you see fit! If you check the source, you'll see I included a lot of comments to help folks understand what's going on in case they wanted to build something else using it - open source for the win! 🎉

nummacway commented 5 months ago

Didn't know your save game tool already did that. I only used it the other way around (with no success of course). Thank you.

I will create my own tools. For that, I did a lot more research. Two results are different from what you say on your page, but should apply to the SF2000:

Not sure if all of this applies to the SF2000, but I don't know why it shouldn't.

Said NES saves: save.zip