G2 External Bus
(last updated August 25, 2003
The authors of this page disclaim all liability associated with the
information contained. If you use this information, it is AT YOUR OWN
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
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
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.
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:
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
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?? :)