GTROM 4-Screen Mirroring + Bankswitching Test

CutterCross

Active member
Okay I'm not sure how this is going to fit in on this forum seeing how it's not NESmaker related, but I know a decent amount of users here might be interested in stuff like this. This may need to be moved to a specialized category.

View: https://www.youtube.com/watch?v=KCQaO61_ahY


I'm experimenting with traditional NESdev and other mapper types. I finished a test project that uses GTROM as its mapper. GTROM has dedicated memory to fill all 4 PPU nametables with unique data, and it can hold 2 pages of 4-screen nametable data that can be swapped into the PPU memory window on the fly. It also has two 8 KiB pages of CHR-RAM, as opposed to UNROM 512's four 8 KiB pages. GTROM also has 2 LEDs [green and red] on the board that can be controlled, but no emulator / flashcart implementation supports this.

GTROM's most difficult aspect to develop for is it's 32 KiB PRG-ROM page size. UNROM 512 has a 16 KiB page size, and this allows for one 16 KiB bank to remain loaded for the entire program, and the other 16 KiB can be swapped out with other banks. This "static bank" layout can't be done with GTROM, because it can only bankswitch the entire 32 KiB. So to work with this, you have to duplicate your "static" data in the same locations on every bank, and be very careful in its setup so that your program doesn't crash upon switching banks.

This ROM tests the 4-screen mirroring setup and nametable page toggle, as well as the 32 KiB page bankswitching via 7bit PCM streaming. The LEDs have toggle support with the B and A buttons, but I have no way of testing this right now until I can get my hands on an actual GTROM board.
 

Attachments

  • GTROM_CC_Test1.zip
    98 KB · Views: 7

Jonny

Well-known member
It's more relevant than some stuff on here! Very interesting read. I wonder why the LEDs where added to the board. Maybe just because they could?
If you can get the schematics and are legally allowed to do it, I'd look into getting your own PCBs made if they're hard to get hold of. That way you would re-design the traces to the LEDs and make the red eyes as part of the label design. Prying Eyes on the cart.... although, not seen in a toaster NES.
 

CutterCross

Active member
It's more relevant than some stuff on here! Very interesting read. I wonder why the LEDs where added to the board. Maybe just because they could?
If you can get the schematics and are legally allowed to do it, I'd look into getting your own PCBs made if they're hard to get hold of. That way you would re-design the traces to the LEDs and make the red eyes as part of the label design. Prying Eyes on the cart.... although, not seen in a toaster NES.
Memblers is the designer and main distributer of GTROM boards. https://forums.nesdev.com/viewtopic.php?f=4&t=12716

The main selling point of GTROM is its affordability to manufacture and order. [At the time of this post] UNROM 512 boards from INL are $16 per board. The same boards from Broke Studio and Muramasa are slightly cheaper but there are other factors that could drive up the overall cost. [Shipping from overseas, boards not pre-assembled, etc.] The last quote I could find from Memblers about GTROM boards are around the $9 - $10 mark from 2019.

The affordability is one of the main reasons I considered developing for it in the first place. The 8 KiB of onboard nametable RAM is completely overkill for what any of my projects would use, and the reduced 16 KiB of CHR-RAM would make it less appealing to me. My other main draw is it's famiclone-compatible configuration. [It doesn't really have a proper name, but I'll abbreviate it to GTROM-FCC.] This configuration sacrifices its extended nametable RAM for compatibility with famiclone systems that don't allow the onboard nametables to be replaced. So it's back to standard horizontal / vertical mirroring for nametables, but you get a full 32 KiB of CHR-RAM in return. GTROM-FCC is what I ultimately want to work with for something like Prying Eye. But there's currently no Mesen / INLretro support for development of that. It's something I should bring towards the NESdev community in hopes for a call-to-action to get proper development support for it.
 
Last edited:
Top Bottom