this may help if you don't want to duplicate palettes for two (or more) sprites that

use different palette sets, but you want them to use the same set in your project.



the palette loaded into nes vram is as follows (each letter is a byte):



    txxx mxxx mxxx mxxx

    mxxx mxxx mxxx mxxx



    t = universal background color

    m = mirror of t

    x = values that can be changed and will show durring rendering



the first row is for backgrounds and the second is for sprites. each sprite (8x8

pixel tile) has 4 bytes that are written to sprite oam. these 4 bytes contain this

data:



    0 - y position of the top sprite

    1 - the tile number of the sprite (index into pattern table)

    2 - attributes of the sprite (bits: 76543210)

        bits 0 and 1 tell the ppu what palette entry to render the sprite with so:

            xxxxxx00 = 1st sprite palette

            xxxxxx01 = 2nd

            xxxxxx10 = 3rd

            xxxxxx11 = 4th

        the 'x' bits do other stuff, but dont pertain to palettes

    3 - x position of left of sprite



now trace the value in ram (probably somewhere in $0200-$02FF, though not

always) for the attribute byte of the sprite you wanna change. set a breakpoint

for when that address is written to so you can see where the game sets that value.

now change the value that is written to that address to reflect which palette you

want to be used durring rendering of that sprite. be sure all the 'x' bits are the same

in your new value or you will get some strange effects.



the 4 bytes will always be in the order listed above because more then likely the

game will use sprite dma to transfer all the values into sprite oam. so if the data

is stored at $0200 it will be in this order:



    $0200 = sprite0_Y

    $0201 = sprite0_T

    $0202 = sprite0_A

    $0203 = sprite0_X

    $0204 = sprite1_Y

    $0205 = sprite1_T

    $0206 = sprite1_A

    $0207 = sprite1_X

    ...etc...



hope this helps.

nes prg-rom space is:



 bank0 - $8000 to $BFFF

 bank1 - $C000 to $FFFF



smaller switchable banks are possible, just depends on the mapper. ram is

located at $0000 to $07FF and is thus mirrored after that up to $2000.  all

code/data is loaded into those 2 banks of prg-rom, though thats not there actual

offset in the rom. the value will be stored in ram when needed but will first need

to be loaded from rom. you need to find where in rom it is loaded from by using a

breakpoint set to when that location in ram is written to. and ram will be written to

like so:



   lda #n

   sta $g



where n = the value of health and g = offset in ram. though it might be tricky

because indirect or indexed addressing might be used or they will use the X or Y

register instead of the accumulator (A register). so you might get something like:



   lda ($nn), Y

        or

   lda ($nn, X)



which are the two forms of indirect addressing (X and Y are 6502 registers, nn =

zero page address). or you might also get one of these:



   lda $nn, X

   lda $nnnn, X

   lda $nnnn, Y



which are forms of indexed addressing. ($nn = zero page address and $nnnn =

non-zero page address) when the game stores the value into ram it may also use

indirect/indexed addressing rather than absolute.

an array would probably be accessed by indexed addressing.

($nnnn = base adress)



    opcode $nnnn, register



just plug in your processor opcode that loads/moves a value as well as the

indexing register. a struct would probably use indexed indirect adressing.



    opcode ($nnnn), register



the base address would point to the first byte of the struct and the register would

be used to move to different variables. then increase the base pointer by the length

of the struct to get to the next struct.

Originally posted by spel werdz rite

---

Anyways, my knowledge of 6502 is limited.

---

Originally posted by d4s

---

it is probably very hard to convert a game that originally didnt use a mapper

---

Originally posted by Dario

---

i give this a negative infinity.

---

Originally posted by mcchrisownzzz

---

well. that's no good.

---

Originally posted by BGNG

---

Taking after the great editor of DOS days, Hexposure

---

+-------------------------------------------------------+

|			Format:				|

+-------------------------------------------------------+



	-ah  -al  -nb  -b0 ...[bN]



		ah : high part of address in vram



		al : low part of address in vram



		nb : dc54hhhh

		     ||||||||

		     ||||++++-length of data

		     |||+-----?

		     ||+------?

		     |+-------0=repeat b0; 1=read in new byte (up to bN)

		     +--------0=write in rows; 1=write in columns



		b0 : first byte of data



		bN : the last byte of data (only used if nb.c == 1)



+-------------------------------------------------------+

|			Rom Layout			|

+-------------------------------------------------------+



	address	 #bytes usage	

	------- ------- -------------------------------

	$0000	?	

	...

	$356B	32	In-game Palette

	...

	$359C	4	Fig 1.1 - LadB

	$35A0	7	Barrels Column #1

	$35A7	7	Barrels Column #2

	$35AE	7	Barrels Column #3

	$35B5	4	Fig 1.1 - LadB

	$35B9	4	Fig 1.1 - Goal

	$35BD	4	Fig 1.1 - Plat1

	$35C1	4	Fig 1.1 - Lad1

	$35C5	4	Fig 1.1 - Plat2

	$35C9	15	Fig 1.1 - Plat3Top

	$35D8	18	Fig 1.1 - Plat3Bot

	$35EA	4	Fig 1.1 - T1

	$35EE	20	Fig 1.1 - P4T

	$3602	19	Fig 1.1 - P4M

	$361F	9	Fig 1.1 - P4B

	$3628	4	Fig 1.1 - T2

	$362C	26	Fig 1.1 - P5T

	$3646	4	Fig 1.1 - Lad2

	$364A	27	Fig 1.1 - P5M

	$3665	4	Fig 1.1 - Lad3

	$3669	4	Fig 1.1 - T3

	$366D	4	Fig 1.1 - T4

	$3671	8	Fig 1.1 - P6T	

	$3679	29	Fig 1.1 - P6M

	$3696	21	Fig 1.1 - P6B		

	$36AB	4	Fig 1.1 - T5

	$36AF	4	Fig 1.1 - Lad4

	$36B3	14	Fig 1.1 - P7T

	$36C1	29	Fig 1.1 - P7M

	$36DE	12	Fig 1.1 - P7B

	$36F1	4	Fig 1.1 - T6

	$36F5	22	Fig 1.1 - P8T

	$370B	4	Fig 1.1 - P9

	$370F	18	Fig 1.1 - P8B

	$3721	5	Left 2 Tiles of oil can

	$3726	5	Right 2 Tiles of oil can

	$372B	?	

	...

	$3753	138	Zone 3 Object Data

	$37DD	?	

	...

	$3819	207	Zone 2 Object Data

	$38E9	16	Title Screen Background Palette

	$38F9	4	Title Screen Pointer Palette (only 1 color)

	$38FD	?	

	...

	$600F	?	



	NOTE: Any object in Fig 1.1 named 'T*' is only one tile by default

Originally posted by VinceIP

---

Is it possible to expand a NES rom without major glitches?

---

Originally posted by BOBTHEVILA

---

If you want it to be a tad better you might be able to help with finding the hex that make them anoyingly fllicker. Then I could turn it off

---

Originally posted by VinceIP

---

it would be fine to play hacked NES ROMS since it no longer has a patent.

---

---

SMB3 runs on the NES, which is much simpler than the SNES and therefore easier to ASM hack.

---