8x16 and whatever else unreg wants to know

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

According to nesdev wiki, the serial register can be lost if NMIs occur, but rendering and NMIs on VBlank have been disabled... so this still doesn’t make sense.

Will continue to work this weirdness out. :)


edit: Fiskbit, (Thank you Fiskbit! :D), sheds light on this problem in Sour’s Mesen thread:
Fiskbit wrote: Tue Sep 22, 2020 4:21 pm Different serial registers have different ways of handling the serial writes. w is used specifically for the $2005 and $2006 PPU writes, which take 2 writes. You're correct that interrupts can be a big problem for serial registers; if the handler needs to use a serial register that is also used outside the interrupt, then the two might interfere with each other. This also happens in cases like MMC3, where you write to two different registers to do something like swap banks.

MMC1 has a 5-write serial register, but this isn't using the w bit in the PPU; it has its own method of tracking the 5 writes. Unfortunately, Mesen doesn't allow you to see the interior state of a mapper. There's a ton of mappers and they all have their own registers and behavior, so it's not an easy thing to expose. As a result, it's a bit hard to debug MMC1 issues where your number of writes is wrong.
So, it seems that implementing thefox’es code ideas, link on the bottom of that linked nesdev wiki page, is crucial to solve this problem. ...However, rendering and vblank interrupt are disabled, so vblank’s nmi isn’t destroying MMC1’s 5-write serial register, right? I’ll find out later today. :)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 and whatever else unreg wants to know

Post by tepples »

It's not that vblank and NMI destroy the MMC1 per se as much as that trying to write to it from both the main and interrupt threads causes a conflict over the resource. There are a few ways to work around it, one of which involves never switching banks in the NMI handler.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Ahh, thank you tepples! :D That’s a great strategy, but I don’t believe this is an issue.

The nesdev wiki, in the MMC1’s “Higher CHR lines” section, says:
In these scenarios, however, both CHR bank registers must be set to the same value (or the CHR bank size must be set to 8KB), or the PRG ROM/RAM will be bankswitched as the PPU renders, causing disastrous results.
That sounds like what I’m experiencing... disastrous results. (We’re using MMC1’s SUROM.)

Maybe the CHR registers aren’t the same value anymore? I believe the CHR bank size is set to 4kb. Hmmm... where are the CHR registers? Haven’t used them in a loooooong time. :)


edit: but, rendering is disabled when PRG ROM banks become 0 and 1... and that doesn’t make any sense anyways bc the second PRG bank should be restricted to only either bank 15 or 31. :?

final-edit: I remember changing the CHR bank size to 4kb a while ago since our CHR files all fit in a 4kb space, but the CHR bank size must not matter at all bc we’re using CHRRAM now, so CHR banks aren’t used. This seems like the solution! :D
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Sigh, sorry, we’re actually using SXROM... why do we need 32kb of PRGRAM?

Anyways, the CHR register is used to select 256kb PRGROM bank0 and 8kb PRGRAM bank0.

Next, $0E is correctly written to $8000 to set MMC1 for vertical mirroring, fixed $C000, and 8kb CHRRAM pages (using CHRRAM).

My question is: since SXROM is listed as Japan Only, does that have any effect on the problem I’m experiencing? Or, maybe tepples is right and the NMI and MainLoop are each attempting to set banks and one interrupts the other.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Rendering is disabled inside of vblank, so the interrupt flag is set... then the PRGROM banks are changed after writing the first 4K CHR file to PPU $0000. During this PRGROM bank change, on cycle 119 of Scanline 225, the Interrupt flag is still set.

Does changing banks outside of vblank, with rendering disabled, and the Interrupt flag set, cause the NES to change both PRGROM banks to bank 0 and bank 1? Even when the second PRGROM bank can only be either 15 or 31?

edit: the second PRGROM bank is fixed to either bank 15 or 31. Isn’t the only way to change that have to do with writing to the CHR register?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 and whatever else unreg wants to know

Post by tokumaru »

MMC1 sucks, and this convoluted "official hack" of using CHR banking to increase PRG size only makes it worse. I honestly don't know why homebrewers still pick this mapper...
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 and whatever else unreg wants to know

Post by tepples »

