It is currently Tue Oct 17, 2017 6:28 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Feb 10, 2014 5:46 am 
Offline

Joined: Thu Dec 12, 2013 4:00 pm
Posts: 40
As you are most likely aware, I have an INL-ROM board with the flash upgrade and Sunsoft 5B support (including full sound), and my ultimate goal with it is to make a Gimmick repro-cart. However, I wanted to test the cart before I actually put Gimmick onto it. Since I don't want to test JUST Sunsoft 5B games (i.e. Return of the Joker), I also wanted to test some NROM games (i.e. Super Mario Bros.) Then I found out that I needed to modify the ROM to get it working with 5B. What's the bare minimum I need to do in order to get Super Mario Bros. working on the Sunsoft 5B?

Also, somewhat related: Is there a test program for the Sunsoft 5B/FME-7 out there?

_________________
For some reason, I seem to have a lot of luck with NES-related stuff.

There are two kinds of people in this world: those who are convinced there are two kinds of people in this world, and those who aren't. - Unknown


Last edited by DevEd on Mon Feb 10, 2014 9:01 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Feb 10, 2014 8:15 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
You have to initialize the PRG and CHR banks so that they are mapped to the correct locations. To do that, you must first find some empty space in the last (hardwired) bank. This might not be easy, since SMB is prety tightly packed, so you might have to overwrite something (a level, a song, something like that).

Once you find a few consecutive bytes you can overwrite, you must change the reset vector (the 2-byte value at $FFFC-$FFFD) to point to this location, because you want the new code to run as soon as the program starts. Take note of the old reset vector, because you'll need to jump to it later so that the original code can run after you have configured the mapper.

Now, if you look at the documentation you'll see that the NES communicates with this mapper by sending it a command number and them a parameter to complete each command. Just use that information to set all PRG and CHR bank registers. Something like this:
Code:
   ;map PRG bank 0 to $8000-$9fff
   lda #$09
   sta $8000
   lda #$00
   sta $a000

   ;map PRG bank 1 to $a000-$bfff
   lda #$0a
   sta $8000
   lda #$01
   sta $a000

   ;map PRG bank 2 to $c000-$dfff
   lda #$0b
   sta $8000
   lda #$02
   sta $a000

This is easy but needs a lot of space, you could make it more compact if you used tables and/or loops.

After the banks are in place, you also have to initialize the mirroring. Mirroring is controlled by register $0c. To set the mirroring to vertical you have to do this:
Code:
   ;set mirroring to vertical
   lda #$0c
   sta $8000
   lda #$00
   sta $a000

After setting PRG, CHR and mirroring you can jump to the original initialization code (I think you can get away with not initializing the IRQ registers, but if you do run into problems you should consider initializing all the registers), and the game will work as if it were in an NROM cart.

Note: If you can't find space for the mapper configuration and you don't want to overwrite anything, you can always increase the amount of PRG-ROM, move (some of) the original initialization code from the fixed bank to a new bank (where your new initialization code will be), and use the space you freed up on the hardwired bank to switch the new bank and jump to it.


Top
 Profile  
 
PostPosted: Mon Feb 10, 2014 9:01 am 
Offline

Joined: Thu Dec 12, 2013 4:00 pm
Posts: 40
So I've got the code I need assembled and ready for inserting, however, I still have no idea HOW to insert the code. I want to expand the ROM so I don't have to overwrite anything, but I have no idea how to do that. Also, I couldn't find the "reset vector". What offset is it located at in Super Mario Bros.?

EDIT: Changed topic title.

_________________
For some reason, I seem to have a lot of luck with NES-related stuff.

There are two kinds of people in this world: those who are convinced there are two kinds of people in this world, and those who aren't. - Unknown


Top
 Profile  
 
PostPosted: Mon Feb 10, 2014 9:40 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
DevEd wrote:
I want to expand the ROM so I don't have to overwrite anything, but I have no idea how to do that.

To keep the ROM a power of 2, put 32KB of "nothing" between the header and the original 32KB of PRG-ROM. Don't forget to update the PRG-ROM page count in the header.

Quote:
Also, I couldn't find the "reset vector". What offset is it located at in Super Mario Bros.?

16 bytes of header + 32768 bytes of PRG-ROM - 2 bytes of the IRQ vector - 2 bytes of the reset vector = 32780, which is $800C in hex.

But since you're going with ROM expansion, you shouldn't change the address of the reset vector, you should change the routine itself. Go to the address indicated in the reset vector and cut enough of the reset routine to insert a switch to the new bank where your initialization will be. The code will look something like this:
Code:
   lda #$09 ;prepare to map a bank to $8000-$9fff
   sta $8000
   lda #$00 ;map the initialization bank
   sta $a000
   jmp NewResetHandler ;call the new initialization routine
