|
Post by hyperfighting on Jul 21, 2023 15:42:49 GMT
Hi All, I am curious if there are any steps available to incorporate the SF2 Mapper into a HuC project? My motives are more GFX...Function Name Space Boost? I am curious if it is known that you would have more function name space by utilizing the mapper EX: If you get the dreaded..."No more space in bank for .proc trampoline!" Side note: Is there any tricks to get around "No more space in bank for .proc trampoline!" aside from reducing the existing number of HuC functions / going cd and using overlay functionality? [upd]SF2+ Mapper
So it appears if I'm reading this correctly a "SF2+" mapper exists. The post is circa 2010 and describes "A private release of Mednafen WIP supports it" exceeding the 2.5 megabyte image to up to 8.7 megs! This has got me wondering? - Do standard versions Mednafen currently support this mapper since it has been 13 years since the initial post did it get built in or do you still need a custom build? - Assuming you had a HuC card with the SF2+ mapper would real hardware support it? I assume yes.... - RetroStage has yet to develop a SF2 Mapper but the future looks friendly on this front. If additional information was provided regarding SF2+ Mapper maybe we could have that mapper! - I am excited to experiment but don't know where to start...I believe HuC auto builds images to a max of 1024kb but could there be a provision to build up to 8.7 megs! The hype is real I'm out of my depth here.... elmer you have been actively maintaining a HuC branch do you have any thoughts on possibility of adding SF2 and SF2+ mapper support to HuC?
|
|
|
Post by elmer on Jul 22, 2023 15:23:35 GMT
This has got me wondering? I'm not sure if mednafen supports more than the regular 2.5MB SF2 mapper at the moment, but it is absolutely trivial in concept to increase the size allowed to 4MB/8MB ... as the RetroStage developers already know if they've taken a look at how the SF2 mapper works, and "yes" it would work on a real console. Side note: Is there any tricks to get around "No more space in bank for .proc trampoline!" aside from reducing the existing number of HuC functions / going cd and using overlay functionality? No, there are no "tricks" available ... just the advice "LEARN HOW TO PROGRAM A GAME"! There is absolutely no reason for you to hit the limit of "No more space in bank for .proc trampoline!" if you actually program in a sane and sensible manner (for the platform and time-period), and create some data-driven abstractions instead of coding every single little detail as its own function. If you are unable to change how you program, then perhaps breaking things up and using CD overlays is the only solution for you. Please understand that the best (and even most of the lesser) professionally-developed CD games on the PC Engine just use a very small amount of program code (usually less than 10 banks) for the game itself, and then the CD overlays contain data rather than code. I am curious if there are any steps available to incorporate the SF2 Mapper into a HuC project? You can already develop for the "SF2" mapper, or what you are calling the "SF2+" mapper in HuC, if you actually learn a bit about the machine, and then do a bit of thinking about the problem, and finally create a couple of tiny assembly-language routines. FWIW @tuboxray said that he was going to release some example of how to do this, but I've not seen it, yet. Basically, the technique that I believe would work for HuC is fairly simple ... you make sure that all of your code is in the low 512KB of the HuCARD ROM, and then bank in different 512KB regions of data into the top 512KB of the HuCARD ROM. This can already be developed in HuC just by creating a regular 512KB HuCARD ROM with some care about the bank starting points, and then creating different extra 512KB data overlay ROMs that you just concatenate on to the end of the program-ROM in order to create a 2.5MB (or larger) HuCARD ROM. The problem is that you would actually need to pay attention to what you're doing, and also actually learn how to use the tools that are available to you in order for this to work! What you seem to be asking for instead is an "I just want this all to magically work without having to think about it." solution. That may be available at some point in the future, but it will require some fairly deep changes to how the PCEAS assembler works. My motives are more GFX...Function Name Space Boost? Well, a CD has room for 640MB of data, so perhaps that's the path that you should follow?
|
|
|
Post by hyperfighting on Jul 22, 2023 20:25:38 GMT
elmer Thanks for getting back to me and for verifying PCEAS assembler does not natively support auto adjusting data over 1024kb to the SF2 Mapper format. I had to ask in the off chance it was possible to do so. It's exciting to know HuCards could be 8mb! Regardless if nobody should ever hit the .proc trampoline limit I was still curious if the additional 512kb banks could allow for more function namespace just due to the fact we now have more space to store data. It seems this is a hard limit of HuC's design or with an advanced Mapper could it be possible? Moving forward since it hasn't been documented it would be awesome to detail the method for building and concatenating 5 - 512kb roms. turboxray if you have a method for doing this I am excited to give it a try!
|
|
|
Post by paranoiadragon on Jul 29, 2023 1:14:20 GMT
I'm sure I don't understand any of what's being talked about. But I noticed you said it's exciting that Hucards can be 8 megabits? They can be bigger than that, ask Street Fighter 2 is 20 if I recall and the two arcade cards are 16 and 18 if I'm remembering right. Maybe you're talking about the fact that a game can be 8 megabits without a mapper? I know Street Fighter 2 of course has one but I'm not aware of the arcade cards need a mapper. But then again of course, they're not games, they're just basically a bios so I'm probably talking out of my arse! 😄
|
|
|
Post by hyperfighting on Jul 29, 2023 4:33:57 GMT
Apparently if you are able to harness the true power of the HuCard mapper! You can go as far as 8 Megabytes! This is really exciting for people interested in the HuCard media! Unfortunately there is no documented sample project bundled with HuC yet.
I hope the devs working on the new HuC builds help us with a template we can experiment with. I know we are talking Hudson but 'The Future Is Now' with RetroStage producing HuCards we might just get one capable of 8mb if they are confident that there are some active projects and real interest.
Unfortunately, in my case this is a daunting task based on Elmer's roadmap in this case I need to admit that this tactic of building and concatenating multiple 512kb roms is far beyond my no how. I really hope someone will help get the basic devs on the right track.
|
|
|
Post by turboxray on Jul 29, 2023 20:47:54 GMT
The problem isn't the extended memory. It's getting the existing labels/pointers in the far memory to play nice with huc. Since it's mostly graphic data (tiles and sprites) that would be in the extended mapper memory, I was going to provide alternate vram loading functions that would take a 32bit pointer (mapper bank, bank, address) format. A tool chain (written in python) would take multiple PCEAS rom builds, and the symbol table, and accumulate that into something you bring into your HuC project. You know, the simplest proof of concept and left it evolve from there. Even if it's limiting, better than nothing, it's at least a starting point.
My time is limited. And I won't be working on anything new like this until I get PSG VGM sfx finished for DK and Greg's project.
|
|
|
Post by hyperfighting on Jul 30, 2023 17:59:06 GMT
Knowing that you are on the case in any capacity is always a good look! Best of luck on your sound engine! When this blows its gonna be huge literally! It never ceases to amaze me how much data can be squeezed into 1mb let alone 8mb! Crazy!
|
|