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.
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 ?
BrokenLizard said:
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
BrokenLizard said:
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.)
BrokenLizard said:
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).
BrokenLizard said:
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)
BrokenLizard said:
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.
BrokenLizard said:
4. Make sure you are using either HCT or HC parts. Other logic families will not work.
I am using "HC" type.
BrokenLizard' date='13 March 2010 - 12:56 PM' timestamp='1268452616' post='156339 said:
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.
BrokenLizard' date='13 March 2010 - 12:56 PM' timestamp='1268452616' post='156339 said:
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.
ExCyber' date='13 March 2010 - 04:12 PM' timestamp='1268464368' post='156340 said:
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.
BrokenLizard' date='13 March 2010 - 12:56 PM' timestamp='1268452616' post='156339 said:
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"