It is currently Sat Aug 17, 2019 9:52 am

 All times are UTC - 7 hours

 Page 57 of 102 [ 1523 posts ] Go to page Previous  1 ... 54, 55, 56, 57, 58, 59, 60 ... 102  Next
 Print view Previous topic | Next topic
Author Message
 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Fri Dec 14, 2012 9:34 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
Thank you tokumaru and 3gengames!

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Fri Dec 14, 2012 9:47 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11397
Location: Rio de Janeiro - Brazil
3gengames wrote:
It's not right, you have to shift and store it 5 times, remember that!

I was talking about generic register writes, but yeah, since the MMC1 only takes 1 bit of data at a time you have to make multiple writes.

I think unregistered is REALLY confused about how bankswitching works... Let me try to explain it. The 6502 can only see 64KB of memory, because it only has 16 address lines (2^16 = 65536). Only half of that is used to access the ROM, because the other half is used to access RAM and internal registers. 32KB of ROM is not much, and as games became more complex they needed more space.

You can't make the NES see more memory than the 6502 allows, but you can mix and match smaller banks of ROM and make them visible in the available memory range. You'll still see only 32KB at any given time, but you can map different parts of a bigger ROM into those 32KB. Each mapper has different bank sizes and different rules, but one thing that doesn't change is that you need to tell the mappers which banks to put where, and you do that by writing to their registers.

When you try to write to PRG-ROM (\$8000-\$FFFF) the mapper intercepts the writes and redirects them to one of its registers, depending on which address was used for the write. Simple mappers (CNROM, UxROM, AxROM, BxROM, etc.) only have one register, so you can access it by writing to any address between \$8000-\$FFFF. Mappers with more registers break up that space into multiple ranges where the different registers can be accessed.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sat Dec 15, 2012 3:38 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
tokumaru wrote:
3gengames wrote:
It's not right, you have to shift and store it 5 times, remember that!

I was talking about generic register writes, but yeah, since the MMC1 only takes 1 bit of data at a time you have to make multiple writes.

I think unregistered is REALLY confused about how bankswitching works... Let me try to explain it. The 6502 can only see 64KB of memory, because it only has 16 address lines (2^16 = 65536). Only half of that is used to access the ROM, because the other half is used to access RAM and internal registers. 32KB of ROM is not much, and as games became more complex they needed more space.

You can't make the NES see more memory than the 6502 allows, but you can mix and match smaller banks of ROM and make them visible in the available memory range. You'll still see only 32KB at any given time, but you can map different parts of a bigger ROM into those 32KB. Each mapper has different bank sizes and different rules, but one thing that doesn't change is that you need to tell the mappers which banks to put where, and you do that by writing to their registers.

When you try to write to PRG-ROM (\$8000-\$FFFF) the mapper intercepts the writes and redirects them to one of its registers, depending on which address was used for the write. Simple mappers (CNROM, UxROM, AxROM, BxROM, etc.) only have one register, so you can access it by writing to any address between \$8000-\$FFFF. Mappers with more registers break up that space into multiple ranges where the different registers can be accessed.

Ttokumaru, thanks so much for all this info! I can't reply more until Monday.

edit: Sorry tokumaru.

Last edited by unregistered on Mon Dec 17, 2012 10:11 pm, edited 1 time in total.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Dec 17, 2012 11:05 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
tokumaru wrote:
I think unregistered is REALLY confused about how bankswitching works... Let me try to explain it.
Thank you so much tokumaru!!

tokumaru wrote:
When you try to write to PRG-ROM (\$8000-\$FFFF) the mapper intercepts the writes and redirects them to one of its registers, depending on which address was used for the write. Simple mappers (CNROM, UxROM, AxROM, BxROM, etc.) only have one register, so you can access it by writing to any address between \$8000-\$FFFF. Mappers with more registers break up that space into multiple ranges where the different registers can be accessed.

If we use mmc4 which registers does a sprite file use? 3 and 4? It wouldn't want to switch between the sprite and the background file when one of the tiles from rows e and d are used, would it? Does 0fd0 - 0fdf refer to row d of the 4k chr file? If we want to use the same chr file in register 1 and tile d1 is read, does it create a problem with latch 0... or does it stay with the same chr file?

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Dec 17, 2012 11:42 am
 Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2269
