Coleco ADAM Emulation - Odd Graphical Glitches in Donkey Kong Super Game

[+llabnip]

Okay - some months back you guys were absolute rocks-stars in helping me figure out my Z80 / VDP issues with ColecoDS (a Colecovision emulator for the DS/DSi).

 

After getting nearly 100% compatibility on the original CV and SGM games, I've started to tackle the ADAM emulation.

 

I have support for the ADAM memory management (Port60 and Port20... and Port53 for SGM but not ADAM) for the upper/lower 32K memory regions.

I have support for DDP and DSK images. 

I have support for basic AdamNet handling (keyboard, device interfaces, etc).

 

And just about every ADAM game (that works with the base 64K of RAM) works fine... but one game that has problems is Donkey Kong Super Game. 

 

Doesn't matter if I load the .DDP or the .DSK (both known good from Adam Archive) - both behave the same. 

 

Below you can see Donkey Kong Jr Super Game (left) vs Donkey Kong Super Game (right).   The DK game has missing colors/graphics and other oddities on screen. Collision detection seems fine. Sprites seem mostly fine and the game plays generally okay... but it's clearly not right.

 

I thought it had something to do with my handling of swapping RAM in/out via the Adam memory ports (60/20) but my debugger didn't show anything unusual there.

 

I thought maybe it was related to DMA to memory for data transfer from the disk/tape device... but it seems to be similar to DK Jr. in this respect.

 

I'm now suspecting the VDP video mode... you can see the VDP mode is 0 for DK but 3 for DK Jr... and it switches as we go through the intro/game select screen. I'm wondering if because the emulation is reading the disk "too fast" that maybe some bit of code isn't happening right?

 

I'm only about 10 hours into debugging - but it's enough effort that I thought I'd reach out here and see if anyone had a spark of a clue to chase down.

 

As always, I appreciate any random thoughts anyone might have about this. You never know what clue uncovers the answer!

 

 

Edited March 9, 2022 by llabnip

[NIAD]

I would shoot Nanochess a PM if he doesn’t reply in this thread. He is the author of the CoolCV emulator and IIRC the ADAM DK-SG works properly. All around genius and nice guy!

[+llabnip]

Thanks @NIAD - I will reach out to @nanochess at some point... though I discovered bigger problems with the ADAM emulation.

 

I had thought most games were working fine... but in deeper testing that's not true. I'm finding some games seem to play fine - but eventually run into problems. For example, Dragon's Lair plays fine - I can get through the first 3 or 4 areas pretty well... and then when I finally die, it looks okay until I try something like pressing ZERO to get to the High Score list. Then it goes sideways... graphics get garbled and sometimes it resets. 

 

Donkey Kong Jr. plays perfectly through the first screen - as soon as it transitions to screen 2 (chains) the screen garbles. Also - dying on this chains screen freezes the game. 

 

So I think it's just Donkey Kong Super that is corrupt from the get-go... other games are having problems but only at certain points (and always the same points). 

 

Back to the drawing board! 

 

[+llabnip]

Getting closer... after a night of running various RAM Tests found on the Adam Archive... Eric Pearson's RAMTest 2.0 (2018) shows a RAM failure at address 65220 which is hex 0xFEC4

 

As I look at the ADAM Technical Reference Manual, this address is in the Device Control Block.

 

This is not a coincidence... hmmm....

 

[+llabnip]

I've had a fairly significant breakthrough.

 

The baseline code I started with is a fairly old version of ColEM which I've patched (mostly in the TMS9918 area).  Turns out that the most recent ColEM 5.6 build has all these same Adam glitches.  The code in this area for reading DDP and DSK seems to go all the way back 23 years to AdamEM by Marcel de Kogel.  The problem is that when we read from tape/disk, it's done all in one "instant" without the CPU getting any chance to continue running. It's as if immediately after the instruction to read the tape/disk, the buffer is ready.  I tried slowing it down - which didn't work... because I was still reading the tape/disk instantly and only reporting the status to the running program after some time. 

 

The key to fixing this was to not only wait to report the status (i.e. drive is no longer busy) - but to also buffer the read into a holding buffer that is not accessible to the program. Only when we finally decide to give the 'all clear' status response to the program do we copy the buffer into the CPU memory. 

 

I think what's happening is that clever programmers know that it takes time to read the tape/disk and so they probably kick off the next request mid-way through processing the first 1K chunk of data that was read in. In this way, they keep the pipe-line reasonably full and reduce total loading times.

 

With the "instant" read and report of status, the program did not have time to digest the first block - and so some of memory was getting corrupted. This caused the glitches in DK Super Game along with numerous other issues ranging from screen oddities to outright crashes.

 

I leave this post in the hopes that anyone searching desperately for some clues with ColEM Adam support (perhaps they ported it to other platforms) can find some help.

 

I've still got a few minor issues ... for some reason Adam Bomb II does't run quite right - I have to reset it many times (random patterns in RAM including the 64K expended RAM I added today) to get it to come up... once it starts running, it seems fine.  But the compatibility is starting to really rise here!


 

[NIAD]

It sounds like you are working your way through similar issues or learning experiences that Thomas Cherryhomes experienced in his bring-up of the FujiNet ADAM drivers and support software.

 

 

[Tekman]

As a beta tester of the ADE drive emulator, it was found that Adam Bomb II was extremely sensitive of having anything left in residual ADAM memory when it was run or it would have graphical glitches and often just fail with an error message that I can remember.  The workaround with the ADE Commander companion boot disk software was to do a memory wipe just before launching AB2 to get it to work correctly. But that is with a physical ADAM and not sure if that even relates to what is being done in an emulator.

[+llabnip]

Thanks Tek! Yeah for sure there is something picky about what AB2 wants to see in RAM at startup.  Strangely enough, if I wipe RAM to 0x00 it never starts. If I randomize RAM it starts about 25% of the time (and seems to run fine).