Saturn CD Block ROM dumped again.

The Yabause source tree apparently has some decompilation notes: Yabause/yabause.

I was looking through Yabause to figure out the memory map of the SH-1. I don't follow the memory mapped registers being used within the CD Block.
 
If I remember correctly, in the yabause source tree there is 3 files, called SH1-pseudo, mpeg.c and ygr.c (or something similar), from this files you can get almost all registers used from SH1.

SH1-pseudo looks extracted from coments of the dissasembled ROM code, probably done for JHDL, but in my opinion this file is interesting from a emulation point of view.

What you are searching for is DRAM, ROM and OnChip SRAM base address????
DRAM 0x09000000
ROM 0x00000000
OC SRAM 0x0f000000
YGR regs 0x0A000000

Ive put by memory, tomorrow I will confirm, the address are related with CS pins of the SH1 an where it are mapped.
 
You are missing one section: 0x05ffe000-05ffffff. This appears to contain more memory mapped registers.
 
Thanks.
My idea is share everithing I get.

Great ! In advance, thank you for sharing :)

AFAIK pseudo saturn exploit copy fake sectors to CDB ram, but neither am I an expert.

Hmm, now that you say it, I do confirm that Pseudo Saturn is sending sectors to CDB. CD access library use this register only in read access, but writing to it actually does something. Sorry for the lack of checking on my side !
 
Did anyone ever try dumping the SH1 as an EPROM? I wonder if any of the functionality is still present in the non-PROM versions.
 
Did anyone ever try dumping the SH1 as an EPROM?
If Im in correct JHDL tried to dump the rom in programing mode.
I wonder if any of the functionality is still present in the non-PROM versions.
What funtionality do you refer???
Great ! In advance, thank you for sharing :)
Not at all, sorry for no posting more progress.
The only Ive discovery at the moment is a kind of prompt on test pins.
Its a normal serial conection at 9600bps, you can write with an serial terminal some comands for read and write some memory regions, but the relevant sections are not fully accesible, the code dont let you read the ROM, or write the on chip DRAM wich is the place where is located the stack. If you try to read the ROM always return 31 characters (IIRC) from ofset 0x0400, the copyright message I posted in first post.
At this moment Im block in a weird fuction, that looks like ofuscate the pointers to some calling functions, ghidra blocks at the same point.
Ive ported some portions of code to python for geting an ram map, but I missing something and the code reaches a function return that underflows the stack.
So at this moment Im modifying mydissasembler for turning it in an very basic SH1 emulator.
 
If Im in correct JHDL tried to dump the rom in programing mode.

What funtionality do you refer???

Not at all, sorry for no posting more progress.
The only Ive discovery at the moment is a kind of prompt on test pins.
Its a normal serial conection at 9600bps, you can write with an serial terminal some comands for read and write some memory regions, but the relevant sections are not fully accesible, the code dont let you read the ROM, or write the on chip DRAM wich is the place where is located the stack. If you try to read the ROM always return 31 characters (IIRC) from ofset 0x0400, the copyright message I posted in first post.
At this moment Im block in a weird fuction, that looks like ofuscate the pointers to some calling functions, ghidra blocks at the same point.
Ive ported some portions of code to python for geting an ram map, but I missing something and the code reaches a function return that underflows the stack.
So at this moment Im modifying mydissasembler for turning it in an very basic SH1 emulator.
Hi
A long time ago I did a SH1 windows emulator to dig in cdb ROM dump.
If Im in correct JHDL tried to dump the rom in programing mode.

What funtionality do you refer???

Not at all, sorry for no posting more progress.
The only Ive discovery at the moment is a kind of prompt on test pins.
Its a normal serial conection at 9600bps, you can write with an serial terminal some comands for read and write some memory regions, but the relevant sections are not fully accesible, the code dont let you read the ROM, or write the on chip DRAM wich is the place where is located the stack. If you try to read the ROM always return 31 characters (IIRC) from ofset 0x0400, the copyright message I posted in first post.
At this moment Im block in a weird fuction, that looks like ofuscate the pointers to some calling functions, ghidra blocks at the same point.
Ive ported some portions of code to python for geting an ram map, but I missing something and the code reaches a function return that underflows the stack.
So at this moment Im modifying mydissasembler for turning it in an very basic SH1 emulator.

Hi,

Some years ago I did a SH1 GUI Emulator to dig in CDB ROM. I was using CDB 106 ROM for my tests. When I stopped the emulator coding, only the CPU core was emulated. It has some good featuree for now, it can step in code instruction by instruction, highlight register/memory changes, breakpoints by PC location or cycles, log memory access, save states and maybe some others that I did not remember now. Follows attached some emu prints. The disasembled code is a direct copy of IDA. It has not a disassembly feature. If you have interest please let me know.
 

