nesdev.org

Is this conversion as simple as replacing the CHR-ROM chip by a SRAM one (and bringing the CHR /WR signal to it)? I'm asking because I have never seen a TGROM board in person, and since the MMC3 controls a bunch of CHR address lines, I though maybe the address lines in this board are connected directly to the SRAM chip, instead of going through the MMC3.

If this is correct, what would be the correct way to perform this conversion? Would cutting all the traces of address lines comming from the MMC3 and soldering 13 wires (14 if you count the CHR /WR) from the cart connector into the SRAM chip work? Can all those lines comming out of the MMC3 be left unconnected?

Can anyone that owns a TGROM board tell me what happens to the CHR address pins comming out of the MMC3?

I'm looking into using this board for my project, since the 256KB of ROM I can have in a UOROM board seem to not be enough anymore. With a TGROM board I can have 512KB of program ROM, and the possibility to switch ROM in chunks of 8KB seems like a plus.

I have a bunch of TLROMs at home, but the TGROMs are pretty rare. So the only possible solution for me is this conversion.

Thanks for the help.

Okay. TGROM is to TLROM what TNROM is to TKROM, and drk141 has written a doccument explaining how to convert from one to another. Converting from TLROM to TGROM would have the exact same problem : You'd have to glue an additional CHR /WR pin, wich is unused (and not even present) on the connector of a TNROM board. I doubt you'll find any TLROM board with this pin, however maybe you could find a TFROM-01 cart who has it (that would change nothing to conversion, in fact it would be even easier).

In a true TGROM board, the CHRRAM is banked by the MMC3, because it's upper adress lines does not come directly from the NES, but from the MMC3 (it should be A10, A11 and A12 if I remember correctly). That means you can bankswitch the CHRRAM by 1KB chunk just like if it were ROM. However, if you do connect those line directly to the PPU ardress lines, you just will be unable to bankswitch CHRRAM, wich is completely useless I guess (at lest Mega Man 4, 6 and Final Fantasy III, the main games that uses MMC3 and CHRRAM, doesn't do this).

Since the 8 KB RAM have a pinout very similar to small ROMs (like the 32KB ROMs found in TFROM boards), I bet the simplest way to get a TGROM board without destroying a Mega Man cart would be to do it from a TFROM board, wich has standard CHR EPROM pinouts. You will just have to change pin 27 from A14 to /WE (by connecting it to the main connector) and pin 26 from A13 to VCC (the positive chip enbable). If you can find a TFROM-01 board it's even better as the /WE pin is present, saving you much trouble.
If you really only have TLROM baord, I don't think you should give up as you just have some more wires to change I guess, but that should be feasible as long as you can add that extra /WE pin.

Else, just stuck with UOROM and apply massive compression to your stuff. I'm sure this is doable... or is your game THAT big ?

PS : Else you could go the SUROM without battery way, closer to UNROM than TGROM, and easily modifiable from any common Kid Icarus or Metroid cart.

Bregalad wrote:Else, just stuck with UOROM and apply massive compression to your stuff. I'm sure this is doable... or is your game THAT big ?

Yes, it's that big. It's a Sonic clone. Sonic the Hedgehog games can be big: Sonic 2 was 1024 KiB, and Sonic 3 was so big (4096 KiB) that they had to split it up over two 2048 KiB cartridges, using Sonic & Knuckles as an expansion pak in a Game Genie-like configuration for Sonic 3.

I'd suggest comparing to the Game Gear sonic games instead, which topped out at 512KB.

Thanks, Bregalad. I wouldn't think the 8KB of CHR-RAM would be bankswitchable. That would sure make the conversion easier. Although it seems rather pointless. I'm sure there are some effects you could do with that, but hardly during the main game engine. And silly me thinking I'd have to connect 13 wires from the connector, as surely the first 10 are already directly connected, the MMC3 only controls the higher lines.

You are right about the difficulty of having to attach a new pin to the connector... although some people have done so with some sort of thin metal and super glue.

Dwedit wrote:I'd suggest comparing to the Game Gear sonic games instead, which topped out at 512KB.

There is the disaster that was Sonic Blast, which is 1MB. But I'm hardly thinking of the Game Gear/Master System games. I'm basing myself on the Mega Drive/Genesis series, and trying to incorporate a lot aspects of it, many not present in the 8-bit games.

