Mirrors/sf2000
2
0
Fork 0
mirror of https://github.com/vonmillhausen/sf2000.git synced 2024-11-03 08:35:12 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update README.md

Browse Source 
Moved most of the intro section under the "Is this thing any good?" FAQ, and slightly reworded parts of it. Fixed a few typos.
This commit is contained in:
vonmillhausen 2023-07-19 11:31:20 +01:00
parent 44efbf903f
commit 33ddbf1732
1 changed files with 14 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
README.md
View File

@ -1,11 +1,7 @@
# SF2000 # SF2000
The SF2000 is a cheap hand-held emulation gaming console which was released in early 2023. Although the device itself is sold by a variety of vendors, it was the vendor "Data Frog" who caught public attention, and so the device is often simply referred to as "the Data Frog". The SF2000 is a cheap hand-held emulation gaming console which was released in early 2023. Although the device itself is sold by a variety of vendors, it was the vendor "Data Frog" who caught public attention, and so the device is often simply referred to as "the Data Frog".
For a cheap device, it's actually fairly capable - most Game Boy, Game Boy Color, NES and Genesis/Mega Drive games play at full speed, and many arcade, Game Boy Advance and SNES titles do as well. The device has an IPS panel (not OCA laminated), and a user-replaceable "18650" battery, which can be charged via a USB-C port on the device. It also has analog A/V out (note: not HDMI), meaning it can be connected to a CRT TV - the type of display most arcade, Genesis/Mega Drive and SNES games were originally intended to be displayed on. It has a built-in 2.4GHz antenna, and can receive input from a compatible wireless controller (usually sold separately). This document is a collection of notes and information I've made about the device.
Some downsides to the device: it's mono only, there's no headphone jack (although there is a volume wheel), screen brightness cannot be altered (it's fairly bright), SNES and Game Boy Advance are hit-or-miss in terms of performance (some games are fine, many games run slowly), the stock firmware is closed-source so the device's performance may never get any better than as-shipped, and some folks have had issues with the buttons (they're quite cheap, and sit flush when pressed).
So is the "Data Frog" any good? Only you can answer that question for yourself. There are certainly more powerful devices out there, more fully featured devices, devices with better hardware, etc. - but almost all of those devices cost a lot more than the SF2000. At the end of the day, you have to look at the features offered at the given price-point, and only then can you decide if you're interested in the device or not.
--- ---
@ -65,7 +61,11 @@ So is the "Data Frog" any good? Only you can answer that question for yourself.
## FAQ (Frequently Asked Questions) ## FAQ (Frequently Asked Questions)
### Is this thing any good? ### Is this thing any good?
[Read my introductory section above :)](#sf2000) For a cheap device, it's actually fairly capable - most Game Boy, Game Boy Color, NES and Genesis/Mega Drive games play at full speed, and many arcade, Game Boy Advance and SNES titles do as well. The device has an IPS panel (not OCA laminated), and a user-replaceable 18650 battery, which can be charged via a USB-C port on the device. It also has analog A/V out (note: not HDMI), meaning it can be connected to a CRT TV - the type of display most arcade, Genesis/Mega Drive and SNES games were originally intended to be displayed on. It has a built-in 2.4GHz antenna, and can receive input from a compatible wireless controller (usually sold separately).
Some downsides to the device: it's mono only (you only get the left-channel audio), there's no headphone jack (although there is a volume wheel), screen brightness cannot be altered (it's fairly bright), SNES and Game Boy Advance are hit-or-miss in terms of performance (some games are fine, many games run unplayably slowly), the stock firmware is closed-source so the device's performance may never get any better than as-shipped, and some folks have had issues with the buttons (quality control is hit-or-miss, and some folks have had terrible button response, such as a d-pad that can't do diagonals reliably, or ABXY buttons that sit flush with or even go under the case).
So is the "Data Frog" any good? Only you can answer that question for yourself. There are certainly more powerful devices out there, more fully featured devices, devices with better hardware, etc. - but almost all of those devices cost a lot more than the SF2000. At the end of the day, you have to look at the features offered at the given price-point, and only then can you decide if you're interested in the device or not.
### Is there any custom firmware? ### Is there any custom firmware?
As of July 18th 2023, **no**, not yet. However efforts are underway; an SDK for the CPU has been identified, and custom firmware is now in the very early stages of development. Most recently, a limited build of Retroarch has been demonstrated to run, with a single core (TGBDual, the same Game Boy/Game Boy Color emulator included in the stock firmware) capable of loading ROM content. Video and audio drivers for Retroarch are at very early stages of development and are therefore not optimised, and much audio "crackling" is present; additionally, performance issues have been hinted at (game runs much faster when the audio subsystem is not engaged). As of July 18th 2023, **no**, not yet. However efforts are underway; an SDK for the CPU has been identified, and custom firmware is now in the very early stages of development. Most recently, a limited build of Retroarch has been demonstrated to run, with a single core (TGBDual, the same Game Boy/Game Boy Color emulator included in the stock firmware) capable of loading ROM content. Video and audio drivers for Retroarch are at very early stages of development and are therefore not optimised, and much audio "crackling" is present; additionally, performance issues have been hinted at (game runs much faster when the audio subsystem is not engaged).
@ -202,7 +202,7 @@ Emulator is TGB Dual v0.8.3 (Git commit [`9be31d3`](https://github.com/libretro/
### Game Boy Advance ### Game Boy Advance
Emulator is gpSP v0.91 (Git commit [`261b2db`](https://github.com/libretro/gpsp/commit/261b2db)). Performance is fairly poor. On the original firmware, A and B buttons are mapped correctly, but the GBA shoulder buttons are mapped to X and Y for some reason. See "[Button Mappings/Key Bindings](#button-mappingskey-bindings)" section below. Emulator is gpSP v0.91 (Git commit [`261b2db`](https://github.com/libretro/gpsp/commit/261b2db)). Performance is fairly poor. On the original firmware, A and B buttons are mapped correctly, but the GBA shoulder buttons are mapped to X and Y for some reason. See "[Button Mappings/Key Bindings](#button-mappingskey-bindings)" section below.
While the SF2000 does include a copy of the real GBA BIOS file in the `bios` folder, there's a bug in the `05.22` firmware (and possibly earlier firmwares) that prevents that BIOS from ever actually being loaded. As such, gpSP _always_ falls back to the built-in "NORMMATT" BIOS instead (a reverse-engineered BIOS that is not identical to Nintendo's one). This has been noted to have some compatibility issues - for example, the main menu on "The Legend of Zelda - The Minish Cap" is broken on a stock SF2000 using the `05.22` firmware due to the NORMATT BIOS. You can correct for this bug by copying the `gba_bios.bin` file from the `bios` folder to the two following locations (create any folders as needed - and credit to `bnister` for the finding!): While the SF2000 does include a copy of the real GBA BIOS file in the `bios` folder, there's a bug in the `05.22` firmware (and possibly earlier firmwares) that prevents that BIOS from ever actually being loaded. As such, gpSP _always_ falls back to the built-in "NORMMATT" BIOS instead (a reverse-engineered BIOS that is not identical to Nintendo's one). This has been noted to have some compatibility issues - for example, the main menu on "The Legend of Zelda - The Minish Cap" is broken on a stock SF2000 using the `05.22` firmware due to the NORMMATT BIOS. You can correct for this bug by copying the `gba_bios.bin` file from the `bios` folder to the two following locations (create any folders as needed - and credit to `bnister` for the finding!):
- `GBA/mnt/sda1/bios/gba_bios.bin` (this fixes it for the main GBA game list) - `GBA/mnt/sda1/bios/gba_bios.bin` (this fixes it for the main GBA game list)
- `ROMS/mnt/sda1/bios/gba_bios.bin` (this fixes it for GBA games added to the user `ROMS` folder) - `ROMS/mnt/sda1/bios/gba_bios.bin` (this fixes it for GBA games added to the user `ROMS` folder)
@ -225,7 +225,7 @@ If you want to mess around with SF2000 save states, you can [do so using my SF20
### Default ROMs ### Default ROMs
The default full firmware for the SF2000 comes with over 6000 ROMs across the seven supported systems. The manual suggests these are for "demonstration purposes" only, and should be deleted by the owner (with any failure to do so not being their responsibility) - despite the fact that the SF2000's menus are hard-coded for this specific list of ROMs. The ROM files themselves are a custom bundle format; the first `59,904 bytes` are an RGB565 image shown as a thumbnail beside the game when selected in a game-list, and the remainder of the file is a slightly mangled/obfuscated ZIP file containing the game's single ROM file. The only exception to this format are the arcade ROMs, which consist of a plain-old Final Burn Alpha ROM zip file, coupled with a `.zfb` file containing the thumbnail image and a pointer to the ROM zip file name. The default full firmware for the SF2000 comes with over 6000 ROMs across the seven supported systems. The manual suggests these are for "demonstration purposes" only, and should be deleted by the owner (with any failure to do so not being their responsibility) - despite the fact that the SF2000's menus are hard-coded for this specific list of ROMs. The ROM files themselves are a custom bundle format; the first `59,904 bytes` are an RGB565 image shown as a thumbnail beside the game when selected in a game-list, and the remainder of the file is a slightly mangled/obfuscated ZIP file containing the game's single ROM file. The only exception to this format are the arcade ROMs, which consist of a plain-old Final Burn Alpha ROM zip file, coupled with a `.zfb` file containing the thumbnail image and a pointer to the ROM zip file name.
I was curious to see how the included ROMs matched up against the current "[No-Intro](https://no-intro.org/)" catalogue for each of the non-arcade systems, so I wrote a small script to extract the ROMs from the SF2000's bundles (`05.22` firmware), and compare the hashes against the current (June 9th, 2023) set of No-Intro DAT files. You can [find a big HTML file with all of the results here](/defaultRoms/defaultRomsNoIntroCheck.htm), and [a raw CSV file of the same data here](/defaultRoms/defaultRomsNoIntroCheck.csv). You can click most of the column headers in the HTML version to sort the table by that column. The NES ROMs had their first 16-bytes stripped to remove their "iNES" header (thanks for the tip, `bnister`!), and were compared against the "headerless" No-Intro NES dat file. I was curious to see how the included ROMs matched up against the current "[No-Intro](https://no-intro.org/)" catalogue for each of the non-arcade systems, so I wrote a small script to extract the ROMs from the SF2000's bundles (`05.22` firmware), and compare the hashes against the current (June 9th, 2023) set of No-Intro DAT files. You can [find a big HTML file with all of the results here](/defaultRoms/defaultRomsNoIntroCheck.htm), and [a raw CSV file of the same data here](/defaultRoms/defaultRomsNoIntroCheck.csv). You can click most of the column headers in the HTML version to sort the table by that column. The NES ROMs had their first 16-bytes stripped to remove their "iNES" header (thanks for the tip, `bnister`!), and were compared against the "header-less" No-Intro NES dat file.
--- ---
@ -527,7 +527,7 @@ If you want to do it using [Audacity](https://www.audacityteam.org/) , the steps
* Set "Project Sample Rate" to "22050 Hz" * Set "Project Sample Rate" to "22050 Hz"
* Click "OK" * Click "OK"
3. Click the "Select" button in the lower-left corner of your audio track area to select all the audio 3. Click the "Select" button in the lower-left corner of your audio track area to select all the audio
4. If your track is stereo, downmix to mono: "Tracks" menu > "Mix" > "Mix Stereo Down to Mono" 4. If your track is stereo, down-mix to mono: "Tracks" menu > "Mix" > "Mix Stereo Down to Mono"
5. "Tracks" menu > "Resample..." 5. "Tracks" menu > "Resample..."
* Set "New sample rate (Hz)" to "22050" * Set "New sample rate (Hz)" to "22050"
* Click "OK" * Click "OK"
@ -560,7 +560,7 @@ These are files that I have not yet determined what they do; if anyone has any i
| `kcnuv.lit` | ✨ | ✅ | ✅ | ✅ | UNKNOWN; a bunch of 4-byte binary chunks (e.g., `0xC4 0x00 0x00 0x00`), followed by a list of .NES ROM file names. Very similar to the `.bvs`/`.nec`/`.tax` files detailed above, but doesn't have the same type of "header" they have | | `kcnuv.lit` | ✨ | ✅ | ✅ | ✅ | UNKNOWN; a bunch of 4-byte binary chunks (e.g., `0xC4 0x00 0x00 0x00`), followed by a list of .NES ROM file names. Very similar to the `.bvs`/`.nec`/`.tax` files detailed above, but doesn't have the same type of "header" they have |
### Notes For Theme Creators ### Notes For Theme Creators
This section isn't really about the `Resources` files per-se, but it's tangentally related. The fact that the SF2000's UI resources are pulled from the microSD card opens up the door to "theming" the device, which is great. However, if you do decide you want to make a theme for the SF2000, here's a few things I've found that you may want to bear in mind: This section isn't really about the `Resources` files per-se, but it's tangentially related. The fact that the SF2000's UI resources are pulled from the microSD card opens up the door to "theming" the device, which is great. However, if you do decide you want to make a theme for the SF2000, here's a few things I've found that you may want to bear in mind:
- If you're including background music in your theme, note that when the SF2000 starts up it fails to output about the first 1 second of audio; therefore, if you'd like the person using your theme to hear your background music from the start, cut one second off the end of your background music loop, and move it to the start of the loop instead. - If you're including background music in your theme, note that when the SF2000 starts up it fails to output about the first 1 second of audio; therefore, if you'd like the person using your theme to hear your background music from the start, cut one second off the end of your background music loop, and move it to the start of the loop instead.
- If you're creating custom system logos (`sfcdr.cpl`), make sure the logos don't overlap the "Games Exist" image's screen area (`exaxz.hsp`, top-left coordinate `456, 88`, width and height `152, 72`); the main menu compositor clips an area of the section's _background_ image behind where the "Games Exist" artwork will be drawn, renders the "Games Exist" artwork into that clipped section, and then draws the result _on top_ of the system logo. As a result, any pixels of the system logo that should be visible in that area will be replaced by the background image, even if you make the "Games Exist" image fully transparent. Removing the `exaxz.hsp` file entirely doesn't work either, as you get garbage drawn on the screen in the same area instead. The only section not impacted by this is the "User ROMs and Settings" section, as on that screen the "Games Exist" artwork is not drawn. - If you're creating custom system logos (`sfcdr.cpl`), make sure the logos don't overlap the "Games Exist" image's screen area (`exaxz.hsp`, top-left coordinate `456, 88`, width and height `152, 72`); the main menu compositor clips an area of the section's _background_ image behind where the "Games Exist" artwork will be drawn, renders the "Games Exist" artwork into that clipped section, and then draws the result _on top_ of the system logo. As a result, any pixels of the system logo that should be visible in that area will be replaced by the background image, even if you make the "Games Exist" image fully transparent. Removing the `exaxz.hsp` file entirely doesn't work either, as you get garbage drawn on the screen in the same area instead. The only section not impacted by this is the "User ROMs and Settings" section, as on that screen the "Games Exist" artwork is not drawn.
@ -568,7 +568,7 @@ This section isn't really about the `Resources` files per-se, but it's tangental
- One _other_ workaround (that's even worse than the first workaround): bake just the portion of the system logo that overlaps with `exaxz.hsp` into the background. Doing it this way, you can still have your custom system logo in `sfcdr.cpl`, and still have it in the rotation animation (which gives the user something to look at, and reduces that fake "latency" feeling from the workaround above)... but you'll see the bit of logo baked into the background appear instantly, and then the rotating logo will slide up/down to meet it, so it'll still look a bit janky. So really it comes down to picking your particular flavour of jank: scaling your logos to avoid the `exaxz.hsp` screen area (which might leave you with a lot of empty space), baking your logo into the section background (adding fake "latency" to the experience), or only partially baking your logo into the section background (which will make things look jank during the rotation animation, but perfect otherwise)... the decision is yours! - One _other_ workaround (that's even worse than the first workaround): bake just the portion of the system logo that overlaps with `exaxz.hsp` into the background. Doing it this way, you can still have your custom system logo in `sfcdr.cpl`, and still have it in the rotation animation (which gives the user something to look at, and reduces that fake "latency" feeling from the workaround above)... but you'll see the bit of logo baked into the background appear instantly, and then the rotating logo will slide up/down to meet it, so it'll still look a bit janky. So really it comes down to picking your particular flavour of jank: scaling your logos to avoid the `exaxz.hsp` screen area (which might leave you with a lot of empty space), baking your logo into the section background (adding fake "latency" to the experience), or only partially baking your logo into the section background (which will make things look jank during the rotation animation, but perfect otherwise)... the decision is yours!
- When designing your theme, think carefully about the use case in which you want your theme to look best. Although the SF2000 uses many different UI images at many different scales, internally the screen area it draws to is `640 x 480` pixels in size. However, the actual physical display is only `320 x 240`; as the SF2000's OS does not do any image resampling when downscaling its UI output to the screen, what essentially happens is every second row and column of pixels is thrown away - and as a result, a theme designed for the internal `640 x 480` resolution can look a bit aliased or "jagged" on the internal display. If you want your theme to look pixel-perfect on the internal display, design it for `320 x 240` instead (i.e., for any image asset you create, design and create it at half of the original resolution of the same file in the stock SF2000 theme), and perform a nearest-neighbour upscale of the image back to the original resolution when converting it to an SF2000 data format. The resulting images will be pixel perfect on the internal display. _HOWEVER... there is one major downside to do thing this_: AV output. When using the AV output of the SF2000, it does so at 576i - higher than the resolution of the internal display. If you're using a theme that was scaled up from a `320 x 240` design base, you can clearly see pixelisation of the UI assets on the external display; a `640 x 480` based theme displays smooth assets. So what if you want to design a theme that looks decently sharp (not aliased) on the internal display, _and_ looks decently smooth on an external display, then design your theme for three-quarters resolution (`480 x 360` design base), and do a bilinear upscale to `640 x 480` based resolutions during final data conversion. To summarise: - When designing your theme, think carefully about the use case in which you want your theme to look best. Although the SF2000 uses many different UI images at many different scales, internally the screen area it draws to is `640 x 480` pixels in size. However, the actual physical display is only `320 x 240`; as the SF2000's OS does not do any image resampling when downscaling its UI output to the screen, what essentially happens is every second row and column of pixels is thrown away - and as a result, a theme designed for the internal `640 x 480` resolution can look a bit aliased or "jagged" on the internal display. If you want your theme to look pixel-perfect on the internal display, design it for `320 x 240` instead (i.e., for any image asset you create, design and create it at half of the original resolution of the same file in the stock SF2000 theme), and perform a nearest-neighbour upscale of the image back to the original resolution when converting it to an SF2000 data format. The resulting images will be pixel perfect on the internal display. _HOWEVER... there is one major downside to do thing this_: AV output. When using the AV output of the SF2000, it does so at 576i - higher than the resolution of the internal display. If you're using a theme that was scaled up from a `320 x 240` design base, you can clearly see pixelisation of the UI assets on the external display; a `640 x 480` based theme displays smooth assets. So what if you want to design a theme that looks decently sharp (not aliased) on the internal display, _and_ looks decently smooth on an external display, then design your theme for three-quarters resolution (`480 x 360` design base), and do a bilinear upscale to `640 x 480` based resolutions during final data conversion. To summarise:
- If you only care about how your theme looks on the internal display, and don't care about how it looks on AV output, design for a `320 x 240` base resolution and do a **nearest-neighbour** 2x upscale when converting to SF2000 formats - If you only care about how your theme looks on the internal display, and don't care about how it looks on AV output, design for a `320 x 240` base resolution and do a **nearest-neighbour** 2x upscale when converting to SF2000 formats
- If you only care about how your theme looks via AV out, and don't care about it looking alised/jagged on the internal display, design for the regular `640 x 480` base - If you only care about how your theme looks via AV out, and don't care about it looking aliased/jagged on the internal display, design for the regular `640 x 480` base
- If you care about both display types, and want your theme to look great (but not perfect) on both, design for a three-quarters `480 x 360` base, and do a **bilinear** upscale to regular `640 x 480` base resolutions when converting to SF2000 formats - If you care about both display types, and want your theme to look great (but not perfect) on both, design for a three-quarters `480 x 360` base, and do a **bilinear** upscale to regular `640 x 480` base resolutions when converting to SF2000 formats
--- ---
@ -594,6 +594,8 @@ All of these are linked above already in their relevant sections, but just in ca
--- ---
## Version History ## Version History
- `20230719 - 1.28`: Moved most of the intro section under the "Is this thing any good?" FAQ, and slightly reworded parts of it. Fixed a few typos.
- `20230718 - 1.27`: Updated FAQ about custom firmware with latest details (first running Retroarch core! 🎉) - `20230718 - 1.27`: Updated FAQ about custom firmware with latest details (first running Retroarch core! 🎉)
- `20230714 - 1.27`: Updated FAQ about custom firmware with latest details (Retroarch input driver in basic functional state) - `20230714 - 1.27`: Updated FAQ about custom firmware with latest details (Retroarch input driver in basic functional state)
@ -626,7 +628,7 @@ All of these are linked above already in their relevant sections, but just in ca
- `20230526 - 1.13`: Updated Audacity instructions to support latest version of Audacity. Added a BIOS CRC32 patcher tool for the reckless and brave. Added a note about `Foldername.ini` text colours reverting after loading a game (thanks `Zerter#4954`!) - `20230526 - 1.13`: Updated Audacity instructions to support latest version of Audacity. Added a BIOS CRC32 patcher tool for the reckless and brave. Added a note about `Foldername.ini` text colours reverting after loading a game (thanks `Zerter#4954`!)
- `20230525 - 1.12`: Added a section about the internals of the `Foldername.ini` file. Added a note to the Arcade section about the "inrom" column in `adcockm`'s metadata document. Added a small firmware note for the `05.22` about community-spotted GBA performance improvements. Added specific emulator versions and Git commit links for each emulator (thanks `bnister` and `notv37`!). Added specific steps for producting SF2000-format audio files using Audacity. - `20230525 - 1.12`: Added a section about the internals of the `Foldername.ini` file. Added a note to the Arcade section about the "inrom" column in `adcockm`'s metadata document. Added a small firmware note for the `05.22` about community-spotted GBA performance improvements. Added specific emulator versions and Git commit links for each emulator (thanks `bnister` and `notv37`!). Added specific steps for producing SF2000-format audio files using Audacity.
- `20230524 - 1.11`: Added my new [Generic Image Tool](https://vonmillhausen.github.io/sf2000/tools/genericImageTool.htm). Added more exceptional information from `adcockm` in regards to arcade emulation on the SF2000, and cleaned up the old info accordingly. Corrected some typos related to `bisrv.asd` (thanks `luke7352`!). Usage of `nvinf.hsp` was tracked down to the numbers of games available on the main menu pages (thanks `kid_sinn#9691`!). - `20230524 - 1.11`: Added my new [Generic Image Tool](https://vonmillhausen.github.io/sf2000/tools/genericImageTool.htm). Added more exceptional information from `adcockm` in regards to arcade emulation on the SF2000, and cleaned up the old info accordingly. Corrected some typos related to `bisrv.asd` (thanks `luke7352`!). Usage of `nvinf.hsp` was tracked down to the numbers of games available on the main menu pages (thanks `kid_sinn#9691`!).