tepples wrote:The official Super NES port of the 240p Test Suite was 512K last I checked, and the Super Game Boy allowed downloading only up to 64K last I checked. Is there source code for a Super NES program sending requests back to the Game Boy CPU so that it can request 4K of data at a time through the DATA_TRN mechanism? Is there public source code for loading and running native code on a Super NES through Super Game Boy at all? Or would I end up having to become the only developer other than the Taito devs who made Space Invaders to actually use DATA_TRN and JUMP?
No such source code exists publicly to my knowledge. What does exist is documentation of the hardware used for communicating through the SGB cartridge
. With that info, I think the limiting factors (other than time of course) is one's knowledge of the SNES architecture, as well as access to debug tools. At least Higan emulates SGB.
As calima suggested above, one goal of this project is to fit it in 32768 bytes, the size of Catskull's $10 MBC-less flash cart
. As a precedent for the practicality of producing Super Game Boy enhanced software small enough to fit in such a cartridge, which licensed Super Game Boy enhanced or Game Boy Color enhanced games are 32K? No-Intro's DAT-o-MATIC
doesn't appear to have a way to filter by size, even if we assume that filtering by title "SGB Enhanced" is reliable.
If the query is games licensed by Nintendo, I'm fairly certain there are no examples. But I can mention my own port of Flappy Bird. Even though it's a simple game, there's quite a lot of graphics in it. Including an as mentioned, SGB border graphics, intro screen, multiple animation frames for the bird, certain graphics that are different in GB and GBC mode as well as multiple easter eggs. But there you have an example a 32k game that is both SGB and GBC enhanced, and it was sold on cartridge. Attached is the ROM and a screenshot of it SGB border.
Some size stats about the game:
(Almost) all graphical assets are compressed using my shoddy homebrew compression algorithm. To take the SGB border as an example:
Tile data: 8192 bytes
Attribute map: 2048 bytes
GB map data used for the data transfer: 448 bytes
Tile data: 5185 bytes
Attribute map: 742 bytes
GB map data used for the data transfer: 21 bytes (That data is mostly sequentially incrementing tile numbers so it compresses extremely well in my compression encoding. But that's one of the things it was optimized for.)
Total: 5948 bytes
A tally of all graphical assets (uncompressed) comes out to 28200 bytes, whereas the complete ROM (code+compressed graphics) is 27785 without slack.
With that said, what takes up the most space in any game is likely graphics as well as level data. The test suite will have no level data and could cut down the data considerably by restricting itself to the more utilitarian tests and skip for example the Sonic screen. The graphics used in the more utilitarian tests would compress well, owing to their mostly repetitive nature. There's nothing intrinsic about SGB that would make the ROM big, other than actual size of the graphics. I realize, though, that at that point we're discussing a whole new product.
tepples wrote:If no such games exist, then who manufactures production cartridges larger than that?
There's nothing special about a SGB cart, so if all you want is a physical cartridge for a release, there are various ways. Just let people run it on their own flashcarts. You could buy the cheap knock-off games from eBay or Aliexpress, which are often reflashable. That could be a cheap way of getting something out, although those carts often a bit flaky.
In addition, with my obligations to my employers (plural), I may not be able to produce a Super Game Boy enhancement patch, a Game Boy Color enhancement patch, and a Game Boy Advance port (which someone on Shmups Forum requested after I announced this there
) on my own any time soon. Once I complete the mono version, I am willing to review such patches provided by you, calima, or anyone else.
That, I totally get. What could theoretically be done, and what one person could do on their own given their available time are different things. I'll put it on the todo list.
In this post
, I have passed along this nitpick to the maintainer. I think the main sticking point is what button binding would be used to show each test's help page on each supported platform.
My counter-nitpick would be that it's not that it would be needed per se, it's just what I expected the button to do. Why have a dedicated button for showing the about screen, when there's a menu item for it. Remove that keybinding and reuse it and there should be no problem with any lack of buttons. Although that's just my stupid opinion.