For example, in the Master System games, the levels were built of 32x32-pixel metatiles, and when decompressed could use at most 4KB of memory. That's a serious limitation on level size, while the Maga Drive has seen some huge levels in S3K. Also, the graphical details are very poor, even though I believe the SMS could do much better. The gameplay is pretty slow too. What I expect to do is get closer to the Mega Drive series than the SMS people ever did, because they didn't try hard enough.

Well, back to the board issue, I'm even considering using CHR-ROM now. I was originally planning on simulating CHR bankswitching of 256-byte blocks with CHR-RAM (it was working), but that would require a lot of VBlank time (even though the tiles were scrambled in the ROM to make the transfer faster), and the processor would spend too much time managing that (since I could only update 256 bytes per frame, I had to manage a queue), so by redesigning a few things to have the game fit the CHR bankswitching scheme of MMC3 I could take some load off the CPU, which is always good.

At first I was enjoying the challenge of making it work on the simple UOROM board, limited to 256KB of ROM and 2KB of RAM. But if you think of the GG/SMS games, as Dwedit said, Sonic 1 was 256KB, and it features only a few small levels, undetailed graphics and 1 playable charater. I'm planning the exact opposite of all that, and having it all fit in the same space was becoming too much trouble.

Now it just seems stupid to have this type of "challenge", while I could, for the sake of a better game, simplify things for me. I'm even considering using a TSROM board, and make use of the extra 8KB of RAM. That would make it easier to handle level maps (that could even be compressed in the ROM), would allow for pre-calculation of some values that'd make the engine run faster, more states of objects could be kept during the levels... If it's for the sake of a better game, why not? What do you guys think?