Pick MMC3 for IRQ's, or MMC1/UNROM and do sprite 0 hit to find where you need to swap the graphics, as MMC4 isn't easy to prototype on as there's only one game that uses it, and you really don't need it's features unless you're making a game like they did. Basically what you do is do a sprite 0 hit or NMI, then switch the graphics to the appropriate bank for the next scanline to use in the status bar or something.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Wed Dec 19, 2012 5:44 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
3gengames wrote:
Pick MMC3 for IRQ's, or MMC1/UNROM and do sprite 0 hit to find where you need to swap the graphics, as MMC4 isn't easy to prototype on as there's only one game that uses it, and you really don't need it's features unless you're making a game like they did. Basically what you do is do a sprite 0 hit or NMI, then switch the graphics to the appropriate bank for the next scanline to use in the status bar or something.

Thank you 3gengames!

---
Ok here are 2 more questions:
1.)If we use 8kb CHR files... how do you select a tile in the second 4kb half? NESst uses 00 for the first tile of both A and B.
2.)When using MMC1 would it be hard (too slow)... for the cpu to use both 4 and 8 kb files?

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Wed Dec 19, 2012 6:49 pm
 Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2269
On MMC1 you can just write the lower or higher graphics page register to the 4KB graphic page you want, swapping it all out. And as for no mapper using another tile from the opposite side, you can't on the background. You have to either switch the table the graphics use, or swap in the other graphics. Make sense?

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Thu Dec 20, 2012 4:55 am

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11397
Location: Rio de Janeiro - Brazil
unregistered wrote:
1.)If we use 8kb CHR files... how do you select a tile in the second 4kb half?

The background can only use tiles from one of the pattern tables at a time... If you need more than 256 tiles for the background you either have to use the MMC5 (not recommended) or split the screen (with an IRQ or sprite 0 hit) and tell the background to start using tiles from the other pattern table.

Sprites can use patterns from both pattern tables if they're set to the size of 8x16 pixels.

Quote:
When using MMC1 would it be hard (too slow)... for the cpu to use both 4 and 8 kb files?

You should stop thinking about "files". You use files to build the ROM, but once the ROM is ready it's just a bunch of bytes, and the NES has no concept of files whatsoever.

The MMC1 doesn't do anything to help with using more than 256 tiles for the background. It has the capability of bankswitching 4KB or 8KB chunks, but that doesn't affect what the NES can use for backgrounds.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sat Dec 22, 2012 4:02 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
How am I to use the 16kb prg switching part of the memory managenent controller successfully? I understand how the switching works thanks to Matthew J. Richey's document! I am missing knowledge of how to create my .nes rom file program to use a MMC. How do I prepare my code to be used in bank 2 or bank 3?

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Sat Dec 22, 2012 5:42 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
3gengames wrote:
On MMC1 you can just write the lower or higher graphics page register to the 4KB graphic page you want, swapping it all out. And as for no mapper using another tile from the opposite side, you can't on the background. You have to either switch the table the graphics use, or swap in the other graphics. Make sense?
Yes, I think so. Thanks 3gengames.

tokumaru wrote:
unregistered wrote:
1.)If we use 8kb CHR files... how do you select a tile in the second 4kb half?

The background can only use tiles from one of the pattern tables at a time... If you need more than 256 tiles for the background you either have to use the MMC5 (not recommended) or split the screen (with an IRQ or sprite 0 hit) and tell the background to start using tiles from the other pattern table.
This helped me to better understand what 3gengames wrote! Thanks tokumaru!

tokumaru wrote:
Quote:
When using MMC1 would it be hard (too slow)... for the cpu to use both 4 and 8 kb files?

You should stop thinking about "files". You use files to build the ROM, but once the ROM is ready it's just a bunch of bytes, and the NES has no concept of files whatsoever.

The MMC1 doesn't do anything to help with using more than 256 tiles for the background. It has the capability of bankswitching 4KB or 8KB chunks, but that doesn't affect what the NES can use for backgrounds.
Excellent!! Now I'm fixed away from my past thoughts; thank you so much tokumaru!

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Thu Dec 27, 2012 6:01 pm

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
Kasumi, on page 56, wrote:

