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.
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
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
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.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.
Heh, I was going to say those bytes didn't look like actual code.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.
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
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.