Need guidance with nes to snes.

[infidelity]

Ok, so I'm making progress, but can't figure out why my DMA doesn't finish its transfer, and then doesnt transfer anything else when the routine is called upon 3 more times. I'll get my code up, rather big.

Here's the code

primary graphics load routine

Code: Select all

lda $f5		;current $8000-$9FFF
pha
lda $f6		;current $A000-$BFFF
pha
lda $08	
pha
lda $09
pha
lda #$28		;bank 28
sta $f6		;bank 28 to $A000-$BFFF
jsr $ff37		;mmc3 bankswap
lda $ff		;NES PPUCTRL
and #$fe
jmp $ed38	;set bits from NES $2000 to SNES equivilents

lda $03b800,x	;lo byte pointer to gfx
sta $02
lda $03b870,x	;hi byte pointer to gfx
sta $03
ldy #$00
lda [$02],y	;if A=FF, no palettes, if 00-7F, palettes
bmi $da42
sta $0618,y	;sprite palette 2 & 3 buffer
sta $0638,y	;sprite palette 2 & 3 buffer
iny
cpy #$08		;8 bytes loaded yet?
bne $da2d
lda #$ff		;palette buffer write flag
sta $18		;palette buffer
bne $da43
iny
lda #$28		;bank 28
sta $f6
jsr $ff37		;mmc3 bankswap
lda [$02],y	;load bank id for gfx location
bmi $da77		;if 80-FF, goto pull's to end routine
pha
iny
lda [$02],y	;hi byte # of bytes to transfer to vram
sta $08
iny
lda [$02},y	;hi byte to chr gfx
sta $06
ldx #$00
stx $05
iny
lda $4212		;originally lda $2002 (nes)
lda [$02],y	;vram hi byte
sta $09
pla			;restore bank id for gfx location
sta $f5		;store as $8000-$9FFF
sta $f6		;store as $8000-$9FFF
inc $f6		;inc so bank id will store as $A000-$BFFF
jsr $ff37		;mmc3 bankswap
jmp $ecf2		;dma routine
nop
nop
bne $da43
pla
sta $09
pla
sta $08
pla
sta $f6
pla
sta $f5
jmp $ff37		;mmc3 bankswap

dma routine

Code: Select all

phy
lda $09
sta $7b
lda $06
sta $7d
lda $08
sta $7f
rep #$18
lda #$80
sta $2115
ldy $007A		;vram target location
sty $2116
lda $f5		;bank id
sta $4304
ldy $007c		;chr hi byte location
sty $4302
ldy $007e		;# of bytes to transfer
sty $4305
lda #$01
sta $4300
lda #$18
sta $4301
lda #$01
sta $420b
stz $7b
stz $7d
stz $7f
sep #$30
ply
jmp $da72

So what happens for the copyright screen, is that the primary graphics routine gets initiated 4 times, to set up the chr in the nes to $0000-$07FF, $0800-$0FFF, $1000-$17FF, $1800-$1FFF. And since in snes its 2 bytes wide per chr tile, i made a conversion table regarding the amount of bytes to transfer.

Code: Select all

strings represent tiles 00-0F, 10-1F, 20-2F, etc etc

1 string, 100 bytes - 200 bytes
2 strings, 200 bytes - 400 bytes 
3 strings, 300 bytes - 600 bytes
4 strings, 400 bytes - 800 bytes
5 strings, 500 bytes - A00 bytes
6 strings, 600 bytes - C00 bytes
7 strings, 700 bytes - E00 bytes
8 strings, 800 bytes - 1000 bytes
9 strings, 900 bytes - 1200 bytes
10 strings, A00 bytes - 1400 bytes
11 strings, B00 bytes - 1600 bytes
12 strings, C00 bytes - 1800 bytes
13 strings, D00 bytes - 1A00 bytes
14 strings, E00 bytes - 1C00 bytes
15 strings, F00 bytes - 1E00 bytes
16 strings, 1000 bytes - 2000 bytes

And i have the bank id's converted as well.

And when these routines load, i almost got the first dma transfer completed, then the other 3 times, i get nothing. Here is a breakdown of the bytes that are loaded.

Code: Select all

