I don't know how many hardware-oriented folks are here, so I don't know how useful this post will be, but...
I'm getting kind of tired of burning CDs for all my testing, so I'm hoping to modify my AR to be usable with a standard ECP/EPP parallel port. This involves mitigating certain weirdnesses in the commslink protocol, particularly related to bus turnaround. A normal commslink transaction seems to go something like this:
1) PC asserts STROBE and drives a byte on the data bus
2) AR detects asserted STROBE and reads the byte
3) AR pulses ACK and drives a response byte on the data bus
4) PC latches the byte and deasserts STROBE
What makes the whole exercise somewhat tricky is that there is no interlock step between 2 and 3 that can be used to have the PC turn the bus around. On a comms link card, the ACK signal directly suppresses the output of the PC->AR latch and loads an AR->PC latch. Since the timing of ACK is controlled by the AR, and corresponds to both an acknowledge and a bus turnaround, a parallel port host program has no way to disable the output drivers between stages 2 and 3 of the exchange to prepare for the AR to drive the bus.
Currently my plan is to do the following:
- Remove the DB25
- Isolate pins 14-17 (they are connected to ground).
- Install a female DB25 (optional of course; my shortest cables are male-male and I prefer hosts to have the more durable female connectors)
- Lift the /E pin from the 74HC245 buffer in the AR cart and wire it to a 74HC00 like so that /E = old /E NAND A-Bus /read
WARNING: For anyone out there feeling adventurous, I screwed this up - this will most likely result in frying your parallel and/or commslink port.
- Add a 74HC574 to latch the AR->PC byte, with L connected to AR ACK and /E = (NOT ADDRSTB) AND WRITE
- Move AR ACK from pin 11 to pin 10 of the DB25 to connect it to PC ACK
Hopefully, this will result in a more parallel port friendly (if slightly slower) protocol:
1) PC asserts WRITE and drives a byte on the data bus
2) AR detects asserted WRITE and reads the byte
3) AR pulses ACK and writes a response byte to the '573 (the comms bus is not driven because an A-bus /read signal is not generated to enable the '245)
4) Deassertion of AR ACK signal causes interrupt on PC (AR ACK is active high, PC ACK triggers an interrupt on a falling edge)
5) PC deasserts strobe and performs bus turnaround
6) PC asserts ADDRSTB (enabling the latch) and reads the latched byte from the AR.
The signal names here are EPP signal names. The traditional signal name and correspondence is:
WRITE = STROBE = Pin 1
DATASTB = AUTOFEED/AUTOLF = Pin 14
ADDRSTB = SELECT IN = Pin 17
ACK = INTR = Pin 10
I might hold off a bit longer and see if I can figure out a way to generate an EPP-compatible WAIT signal from ACK. This would make the interface a bit faster. However, it would also require inverting the WRITE signal, since the AR STROBE signal is active high and the EPP WRITE signal is active low. Non-EPP accesses can always control the state of STROBE manually, so this isn't a problem for normal usage.
edit: after reviewing some of the EPP mode info, it looks like the ACK signal itself may act as a usable EPP WAIT signal. New plan (pending some validation, there's solid potential for a snag or two) is to produce an EPP-compatible interface.
With any luck, this will produce:
EPP write (data or address): PC -> AR write
EPP address read: reads the AR response byte from the '573
EPP data read: hang/timeout (can't win 'em all with just a single 7400...)
And no need to wrestle with parallel port interrupts. 🙂
The idea is that this opens the door for easier driver writing (EPP handshakes are hardware-controlled so you don't have to twiddle individual control lines in your driver) and if an AR firmware replacement ever comes around we could potentially have a kicky fast burst transfer mode.
The subtitle says "request for comments", so...
Any comments/suggestions/corrections? 🙂
References:
Charles MacDonald's commslink doc: on his site, in the Sega Saturn section
Warp Nine Engineering's EPP mode document
Free Wing's parallel port commslink adapter package
Gamestation X's Hardware Book mirror
I'm getting kind of tired of burning CDs for all my testing, so I'm hoping to modify my AR to be usable with a standard ECP/EPP parallel port. This involves mitigating certain weirdnesses in the commslink protocol, particularly related to bus turnaround. A normal commslink transaction seems to go something like this:
1) PC asserts STROBE and drives a byte on the data bus
2) AR detects asserted STROBE and reads the byte
3) AR pulses ACK and drives a response byte on the data bus
4) PC latches the byte and deasserts STROBE
What makes the whole exercise somewhat tricky is that there is no interlock step between 2 and 3 that can be used to have the PC turn the bus around. On a comms link card, the ACK signal directly suppresses the output of the PC->AR latch and loads an AR->PC latch. Since the timing of ACK is controlled by the AR, and corresponds to both an acknowledge and a bus turnaround, a parallel port host program has no way to disable the output drivers between stages 2 and 3 of the exchange to prepare for the AR to drive the bus.
Currently my plan is to do the following:
- Remove the DB25
- Isolate pins 14-17 (they are connected to ground).
- Install a female DB25 (optional of course; my shortest cables are male-male and I prefer hosts to have the more durable female connectors)
- Lift the /E pin from the 74HC245 buffer in the AR cart and wire it to a 74HC00 like so that /E = old /E NAND A-Bus /read
WARNING: For anyone out there feeling adventurous, I screwed this up - this will most likely result in frying your parallel and/or commslink port.
- Add a 74HC574 to latch the AR->PC byte, with L connected to AR ACK and /E = (NOT ADDRSTB) AND WRITE
- Move AR ACK from pin 11 to pin 10 of the DB25 to connect it to PC ACK
Hopefully, this will result in a more parallel port friendly (if slightly slower) protocol:
1) PC asserts WRITE and drives a byte on the data bus
2) AR detects asserted WRITE and reads the byte
3) AR pulses ACK and writes a response byte to the '573 (the comms bus is not driven because an A-bus /read signal is not generated to enable the '245)
4) Deassertion of AR ACK signal causes interrupt on PC (AR ACK is active high, PC ACK triggers an interrupt on a falling edge)
5) PC deasserts strobe and performs bus turnaround
6) PC asserts ADDRSTB (enabling the latch) and reads the latched byte from the AR.
The signal names here are EPP signal names. The traditional signal name and correspondence is:
WRITE = STROBE = Pin 1
DATASTB = AUTOFEED/AUTOLF = Pin 14
ADDRSTB = SELECT IN = Pin 17
ACK = INTR = Pin 10
I might hold off a bit longer and see if I can figure out a way to generate an EPP-compatible WAIT signal from ACK. This would make the interface a bit faster. However, it would also require inverting the WRITE signal, since the AR STROBE signal is active high and the EPP WRITE signal is active low. Non-EPP accesses can always control the state of STROBE manually, so this isn't a problem for normal usage.
edit: after reviewing some of the EPP mode info, it looks like the ACK signal itself may act as a usable EPP WAIT signal. New plan (pending some validation, there's solid potential for a snag or two) is to produce an EPP-compatible interface.
With any luck, this will produce:
EPP write (data or address): PC -> AR write
EPP address read: reads the AR response byte from the '573
EPP data read: hang/timeout (can't win 'em all with just a single 7400...)
And no need to wrestle with parallel port interrupts. 🙂
The idea is that this opens the door for easier driver writing (EPP handshakes are hardware-controlled so you don't have to twiddle individual control lines in your driver) and if an AR firmware replacement ever comes around we could potentially have a kicky fast burst transfer mode.
The subtitle says "request for comments", so...
Any comments/suggestions/corrections? 🙂
References:
Charles MacDonald's commslink doc: on his site, in the Sega Saturn section
Warp Nine Engineering's EPP mode document
Free Wing's parallel port commslink adapter package
Gamestation X's Hardware Book mirror