Continuing the comm port discussion...

Well, this link was interesting, so why don't i see what i can do:


Here's the pinout of the port, or at least I think it is. Using a serial cable should allow you to trigger remote interrupts, which is a big plus. However, I've never even seen a link cable so there's not much chance of experimenting. (The MIDI interface would also be interesting to play with.)


If I read the schematic right, this means the Communications Port is actually plugged straight into the SCI bus of the SH-2, both master and slave... meaning it's most likely fully controllable. (I belive theres a SCI.c somewhere around the compiller)

The plug it's the main problem... but there are test pads 15, 16 and 17 on that schematic that, if they're consistent between board revisions (they're on my board as well), can be soldered to an adapter or to stick the whole device inside, adding a ordinary port.

The cable might be built for serial purposes with a MAX232, or, what I find more interesting, to USB if we add a TI3410 to the mix(I just requested some samples for it). Ti3410 has a RS232 conversion and 3 I/O pins and is programmable hence looks like a perfect solution.
Another option would be to use the controller ports, which should be usable as 7-bit parallel ports. The primary advantage of this method is that controller connectors and cables are easier to come by, just hack up a joypad.
While I won't say that's a bad idea, the controller ports are used by most software, and require configuration of the SMPC. The serial port would be more available for use.
Yes, there's that chance, but we would have to implement our own data retrieving process... The advantage of using the SCI is that we not only have a hardware implementation right in the processor, noone can blame me for blowing up their PC paralel port due to a badly built cable... besides, MAX232 are cheap nowadays, As the connectors seem to be ordinary parts, i'll look into a good source for them.
I suppose this is somewhat offtopic, but does anyone else think that this guy got the SCU and VDP1 mixed up? His "VDP1" implements the A-bus, and his "SCU" is marked with a part number that appears to place it in Hitachi's "Q2" graphics processor family...
isn't the rumoured link-cable what we need? i mean, snip it apart and see how to attach a standard serial plug. the cable shouldn't be that problematic but since the port seems to be almost directly connected to the CPUs testing might dangerours. f.e.: voltage too high -> buzz....

JJK! anyhow, the pinout really does help i think. shouldn't be that hard to write a SerialLoader.

BTW, what's this suppoesed to show? the CD-block?
Yes. I was thinking about looking for some interesting interconnections between the VCD card slot, the cartridge port, and the CD subsystem... it'll have to wait a bit though.
lets see...

wonder_k : The link cable only comes packed with a japanese BASIC package. Not only it's expensive, it's also rare enough for me to even think about trying to wreck one of those. Besides, the schematic looks pretty certain that it's the serial connections, and i'm tempted to agree with him, since each SH-2 has this very complex and enhanced serial interface it would be a waste not to use it. Add to that the 5V output and this is a perfect candidate to a serial port interface.

I'm trying first the (very basic) SCI library on this page:

built on those files:

- sci.c

- scidrv.s

- Makefile

- sci.h

That implements :

void sci_putstr(char* buff);

int sci_getchar(void);

If that fails, there are a couple of other options...

As for the scematics, he does claim to be working on pure guess. I suppose he figured VDP1 and VDP2 were closely numbered. Remember he provably never looked at the official documentation.
Originally posted by TakaIsSilly@Mar 14, 2003 @ 08:18 PM

The link cable only comes packed with a japanese BASIC package. Not only it's expensive, it's also rare enough for me to even think about trying to wreck one of those.

Lik-Sang are carrying Blaze cables for USD7.99 so it's not that expensive. No BASIC included, but you can make two interfaces from one cable.
Done some early designs for the link cable:

(geez, looks suspiciously like one of those cellphone cables.)

I DID NOT test this cable, so I really DON'T RECOMMEND building it. That said, Im going to build it. I found out the correct SSR registers and i'm editing the files i got to conform to SH7604.
Cool. I've thought about combining this with a couple other enhancements if I can set up a decent place to solder...
As both my Saturns are dead (and I just lifted a track from the mainboard of one of those, out of pure frustation, autch - nothing to do with this cable, BTW), I won't be able to test for a couple of days, so here's a tiny Saturn binary file I rigged up to test the device. This should send "Hello World!" to the comm port once after you press Start - Assincronous, 8-bit + 1 Stop, No Parity. I don't know at what speed the port is setup, provably it's some ludicrous speed if the bios hasn't init it, but at least it should give some garbish:
The darned machines are turning on us >_<. Looks like they don't like their inhards tinkered mutch. Makes me wonder if i should power the MAX232 using the port...

Also, Ex, were are the darned connectors in the Digi-Key Catalog? I've been digging tru and I can't find it anywere...
Oh, those. The man from USP went to my house this morning, so I already have three samples to play with. As for the connector, I'll drag a Saturn to the hardware store and hope for the best.

Tonight I'll make a decent upload/download test binary, tomorrow I'll buy the hardware... Given college work and a some midtern stuff to handle, later this week we should get results.
Been designing the interface for uploads. Will look something like this, bugs by Toss fixed


As for the cable it's pending on getting a new Saturn in the next days.
Making some dumb work while waiting : Here's a simple interface for programming the serial port. You can use it to code for the ordinary link cable! Have them both sci_init() at the same baud rate, and data will transfer between machines.

I didn't added info with the files, use the included Makefile to complie, and then move scidriver.o, sci.h and sci.o to your current program. Here's what the functions do, if they're not very explicit.

void sci_init(char baud);

Inits the SCI port with an asyncronous protocol. you can pick the baud rate between 1200 and 38400.

void sci_putchar(char data);

Sends data tru the port.

void sci_putstr(char* buff);

Sends a whole string of null-terminated data.

int sci_getchar(void);

Retrieves a byte from the port. Sorry about the int, cast it to a char or modify it yourself ^^;

They're not tested on the real thing, but Satourne and GiriGiri seem to respond positively.
Dumb Question (and largely off topic) Time: Which one is the comm port?

From the drawings it looks like the cartridge port, which if I'm not mistaken is a parallel interface. So that means the serial interface is the......? controller port? vcd card port?

I'm asking this because as I'm coding my Save Game Copier (for the contest), I've come across a number of functions which work for multiple devices.

An example is the BUP_Write(Unit32 device, Uint32 datasize, BupStat *stat)

where device number is:

0 = internal memory

1 = memory cartridge

2 = serial interface

Sounds pretty interesting to me. Perhaps Sega was planning to have a dex drive sorta linkup?

Oh yeah and impressive screen shot Taka