HomeForumsWhat's newResources 
 
 
Dumping MPEG Card Bios
Madroms - Oct 12, 2009

 1  2  Next> 

  Madroms Oct 12, 2009
I am in the progress of dumping Saturn stuff lately and I am wondering how the MPEG Card bios works.

Standard Saturn Bios is readable directly in the memory as it is duplicated there.

Cartridge Data are also readable directly in the memory.

But for the MPEG Card bios, how it works with the Saturn ? Is it readable through any part of the memory ? If not, is there a way to read it from the Saturn ?

Thanks for any tips you can provide

 RockinB Oct 12, 2009
There was a tool published for doing this in a CDC replacement topic here at SX. Try googling for mpgromdump.zip

 Madroms Oct 12, 2009
Ok, thanks. I will look at it and I will come back here if I will not understand the code

 Madroms Oct 13, 2009
I need help for undestanding what that does on the mpgromdump program (I am not as good as some of you on c/c++).

In main.c, there is this define:

Code: 
  
//////////////////////////////////////////////////////////////////////////////


#define SYS_MPEGCHECK(i, i2, i3) \

        ((**(int(**)(int, int, int))0x6000298)(i, i2, i3))


//////////////////////////////////////////////////////////////////////////////


And then it is used here:


Code: 
  
  Sint32 ret;

   char tempstr[128];


   if ((ret = SYS_MPEGCHECK(0, 128, 0x06080000)) < 0)

//   if ((ret = SYS_MPEGCHECK(128, 128, 0x06080000)) < 0)

   {

      sprintf(tempstr, "SYS_MPEGCHECK < 0(%d)", ret);

      slPrint(tempstr, slLocate(2, 22));

   }

   else

   {

      sprintf(tempstr, "bytes read = %d", ret);

      slPrint(tempstr, slLocate(2, 22));

   }


   slPrint("COMPLETE: Waiting for commlink...", slLocate(2, 1));


I don't understand the define part. What does it do ? I see 3 int variables (or pointers to int ?), some pointers, one memory address, but I don't see what it does putting all of this together


And what is the difference with:

Code: 
  
#define SYS_CHKMPEG(_dummy_) \

        ((**(volatile Sint32(**)(Sint32))0x6000274)(_dummy_))

found on SEGA_SYS.h ?


Thanks

 ExCyber Oct 13, 2009

Madroms said:
I don't understand the define part. What does it do ? I see 3 int variables (or pointers to int ?), some pointers, one memory address, but I don't see what it does putting all of this together

It's defining a somewhat convoluted function call to a BIOS function (indirected through a table that the BIOS sets up in RAM). I don't know the details of the syntax off the top of my head, though it's not so much a special syntax as it is an unusual combination of standard elements (casts, dereference, and function call). I think the meaning is basically:


call the function at the address stored at 0x6000298, which returns int and accepts 3 int arguments


The macro is parameterized and fills in the arguments so that it can be used similarly to a normal function call.


edit: I think I figured it out enough to break it down. I'll try to explain it as well as I can.


Complicated C expressions involving type definitions often must be read "inside-out". In this case, let's start with the literal expression:


Code: 
  
0x6000298
As far as the C compiler is concerned, this number is of type "int". That's not really what it is, though. In reality, it's the address of a memory cell containing the address of a function; it's a pointer to a pointer to a function. So we must tell the C compiler that this is what it is by using a cast operation. But in C there is no such thing as type "function"; the type of a function is defined by its signature (return type and argument types). In this case, the function returns int and accepts 3 int arguments. So in order to tell C about a function we must tell it about those things:


Code: 
  
(int(**)(int, int, int))0x6000298
(The inner "(**)" part means "pointer to pointer to function")


Now we have the number 0x6000298, properly understood as type "pointer to pointer to function returning int and accepting 3 int arguments". But now we want to call the function, so we must adopt the standard function call syntax and also dereference the "pointer to pointer" in order to obtain the actual function:


