blargg's test rom's console output

blargg's test rom's console output
by beannaich on 2011-10-11 (#84958)

Ok, here's a weird one. I was running some of blargg's magnificent test roms on my emulator, when the output window of one of them caught my eye™

At first, I thought the entire window was screwed to hell. But then I noticed that only strings are garbled, constants and numbers are just fine!

Code:

01-/garbled crap here/
02-/garbled crap here/
...
11-/garbled crap here/

So, I went digging through the source to see what was going on. I see a lot of calls to a sub-routine called "print_char_", yet I can't find it's definition anywhere. Anyways, if anyone knows more about this (read: blargg) and wants to help me out, that would be splendid!

edit: all string character values seem to be -40h of what they should be..

by tepples on 2011-10-11 (#84959)

Try replacing each such character with the character 64 characters later in the ascii table. For example, in Python:
Code:
string_01 = """)-0,)%$"""
print "".join(chr(ord(c) + 64) for c in string_01)
string_02 = """)--%$)!4%"""
print "".join(chr(ord(c) + 64) for c in string_02)

produces
Code:
implied
immediate

Your homework:
Make a pattern table viewer.
Look at what's being written to the nametable memory. If it looks garbled, the problem is in your CPU. If it looks like ASCII, the problem is in your PPU, possibly in your CHR bankswitching.

by beannaich on 2011-10-11 (#84961)

Beat me to it, tepples!

I still have no idea why this is occurring, my cpu passes all test roms. do you have any clue where "print_char_" is defined? that might help me to solve this bug.

I have a pattern table viewer, it looks garbled there as well. I know the problem is with the CPU, that's why I was digging around in the source. I just can't find where in the source the characters are actually printed.

by tepples on 2011-10-11 (#84962)

beannaich wrote:
do you have any clue where "print_char_" is defined?

Set up a debugger and trap all writes to $2007.

Can I see 1. the output of your pattern table viewer, 2. the output of your nametable viewer, and 3. a hex dump of the relevant page of nametable memory?

by beannaich on 2011-10-11 (#84963)

tepples wrote:
Can I see 1. the output of your pattern table viewer, 2. the output of your nametable viewer, and 3. a hex dump of the relevant page of nametable memory?

The ROM isn't bugged, if that's what you're getting at. I'll log all writes to $2007.

edit: log suggests that the ppu is doing things wrong. which is odd since i can run other roms just fine

by tepples on 2011-10-11 (#84965)

This 64 tile difference is also the size of a CHR bank in MMC3 and plenty of other mappers. What mapper is the demo using, and how are you initializing its banks?

by beannaich on 2011-10-11 (#84966)

the test rom uses MMC1, below is my rom initialization code:

Code:
base.SwitchChr(Chr.Size08, Chr.Addr0000, 0x00);
base.SwitchPrg(Prg.Size16, Prg.Addr8000, 0x00);
base.SwitchPrg(Prg.Size16, Prg.AddrC000, 0x0F);

SwitchChr is defined as:

Code:
protected void SwitchChr(int addr, int size, int page)
{
page *= (size);
page &= (console.Rom.ChrRom.Length) - 1;
addr &= (size - 1) ^ 0x07;

for (int i = 0; i < size; i++)
{
chrBank[addr++] = page++;
}
}

by tepples on 2011-10-11 (#84969)

Two things to try from here:

A. Print what's in chrBank[] each frame.
B. Step through your tile fetching in your IDE's debugger.

by beannaich on 2011-10-11 (#84971)

tepples wrote:
A. Print what's in chrBank[] each frame.

SwitchChr is only called during initialization for this ROM. chrBank's contents are chrBank[n] = n

tepples wrote:
B. Step through your tile fetching in your IDE's debugger.

I'll give this a shot.

by beannaich on 2011-10-12 (#84983)

Figured it out, it was indeed the chrBank[].

I had assumed that the buffer was being written to properly, and it wasn't. The buffer was filled with all 0's, causing every char to be read from the same 64 char page, as you alluded to earlier.

D'oh!

by Zelex on 2011-10-12 (#84990)

Never doubt tepples.... never

by beannaich on 2011-10-12 (#84995)

Sherlock Holmes' skills of reasoning and deduction are second only to tepples.