Some informations about ExSTAND ?

[cafe-alpha]

Hello, I would like to connect my Saturn to my PC, but unfortunately, my DataLink doesn't seems to work.

As a workaround, I plan to build a Freewing.

After purchasing the required parts for it, I discovered the "yano/ExSTAND", and I would like to know more about it.

Here are my questions :

1. Is there any description about the ExSTAND transmission protocol ?

I would like to write a satutil-like program for the ExSTAND, but I couldn't found information/sample code/etc about ExSTAND.

By the way, I could find in this topic some programs that should work for the ExSTAND. Programs can be downloaded here, but source code are not provided.

Is there any chance to get the sources of theses programs ?

The author of theses programs (seal1) says he needs the agreement from TyRaNiD before releasing the SaturnDebugger source.

As far I know (=thanks to google), TyRaNiD in this forum seems to be TyRaNiD on http://forums.ps2dev.org/, and his email is written somewhere in this page.

I would be very glad to use an ExSTAND instead of a freewing, because the transfer speed seems twice better !

2. I could read about the freewing/ExSTAND that the shorter the cable is, the better the transmission is.

I agree to this, but ... what is a reasonable cable length in this case ??

I plan to use a 50cm long old parallel extension : PC<->PCB = 25cm and PCB<->ARP = 25cm. Is it reasonably short ?

 

[BrokenLizard]

I use the 35 inch parallel cables that came with Iomega's Zip drives. These cables have never given me any problems and they are available for around $10 on Ebay. When selecting a cable, I would be more concerned with quality than length. Many older cables were not properly shielded and are far more susceptible to noise. When building the adapter, it would probably be best if one end directly connected with either the ARP or your computer.

Have you tried determining the protocol from the schematic? If you have experience with digital logic circuits, working with the Yano/Exstand adapter schematic will be quicker than finding and understanding pre-existing source code. The waveforms and documentation available for the FreeWing adapter combined with Charles MacDonald's "Comms Link hardware notes" file may provide some assistance.

 

[antime]

Yano's Virtual Pro Comms Link Driver comes with assembly-language sources for both the ExSTAND and FreeWing interfaces.

 

[cafe-alpha]

BrokenLizard and antime, thanks for you anwers.

My new freewing I tested yesterday seems to work

But transmission is very noisy ^^; , especially when writing data.

Have you tried determining the protocol from the schematic? If you have experience with digital logic circuits, working with the Yano/Exstand adapter schematic will be quicker than finding and understanding pre-existing source code. The waveforms and documentation available for the FreeWing adapter combined with Charles MacDonald's "Comms Link hardware notes" file may provide some assistance.

Yano's Virtual Pro Comms Link Driver comes with assembly-language sources for both the ExSTAND and FreeWing interfaces.

The main purpose of building an ExSTAND/Freewing is to check if the communication between my Saturn and PC work or not.

I would like to know which one(s) between my PC/Saturn/USB DataLink/ARP doesn't work ... and I also want to record my backups on my PC

.

Unfortunately, I am by far not a wizard in electronics and assembly language, so that I prefer not to get stuck in reverse-engineering schematics or translating assembly sources to C.

That's why I choosed to build a freewing, because I could find pre-existing communication code for it (here) :

I use the 35 inch parallel cables that came with Iomega's Zip drives. These cables have never given me any problems and they are available for around $10 on Ebay. When selecting a cable, I would be more concerned with quality than length. Many older cables were not properly shielded and are far more susceptible to noise. When building the adapter, it would probably be best if one end directly connected with either the ARP or your computer.

It is a good idea ! Thanks to it, I wired both connectors with 2 short ribbon cables, and I keep my parallel extension cable as-is.

Hence, I can choose to use the extension cable between PC <-> freewing, or between freewing <-> ARP.

 

[cafe-alpha]

I got a question :

I download backup data from my Saturn, and the transfer ends successfully.

Just after that, I re-download backup data ... its contents shouldn't shouldn't have changed, however, the file I receive is different from the first one !

Moreover, I did this test 100 times, and all the files are different !! (see all the files here)

In order to download data, I use a modified version of Charles MacDonald's satutil program.