Code: 
  
(**(int(**)(int, int, int))0x6000298)(i, i2, i3)
(I think the actual macro wraps this in one more level of parens just to be safe)

 Madroms Oct 13, 2009
Thanks for all ExCyber.

Ok, I understand. It calls a Bios function indirectly, by pointing to 0x6000298 memory address. And it passes 3 args to this pointer.

Is there a way to know which Bios function is called at this address and what do the args do ?

Looking at the args:

i = 0

i2 = 128

i3 = 0x06080000

I could think:

i = start address for reading

i2= size ? If so, in bytes ? kb ???? And how could we know the correct size of the full MPEG card bios ?

i3 = memory address to copy what it is read.

Something wrong ? (probably )

What I want to do is:

Reading MPEG Card bios then copy it to low mem (0x00200000) and then re-reading data from there (using 0x20200000) for easier access.

On a side note, I don't know why we must (?) use 0x2XXXXXXX addresses to read memory instead of 0x0XXXXXXX [or maybe I have all wrong].

 antime Oct 13, 2009
Here's CyberWarriorX's explanation... of that function.


You don't absolutely have to use the uncached memory aliases except when accessing hardware registers. If you read hardware registers via the cache two unpleasant things can happen:
  • The cache will return stale values.
  • When the cache does read data, it always reads a whole cache line. Unintended accesses to adjacent memory locations can have bad consequences.
Since the Saturn's CPU caches do not support bus snooping, memory written by eg. DMA or the other CPU will not be marked as invalid. In these cases you can either manually invalidate the cache or use the uncached aliases.

 Madroms Oct 14, 2009
Oh, I missed his post. Thanks for the link.


And thanks for the info about cached/uncached memory


I will finish my rom dumper maybe this week end and I will try it quickly on a real hardware.

The only problem is I can't test the MPEG dump part easily on emu so I hope it will work (not that the code provided is bad but mine could have some errors )

 Runik Oct 15, 2009
I can test your stuff on real hardware if you want

 Madroms Oct 15, 2009
Noted Runik If I need your help I will contact you.

3 more questions:

1) is it possible to dump stuff connected on the Serial port ? aka reading RAW data through the serial port ?

2) does anyone know what this is (some data extraction from a file found on a dev disc):

Code: 
  
SEGA SEGASATURN SEGA ENTERPRISESCS HW GIGAV0.00019950100CART16M JTUBKAEL        J               SATURN TTY      TERMINAL        TEST ROM        TEST ROM        TEST ROM        TEST ROM        TEST ROM
Code: 
  
USOMON Ver 0.90 Rev 5c23m (C)1995 SEGA HW R&D Y.Shimizu.
uso.bin file: 10253 bytes. Probably something related to CartDev.

3) I am missing the SegaSaturn Developer's Documentation Vol. 1 Electronic Version Rel. 1 CD (with a yellow cover). Does anyone know what type of docs there are on it ? (and if someone wants to sell it, le me know )

 Madroms Oct 18, 2009
Ok, ROM dumper program finished and tested on real hardware.

Results:

1) ROM Cart: KOF95 + Ultraman => dumpable (both are 16MBit ROM)

2) AR Carts: All of them (AR, Urawaza, AR2, PAR,...) + clones => dumpable

3) Import adapter => dumpable

Ex:

a) Multigame Adaptor: reading the header => DATEL 95 UNI ADAPTER V1.1

b) CD+Plus: reading the header => Hong Kong Ver. 1.0, and the ROM has some ref to Pro Fighter, Game doctor and X-Terminator (so you know where it comes from )

c) Magic Card V2: also dumpable

4) Saturn Bioses: all dumpable (no news on this part as you can always use an AR+PC Comms for this). But I will probably dump some undumped Bioses in the future