breakdown
[palette (08 bytes, if no palette then first byte is always FF)] [bank id] [# of bytes to transfer in 100's] [hi byte gfx pointer] [hi byte ppu address]

original nes version
FF2408B800 2A089808 08089010 08029B18 02019A1A FF

my snes conversion
FF2B10F000 2C10B010 2410A040 2404B648 2102B44A FF

So the conversion of mine, only $0F40-$0FE0 are not transferred via DMA, even though I set 1000 bytes to be transferred, and the remaining gfx I want transferred, nothing happens.

[creaothceann]

Do you have any HDMA channels active at that time?

[infidelity]

Do you have any HDMA channels active at that time?

I dont believe so, can you suggest what to check for to make sure that's not happening?

[creaothceann]

Registers 420B and 420C enable DMA and HDMA.

If you don't use HDMA then there's something else preventing the game from starting the DMAs.

[dougeff]

A DMA to the VRAM could fail if the screen is active. You need either forced blank of or v-blank.

Interesting side note, DMA uses 100% of the CPU and can't be interrupted. Any pending interrupts will wait until it is done before firing. So we know that NMI or IRQ are not to blame. (HDMA can interrupt it, as creaothceann noted)

[infidelity]

A DMA to the VRAM could fail if the screen is active. You need either forced blank of v-blank.

Interesting side note, DMA uses 100% of the CPU and can't be interrupted. Any pending interrupts will wait until it is done before firing. So we know that NMI or IRQ are not to blame. (HDMA can interrupt it, as creaothceann noted)

I'll take a look at $2100.

[dougeff]

* or v-blank
typo

[infidelity]

Thank you, dougeff & creaothceann! I need to redo my code yet again, I need to change how $2100 is written to. I need to redo my massive tables of how the game sets up the NES $2000 bits. When the value is 8# in nes for $2000, it's for NMI, but I have that check of that bit going to $2100 in the snes, and when there is no 8# to go against, its setti f that 8# bit to 0#, and stores it to $2100, which is rendering enabled for the SNES. I forced the value of 80 into $2100 before my DMA routine, and all my gfx appeared in the tileviewer.

However, one set was all blank tiles (do to most likely a misdirection in the gfx location address) and they were injected into the wrong addresses within vram, I swear I had my conversions correct? I was basing them off of the tilemap. Wanted the first 80 tiles to be at $0000, the next 80 tiles at $1000, the Sprite tiles to be at $4000.

Edit - can someone let me know if additional steps are needed when doing DMA multiple times? I swear I'm entering in the hi byte for the location in vram correct.

[93143]

I can't tell from a quick look over your code whether this is an issue (you use a lot of indirection), but the VRAM address is a word address. If you want to put graphics at byte $1000, you have to write #$0800 to $2116/$2117.

Also, why are you reading $4212? As far as I know it doesn't do anything, and you don't use the value.

DMA has no memory of how recently it's been used. Any parameters that the DMA unit leaves the way you want them need not be re-specified (the source address and transfer size at least are modified during the transfer). It's probably safer to reset everything, particularly if the code is not final and the project is large.

...

Also, I gather that you've converted the NES graphics to SNES format, doubling the size. This is not necessary. As I mentioned earlier, you can transfer NES 2bpp format from ROM into SNES 4bpp format in VRAM by only DMAing bytes to either $2118 or $2119, rather than words to both (and setting $2115 to increment the VRAM address after a write to whichever byte you're using). Converting the data to be twice the size is not necessary. The only catch is that the palette ends up noncontiguous, because you're writing only even or only odd bitplanes, rather than the first two.

You may have gone too far down this path to want to change it now. It's not a big deal either way unless you end up bottlenecked, which I gather is unlikely.

[infidelity]

I just had the hi byte for the vram wrong. I setup an infinite loop at the end of my dma for on-the-fly manual testing, and altered the ram values.

00=$0000 vram
01=$0200 vram
02=$0400 vram
Etc, etc

I have the gfx pointer now loading correctly, and storing correctly in vram!

I converted all gfx (bg/Sprite) to 4bpp, I know there's no need for that, but I wanted to go that route anyways.

The read of $4112, I have that cause the original nes game does LDA $2002, and I want to have the equivalent to make sure nothing crashes in the game.

[93143]

The read of $4112, I have that cause the original nes game does LDA $2002, and I want to have the equivalent to make sure nothing crashes in the game.

Okay, but $4212 is not $2002 and doesn't behave the same. Why does the NES read that register?

[tepples]

A closer counterpart to NES PPUSTATUS ($2002) is SNES RDNMI ($4210). For both registers:

• Bit 7 goes high on vblank and low at end of vblank or after a read.
• If this register hasn't been read, disabling and reenabling NMI during vblank causes a second NMI.

There are a handful of reasons for an NES program to read $2002:

1. To prevent a second NMI if NMI is disabled and reenabled.
2. To reset the first/second write flag for $2005 and $2006.
3. To detect sprite 0. On SNES, the HV interrupt or HDMA is used instead.
4. To detect 9 sprites. Not used in many commercial-era games that I'm aware of. The closest SNES counterpart is STAT77 ($213E).

[infidelity]

A closer counterpart to NES PPUSTATUS ($2002) is SNES RDNMI ($4210). For both registers:

• Bit 7 goes high on vblank and low at end of vblank or after a read.
• If this register hasn't been read, disabling and reenabling NMI during vblank causes a second NMI.

There are about three reasons for an NES program to read $2002:

1. To prevent a second NMI if NMI is disabled and reenabled.
2. To reset the first/second write flag for $2005 and $2006.
3. To detect sprite 0. On SNES, the HV interrupt or HDMA is used instead.
4. To detect 9 sprites. The closest SNES counterpart is STAT77 ($213E).

Thank you tepples!

[infidelity]

I am now at the point where the game starts pulling the current stage id, modifies it by adding 20 to it, to obtain the bank id for the current stage construction data, it always loads the data from A000-BFFF, so right now I'm playing through the entire nes game, I wrote a routine to log every created bank id and store it into wram, once I see it logged I'll write down what screen/stage it belongs to. Once I have all of them, I'll then begin the process of how to set all of these banks up within my port.

[creaothceann]

I wrote a routine to log every created bank id and store it into wram, once I see it logged I'll write down what screen/stage it belongs to

Maybe you can replace the value, and quickly test all variations. If you're lucky the game instantly crashes for invalid values.