Page 2 of 3

Posted: Wed Jul 18, 2012 8:33 pm
by DeV78
Chilly Willy wrote:
slobu wrote:Sorry, a bit of humor. I was saying that the only way to get graphics that good was a human sacrifice.
Little bit of Venture Bros there - the JoyBox is powered by an orphan's heart. :lol:

Son, it's time we had a talk about men and women. You see only women have what's called a joybox...

This is what he's talking about :

Best show ever, next to sifl n olly :D

Ok, so, the game isn't a hoax as far as I know. Several people I know have played the exact game shown here :

If necessary I can upload some video of the game when it arrives for proof. If for any reason its not authentic and another one of the many SMW hacks I'll let you know.

I know there was a guy who guys by Azathoth (or still does) who tried to dump this using the Sega CD cable. From what I heard he didn't get but so far and stopped posting about it. Supposedly he's on some other forums I lurk so I'll find him eventually I guess.

I think I may lack some of the tools necessary to give this a true attempt. If you or anyone you know is apt to give this a shot and from Australia (where my buddy with the game is) I can try to organize a meet up.

Posted: Thu Jul 19, 2012 1:09 am
by Chilly Willy
Sorry, got that wrong... it was the Joy Can that was powered by an orphan heart. That's a great show, can't wait for the next season. :D

Posted: Thu Jul 19, 2012 11:36 pm
by TmEE co.(TM)
notaz wrote:Where did you find one of those, local markets perhaps? If so, I could try to get one locally, would be interesting to investigate it (I have made myself a cable and ext port RAM device).
I got to borrow it from a friend. I suggested him to track down a "non original" copy as I am sure pirates have managed to get rid of all protections in the game so its just bare ROM.
It has been a while since I saw some MD game here locally but I have not looked really either.

