It is currently Sat Aug 18, 2018 7:11 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 17 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sat Aug 04, 2018 9:17 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 617
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.


Top
 Profile  
 
PostPosted: Sat Aug 04, 2018 10:41 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7392
Location: Seattle
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:
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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group