ResumeOriginalProgram:
   sta $a000 ;map the original SMB bank

That may require you to move 16 bytes of code from the fixed bank to the new initialization bank, if you can't find that much free space in the fixed bank. That last mapper write (the one after the ResumeOriginalProgram label) must be in the hardwired bank because your initialization bank will be switched out so that the original SMB bank can be mapped in, and you can't have a bank switch itself out or the program would crash, so you can prepare the switch in that bank, but the command must be finalized in the hardwired bank, after you've mapped everything else.


Top
 Profile  
 
PostPosted: Mon Feb 10, 2014 9:59 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19085
Location: NE Indiana, USA (NTSC)
Code similar to what I posted for an MMC3 conversion should work, so long as you can find 32 bytes. Untested:
Code:
  ldx #12
loop:
  stx $8000
  lda mmc3tbl,x
  sta $A000
  dex
  bpl loop
  jmp rest_of_reset
  ; A=$00 and X=$FF at end, so ready for $2000/$2001 writes and TXS
fme7tbl:
  ; the 13 parameters are eight 1K banks for CHR ROM $0000-$1FFF,
  ; four 8K banks for CHR ROM $6000-$DFFF, and nametable mirroring type
  ; see http://wiki.nesdev.com/w/index.php/Sunsoft_FME-7
  .byt 0,1,2,3,4,5,6,7,  3,4,5,6,  0


Top
 Profile  
 
PostPosted: Mon Feb 10, 2014 10:08 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5709
Location: Canada
If you're looking for games just for testing, try FDS games. They won't touch the fixed bank area at $E000-FFFF so you can be free to put your startup code there. There are probably at least a few FDS games that would work, look for ones that aren't writing to the FDS' special RAM areas. Can the INL board do PRG-ROM at $6000?

Also, I'm slightly relieved on opening this thread that you're using an INL board and not taking apart an original FME-7 board. :)


Top
 Profile  
 
PostPosted: Mon Feb 10, 2014 11:39 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19085
Location: NE Indiana, USA (NTSC)
If you just want something for testing, try Holy Diver Batman. It should run on both Holy Diver boards (#78.3) and Batman: Return of the Joker boards (#69) like the one you have.


Top
 Profile  
 
PostPosted: Tue Feb 11, 2014 5:51 am 
Offline

Joined: Thu Dec 12, 2013 4:00 pm
Posts: 40
rainwarrior wrote:
Also, I'm slightly relieved on opening this thread that you're using an INL board and not taking apart an original FME-7 board. :)


I don't have an original FME-7 board, so taking apart one would be impossible. but if I had Return Of The Joker... >:}

tepples wrote:
If you just want something for testing, try Holy Diver Batman. It should run on both Holy Diver boards (#78.3) and Batman: Return of the Joker boards (#69) like the one you have.


Holy Diver, Batman! I'll have to give that a try at some point.

EDIT: Also, A) I STILL don't have an NES for testing, and B) I'm probably going to have to take apart a cartridge in order to put the INL-ROM board into the NES.

_________________
For some reason, I seem to have a lot of luck with NES-related stuff.

There are two kinds of people in this world: those who are convinced there are two kinds of people in this world, and those who aren't. - Unknown


Top
 Profile  
 
PostPosted: Tue Feb 11, 2014 12:19 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2799
No one mentioned this yet but FME-7 supports mapping ROM to $6000-$7FFF which could be helpful. SMB resets to $8000, which won't work for the FME-7 which only fixes $E000-$FFFF. If you can find one of the reverse engineered source codes to the game, you should find some area in $E000-$FFFF that is either a routine or data set that you can find all the other references to, and alter those references to find the same thing somewhere in $6000-$7FFF where you will move it to. Then you can reuse the space in that last bank for your reset vector and calling an init routine that could also be in the $6000 bank.

Since the source code is around it shouldn't be too hard.


Top
 Profile  
 
PostPosted: Tue Feb 11, 2014 1:33 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
Excellent points, MottZilla. You must have the reset vector point to somewhere in the last PRG bank where you can find (or create, by moving something to the new bank and fixing any references to the moved code/data) enough room for the code that maps the new bank to $6000-$7FFF and jumps to the mapper setup code in it. After the whole configuration is done you can just JMP to $8000 to resume the original program.


Top
 Profile  
 
PostPosted: Tue Feb 11, 2014 3:13 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5709
Location: Canada
If you used the FDS version of Super Mario Bros. the relocation from $E000-FFFF to $6000-7FFF might already be done for you...


Top
 Profile  
 
PostPosted: Wed Feb 12, 2014 5:37 am 
Offline

