Black/Dead scanline problem + 65816/SPC700 timing?

[gauveldt]

ZSNES SVN Revision: 3415

It seems the Mode 7 flying scene in the intro of Tales of Phantasia has a scanline glitch. I tried unsuccessfully to save the glitch in BMP (using PNG wrote corrupted files) the snapshots didn't show the glitch appearing on screen. Since it's not showing up on screen dumps this may be a filter/display driver glitch.

It starts as a black line in the horizon part of the scene and about halfway through the black line goes and then a scanline glitch of garbage stays around the middle sprite (Cless on the wing-thing--don't spoil it as I haven't gotten that far in that game yet).

Video mode: Variable ODR,W
(Variable, OpenGL, Display filters, keep-aspect, windowed)
Any window size reveals the glitch.

This game is a real hardware banger as far as the SPC goes too. There are occasional sound glitches when the 65816 EMU can't keep up with the SPC-700 EMU (either that or the timing is off -- I know from doing famidev coding on a genuine SNES that the timing of sending data to the SPC-700 ports is very finicky). Fixing this may require temporarily incorporating port event dumping of access to 2140-2143 on the 65816 EMU side and F0-F3 on the SPC-700 side and noting if it's the 65816 hitting the ports or an H-DMA operation on the 65816 side).

Game used at time of discovery:
TOP ENGLISH (C) DEJA
TYPE:NORMAL
INTERLEAVED:NO
BANK:EHI
CHKSUM:OK
VIDEO: NTSC
CRC32:14612848

My system:
AMD AthlonXP 2900
1GB SDRAM
NVidia GEForce OpenGL vendor driver for Linux (XFree86)
Linux nall 2.6.8-2-k7 #1
Tue Aug 16 14:00:15 UTC 2005 i686
GNU/Linux
Debian SARGE Linux

ZSnes SVN Revision 3415

[gauveldt]

ZSNES SVN Revision: 3415

It seems the Mode 7 flying scene in the intro of Tales of Phantasia has a scanline glitch. I tried unsuccessfully to save the glitch in BMP (using PNG wrote corrupted files) the snapshots didn't show the glitch appearing on screen. Since it's not showing up on screen dumps this may be a filter/display driver glitch.

PS: The stable release officially avaialable at www.zsnes.com (1.42--the 18-month old version) does NOT have this display problem.

[byuu]

Ah, so this would be your document here?
http://www.alpha-ii.com/snesmusic/files ... ation.html

Fun. Qwertie popped up a while earlier, too. Wonder when Lord ESNES or Trepalium will pop in :)

Well, no offense but pagefault and co probably know quite a bit more about the inner workings of the SNES at this point. The problem with ZSNES is that the SPC700 core lacks timing. Every opcode just uses a timing average, for speed reasons. So as it stands, 'div ya' takes the same amount of time as 'nop'. I would imagine that once that is remedied, your sound glitches will start to go away.

As for the black line, who knows. When does ZSNES render the scanline? I use dot >=48 and that seems to work for most games that do mid-scanline PPU register writes (Dai Kaijuu Monogatari 2, Metroid 3, etc). Would probably work for ToP, too. Obviously a dot renderer would be better, but yeah that isn't happening this decade for ANY SNES emulator :/

[pagefault]

Hi,

Thanks for the bug report. The SVN code is currently a work in progress and it has some issues. As far as I can tell using the windows port with that revision I cannot reproduce the bug, so perhaps it is a linux only bug at this point. As for the sound not being right, there is currently a problem with the SDL audio output driver that causes ToP and other games that have timing sensitive sound output to sometimes produce static. SVN is using the same audio code as 1.42 but some changes may have made this bug more noticabe. There is effort to get this fixed but because linux is not my primary OS it is taking considerably longer since I am not very familiar with the way the sound works.

The state the entire tree is right now isn't very good for playing games as we are in the middle of porting a lot of the old assembly code to C so there are many bugs we still have to work out and some side effects like that stray scanline may be a side effect from them.

We are well aware of the CPU and SPC timing problems in the current code and we are working on bringing them up to spec with what knowledge is known today about the SNES. The overhauled CPU core should be in SVN in a few weeks which should help to clear up many of the SPC<->CPU issues we are currently having, as well as decoupling the SPC core from the main execution loop to let it run free. For now it might be a good idea to stick to 1.42 or an earlier revision until we can work out these problems.

[gauveldt]

Ah, so this would be your document here?
http://www.alpha-ii.com/snesmusic/files ... ation.html
Fun. Qwertie popped up a while earlier, too. Wonder when Lord ESNES or Trepalium will pop in

Well, no offense but pagefault and co probably know quite a bit more about the inner workings of the SNES at this point. The problem with ZSNES is that the SPC700 core lacks timing. Every opcode just uses a timing average, for speed reasons. So as it stands, 'div ya' takes the same amount of time as 'nop'. I would imagine that once that is remedied, your sound glitches will start to go away.

