It is currently Tue Jun 18, 2019 1:36 am

All times are UTC - 7 hours



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 new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Tue May 03, 2016 8:44 am 
Offline

Joined: Mon May 02, 2016 6:12 pm
Posts: 7
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.

Top
 Profile  
 
PostPosted: Tue May 03, 2016 8:49 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21440
Location: NE Indiana, USA (NTSC)
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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue May 03, 2016 9:26 am 
Offline

Joined: Mon May 02, 2016 6:12 pm
Posts: 7
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


Top
 Profile  
 
PostPosted: Tue May 03, 2016 9:41 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21440
Location: NE Indiana, USA (NTSC)
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.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Tue May 03, 2016 10:20 am 
Offline

Joined: Mon May 02, 2016 6:12 pm
Posts: 7
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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