Disclaimer

The authors of this page disclaim all liability associated with the information contained. If you use this information, it is AT YOUR OWN RISK.

Intro

There's been a great deal of documentation about the software internals of the DC, but not a whole lot about the G2 Bus external connector, as I've come to rename the "parallel port" or "external port", among other names. The reason for this name change will become obvious shortly.

As I've now built two separate devices to attach to this bus based on various docs around the net (primarily those of bITmASTER), I've come to learn a bit more about the nuances of this beasty and decided to document it more thoroughly in case anyone else is thinking of taking the plunge and building some custom DC add-ons.

The External G2 Bus

My friend Andrew and I fired up his logic analyzer tonight, hooked it up to the external port, and discovered something very interesting -- the BIOS was chatting with it when there was nothing attached! After some more careful examination of the actual bits being captured it became quite obvious what was going on -- the SH-4 was talking to the sound processor, which of course is also located on the G2 bus (like the external port). All sorts of interesting things began to click once this connection was made.

It was fun to watch the data streaming by, knowing exactly what the thing was doing. First came a huge burst of data to upload the ARM7's program into its RAM (with ARM instructions clearly visible in the data). Then the sound that is played at startup itself. Finally, the SH-4 carried on a conversation with the SPU to watch the playback itself. After the sound was finished, everything quietened down for several seconds, and the Katana-based bios software started reading the RTC on the SPU. This was clearly visible as reads from 0x00710000, returning increasing values (about once per second).

Unfortunately we still didn't have enough time to fully understand what was going on (and we seemed to be missing 16 of the 32 bits of the address and data...?!) but it was interesting to see. I still wonder if there is some way to exploit this to execute code without a boot CD or flash replacement.

This also makes it clear how peripherals (e.g., modem, BBA, etc) attach themselves to various areas of memory. My guess is that the ASIC simply passes through various memory region accesses directly onto the G2 bus.

It's still unknown if custom hardware attached to the G2 bus will ignorantly interfere with the communications with the sound processor (the signals seemed to act funny) but so far it seems there is no conflict.

As stated elsewhere, the "official" address of the G2 external port is 0xb4000000 in SH-4 memory space. Addresses used here will talk directly to an external device as expected.

PCI, Interrupted

Back to the subject at hand... the external G2 bus is a fairly simple multiplexed address/data bus. This is very much like PCI, except that it is 16 bits wide instead of 32. The signaling is fairly similar -- there is a steady clock signal at 25MHz (presumably the system's bus clock divided by 4), a direction line, an address enable and a data enable, and 16 A/D shared lines. There is also an IRQ pin which presumably is capable of triggering an interrupt on the SH-4.

I will eventually get around to producing some proper pinouts and timing diagrams, but here is a basic text-based pinout:

  ---\ 1
2 |  |
  |  | 3
4 |  |
  |  | 5
  ...
  ---/ v-- back of DC

1-4    - +5V
5      - ?
6      - -IRQ
7-9    - ?
10-12  - GND
13     - ?
14     - DIR
15     - ?
16     - -DATAEN
17-19  - +3.3V
20     - ?
21     - -ADDREN
22     - ?
23,24  - GND
25     - A/D 15
26     - A/D 14
...
40     - A/D 0 (perhaps just D0)
41,42  - ?
43     - CLK
44,45  - GND
46     - ?
47,48  - GND
49,50  - ?

-SIGNAL = active low

Most of the lines should be pretty self-explanatory. When ADDREN is active, the A/D lines are set to an address, and DIR is set to a direction. These values must be latched. DATAEN is then set active, and the DC reads the A/D lines for data (DIR low) or places data on them (DIR high). This pattern is repeated for each read or write cycle. CLK strobes a steady 25MHz as long as the DC is powered on.

All of the above info is tentative, and was obtained by reverse engineering (mostly by bITmASTER). Please do not trust anything valuable to it!

Making custom peripherals

I'm assuming that anyone who hits this page is either curious or wants to actually build their own peripheral devices. All of the schematics that have been designed to date (and tested) are built in the following manner:

The A/D lines (as many of them as you want to handle) are connected to some 74574s (HCT or ACT is preferable, HC/AC at the least), with an inverted ADDREN connected to CLK on the 574. DIR must also be latched here. This will cause the 574s to latch the address requested and the DIR signal whenever ADDREN is toggled active.

The A/D lines should also be connected to a set of 74245s. These are tri-state buffers. The ENABLE for these chips should be activated whenever the DATAEN signal is active. DIR is determined from the latched DIR signal. Thus whenever a data cycle is in progress, either the device's data signals will drive the A/D lines, or the DC's data signals (from A/D) will drive the device's data lines.

Anything else you want to do is up to how you want to design it, and what the device's requirements may be. For example, if one wanted to build a PCI bus that actually operated to spec (33MHz CLK minimum), one would need to add an oscillator for the 33MHz clock, and do some weird FIFO buffering to talk to the DC side of things. Not very simple. ISA is much simpler (and thus IDE, which just attaches as a subset of ISA) -- you just have to demux the A/D signals and apply them to the appropriate places. If you want to get fancy, you could add decoding that sets up part of the address range as I/O port access, and part of it as memory access. All current designs allow only I/O access since this is sufficient for about 99% of the peripherals one would want to use with a DC. (Why would you want a second video card?? :)