Pro Action Replay software ?
- Thread starter TmEE
- Start date
TmEE said:I have been looking for PC side software to manage the Saturn PAR but I've been unable to find any...
I'm particulary interested in the ACTION.EXE, which you can use to transfer save data according to Charles MacDonald
does anyone have something left ?
Don't forget also that you need some hardware to interface your cartridge to the PC. You will need the ISA-bus based COMMS CARD in order to use the software in the previous post.
I make a USB-based solution, also, if you're interested. You can find more info at http://www.gamingenterprisesinc.com/
There is a parallel port adapter schematic here in PAR_HARD.LZH. From what I remember this design is pretty similar to the ISA one, except for the multiplexer; this adapter is designed for SPP mode, so nibblewise communication is used to transmit the PAR->PC latch contents. The pinout might tempt you to try a passive adapter, but the protocol is not friendly to that approach. The Saturn/PSX side controls both the bus direction and the valid window of the PAR->PC response byte, and there is no signal for the PC to delay either one - the protocol is designed to write directly into a latch without PC-side intervention.
Unfortunately, I don't know of a single source for all of the relevant info. Charles MacDonald has some info spread across his EMS AR doc and his comms protocol doc, and there's the waveform diagram in the Free Wing package. I also poked around with a multimeter some years ago. I'll try to piece it together here (some details are from memory and could be wrong):
There are 4 chips on the PC comms card:
- One 74374/574 8-bit tri-state flip-flop (stores the PC->PAR byte)
- One 74373/573 8-bit transparent latch (stores the PAR->PC byte)
- One 7474 dual flip-flop (stores the "waiting for response" status flag / the state of STB)
- One PAL/GAL chip to decode the port addresses and otherwise glue things together.
(The PAL/GAL might be overkill for what was actually implemented; the Datel card looks like they tried to implement an interrupt-driven mode, but this isn't documented anywhere and I don't know of any software that uses it)
The interface presented to the PC is two I/O port addresses: a data port and a status port, typically at $320 and $322 respectively, but jumpers on the card can move them to $300/$302, $310/$312, or $330/$332.
An exchange basically goes like this:
The PC application writes a byte to the data port. This sets the contents of the PC->PAR flip-flop and causes STB to go high, indicating to the PAR that a byte is available. It also sets the PC-side status flag (essentially the same thing as STB), indicating that a response has not been received yet. The application spins until the status flag goes low again or until a maximum timeout period.
The PAR reads the sent byte, then writes a response byte. This causes /ACK to go high and then low (I think it's just a buffered version of the write pulse from the CPU).
The /ACK pulse does three things:
1) Disables the output of the PC->PAR flip-flop for the duration of the response write (i.e. it's connected to /OE of the PC->PAR flip-flop, and the fact that it's high disables the output)
2) Causes the PAR->PC latch to latch the response byte (i.e. it's connected to LE of the PAR->PC latch, and the falling edge causes the response byte to be latched)
3) Clears STB/status (I don't remember how this is done; might go through the PAL)
The PC application sees that the status flag is cleared and reads the data port, returning the contents of the PAR->PC latch.
If you really need verification of the hardware details, I might be able to find my comms card and throw it on the scanner, but that won't give you the PAL contents...
You might also find this interesting.
There are 4 chips on the PC comms card:
- One 74374/574 8-bit tri-state flip-flop (stores the PC->PAR byte)
- One 74373/573 8-bit transparent latch (stores the PAR->PC byte)
- One 7474 dual flip-flop (stores the "waiting for response" status flag / the state of STB)
- One PAL/GAL chip to decode the port addresses and otherwise glue things together.
(The PAL/GAL might be overkill for what was actually implemented; the Datel card looks like they tried to implement an interrupt-driven mode, but this isn't documented anywhere and I don't know of any software that uses it)
The interface presented to the PC is two I/O port addresses: a data port and a status port, typically at $320 and $322 respectively, but jumpers on the card can move them to $300/$302, $310/$312, or $330/$332.
An exchange basically goes like this:
The PC application writes a byte to the data port. This sets the contents of the PC->PAR flip-flop and causes STB to go high, indicating to the PAR that a byte is available. It also sets the PC-side status flag (essentially the same thing as STB), indicating that a response has not been received yet. The application spins until the status flag goes low again or until a maximum timeout period.
The PAR reads the sent byte, then writes a response byte. This causes /ACK to go high and then low (I think it's just a buffered version of the write pulse from the CPU).
The /ACK pulse does three things:
1) Disables the output of the PC->PAR flip-flop for the duration of the response write (i.e. it's connected to /OE of the PC->PAR flip-flop, and the fact that it's high disables the output)
2) Causes the PAR->PC latch to latch the response byte (i.e. it's connected to LE of the PAR->PC latch, and the falling edge causes the response byte to be latched)
3) Clears STB/status (I don't remember how this is done; might go through the PAL)
The PC application sees that the status flag is cleared and reads the data port, returning the contents of the PAR->PC latch.
If you really need verification of the hardware details, I might be able to find my comms card and throw it on the scanner, but that won't give you the PAL contents...
You might also find this interesting.
That information you just provided is total awesomness. I'll try to work out a schematic based on it and few other things, and hopefully it would be a working design 
Scans of the card can and will help a lot, it would be highly appreciated. I'm not too worried about PAL contents, I'm quite handy with logic chips and if I have enough info, I will be able to figure something out in most cases
Scans of the card can and will help a lot, it would be highly appreciated. I'm not too worried about PAL contents, I'm quite handy with logic chips and if I have enough info, I will be able to figure something out in most cases
Okay, managed to find it. The scans are a little goofy (the scanning software and/or scanner seems a bit crappy), but the traces seem to be reasonably visible. One thing to note is that both of the latches are 74HC373s; I was apparently remembering the Free Wing interface rather than the comms card in that respect. Let me know if you have any other questions.
http://img269.imageshack.us/gal.php?g=datelpcclparts.jpg
http://img269.imageshack.us/gal.php?g=datelpcclparts.jpg
antime
Extra Hard Mid Boss
$3x0 is the data port and $3x2 is the status port. To transfer data, execute the following sequence (taken from Charles MacDonald's satutil program):
Code:
uint8 comms_exchange_byte(uint8 value)
{
outp(comms_port, value);
while (inp(comms_port + 2) & 1);
return inp(comms_port);
}I think I should point out, for anyone not proficient in C, that the line
doesn't apply to the following line; it's a complete while loop with a null statement as the loop body (due to the presence of the semicolon), so it just waits for the condition to become false. This is one of those syntactical subtleties that can be used to make concise programs, but that makes C neophytes tear their hair out.
Code:
while (inp(comms_port + 2) & 1);doesn't apply to the following line; it's a complete while loop with a null statement as the loop body (due to the presence of the semicolon), so it just waits for the condition to become false. This is one of those syntactical subtleties that can be used to make concise programs, but that makes C neophytes tear their hair out.
Similar threads
