nesdev.org

dougeff wrote: ↑Mon Mar 08, 2021 5:48 pm I had a thought. Instead of changing all the 6502/NES code to SNES... keep the 6502 exactly the same, and build an interpreter that parses every 6502 instruction like some kind of emulator.

93143 wrote: ↑Mon Mar 08, 2021 7:17 pm I was editing my previous post when you showed back up, and you may have missed a detail. In any case I might as well be explicit about this, just in case you don't already know:

The SNES has two bank registers: the program bank and the data bank. They are not the same thing and can have different values. The former is the top byte of the 24-bit program counter, and is changed via jml (or jsl or rtl, technically). The latter is used with loads and stores as the implicit top byte of a 16-bit ("absolute") address, to form a 24-bit address, and is changed via plb. This is very important to keep in mind if you're attempting to emulate a PRG ROM bankswitch, because you may need to change both registers.

phk pushes the program bank byte onto the stack. This is often used to set up for plb, for instance when initializing a FastROM program.

;setup indirect indexed addressing to $70-$71.
lda #$40          
sta $70
lda #$1d
sta $71

;to see if routine has converted 20th nes palette, 
if so, skip to DMA transfer.
cmp #$20
beq $8245

;use $1d30 as an x counter, for which of the 20 nes
palette colors you are currently on in $600-$61F, use
loaded nes color value as x pointer, to get it's new x 
value to load within the 16-bit/2 byte equivalent table,
check to see if routine has loaded 8 bytes. (4 colors)
ldy #$00
ldx $1d30
lda $0600,x
tax
lda $1f40,x
tax
lda $1f40,x
sta ($70),y
iny
inx
lda $1f40,x
sta ($70),y
inc $1d30
iny
cpy #$08
beq $820e

;if y has reached 8 bytes, (4 nes colors) take low byte from $70, inc 
by 20, so that the next bg/sprite can receive its 16-bit
values.
lda $70
clc
adc #$20
sta $70
lda $1d30
cmp #$10
bne $8208

;if 10 nes colors have been converted by this time,
(bg1-4) then reset $70-$71 for new indirect indexed
addressing for sprite palettes.
lda #$40
sta $70
lda #$1e
sta $71
bne $8208

;dma transfer of newly created 200 byte table within
wram, this routine is reached when the conversion
routine has completed converting 20 nes colors.
stz $1d30
stz $70
stz $71
rep #$18
lda #$00
sta $2121
lda #$7e
ldx #$1d40
ldy #$0200
stx $4302
sta $4304
sty $4305
stz $4300
lda #$22
sta $4301
lda #$01
sta $420b
sep #$30

rtl

93143 wrote: ↑Wed Mar 10, 2021 7:36 pm You know, this stuff is documented already in a really easy-to-read format. I've mentioned it before:

https://wiki.superfamicom.org/registers

What are you using as reference?

Myself086 wrote: ↑Thu Mar 11, 2021 4:19 am Sounds to me like you're coding directly in hex without an assembler.

infidelity wrote: ↑Thu Mar 11, 2021 9:06 am Yup, I work entirely via hex, been coding that way since 2004.

turboxray wrote: ↑Thu Mar 11, 2021 10:44 am

infidelity wrote: ↑Thu Mar 11, 2021 9:06 am Yup, I work entirely via hex, been coding that way since 2004.

It's 2021. This could be the year that you finally switch over to an assembler Really though, working with an assembler isn't that bad. I mean, your projects are ambitious and impressive. I loved your NES zelda hack (more of a new game than a hack). Anyway, you could totally be fluent/comfortable with an assembler with a month or two.

infidelity wrote: ↑Fri Mar 12, 2021 7:22 am During the loop at the end of the reset vector, before the NMI fires, my stack, my stack pointer, A,X,Y, all match between my port, and the original nes rom.

But, when the NMI fires in my port, my stack gets shifted down by 1 byte.

dougeff wrote: ↑Fri Mar 12, 2021 9:35 am You sure it's not an IRQ or BRK $00 and your IRQ or BRK vectors point to $0000 ?