SOLVED-Super Mario Bros. nrom conversion glitches

A place that you can discuss reproduction of classic titles or "licensed-for-reproduction" homebrew for personal use.

Moderators: B00daW, Moderators

Forum rules
1. NO BLATANT PIRACY. This includes reproducing homebrew less than 10 years old, with the exception of free software.
2. No advertising your reproductions, with the exception of free software.
3. Be nice. See RFC 1855 if you aren't sure what this means.
Post Reply
SMBRAR
Posts: 7
Joined: Mon May 02, 2016 6:12 pm

SOLVED-Super Mario Bros. nrom conversion glitches

Post by SMBRAR »

So I have a gyromite that I decided to convert to SMB. This is the 1st time I tried this. When I programmed the 27c256's I was sleep deprived and my math is bad to begin with.

I programmed the PRG and CHR file once each to the 1 time programmable 27c256's, the result was the game functioning, but with black background and mario/enemy sprites were orange blocks. I should mention I swapped the H mirroring that gyromite uses to the V mirroring.

I later read that it was important to fill the chip, I got another 27c256 and quadrupled the 8kb CHR file by the windows copy command (copy/b smb.nes.chr + smb.nes.chr + smb.nes.chr +smb.nes.chr smb32.nes.chr)

The result afterwards was everything behind mario from the center position of screen displaying the screen ahead off screen. So the future was behind mario basically. It seems to be related to the Horizontal / Vertical position. Its playable that way with constant forward progression.

Am I confusing kilobits and kilobytes somewhere? Does anybody have any ideas or advice?
Thanks
Last edited by SMBRAR on Tue May 03, 2016 10:22 am, edited 1 time in total.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Super Mario Bros. nrom conversion glitches

Post by tepples »

Your first attempt
It's not quite as important to double up the CHR ROM if you make sure the unused address lines (A13 and A14 on a 27C256) are tied to ground. Nintendo boards tend to tie unused address lines to +5 V (logical 1), which causes the last 8K of the EPROM to be read instead of the first. (The reasons are probably related to Nintendo's use of mask ROMs from different manufacturers that put +CE on different pins.) If you don't double up CHR ROM, and you don't ground the unused address lines, the PPU will see unprogrammed parts of the EPROM. Unprogrammed parts of an EPROM contain $FF bytes, which the PPU renders as solid blocks of color 3 of each subpalette.

Your second attempt
Map updates down the center line of the screen in Super Mario Bros. are a symptom of wrong mirroring. Your confusion was compounded by the fact that Nintendo and homebrew adopted different naming conventions. NES Game Pak PCBs manufactured by Nintendo use the "arrangement" convention for nametable mirroring, which is opposite to the "mirroring" convention used in the specification of the iNES and NES 2.0 formats. The H pad means the unique nametables are horizontally arranged, side by side, which produces vertical mirroring. Thus the H pad is correct for Super Mario Bros. if using Gyromite or another Nintendo donor.
SMBRAR
Posts: 7
Joined: Mon May 02, 2016 6:12 pm

Re: Super Mario Bros. nrom conversion glitches

Post by SMBRAR »

tepples wrote:Your first attempt
It's not quite as important to double up the CHR ROM if you make sure the unused address lines (A13 and A14 on a 27C256) are tied to ground. Nintendo boards tend to tie unused address lines to +5 V (logical 1), which causes the last 8K of the EPROM to be read instead of the first. (The reasons are probably related to Nintendo's use of mask ROMs from different manufacturers that put +CE on different pins.) If you don't double up CHR ROM, and you don't ground the unused address lines, the PPU will see unprogrammed parts of the EPROM. Unprogrammed parts of an EPROM contain $FF bytes, which the PPU renders as solid blocks of color 3 of each subpalette.
Thank you for sharing your knowledge. It is greatly appreciated. (^ u ^ )
tepples wrote: Your second attempt
Map updates down the center line of the screen in Super Mario Bros. are a symptom of wrong mirroring. Your confusion was compounded by the fact that Nintendo and homebrew adopted different naming conventions. NES Game Pak PCBs manufactured by Nintendo use the "arrangement" convention for nametable mirroring, which is opposite to the "mirroring" convention used in the specification of the iNES and NES 2.0 formats. The H pad means the unique nametables are horizontally arranged, side by side, which produces vertical mirroring. Thus the H pad is correct for Super Mario Bros. if using Gyromite or another Nintendo donor.
:o Once again, thank you for the wisdom. I will go change it back right now. Thanks again !! :D
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Super Mario Bros. nrom conversion glitches

Post by tepples »

Open the NesCartDB page for Super Mario Bros. (U). Click the PCB image at left center to zoom in, and notice that the H pad is bridged. The same is true of the Japanese version.
SMBRAR
Posts: 7
Joined: Mon May 02, 2016 6:12 pm

Re: Super Mario Bros. nrom conversion glitches

Post by SMBRAR »

tepples wrote:Open the NesCartDB page for Super Mario Bros. (U). Click the PCB image at left center to zoom in, and notice that the H pad is bridged. The same is true of the Japanese version.
Thank you, that resource is incredibly helpful. Also, SUCCESS! Works like a charm now. :mrgreen: Thanks again tepples, you are great.
Post Reply