PowerPak and BootROM Questions

Can user-made mappers for the PowerPak directly access the 32KB WRAM pins? They don't seem to be in the FPGA pinout, even though it has support for WRAM. Does the "glue logic" mentioned in RetroUSB.com's description for the PowerPak connect with those pins?

Can the FPGA support more RAM? According to the CNROM sample project summary, only 4KB out of the 6KB RAM in the FPGA is used (the "FRAM" in the schematics), so does that mean that user-made mappers can use 2 more KB of FPGA RAM, or is that reserved for the BootROM?

How should custom games load up the BootROM modules? Examining the Introducing the NES PowerPak thread, it seems as if the BootROM's code (not the modules, I know they are loaded from the CF card) is at around $Fxxx, but I don't think there was actual source code for the BootROM released online, just the BootROM itself. Correct me if I am wrong about any of this.

The WRAM is accessed through the same pins as the PRG, cept there is WRAM /EN. Data bus and address bus are the same.




Yes mappers can use the additional block RAM, I haven't tried it tho. The RAM can either be used on the CHR or PRG side. Nothing is reserved for the boot rom once the game is running.



This is all theoretical, havent tried it and not sure it can actually work... The game would have to load/jump to temp code into internal ram, write to a register to enable the boot rom, then jump to a boot rom procedure. Your app would have to not use the spaces in ram the boot rom uses for variables. All the FAT handling uses lots of the internal/prg/wram space so it may be hard to avoid that. It may be possible for your game to save some of the variables on start up (like game starting sector) so the FAT stuff isnt needed as much.

Theoretically, if a mapper is messing with WRAM pins while the NES's CPU is accessing PRG RAM (not the WRAM), and since the PRG RAM and WRAM chips share the same cart PRG input/output pins, would that cause bus conflicts with the NES PRG input/output?

bunnyboy, have you been considering to release some of the BootROM source code and/or register set soon, if ready? I was thinking about using the BootROM to load up user-designed modules to the internal RAM to update small chunks of PRG and CHR RAM as a way to extend the 512KB limit for PRG and CHR RAM.

That sounds kind of like how calls to ProDOS on the Apple II family work. On the II Plus, IIe, and IIc, $0000 to $BFFF is RAM, $C000-$CFFF is I/O, and $D000-$FFFF is switchable between a 12 KB RAM, an extra 4 KB RAM, and BASIC ROM. ProDOS loads itself into RAM at $D000-$FFFF and places a dispatcher and a few other variables at $BF00-$BFFF. This dispatcher handles juggling the RAM and ROM bankswitching.

Well, as far as I know, all cartridges have WRAM and PRG on the same address and data bus. As long as the /CE lines for the two chips aren't activated simultaneously, there should be no bus conflict.