Hunchback with video issues : Playpack on L-1200-1

[NivagSwerdna]

I'm a bit fed up with reverse engineering Konami customs that I probably will never use or sell so time for a challenge to take my mind off it...

This is the original board (original to me) from my first ever cocktail purchase (Hunchback in a Cocktail)... I turned it on a few months back and it had video issues so got forgotten about... it seems I have some spare time... so....

Ladies and Gentlemen... look what we have here...


First job is to see if the pinout is compatible with my existing Konami adapter....

 

[NivagSwerdna]

Bottom PCB...


Looks like A1 has a magic black box. ROMs swapped.... and looks like a colour PROM swap; otherwise no obvious mods.

A1 would be a Z80 in an original scramble. 2C-2P are system ROM... all 2716s... 5H, 5F are graphic ROM... also 2716s....

6E is the colour PROM (replaced by something labelled H15)... this is a 6331-1 PROM 32x8 Bipolar yester-year job.

 

[philmurr]

L-1200 is a standard Konami Scramble pcb, even has the Konami Scramble K103 protection chip on the sound board.

Konami classic pinout with Century playpack black box

 

[Macro]

Century playback is an s2650 CPU.and a bit of logic to handle the mapping changed. S2650 can only access 32k as 4 8k pages. So rom is usually done as first 4k of each page, with ram and io common in all pages

 

[NivagSwerdna]

That's interesting. I have never heard of these before.... so 6J seems to have 4 bits IN and 4 bits out... and is sent sequences (when Scramble present) e.g. x3 x1 x9 and produces an output 4x where the answer is the earlier value +1... fascinating. I assume that the high nibble is an output so that Custom IC 2 does some sort of logic and then feeds that into the other PIA at 1E. Fascinating!

 

[philmurr]

View attachment 5015
That's interesting. I have never heard of these before.... so 6J seems to have 4 bits IN and 4 bits out... and is sent sequences (when Scramble present) e.g. x3 x1 x9 and produces an output 4x where the answer is the earlier value +1... fascinating. I assume that the high nibble is an output so that Custom IC 2 does some sort of logic and then feeds that into the other PIA at 1E. Fascinating!

You are correct with the first part of your description, although Scramble protection is fairly easy to bypass in software. It's been 5 or 6 years since I looked, but from memory, IC2 isn't used.

Also the Stern version of Scramble uses a different protection chip with different equations.

 

[NivagSwerdna]

I'm trying so hard not to get distracted but I just love these custom ICs... Tickling in my chip tester suggests that pin 12 is a '9' detector, and pin 19 is a 0, 2, 8, 10 detector... Given it has no clock the clock must derived from the bit pattern and the '9' detector seems to match that the operation is performed on the value 9... I really need to prioritise my time.

 

[vsl]

Hi,
can I ask you for high resolution pictures of pcb ..elements side.. and the ...solder side... of the Z80 CPU area. If you can dump the eproms and share them I will be very grateful.
Greetings!

 

[NivagSwerdna]

OK... time to concentrate... Applied 5V (I think the -5V and +12V are only required for the audio section, pre-amp and amp respectively)...




Gave everything a bit of a wobble to ensure everything nicely seated....

Well that was boring! The colours don't look great... will investigate the Colour PROM in due course...


Character rendering looks pretty reasonable.
I do notice that there seems to be a slight glitch when in attract mode... doesn't seem to show the title screen for more than a flicker...

 

[NivagSwerdna]

Decided to read the ROMs for the LOLs...

6bd8a8a26ea3eef33c97de2f09d443a1617b1dfd *HB1.bin
9f333509ae3d6c579f6d96caa172a0abe9eefb30 *HB2.bin
c60c833f28c6de027d46f5a2a54ad5646ec58453 *HB3.bin
cfa1ac322cdfe1d4d112b0a4dd85d3552a6e33d0 *HB4.bin
aebfca355d937825217d069689f9b4d7a113b10a *HB5.bin
7854e4975a4f75916f60749ac24147c335927394 *HB6.bin
90da1e375733873bc592e11980bdaf8168bd5aea *HB7.bin
e6333e53570fb05a841a7f141872c8bd14143f9c *HB8.bin

