3D Block (Hwang Shinwei)

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

NewRisingSun
Posts: 1215
Joined: Thu May 19, 2005 11:30 am

Re: 3D Block (Hwang Shinwei)

Post by NewRisingSun » Sat Aug 04, 2018 9:17 am

A very partial emulation that runs Block Force. Using the Square Force ROM from GoodNES, setting it to mapper #355 (and CHR-RAM to 8 KiB), and making sure that CPU->RAM Initialization is set to 00 in the emulator, should run the game. The initial high score (which is 006502 on the unprotected multicart-extracted version) is very sensitive to IRQ timing and therefore probably displayed incorrectly.

Right now, I am just firing an IRQ 13760 M2 cycles after any write to addresses 00D7 or 00E8. Emulating 3D Block will not be possible with such fakery and will definitely require dumping the microcontroller ROM, because that one will actually contain some gameplay code without which the blocks will never fall.

lidnariq
Posts: 9689
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: 3D Block (Hwang Shinwei)

Post by lidnariq » Sat Aug 04, 2018 10:41 am

What I personally find weird is that the PIC here is running directly off the same 1.8MHz clock that the CPU is, but the PIC has a ÷4 prescaler on the CPU, so it's actually running at ≈450KIpS.

The 12 I/O lines on the PIC are connected to CPUA[4...14] and /IRQ; so theoretically the PIC could choose to assert /IRQ based on that portion of the address, possibly requiring specific addresses in sequence. But it's not paying attention to the R/W line, so whatever's going on can't be related to direction.

This very old model of PIC doesn't have (internal) interrupts, and the only thing it could be doing is polling the address lines; to check for specific addresses will take 8 Tcy (32 6502 cycles) with some code that looks something like

Code: Select all

a:
movlw 0x55
xorwf PORTB, w
btfss STATUS, Z
goto a
movlw 0xA
xorwf PORTA, w
btfss STATUS, Z
goto a
although I'm certain there's a little more cleverness possible.

Due to using the same clock as the CPU, we know that the PIC can only check its inputs (the address bus) exactly every 4th cycle. But at the same time, there's nothing to keep the PIC synchronized, so I don't think there's reason to think that the code inside is only checking 6502 CPU cycles n where n≡1(mod 4)


I know I'd read some article in the past about defeating the code protect using a die photograph to find the location that the CP bit is and erase it...

Apparently the PIC16C54 follow-up PIC – the PIC16C84 – is vulnerable to a variety of relatively inexpensive deprotection attacks. https://www.cl.cam.ac.uk/~sps32/mcu_lock.html

There's also more invasive solutions: http://caps0ff.blogspot.com/2018/05/mos ... 16c57.html

krzysiobal
Posts: 757
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: 3D Block (Hwang Shinwei)

Post by krzysiobal » Wed Aug 22, 2018 3:05 am

I read the PIC's contents from MLX's cartridge:
Attachments
pic.png
pic.BIN
(1 KiB) Downloaded 312 times

NewRisingSun
Posts: 1215
Joined: Thu May 19, 2005 11:30 am

Re: 3D Block (Hwang Shinwei)

Post by NewRisingSun » Wed Aug 22, 2018 3:55 am

Cool! Was it not protected after all, or did you manage to disable/evade the protection?

krzysiobal
Posts: 757
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: 3D Block (Hwang Shinwei)

Post by krzysiobal » Wed Aug 22, 2018 3:58 am

I did not do anything.

NewRisingSun
Posts: 1215
Joined: Thu May 19, 2005 11:30 am

Re: 3D Block (Hwang Shinwei)

Post by NewRisingSun » Wed Aug 22, 2018 4:26 am

Data sheet wrote:In code protected parts, specifically PIC16C54/C54A/CR54/C55/C56/C57 devices, the contents of the program memory cannot be read out in a way that the program code can be reconstructed. A location when read out will read as: 0000 0000 xxxx where xxxx is the XOR of the three nibbles. For example, if the memory location contains 0xC04 (movlw 4), after code protection the output will be 0x008.
That seems to describe the data in PIC.BIN rather well, so it is protected after all, and the data you have read is not the actual data.

krzysiobal
Posts: 757
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: 3D Block (Hwang Shinwei)

Post by krzysiobal » Wed Aug 22, 2018 5:59 am

Ok, I will brute force the chip with logic values soon.

lidnariq
Posts: 9689
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: 3D Block (Hwang Shinwei)

Post by lidnariq » Wed Aug 22, 2018 9:32 am

