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
SOLVED-Super Mario Bros. nrom conversion glitches
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.
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.
SOLVED-Super Mario Bros. nrom conversion glitches
Last edited by SMBRAR on Tue May 03, 2016 10:22 am, edited 1 time in total.
Re: Super Mario Bros. nrom conversion glitches
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.
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.
Re: Super Mario Bros. nrom conversion glitches
Thank you for sharing your knowledge. It is greatly appreciated. (^ u ^ )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.
Once again, thank you for the wisdom. I will go change it back right now. Thanks again !!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.
Re: Super Mario Bros. nrom conversion glitches
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.
Re: Super Mario Bros. nrom conversion glitches
Thank you, that resource is incredibly helpful. Also, SUCCESS! Works like a charm now. Thanks again tepples, you are great.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.