Sega Saturn PC link

[danielt3]

hi all

I'm a wannabe sega saturn programmer, and i'm stuck into this link problem. I think this was largely discussed here in the forum and i did search for answers befora posting. But since those could not answer my questions, i'm posting here.

Here they are:

1.) i'm thinking on ordering a Action Replay 4M Plus for my sega saturn

Action Replay 4M Plus (lik-sang)

will i be able to link it to my pc using parallel/serial ports and not using the infamous CommLink card?!

2.) I read on Rockin'-B's Tutorial that exists a FreeWing IF ou yano extend cart that can act like an interface between the action replay's port and the parallel port. Anyone has built this?! Do they work properly?! I searched over the internet but i could not find any schematics for builting these. Can anyone send me a link?????

3.) Can anyone ever tried to reverse engineer the protocol in order to directly link the action replay to the pc serial/parallel port?!?!? I think that, if properly set up, PC port can provide enough speed to do the job of linking the pc and the console for development proposes.

What can you say about the viability of this??!?

that's it for now

thanks

Daniel

 

[mrkotfw]

go with the comms link card and save yourself a world of trouble. and do not use sbl/sgl. use charles' code as examples, use antime's or bart's linker/crt0 scripts. oh, and don't give up!

 

[RockinB]

The AR protocol is used in homebrew PC tools and homebrew Saturn demos, so it's sort of reverse engineered. Examples: sh2 debugger, 68k debugger, Charles MacDonald's Saturn demos.

The schematics can be found in topics of this board.

QUOTE(Piratero @ Thu, 2005-11-03 @ 09:45 AM)use sbl/sgl

[post=141312]Quoted post[/post]​

[/b]

This is no good advice, as it applies only for a minority of coders. The average "wannabe sega saturn programmer" will just give up and leave. Is that what you want?

@Thu, 2005-11-03 @ 09:45 AM

oh, and don't give up!

[post=141312]Quoted post[/post]​

True!

 

[danielt3]

Originally posted by Piratero@Thu, 2005-11-03 @ 06:45 AM

go with the comms link card and save yourself a world of trouble. and do not use sbl/sgl. use charles' code as examples, use antime's or bart's linker/crt0 scripts. oh, and don't give up!

well...thanks for the tip...but these CommLink cards are kinda hard to find (altough i have found some CommLink cards for the PSX...are they the same saturn uses?!?!?)

Daniel

 

[danielt3]

Originally posted by Rockin'-B+Thu, 2005-11-03 @ 07:18 AM--><div class='quotetop'>QUOTE(Rockin'-B @ Thu, 2005-11-03 @ 07:18 AM)</div><div class='quotemain'>The AR protocol is used in homebrew PC tools and homebrew Saturn demos, so it's sort of reverse engineered. Examples: sh2 debugger, 68k debugger, Charles MacDonald's Saturn demos.

[/b]

well thanks...i've read charles' docs on the action replay...it doesn't seem to be hard to make a tool that can directly communicate with those via the parallel port for debugging/dev proposes...is there any obscure point that would not allow this to work?!??!

<!--QuoteBegin-Rockin'-B@Thu, 2005-11-03 @ 07:18 AM

The schematics can be found in topics of this board.

[/quote]

i found this: SatLink

but there is something i didn't understand: is the called COMM PORT that wierd port located on the saturn back, in the same place of the battery?????

because if it is, we are in the same problem since that alien connector wouldn't let me use the i/o port...if not, please tell me what one is the schematic about?!??!!?

 

[Quick Man]