Posted: Sun Aug 12, 2012 4:45 am
by andlabs
Late but I should put in my two cents anyway (I posted the huge quote below on another forum a few days before the last post here was made); I did this on the forums for the bootleggameswiki already. Someone stuck this particular game in a Retrode and gave Sik and I a dump to analyze. We determined that the dump was incomplete as it lacked the level art, level layouts and Z80 sound driver, however I think I understand where they should be in the ROM (there's a huge space in the middle that alternates between 0s and $FFs every 32KB or so I don't remember exactly as well as a few other similar holes later on), however the full engine code, palettes, title screen/ending graphics, music data, etc. are there.
The custom hardware is mapped to the $6xxxxx region.
The custom hardware either does mirroring, mirroring/decryption, or access from a separate ROM. There's some large holes in the Retrode dump filled with either $00s or $FFs (alternating every 8KB); it may be this. These store GEMS (seriously), the level tiles, the level tilemaps, and the level layouts (the last three of which are all loaded from VRAM).
In addition, the hardware provides some registers. Three of these registers are used to calculate the sizes of tilemaps, specifically
(byte read from $660001) = (byte written to $600003) ^ f(byte written to $640001, 1)
where ^ is xor and f() is either shift byte left or rotate byte left (we're not sure which) and that this possibly only holds true if byte $DE is written to byte $670001.

The game steals the Sega standard init code so it does follow TMSS even though the cart hardware seems to bypass it. There's also this initailization function:

Code: Select all

ROM:00000436 ; =============== S U B R O U T I N E =======================================
ROM:00000436 sub_436:                                ; CODE XREF: ROM:00000326p
ROM:00000436                 move.w  #9,d0
ROM:0000043A loc_43A:                                ; CODE XREF: sub_436+Cj
ROM:0000043A                 move.b  #0,($600001).l
ROM:00000442                 dbf     d0,loc_43A
ROM:00000446                 move.b  #$80,($610003).l
ROM:0000044E                 nop
ROM:00000450                 move.b  #$DE,($670001).l
ROM:00000458                 move.b  #0,($660001).l
ROM:00000460                 move.b  #0,($600001).l
ROM:00000468                 move.b  #$38,($600003).l ; '8'
ROM:00000470                 move.b  #$A5,($640001).l
ROM:00000478                 move.b  ($670001).l,d0
ROM:0000047E                 move.b  ($660001).l,d1
ROM:00000484                 move.b  ($660003).l,d2
ROM:0000048A                 nop
ROM:0000048C                 move.b  #1,($600001).l
ROM:00000494                 move.b  #$55,($600003).l ; 'U'
ROM:0000049C                 move.b  ($660005).l,d0
ROM:000004A2                 move.b  ($660007).l,d1
ROM:000004A8                 nop
ROM:000004AA                 move.b  #$E0,($670001).l
ROM:000004B2                 move.b  #0,($660001).l
ROM:000004BA                 move.b  ($640003).l,d0
ROM:000004C0                 andi.b  #$C0,d0
ROM:000004C4                 ori.b   #$55,d0 ; 'U'
ROM:000004C8                 move.b  d0,($640003).l
ROM:000004CE                 move.b  ($670001).l,d2
ROM:000004D4                 move.b  ($660009).l,d0
ROM:000004DA                 move.b  ($66000B).l,d1
ROM:000004E0                 move.b  ($66000D).l,d2
ROM:000004E6                 move.b  ($66000F).l,d3
ROM:000004EC                 nop
ROM:000004EE                 rts
ROM:000004EE ; End of function sub_436
and an example of the mirroring/decryption(?), to get to the Z80 sound driver, which is GEMS:

Code: Select all

ROM:00008326 ; =============== S U B R O U T I N E =======================================
ROM:00008326 sub_8326:                               ; CODE XREF: LoadGEMS+20p
ROM:00008326                 move.w  #$100,($A11100).l
ROM:0000832E                 move.w  #$100,($A11200).l
ROM:00008336 loc_8336:                               ; CODE XREF: sub_8326+1Cj
ROM:00008336                 move.b  (a0)+,d1
ROM:00008338 loc_8338:                               ; CODE XREF: sub_8326+16j
ROM:00008338                 move.b  d1,(a1)
ROM:0000833A                 cmp.b   (a1),d1
ROM:0000833C                 bne.s   loc_8338
ROM:0000833E                 addq.w  #1,a1
ROM:00008340                 subq.w  #1,d0
ROM:00008342                 bne.s   loc_8336
ROM:00008344                 rts
ROM:00008344 ; End of function sub_8326
ROM:00008346 ; =============== S U B R O U T I N E =======================================
ROM:00008346 sub_8346:                               ; CODE XREF: LoadGEMS+24p
ROM:00008346                 move.w  #0,($A11200).l
ROM:0000834E                 move.w  #0,($A11100).l
ROM:00008356                 move.w  #$100,($A11200).l
ROM:0000835E                 rts
ROM:0000835E ; End of function sub_8346
ROM:00008360 ; =============== S U B R O U T I N E =======================================
ROM:00008360 LoadGEMS:                               ; CODE XREF: sub_38E+8Cp
ROM:00008360                 move.b  #7,($600001).l
ROM:00008368                 move.b  #$D3,($600003).l
ROM:00008370                 movea.l #$614DBC,a0
ROM:00008376                 lea     ($A00000).l,a1
ROM:0000837C                 move.w  #$2000,d0
ROM:00008380                 bsr.w   sub_8326
ROM:00008384                 bsr.w   sub_8346
ROM:00008388                 rts
ROM:00008388 ; End of function LoadGEMS
The title theme and first stage theme don't use GEMS but rather a custom sound playback system that runs off VInt; everything else does (there are three tracks for this custom playback system but I'm mostly certain the third one just silences playback)
In addition the Retrode dump shows us that the game is 512KB, with the 512KB being mirrored once (unless the game is splitting the masked data betwene the two halves, but I find that unlikely), then everything from the 1MB point to the 4MB point is just $FF bytes.

There was also this suggestion from LocalH
Might I suggest aping Chris Covell's NES dumping method, writing a ROM that would load some basic tiles into VRAM for on-screen display, loading the actual dumping code into RAM, spinning on a pad-polling loop in RAM, cart-swapping, then press Start (or whatever) and have the RAM code dump the ROM using what information is known about the mapping hardware, either sending it through the SCD transfer cable or sending it through the audio output via KCS (both slow methods but reliable).
I think someone countered it elsewhere but I don't remember.

Posted: Tue Oct 30, 2012 7:05 pm
by Eke
ok, someone sent me his cartridge so i could mess with it and i have been able to have the cartridge extra hardware reverse-engineered (maybe not 100% completely but still more than needed to emulate the protection !)


i have been using a SGC explorer, which is a very nice teensy-based MD cartridge board interface build by Bruno Freitas, who was kind enough to offer me one a few month ago :D

the cool thing with this board is that it can manage all necessary signals of the cartridge connector and you can reproduce the same access as the game is doing

