action replay custom firmware flashing

[the_mad_joob]

Hey there...

Here is my problem :

I need to test a custom firmware on my action replay 4m plus (EMS).

Because i don't own a pc comms card, i was thinking of using ExCyber's utility included in Save Game Manager.

The main deal is about importing my file so i can get it recognized by SGM, and then flash it.

Easy, you would say ?

Actually not...

Plan A : burn the file on a separate cd and use the "rescan cd" function of SGM > FAILURE

- C4 2005 cd :

The "rescan cd" function (3rd version of SGM) only works with the C4 2005 cd itself.

- The Rockin'-B All Stars cd :

The "rescan cd" function (5th version of SGM) automatically causes an instant freeze when used.

Plan B : burn a custom cd with Atlas Creator including SGM and the file > FAILURE

SGM.AGP (required) is corrupted so Atlas Creator is unable to create the cd image at all.

Looks like Rockin'-B's site has become some kind of no man's land...

It seems impossible to reach him so i don't expect any bug fixes before years.

That said, i decided to purchase an usb datalink.

Plan C : send the file to ram using the datalink > FAILURE

Sending the file actually works but it would take a lot of tries to find a safe area which is not overwritten by the AR manager, Atlas or SGM.

Plan D : send the file to backup memory using the datalink > WORKING ON IT

Because this is my last option left, i decided to give it a try.

The good point is that this area is safe from the softwares i intend to use.

The bad point is the size and strucure of the area.

Anyway, the main idea is to :

- split the file in 9 pieces

- edit each piece to make it fit the backup memory specific data format and then send it with the datalink

- move each piece to a sega backup cartridge

- join all the pieces together with SGM

- flash the action replay

So, i recently started to learn how the backup memory works by myself with the help of a hex editor.

In fact, i figured out almost everything except a couple of things.

>>> This is where i need help :

- 3 bytes are obviously reserved for checksum in the header of each game save.

How is it calculated ?

- Sometimes, before the actual data of a game save, some kind of character-indexing bytes can be found.

Despite those bytes don't seem to be essential, what is their function ?

Thanks in advance =]

 

[ExCyber]

arflash can be built as a separate app. It doesn't support reading files (Rockin'-B added that, in a way that's sort of strange so it's not easy to add it to the standalone app), but if you have a toolchain with SGL and a "bin2c" app you can build a custom arflash binary with your firmware image. That is, if you can find the source code; it seems to have disappeared a bit. If you're interested in this approach, I'll look around the obvious places on my backups and see if I can find it.

Another hacky possibility that comes to mind with the Data Link is to dump memory before the flash occurs, find the location of the AR firmware (it starts with a pretty recognizable header, which you can see on the firmware files on SGM), and overwrite it before starting the flash. Saturn has no MMU, so it should all be in one contiguous region.

As for the save game format, I don't know much about that, but are you sure it's 3 bytes for the checksum and not 2 bytes for the checksum and another byte for something else? Hash algorithms usually use a power-of-two number of bits. The method that Sega used for Genesis games is something like this (probably not exactly right; you can find actual code to calculate it in an open-source Genesis emulator):

Skip the header

For odd-numbered bytes, just add the value of the byte to a 16-bit total

For even-numbered bytes, multiply them by 256 (i.e. shift left 8 bits) and add them to the total

 

[the_mad_joob]

Thx for the reply =]

Building a standalone app is a great idea, for sure.

Unfortunately, my knowledge in C sucks quite a bit for now...

Overwriting the firmware directly is another idea i haven't considered yet.

As for the location, and if Charles MacDo is right, it seems to be the following :

$22000000-$2207FFFF (A-bus CS0 region, mirrored every 256 KB)

I don't know if the datalink is able to write there and continue working at the same time, considering it may need to access some firmware routines to actually do the writing job.

Anyway, i'll try and tell you.

About the backup memory, here is what we have discovered for now : http://segaxtreme.net/community/topic/16849-backup-memory-structure/

 

[Amon]

I think the ARFLASH source is distributed with Saturn Orbit dev thingy.

 