The Comm Port is properly known as the Communications Connector, which is the port next to the graphics plug. The one behind the battery is for a VCD card if you decide to put one in (unless you live in Japan there's little point since VHS works perfectly well elsewhere).

The Playstation commlink card should work with the Saturn - it just uses different hardware. Certainly the commlink card I bought was advertised as for the PSX but on the packaging claims to work with the Saturn as well.

 

[ExCyber]

A commlink card is a commlink card. It doesn't care what console is on the other side of the AR. Those differences are all handled by software.

it doesn't seem to be hard to make a tool that can directly communicate with those via the parallel port for debugging/dev proposes...is there any obscure point that would not allow this to work?!??!

You can't just do a direct connection and set it up as bidirectional because the commlink protocol does not allow for the host to control bus turnaround. What will happen is that you'll have a period where both output drivers (the AR's 74xx245 and your PC's parallel port) are turned on at the same time, causing a bus conflict. Adapter designs do exist, but they basically implement the equivalent of an entire commlink card (4-5 cheap ICs). I can dig up a link if you're interested in building one.

 

[mrkotfw]

Originally posted by Rockin'-B

This is no good advice, as it applies only for a minority of coders. The average "wannabe sega saturn programmer" will just give up and leave. Is that what you want?

honestly, that is not a good reason as to why he shouldn't avoid the libraries. i've used them, and i learned nothing from it. isn't programming all about learning? what good is it if you have everything done for you? if i can write a lame demo without the use of the libraries, anyone can. :blah i doubt he'll be scarred for life if he does something like:

#define SetupTV(n) *(volatile unsigned long *)0x25F80000 = (n);

SetupTV(0x8000);

that wasn't so bad, now was it?

 

[RockinB]

Piratero, you do expect to much from Saturn n00bs.

Originally posted by Piratero@Fri, 2005-11-04 @ 05:57 PM

#define SetupTV(n) *(volatile unsigned long *)0x25F80000 = (n);

SetupTV(0x8000);

that wasn't so bad, now was it?

[post=141360]Quoted post[/post]​

This looks like a simple line of code, but it couldn't be done without further knowledge from the docs.

There are a lot of reasons to push the effort in avoiding the use of SGL/SBL libraries, no doubt about that.

But in a situation where Saturn homebrew releases are so rare, my strategy is to make things easy to even get n00bs into Saturn dev. And I succeeded as I had contact with a couple of n00bs recently. But if I would have told them to do everything from scratch, none of them would make any contribution to the Saturn homebrew scene.

I do have much respect for people doing things without SGL or even without SBL. The point is just: a Saturn dev n00b is not necessarily an experienced programmer.

 

[Amon]

Originally posted by Rockin'-B@Fri, 2005-11-04 @ 11:28 AM

But in a situation where Saturn homebrew releases are so rare, my strategy is to make things easy to even get n00bs into Saturn dev. And I succeeded as I had contact with a couple of n00bs recently. But if I would have told them to do everything from scratch, none of them would make any contribution to the Saturn homebrew scene.

I do have much respect for people doing things without SGL or even without SBL. The point is just: a Saturn dev n00b is not necessarily an experienced programmer.

[post=141363]Quoted post[/post]​

Rockin-b has been a lot of help. I am a Saturn dev n00b and I have no real experience programming other than my C/C++ classes a few years ago, and now Java and C# classes. I am entering myself in the c4 contest in order to get experence with programming for the saturn. Once I have more experence I would love to avoid using the SGL and SBL. I even managed to do a few things myself.

 

[Quick Man]

I actually agree with Piratero to a large extent - it's a severely good idea to avoid Sega's own libraries since the documentation is poor and implementation is variable, as Rockin-B's experiences with the depth cueing will attest.

I'm looking to wean myself off the stock libraries as soon as possible. Ideally we'd have an opensource development library developed by users here, I think.

 

[mrkotfw]

i haven't met anyone who started writing complex demos, tools, or anything that requires months/years of experience. i am not a good programmer myself, but avoiding the "difficult" tasks is not good at all. what if people found math, or any other subject difficult? would you prefer to dumb it down so it'd attract more people? i'll add a just so i won't sound too negative

I actually agree with Piratero to a large extent - it's a severely good idea to avoid Sega's own libraries since the documentation is poor and implementation is variable, as Rockin-B's experiences with the depth cueing will attest.

the documentation is probably the only thing i'd be okay using even though its just as bad as using the libraries. you actually agree with me? :cheers

 

[RockinB]

Yeah, the docs are good but sometimes outdated because the newer japanese docs haven't been translated. Maybe someone should do this...

 

[mrkotfw]

what is actually missing?

 

[CyberWarriorX]

Yeah, the docs are good but sometimes outdated because the newer japanese docs haven't been translated. Maybe someone should do this...

And where are these newer japanese docs anyways? I've been looking for them myself with no results.

Cyber Warrior X

 

[RockinB]

Originally posted by CyberWarriorX@Sat, 2005-11-05 @ 10:18 PM

And where are these newer japanese docs anyways? I've been looking for them myself with no results.

Cyber Warrior X

[post=141398]Quoted post[/post]​

Included in the SGL distribution in folder

sgl302j/DOC/300_JPN/

New SGL features like real time gouraud and depth cueing (and surely others as well) are not covered by old 210A_US docs.

 

[CyberWarriorX]

Ah, somehow I thought you meant the actual hardware docs. Actually, one thing I've noticed is that 3.02 wasn't even the last version used. It almost looks like there were a few other major changes done to the SBL/SGL after that. For instance, in a few newer jap games(from 1998 and later) it looks like a more sophisticated BUP library was done among a few other things, like GFS and CDC updates and probably more.

Cyber Warrior X

 

[RockinB]

Originally posted by CyberWarriorX@Mon, 2005-11-07 @ 04:51 AM

Ah, somehow I thought you meant the actual hardware docs. Actually, one thing I've noticed is that 3.02 wasn't even the last version used. It almost looks like there were a few other major changes done to the SBL/SGL after that. For instance, in a few newer jap games(from 1998 and later) it looks like a more sophisticated BUP library was done among a few other things, like GFS and CDC updates and probably more.

Cyber Warrior X

[post=141435]Quoted post[/post]​

How can you determine these changes? Did you used this tool (you made?) to look for SBL/SGL usage in binary executables?

 

[CyberWarriorX]

How can you determine these changes? Did you used this tool (you made?) to look for SBL/SGL usage in binary executables?

Using a disassembler and comparing code between libraries. It also helps too that the GFS, STM and CDC libraries contain version strings(although CDC doesn't always). The newer BUP library contains a version string as well.

Cyber Warrior X