I think this "Challenge" is not stupid. 256KB of PRG ROM, if cleverly used, may be used to make a game as big as for example Mega Man 3 (wich has not so cleverly used 256KB - 128 KB) or even Castlevania III - Dracula's Cure (with much poorer graphics, but the same lenght) (as the game as ageragly cleverly used 256KB -128 KB).
However, you are right at this kind of Challenge shouldn't deteriorate the quality of the game, and honnesly, if you already made a game with 256 KB of stuff in it, you have my sincere respects. My game currently has about 16 KB of PRGROM and 20 KB of CHRROM used, and I plan it to end up 32 KB - 32 KB, so there is still some work to do (about 1/6 of the levels are done, and almost no ennemies at all, with music), but I have a complete working game engine.
About the mapper you should be using you're completely free about it. It's up to you to know if you want to use CHRRAM or CHRROM. If you already make it that far with CHRRAM, I think you should think seriously before switching back to CHRROM, because this may add some serious more work and changes. If you stick with CHRRAM, I'd recommand SUROM if you want to keep as close to UNROM as possible, you have 2 main banks instead of one wich can become an advantage, you have a lot more ram (it seems you complained a lot about the lack of RAM recently), and if you add a battery you can even save the progress. If you don't you still have more RAM, and as I said before this can be very easily modified from any common Metroid and Kid Icarus copy. (I'd destroy any Metroid cart to play your game period, I really hate Metroid). It's not hard to add a battery even from a cart who hasn't it, nor it is hard to find a Zelda cart to sacrifice.
Else, TGROM will have you stuck with less RAM, but you have the IRQ counter and 8 KB ROM bankswitching (I don't know if this is really a big advantage, maybe it is). I guess the IRQ counter is a serious advantage and you might consider this. Read what I said above for converting one from another board, that sounds doable. Plus I remember you to have the power pack, so you can test the game with power pack until you're absolutely sure you won't change it, then test it on a real MMC3 before releasing it to be sure the thing works. Of course if you want both advantages at once (IRQ and RAM) TNROM is the way to go.

Now if you want to change back to CHRROM, I'd not recommand SLROM because it has a somewhat limited CHR bankswitching sheme, so go to TLROM or TSROM. TSROM is a decently common board, so you may think of TLROM first, and if the thing cannot fit use TSROM.

You also may want to consider if you plan on putting the game on physical carts. It would be very easy to make a custom UNROM board with 512KB PRG, but then you can't use existing boards. The SUROM board is relatively uncommon but brand new MMC1 boards with that capability are available. That would give you saved games, but a password system like MegaMan would probably work just as well. Don't think the 4KB CHR RAM switching would help you at all. Modifying the T*ROM boards pretty much means you wont be building more than a couple, and making new boards for MMC3 gets really expensive.

Basically if you want "mass" production, stay away from MMC3. If you are just releasing as a ROM, do it easy on the MMC3 and make it the most complex game possible.

I notice that the chip on the ReproPak MMC1 from RetroZone looks like a CPLD. But how big of a mapper can we fit into a CPLD? What MMC3 features would have to be cut?

I understand what you guys are saying. I don't like the MMC1, mostly because of the weird way in which we have to write to it's registers. Switching CHR-ROM in 4KB chunks is pretty useless for me too. I'm already having enough trouble arranging it all according to the MMC3 specs.

I believe I could have this game use the ReproPak MMC1, as lon as I kept using CHR-RAM. But I'm already getting used to the idea of using the MMC3... being able to switch PRG-ROM in 8KB chunks made a lot of my design simpler. And by using CHR-ROM I can avoid using some nasty tricks I had in order to have more dynamic patterns, involving a lot of timed VBlank code.

For me, a version of the MMC3 without the scanline conter would work fine, as I'm not using it. In fact, I'm making heavy use of 8x16 sprites from both sides of the pattern table, something that breaks the counter. The lack of a scanline counter would sure simplify the mapper logic. I however would never be able to build a cart from the start.

Thing is I do worry about how I'd make carts with this game, but I'm not willing to sacrifice features for that. And bunnyboy, it's not like the MMC3 makes the game more complex. In fact, it's making the code much simpler.

Since the beginning, I had features I knew this game would have, and I thought they'd all be possible on the UOROM board. I wasn't wrong about this, but to make those features work, i needed all sorts of tricks going on, which greatly increased the complexity of the code. The MMC3 will take a lot of that out of my hands, and thus code will be simpler.

By having extra RAM, I can have all the data arranged in a way that improves readability, instead of having to scramble, pack and shift bits to compress the data as much as possible.

If there was a good way to design custom mappers, I'd probably think of something good. But what difference does it make if it's easy to create a 512KB UOROM board if no emulators will support it? how will I code a game like this?

Yes, it's that big. It's a Sonic clone. Sonic the Hedgehog games can be big: Sonic 2 was 1024 KiB, and Sonic 3 was so big (4096 KiB) that they had to split it up over two 2048 KiB cartridges, using Sonic & Knuckles as an expansion pak in a Game Genie-like configuration for Sonic 3.

I just noted that SMB : All Stars (SNES) is 2048 KB, while the sum of all it's 8-bit counterparts is : 40 KB (SMB1) + 64 KB (SMB2J) + 256 KB (SMB2US) + 384 KB (SMB3) = 744 KB. So the 16-bit/8-bit ratio for the same game seems to be arround 2.75 for this game. (of course the same 8-bit game is smaller mainly because it have less graphics (and simpler ones), and less channels on music). Note that the fact that the same mario sprite is used and that some music is reused among different games in SMB : All Stars may be that the actual ration could be a little higher (arround 3).

That means that if Tokumaru ports Sonic 2 on the NES with a similar ration, the final result would be 1024/2.75 = 372 KB. If he want to fit 256 KB, he would have to decrease this ratio to 2. However, with 512 KB at disposal, the ratio can be increased up to 4, meaning a lot of new features could be potentially be added in the game.

Bregalad wrote:So the 16-bit/8-bit ratio for the same game seems to be arround 2.75 for this game. (of course the same 8-bit game is smaller mainly because it have less graphics (and simpler ones), and less channels on music).

That's an interesting way of thinking about it... I wonder if code makes a big difference as well... You know, when I look at 68000 assembly code I think of the space some instructions may need because of the amount of memory the system can address... but by using 16 and 32-bit registers it can also handle more data a time, while we 6502 people need a bunch of instructions just to add two 16-bit numbers. So I wonder how much the difference between instruction sets affects the size difference, not only graphics and sound.

That means that if Tokumaru ports Sonic 2 on the NES with a similar ration, the final result would be 1024/2.75 = 372 KB.

Curiously enough, that seems about right. When I switched to 512KB, I realized I would not need all of it, and your guess seems pretty close to what I'll end up using. I have decided to not compress my graphics anymore, though, for the sake of simplicity. Plus I never came up with the revolutionary compression algorithm I'd like... =)

If he want to fit 256 KB, he would have to decrease this ratio to 2.

You must also take into account the amount of RAM the system has. Much of the data in Sonic games is compressed (graphics, level layouts, even music), because the system they run on has 64KB of RAM, much more than the 8KB of the Master System or the 2KB of the NES. Since I decided to use the extra 8K of RAM I too became able to have some of the data in the ROM be stored in a more compact way and expand it to RAM for more efficient access.

However, with 512 KB at disposal, the ratio can be increased up to 4, meaning a lot of new features could be potentially be added in the game.

I plan to have most of the features in Sonic 2. The only things I know I'll not have is the split screen versus gameplay (that would require a completely different game engine) and the "one character following the other" thing, because that would be a real sprite killer, so each character plays solo. Other than that, I expect it all to be there. I'm not "porting" anything though, mine is an original game, inspired by the 16-bit series. I'll also incorporate stuff from later games, such as the different types of shields (not exactly the same shields, but I'll have a few different types) in Sonic 3/& Knuckles.

