Cave SH-3 Analysis

[rtw]

I have started to document the SH-3 hardware here:

http://www.world-of-arcades.net/Cave/Ha ... rdware.htm

Feel free to post ideas, discoveries and ideas in this thread.

rtw

[rtw]

The flash chips on the left probably only contain sound data (look at all the connections to the YMZ770). The game data is probably stored in the 128MByte NAND flash, likely compressed and/or encrypted since it's presumably going to be copied to RAM before running anyway, and they could accelerate the decoding process in the FPGA if needed.

Thanks for the heads up on the sound chip, seems plausible. So
assume U24 & U23 contain sound data or samples.

Assume that the game is stored in NAND (U2) and has to be decoded, but the board has to boot from somewhere.

Only chip which has a boot block is (U4)

So if the game boots off U4, the boot loader can be responsible for
loading the FPGA. The FPGA byte size is 290405 bytes which is easily
contained in U4 since it can hold 2Mbytes. Plausible ?

Speaking of that chip, I have no idea why the FPGA bitstream would be stored there, as mentioned on the world-of-arcades page; I would expect Cave to just upload it at the factory and battery-back the FPGA so that nobody can rip the bitstream in-transit and thereby clone the FPGA design. Has anyone found out what happens (or doesn't) when a Cave SH3 board loses all power?

I have powered off the PCB and examined the tracks. The battery only
powers the real time clock.

The bitstream to the FPGA may also be compressed. A man in the
middle attack is possible but this is a BGA device so it's complex.

Battery backing an FPGA gives all kinds of trouble. Power pins have to be
protected, the init state of the FPGA has to be controlled etc.
I believe that Cave put the protection in the CPLD which cannot be read.

rtw

[EOJ]

Seems like it will be very,very difficult to ever emulate Cave's SH3 hardware in something like MAME. They have some complex protection measures in place.

So what's the total RAM, 32MB + 8MB?

[Koma]

rtw,about the S2 (DIL SWITCH) Half Pitch DIL Switch x 4.
I have put on my Ibara pcb the dip 1 on off and when the game boot up,i access directly to the bios.I suppose you already knew right?

[eretsua]

I have powered off the PCB and examined the tracks. The battery only powers the real time clock.

i'm very happy about that.

I believe that Cave put the protection in the CPLD which cannot be read.

why can it not be read? don't have any background knowledge, just curious.

[rtw]

Seems like it will be very,very difficult to ever emulate Cave's SH3 hardware in something like MAME. They have some complex protection measures in place.

So what's the total RAM, 32MB + 8MB?

MAME doesn't need to emulate the FPGA, they just have to
emulate the frame buffer functionality.

I am unsure about the RAM total, I need to check some data sheets.

rtw

[rtw]

rtw,about the S2 (DIL SWITCH) Half Pitch DIL Switch x 4.
I have put on my Ibara pcb the dip 1 on off and when the game boot up,i access directly to the bios.I suppose you already knew right?

No I did not, thanks

I played with the others on S2 and got colour changes...

rtw

[rtw]

why can it not be read? don't have any background knowledge, just curious.

The CPLD can store a program inside itself in FLASH. This program cannot
be read out of the chip for security reasons.

Only way of reading this program would be by decapping the chip,
and restoring the readback fuse. This is NOT trivial!

Read about it here:

http://www.grandideastudio.com/files/se ... slides.pdf

rtw

[Ex-Cyber]

I believe that Cave put the protection in the CPLD which cannot be read.

EPM7032 is pretty small. The only possibility that comes to mind is that houses an LFSR whose values are periodically fed to the FPGA (which would contain a matching LFSR), and the FPGA is designed to fail somehow (randomly disappearing sprites? ) if it doesn't get the right value. Then they could change the LFSR configuration and/or seed value for each game to prevent bootleggers rewriting the board with new games. That seems a little on the weak side, but I've heard of much sillier schemes.

A man in the middle attack is possible but this is a BGA device so it's complex.

It must be available somewhere other than the Cyclone (i.e. at the other end of the connection) As far as I can tell, Cyclone only supports serial configuration, so I don't think it could be lineswapped.

[rtw]

I believe that Cave put the protection in the CPLD which cannot be read.

EPM7032 is pretty small. The only possibility that comes to mind is that houses an LFSR whose values are periodically fed to the FPGA (which would contain a matching LFSR), and the FPGA is designed to fail somehow (randomly disappearing sprites? ) if it doesn't get the right value. Then they could change the LFSR configuration and/or seed value for each game to prevent bootleggers rewriting the board with new games. That seems a little on the weak side, but I've heard of much sillier schemes.

A man in the middle attack is possible but this is a BGA device so it's complex.

It must be available somewhere other than the Cyclone (i.e. at the other end of the connection) As far as I can tell, Cyclone only supports serial configuration, so I don't think it could be lineswapped.

I believe the CPLD controls access to the serial EEPROM as well. But you
might be right it might contain an LFSR.

A man in the middle might be done from the SH-3 but it would be good
to know which pins the BGA is connected to the SH-3 with.

rtw

[Ex-Cyber]

I believe the CPLD controls access to the serial EEPROM as well. But you might be right it might contain an LFSR.

I only suggested an LFSR because I can't think of any other security-related function that would actually make sense to put into such a small CPLD - I've seen no direct evidence that they did such a thing. It's possible that values stored in EEPROM are involved in protection somehow, but I think that would be too easy to copy to be of much value. Still, the protection doesn't necessarily have to be too strong - they can potentially change the details whenever they want, and they probably don't care if someone cracks a game 2 years later when operators are already lining up to buy the next one.

A man in the middle might be done from the SH-3 but it would be good to know which pins the BGA is connected to the SH-3 with.

If the alternative is mucking around with a BGA, educated guessing and process of elimination starts looking pretty good. The SH-3 doesn't seem to have too many pins that would be suitable for doing Cyclone configuration. Anyway, if it is done by the SH-3, then it should be possible to recover the bitstream by analyzing the bootstrap program via the debug interface...

[rtw]

Thanks foir the interesting ideas Ex-Cyber, do you have access to
a Cave SH-3 PCB ?

A friend of mine pointed me to this page, it would be cool to get
an overview of the JTAG chains.

http://nsa.unaligned.org/jrev.php

And do you have an SH-3 Advanced User Debugger ? I have the pinout
mapped out already.

rtw

[Ex-Cyber]

do you have access to
a Cave SH-3 PCB ?
[...]
And do you have an SH-3 Advanced User Debugger ?

Negative on both counts, sadly. I'd be thrilled if I even had access to a recent Cave game to play, let alone one that I'd be allowed to probe. I'm not really equipped to do serious reverse engineering, though.

edit: Strictly speaking, the "Advanced User Debugger" is not a piece of equipment, but an interface for an in-circuit emulator; there's still the User Debug Interface which is accessible via JTAG. It's still not clear to me exactly what functions this interface provides; I'll have to dig deeper into the manual.

A friend of mine pointed me to this page, it would be cool to get
an overview of the JTAG chains.

Bookmarked. Looks interesting...

[rtw]

edit: Strictly speaking, the "Advanced User Debugger" is not a piece of equipment, but an interface for an in-circuit emulator; there's still the User Debug Interface which is accessible via JTAG. It's still not clear to me exactly what functions this interface provides; I'll have to dig deeper into the manual.

You should pick up an Ibara, they are pretty cheap these days.

I'm aware of the AUD interface

I was wondering if anyone had any idea what the functions are for the RAM chips:

U6 (SDRAM) MT46V16M16 4 MBit x 16 x 4 banks == 32MByte

U7 (SDRAM) MT46V16M16 4 MBit x 16 x 4 banks == 32MByte

U1 (SDRAM) MT48LC2M32 512K x 32 x 4 banks, 8Mbyte

One of them is video RAM. one is program RAM and one is sound RAM.

But which ?

rtw

[neorichieb1971]

Sorry to interupt your geeky thread (don't worry you sound knowledgable which is a good thing). But is there a point to this thread? Are you trying reverse engineer something? If something is being analysed surely you have a reason?

Sorry, just being nosey.

[Ex-Cyber]

I'm aware of the AUD interface

Are you aware of any actual documentation of it, or does Renesas hoard that stuff so that they can go on charging $2000+ for what amounts to a dongle?

I was wondering if anyone had any idea what the functions are for the RAM chips:

U6 (SDRAM) MT46V16M16 4 MBit x 16 x 4 banks == 32MByte

U7 (SDRAM) MT46V16M16 4 MBit x 16 x 4 banks == 32MByte

U1 (SDRAM) MT48LC2M32 512K x 32 x 4 banks, 8Mbyte

I suspect that that the 8MByte one is SH-3 work RAM and the others are both for graphics. Since there appears to be dedicated flash memory for sound samples, I don't think much - if any - dedicated sound RAM would be needed.

Sorry to interupt your geeky thread (don't worry you sound knowledgable which is a good thing). But is there a point to this thread? Are you trying reverse engineer something? If something is being analysed surely you have a reason?

I can only speak for myself. At this stage, I think the principle behind this quote applies:

Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it.

[rtw]

Are you aware of any actual documentation of it, or does Renesas hoard that stuff so that they can go on charging $2000+ for what amounts to a dongle?

Sadly no all I have is the Renesas manuals.

I suspect that that the 8MByte one is SH-3 work RAM and the others are both for graphics. Since there appears to be dedicated flash memory for sound samples, I don't think much - if any - dedicated sound RAM would be needed.

But the FLASH chips would store the instrument banks, like on the SPI boards, someone would have to activate the tunes, i.e. send down
a midi stream or similar ? Maybe the SH-3 is powerful enough ?

I have the manual for the YMZ770C but it's in Japanese. Title is:
Amusement Music Decoder With Sequencer type-A

Autoxlation

High-performance compressed audio player with built-in automatic sequencer play LSI.

A bit rate of 24 to 384 k bit/sec in the variable,
The sampling frequency of 16 to 48 kHz
External ROM 256 songs phrases data from 8 phrase
simultaneous independent renewable
8 system of internal sequencer
Features integrated

http://www.yamaha.co.jp/product/lsi/prod/sgl/index.html

Science is like sex: sometimes something useful comes out, but that is not the reason we are doing it.

Awesome quote, which sums everything up nicely

rtw

[Ex-Cyber]

But the FLASH chips would store the instrument banks, like on the SPI boards, someone would have to activate the tunes, i.e. send down
a midi stream or similar ? Maybe the SH-3 is powerful enough ?

The datasheet translation says "automatic sequencer", which makes me think that the Yamaha chip has some kind of embedded processor and RAM to manage the actual playback; the SH-3 probably just needs to upload the actual sequence data (which is probably small enough to be held in RAM inside the YM chip) to get a song going. If it's just doing sample playback, I think the SH-3 could still manage it with the appropriate timer interrupts...

[Dragon1952]

I think that this is an excellent thread and important as well. Understanding and discussing how impressive coin-op 2D hardware works helps lead to more cool 2D hardware for coin-op games.

I work for a new start-up video game publisher and we are researching the very real possibility of creating a similar small and powerful 2D hardware system to make a new generation of arcade games using this type of technology (rather that polygonal 3D)..... like Cave does.

Keep up the great debate!

[rtw]

The datasheet translation says "automatic sequencer", which makes me think that the Yamaha chip has some kind of embedded processor and RAM to manage the actual playback; the SH-3 probably just needs to upload the actual sequence data (which is probably small enough to be held in RAM inside the YM chip) to get a song going. If it's just doing sample playback, I think the SH-3 could still manage it with the appropriate timer interrupts...

Thanks for the heads up.

I will peel of the label on my Ibara to see where the paths are. Looks
like there are a few paths going from U1 towards the YMZ770C.

Another thing is that Ibara has a pretty interesting loading screen. With
information on banks being copied and a memory map. I'll snap some
pictures in the near future.

I don't have a video camera, but maybe someone here could make
a small video of the Ibara boot up ?

rtw

[Ex-Cyber]

I will peel of the label on my Ibara to see where the paths are. Looks like there are a few paths going from U1 towards the YMZ770C.

Good catch. Looking at the pinout and block diagram in the datasheet, I think these pins are the host interface data bus, and are simply connected to the 8MByte SDRAM as a means of sharing the data bus with it. What I'm curious about is whether that bus connects from the SDRAM directly to the SH-3 or goes to the FPGA (or both?).

edit: well, realistically the question is: is the SDRAM connected directly to the CPU? It's probably a safe assumption that its data bus is connected to the FPGA (either because the FPGA is interfacing it or because the CPU uses the same data bus to communicate with the FPGA).

Also, skimming+Babelfish provides further evidence of RAM inside the YMZ770C:

The /RESET terminal from "L" level in "H" level after the changing, with the clock which is input into XI terminal between 262144 clocks, because initialization of the built-in RAM of LSI is done, as for the command from HostCPU is ignored with all modes.

[Koma]

I don't have a video camera, but maybe someone here could make
a small video of the Ibara boot up ?
rtw

I can make a try.I don't guarantee the result with my poor camera

[rtw]

I can make a try.I don't guarantee the result with my poor camera

Please make a try

I peeled of the sticker on my Ibara, it looks like this:



As you see the sticker hides the wires from RAM to the YM.

But the weird thing is that it looks as if the FLASH chips connected
to the YM are not part of a JTAG chain. I.e. they see no device which
can program them.

rtw

[EOJ]

But the weird thing is that it looks as if the FLASH chips connected
to the YM are not part of a JTAG chain. I.e. they see no device which
can program them.


rtw

So they are programmed before they are put onto the PCB?

[Ex-Cyber]

But the weird thing is that it looks as if the FLASH chips connected
to the YM are not part of a JTAG chain. I.e. they see no device which
can program them.


rtw

Stuff isn't necessarily programmed via JTAG directly; I've heard that it's common to use JTAG to upload a test/production program for the CPU to run, and then the CPU can get the data from a serial port or some other connection.

[rtw]

Stuff isn't necessarily programmed via JTAG directly; I've heard that it's common to use JTAG to upload a test/production program for the CPU to run, and then the CPU can get the data from a serial port or some other connection.

We use JTAG at work for initial FLASH program. In order for it to work
properly, we need access to the CPU and in turn it needs access to
all the programmable chips so that it can FLASH them.

Either the YM FLASH chips contains a given set of instruments, which is
the same for all games i.e. WaveTable. But if this is the case
where are the sound effects ?

rtw

[Ex-Cyber]

Stuff isn't necessarily programmed via JTAG directly; I've heard that it's common to use JTAG to upload a test/production program for the CPU to run, and then the CPU can get the data from a serial port or some other connection.

We use JTAG at work for initial FLASH program. In order for it to work
properly, we need access to the CPU and in turn it needs access to
all the programmable chips so that it can FLASH them.

Well, I can imagine several possibilities, but it pretty much comes down to one empirical question: what do the /WE pins (pin 11) on those chips connect to? From your pic, I can only see that they go to vias, except for the lower-right one, which has a resistor connected inline with the via.

[rtw]

Well, I can imagine several possibilities, but it pretty much comes down to one empirical question: what do the /WE pins (pin 11) on those chips connect to? From your pic, I can only see that they go to vias, except for the lower-right one, which has a resistor connected inline with the via.

Cave has obviously added some obfuscation, large ground planes are
present on the PCB.

Is it pin 11 on the 29DL321's you are wondering about ?

rtw

[Ex-Cyber]

Well, I can imagine several possibilities, but it pretty much comes down to one empirical question: what do the /WE pins (pin 11) on those chips connect to? From your pic, I can only see that they go to vias, except for the lower-right one, which has a resistor connected inline with the via.

Cave has obviously added some obfuscation, large ground planes are
present on the PCB.

Is it pin 11 on the 29DL321's you are wondering about ?

rtw

Yes.

[rtw]

Discovered something interesting this evening.

The EPM7032 CPLD on my Ibara BL is marked as "Mushitama"

And the two sound FLASH chips look like they have been manually
soldered. I.e. this PCB has been changed from a Mushihimetama
to an Ibara BL!

Anyone else have a BL with the same artifacts ?

rtw