Comparing to MAME...

ROM_START( hunchbks )
    ROM_REGION( 0x8000, "maincpu", 0 )
    ROM_LOAD( "2c_hb01.bin",  0x0000, 0x0800, CRC(8bebd834) SHA1(08f2ce732d2d8754bf559260e1f656a33e2a06a5) )  DIFF  @0670 17 not 0D
    ROM_LOAD( "2e_hb02.bin",  0x0800, 0x0800, CRC(07de4229) SHA1(9f333509ae3d6c579f6d96caa172a0abe9eefb30) )  OK   
    ROM_LOAD( "2f_hb03.bin",  0x2000, 0x0800, CRC(b75a0dfc) SHA1(c60c833f28c6de027d46f5a2a54ad5646ec58453) )  OK
    ROM_LOAD( "2h_hb04.bin",  0x2800, 0x0800, CRC(f3206264) SHA1(36a614db3fda4f97cc085d84bd13ea44969de95b) )  DIFF  @0050, @0061-0066
    ROM_LOAD( "2j_hb05.bin",  0x4000, 0x0800, CRC(1bb78728) SHA1(aebfca355d937825217d069689f9b4d7a113b10a) )  OK
    ROM_LOAD( "2l_hb06.bin",  0x4800, 0x0800, CRC(f25ed680) SHA1(7854e4975a4f75916f60749ac24147c335927394) )  OK
    ROM_LOAD( "2m_hb07.bin",  0x6000, 0x0800, CRC(c72e0e17) SHA1(90da1e375733873bc592e11980bdaf8168bd5aea) )  OK
    ROM_LOAD( "2p_hb08.bin",  0x6800, 0x0800, CRC(412087b0) SHA1(4d6f343577ae73031f32cda8903c74e5a840e71d) )  DIFF all FFs!
...
ROM_END

So ROM 2, 3, 5, 6, 7 match but ROM 1 has a one byte difference, ROM 4 differs by 7 bytes and my ROM 8 reads as all FFs... perhaps I have a bit of bit rot?

 

[NivagSwerdna]

I looked at MAME... using hunchbks and the title screen behaviour is very different so I think I may as well burn the dodgy ROMs and just for the LOLs do the complete set. I would be interested to know if people think 'refreshing' ROMs is a good idea or just a waste of time...



Typical... my eraser only has space for 7 so this has to be two passes of 4.... the one that read all FFs is marked with the dot.... maybe that's a dud anyway...

PS
@vsl The images match that in hunchbks.zip (You can find that on various sites... just google it).

 

[NivagSwerdna]

OK... so the main ROMs are erased and re-flashed...

I downloaded the GFX1 and SFX ROM and their checksums match so I will leave those well alone...

Downloaded the 6331 PROM at 6E...

0000 : 00 c7 17 f6 00 c0 17 3f 00 c0 07 3f 00 c4 c0 07 00 31 17 17 00 17 31 3f 00 07 f6 f0 00 07 3f c4

CRC32: cbff6762
SHA1 Hash: 4515a6e12a0a5c485a55291feee17a571120a549

Now this is really strange... so the SHA1 sum of this file is 4515a6e12a0a5c485a55291feee17a571120a549 but it should be
e53cbc54ea96e846481a67bbcccf6b1726e70f9c.

The MAME definition has...