Curiously enough, that seems about right. When I switched to 512KB, I realized I would not need all of it, and your guess seems pretty close to what I'll end up using. I have decided to not compress my graphics anymore, though, for the sake of simplicity. Plus I never came up with the revolutionary compression algorithm I'd like... =)

Yeah, I didn't know if my theory would work, but it look like it does !!
The fact that SMB : All stats is completely like the original games make this comparaison significant, but I don't know if it also applies to Genesis and so on.
In fact I mess up with numbers above, the ratio is effetively 2.75 (possibly lower if SMB : All stars uses the same data for its different games it may in fact run about 2.5), but if you use 512 KB you decrease it to 2, you don't increase it to 4. Lowering to 256 KB would require it to decrease to increase to 4, wich seems really hard.
And yes, as you said, more RAM means less ROM, but in fact this is already taken in account since both the SNES and the Genesis have significantly more RAM than the NES. How you use it may change a lot however.

Bregalad wrote:In fact I mess up with numbers above, the ratio is effetively 2.75 (possibly lower if SMB : All stars uses the same data for its different games it may in fact run about 2.5)

It appears not to, at least not among the NES games. The sprites for Super Mario Bros. 2: Mario Madness differ from those used in the other three games. Super Mario Bros. and Super Mario Bros. 3 use identical-looking sprites, apparently stored separately in ROM. Specifically, SMB1 is stored in 8x8 format, while SMB3 is 8x16.

And yes, as you said, more RAM means less ROM, but in fact this is already taken in account since both the SNES and the Genesis have significantly more RAM than the NES. How you use it may change a lot however.

However, All-Stars uses it inefficiently. The graphics aren't compressed at all, meaning there's a 2:1 expansion for just the front layer, in addition to the added back layers. I'd imagine that for All-Stars and Tetris & Dr. Mario, they tried compression, but they couldn't get it small enough to squeeze it into half the released cart size, so they just left it uncompressed.

That's not even counting the much bigger ROM space of audio on the Super NES vs. on the other platforms. Every sound on the Super NES is 4.5-bit DPCM, unlike NES and Genesis sounds that are either 1-bit DPCM, FM tone generators, or simplistic tone generators.

Yes, the samples on the SNES can take some space, but SMB : All stars doesn't seem to use many of them. In fact a small set of samples used among a whole game can run in some 32 KB or something.

And as you said, it seems smart to have graphics compressed if this allow you to reduce the size of the ROM, but leave them uncompressed else.
For example if you code a game (using CHRRAM or another platform than NES, because NES seems to be the only platform to feature CHRROM) and end up with it being 160 KB, you can try compress the graphics to get down to 128 KB. If you can that's a good thing, else you'll want to leave the graphics uncompressed, add cutsces and secrets and so on so you can take benefit of the whole 256 KB.

EDIT : It looks like in All Stars SMB1's sprites is different from SMB3's (exept for small mario). However, all SMB2j's graphics are exactly the same as SMB1.