SegaXtreme

Home	Forums	What's new	Resources

Parallel port AR mod

ExCyber - Dec 13, 2003

		ExCyber		Dec 13, 2003
			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...

		dhau		Dec 13, 2003
			Hi ExCyber, I have SuccessCompu's N64 Parallel Port Adaptor.... This adapter is sold for use with CD64 backup unit for Nintendo 64, however, originally CD64 was designed to work with PC Comms Link card. I think it's a commercial variation of famous FreeWing interface. I think it'll cost more to build freewing at home. Another thing: I'm not sure, but I think PC Comms Link and normal PC Parallel Port use different voltage levels (3.3v vs 5v), so you'll need to use some sort of converter chip. But I'm dumb in hardware, so don't trust this info, just doublecheck the voltage levels before plugging AR in PC Parallel Port

ExCyber

Dec 13, 2003

	
	
		
		
			I think it's a commercial variation of famous FreeWing interface.

It's not, unless the CD64 supplies power on the comms port (if it does, I'd like to know which pin(s) it's on...). It's probably a passive adapter that isolates the parallel port signals from grounds in the CD64 and relies on the software to make sure everything is done correctly. I doubt it would work with an AR cartridge. It's not an exaggeration to say that the Free Wing I/F is basically an entire comms link card with a parallel port interface in place of the ISA interface. I was going to build one but changed my mind because I didn't want to have to deal with the issue of a power supply (I've got enough transformers plugged into my walls already, don't need to add another).

	
	
		
		
			I think it'll cost more to build freewing at home.

The chips needed for the Free Wing I/F are actually pretty inexpensive ($10 or so if you're buying from an overpriced supplier, $5 or so from a good one).

Anyway, I thought it would be better to implement it as a modification to the AR. This eliminates the need for an external power supply, doesn't need 2 DB25 connections (can keep overall signal path shorter + fewer connectors -> more reliable), and if I play my cards right it could be EPP-compatible (easier to write host software/driver, faster). All this for 3 (at worst; I'm real close to cramming into 2) chips and a bit of rewiring.

		Destop		Dec 24, 2003
			Ive built both the Freewing and exstand adapter and have had better luck with exstand for the saturn. GSCC the game training program works pretty decent except if u try to dl big chunks of ram itll timeout. Ive played with Charles 'sat' util and got it to read ram reliably but have yet to get it to run code. I might be getting lots of noise on the cable coz I notice that the saturn sends a checksum at then end of the transmission and most of the time the checksum is bad. Im sure circuit can be simplified more like you said,just have to do more work on the pc side driving it. Let me know how it comes along and ill be glad to help test the thing coz i really want to get a decent homebrew link setup on the saturn. And you dont have to worry about wallworts, I just did like everyone else and tapped off a 5V line in side the cart and ran it to the unused pin 13 of the DSUB connector.

		madmalkav		Jan 13, 2004
			Destop, you know any web I can get info about exstand in non japanese language? thx.

		runderwo		Feb 2, 2004
			The CD64 PPA gets power from the PC parallel port. You can look at the schematic and judge for yourself whether it will work with the PAR circuit/software. http://n64.icequake.net/doc/cd64-ppa/paral...ortad... There are two errors in the schematic that I know of, both are documented there.

		seal1		Apr 13, 2004
			hello ExCyber, how is your project ? need something like your project coz my new mainboard has no longer a ISA-slot. ciao seal1

		ExCyber		Apr 13, 2004
			It's on hold for the moment, as I don't have a place to work on it.

		seal1		Mar 22, 2005
			bump anything new ?

		ExCyber		Mar 23, 2005
			I wish. At the moment I'm without a working AR, so the whole AR hacking side of my project list is on hold.