Attachments

  • 00.png
    00.png
    156.6 KB · Views: 283
  • 01.png
    01.png
    197.7 KB · Views: 285
  • 02.png
    02.png
    215.5 KB · Views: 259
  • 03.png
    03.png
    219.7 KB · Views: 247
  • 04.png
    04.png
    178.9 KB · Views: 249
  • 05.png
    05.png
    176.4 KB · Views: 260
  • 06.png
    06.png
    200.4 KB · Views: 264
  • 07.png
    07.png
    198.4 KB · Views: 309
Last edited:
Hi
A long time ago I did a SH1 windows emulator to dig in cdb ROM dump.


Hi,

Some years ago I did a SH1 GUI Emulator to dig in CDB ROM. I was using CDB 106 ROM for my tests. When I stopped the emulator coding, only the CPU core was emulated. It has some good featuree for now, it can step in code instruction by instruction, highlight register/memory changes, breakpoints by PC location or cycles, log memory access, save states and maybe some others that I did not remember now. Follows attached some emu prints. The disasembled code is a direct copy of IDA. It has not a disassembly feature. If you have interest please let me know.
Thanks, I dont have a windows computer only a virtual machine with windows xp, and IDA neither, but im interested in give a look.

Do you found something interesting in CDB? What I want to find at this moment is an easy way for dump the rom, maybe if the rom is more accesible, more people will work on it, to finally find some easy way for execute arbitrary code in SH1.

How do you dump the ROM???
 
I believe that It can run on WinXP. I will do a test. I had plans to port it to an open RAD in linux like QT or Glade(GTK). By now I have not spare time to do it.

I didn't dig deep enough. I had a personal problem at that time and stopped to work on dump. I never touched it again after this. At that time I was interested in the Command/Data Interface and how CDB process buffered CD Data.

The ROM was dumped by another guy that asked me to study it, but the method was the same as you did.

Do you pretend inject code through SH2 and then dump the CDB ROM?
 
Try to find a way, or some exploitable way.



I didnt know that, if have know before I dont have buy the CDB daughterboard, and didnt embarked that crusade.

Even so, I will follow researching.
I have another crusade to you. I see at this moment that there is a method to dump H8 microcontroller ROM. Maybe it could work on first versions of CD Drive that has a H8. This is a glitch method using FPGA.

This guy is dumping the servo controller of N64DD.



 
Sorry for the basic question,

How does the CS2 relate to the CD-block? Is it correct to say the SH-1 is the CD block and that the SH-1's firmware is the cd block? I've spent some time looking at the SH-1 code and it's doesn't seem to do much. Like the code to get the TOC doesn't look like it does anything at all. Maybe it's reading a memory mapped register which triggers other code execution?

I guess I don't see how the SH-1 interfaces with the disc.
 
It doesn't directly. It sends requests to the H8 microcontroller on the CD board, which drives the CD chipset. Data read from the CD goes back through the CD block LSI.

One detail I noticed from the schematics is that the LSI can handle both the 20- and 21-pin interfaces, meaning that Sega were planning to use two different CD chipsets from the start.
 
It's like antime writed. CD interface is composed by two modules: CDB(CD Block = SH1 + YGR) and CDD(CD Drive = RF IC + DSP + Servo Control Microcontroller ).
CD Drive gets raw data from CD. The H8 microcontroller send/get commands/status of SH1. If command is to get data it drives the OPU(Opticaal Pickup Unit) motor and coils to get the correct position on CD track and the reflected data(lands and pits) of Optical Media is amplified by RF IC, this data goes through DSP that demodulate it a nd process subcodes. The output of this process is sento to CDB.

CD Block: YGR descramble raw data and subcode, interrupts SH1 to process descrambled data or SH2 Commands.
 
I have another crusade to you. I see at this moment that there is a method to dump H8 microcontroller ROM. Maybe it could work on first versions of CD Drive that has a H8. This is a glitch method using FPGA.

This guy is dumping the servo controller of N64DD.




So hard to me, I dont know anything about FPGA and neither how the vulnerability works. :(
 
In SS service manual there is a schematic wich helps to get a global idea how CDB is composed.
But not show the line wich SH1 uses to send comands to CD drive.
 

Attachments

  • IMG_20200818_024420.jpg
    IMG_20200818_024420.jpg
    263.3 KB · Views: 264
Back
Top