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: 1098
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Tue Sep 22, 2020 3:59 pm

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: 22090
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 » Thu Sep 24, 2020 5:01 am

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: 1098
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Tue Sep 29, 2020 9:11 am

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: 1098
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Tue Sep 29, 2020 2:56 pm

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: 1098
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Wed Sep 30, 2020 3:02 pm

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: 11892
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 » Wed Sep 30, 2020 9:07 pm

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: 22090
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 » Thu Oct 01, 2020 4:54 am

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: 1098
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Fri Oct 02, 2020 3:28 pm

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! :)

Post Reply