Tutankham: Incomplete Video

[NivagSwerdna]

I've been tinkering with my Konami Tutankham for a few weeks trying to understand the ins and outs of the Konami customs....

... and I've broken it.



The playfield no longer renders correctly... and interestingly the video now corrupts the top of the playfield. FWIW it is quite interesting as an insight into how the game works... the maze is loaded into video memory and then hardware scrolled as the player proceeds. The active sprites, character, beasts, bullets etc... are rendered on the fly into the video RAM.

Hopefully I haven't broken anything too important.

 

[NivagSwerdna]

Out with the logic probe.... going down the line of graphics ROMs.... C1...C12... (actually only 9 are populated)... these are actually in sockets I1..I9

Check pin 18.... C8 pin 18 is LO, all others HI.

Check 74LS154 decoder at H8.... p8 is LO (active), all other outputs LO... p23, p22, p21, p20 are HHHL... i.e. 7... p8 is Y7 so that is all correct.



Lifted ROM at C8 (aka I8)...


Read OK...Checksum 2F62F...

Verify against original...



So that appears correct.... Hm....

 

[NivagSwerdna]

I hadn't appreciated but there seems to be a reason for that socket at I12.... if you look in the code for accesses to bank select you find that on startup the $8300 bank select is set to 0B (i,e, 11)... which sets Y11 active LO, enabling the socket in I12 (aka C12)...


The code checks for a 55 at the first byte of the ROM... and if present it jumps to the second byte with a JSR

Is there a diagnostic ROM for Tutankham? I certainly don't know of one.

 

[NivagSwerdna]

I suspect the 74LS375 @ H9.... don't have any spare.... so ordered a couple....

 

[philmurr]

I hadn't appreciated but there seems to be a reason for that socket at I12.... if you look in the code for accesses to bank select you find that on startup the $8300 bank select is set to 0B (i,e, 11)... which sets Y11 active LO, enabling the socket in I12 (aka C12)...


The code checks for a 55 at the first byte of the ROM... and if present it jumps to the second byte with a JSR

Is there a diagnostic ROM for Tutankham? I certainly don't know of one.

I've never found an original test ROM fur Tut but it's quite a common thing in lots of Konami games, for example Amidar and Super Cobra do a similar check



This is from Super Cobra which checks $6000 which is part of ROM space (unused in the standard SC ROMset)

 

[NivagSwerdna]

Interesting. I wonder how they handle the watchdog reset that is normally done during the IRQ handler? Maybe they just disable interrupts and try and get to the watchdog within the WDT period?

 

[Mc-Q]

a 16line decoder permanently enabled to sequentially enable 4k eproms?
i would be SOOO tempted to pull all that out and fit a 27c512!

i often do that type of thing with small program roms on stuff, but never even thought about the gfx before!

 

[Mc-Q]

btw, your programmer software has serious bugs - upgrade to 12.66

Download Newest XGecu T56/T48/TL866II software(下载最新软件) - 编程器使用与软件下载 - XGecu Programmer Forums - Powered by Discuz!

