HomeForumsWhat's newResources 
 
 
Pro Action Replay software ?
TmEE - May 26, 2009
  TmEE May 26, 2009
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 ?

 ExCyber May 26, 2009
Try here.... Note that the Datel and EMS software aren't fully compatible; the save-sending function might be compatible, but I never tried it.

 TmEE May 28, 2009
ok thanks for the link, lot of useful stuff there


I have a Datel AR cart BTW

 gameofyou1 May 29, 2009

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/...

 TmEE May 29, 2009
Are the COMMs card's schematics available anywhere ? I'd build one, or at least poke one on an existing ISA card. USB is something I'm not really interested in.

 ExCyber May 29, 2009
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.

 TmEE May 30, 2009
The way how communication happens makes things more complicated.... at least now I have the ROM images of the PAR so I could work out my own dev cart once I get that far.


I'm trying to locate some info and pics of the comms card, but so far without any meaninfgul success :/

 ExCyber May 31, 2009
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.

 TmEE May 31, 2009
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

 ExCyber May 31, 2009
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=datelpcclpar...

 TmEE Jun 1, 2009
These are some nice pics


I'll try to work out something in nearer future, probably at work since I hav nothing too much to do there

 TmEE Jun 4, 2009
I have a question, the card uses 2 addresses (well, 4). 3x0 (+3x1), 3x2 (+3x3), what do they do ?

 antime Jun 5, 2009
$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);

}

  ExCyber Jun 5, 2009
I think I should point out, for anyone not proficient in C, that the line


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.

 TmEE Jun 7, 2009
My C knowledge sucks, and if I understood correctly, the first bit is what matters in the status port, right ?

(I'm ASM and QB45 guy, lol)

 ExCyber Jun 7, 2009

TmEE said:
My C knowledge sucks, and if I understood correctly, the first bit is what matters in the status port, right ?

(I'm ASM and QB45 guy, lol)


Right. I would guess that the others either always return 1 or depend on the bus cycles in some weird way.