There is no way to specify a CHR-less cartridge with an iNES header (and if you tie the CHR lines to GND or +5V it would be like a CHR-ROM filled with 0s or 1s anyway I guess). 0 in that field of the iNES header always means CHR-RAM as far as I know. None of the VRC6 games uses CHR-RAM though, so I don't know if this can confuse some emulators.unregistered wrote: ↑Thu May 06, 2021 11:07 am I’m noticing that you’ve set your CHR-ROM pages to 0. So either you are somehow using CHR-RAM, or your game is not meant to display any type of CHR graphic on the screen?
My cart runs differently in different emulators
Moderator: Moderators
Re: My cart runs differently in different emulators
Last edited by Pokun on Thu May 06, 2021 3:12 pm, edited 1 time in total.
-
- Posts: 160
- Joined: Sat Apr 24, 2021 7:25 am
Re: My cart runs differently in different emulators
I'll admit I'm not sure what CHR means. Also I thought the max hex address value was $FFFF since the 6502's address bus is 16 bit.unregistered wrote: ↑Thu May 06, 2021 11:07 amhmmm… I’ve never used the VRC6 mapper, but I’m noticing that you’ve set your CHR-ROM pages to 0. So either you are somehow using CHR-RAM, or your game is not meant to display any type of CHR graphic on the screen?puppydrum64 wrote: ↑Wed May 05, 2021 3:42 pm I think I'm starting to get it but let's see if I've got this right.
Code: Select all
;Header db "NES",$1a ;ID db $02 ;Rom pages (16k each) db $0 ;CHR-ROM pages db %10000010 ;mmmmFTBM mmmm = mapper no bottom 4 bits , Four screen vram layout, Trainer at &7000, Battery ram at &6000, Mirror (0=horiz, 1=vert) db %00010000 ;mmmm--PV mapper (top 4 bits... Pc10 arcade, Vs unisystem ) db 0 ;Ram pages db 0,0,0,0,0,0,0 ; org $8000 skip $2000 ;bank 1 org $8000 skip $2000 ;bank 2 org $8000 skip $2000 ;bank 3 org $C000 org $E000 nmihandler: rti irqhandler: rti RESET: ;YOUR CODE GOES HERE org $FFFA dw nmihandler dw RESET dw irqhandler
For my MMC1 with CHR-ROM, I was told to include the CHR files at $10000 (at the very end of the code you’ve provided). But, now with my version-of-MMC1 header set for using CHR-RAM, those CHR-ROM files starting at $10000 are invalid for me.
-
- Posts: 160
- Joined: Sat Apr 24, 2021 7:25 am
Re: My cart runs differently in different emulators
Ah, I keep forgetting that 1KB isn't $1000 bytes. Also I thought bank 0 was the one that was always loadedunregistered wrote: ↑Thu May 06, 2021 1:13 pm According to the wiki:
https://wiki.nesdev.com/w/index.php/VRC6
VRC6 has 8 1kb switchable CHR-ROM banks… so, starting at $10000, include your 1kb files.
That page also states that VRC6 has a maximum 256kb CHR-ROM space. I’m sure it also explains how to bank switch the VRC6 CHR banks.
(1kb is kind of small; 1kb == $0400; your first 1kb CHR-ROM file would fill up $10000 - $103FF; or, you could include a 4kb CHR-ROM file between $10000 - $10FFF and just arrange your 4kb file while remembering that it will be separated into 4 banks.)
(There are even mappers that use 8kb CHR banks; I just talked about using 4kb files bc my MMC1 was set to use 4kb CHR banks.)
And, one last kind note from me: Since it’s on a computer, your first bank, of PRG-ROM PRG-RAM CHR-ROM or CHR-RAM, is bank0.
-
- Posts: 160
- Joined: Sat Apr 24, 2021 7:25 am
Re: My cart runs differently in different emulators
Well currently my test rom has no graphics, it was just a music test. I wasn't really concerned with graphics at the moment. But eventually the game will need to have graphics so I should allocate that memory space. CHR ROM is where the tilesets are stored right?unregistered wrote: ↑Thu May 06, 2021 11:07 amhmmm… I’ve never used the VRC6 mapper, but I’m noticing that you’ve set your CHR-ROM pages to 0. So either you are somehow using CHR-RAM, or your game is not meant to display any type of CHR graphic on the screen?puppydrum64 wrote: ↑Wed May 05, 2021 3:42 pm I think I'm starting to get it but let's see if I've got this right.
Code: Select all
;Header db "NES",$1a ;ID db $02 ;Rom pages (16k each) db $0 ;CHR-ROM pages db %10000010 ;mmmmFTBM mmmm = mapper no bottom 4 bits , Four screen vram layout, Trainer at &7000, Battery ram at &6000, Mirror (0=horiz, 1=vert) db %00010000 ;mmmm--PV mapper (top 4 bits... Pc10 arcade, Vs unisystem ) db 0 ;Ram pages db 0,0,0,0,0,0,0 ; org $8000 skip $2000 ;bank 1 org $8000 skip $2000 ;bank 2 org $8000 skip $2000 ;bank 3 org $C000 org $E000 nmihandler: rti irqhandler: rti RESET: ;YOUR CODE GOES HERE org $FFFA dw nmihandler dw RESET dw irqhandler
For my MMC1 with CHR-ROM, I was told to include the CHR files at $10000 (at the very end of the code you’ve provided). But, now with my version-of-MMC1 header set for using CHR-RAM, those CHR-ROM files starting at $10000 are invalid for me.
Re: My cart runs differently in different emulators
CHR means character, which is the type of graphics the PPU is doing (this is also known as text mode in many video chips since it's initially for displaying text on a computer monitor). The CHR-ROM (or CHR-RAM in your case) is the character ROM which contains all the character pattern data used by background tiles and sprites, and defines their look. If you use CHR-ROM, the iNES file format says that you should include it after the PRG-ROM (the ROM you have). Since the final address of the PRG-ROM is $FFFF, Unregistered just meant that the CHR-ROM would have the address $10000, but don't think too much of that as that isn't actually where it goes (and you are correct that $10000 doesn't exist in the address space). The CHR-ROM/-RAM is a chip on the cartridge which is mapped directly into the PPU address space (pattern table 0 and 1 at $0000-$1FFF in the PPU space).
To use CHR-ROM, you need to change the CHR-ROM pages field in the header to 1 or more. Each CHR page/bank is 8 kB. Then you can use the INCBIN directive (or whatever it is in VASM) to include a binary file with your CHR-ROM data after the vectors (at bottom of your source file). NES Screen Tool is popular for making CHR data. Here are some CHR you can use to get you started. You can import them into NES Screen Tool and convert them to CHR.
To use CHR-ROM, you need to change the CHR-ROM pages field in the header to 1 or more. Each CHR page/bank is 8 kB. Then you can use the INCBIN directive (or whatever it is in VASM) to include a binary file with your CHR-ROM data after the vectors (at bottom of your source file). NES Screen Tool is popular for making CHR data. Here are some CHR you can use to get you started. You can import them into NES Screen Tool and convert them to CHR.
-
- Posts: 160
- Joined: Sat Apr 24, 2021 7:25 am
Re: My cart runs differently in different emulators
So CHR ROM is saved on the PPU? I thought you couldn't do anything with the PPU except tell it what to draw by writing to the $2000 ports.Pokun wrote: ↑Thu May 06, 2021 3:35 pm CHR means character, which is the type of graphics the PPU is doing (this is also known as text mode in many video chips since it's initially for displaying text on a computer monitor). The CHR-ROM (or CHR-RAM in your case) is the character ROM which contains all the character pattern data used by background tiles and sprites, and defines their look. If you use CHR-ROM, the iNES file format says that you should include it after the PRG-ROM (the ROM you have). Since the final address of the PRG-ROM is $FFFF, Unregistered just meant that the CHR-ROM would have the address $10000, but don't think too much of that as that isn't actually where it goes (and you are correct that $10000 doesn't exist in the address space). The CHR-ROM/-RAM is a chip on the cartridge which is mapped directly into the PPU address space (pattern table 0 and 1 at $0000-$1FFF in the PPU space).
To use CHR-ROM, you need to change the CHR-ROM pages field in the header to 1 or more. Each CHR page/bank is 8 kB. Then you can use the INCBIN directive (or whatever it is in VASM) to include a binary file with your CHR-ROM data after the vectors (at bottom of your source file). NES Screen Tool is popular for making CHR data. Here are some CHR you can use to get you started. You can import them into NES Screen Tool and convert them to CHR.
Re: My cart runs differently in different emulators
CHR ROM is on the game cartridge. It is connected directly to some of the pins of the cart, so the the PPU can access the tile data from the ROM directly.
The PPU itself doesn't have any memory to hold tile data, so there is no need to copy those data to the PPU (if that's what you meant by "saving" CHR ROM on the PPU).
The PPU itself doesn't have any memory to hold tile data, so there is no need to copy those data to the PPU (if that's what you meant by "saving" CHR ROM on the PPU).
-
- Posts: 1318
- Joined: Thu Apr 23, 2009 11:21 pm
- Location: cypress, texas
Re: My cart runs differently in different emulators
The way that made a difference for me is that I attempted to always acknowledge the $ standing for hexidecimal. So then 1kb, which equals 1024 bytes, can’t possibly fill $1000. $1000 is such a large decimal value.puppydrum64 wrote: ↑Thu May 06, 2021 3:20 pmAh, I keep forgetting that 1KB isn't $1000 bytes. Also I thought bank 0 was the one that was always loadedunregistered wrote: ↑Thu May 06, 2021 1:13 pm According to the wiki:
https://wiki.nesdev.com/w/index.php/VRC6
VRC6 has 8 1kb switchable CHR-ROM banks… so, starting at $10000, include your 1kb files.
…
Bank0 is not always loaded everywhere. On my version of MMC1, it’s set up so that the second bank is either set to bank15 or bank31; there, the second bank is a “fixed” bank; with my setup, the second MMC1 bank is incapable of being bank0.
—-
@Pokun, you said VRC6 has an 8kb CHR-ROM bank… obviously, I’ve never used VRC6, but the nesdev wiki site I linked in my quote above says the VRC6 has 8 1KB switchable CHR-ROM banks. Maybe it’s possible to use them all as an 8kb bank too? Hmmm… so much to learn… they spent a ton of effort creating the NES.
Re: My cart runs differently in different emulators
I don't think I said that, at least I didn't mean to say that. The CHR area is always 8 kB on the Famicom/NES and the VRC6 (and many other mappers) can bank switch that for more.
I think bank naming is arbitrary, but ROM banks are usually numbered from the bank with the lowest address starting with bank 0. Some even call them pages, but I think that's confusing because a "page" in 6502-lingo (like the zero-page) is a unit of 256 byte.
As the programmer you only have direct control of the CPU (using CPU instructions like LDA and STA) and the CPU only has access to the CPU address space. The Famicom/NES also has a PPU address space which is separate and not connected to the CPU's address lines. What this means in practice is that if you enter an instruction like STA $2000 you will write to address $2000 in the CPU address space (which is the PPUCTRL register) and not the $2000 in the PPU address space (which is part of the nametable). As you probably know already, you do have indirect access to the PPU address space by writing the PPU address and data to the PPU I/O registers at $2006 and $2007 (these are in the CPU address space and allows communication with the PPU address space).
The CHR-ROM/-RAM is a chip on the cartridge, and as Gilbert said it's connected to the PPU address space already, so you don't need to do anything with it, and the CPU can't directly access it like the rest of the PPU space. If you use CHR-RAM however, you must write your tile data to the chip via $2006 and $2007, as RAM only contains random garbage at boot. If you use CHR-ROM you don't have to do anything (other than including your tile data in your source file after drawing it).
I think bank naming is arbitrary, but ROM banks are usually numbered from the bank with the lowest address starting with bank 0. Some even call them pages, but I think that's confusing because a "page" in 6502-lingo (like the zero-page) is a unit of 256 byte.
No it's not "saved", it's already part of the PPU address space as soon as you insert the cartridge in the cartridge slot, the cartridge slot is just wired that way. Think of the cartridge as a part of the whole system.puppydrum64 wrote: ↑Thu May 06, 2021 7:17 pm So CHR ROM is saved on the PPU? I thought you couldn't do anything with the PPU except tell it what to draw by writing to the $2000 ports.
As the programmer you only have direct control of the CPU (using CPU instructions like LDA and STA) and the CPU only has access to the CPU address space. The Famicom/NES also has a PPU address space which is separate and not connected to the CPU's address lines. What this means in practice is that if you enter an instruction like STA $2000 you will write to address $2000 in the CPU address space (which is the PPUCTRL register) and not the $2000 in the PPU address space (which is part of the nametable). As you probably know already, you do have indirect access to the PPU address space by writing the PPU address and data to the PPU I/O registers at $2006 and $2007 (these are in the CPU address space and allows communication with the PPU address space).
The CHR-ROM/-RAM is a chip on the cartridge, and as Gilbert said it's connected to the PPU address space already, so you don't need to do anything with it, and the CPU can't directly access it like the rest of the PPU space. If you use CHR-RAM however, you must write your tile data to the chip via $2006 and $2007, as RAM only contains random garbage at boot. If you use CHR-ROM you don't have to do anything (other than including your tile data in your source file after drawing it).
-
- Posts: 160
- Joined: Sat Apr 24, 2021 7:25 am
Re: My cart runs differently in different emulators
The assembler I'm using won't let me use the command "org $10000", says it's too large.
-
- Posts: 160
- Joined: Sat Apr 24, 2021 7:25 am
Re: My cart runs differently in different emulators
So let's say I wanted to put a smiley face graphic in my test ROM and I put it in my .asm file like so:Pokun wrote: ↑Fri May 07, 2021 3:59 am I don't think I said that, at least I didn't mean to say that. The CHR area is always 8 kB on the Famicom/NES and the VRC6 (and many other mappers) can bank switch that for more.
I think bank naming is arbitrary, but ROM banks are usually numbered from the bank with the lowest address starting with bank 0. Some even call them pages, but I think that's confusing because a "page" in 6502-lingo (like the zero-page) is a unit of 256 byte.
No it's not "saved", it's already part of the PPU address space as soon as you insert the cartridge in the cartridge slot, the cartridge slot is just wired that way. Think of the cartridge as a part of the whole system.puppydrum64 wrote: ↑Thu May 06, 2021 7:17 pm So CHR ROM is saved on the PPU? I thought you couldn't do anything with the PPU except tell it what to draw by writing to the $2000 ports.
As the programmer you only have direct control of the CPU (using CPU instructions like LDA and STA) and the CPU only has access to the CPU address space. The Famicom/NES also has a PPU address space which is separate and not connected to the CPU's address lines. What this means in practice is that if you enter an instruction like STA $2000 you will write to address $2000 in the CPU address space (which is the PPUCTRL register) and not the $2000 in the PPU address space (which is part of the nametable). As you probably know already, you do have indirect access to the PPU address space by writing the PPU address and data to the PPU I/O registers at $2006 and $2007 (these are in the CPU address space and allows communication with the PPU address space).
The CHR-ROM/-RAM is a chip on the cartridge, and as Gilbert said it's connected to the PPU address space already, so you don't need to do anything with it, and the CPU can't directly access it like the rest of the PPU space. If you use CHR-RAM however, you must write your tile data to the chip via $2006 and $2007, as RAM only contains random garbage at boot. If you use CHR-ROM you don't have to do anything (other than including your tile data in your source file after drawing it).
Code: Select all
Bitmap:
; 00000000 - Bitplane 0
DB %00111100 ; 0
DB %01111110 ; 1
DB %11111111 ; 2
DB %11111111 ; 3
DB %11111111 ; 4
DB %11011011 ; 5
DB %01100110 ; 6
DB %00111100 ; 7
; 11111111 - Bitplane 1
DB %00000000 ; 1
DB %00000000 ; 2
DB %00100100 ; 3
DB %00000000 ; 4
DB %00000000 ; 5
DB %00100100 ; 6
DB %00011000 ; 7
DB %00000000 ; 8
BitmapEnd:
-
- Posts: 160
- Joined: Sat Apr 24, 2021 7:25 am
Re: My cart runs differently in different emulators
Also one thing I've come to find out, is that even though everyone so far has told me not to use "org $BFF0" it seems that my code will have no effect unless I use it. From what I can tell, all attempts to do anything else results in either an invalid file, corrupt file, or my code doing nothing at all. I'm guessing that's just a quirk with VASM and isn't typical syntax with other assemblers.
Re: My cart runs differently in different emulators
It's a VASM quirk. Every assembler is different, and on this specific forum we collectively have the most familiarity with cc65, asm6, and nesasm.
The times I've written things using xa65 I had to use similar syntax. I've since mostly switched to cc65.
The times I've written things using xa65 I had to use similar syntax. I've since mostly switched to cc65.
-
- Posts: 160
- Joined: Sat Apr 24, 2021 7:25 am
Re: My cart runs differently in different emulators
CC65 seems like it would be best since there's already famitracker support. Unfortunately I know absolutely no C
Re: My cart runs differently in different emulators
CC65 is a whole suite of C compiler, assembler, and linker. No need to use C unless you want to.