My guesses:
  • Available UNROM 512 and GTROM boards lack extra work RAM at $6000-$7FFF.
  • At one time, the 5 volt tolerant CPLD to hold MMC3, FME-7, or other "advanced" mappers with built-in WRAM support cost more than the 5 volt tolerant CPLD to hold MMC1.
  • Even MMC3 lacks more than 8K of WRAM.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

OOOOOH, now, thank you top of nesdev wiki MMC1 page, writing a negative value, bit7 set, to any address in $8000-$FFFF causes ONLY the shift register to reset! If bit7 is set the shift register isn’t written to... so that’s why the game is one write behind. :D PRAISE GOD!! :mrgreen: :D

My problem was that I was trying to use bit7, in the variable to write to ROM for bank change, as a flag. Wow :o that was a poor mistake... but, it’s ok now. :)

The nesdev wiki is super helpful! :)


edit: the simplest solution is to “and #01111111b” after that variable is loaded into the accumulator, before the first of 5 ROM writes. Sweet! :)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

This is a helpful note to others.
———-

I’ve been trying to troubleshoot sprite collision and today, I wanted to see what my sprite’s value in OAM was, bc it takes a while for values written to page 2 to be DMA’ed. After scouring the wiki for hours to find the address of OAM in the PPU memory, and then after finding this page:

https://wiki.nesdev.com/w/index.php/PPU_memory_map

it ended up letting me discover that OAM is NOT a part of the 16K-PPU-Memory (it’s a separate 256kb bytes of DRAM). So, after revisiting Mesen’s Memory Tools, it happily allows me to view Sprite / OAM RAM! 😀


That’s extremely helpful bc OAM does, currently, contain a different value than $0200.


EDIT: :oops: thank you tokumaru! :)
Last edited by unregistered on Thu May 13, 2021 8:10 am, edited 1 time in total.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: 8x16 and whatever else unreg wants to know

Post by tokumaru »

Small correction: the OAM is 256 bytes, not kilobytes (to be really pedantic, it's actually less than that, because the unused attribute bits are not saved).

Anyway, the OAM is like the palette RAM. They're extra pieces of memory located inside the PPU itself. The difference between them is that the PPU maps the palette to part of the VRAM addressing space ($3F00-$3FFF), even though it's not actually stored in VRAM.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

tokumaru wrote: Wed May 12, 2021 6:05 pm (to be really pedantic, it's actually less than that, because the unused attribute bits are not saved).
Oooh! So that’s why all of the unused 3rd bytes are #$E3! Really cool to know! Thank you tokumaru! 😀
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Hi all.

My rom doesn’t load in Mesen. Can’t select the debugger and Mesen’s screen is a constant black.


Haven’t a clue why this happened… I have been gdb debugging asm6 to learn more about why it has refused to assemble a 5th-in-a-row asl, when the lst file includes that asl, but then it did assemble it. MY ASM6 ASSEMBLER HASN’T BEEN TAMPERED WITH SINCE 2/24/2021 5:20 PM. It’s obviously been used, successfully, many many times since.

Is there a way to see why my .nes file fails to load in Mesen? Maybe an error list file of some sort? This is confusing… Mesen runs all other roms, that have been tested, perfectly.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

^Nintendulator says:
Loading file ‘(my file path here)’
iNES ROM image loaded: mapper 1 (MMC1) - Fully supported!
PRG: 512KB;CHR: 0KB
Flags: Battery-backed SRAM, Vertical mirroring
Loaded successfully!
Loaded SRAM (8192 bytes)
Performing hard reset…
Reset complete.
And… then it just does nothing with a black screen.


(Using Nintendulator Version 0.970)
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

Due to lack of response, I’m going to guess that the ROM has been built invalidly. And I’ll build it with the real asm6 just to see what happens. 🙂
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered »

WOW! The real asm6.exe also spouts an nes file that causes a black screen… so, is it not possible for asm6 to assemble 5 asl statements in a row?


Is there a simpler way of arriving at the byte shifted left five times? Maybe rotating right 4 times?

___
EDIT: Replacing those asl with a clc and 4 ror statements cause nothing new to happen; just a black screen.

“chkdsk [drive letter]: /r” in Windows cmd.exe finished successfully (no errors found, no errors fixed).

So, the problem has nothing to do with my hard-disc sectors, asm6_ changes, or 5 asl statements used. It’s an asm6 problem; if you could help with any type of info, that would be an awesome blessing! :D
Post Reply