MOB Animation Issues on D1K and D2K Emulation

[+wavemotion]

I realize this should probably be in the Emulation forums - but most of the folks there are players and I think I need a bit more specific clues from those that understand the Intellivision HW. So here's a shot in the dark.

Let me start by saying that I'm a self-starter and tend to exhaust a lot of debug and possibilities on my own before reaching out for help - so I'm currently at the 20+ hour mark and decided to see if anyone has a clue to push me in the right direction

My new Intellivision emulator for the DS/DSi is based on the old BLISS core (last updated a decade ago). I've cleaned it up and fixed some of the more annoying issues such as the sprite flicker on Stampede and fireball glitches in MotU. I also fixed the timing issues that prevents Motocross from running.

One of the very few remaining problems is really strange. It only manifests itself on D1K and D2K (great games! Love to support Carl's efforts) - when the Ape is climbing the girders on cut-scenes. No other aspect of this game shows the glitch.  When the ape climbs, you can see a gaping hole in the middle of the animation - and some rogue pixels that don't look right to the sides of the ape.  Once the Ape gets to the top and starts "bouncing" to the right... it looks perfect. All other animations of the ape (rolling eyes, rolling barrels, etc.) and the game look perfect until the next climbing cut-scene.

 

So far my debug has confirmed that this animation is done using most of the MOBs (and not background tile shuffle/animation). At first I thought it was simply a priority problem - but I've gone over that code 10 times and played with the Mob Collision Test program and the Color Stack Fiddler program and as near as I can tell, all 8 MOBs are rendered correctly, in priority order and with proper background priority interactions. All stretching and 1/2 card handling for MOBs appears correct.

I then thought maybe it was related to my STIC timing - maybe we were going into Bus Isolation mode too early/late. I fiddled with the timing and even produced a temporary version that never went into bus isolation mode to see what effect it had:  no difference.

 

I thought maybe the emulator was incorrectly determining what MOBs were "dirty" in terms of needing to be re-rendered... so I forced all MOBs to display all the time and while that slows my emulation down, it still made no difference.

 

Near as I can tell the actual graphical cards pointed to have the glitchy graphics... so I think I'm rendering what's being pointed to ... but what's being pointed to is semi-garbage.

Any thoughts of any kind from programmers as to what might be happening here? Even a total guess might lead me in the right direction.

 

As always, I appreciate this community and anyone taking the time to read this plea for help!

Edited October 5, 2021 by llabnip

[R.Cade]

That happens in the MiSTer FPGA implementation of the INTV also. It must use a trick that is undocumented, accidentally or not.

 

 

[+wavemotion]

6 minutes ago, R.Cade said:

That happens in the MiSTer FPGA implementation of the INTV also. It must use a trick that is undocumented, accidentally or not.

That makes me feel better, actually!
I did mention this to Carl with my payment but he didn't specifically respond to it... not that I blame him. $10 shouldn't buy you design-level support for anything  

I wonder what the "trick" is...

[carlsson]

Without Bus Isolation, is that another term for being able to address the STIC anytime, not just during the two time slots that us IntyBASIC programmers know as DEFINE and DEFINE ALTERNATE?

[+wavemotion]

11 minutes ago, carlsson said:

Without Bus Isolation, is that another term for being able to address the STIC anytime, not just during the two time slots that us IntyBASIC programmers know as DEFINE and DEFINE ALTERNATE?

Correct. I basically disabled the bus isolation so you can access the STIC and GRAM stuff anytime. That's not correct - nor is it accurate... but mostly was just trying to figure out if Carl was hitting that hardware close to a cut-off point that my emulation wasn't getting right.  Even allowing STIC access anytime from anywhere didn't seem to make any difference in this particular glitch.

I also tried the opposite... shortening the window where the STIC is accessible to see if maybe he was accidentally hitting it when real hardware would have disabled it... that didn't work either.

Edited October 5, 2021 by llabnip

[+wavemotion]

Still working on this issue in my "spare" time

I built a mini-debugger into my DS emulator for the Intellivision. Enough to let me know what's happening with the CPU, STIC, PSG and various key RAM locations. It let's me pause, single step a CPU instruction or run 1 frame at a time.  Near as I can tell, the D1K (and D2K by extension) doesn't do anything too funky - the background tab memory is not changing during any of these glitchy frames of animation. There isn't any tricks being played STIC-wise that I can detect - in fact there appears to be plenty of frames where nothing changes to slow down the "climb" of the ape.

 

Near as I can tell, all of this animation action happens via the 8 MOBs which are used to render the ape climbing. A few of the MOBs are marked with horizontal mirroring - which I'd be surprised if I got wrong in the emulation core as I'm sure other games use it... but I'll definitely double check to see if maybe there is some boundary condition that isn't right.   The only other thing I see in the MOBs inspection is that 7 of the 8 MOBs are rendering from GRAM and the 8th is rendering from GROM. Again - shouldn't be an issue, but I'll double check that we handle that properly.  It's perplexing to be sure... if any keen programmer sees anything in the MOB inspection (2nd image) that looks a bit "unusual" (in that it's not commonly done) - I'd be interested as it might point me in the right direction to find my emulation bug.