XGecu Programmer Forums 点击查看：XGecu T48（TL866 三代极高性价比）XGecu T48(TL866-3G) programmer (TL866 3rd generation) 当前软件版本( XGecu T56/T48/TL866II Plus Softwar ... - Discuz! Board

forums.xgecu.com

 

[NivagSwerdna]

Updated Programmer s/w

Out with the old...




In with the new...



I didn't think it deserved a socket... and anyway... just adding sockets is another point of failure IMHO.

and..



We are back.

That was quite a subtle failure... just one bit of the bank decode failed (stuck low)... as the game renders you can see it switching banks alot... including bank 7 so it is quite hard to spot. e.g. It doesn't use one bank for Level 1, etc... it flits between them. Anyway... jobs a good un.

I'm quite tempted to have a go at a Diagnostic ROM... the fact that I've never done any 6809 assembly might be a challenge... but the IRQ looks hook-able...
The IRQ vector at FFF8 jumps to A006... then jumps on to CCD6... and then there is a bit of code..



If you bodged in a value of 5 into 0002 then that should go off to 96F1 which would be in your code. Obviously for that to work you need ROMS F, A and C to be good and 0002 to be good. But it's a way in. You could then copy some code to either video RAM or static RAM and jump to it, read the other ROMs but would need to page yourself back in when the next IRQ came around... sounds fun.
Might put learning 6809 Assembly on the things to do list.

 

[Mc-Q]

you may find the source of some other konami test roms.

Diagnostic ROM’s

Visit the post for more.

www.jammarcade.net

 

[NivagSwerdna]

I think this game is a bit different from most in that the graphics are rendered from the video RAM and no sprites are involved. So to get useful stuff on the screen you need to fill in the bits one at a time. I believe the colour depth is 4 bits so each byte of video RAM renders as two pixels.
The visible area which starts at 0800 which is the bottom left of the screen when viewed as the game is played... x087F being the top of the first column. The most significant nibble is painted last... i.e. the nibbles are swapped. The rightmost column starts at x7780 with the top right being x77FF.
Getting characters on the screen (for a diagnostic) is a bit of a pain as they need to be painted... but I've discovered that there is a table starting at 0xF000 which has sets of 32 bytes, one for each character. These can be used to paint the alphabet and some numbers. There is a helper function at D6EA which renders a character (Y points at video RAM, X at Char table)...

Should give this..


If there was ever a Juno First diagnostic that might give some insight.
The RAM at 0000-07FF and 7800-7FFF is probably fair game for any purpose.
PS
The RAM area 0000-07FF comes visible when scrolled by 0xF0 (i.e. shift -16?); The RAM area 7800-7FCF comes visible when scrolling to
0F i.e. +15. The RAM doesn't cover much either side of the visible screen so it must be being rebuilt as the scroll takes effect.

 

[Mc-Q]

a few years back i thought about making a sort-of universal test-rom software that would just test ram but instead of rendering anything would flash codes to an led or maybe drive a serial 2wire display.
never got round to doing it though.
i got the idea after having several glaxian boards giving error codes i couldnt see properly on the screen!

 

[NivagSwerdna]

So here we are 7 days later... taught myself some 6809 Assembly...

Tutankhm Diagnostic. Burn to a 2732 and load into what should be an empty but socketed C12 @ I12.


Share & Enjoy

v1.2 in later post.... look below....

 

[NivagSwerdna]

I should probably add some SFX... Although my board isn't actually connected to an amp and speaker...

I presume that is something like queuing a command to the sound board.... Any clues appreciated.

 

[NivagSwerdna]

I should probably add some SFX... Although my board isn't actually connected to an amp and speaker...

I presume that is something like queuing a command to the sound board.... Any clues appreciated.

Answer my own question...

Write sound number to x8700; Trigger with a 00 then a 01 to x8600; Mute must not be enabled... i.e.x 8205 should be 00

Must add that when I get time. x11, x13 and x14 are good noises

 

[Mc-Q]

does the testrom test inputs by displaying them onscreen?

 

[NivagSwerdna]

You'll need to try it to find out.... 😁
Yes. The four five bytes on the 4th Stage are the inputs.
TBH I haven't tested it but it should work and should refresh reasonably rapidly.

 

[Mc-Q]

another usefull feature would be to display the dipswitches,
no need to translate them, just the 8bit hex will do.
because i often see faulty dipswitches when i fix boards - specially the make with the different colours for each switch.
those are total junk.

 

[NivagSwerdna]

It already does that

 

[NivagSwerdna]

I apologise for my rather terse response! Stressed and busy!

On one of the pages it shows... "I" followed by 10 hex digits.... these represent the bytes... $8160, $8180, $81A0, $81C0 and $81E0 which should correspond to..

map(0x8160, 0x8160).mirror(0x000f).portr("DSW2"); /* DSW2 (inverted bits) */
map(0x8180, 0x8180).mirror(0x000f).portr("IN0"); /* IN0 I/O: Coin slots, service, 1P/2P buttons */
map(0x81a0, 0x81a0).mirror(0x000f).portr("IN1"); /* IN1: Player 1 I/O */
map(0x81c0, 0x81c0).mirror(0x000f).portr("IN2"); /* IN2: Player 2 I/O */
map(0x81e0, 0x81e0).mirror(0x000f).portr("DSW1"); /* DSW1 (inverted bits) */