I download data by chunk of 32 bytes. If a checksum error happens in a chunk, I send null characters until receiving `OK', and I restart download.

Maybe the problem is due to the fact that it doesn't seem possible to check that download parameters (address+length) were correctly sent ... or maybe not.

Does somebody can do the same kind of test ?

1. download backup data twice (or more).

2. compare each file (for example, by comparing their md5sum).

 

[BrokenLizard]

What is the frequency of checksum mis-match? Downloading 65,536 bytes in 32 byte chunks results in 2048 separate read operations. The transfer method you described involves a simple 8bit summing checksum, which offers very little protection. There is a 1 in 256 chance that the checksum will incorrectly match, resulting in corrupted data.

Also, there may be a small bug in SatUtil's par_dump_memory function. The checksum variable is being used without having been initialized to a known value. Depending on the compiler and compiler settings, this may result in erroneous checksum values.

Try downloading a 1,024 byte block of data all in one chunk. If everything is working correctly, you should be able to successfully read the data many times in a row. If you cannot, then there may be too much noise on your data lines or one of the links in your setup is generating random data. Additionally, try to copy one of the game save files from Slinga's Save Game Copier program to your Saturn. In the ISO file, you can find the individual game save files. This will provide an easy means of comparing if the data being read is correct or corrupt.

If noise is the culprit, there are a number of items you can try.

1. Reduce the length of the wires coming out of your FreeWing adapter. Try mounting at least one of the DB25 connectors directly on the perfboard and plugging the adapter directly into the ARP.

2. Shorten the wires connecting IC pins on your board.

3. Try adding a bypass capacitor to each IC on your board. These capacitors should be as close as possible to the chip's power pins.

4. Make sure you are using either HCT or HC parts. Other logic families will not work.

5. Rewire long sections of ribbon cable so that every other conductor is ground.

6. Repeatedly copy a save file back and forth between the ARP and system memory. If your ARP is damaged or not making a good connection with the cartridge connector, the save file will become corrupted. It is possible that the ARP is damaging the data before it is even transferred to your FreeWing.

While I never use the adapter, I created a PCB when I assembled my FreeWing. The board is very small (about 2.5 inches by 2 inches) but uses fine-pitched surface mount parts. If you feel that you have the soldering skills required to assemble a FreeWing with this PCB design, I can send you one. I have 99 extras and since I use my USB to PAR adapter, I have no use for them. If you are interested, I can post pictures.

 

[ExCyber]

6. Repeatedly copy a save file back and forth between the ARP and system memory. If your ARP is damaged or not making a good connection with the cartridge connector, the save file will become corrupted. It is possible that the ARP is damaging the data before it is even transferred to your FreeWing.

I think this really only exercises the path from the system to the flash chips, which is probably not the issue if the firmware actually runs without crashing while every comms transfer is being corrupted (okay, it's actually running from RAM at that moment, but shouldn't the initial copy at boot screw up if there's an error that frequent?).

 

[cafe-alpha]

Hello, I'm sorry for this looong delay without reply.

I didn't wanted to post a reply before improving the situation.

About the progress : I actually gave up half of the problem : being able to handle communication with ARP's original firmware.

The problem I didn't gave up is to allow to enable communication with my Saturn

To achieve this, I build a Saturn library dedicated to transmission, so that I was free to design a custom transmission prototcol for my freewing.

Improvements compared with original ARP firmware :

- Open source ... when I will release it (= when it will be enough reliable).

- Very easy to use in homebrew application : 2 .c files to add to your project, one .h files to include, an `init' function to call at the begining of the application, and a `check' function to call before slSynch.

- Non-blocking transmission functions.

- Watchdog to prevent from being in an unstable state : when the program is in a non-idle state for a too long time, automatically return to idle state, so that in the worst case when you are "lost in transmission", you can reset the transmission by simply adding a `Sleep(1000);' in your PC communication program.

- In the `receive' function, changed the 8bits checksum by a 16bits CRC, so that you are almost sure that you will not receive incorrect data as a correct data. (Note : I first tried with a 8bits CRC, but I experienced some "false positive data").

- In each command (send, receive, etc), added a 16bits CRC (same as above), so that an error in command transmission will not crash your Saturn.

