PAR / GameShark reflash CD image?

Ok, on PSX side there is a nice CD image floating around to restore PAR / GS 2.x to ezoray (one of the early firmware replacements, died due to Caetla superiority). Once ezoray is in flash, one can use a variety of flashing tools to update flash with official PAR/GS or caetla firmware.

Now wouldn't it be very nice to have something similar on Saturn side? I, for instance, would be extatic about such a tool. Preferably for both for EMS and Datel products, but even EMS only support will do 🙂

I would transfer a paypal payment of 5$ US to anyone who will come up with such product, and it will be 10$ if the source is available. It's not a paid job, it's more of the fame and self-esteem busting excersise, so don't get all cranky about low value of reward. Think of it not as a payment, but as a nice simbolic prize for being the best Saturn homebrew coder.

Anyway, if a firmware repair CD image will be released to public, I am pretty sure that could lead to at least two beautiful things:

1) better alternative firmware for PAR / GS, like Caetla on PSX side

2) flashable small games and / or demos with possibility of reading data from CD on modded Saturns or from PC with Comms Link card (i.e. host-based file system)

Another possible project is to reverse-engine Saturn BIOS, and see what can be done to improve it (remove intro sequence, territory lockouts, may be something else). But this is harder and less rewarding then PAR repair CD.
 
It's actually already coded and works (for both EMS and Datel designs), just wasn't public because it's kinda an ad-hoc pile of poo that requires static linking in the ROM image to flash. I'd post the source right here, but the board won't let me. <_<
 
Cool! :bow :bow :bow ExCyber, by this message I proclaim you the greatest Saturn homebrew developer of the year 2003!

I will send you a private message with my email and ask you to kindly share wisdom with unworthy 🙂

Anyway, as I promised, I can PayPal you 10$ or send you some weird jap games I bought recently over eBay 🙂
 
Be careful with this stuff; in general I wouldn't recommend using this on a working cart just to play with it (unless you can afford to lose the cart for a bit while I figure out what went wrong). If the flash ID is unrecognized, the core firmware (read: region bypass) might still boot but you're virtually guaranteed to run into save / code list problems unless the firmware is patched to recognize your chip (this approach is known to work on one unusual cart design that uses a 3.3v variant of the usual SST flash*). PM me with bug reports.

edit:

*: or at least Arakon hasn't bothered me about it since 😉
 
I'm kind of curious... Was anyone able to successfully burn any of those pre-built images? I tried twice with my new dvd burner. Both times it didn't work(it won't even bother checking the copy-protection ring). So I figured I would try my old burner(which has never had any problems burning saturn stuff in the past). Exact same result.

Cyber Warrior X
 
I'm using the Sporting Clays / phemusat ip.bin; ISTR that an earlier version of it didn't work unless booted from an AR, but that may or may not be true of this one...

edit: just tried it (the emsar4mp image, but all have an identical ip.bin), booted with and without the AR.
 
Very cool stuff!

ExCyber, is it you who wrote this stuff? This way one could try to flash it with some small selfmade program. Any stuff that has to be considered doing this, except for the correct id? Is the whole content that was flashed loaded into workram and executed? I'm a little out of business right now, but maybe there exists an ip.bin for cartridge games, too.

You are quite familiar with the cartridge port, do I remember right?

Then do you know if there is a way to send signals to/receive signals from cartridge, except from adress/data busses.

And how about the slot for the videocd cart, do you know anything about that?

Thanks.
 
ExCyber, is it you who wrote this stuff?

Yes. I had done most of the core research quite a few months ago, then Arakon pushed the implementation forward by mentioning his broken cart a while ago and more or less volunteering to be my guinea pig. Subsequently I fried and fixed one of his carts. Pointer arithmetic :devil

maybe there exists an ip.bin for cartridge games, too

Yes, it can be found in the first 768 bytes of the ROM image and AFAICT is pretty much identical to a standard ip.bin up to that point.

Is the whole content that was flashed loaded into workram and executed?

The AR does this itself, and it strikes me as a good idea given what's known about the cartridge port (Sega didn't even really trust it). It might be possible to coax the BIOS into doing the transfer itself with appropriate modifications to the ip.bin.

Then do you know if there is a way to send signals to/receive signals from cartridge, except from adress/data busses.

Nope, only really examined what's used by the AR cart. I suspect that Netlink, at least, uses some other pins (maybe one of the onboard serial ports of the SH-2)

And how about the slot for the videocd cart, do you know anything about that?

Virtually nothing.
 
Did the cartdev/PsyQ hardware need a boot disc? If it didn't it might be possible to boot from cartridges, unless they use the same injection trick as the ActionReplay.

The cartridge header is specified as being for data cartridges only, and doesn't look like it's meant for code. The header in the AR ROM doesn't follow this specification but looks like it's at least trying to follow the standard IP header.
 
If it didn't it might be possible to boot from cartridges, unless they use the same injection trick as the ActionReplay.

Injection trick? AFAICT, the "trick" consists of connecting a ROM with an ip.bin to the A-Bus CS0 area and leaving the BIOS to its own devices.

The cartridge header is specified as being for data cartridges only, and doesn't look like it's meant for code. The header in the AR ROM doesn't follow this specification but looks like it's at least trying to follow the standard IP header.

Yeah, this is probably why there are various bits in the boot section of Disc Format Standards Specification that say things like "for a CD", "ignored for CDs", implying that an ip.bin can be used on another medium. But now that I look at it closer, the information layout seems to be different...

edit: aside from the media type being "GAMESAMPLE" instead of a CD flag, it really just looks like it's trashed, with arbitrary text where some values are supposed to be, and a duplicate set of the area flags. However, it also looks like stuff that the BIOS is likely to ignore (e.g. title, peripheral flags, release date)
 
Back
Top