5) Modem: non dumpable ?? I tested the Japanese X-band Modem. I didn't find any header of the Modem Bios/ROM in the memory (checking the A-Bus CS0) but I find some strange data on the A-Bus CS1: lot of FF00FF00, and sometimes some other data (J or S letters and = sign), then a lot of FFA5... Normally, A-Bus CS1 memory is full of FFFF is the Saturn port is not used. Could this be some part of the modem Bios/ROM ? (or maybe itself fully available here). Else, does anyone know how it works ?

6) MPEG Card Rom: no succes I always had a return code of -91. I tested the program with a EUR model 1, EUR model 2, JPN model 2 and with the EUR VCD Card and the RG-VC1 JPN VCD Card. Same result for all the combinaison.

I put this pice of codes in my programm:

Code: 
  
#define SYS_MPEGCHECK(i, i2, i3) \

        ((**(int(**)(int, int, int))0x6000298)(i, i2, i3))

and then in a function:

Sint32 retMPEG;

char tempstr[128];

         if ((retMPEG = SYS_MPEGCHECK(0, 128, 0x00200000)) < 0) {

              sprintf(tempstr, "return code < 0 : %d", retMPEG);

              MPEGsuccess = 0;

         } else {

                mFile.data = (void *)0x00200000;

                    mFile.size = retMPEG;

                sprintf(tempstr, "bytes read = %d", retMPEG);

          }
Did I make something wrong ?

 antime Oct 18, 2009

Madroms said:
5) Modem: non dumpable


It's a modem, what would there be to dump?

 Madroms Oct 18, 2009
It could have a ROM somewhere, not ? I didn't open mine so I don't know if all the data must be on the saturn program to "drive" it or if it has some sort of data on a ROM as part of the hardware.

 antime Oct 19, 2009
No, it's a very generic modem design, controlled via the standard AT command set. There is an EEPROM on board, but it's not memory-mapped.

 Madroms Oct 24, 2009
Ok, so nothing for the modem.

Noone for the MPEG Bios dump ? Did anyone succeed in the past to dump it with this command ?

 TascoDLX Oct 24, 2009

Madroms said:
6) MPEG Card Rom: no succes I always had a return code of -91.


That error means the transfer command (0xE2) failed, though it doesn't really tell why.



Madroms said:
And what is the difference with:

Code: 
  
#define SYS_CHKMPEG(_dummy_) \

        ((**(volatile Sint32(**)(Sint32))0x6000274)(_dummy_))

found on SEGA_SYS.h ?


That function will check for and authenticate the MPEG card (returns 0 if OK). It probably should be called first, if only to verify. Also, I'm not sure if you need to unlock the drive as well since the BIOS gets passed through the CD buffer. It's not something I have experience with.

 Madroms Oct 27, 2009
ok, i will try this function to see what it returns.

What is the function to unlock the drive ? And what is the consequences to do this ? (unable to run some code for ex,...)

 TascoDLX Oct 28, 2009
Actually, I don't think you have to worry about that unlocking thing, though you can find the function, CdUnlock(), in Rockin'-B's tutorial... (at the end) as well as other places. From the info I've gathered, the lockout only prevents the reading of data from bootable Saturn discs (until a disc is authenticated, of course). It shouldn't have any effect on what you're trying to do.

 vbt Oct 28, 2009

TascoDLX said:
Actually, I don't think you have to worry about that unlocking thing, though you can find the function, CdUnlock(), in Rockin'-B's tutorial... (at the end) as well as other places. From the info I've gathered, the lockout only prevents the reading of data from bootable Saturn discs (until a disc is authenticated, of course). It shouldn't have any effect on what you're trying to do.


Cdunlock allows also to access data from a CD without an ip.bin .

 TascoDLX Oct 29, 2009
OK. I think I was thrown by the name of the function. CdUnlock initializes the drive, which must be done for disc access. Discs with the Sega IP.BIN need the security ring to be verified before data can be read. I'm still not sure if it's needed here, but it couldn't hurt.

 1  2  Next>