MMC5 problems...

[Anes]

$6000-7FFF will have RAM, never ROM. So you are correct there.

Uncharted Waters will not jump to $7xxx without first writing necessary PRG data to RAM. Though I don't think it does that (it wouldn't have any reason to).

Are you sure UW is actually supposed to be jumping to $7xxx? Maybe you have some other PRG swapping mistake that's making it erroneously jump to a bad address?

I have checked and re-checked and fixed some problems so, it's not jumping to $7xxx.
What it does now is a JSR to $8000 where i get 0x5C Unofficial Opcode.

Anyway the game IS writing to registers $5114-5116 to do prg-rom swapping but it sticks prg-mode to "0"! so it doesn't swap anything!!

[Disch]

After doing a quick check, it doesn't look like UW ever writes to $5100. So your emu should be defaulting to mode 3 (8k mode) on Reset.

I clearly remember having this problem with some games... and thought I put that in the doc, but I can't seem to find it there. Whoops.

[Anes]

After doing a quick check, it doesn't look like UW ever writes to $5100. So your emu should be defaulting to mode 3 (8k mode) on Reset.

I clearly remember having this problem with some games... and thought I put that in the doc, but I can't seem to find it there. Whoops.

Yes, you are right. I changed to "3" and now i can hear some music. My target now is ex1 mode, such a big thing.
Thnks.

[Anes]

Disch you wrote:

Code: Select all

Extended Attribute Mode:
 ---------------------------
 When in Ex1 mode (see $5104 above), ordinary attribute tables and BG CHR regs are ignored, and instead, each
 byte in ExRAM coresponds with an onscreen tile, and assigns that tile a 4k CHR page (allowing you to choose
 from 16k tiles instead of 256) and its own attribute bits (allowing each 8x8 tile to have its own palette,
 rather than having the normal 16x16 blocks).
 
 Bytes in ExRAM:
   [AACC CCCC]
     A = Attribute bits
     C = 4k CHR Page

How is this "assigns that tile to a 4K CHR page"?
Do i have to read from CHR-ROM i mean something like:

Code: Select all

tile = g_pChrRom[(data & 0x3F) * 4096]

Where g_pChrRom is all CART CHR-ROM.
Of course is my emu is Reading from 1024 bytes extra-ram. But how can it address 16K if extra-ram is 1024?
Im confused, need some explanation. i cannot make it to work.
Help!!

[natt]

Looking at it from the perspective of the fetch pattern, here is roughly what should be done:

1. PPU fetches an NT byte; that is, (addr >= 0x2000 && (addr & 0x3ff) < 0x3c0)
Return the NT fetched byte as requested from whatever nametable is in context. Let N = addr & 0x3ff; that will be your index into ExRAM for the next fetch.

2. PPU fetches the corresponding AT byte.
Do not return anything from normal PPU space here. Instead, return the two top bits of exram[N] as the attribute (they will need to be shifted into the correct bit position). Let B = exram[N] & 0x3F; this will give you the block to get pattern tables from.

3. PPU fetches the low pattern byte (first bitplane).
The bottom 12 bits of the address for this should be passed through as is from the PPU. The next 6 bits are B. The top two bits are from the register at 0x5130. This gives a total of 20 bits of address into a 1MiB CHR ROM; remove top bits for smaller CHR ROMs as appropriate.

4. PPU fetches the high pattern byte (second bitplane)
Do exactly as in #3. PPU A3 will be high this time, where it was low last time.

[Disch]

Assuming you want a bit of a higher level explanation.

In ExAttribute mode, the normal CHR swapping regs for the BG are ignored completely (except for $5130). So instead of doing normal CHR swapping.. you can think of it where each 8x8 tile swaps in its own 4K page just for that one tile.

So for each bg tile... the page you swap in is: ExBits | (reg5130 << 6)

[Anes]

