Saturn CD Block ROM dumped

Looks like the GDEMU GUY (SD CARD VERSION) is working on Saturn one too.

 

Fascinating read, great work by jhl for sure. Should you ever decide to release a MPEG card MicroSD/SD card piece of hardware I'd be interested in acquiring one, perhaps two kits. It really is amazing to see such a "Renaissance" of sorts for old consoles offering the ability to play on the original hardware (something that is missing when playing via Emulators). Great work!

 

This is progressing well in my spare time. Got code injection into the SH-1 using my prototype board last weekend. Still a hell of a lot to do... though at this point it works as a solderless modchip at least!

 

Wow, you're fast at developing oO
Any pics/whatever available ?

Did you copied mpeg cartridge layout, or made something new from scratch ?
And about firmware on your cartridge : did you put a patched version of the Saturn internal SH-1 ROM ?

BTW, which SH-1 compiler are you using ? (or planning to use ?)

 

It's a brand new design. The interaction between the cart and CDB is fairly complex (much more so than the cart slot on the console proper) - it can't just be a hunk of ROM. The cart will patch selected points in the CDB to do its job, but it's not doing a full ROM replacement or anything. It's also not likely to be a user-accessible interface in the final cart. There's a microcontroller on there with its own firmware too.

I'm using gcc, same as I used for dumping the ROM in the first place. Will do for the SH-2 portions too, which I would like to open source.


Speaking of which - does anyone have a spare Saturn USB cart around? I'm going to need one soon.

 

I got one spare USB dev cart.
Please let me know if you are interested

Also, I have another cart that allows to easily connect some (not all) address/data lines for use on logic analyzer/whatever. Please let me know if you prefer this model or not.
If you're interested, some extra time is required on my side to buy ICs and populate your cart.

Are you developing under Windows or Linux ?
There is windows utility for this cart on my homepage, and you can find linux utility on antime's homepage.

Thank you in advance for open sourcing :]

 

Thanks for your generous offer! I've sent you a PM.


Just to make it clear to anyone skimming this thread: I would like to open source the SH-2 portions of this project - loader menu and so forth. That will enable Saturn developers access to files on SD cards and maybe USB too. I am making no plans for the hardware and firmware portions of the design at this point.

 

Here's one for cafealpha2. This is as of being able to boot burned CDRs (this is a stock Saturn, except for all the missing parts).
My desk was really neat when I started on bringing up this board. Really neat.

 

This is looking great, I'm happy that the saturn gets some attention. Keep up the good work

 

Wow, you have a nice development environment !
I'm surprised by the simplicity of bottom side of your cartridge, in comparison with the real mess that is regular MPEG cart oO

 

Not as messy as the MPEG cart I modified for code injection - it ended up with even more components than before:



Meanwhile, here is the future. The name isn't staying, and I haven't populated the SD slot, but otherwise that's how many parts there are going to be.

 

It's happening! Very excited for this, absolutely amazing work. Thank you for doing all of this!

 

I see, all the routing mess like in the MPEG card is hidden in the CPLD
But I'm still astonished by the apparent simplicity of your design !
-> You don't use RAM or even ROM ?

How do you bypass this ??
Since there's no ROM, your cartridge is not concerned ?


And, where do you plan to store SH-2 code ?
On the Action Replay/etc cartridge slot ?
(like an enhanced Pseudo Saturn firmware ?)


Just another question : how did you soldered the TQFP100 CPLD ?
Only by using soldering iron and flux ? Or do you use toaster oven ?
Until now, all my tries to solder TQFP100 were miserable failures ...
(Don't worry about your USB dev cart : it works Smaller pitch on it is 0.7mm, so even a software guy like me can solder everything easily.)

 

The design has no physical RAM or ROM - but both are emulated; this is
absolutely necessary. In this aspect it is similar to the Drag'n'Derp, which
emulates a FAT filesystem on a thumb drive, even though no such drive exists.
The CPLD-MCU pairing is capable of great flexibility. In putting this first
board together I necessarily made a lot of assumptions about how things work;
one of my major assumptions turned out to be wrong. If I had hardwired logic,
I would have had to make another board (or do a lot of soldering). As it
happens, I was able to implement the system in another way, just by changing
the firmware in both devices.

It has certainly been challenging. I had to try three different architectures
before I found one that would succeed, under the three major constraints: SH-1
timing, MCU speed, and CPLD complexity. I've spent the last two weekends with
my 'scope on a 50 nanosecond timebase getting it figured out. But now those
two critical emulations work, which proves that the system I envision is
feasible.

I don't think the SH-2 code will fit in the microcontroller. I think it will
live instead on the SD card. That way, it will be easy for users to
compile their own versions if they wish. There will certainly be nothing
requiring the top cartridge slot.

I use the drag soldering technique for fine pitch parts. I use a cup-shaped
tip, which is easiest; you can achieve the same effect with a fine point tip,
but it is much harder. Apply flux, and drag a ball of solder along the pins.
It works very well once you get the temperature right, and after a bit of
practice.
Before I learned to do that, I used to use a hotplate (actually, an electric
frying-pan, with the side cut off). Put enough solder on each pad to get a
nice dome, apply flux, place the chip, and then heat it on the pan until the
solder melts. Of course, this only works for single-sided boards, and can
easily warp the board. I strongly recommend the drag technique instead.

 

x

 

Thank you for the explanations, jhl

Oh I see.
Does it means you are using USB port to access ROM/RAM ?

Great !
I suppose you already though about it, but this would allow to dump backup cartridge (= without external connector) contents to SD card or whatever else :]

BTW, how do you execute SH-2 code from SD card ?
Do you have access to SH-2 data/address buses on rear cartridge slot ?



And, thank you for the drag soldering advice.
Actually, I use a point-shaped tip, which is very good for >0.7mm pitch parts, but as you said, not very easy to use when it comes to 0.5mm pitched ones.

By cup-shaped tip, do you mean something like this ?
http://www.hakko.com/english/tip_selection/img/work_type_07_drag.jpg
My anniversary is in few months, so let's hope that my wife will offer me a Hakko soldering iron

 

No. All RAM/ROM access is emulated within the microcontroller.

It will be booted more or less as if loading from CD.

Yes, exactly. The Hakko cartridge tips are very pleasant to use.

 

OK, I see now more or less how it works
There's no SH-2 related bus on rear cartridge connector, but it's not a problem, since BIOS reads IP and firmware from CDROM, which can be hooked by your cartridge. It is a very smart idea to do.

So if you want, you can also emulate USB dev cart with only your cartridge.


> No. All RAM/ROM access is emulated within the microcontroller.
RAM resources in MCU is tens of KB-ish, so you don't emulate whole RAM, right ? Only enough access is emulated to make SH-1 program happy with your cartridge ?

 

To a point, sure. But no USB FIFO. The whole reason I started this project was to build a dev system, so it should have some useful dev features in it too. We'll see.

I think you answered your own question

 

the design is impressively clean! looking forward to the progresses