Emulating 32 KB PRG RAM
Moderator: Moderators
-
- Posts: 11
- Joined: Sat May 15, 2021 11:15 am
Emulating 32 KB PRG RAM
I want to emulate 32 KB of PRG RAM instead of 8 on FCEUX, Mesen or something else. How can i do that? What mapper do i need?
That RAM should be mapped from $4020 through $BFFF.
(I use only 16 KB of ROM, so the space beetween $4020 through $BFFF is free.)
That RAM should be mapped from $4020 through $BFFF.
(I use only 16 KB of ROM, so the space beetween $4020 through $BFFF is free.)
Re: Emulating 32 KB PRG RAM
It will be unusual to find a mapper that uses $4000-5FFF for RAM or ROM. Refer here for mappers that support large PRG-RAMs:
https://wiki.nesdev.com/w/index.php/Cat ... ge_PRG_RAM
Is there any reason you want a 32 kilobyte contiguous chunk of RAM instead of doing bankswitching? That would probably open up your options.
MMC5 has 5 8-kilobyte banks in mode 3:
6000-7FFF Always RAM
8000-9FFF Configurable to RAM or ROM
A000-BFFF Configurable to RAM or ROM
C000-DFFF Configurable to RAM or ROM
E000-FFFF Always ROM
Also: 5C00-5FFF can be configured as RAM.
This would allow a couple close options for you:
RAM from $5C00-BFFF (25 kilobytes) and ROM from $C000-FFFF (16 kilobytes)
RAM from $5C00-DFFF (33 kilobytes) and ROM from $E000-FFFF (8 kilobytes)
I am not aware of any other mapper that can map RAM to such a large area. If you are okay with bankswitching, that can vastly increase the space and probably allow you to use simpler mappers. MMC1 would be a very good candidate but you would have to use RAM only in the range $6000-7FFF and bankswitch it to get the full 32 kilobytes.
https://wiki.nesdev.com/w/index.php/Cat ... ge_PRG_RAM
Is there any reason you want a 32 kilobyte contiguous chunk of RAM instead of doing bankswitching? That would probably open up your options.
MMC5 has 5 8-kilobyte banks in mode 3:
6000-7FFF Always RAM
8000-9FFF Configurable to RAM or ROM
A000-BFFF Configurable to RAM or ROM
C000-DFFF Configurable to RAM or ROM
E000-FFFF Always ROM
Also: 5C00-5FFF can be configured as RAM.
This would allow a couple close options for you:
RAM from $5C00-BFFF (25 kilobytes) and ROM from $C000-FFFF (16 kilobytes)
RAM from $5C00-DFFF (33 kilobytes) and ROM from $E000-FFFF (8 kilobytes)
I am not aware of any other mapper that can map RAM to such a large area. If you are okay with bankswitching, that can vastly increase the space and probably allow you to use simpler mappers. MMC1 would be a very good candidate but you would have to use RAM only in the range $6000-7FFF and bankswitch it to get the full 32 kilobytes.
-
- Posts: 11
- Joined: Sat May 15, 2021 11:15 am
Re: Emulating 32 KB PRG RAM
Yes. It's for testing purposes.Ben Boldt wrote: ↑Sun May 16, 2021 9:41 am It will be unusual to find a mapper that uses $4000-5FFF for RAM or ROM. Refer here for mappers that support large PRG-RAMs:
https://wiki.nesdev.com/w/index.php/Cat ... ge_PRG_RAM
Is there any reason you want a 32 kilobyte contiguous chunk of RAM instead of doing bankswitching? That would probably open up your options.
Re: Emulating 32 KB PRG RAM
If you want to create something that has never existed on any cartridge (RAM available at 4020-5FFF region), you can modify an emulator yourself. You can even expand the base console RAM from 2K to 8K, and remove the memory mirroring.
But what kind of project needs this?
But what kind of project needs this?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: Emulating 32 KB PRG RAM
Sounds like you need to make your own mapper, using a customized version of the emulator.
But there's a reason why mappers that use the 4xxx range are basically nonexistant.
A cartridge decoding 4020+ to be RAM would need to look at 11 address bits, and run combinational logic (AND, OR, NAND, etc) on it to see if it is in range or not, then generate the 'chip enable' bits that the RAM chip would need to see.
If you were making something like this today, you'd use a CPLD chip to check 11 bits.
It would be a lot of hardware for an NROM-like mapper, but with RAM. Hence why nobody wanted to build cartridges that would check the 4020-4FFF page (one exception, the Famicom Disk System).
Decoding 5000+ would require only 4 address bits rather than 11 address bits. And even that was too much for most mappers.
But there's a reason why mappers that use the 4xxx range are basically nonexistant.
A cartridge decoding 4020+ to be RAM would need to look at 11 address bits, and run combinational logic (AND, OR, NAND, etc) on it to see if it is in range or not, then generate the 'chip enable' bits that the RAM chip would need to see.
If you were making something like this today, you'd use a CPLD chip to check 11 bits.
It would be a lot of hardware for an NROM-like mapper, but with RAM. Hence why nobody wanted to build cartridges that would check the 4020-4FFF page (one exception, the Famicom Disk System).
Decoding 5000+ would require only 4 address bits rather than 11 address bits. And even that was too much for most mappers.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: Emulating 32 KB PRG RAM
For what it's worth, the Famicom Disk System puts RAM at $6000-$DFFF (and its BIOS at $E000-$FFFF), and it also provides subroutines for commonly-performed actions like disk I/O.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: Emulating 32 KB PRG RAM
It might be worth thinking about how to design your OS with bankswitching in mind. That will make it much more expandable, which usually becomes an important thing with OSs. The OS or the resident program could be in charge of bankswitching; that's a design choice. If you use the MMC5, a scheme like this might be reasonable:
- $0000-0800 (2k NES internal RAM) - dedicated to the OS.
- $6000-7FFF (8k RAM) - dedicated for resident program's read/write RAM.
- $8000-BFFF (16k RAM) - dedicated for resident program's program data.
- $C000-FFFF (16k ROM) - dedicated to OS program code.
How do you plan to load software? Would you be thinking about the Family Basic tape drive? I don't think FDS can work with your application because that occupies the cartridge slot and already has its own OS like Quietust pointed out. Famicom network system has some potential if you were to create a special card and load your programs over a network connection. But we don't know enough about Famicom network system to be able to do something like that yet. (Hopefully we do someday though.)
- Jarhmander
- Formerly ~J-@D!~
- Posts: 568
- Joined: Sun Mar 12, 2006 12:36 am
- Location: Rive nord de Montréal
Re: Emulating 32 KB PRG RAM
Well, you can't make such "clean" memory segmentation, because both the OS and the programs needs to access zero page (indirection!) and the stack.
((λ (x) (x x)) (λ (x) (x x)))
Re: Emulating 32 KB PRG RAM
Good point.
Re: Emulating 32 KB PRG RAM
Fukutake Study Box
fds system
MMC5
These are the PRG ram mapping methods you can refer to.
FDS is the simplest implementation of $6000 - $dfff.
fds system
MMC5
These are the PRG ram mapping methods you can refer to.
FDS is the simplest implementation of $6000 - $dfff.