Yeah that's me; however, it is a really old SPC-700 doc circa around 1994-95. I should have put a date on it. The email address there also no longer applies since I've long ditched 56k dialup for internet access.

The lack of timing may well be a problem (for many ROMs since there are many that send music data over the SPC ports -- these games also usually don't generate useable SPC dumps either -- dump the sound buffer, load a tracker, split the dump to samples, and with much tedium recompose the song). I'll have to look back thru my backup CDs and see if I have anything with SPC700 timing refs, unless some of the modern ZSNES developers already have this information.

ToP was a later generation game and thus had programmers who had all the nuts and bolts for what could be bashed out of the SNES hardware. The SPC programming ToP uses rocks (streaming sample input, surround sound encoding as well as stereo and mono, AND graphical equalizing of the output!)! One of the ones that really makes SNES audio shine. Coprocessed sound was well ahead of its time when the famicon/SNES came out. SNES-tracking with this core would give ImpulseTracker quite a competition.

As for the black line, who knows. When does ZSNES render the scanline? I use dot >=48 and that seems to work for most games that do mid-scanline PPU register writes (Dai Kaijuu Monogatari 2, Metroid 3, etc). Would probably work for ToP, too. Obviously a dot renderer would be better, but yeah that isn't happening this decade for ANY SNES emulator :/

As I mentioned also SNES 1.42 didn't have this problem -- it creeped up some point along the SVNs. It wasn't until I went to an SVN version that I started getting the scanline glitch.

Screen dumps don't show the problem which suggests something on the final render that is not working. Whether dot-based processing would fix this I'm uncertain. Only someone who's spent more time in the ZSNES code would know for sure.

[gauveldt]

Hi,

Thanks for the bug report. The SVN code is currently a work in progress and it has some issues. As far as I can tell using the windows port with that revision I cannot reproduce the bug, so perhaps it is a linux only bug at this point. As for the sound not being right, there is currently a problem with the SDL audio output driver that causes ToP and other games that have timing sensitive sound output to sometimes produce static. SVN is using the same audio code as 1.42 but some changes may have made this bug more noticabe. There is effort to get this fixed but because linux is not my primary OS it is taking considerably longer since I am not very familiar with the way the sound works.

I should mention that the sound issue was a problem in 1.42 as well as the SVN edition; however, perhaps this is a good thing, the incidence is a bit lower in the SVN. The SVN actually occasionally lets me play The Dream Will Never die in the sound test window without glitching. Actually it's more likely to glitch in the sound test window than it is to glitch during the intro.

Something was mentioned elsewhere about a switch to OpenGL diplsay lists. Could this be where the scanline problem is emerging? The problem doesn't show in BMP dumps (oh yeah check the PNG code as I get corrupted images [vertical line artifcats along the entire image and generally incorrect data though you can kinda see the image in garbagy, noisy sort of way] when I try to save as PNGs), meaning that the display buffer at the time of BMP dumping doesn't show the dead scanline.

Hence why I speculated a potential final rendering filter/driver issue.

I know about living on the bleeding edge... All mayhem breaks loose when the ROM name is specified on the command line in the afformentioned SVN. The pick state window doesn't even draw correctly (the cursor box draws out of the window). It's eerie and fascinating all at the same time.

You mentioned no one on the devteam is familiar with linux infrastructure. Any particular areas you need help with?

[gauveldt]

Hi,

Thanks for the bug report. The SVN code is currently a work in progress and it has some issues. As far as I can tell using the windows port with that revision I cannot reproduce the bug, so perhaps it is a linux only bug at this point. As for the sound not being right, there is currently a problem with the SDL audio output driver that causes ToP and other games that have timing sensitive sound output to sometimes produce static. SVN is using the same audio code as 1.42 but some changes may have made this bug more noticabe. There is effort to get this fixed but because linux is not my primary OS it is taking considerably longer since I am not very familiar with the way the sound works.

I was infromed in another thread that submitting bug reports against 1.42 was futile and was advised to check out the latest SVN before issuing one.

[pagefault]

Ah yeah, technically right, but right now even SVN isn't really good for submitting bugs, we are sort of in transition. But I will make a note of this and be sure to check up on it.

[creaothceann]

All mayhem breaks loose when the ROM name is specified on the command line in the aformentioned SVN. The pick state window doesn't even draw correctly (the cursor box draws out of the window). It's eerie and fascinating all at the same time.

Sounds like a wild pointer.

[gauveldt]

Ah yeah, technically right, but right now even SVN isn't really good for submitting bugs, we are sort of in transition. But I will make a note of this and be sure to check up on it.

So long as I can continue my game in Tales of Phantasia without anything major that avoids zsnes or ToP from running altogether all is cool.

Is there a way to "rewind" to a previous SVN revision if I hit one that stops zsnes or ToP cold? The current SVN revision I'm using seems to work but at the same time I'd like to keep current so long as nothing is broken (and in the event something is) I'd also like to move ahead again periodically to see if stuff works again (again just reverting back to the last known working SVN revision so long as the latest revision is broken).