Edit: I just noticed that the xLocation for Mob 8 is off the screen (0xFD = 253). I don't check for that - so I added a check to not render a MOB if it is greater than position 167 (not sure what the right number is here... but I figure to be a bit safer to include horizontal shift by up to 7 pixels). This didn't fix D1K or D2K but did fix the long standing BLISS (and possibly MAME) core bug for Q-Bert where you lose a life after clearing every board. So at least something good has come from the debugger! Looks like the programmer just jammed most of the MOBs out to X position 255 (0xFF) to get them off the board when a level is cleared and the buggy emulation rendered an off-screen collision of Q-Bert with one of the baddies... so that mystery is solved. Now if I can just figure out the D1K glitch - it's the last glitch I know about. 

Edit#2:  The 7th mob is also a little unusual in that it's sourced from GRAM but the card number is 0xFB which is outside the 64 card limit for GRAM. The emulator will AND that with 0x3F so it looks like we do support this ... but it's a little strange. 

Edited October 18, 2021 by llabnip

[+nanochess]

Maybe this can help: When a MOB is using the 16-pixel height flag, the lower bit of the card number should be taken as zero by the STIC.

[+wavemotion]

31 minutes ago, nanochess said:

Maybe this can help: When a MOB is using the 16-pixel height flag, the lower bit of the card number should be taken as zero by the STIC.

Holy hell - that was the problem!!  

Óscar - you are a prince among men!  It reminds me of an old story I've heard told:
 

The huge printing presses of a major Chicago newspaper began malfunctioning on the Saturday before Christmas, putting all the revenue for advertising that was to appear in the Sunday paper in jeopardy. None of the technicians could track down the problem. Finally, a frantic call was made to the retired printer who had worked with these presses for over 40 years. “We’ll pay anything; just come in and fix them,” he was told.

When he arrived, he walked around for a few minutes, surveying the presses; then he approached one of the control panels and opened it. He removed a dime from his pocket, turned a screw 1/4 of a turn, and said, “The presses will now work correctly.” After being profusely thanked, he was told to submit a bill for his work.
 

The bill arrived a few days later, for $10,000.00!

Not wanting to pay such a huge amount for so little work, the printer was told to please itemize his charges, with the hope that he would reduce the amount once he had to identify his services.
The revised bill arrived: $1.00 for turning the screw; $9,999.00 for knowing which screw to turn.

 

[Mik's Arcade]

I didn't understand a single thing anyone in here was talking about, but I love how Oscar just swooped in here with one sentence and solved it.

 

I love this community. You guys are so good at this stuff

 

[+wavemotion]

Just to put a bit of closure on this... I've released the fix for the graphical glitch in D1K and D2K (along with the fix for Q-Bert...) - this should be the last of the old BLISS core bugs finally put to rest. 

 

I spent an evening on the couch watching the ape climb the ladders glitch-free

Thanks again to @nanochess and the entire community here!