3. PPU fetches the low pattern byte (first bitplane).
The bottom 12 bits of the address for this should be passed through as is from the PPU. The next 6 bits are B. The top two bits are from the register at 0x5130. This gives a total of 20 bits of address into a 1MiB CHR ROM; remove top bits for smaller CHR ROMs as appropriate.

With "The bottom 12 bits of the address for this should be passed through as is from the PPU" do you refer to PPU ADDR i mean the addr that can be changed with $2006?

Sorry, but sometimes is difficult to me to understand.

[Disch]

When the PPU fetches a CHR byte it'll put $0xxx or $1xxx on the PPU address bus. When in ExAttr mode, the MMC5 takes the low 12 bits of that... the 6 bits from ExRAM... and the 2 bits from $5130 to form a 20 bit address from which it will fetch the CHR data.

The address is:

Code: Select all

FFXX XXXXAAAA AAAAAAAA

F=bits from $5130
X=ExRAM 'chr page' bits
A=low bits from PPU address (Loopy_V)

Or.. if you want more detail as to bits:

Code: Select all

FFXX XXXXTTTT TTTTPYYY

F=bits from $5130
X=ExRAM 'chr page' bits
T=Tile number
P=bitplane (0 for low, 1 for high)
Y=pixel row (fine vertical scroll)

Though really... this is probably thinking of it as more complex than it needs to be. Conceptually the ExRAM bits just select a 4K page. You use that instead of the normal CHR swapping regs. The rest is the same as normal.

[Anes]

ok i got it now. But still have problems. Graphics not looking good.
Is it supposed this 20 bit addr is absolute to CHR-ROM?
I mean, for simplicity say i have an unsigned byte * that holds all the CHR data.
I have trying making something like:
I build the 20 bit addr like so:

Code: Select all

addr = Mmc5.upper_chr << 18;
addr |= (ex1 & 0x3F) << 12;
addr |= (Ppu.addr & 0xFFF);

Where Mmc5.upper_chr is reg5130, ex1 is the byte read from extra-ram and Ppu.addr is PPU ADDR reg.

For step 3 as natt says i do:

Code: Select all

biteplane_0 = chrmem[addr];

For step 4:

Code: Select all

biteplane_1 = chrmem[addr | 8];

Where chrmem is the whole chr-rom.
Is that wrong?

[natt]

ok i got it now. But still have problems. Graphics not looking good.

That all looks correct. If it's not working right, it's probably a silly transcription error somewhere.

[Disch]

Are you updating the PPU addr to reflect the tile number? Or is it still the scroll? You should be doing the former.

Normally the PPU addr has the scroll value in it, but to fetch CHR, it puts the tile number on the bus instead.

I was mistaken when I said that was Loopy_V. I'm kind of rusty. Loopy_V would be the scroll and that's not correct. It's actually just the normal address of the CHR to fetch.

[Anes]

Are you updating the PPU addr to reflect the tile number? Or is it still the scroll? You should be doing the former.

Normally the PPU addr has the scroll value in it, but to fetch CHR, it puts the tile number on the bus instead.

I was mistaken when I said that was Loopy_V. I'm kind of rusty. Loopy_V would be the scroll and that's not correct. It's actually just the normal address of the CHR to fetch.

I don't have a tile_number var i do it all with ppu ADDR.
So if i have a tile_number var how is it supposed to be clocked?

[Disch]

Nevermind I think I might be confusing you more =X

Check natt's previous post with the fetch pattern again. That covers it as well as I can.

Though again... I really think we might be making this more complicated than it needs to be. You fetch the CHR the same way as with any other game. The only difference is the CHR page is selected by the ExRAM byte rather than the CHR swapping regs.

[natt]

Post a screenshot of Just Breed? Might be able to tell something from it.

Might not.

[Anes]

Thanks to Disch and natt now i have:

Do you see the image cropped in its upper part. It's about four tiles cropped.
I suppouse its a scrolling thing, but i cannot find the error.
Any Idea??

Edit: It seems to be in KOEI games only.