[the_mad_joob]

Thx a lot for the info Amon but my skills in C are the same as a 1 year child trying to mod a saturn =]

I am more familiar to asm but maybe i will give it a try if i can unlock some time...

 

[ExCyber]

Building a standalone app is a great idea, for sure.

Unfortunately, my knowledge in C sucks quite a bit for now...

You don't have to really write any C for that approach; arflash was already written as a standalone app. You would only need to convert your binary to a C array (there are many different programs to do this, usually called "bin2c") and add the declaration and brackets (which you can just copy/paste from one of the stock firmware headers).

Overwriting the firmware directly is another idea i haven't considered yet.

As for the location, and if Charles MacDo is right, it seems to be the following :

$22000000-$2207FFFF (A-Bus CS0 region, mirrored every 256K)

I don't know if the datalink is able to write there and continue working at the same time, considering it may need to access some firmware routines to actually do the writing job.

Anyway, i'll try and tell you.

That won't work, because of the way the flash memory works (you can't write straight to the memory; there's a command protocol). What I meant was to load up arflash and overwrite its copy of the new firmware in RAM before starting the flashing process. However, you're right that this might not work if the right routines don't exist in the firmware.

Total size is 65536 bytes.

All even bytes cannot be used and must always be set to $FF, which represents a waste of 32768 bytes !

It's only a waste of address space. The reason those even bytes can't be written is that there's no RAM there.

 

[the_mad_joob]

I suppose i can handle a simple copy/paste job then =]

Before trying to write, i tried to dump both $22000000-$2207FFFF and $02000000-$0207FFFF and found only arbitrary data...

Anyway, as you say, i won't be able to write without the right protocol.

Otherwise, it seems impossible to write to ram with the datalink if you are not currently running the AR manager.

And writing with SGM would be quite a pain (not even sure if it's possible).

About the even bytes, i was thinking of something like this but was not sure so thanks for the confirmation.

It's just about the way memory is adressed if i understood well.

 

[ExCyber]

Before trying to write, i tried to dump both $22000000-$2207FFFF and $02000000-$0207FFFF and found only arbitrary data...

IIRC, the memory dump routines in the stock firmwares are coded to deliberately send garbage data if asked to dump from the AR flash region.

Otherwise, it seems impossible to write to ram with the datalink if you are not currently running the AR manager.

And writing with SGM would be quite a pain (not even sure if it's possible).

I think you need to have a master code and have codes enabled for transfers to work while running a game/app. There is a default master code that works for most games, but I don't remember whether I've tried it with any homebrew apps. It's probably based on hooking some standard bit of SGL code, so it's probably worth trying with SGL-based apps (which arflash is).

About the even bytes, i was thinking of something like this but was not sure so thanks for the confirmation.

It's just about the way memory is adressed if i understood well.

Yes, it's just an 8-bit RAM being accessed on a 16-bit bus, so half of the addresses are reading the "empty half" of the bus.

 

[the_mad_joob]

That must be the reason why the datalink software has to send a utility before being able to dump the firm...

Well thanks for all those infos.

I'll try different things and tell ya...

 

[antime]

I've uploaded a version of ExCyber's arflash that I've successfully used to flash an Action Replay cart here. To build the binary you need ExCyber's fixed SGL package and of course a compiler toolchain. You will need to customize the following:

• In the Makefile, you need to edit both rows to point to your SGL installation
  
• Replace romimage.h with your firmware image. ARROM_LEN should be the length of the image, and the arrom_image array is the image itself. Remember to pad the image to at least the next full flash page as arflash doesn't handle that at all.
  

After you've run make, you'll get a binary (sl.bin) that you can just upload as any other binary using whatever method you want.

 

[the_mad_joob]

I downloaded SaturnOrbit and am already working on it.

This pack is awesome and already includes more than i could ever need...

Anyway, thx a lot antime, especially for the ARROM_LEN var i would probably have forgotten without your help =]

I intend to try to run arflash using the "load homebrew game" function of the datalink software.

Let's see...

 

[the_mad_joob]

Great news...

The method of injecting a firmware using arflash's source actually worked =]

So i can tell you the application loader of the datalink works like a charm.

In fact, i wanted to try if it was possible to update only the executable area (64 KB), the codes (32 KB), or both, in order to be able to flash without destroying the game saves.

I tested something like 6 differents firmwares but this unfortunately doesn't work.

At best, saves are erased, and at worse, the firmware becomes corrupted.

On the other hand, i succeeded in rapairing the corrupted firmware which was included in The Rockin'-B All Stars (the last official one for ar4m+ patched with more codes).

Thx to all of you guys, especially ExCyber who made possible the flashing with a datalink (probably without knowing it when he wrote the code =]).