after MANY hours of register poking, investigations and guess work, here is a summary of my notes
Memory Map (cartrige area)
$000000-$07ffff: lower 512KB ROM
$080000-$0fffff: mirror of $000000-$07ffff (VA19 not connected)
$100000-$5fffff: not mapped
$600000-$67ffff: internal hardware (see below)
$680000-$6fffff: mirror of $600000-$67ffff (VA19 not connected)
$700000-$7fffff: not mapped

Internal Hardware

$600000-$60ffff: upper 512KB ROM selected bank (8 x 64K banks)
$610000-$61ffff: upper 512KB ROM selected bank (8 x 64K banks)
$620000-$62ffff: return alternate 4K chunks of $ff and $00 (fixed to last ROM bank ?)
$630000-$63ffff: mirror of $620000-$62ffff
$640000: not mapped
$640001: always return $00
$640002-$65ffff: mirror of $640000-$640001
$660000: not mapped
$660001: DATA1 register, see notes below
$660002: not mapped
$660003: DATA1 register + 1
$660004: not mapped
$660005: DATA2 register, see notes below
$660006: not mapped
$660007: DATA2 register + 1
$660008: not mapped
$660009: DATA3 register, see notes below
$66000a: not mapped
$66000b: DATA3 register + 1
$66000c: not mapped
$66000d: DATA3 register + 2
$66000e: not mapped
$66000f: DATA3 register + 3
$660010-$66ffff: mirror of $660000-$66000f
$670000: not mapped
$670001: see notes below (1)
$670002: not mapped
$670003: return same value as $670001 anded with 0x7f
$670004-$67ffff: mirror of $670000-$670003

$600000: n.a (!UWR not connected)
$600001: CTRL1 register (see below)
$600002: n.a (!UWR not connected)
$600003: DATA4 register, see notes below (2)
$600004-$60ffff: mirror of $600000-$600003
$610000: n.a (!UWR not connected)
$610001: n.a ?
$610002: not mapped (!UWR not connected)
$610003: CTRL2 register (see below)
$610004-$61ffff: mirror of $610000-$610003
$620000-$63ffff: n.a ?
$640000: n.a (!UWR not connected)
$640001: DATA5 register
$640002: n.a (!UWR not connected)
$640003: DATA6 register
$640004-$64ffff: mirror of $640000-$640003
$650000-$65ffff: n.a ?
$660000: n.a (!UWR not connected)
$660001: ??? (usually set to $00 after writing to $670001, sometimes set to the same value as $670001 ?)
$660002-$66ffff: n.a ?
$670000: n.a (!UWR not connected)
$670001: CTRL3 register (see below)
$670002: n.a (!UWR not connected)
$670003: n.a ?
$670004-$67ffff: mirror of $670000-$670003

CTRL1 register ($600001):
D7-D3: n.a ?
D2-D0: DATA4 write mode, see notes below (2)

CTRL2 register ($610003):
D7: enable (resp. disable) $600000-$6fffff ROM bank-switching & $670001-$670003 output when set (resp. cleared)
D6-D0: n.a ?

CTRL3 register ($670001):
D7: enable (resp. disable) DATA1/DATA3 registers update on $670001 reads when set (resp. cleared)
D6: select $670001 output mode, see notes below (1)
D5: select DATA register being updated on $670001 reads when bit7 is set (0: DATA1, 1: DATA3)
D4-D2: select upper 512K ROM bank (8x64K banks) mapped to $600000-$60ffff when CTRL2 bit7 is set
D1-D0: n.a ?

(1) reading $670001 returns:
- $00 if CTRL2 bit7 is cleared
- DATA5 & DATA6 if CTRL2 bit7 is set and CTRL3 bit6 is set
- DATA5 ^ 0xFF if CTRL2 bit7 is set and CTRL3 bit6 is cleared

when CTRL3 bit7 is set, reading $670001 updates the value in:
- DATA1 if CTRL3 bit5 is cleared: DATA1 = ((DATA5 << 1) ^ DATA4) & 0xfe
- DATA3 if CTRL3 bit5 is set: DATA3 = (DATA6 << 2) & 0xfc

(2) writing $600003 updates:
- DATA4 register: DATA4 = data
- DATA1 register if write mode (CTRL1 bits 0-2) is set to $0: DATA1 = ((DATA5 << 1) ^ data) & 0xfe
- DATA2 register if write mode (CTRL1 bits 0-2) is set to $1: DATA2 = data & 0xfe
- upper 512K ROM bank (8x64K banks, using D2-D4) mapped to $610000-$61ffff if write mode (CTRL1 bits 0-2) is set to $7
- no effect (?) if write mode is set to $2,$3,$4,$5,$6 (game sometimes sets write mode to $6 and writes $00 or $01 to $600003)

