It is currently Tue Oct 16, 2018 9:03 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 56 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Wed Oct 03, 2018 6:42 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20657
Location: NE Indiana, USA (NTSC)
If you have SNROM working, there are two ways to get SUROM going: one that "wastes" bank 15 by making it a duplicate of bank 31, and one that uses it efficiently. Making the most efficient use of SUROM requires figuring out a good separation between the data in banks 0-15 and in banks 16-31. This in turn needs a bit more knowledge of 1. assembly language, in case the C runtime can't be made to understand SUROM, and 2. how much space you plan to devote to different data types, such as background CHR, sprite CHR, maps, and scripts, so that code in bank 15 can be devoted to those data types.

Making a game larger than 256K on the Action 53 mapper has much the same issue, as writing the outer bank register is much like writing the MMC1's CHR bank register, just without the serial complication. But then this might not be quite as relevant to your particular case, as you wrote in another topic that you want to make your game use the same combination of mapper and ROM sizes as at least one game licensed by Nintendo. In this case, it looks like you're targeting Dragon Warrior III and Dragon Warrior IV.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 3:21 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1706
Yeah, the 512 KB in MMC1 is a bit too hacky for me, even if two popular games used it.
So, I decided that I will use MMC3 for my new game from now on.

This has the advantage that I can use animated backgrounds, which is a thing that my graphics artist is very fond of.

Disadvantage: I can only switch the graphics in slices of 1 KB. I have to find a good way to load weapon graphics when changing the weapon in the menu.
In MMC1, I could simply load the ~20 tiles of the active weapon. But not anymore.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 6:49 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3569
Location: Indianapolis
DRW wrote:
Yeah, the 512 KB in MMC1 is a bit too hacky for me, even if two popular games used it.
So, I decided that I will use MMC3 for my new game from now on.

This has the advantage that I can use animated backgrounds, which is a thing that my graphics artist is very fond of.

Disadvantage: I can only switch the graphics in slices of 1 KB. I have to find a good way to load weapon graphics when changing the weapon in the menu.
In MMC1, I could simply load the ~20 tiles of the active weapon. But not anymore.


Sounds like you are using CHR-RAM with MMC1, and you could do that that with MMC3 also. That's the best of both worlds, you can switch 1kB pages and also update individual tiles. 32kB CHR-RAM is the usual size these days. The mapper itself doesn't affect what type of CHR memory you can use (ROM, RAM, or Flash), but the specific layout of the board does, so you would need to confirm with your board supplier.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 6:57 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20657
Location: NE Indiana, USA (NTSC)
Memblers wrote:
32kB CHR-RAM is the usual size these days.

DRW wants to use the same combination of memory sizes as a licensed donor, if this post is any indication.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 7:04 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7648
Location: Seattle
Just to reiterate, there were still a bunch of games released on TNROM and TGROM, with 8 KiB CHR RAM, and that hardware still supports bankswitching the CHR RAM.

Yes, you're limited to figuring out how to usefully get bankswitching animations with only 8 KiB of CHR, but that's the only constraint. It still provides all the advantages of CHR RAM.

Lagrange Point made extensive use of being able to bankswitch just 8 KiB of CHR RAM.


Top
 Profile  
 
PostPosted: Wed Oct 03, 2018 11:46 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1706
Memblers wrote:
Sounds like you are using CHR-RAM with MMC1, and you could do that that with MMC3 also. That's the best of both worlds, you can switch 1kB pages and also update individual tiles.

As far as I understood it, there was no actual licensed game that used bankable CHR RAM with MMC3.
And as tepples already said, I only want to use stuff that was also used back in the day, not things that are only used in homebrews.

(Furthermore, I will probably only ever use the most common mappers/boards: NROM, CNROM, UNROM, MMC1, MMC3. No VRC7 or MMC5 for me.)

Besides, the intention to only use stuff that existed does not refer to the combination of ROM and RAM chip in the MMC3 mapper.
If I used, let's say, 64 KB for PRG and 256 KB for CHR and there is no game that actually uses this combination, this would still be fine because the two MMC3 chips are independent by definition.
There are 30 different combinations of these two chips and if my specific combination wasn't used by any game, then this is still alright because the mapper was designed to be able to combine both chips accordingly. As long as each individual size of each chip was used in any licensed MMC3 game, that's alright.

But CHR RAM + bankable CHR, that's a whole new category. As is a 512 KB UNROM mapper. Those things simply didn't exist back then, so I don't want to use them.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Thu Oct 04, 2018 12:02 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7648
Location: Seattle
DRW wrote:
As far as I understood it, there was no actual licensed game that used bankable CHR RAM with MMC3.
But CHR RAM + bankable CHR, that's a whole new category.
Are ... you just not reading what I'm saying?

All MMC3 support banking their CHR. Always. Even when it's RAM.

The only constraint is that no contemporary boards used more than 8 KiB of CHR-RAM, regardless of mapper. (Deliberately excluding Racermate, Videomation, and Oeka Kids)

The only boards that don't support banking its CHR when it's RAM instead of ROM are rare Famicom-only Bandai mappers (153 and 157). Even MMC1-using boards, where being able to bankswitch only 8 KiB of CHR is more-or-less useless, still supports banking CHR RAM.


Top
 Profile  
 
PostPosted: Thu Oct 04, 2018 12:12 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10892
Location: Rio de Janeiro - Brazil
DRW wrote:
As far as I understood it, there was no actual licensed game that used bankable CHR RAM with MMC3.

