Based on a thread in the nesdev forum, I'm interesting in trying to figure out whether its possible to create a special mapper.
Basically this mapper would allow RAM to be switched between PRG RAM and CHR RAM. So one bank becomes used as CHR Tiles, while another now becomes accessable as PRG RAM. Even though both could be accessable through the code, the primary purpose is to do updates to the PRG RAM region and then mapper switch that in for use by the PPU during vblank.
A primary rule of NES coding is to not touch the memory being used by the PPU. By swapping between these 2 RAM blocks, we would not violate this rule.
The value of this mapper becomes that you can alter an entire set of CHR Tiles outside of VBlank, since they can be swapped in on the next vblank. Great for animations. Really great for fighting games.
So what are the show stoppers here? Is there some fundamental reason that this type of mapper has never been done?
If there are no show stoppers, what would be the appropriate first steps in trying to create it ? (I assume it would be to emulate it but my knowledge in mappers and/or chip design is basic to say the least)
Al
I have had a similar idea for a long time, which would involve making a mapper that simulates dual-ported memory by providing two address/data buses for the CPU and PPU on one side and a single address/data bus on the other. This would have the benefit that you could use just one memory chip in the cart if you only need ROM, or two if you need both ROM and RAM. (for both CPU and PPU)
The fundamental reasons might be:
* Difficulties of developing it. It will be quite a lot harder to get things right than for your general UNROM-clone.
* Cost of logic. Whether you use a CPLD with lots of pins or a lot of TTL chips to accomplish this, it will be significantly more expensive than doing a simple mapper. So if you can live with the limitations of cheaper solutions, it'll be more fun to sell your carts on eBay when you can minimize the production costs.
* Applicability
Before spending too much of your free time engineering something like this (which is always more boring than imagining it :) you should ask yourself what purpose you need it for? Do you have a superb idea in mind that just couldn't be pulled off the usual way? If not, why do all that work?
Personally, I'll need to find a way to solve the complex problem my puzzle game requires on a PC before I can even consider implementing it on the NES. And thus, simply knowing that it's possible to pull off is enough. Though on the other hand, relying on something which hasn't been proven to work yet is risky as well.
Besides, for a 1-on-1 fighting game, what advantage would a complex CHR-RAM method like this have over using bankswitched CHR-ROM? The latter would both be significantly cheaper AND give you lots of more cycles for game logic. Don't do memory copies unless you really have to.
You cannot access the same single port memory by two devices at a time. It doesn't matter if it's the bank the PPU is using or not, the PPU is using the address and data bus which are necessary to get data in and out of the RAM.
In the other thread I described a mapper which has two CHR RAMs, one of which is mapped to the CPU, the other to PPU, but they can switch which one is mapped where. When you write to the one on the CPU, the one on the PPU doesn't get written. This still allows you to write a lot of tiles outside of vblank and switch the RAM onto the PPU before rendering. It would also be possible to tie the two RAMs together so that you can write to both RAM's at a time to add in new tiles you want on both RAMs without having to write them twice.
There is a lot of overhead because sometimes you'll need to catch just one RAM up to the other, but it may be worth it to someone clever since it allows you to update more tiles at the expense of CPU time instead of Vblank time.
> You cannot access the same single port memory by two devices at a time.
> It doesn't matter if it's the bank the PPU is using or not, the PPU is using the
> address and data bus which are necessary to get data in and out of the
> RAM.
I beg to differ. The trick would be to have internal logic that would latch the data requested by the CPU or PPU and read the memory bus on the other side as soon as a previously scheduled fetch has ended. This of course, requires the memory access times to be significantly shorter than the minimum specified for both the CPU and PPU. Not mentioning that the rules for prioritizing the memory requests for the CPU and PPU would be quite complex. But I see no reason why it wouldn't be doable.
Practical, on the other hand...
kyuusaku wrote:
You cannot access the same single port memory by two devices at a time. It doesn't matter if it's the bank the PPU is using or not, the PPU is using the address and data bus which are necessary to get data in and out of the RAM.
In the other thread I described a mapper which has two CHR RAMs, one of which is mapped to the CPU, the other to PPU, but they can switch which one is mapped where. When you write to the one on the CPU, the one on the PPU doesn't get written. This still allows you to write a lot of tiles outside of vblank and switch the RAM onto the PPU before rendering. It would also be possible to tie the two RAMs together so that you can write to both RAM's at a time to add in new tiles you want on both RAMs without having to write them twice.
There is a lot of overhead because sometimes you'll need to catch just one RAM up to the other, but it may be worth it to someone clever since it allows you to update more tiles at the expense of CPU time instead of Vblank time.
Using 2 chips is fine by me especially if it makes the logic easier. 8K RAM chips are easy to come by. I personally wouldnt worry about being able to write to both at once, but thats just me.
Bananamos, the main value of this to a fighting game is ( to put it honestly) I can be lazy or sloppy in my coding. To put it in more favorable terms, it adds a lot more possibilities.
Example: If I want to use all 64 sprites for the 2 fighters, I can devote a full 32 tiles per fighter. I would no longer have to worry about optimizing tile updates, figuring out or designing fighter positions that re-use tiles from other positions, etc..
Al
You *are* aware that copying 64 tiles from one memory location to another would take more than 25% of the CPU cycles in a frame? That means being sloppy in this place only means you'll have to do better in other places, such as doing all other game routines in 75% of the total cycles you could have otherwise.
I'm a big fan of CHR-RAM myself but it really seems like bankswitched CHR-ROM would be the way to go for your project, since a cheap MMC3 board would let you switch all those 64 tiles in no time. That is, unless you desperately want the possibilities only CHR-RAM can provide for some intro effects or whatever.
Do ask yourself: will you actually be prepared to build and manufacture this expensive board *only* to be able to write more sloppy code (and get > 25% of the cycles wasted as a drawback) I'm betting that just like many ideas I've had, this one will remain at the planning stage. But I'd be happy to be proven wrong. :)
And if you're just prepared to waste some CHR-ROM space, there's no need to optimize your tiles the way you mention. Have you ever seen how much duplicated tiles many of the CHR-ROM games have? Being an advocate of efficiency, you are at first appalled by this solution. But then you slowly realize that using complex logic (which may increase the board's cost more than doubling your CHR-ROM size) isn't necessarily a better solution.
(though it is undoubtedly more cool to engineer your own hardware)
Bananmos wrote:
You *are* aware that copying 64 tiles from one memory location to another would take more than 25% of the CPU cycles in a frame? That means being sloppy in this place only means you'll have to do better in other places, such as doing all other game routines in 75% of the total cycles you could have otherwise.
I dont mind the 25% so long as I can cram everything in the 100%.
Bananmos wrote:
I'm a big fan of CHR-RAM myself but it really seems like bankswitched CHR-ROM would be the way to go for your project, since a cheap MMC3 board would let you switch all those 64 tiles in no time. That is, unless you desperately want the possibilities only CHR-RAM can provide for some intro effects or whatever.
I'm just looking for a solution that allows me to overcome my tile limitations. If I can do this using MMC3 I'll likely go that route.
I dont think MMC3 boards can be mass produced either though.
Bananmos wrote:
Do ask yourself: will you actually be prepared to build and manufacture this expensive board *only* to be able to write more sloppy code (and get > 25% of the cycles wasted as a drawback) I'm betting that just like many ideas I've had, this one will remain at the planning stage. But I'd be happy to be proven wrong.
The good news I think is that there are no technical reasons this cant be done. But you are likely right, odds are I will not do it. I just wanted to know the idea was feasable in case I try.
Thanks for all the input. If I go anywhere with this, I'll post about it.
Al
albailey wrote:
I'm just looking for a solution that allows me to overcome my tile limitations. If I can do this using MMC3 I'll likely go that route.
Let me just start by saying that I do not want to ruin your thread or anything, I just want to help. Do you mind giving a few more details about the project you are working on that makes you think that this new mapper is the solution for you? I'm asking because it's very likely that there are (much) easier ways to solve the problem, but we have to know more about it. Do you mind sharing or is it "top secret"? Is it a fighting game? If it is, I'm sure the MMC3 can handle it just fine.
Quote:
I dont think MMC3 boards can be mass produced either though.
This new cart seems just as hard (if not harder) to reproduce...
You guys can consider this thread finished.
As for the game. I'm in design paralysis for over a month now on my fighting game.
If I make my fighters 4x4 tiles(32x32 pixels) I can have at most 8 positions (since I have 2 fighters).
I already know that I can squeeze out more positions if I re-use tiles that are the same in separate positions (blank space, the head, etc..)
But even then I "might" be able to get 12 positions per fighter.
I've also been reading how you were able to squeeze in 16 tile updates during the vblank. This could be the "cure" as long as I alternate between fighters. Meaning I change player 1's position on odd frames and player 2 on even ones.
I just wanted to see what other options existed. (Namely hardware options).
Al
At how many frames per second are your fighters animated?
SInce I am no longer seeking a hardware solution, I should probably answer your question in my nesdev thread. But basically I dont have a set framerate in mind, so long as it seems smooth. I'd be willing to go every 2 frames, 4 frames or whatever seems nice and playable.
Al