ROM_START( hunchbks )
...
    ROM_REGION( 0x10000, "audiocpu", 0 )
    ROM_LOAD( "11d_snd.bin",  0x0000, 0x0800, CRC(88226086) SHA1(fe2da172313063e5b056fc8c8d8b2a5c64db5179) )

    ROM_REGION( 0x1000, "gfx1", 0 )
    ROM_LOAD( "4515a6e12a0a5c485a55291feee17a571120a549.bin",  0x0000, 0x0800, CRC(db489c3d) SHA1(df08607ad07222c1c1c4b3589b50b785bdeefbf2) )
    ROM_LOAD( "5h_hb10.bin",  0x0800, 0x0800, CRC(3977650e) SHA1(1de05d6ceed3f2ed0925caa8235b63a93f03f61e) )

    ROM_REGION( 0x0020, "proms", 0 )
    ROM_LOAD( "6e_prom.bin",  0x0000, 0x0020, CRC(01004d3f) SHA1(e53cbc54ea96e846481a67bbcccf6b1726e70f9c) )
ROM_END

Something odd there... in the gfx1 section I see this sha1sum!

 

[NivagSwerdna]

So my colour PROM seems to match hunchbkg.... I wonder if that was a mistake in the conversion?

 

[NivagSwerdna]

Weird it doesn't show the title screen, or does for a nanosecond and then clears... I guess that suggests a hardware fault somewhere?

 

[NivagSwerdna]

Some photos for the record...


back...

and the board...

I guess I need to do some investigations into why it is behaving slightly strangely with the title screen...

 

[NivagSwerdna]

Installed the Retro Processor Electron Wrangler (my poor man's Fluke) into the Z80 socket...



And read the ROMs...

S: 0000=08F2CE732D2D8754BF559260E1F656A33E2A06A5 2c_hb01
S: 0800=9F333509AE3D6C579F6D96CAA172A0ABE9EEFB30 2e_hb02
S: 1000=C60C833F28C6DE027D46F5A2A54AD5646EC58453 2f_hb03
S: 1800=36A614DB3FDA4F97CC085D84BD13EA44969DE95B 2h_hb04
S: 2000=AEBFCA355D937825217D069689F9B4D7A113B10A 2j_hb05
S: 2800=7854E4975A4F75916F60749AC24147C335927394 2l_hb06
S: 3000=90DA1E375733873BC592E11980BDAF8168BD5AEA 2m_hb07
S: 3800=4D6F343577AE73031F32CDA8903C74E5A840E71D 2p_hb08

all good. SHA1 sums match what is expected.
And tested System RAM...

m: 4000=OK

All good. The last test is equivalent to Memory Short so a reasonably robust test.
So I am slightly stumped as to why it doesn't dwell on the title screen... I looked briefly at the S2650 spec http://datasheets.chipdb.org/Signetics/2650/2650UM.pdf and it looks quite tricky (in fact it looks like an IBM mainframe designer got a look in) so I'm not sure how much progress I will make debugging the title screen transition. Maybe it's just the test harness.... some button that is floating that is being detected?

 

[NivagSwerdna]

When on the title screen it does do some input reading....



Otherwise it is just going about its business... assuming system RAM and ROM are good and assuming CPU is OK then the only thing that seems to be changing would be the inputs...

Measured system clock just to be sure...

Measure CPU Frequency phi
f: 002ED040 00000000
3.067968 MHz, expected 3.07 Mhz

... seems bang on.

I don't know if this game had any protection and that is missing since Scramble protection is in place?

PS

map(0x1500, 0x1503).rw(m_ppi8255_0, FUNC(i8255_device::read), FUNC(i8255_device::write));

0x1500 is the remapped i8255 which would have been at 0x8100 in a Scramble...

map(0x8100, 0x8103).rw(m_ppi8255_0, FUNC(i8255_device::read), FUNC(i8255_device::write));

 

[NivagSwerdna]

Reading my inputs gives....

R: 8100=BF
R: 8101=FC
R: 8102=DF

R: 8100=BF
R: 8101=FC
R: 8102=DF
...

 

[NivagSwerdna]

So following the logic through... Reading 8100 should give the PA register for the i8255 PIA at 1E... And MAME is reading FF and I am reading BF so it looks like bit 6 is clear when it should be pulled high when COIN2 is not active...



The plot thickens...

PS
If you run MAME and hold down the 6 key (COIN2) it behaves as I am seeing... definitely onto something here!

 

[Macro]

Sounds like you have found the problem.