P.S. :

About the backup memory, i've tried different checksum calculation types but none seems to fit the value of those 3 mysterious bytes.

I'm still interested in figuring it out and will probably open a topic dedicated to the backup memory structure and the possibilities of exploiting it.

 

[gameofyou1]

Great news...

The method of injecting a firmware using arflash's source actually worked =]

So i can tell you the application loader of the datalink works like a charm.

In fact, i wanted to try if it was possible to update only the executable area (64 KB), the codes (32 KB), or both, in order to be able to flash without destroying the game saves.

I tested something like 6 differents firmwares but this unfortunately doesn't work.

At best, saves are erased, and at worse, the firmware becomes corrupted.

On the other hand, i succeeded in rapairing the corrupted firmware which was included in The Rockin'-B All Stars (the last official one for ar4m+ patched with more codes).

Thx to all of you guys, especially ExCyber who made possible the flashing with a datalink (probably without knowing it when he wrote the code =]).

P.S. :

About the backup memory, i've tried different checksum calculation types but none seems to fit the value of those 3 mysterious bytes.

I'm still interested in figuring it out and will probably open a topic dedicated to the backup memory structure and the possibilities of exploiting it.

I just came across this topic. Congrats on getting ARflash working with the DataLink !

I would really like to be able to offer people a possibility of re-flashing an ARP with the DataLink. The best solution is if you could load the backup flash file to a specific address in ram. Then load (& execute) the ARflash code. I may do some testing with this, when I get a chance.

Of course this relies on the fact that the ARP is actually functional in the first place...

 

[cafe-alpha]

I would really like to be able to offer people a possibility of re-flashing an ARP with the DataLink. The best solution is if you could load the backup flash file to a specific address in ram. Then load (& execute) the ARflash code. I may do some testing with this, when I get a chance.

Of course this relies on the fact that the ARP is actually functional in the first place...

Here is a while it is possible on my PC+Saturn

I proceed like this:

1) A Saturn program is sent and executed to the Saturn.

2) The Saturn program waits for an ARP file from PC.

-> The ARP firmware transfer is performed from PC to Saturn with a custom PC program that can send/receive data, receive debug messages from Saturn, etc.

3) When the ARP firmware data is received on Saturn, flashing operation starts.

Note: It is also possible with the 2 other following ways:

A ) Saturn program and ARP firmware are loaded from CD-ROM (modchip or swap trick is needed, useful when your ARP doesn't boot)

B ) Saturn program is embedded in a custom ARP firmware (but you need to ... flash your ARP with this firmware first ^^; )

Theses tools work well with my freewing device, however, I don't want to release them, because I'm not sure it works with USB Data Link.

(The reason for this is that I want to be sure it will not blow up your ARP when using a device other than my freewing)

My PC transfer tool has been designed in order to support easily various communication devices. It currently supports :

- freewing

- commslink (not tested)

- USB Data Link (not tested)

If somebody want to test/debug this stuff with his communication device, please contact me (here).

(Note: I will be busy this month, so test/debug will not be possible until the beginning of December)

 

[the_mad_joob]

Hey guys...

*****

@gameofyou1 :

First, thx a lot for having created the datalink.

It's good to see you on these forums actually =]

Sending the firmware first and then the arflash utility is a nice idea i already thought about.