CHR (RAM or ROM) is *always* bankable on MMC3. What licensed gamed didn't have was more than 8KB of CHR-RAM. Games could still switch those 8KB around, hide some of it by mapping another part to more than one slot, things like that... The usefulness of that is debatable, sure, but it's possible nonetheless. As pointed out above, Lagrange Point does it.


Top
 Profile  
 
PostPosted: Thu Oct 04, 2018 1:21 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1706
O.k., it looks like I didn't quite get the concept of banking 8 KB before.
(It looks like in my subconsciousness, it was still the idea that one bank = the size of one NROM chip, i.e. 16 KB for PRG and 8 KB for CHR.)

But yeah, since you can bank in 1 KB steps, this might be a possibility:

Draw your background graphics to the CHR RAM chip four times: Static tiles are repeated in every KB, animated tiles are drawn in their different animation phases in each KB.

Then choose each of these four KBs to be displayed as the active bank to create the tile animation.

Am I understanding this correctly?

If yes:
Well, it's doable. But this basically limits your background graphics to 64 tiles if you want four animation phases, doesn't it?

Did any game actually do this? Using MMC3 with CHR RAM and actually using the banking function on its little 8 KB CHR chip?

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Thu Oct 04, 2018 1:36 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7546
Location: Chexbres, VD, Switzerland
I think you could, say for example use 16 tiles for animations and have 4 animation frames; those would be for examples tiles $00-$0f, $40-$4f, $80-$8f, $c0-$cf. The remaining tiles can be used for static tiles, except those of one bank that will be the one which is bankswitched. This gives you 3*(64-16) = 144 static tiles, located at for example $50-$7f, $90-$bf and $d0-$ff.

Then when doing animations you switch banks 0, 1, 2, 3, 0, 1, 2, 3 etc.... in slot 0, so that tiles $00-$3f mirror $40-$7f for animation frame 1, $80-$bf for animation frame 2 and $c0-$ff for animation frame 3. The problem is that tiles $10-$3f are de-facto unusable for neither animation or static tiles, so you effectively "loose" 48 tiles.

This is just an example of how bankswitched CHR-RAM could be of any use. This wasn't used back in the day (except for Lagrange Point) so I wouldn't consider this the truly "NES authentic" to do it, but since the hardware allows for it without any improvement this is debatable.

You could also use only 2 or 3 animations frame in order to get more static tiles, it's a tradeoff; you still loose 64-N tiles in all cases, where N is the # of animated tiles.

You can also use CHR-RAM the regular way and animate the tiles by VRAM updates, splitting the updates in several frames if needed. In most cases this is acceptable, but sometimes it will look weird to not have all animated tiles switching at the same time.

Also while we're talking on the topic, I can't think of any usefulness of neither MMC1-style 4kb CHR-RAM banking, as it is equivalent to $2000.3 or $2000.4 switching, so it's a redundant feature, unless I'm forgetting something. I also have trouble finding an usage of bankswitching CHR-RAM for sprites, but this could be useful when doing it mid-frame for drawing sprites partly from one bank and partly from another. Maybe interesting effects could be done this way.


Top
 Profile  
 
PostPosted: Thu Oct 04, 2018 2:05 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10892
Location: Rio de Janeiro - Brazil
Bregalad wrote:
This wasn't used back in the day (except for Lagrange Point) so I wouldn't consider this the truly "NES authentic" to do it

This is just a software technique using the available hardware though... if a programmer starts banning software techniques just because they haven't been programmed before, then his games won't be original at all, will they?


Top
 Profile  
 
PostPosted: Thu Oct 04, 2018 8:20 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7546
Location: Chexbres, VD, Switzerland
Bankswitching within a 8kb CHR-RAM is a hardware feature that have only seldom been used. In that regard, it is similar to other hardware features that have seldom been used such as 4-screen mirroring.

A game mixing and improving software techniques already used from various existing games is still going to be original. And yes indeed I said right from the start it would be controversial whether bankswitching within 8kb CHR-RAM is "authentic" or not. What is sure is that bankswitching more than 8kb of CHR-RAM is definitely not authentic.


Top
 Profile  
 
PostPosted: Thu Oct 04, 2018 8:41 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20657
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
A game mixing and improving software techniques already used from various existing games is still going to be original. And yes indeed I said right from the start it would be controversial whether bankswitching within 8kb CHR-RAM is "authentic" or not. What is sure is that bankswitching more than 8kb of CHR-RAM is definitely not authentic.

It's authentic on CPROM and the Oeka Kids board. It could also be considered a predictable cost reduction of TQROM, which has MMC3 and 72 KiB of CHR memory, the last 8 KiB being RAM.


Top
 Profile  
 
PostPosted: Thu Oct 04, 2018 9:15 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10892
Location: Rio de Janeiro - Brazil
Bregalad wrote:
Bankswitching within a 8kb CHR-RAM is a hardware feature that have only seldom been used.

What I meant is that it's a programming trick using the hardware that's already available. Strictly speaking, everything is a hardware feature, since you can't make an NES game without the hardware (CPU, PPU, etc.). But once the hardware is set in stone (the console, the mapper, the controllers), everything you do from there is software. Cleverly using the hardware that's available to you is different from throwing in new hardware to solve a problem.


Top
 Profile  
 
PostPosted: Thu Oct 04, 2018 10:09 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6875
Location: Canada
You can search for MMC3 + CHR-RAM on bootgod's database.

The primary candidates here are Mega Man 4 and 6. I don't think either of this does any CHR bankswitching, but that's a research question that more or less requires playing through both games with a debugger open. (It could easily have been relevant for some animated nametable boss, for example.)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 56 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group