(3) random quirks:
- writing DATA5 or DATA6 registers does NOT immediately change the value returned in DATA1 or DATA3 when proper CTRL3 bits are set, the change is only effective after reading $670001
- similarely, when mode=$0, any writes to DATA4 register immediately change the value returned in DATA1 but calculation will not use the last value written in DATA5 unless $670001 was read in between
- setting CTRL3 bit7 seems to immediately update the value returned in DATA1/DATA3 if DATA4/DATA5 was changed but switching CTRL3 bit5 will not take effect until next write to DATA4/DATA5 followed by $670001 read
- internal registers might be non-volatile, previous state seems to be restored on power-on
As you can see, it seems the ROM is actually 1MB but i noticed similar 4 kB (or so) chunks of $ff and $00 in the various 64k bank that can be accessed through $600000-$60ffff and $610000-$61ffff as in the lower 512KB, so i suspect the initial ROM was initially 512kB then expanded to 1MB by copying out some chunks of data to upper 512kB. Also notice how VA19 is disconnected on the cartridge port, to ensure the upper area can not be directly accessed.


There is no public ROM available as i promised it to the cartridge owner and it' s up to him to decide when he wants to release it (I think he wants to get it fixed first). Indeed, it doesn't work with any existing emulator (except genesis plus gx) anyway and would probably be kind of hard (but not impossible I guess) to patch copy protection and bank-switching. All the infos are there though...

Posted: Tue Oct 30, 2012 7:13 pm
by TmEE co.(TM)
Naiss info !

Posted: Wed Oct 31, 2012 2:56 pm
by Charles MacDonald
Wow, great job hacking that thing!

Must be some strange hardware inside the cart?

Posted: Thu Nov 15, 2012 12:47 pm
by magicrip
When will be available public rom of Super Mario World 64 ?

Posted: Thu Nov 15, 2012 11:33 pm
by bobthebuilder
magicrip wrote:When will be available public rom of Super Mario World 64 ?
Eke wrote:There is no public ROM available as i promised it to the cartridge owner and it' s up to him to decide when he wants to release it

Posted: Fri Nov 16, 2012 12:49 pm
by MetalliC
bobthebuilder Thanks Cap! ;)

I personally would like to know - is the owner plans to publish a dump or not ? (who knows, maybe he is one of these hoarder-type persons?)
So, if not - other people can buy cart, dump it (using information kindly provided by Eke) and share the rom.
If yes - well, we must just relax and wait :)

Posted: Thu Nov 22, 2012 10:49 am
by magicrip

Posted: Thu Nov 22, 2012 12:06 pm
by Eke
Sorry but who are you again ? Do i owe you something?

I am not greedy, i am simply respecting my promise. If i didn't, i probably would not have access to this kind of rare games and would not be able to document and emulate them. I don't really care about anything else and definitively not random internet people who only register on forums to beg for roms. I think there are also more infos here than needed to get it dumped if you really want it, so much for being greedy.

Posted: Thu Jan 17, 2013 9:24 am
by andlabs
So the dump has been released (on the Pirated Games Central forum), and I noticed an interesting thing (race condition) when trying to patch it to get it to work on any emulator: sound effects stop working after the first one. It turns out the game does not disable interrupts in its play sound routine, so the VInt, which handles music for the title screen and first stage, gets control, unlocking the Z80 too early, causing the Z80 to jump into the ROM bank area and panic. This happens in both Gens/GS and Kega Fusion But this doesn't happen on real hardware, as videos have shown, so... what is going on here? Do we have VInt timings wrong? Thanks.

Posted: Thu Jan 17, 2013 10:00 am
by Eke
Have you tried logging all the access to $6xxxxx ? I think i remember it was accessed from Z80 (through banking) so Z80 program would need to be patched as well (hopefully it is not somehow uncompressed).

Good luck with the patch, i tried a bit but gave up pretty fast since it's not really trivial and i prefer to emulate the protection anyway. I believe it requires some ASM insertion to remap $60xxxx and $61xxxx access to the proper location in ROM ($08xxxx-$0fxxxx) since the banks index seems to be calculated and passed as parameter to a common function (hopefully there is only a few ot these functions to patch).

I could not find copy-protection lockouts so i am not sure where the computed logics returned by on-board registers are used but i guess this would need to be patched as well.

Posted: Thu Jan 17, 2013 12:55 pm
by Mixail