Ok I added this code at the end of my fixed PRG bank:
Code:
reset_stub:
sei
ldx #\$FF
txs        ; set the stack pointer
stx \$8000  ; reset the mapper
jmp reset  ; must be in \$C000-\$FFED
.word vblank, reset_stub, irq
and it built my nes file... but, then I tried to add the switchable PRG bank to my code:
Code:
.org \$8000 ;empty switchable PRG bank
reset_stub:
sei
ldx #\$FF
txs        ; set the stack pointer
stx \$8000  ; reset the mapper
jmp reset  ; must be in \$C000-\$FFED
.word vblank, reset_stub, irq
but it, asm6, told me that "...g.asm(596): Label already defined." (Line 596 of that ...g.asm file is simply "reset_stub:".) I do understand what the error asm6 was talking about. But, I don't understand how too prevent that error when I am told to:
To make sure your code works on all MMC1 revisions, put the following code in the last 16 bytes of each 16384 byte bank. (Barbie uses almost identical code.)
Code:
reset_stub:
sei
ldx #\$FF
txs        ; set the stack pointer
stx \$8000  ; reset the mapper
jmp reset  ; must be in \$C000-\$FFED

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Thu Dec 27, 2012 6:04 pm
 Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2269
I'd say make it a macro if you can. I myself just made 16 global labels, numbered MMC1Boot00-MMC1Boot15 so it wouldn't duplicate. And you could also make it JMP [\$FFFC], just to do it. But that's perfectly fine, but you can either make 16 global labels or a macro, both options will get you around that.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Thu Dec 27, 2012 6:52 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11397
Location: Rio de Janeiro - Brazil
I use temporary labels (add a "+" or "-" to the beginning, depending on the location of the code that uses those labels) for labels I must repeat in various banks.

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Dec 31, 2012 11:15 am

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 1034
Location: cypress, texas
3gengames wrote:
I'd say make it a macro if you can. I myself just made 16 global labels, numbered MMC1Boot00-MMC1Boot15 so it wouldn't duplicate. And you could also make it JMP [\$FFFC], just to do it. But that's perfectly fine, but you can either make 16 global labels or a macro, both options will get you around that.
Thank you 3gengames!!

tokumaru wrote:
I use temporary labels (add a "+" or "-" to the beginning, depending on the location of the code that uses those labels) for labels I must repeat in various banks.
Thanks tokumaru!! I have created my 16 files... each one has that code at the bottom
Code:
;PRG bank 15
.org \$8000

.pad \$BFF0  ;Fills bank15 with 0s.
reset_stub15:
sei
ldx #\$FF
txs        ; set the stack pointer
stx \$8000  ; reset the mapper
jmp reset  ; must be in \$C000-\$FFED
.word vblank, reset_stub15, irq

Hope that could work. Will try to build my nes file after lunch!

edit: Lunch was nice. So I've made 16 files... but how do I include each file? Do I need to write code like this
Code:
.org \$8000 ;empty switchable PRG bank

.include "mmc1_bank0.asm" if switchable bank = 0
.include "mmc1_bank1.asm" if switchable bank = 1
...etc
.include "mmc1_bank15.asm" if switchable bank = 15
How could that be done?

Top

 Post subject: Re: 8x16 sprite is really a 16x32 pixel image?Posted: Mon Dec 31, 2012 1:45 pm

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11397
Location: Rio de Janeiro - Brazil
You don't have to write various reset stubs with repeated code. That's redundant and prone to errors. You can make an include file with the stub, and call the label -reset_stub, so that the assembler doesn't complain about repeated labels, and then for the vectors you can just use .word vblank, -reset_stub, irq, still inside the include file, to completely get rid of redundancy. Just include that file at the end of every bank.

Top

 Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending
 Page 57 of 102 [ 1523 posts ] Go to page Previous  1 ... 54, 55, 56, 57, 58, 59, 60 ... 102  Next

 All times are UTC - 7 hours

#### Who is online

Users browsing this forum: No registered users and 6 guests

 You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum

Search for:
 Jump to:  Select a forum ------------------ NES / Famicom    NESdev    NESemdev    NES Graphics    NES Music    Homebrew Projects       2018 NESdev Competition       2017 NESdev Competition       2016 NESdev Competition       2014 NESdev Competition       2011 NESdev Competition    Newbie Help Center    NES Hardware and Flash Equipment       Reproduction    NESdev International       FCdev       NESdev China       NESdev Middle East Other    General Stuff    Membler Industries    Other Retro Dev       SNESdev       GBDev    Test Forum Site Issues    phpBB Issues    Web Issues    nesdevWiki