- Multi-device support ! For the moment, I support transmission with USB data link (implemented, however, not tested), comms card (implemented, however, not tested) and freewing. Adding support for other devices shouldn't be such a pain.

- Error recovery ! By using Reed-Solomon code, at most one byte erasure error can be recovered.

- faster than I expected !! before building my freewing, I thought that transfer speed was around 4KB/s (see here and here). But, reading speed is around 10~11 KB/s ! It is even faster than USB data link (^ ^)v

- It is possible to set the `check' function's polling loop count from PC, so that setting it to a high value before a transfer, then setting it to a low value after the transfer allows fast transmission speed as well as `check' function fast execution time when no transfer is done.

Todo (highest pririty first) :

- Add freewing `send' function. (actually, it is under development, see `*1')

- Add a "write data from RAM to ARP's flash" command. (in order to be able to easily upgrade ARP's firmware).

- Build a replacement firmware for Action Replay : at present time, Saturn executable size is, due to SGL, around 200KB, so in order to shrink the executable, I should need to build a SGL-free program.

- Add stream compression. -> Shouldn't be so difficult, and I already added the compression library + wrapper on the Saturn application. Need to add some commands to transmission protocol, and some improvement on the PC application.

- Add "get CRC" command (CRC is computed from Saturn and then sent to PC) in order to be completely sure that downloaded/uploaded data is correct.

- Add ARP chip autodetection in order to support any action replay, (as well as detecting if the ARP is connected or not).

- Build an user-friendly application : at present time, I am using a command-line based program for testing, but I also build a GUI program for testing compilation. Adding a "send" and "receive" button and a progress bar to it, and it should be OK. (well, it is optimistic; from my personal experience, GUI development have always been time-consuming ...).

- Add Charles MacDonalds "vdp1view" command in PC software.

- Add "dump ARP memory" command (-> save compressed backups stored by ARP firmware) in PC software.

- Add parallel port access support under Windows Vista/Seven.

Note : Parallel port access shouldn't work under Vista/Seven.

-> I use phymem for parallel port access, which doesn't seems to work under Vista/Seven. Parallel-port related functions are gathered in a separate .c file, so that it shouldn't be a difficult task to add support for other OS. The main problem is to have a PC under Vista/Seven for testing ...

I'm sorry I don't release all this stuff now, but I would prefer to release a bug-free version first. Especially, I don't want claim from people who received corrupted backup data because of my application.

Also, as I do this during my free time (= few hours during week-end, and sometimes before going to work), please be patient until the first release.

(*1) : I got some questions about writing data to Saturn.

Q1: In the case I want to execute a Saturn binary data : as the main Saturn executable that send/receives data (loaded from CD) is executed from 0x06004000 address, where should I upload another binary data ? Uploading from 0x06004000 overwrites the main executable, and then the Saturn hangs.

Q2: In the main Saturn executable, when executing binary dataI would like to execute data, I use the following ugly code.

typedef void (*Fct_exec)(void);

void execute(unsigned char* adr)

{

    Fct_exec fct = (Fct_exec)adr;

    fct();

}

In the "write data to Saturn function", I send sample Saturn executable data (mic's flatcube.bin, 9KB) from address 0x06001000, so that it won't overwrite existing code from 0x06004000.

Then, I do execute(0x06001000); , and it seems to freeze my Saturn.

Does anybody can confirm this code works or not ?

I am not very confident about this portion of code, that's why I post it here.

PS: If someone is interested into testing my freewing software, don't hesitate to PM me. For the moment, only Sat->PC read function seems to work.

You need a Saturn with modchip, a freewing device, and a PC under Windows XP.

What I would like to test :

- transmission with a freewing different than mine : especially, I want to know how much noise there is, and the maximum transfer speed.

- compatibility with other Saturn region. (only tested on a Japanese white Saturn).

Note to the forum administrator : can you change this topic's title to "Building my freewing device", please ?

Also, there may be a small bug in SatUtil's par_dump_memory function. The checksum variable is being used without having been initialized to a known value. Depending on the compiler and compiler settings, this may result in erroneous checksum values.

I actually noticed it, but I forgot to mention it.

In my environment, checksum was initialized to a nonzero value, so that it was easy to notice

Try downloading a 1,024 byte block of data all in one chunk. If everything is working correctly, you should be able to successfully read the data many times in a row. If you cannot, then there may be too much noise on your data lines or one of the links in your setup is generating random data. Additionally, try to copy one of the game save files from Slinga's Save Game Copier program to your Saturn. In the ISO file, you can find the individual game save files. This will provide an easy means of comparing if the data being read is correct or corrupt.

Well, I did some measurements about my freewing transmission quality, and I found that about 1.5% of the byte exchanges are ignored.

For example, Saturn send "abcdefg", but PC received "abcdfg" and a checksum error. This is the main reason I gave up trying to use original comms protocol.

(note to administrators : sgcopier.zip is a rar file with an incorrect extension ! I may be fine to change its extension.)

If noise is the culprit, there are a number of items you can try.

1. Reduce the length of the wires coming out of your FreeWing adapter. Try mounting at least one of the DB25 connectors directly on the perfboard and plugging the adapter directly into the ARP.

Unfortunately, when purchasing the electronics parts, I couldn't find a DB25 connector to mount directly on the perfboard (I found only wire type).

2. Shorten the wires connecting IC pins on your board.

If possible, I don't want to modify the hardware : I fear to break it and have to rebuild from start, and buiding it was painful enough !

Also, I don't want to break it, as I it is the only Saturn communication device I own. (I got an USB Data Link, but it doesn't works)

3. Try adding a bypass capacitor to each IC on your board. These capacitors should be as close as possible to the chip's power pins.

It was already done

When building the freewing, and acquaintance suggested me to add capacitors.

As there was no free space near the IC, I soldered them on the copper side of the perfboard, directly under the ICs.

4. Make sure you are using either HCT or HC parts. Other logic families will not work.

I am using "HC" type.

5. Rewire long sections of ribbon cable so that every other conductor is ground.

When I buit my freeing, I removed unused wires from my ribbon cables.

6. Repeatedly copy a save file back and forth between the ARP and system memory. If your ARP is damaged or not making a good connection with the cartridge connector, the save file will become corrupted. It is possible that the ARP is damaging the data before it is even transferred to your FreeWing.

I think this really only exercises the path from the system to the flash chips, which is probably not the issue if the firmware actually runs without crashing while every comms transfer is being corrupted (okay, it's actually running from RAM at that moment, but shouldn't the initial copy at boot screw up if there's an error that frequent?).

Well, I actually think that my freewing is the culprit. (see above for explanations)

Adding CRC to packet and data to transmit allowed me to avoid the transmission problems.

While I never use the adapter, I created a PCB when I assembled my FreeWing. The board is very small (about 2.5 inches by 2 inches) but uses fine-pitched surface mount parts. If you feel that you have the soldering skills required to assemble a FreeWing with this PCB design, I can send you one. I have 99 extras and since I use my USB to PAR adapter, I have no use for them. If you are interested, I can post pictures.

I may be interested. Can you post some pictures of the PCB ?

I would be very interested to compare my freewing with a "clean" one.

edit : I tested download by downloading my Saturn's bios :

Transfer Time = 50941 msec(s) (524288 bytes).

Average transmission speed = 10.292063 KB/s

And downloaded file contents is identical to "SEGA_101.bin"

 

[antime]

Q1: In the case I want to execute a Saturn binary data : as the main Saturn executable that send/receives data (loaded from CD) is executed from 0x06004000 address, where should I upload another binary data ? Uploading from 0x06004000 overwrites the main executable, and then the Saturn hangs.

You can try doing what the Action Replay does and put all the transfer code in workram-L. Since the Saturn ROM will only load and execute code in workram-H you will need a stub that copies the main application code to workram-L and then executes it from there.

Q2: In the main Saturn executable, when executing binary dataI would like to execute data, I use the following ugly code. (...)

In the "write data to Saturn function", I send sample Saturn executable data (mic's flatcube.bin, 9KB) from address 0x06001000, so that it won't overwrite existing code from 0x06004000.

Then, I do execute(0x06001000); , and it seems to freeze my Saturn.

Does anybody can confirm this code works or not ?

I am not very confident about this portion of code, that's why I post it here.

The code looks correct, but you said you are using SGL which will very likely conflict with most things you try to upload.

By the way, if you're not too hung up on using the Action Replay interface you can just connect a USB-serial interface to the Saturn's rear communications port. Using synchronous serial mode you can get transfer speeds of around 100 KB/s - less than the Action Replay is capable of, but a lot more than what you're currently getting. In my experience it's also quite reliable, far better than the CommLink card I used before that. I wrote some code for FTDI's FT2232C chip some years ago.

 

[cafe-alpha]

The code looks correct, but you said you are using SGL which will very likely conflict with most things you try to upload.

You can try doing what the Action Replay does and put all the transfer code in workram-L. Since the Saturn ROM will only load and execute code in workram-H you will need a stub that copies the main application code to workram-L and then executes it from there.

Nice idea

I tried to implement this solution, and it works under yabause, however, it freezes (black screen) on real hardware.

Does somebody have an idea about this problem ?

Here are the sources for testing : ExecTest.zip.

In order to compile/test/etc, you need SaturnOrbit installed on your PC.

Just launch the "GO.BAT" file in ExecTest directory. Typing `r' in the command prompt will recompile the project, and typing `t' will test the program under yabause.

In order to test the program, hitting the Z key (mapped as keyboard's `D' under yabause) will copy then execute flatcube demo. (if you see a rotating cube -> OK, black screen or anything else -> NG)

Program details :

The stub program can be found in ExecTest\copystub folder.

Program size is 240 bytes, and 12 bytes directly after the program are used as parameter for stub program.

Parameters order is :

- Copy source address (4 bytes).

- Copy length (4 bytes).

- Copy destination address (4 bytes).

Program start address is defined as 0x060BFF00 (see ExecTest\copystub\anti_lnkscript), and parameters start address is defined as 0x060BFFF0, so that the stub program is loaded at the end of User Program & Data area (see MEMORY.TXT in SGL documentation).

Program to execute is loaded from address 0x25C0E1C0 (according to MEMORY.TXT in SGL documentation, is seems to be a free area), then the following parameters are given to the xcomms_execute in SaturnGameTutorial.c :

- 0x25C0E1C0 : address where the program is stored from

- 9056 : program size in bytes

- 0x6004000 : program execution start address

Finally, xcomms_execute copies the stub program and the parameters at their appropriate addresses, then call the stub program.

By the way, if you're not too hung up on using the Action Replay interface you can just connect a USB-serial interface to the Saturn's rear communications port. Using synchronous serial mode you can get transfer speeds of around 100 KB/s - less than the Action Replay is capable of, but a lot more than what you're currently getting. In my experience it's also quite reliable, far better than the CommLink card I used before that. I wrote some code for FTDI's FT2232C chip some years ago.

Well, when I found that my USB DataLink was broken and looking for an alternative to it, I tooked a look to your homepage ... however I didn't found any schematics and/or pictures of your device, so that I prefered to build a freewing instead.

Also, 10KB/s may be enough for me, and using data compression during transmission may nearly double the speed (for example, I could compress a Saturn program from 210KB to 130KB, thanks to LZF algorithm).

 

[cafe-alpha]

(I mistook 'edit' and 'reply', sorry)

 

[antime]

Well, when I found that my USB DataLink was broken and looking for an alternative to it, I tooked a look to your homepage ... however I didn't found any schematics and/or pictures of your device, so that I prefered to build a freewing instead.

There are schematics of the Saturn here, the comms port is on page two. The test points are labelled on the underside of the Saturn PCB so the signal lines are easy to match up. My "device" literally consists of a DLP-2232M module connected to the serial port PCB pins, mounted on a piece of stripboard standing on the RFI shield next to the CD drive data cable.

 

[cafe-alpha]

There are schematics of the Saturn here, the comms port is on page two. The test points are labelled on the underside of the Saturn PCB so the signal lines are easy to match up. My "device" literally consists of a DLP-2232M module connected to the serial port PCB pins, mounted on a piece of stripboard standing on the RFI shield next to the CD drive data cable.

Oh, I totally forgot that there were a communication port behind the Saturn ! I finally understand what you were speaking about

As your solution doesn't uses the cartridge port, directly transfering data from backup cartridge to PC may be possible, which is quite interesting :] (all my old game saves are gathered in an official backup cartridge)

However, I would like first to focus on my freewing, because building another communication device implies to waste a lot of time in mounting, debugging, burning test CDs, etc.

As a reminder, here are some useful links about Saturn serial communication port.

Antime's USB transfer tool

Saturn Side:

Saturn schematics

serial port description in section 13

Send/receive source code on Saturn side

PC side :

DLP-2232M datasheet

Related topics:

Communication port information

Continuing the comm port discussion...

Other :

The USB module used in the USB DataLink

USB serial DB25

I got a question : can you confirm the wirings ?

      Saturn <-->  DLP-2232M

 ----------------------------------------

  TXD1 (5)   <-->  ADBUS0 (40)

  RXD1 (6)   <-->  ADBUS1 (39)

  SCK1 (9)   <-->  don't need to wire ?

  TXD1 (11)  <-->  BDBUS0 (13)

  RXD1 (12)  <-->  BDBUS1 (12)

  SCK1 (13)  <-->  don't need to wire ?

  GND (8,12) <-->  GND (14~15, 22~25)

  + Wire DLP-2232M's VCCIOA (18) and VCCIOB (17) and EXTVCC (19) to external power supply's +5V.

    Wire DLP-2232M's GND (14~15, 22~25) to external power supply's ground.

The code looks correct, but you said you are using SGL which will very likely conflict with most things you try to upload.

You can try doing what the Action Replay does and put all the transfer code in workram-L. Since the Saturn ROM will only load and execute code in workram-H you will need a stub that copies the main application code to workram-L and then executes it from there.

The Saturn send/receive excutable is now SGL-free ! Executable size dropped from 201KB to 27KB

(I just picked-up vdp1ex, and added calls to transfer-related functions).

And now, the copy stub trick works with small programs

When executable size exceeds 100KB, the Saturn freezes when executing the data. I don't know why yet.

By the way, does somebody know a SGL-free equivalent to the SYS_Exit function ?

In order to make an Action Replay firmware replacement, I would like to be able to return to the Saturn's "load disk screen".

 

[antime]

I didn't keep notes of the wirings, but looking at the datasheet it's like follows:

TxD1 <-> ADBUS1/TDI

RxD1 <-> ADBUS2/TDO

SCK1 <-> ADBUS0/SK

TxD2 <-> BDBUS1/RxD

RxD2 <-> BDBUS0/TxD

The FT2232D has the undesirable property that the 232 UART mode pins are not compatible with the MPSSE mode pins, so you have to decide whether you want to use asynchronous or synchronous (SPI without the chip select line) on channel A. MPSSE mode is a lot faster, but since it's synchronous you must use some form of host polling and you have to make sure you don't lose synch etc. Generally it works well for fast uploads/downloads, but I imagine a debugger interface would work better with the asynchronous interface.

Channel B doesn't support MPSSE mode, so I used 232 UART mode (I suppose you could use the opto-isolated mode for channel B, but didn't investigate it further). The newer FT2232H chip supports MPSSE on both interfaces, but unfortunately doesn't fix the mode pin incompatibility (otherwise you could upload the application using fast synchronous mode, then switch to asynch mode for debugging etc.) With the quad-interface FT4232H chip you could also wire up the SCSP "MIDI" serial port.

I configured the DLP module to be USB powered, as earlier posts by Artemio Urbina had suggested that the serial port power supply wasn't very good. Remember to connect the ground lines, though.

 

[cafe-alpha]

Thank you for the informations !

I still can't believe that your solution transfer speed reaches 110KB/s, because my freewing is about 10 times slower than it ^^

By the way, I made some improvements to my freewing software : I realized that computing RS code was a heavy task for the Saturn, and thus lowered the transfer speed !

In the download process, I made the Saturn to compute the RS code only when requested (until now, it was computed for all the bytes to transfer), and then speed raised from 11Kb/s to 13.4KB/s.

In the upload process, I use a very simple -but fast- correction algorithm that suppose an error is due to the fact that a byte is received twice (which is generally the case on my device), and speed raised from 12.6 KB/s (resend chunk when error) to 10.8Kb/s (RS correction) to 13.7KB/s (simple correction)

 

[BrokenLizard]

Here are a few pictures of my FreeWing PCB. When I designed this adapter, I did not realize that certain package sizes of the SH74HC157 are difficult to obtain in small quantities. As a result, I made a small package adapter so that I could use a different IC package.

FreeWing PCB on top of a PAR

[attachment=7711:Freewing on PAR.jpg]

Top view of the FreeWing PCB

[attachment=7712:Freewing.jpg]

Bottom view of the FreeWing PCB

[attachment=7710:Freewing Bottom.jpg]

 

[antime]

The board looks nice. Did you have it made somewhere, and how much did it cost?

The serial interface section of the SH7604 manual describes the maximum bit rates you can achieve for the various transfer modes. I found that an external input clock rate of 1.2 MHz will work, even though it's a bit out of spec. The efficiency isn't great (about 75%), but I believe it could be improved a bit with better host-side software (in particular switching to an asynchronous FTDI communications library).

 

[BrokenLizard]

I designed the board using the Eagle Layout Editor and then had www.4pcb.com create the PCBs. I populated the board myself (soldered the components). Components to build the board should cost between $10 and $20. If anyone is interested in using the PCB to build a FreeWing, let me know and I will try to find the schematics and parts list.

 

[cafe-alpha]

Thanks you for the pictures, BrokenLizard

After taking a look to your board, I finally understand what "fine-pitched surface mount parts" means, and I realize that it might me too much difficult for me to build one ...

So instead of building one, can you test your device with my transfer program ?

In the case of a noise-free device (I suppose your device is OK), I would be very interested in knowing which speed the Freewing can reach.

For testing, you will need :

- A PC with a parallel port (Obviously).

- A modchip Saturn, or being able to perform the swap trick.

I recommend the following configuration, because I use the following hardware :

- Windows XP. Because I haven't added parallel port access routines for newer Windows versions yet.

- Saturn Action Replay Plus. After adding ARP type auto-detection, it should work with GameShark/Pro Action Replay/anyting else.

I hope to release a test version of my transfer program in some few weeks.

For testing, you only need to download the test program, execute a batch file, then send me the generated log file.

By the way, I added compression when sending/receiving data !

Now, I can download empty backup memory at 120KB/s ^^

And I added a "vdp1view" feature, however, the resulting snapshot is quite "noisy" ...

Funny note : I noticed that copying data to a temporary buffer before compressing it removes some "noise" in the VDP1 image, so I think that the "noise" is caused by the compression routine when it tries to read the frame buffer when the VDP1 writes it.

Pictures are here : compression only, memcpy, then compression.

By the way, does somebody know a SGL-free equivalent to the SYS_Exit function ?

In order to make an Action Replay firmware replacement, I would like to be able to return to the Saturn's "load disk screen".

I found the answer in SBL's SEGA_SYS.H file :

/* Exit to multiplayer. */

(**(volatile void(**)(void))0x600026C)();

SBL teems with information about Saturn hardware

 

[cafe-alpha]

(bump)

Just to say I made some improvements to my transfer program.

1. In addition to the command-line based transfer program, I have made a GUI program that performs send/receive/etc tasks.

Note: transfer-related stuff are gathered in a DLL (one DLL per communication device), so that multiple hardware as well as multiple program could be supported easily.

2. I have finished the Saturn ARP firmware replacement, so that I can now debug without using any CD

The firmware installation is like using a linux live CD : you burn an iso file on a CD, then test it in order to see if it works, then flash your ARP if you are satisfied with it.

3. In the Saturn Library, in addition to the Saturn<->PC communication functions, I added some functions for program debug purpose, such as "send debug message to PC", "prompt message from PC", "read from/write to file on PC".

And I will be glad if somebody wants to help me by trying this software with a Saturn USB DataLink. (actually, I got an USB DataLink, but it seems to be broken)

If you are interested in helping me, you can reply to this post, or email me here.