Joined: Thu Dec 12, 2013 4:00 pm
Posts: 40
I'm sorry, but I fail to comprehend the concept of a FDS game running on a cartridge on an NES.

Also, doesn't the FDS use its own mapper?

_________________
For some reason, I seem to have a lot of luck with NES-related stuff.

There are two kinds of people in this world: those who are convinced there are two kinds of people in this world, and those who aren't. - Unknown


Top
 Profile  
 
PostPosted: Wed Feb 12, 2014 6:23 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19085
Location: NE Indiana, USA (NTSC)
Games can be ported from one mapper to another. Dragon Quest and Maniac Mansion were ported from discrete mappers to MMC1 when brought to 72-pin land so that they could use battery RAM. Family Computer Disk System (FDS) games like Pro Wrestling, Zelda, Metroid, Kid Icarus, and Doki Doki Panic were ported to a cartridge mapper (UNROM, MMC1, or MMC3) when brought to 72-pin land. Tetris was ported from MMC1 to MMC3 to fit on the multicart with Super Mario Bros. and Nintendo World Cup, and Dr. Mario appears to have been ported from MMC1 to MMC3 for one of the official competition multicarts. Nintendo ported SMB1 to FDS, and pirates did the opposite for SMB2 (J).

The claim made here is that porting certain FDS games to FME-7 could be almost trivial.


Top
 Profile  
 
PostPosted: Wed Feb 12, 2014 6:31 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5709
Location: Canada
The FDS is a cartridge full of RAM that plugs into a Famicom. The disk drive part is only used to load data into that RAM, so aside from the loading part, it's just a cartridge. Yes, it is its own mapper, but a lot of its games don't use most of its features, especially if they were originally NROM games like Super Mario Bros..

The reason I'm suggesting it is that its mapper design has some similarities to the FME-7. It has a "fixed" ROM at $E000-FFFF which was used for its BIOS code, and for this reason an NROM game ported to FDS will have its data already relocated from there, usually to $6000-7FFF. If the game was only a 32k/16k PRG NROM, usually this will be loaded into the FDS once at startup and after that no other FDS mapper features will be needed, so at that point it's effectively a mapper very much like our proposed NROM-368.

Open the Super Mario Bros. FDS in an emulator and let it run until the game loads (e.g. get to the title screen), then do a memory dump from $6000-DFFF and you'll have all the data you need to build your PRG ROM. (Dump the 8k of CHR memory as well.) From there, just write a small startup program in the $E000-FFFF fixed bank that sets up your banks and nametable mirroring then jumps to Mario's code, and a vector table for NMI etc.

For an FDS game to be suitable for a trivial conversion to FME-7, it should meet the following criteria, which I believe SMB does:

1. Only loads data once. (If it loads data multiple times, you could write a replacement for the BIOS' loading code.)
2. Outside the initial data load, never writes to $6000-DFFF. (The FDS has RAM here so it's technically writable. You could use PRG-RAM at $6000-7FFF and load it manually for your FME-7 port. Ram writes at $8000-DFFF are non-portable, but likely extremely rare.)
3. Doesn't use the FDS' IRQ. (You could probably write a replacement with FME-7's IRQ but takes more work.)
4. Doesn't change nametable mirroring. (Requires replacing FDS mirror toggling code with FME-7 mirror toggling code.)
5. Doesn't use the FDS expansion audio. (We have a list of those games here. This isn't much of a problem except that the extra audio won't play. I don't think the register writes are in conflict with the FME-7.)
6. The code in $6000-DFFF never calls BIOS code. (I.e. the code never jumps back to $E000-FFFF after the initial load. If it does, you'll need to write a replacement routine in the fixed bank.)
7. Doesn't write to CHR-RAM after load. (You could possibly run the FME-7 with CHR-RAM? Loading it then requires extra code.)
8. Doesn't write directly to nametable from load. (The FDS BIOS routines can load data from disk directly to the nametable. Requires extra code to duplicate this functionality.)

You can verify each of these things pretty easily with breakpoints in a debugging emulator like FCEUX. If all of the criteria are met, the port should to FME-7 be extremely easy. Even if they aren't met, they can each be overcome (except the missing audio, or possibly RAM use at $8000-DFFF) with a little work.


Top
 Profile  
 
PostPosted: Wed Feb 12, 2014 10:38 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10046
Location: Rio de Janeiro - Brazil
tepples wrote:
Dragon Quest and Maniac Mansion were ported from discrete mappers to MMC1 when brought to 72-pin land so that they could use battery RAM.

I seriously doubt Maniac Mansion was ported... The Japanese and American releases are completely different games.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  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:  
Powered by phpBB® Forum Software © phpBB Group