NewRisingSun wrote:That seems to describe the data in PIC.BIN rather well, so it is protected after all, and the data you have read is not the actual data.
Heh, I was going to say those bytes didn't look like actual code.

It does let us see that there's only 151 words of code in it, at least.

edit: on the unlikely chance this is helpful, I'd made a table of the 12-bit PIC instruction set sorted by instruction encoding:

Code: Select all

00X-03X 000000dfffff movw*
    000 000000000000 nop
    002 000000000010 option
    003 000000000011 sleep
    004 000000000100 clrwdt
005-009 00000000ffff tris
010-017 000000010fff movlb
    01E 000000011110 return
    01F 000000011111 retfie
02X-03X 0000001fffff movwf
04X-07X 000001dfffff clr*
    040 000001000000 clrw
06X-07X 0000011fffff clrf
08X-0BX 000010dfffff subwf
0CX-0FX 000011dfffff decf
10X-13X 000100dfffff iorwf
14X-17X 000101dfffff andwf
18X-1BX 000110dfffff Xorwf
1CX-1FX 000111dfffff addwf
20X-23X 001000dfffff movf
24X-27X 001001dfffff comf
28X-2BX 001010dfffff incf
2CX-2FX 001011dfffff decfsz
30X-33X 001100dfffff rrf
34X-37X 001101dfffff rlf
38X-3BX 001110dfffff swapf
3CX-3FX 001111dfffff incfsz
    4XX 0100bbbfffff bcf
    5xx 0101bbbfffff bsf
    6xx 0110bbbfffff btfsc
    7xx 0111bbbfffff btfss
    8xx 1000xxxxxxxx retlw
    9xx 1001xxxxxxxx call
Axx-Bxx 101xxxxxxxxx goto
    Cxx 1100xxxxxxxx movlw
    Dxx 1101xxxxxxxx iorlw
    Exx 1110xxxxxxxx andlw
    Fxx 1111xxxxxxxx xorlw
[/size]

MLX
Posts: 110
Joined: Tue Feb 14, 2017 9:50 am

Re: 3D Block (Hwang Shinwei)

Post by MLX » Thu Aug 23, 2018 7:43 am

Out of curiosity, would the mentionned version of 3D-Block (CRC 5E8764F8) work on this PCB (did they leave compatibily code in the PIC?).

NewRisingSun
Posts: 1215
Joined: Thu May 19, 2005 11:30 am

Re: 3D Block (Hwang Shinwei)

Post by NewRisingSun » Thu Aug 23, 2018 11:14 am

That is unknown at this time. Since both games' PRG-ROMs are already dumped however, one could reprogram the EPROM on the Block Force PCB with 3D Block's PRG-ROM data and see if it works --- if it doesn't, one can always reprogram it with the original Block Force PRG-ROM data.

lidnariq
Posts: 9689
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: 3D Block (Hwang Shinwei)

Post by lidnariq » Fri Aug 24, 2018 10:50 pm

I found a trivial way to get the contents of a 16C54 out: http://www.piclist.com/techref/microchip/crackpic.htm

In short, you can read the XORed ROM contents, re-program the ROM with all FF0h, read the XORed ROM contents, re-program the ROM with all F00h, read the ROM contents, and then combine the three dumps together.

It does require a some extra effort to program an already-programmed PIC.

NewRisingSun
Posts: 1215
Joined: Thu May 19, 2005 11:30 am

Re: 3D Block (Hwang Shinwei)

Post by NewRisingSun » Fri Aug 24, 2018 11:48 pm

Not to mention that if something goes wrong, the PIC data will likely be lost, so the original cartridge owner should consent to the attempt first.

MLX
Posts: 110
Joined: Tue Feb 14, 2017 9:50 am

Re: 3D Block (Hwang Shinwei)

Post by MLX » Sat Aug 25, 2018 1:57 am

If that's the only way to go, I'd like the person to try their hands with another 16C54, serving as a guinea pig.

I'm not interested in digging for years to find another copy.

NewRisingSun
Posts: 1215
Joined: Thu May 19, 2005 11:30 am

Re: 3D Block (Hwang Shinwei)

Post by NewRisingSun » Sat Aug 25, 2018 2:24 am

Seems like a good approach.

MLX
Posts: 110
Joined: Tue Feb 14, 2017 9:50 am

Re: 3D Block (Hwang Shinwei)

Post by MLX » Sat Aug 25, 2018 4:05 am

(I do prefer that one attempt of feeding it with addresses and see how it reacts is done before going that way too).

Post Reply