summaryrefslogtreecommitdiffstatshomepage
diff options
context:
space:
mode:
author Roberto Fresca <robertof@mamedev.org>2014-02-05 22:22:29 +0000
committer Roberto Fresca <robertof@mamedev.org>2014-02-05 22:22:29 +0000
commit2a290bccf60f63b78247f66f5709f2fe4b9b296e (patch)
tree3df515a4fdb43c95ab09c676a8eb13b11a425eec
parente3b5f3c6f703e1e6ecb964f0e44aff5d3046fafc (diff)
Improvements to Unknown Royal Card on Dino4 hardware: [Roberto Fresca]
- Fully decrypted the graphics set. - Added technical notes...
-rw-r--r--src/mame/drivers/funworld.c54
1 files changed, 53 insertions, 1 deletions
diff --git a/src/mame/drivers/funworld.c b/src/mame/drivers/funworld.c
index cff9bc37939..52cd70343a5 100644
--- a/src/mame/drivers/funworld.c
+++ b/src/mame/drivers/funworld.c
@@ -140,8 +140,10 @@
B) General encryption. Managed through hardware:
- All games using the blue TAB PCB with 2x HY18CV85 (electrically-erasable PLDs), use
- complex operations for each byte nibble. See DRIVER_INIT for the final algorithm.
+ complex operations for each byte nibble. See DRIVER_INIT for the final algorithm.
- Saloon (french) use bitswaps to address & data in program, graphics and color PROM.
+ - Dino4 hardware games have address/data bitswap in program, data bitswap (sometimes
+ with extra boolean XOR operations)
- Microcontroller. Some games are using an extra microcontroller mainly for protection.
@@ -386,7 +388,51 @@
Press DEAL/DRAW to exit the mode.
+
+ * Unknown Royal Card on Dino4 hardware....
+
+ This one is really strange. The game is running in a Dino4 hardware, plus a daughterboard
+ with a mexican Rockwell R65C02 + an unknown PLCC. The program/gfx are totally decrypted.
+ The game vectors are $C122 (RESET) and $C20F (IRQ)
+
+ The code starts...
+
+ C122: A2 FF LDX #$FF ; load 0xFF to reg X
+ C124: 9A TXS ; transfer to the stack
+ C125: 78 SEI ; set interrupts
+ C126: D8 CLD ; clear decimal
+ C127: 18 CLC ; clear carry
+ C128: A9 4C LDA #$4C ;\
+ C12A: 8D 00 00 STA $0000 ; \
+ C12D: A9 10 LDA #$10 ; \ set 4C 10 C2 (JMP $C210) into $0000
+ C12F: 8D 01 00 STA $0001 ; /
+ C132: A9 C2 LDA #$C2 ; /
+ C134: 8D 02 00 STA $0002 ;/
+ C137: 4C DC 48 JMP $48DC ; jump to $48DC...
+
+ 48DC: 93 NOP ;\
+ 48DD: 00 BRK ; \
+ 48DE: B7 4B SMB3 $4B ; \
+ 48E0: 05 93 ORA $93 ; > nothing has sense here...
+ 48E2: 00 BRK ; /
+ 48E3: B7 4D SMB3 $4B ; /
+ 48E5: 05 B7 ORA $B7 ;/
+ 48E7: 4C 05 76 JMP $7605 ; jump to $7605 (no code there)
+
+ The board was later tested with a fluke, and the code dumped from the real hardware,
+ match 100% the one I decrypted here. Even with the game working properly in the real
+ hardware. The only visible changes are in the NVRAM, where the $0000 offset hasn't
+ the JMP $C210 instruction injected at the start...
+
+ Maybe some scrambled instructions on the fatidic 'mexican' Rockwell R65C02 (like Magic Card II)??...
+ Maybe mnemonic 93 is AXA (ab),Y (93 ab) instead of NOP (as some sources said)??...
+ Tooo much obscure / darkness here
+
+ So... No idea what's wrong here.
+ If someone could figure a possible transform, please let me know.
+
+
***********************************************************************************
@@ -843,6 +889,10 @@
range where there's no valid code.
- Decoded and partially decrypted the graphics set.
+ [2014/02/05]
+ - Rcdino4: Fully decrypted the graphics set.
+ - Added technical notes...
+
*** TO DO ***
@@ -5442,12 +5492,14 @@ DRIVER_INIT_MEMBER(funworld_state, rcdino4)
auto_free(machine(), buffer);
+ /* d4-d5 data lines swap, plus a XOR with 0x81, implemented in two steps for an easy view */
int x;
UINT8 *src = memregion( "gfx1" )->base();
for (x = 0x0000; x < 0x10000; x++)
{
+ src[x] = BITSWAP8(src[x], 7, 6, 4, 5, 3, 2, 1, 0);
src[x] = src[x] ^ 0x81;
}