If you want the flashing to be compatible with most firmwares, here is a way to do it :

DATALINK SOFTWARE MODIFICATION :

- Add an option dedicated to firmware flashing in the gui.

- Make a routine which get the size of the firmware file selected by the user.

- Integrate the modified arflash binary in "Program Files\Saturn_USB\".

ARFLASH UTLITY MODIFICATION :

- Make it read the firmware data always at the same location.

- Make it read the firmware size always at the same location.

FLASHING PROCESS :

- The user selects the firmware file.

- The datalink soft calculates the file size.

- The datalink soft sends both data and size at the 2 specific locations.

- The datalink soft sends & executes the arflash binary.

The lazy way would be to create multiple copies of arflash, each including a specific firmware, and add a user-friendly selector in the datalink software.

I was asking myself, is there a way for the datalink to work if the user is not at the action replay main menu ?

I've heard about an action replay master code which allows the cartridge to send/receive during the execution of games.

I don't know much about it but maybe that code was intended to be used with the pc comms card...

CU =]

*****

@cafe-alpha :

Is that some kind of self-made hardware you call "freewing" ?

Never heard about it...

Anyway, your sending system sounds interesting.

I suppose you'll still have to make your software compatible with the 3 different hardwares.

The way of including the program you need in the firmware itself ( B ) seems not that impossible.

Maybe by making the firmware copy a part of itself (your program actually) in memory and then execute it ?

Anyway, modifying the firmware is the real pain here...

A bientôt =]

 

[ExCyber]

Is that some kind of self-made hardware you call "freewing" ?

Free Wing is a Japanese hacker who designed an AR comm interface that connects to a PC (or NEC PC-98) parallel port. It's practically a comm link card that connects to the parallel port instead of ISA. Schematics and a DOS communication tool can be found on this page (search the page for PAR_HARD.LZH).

The lazy way would be to create multiple copies of arflash, each including a specific firmware

Hey, I resemble that remark!

 

[cafe-alpha]

Anyway, your sending system sounds interesting.

I suppose you'll still have to make your software compatible with the 3 different hardwares.

The code for theses hardwares is written, however, I need some volunteers in order to test on real hardware.

So if you are interested in testing my softs, don't hesitate to contact me.

As a reward, I will put your name in the "special thanks" list

The way of including the program you need in the firmware itself ( B ) seems not that impossible.

Maybe by making the firmware copy a part of itself (your program actually) in memory and then execute it ?

Anyway, modifying the firmware is the real pain here...

There are not so much differences between a normal Saturn program and an ARP firmware ^^

Once you can write Saturn firmware, everything becomes possible !

Free Wing is a Japanese hacker who designed an AR comm interface that connects to a PC (or NEC PC-98) parallel port. It's practically a comm link card that connects to the parallel port instead of ISA. Schematics and a DOS communication tool can be found on this page (search the page for PAR_HARD.LZH).

It is explained in a better way than I would have wrote, thank you

Oh, and my device looks like this.

 

[ExCyber]

The way of including the program you need in the firmware itself ( B ) seems not that impossible.

Maybe by making the firmware copy a part of itself (your program actually) in memory and then execute it ?

Anyway, modifying the firmware is the real pain here...

There are not so much differences between a normal Saturn program and an ARP firmware ^^

Once you can write Saturn firmware, everything becomes possible !

Yes, in fact the AR firmware itself runs from RAM. The BIOS copies the IP.BIN to RAM and runs it from there (like when booting a CD) and then the AR's AIP code copies the firmware to RAM and jumps to it there.

 

[the_mad_joob]

For those interested, i created an ultra-light custom atlas cd dedicated to flashing which includes SGM 5, new/repaired firmwares and ready2sent arflash binaries.

Nothing revolutionnary there, but could be quite usefull in some circumstances (until something better is done).

Instructions in READ.TXT : http://rapidshare.com/files/432620923/atlas.rar

I would be glad to include any new firmware dump.

Take care =]

P.S. : If someone knows a way to repair the "rescan cd" function of SGM, i'm quite interested...