i used info from here, and from another place, but i lost the link. i recognize write to 1FF0-1FF3 as bank select operation, i copy two lowest bits of address bus to bank switch register. verilog code: if(!we & !ce & addr[12:2] == 11'b11111111100)sf_map[1:0] <= addr[1:0]; sf_map[1:0] decide which of 512kbyte banks will be mapped
What happens on the USA Sea Port/Ken's Stage? Glitched graphics? Does the entire rest of the game work perfectly other than that stage? Is there a chance that some other writes could be falsely triggering the bankswitch? Or that you aren't accepting some writes? I'm not sure that diagram on that page is correct. And I'm not sure your condition for accepting writes is correct. Are you checking all the address lines from A12 to A2 for being set to their values that would represent $1FFx? Maybe the SF2 mapper expects mirroring to be possible or doesn't fully decode, maybe it supported an even bigger ROM. So maybe you should only check that A12 to A4 are all set (equal 1). So that way any write to $1FF0 to $1FFF will trigger bankswitch. Give it a try, it might fix it.
rest of game work just perfect. Background in Ken's level looks like bunch of random garbage. i tried to remove "& addr[12:2] == 11'b11111111100" from condition, but i got exactly same result. if(!we & !ce)sf_map[1:0] <= addr[1:0];
It still could if Krikzz wants to - my Jaguar Skunk board is white, however if I saw correctly he's got a stack of boards in the background of the prototype picture which I guess means it's just going to be a standard green. I'm so pumped to see a picture even though I know it's not working fully - It probably won't be long before it's all smoothed out and up and running
Color doesn't matter to me - It'll be sitting nice and pretty under my hu-card door on my duo. I'm pumped for this one!
It seems like you should have it implemented fine, this is the source code from Mednafen. static DECLFR(HuCSF2Read) { return(HuCROM[(A & 0x7FFFF) + 0x80000 + (HuCSF2Latch & HuCSF2BankMask) * 0x80000 ]); } static DECLFW(HuCSF2Write) { if((A & 0x1FF0) == 0x1FF0) HuCSF2Latch = A & 0xF; } Are you making sure that the SF2Latch, set by writes to $1FFx is determining the 512Kb Bank correctly? Are you sure that $80000 - $FFFFF on the HuCard is banked to one of the last four 512kb banks of the SF2 ROM? You don't allow setting the first 512Kb bank of the SF2 ROM into $80000 correct? Maybe the problem isn't related to the mapper implementation and the problem is coming from somewhere else then. Did you verify that the Flash is not corrupted? PC-Engine games don't usually if ever contain checksum routines to determine ROM integrity.
looks like my mapper works exactly same like this piece of code from emulator, so problem somewhere else. will check all again
Is SFII the only challenging cart or are we going to get pretty much 100% compatability right from the start? Time for you to make some videos Krikzz
99% of game HuCards are just a ROM up to 1 Megabyte in size. SF2'CE is an exception as it is 2.5 Megabytes and to allow that a memory mapper was designed for it. I have heard Populous might have some extra (maybe battery backed) RAM but that is about it. So again, 99% of HuCard games should work perfectly on the EverDrive. Populous is the only game that will not work.
Great job! I have 2 questions : * is it possible, instead of having a switch for region, to detect automatically the region of the rom and make an internal switching? (Not a big deal, furthermore you can patch the rom to change the region) * Is stoneage gamer plane to make a case for this everdrive or is it even possible (not as problematic as for snes or md everdrive anyway)? Keep up the good work :encouragement:
i didn't said that switch for rom region select, switch only for console region select. switch should be tuned just once, and will stay in same state forever. one position for pce, another for TG16.
I am unsure how we will handle Turbo EverDrive at this point. There are no donor cases we can use like other carts. I have considered vacu-forming, but I am unsure how well that will work or turnout. It will have to be something we experiment with. Getting a custom case engineered and produced is too expensive and risky, especially for a less popular system like the TG-16/PCE. There's a reason why we don't get custom shells done for any of the EverDrives. Mainly its because we don't have control over the project. From a strictly business standpoint since I don't have control over production or the rights to produce them myself (the PCBs) to invest tens of thousands of dollars into custom shells and then have something happen to KRIKzz would be a disaster. We will see. I will have to get a finalized board first to see what I can get done.
Would it be possible to use the Turbo Everdrive like a Tennokoe Bank card? It would be great to be able to transfer saves from my Turbo CD to the SD card, due to the system's limited save memory plus the risk of losing saved games if the Turbo isn't turned on frequently. (I lost my Ys Book I & II save because of this). Additionally, it would take care of the dead battery risk of the Tennokoe Bank cards. I'm going to buy the Turbo ED either way, but this would be a great feature.
That is probably possible. It could be added to the OS as a feature. It shouldn't be hard at all to atleast backup all of system memory to the SD card. Maybe it'd be possible to actually pick and choose each game file.
Even being able to backup the entire system memory like the Tennokoe Bank would be great, though of course, individual game files would be preferable Unless I'm mistaken on how this works, using a method like Tennokoe Bank would require that you have the correct backup loaded to your Turbo Booster Plus or Turbo CD (or whatever other device you may be using) to save game progress, and then you could switch out the system memory with another backup if you're playing a game that was part of a different backup. A little more tedious than swapping out individual games, but much better than clearing memory for saves or losing saves because the system hasn't been powered up recently.
There's no reason to patch the rom. Nearly all HuCard-based PCE/TG-16 roms will play on either system (both NTSC). Region protection was done by the pinouts on the cards, which obviously won't matter now. How did Neo Flash create their cards?
You are wrong. Turbo Chip/North American card based games usually contain a small protection code to prevent them from running on Japanese systems. I have no idea why they did that exactly. It would have made sense if Japanese games had lockouts too. But on US consoles with a simple pin swapping adapter you can play all Japanese HuCards. But to play US Turbo Chips on a Japanese console you need to lift a pin on the CPU inside the console and change its connection. Anyway, I sent KRIKzz the strings of bytes to search for (it's the same in all games) to patch out the protection so that won't be an issue. The switch like he said is for consoles because certain pins on the cartridge connector are swapped. So the switch on the card will tell circuitry on the card how to route those lines which switch between consoles. This way you don't need two versions for each console. The Neo Flash cart probably sets the region on programming by doing any line swapping in software.
They probably had custom molds made. I explained why I its not practical to do this my previous post.
