The MSF signal is frankly a mess. Things seem to have been added and then removed over the years. There are four different length pulses and various additions. Compared to the nice clean DCF77 signal it’s horrible, but unfortunately I can’t get DCF77 to work reliably here. In fact I bought a DCF77 clock but it has never been able to receive a good enough signal to set itself.

As others have discovered the MSF signal is much cleaner at night, but filtering out the noise during the day isn’t too hard. I wrote the decoder in assembler and it basically waits for a valid bit and then locks on to that, ignoring everything until 950ms have passed from it’s start. It also filters out too short and too long pulses and does some debouncing.

The PSX uses a SPI bus. The device is supposed to put data on the bus when there is a high to low transition, then read the command on the low to high change. Sure enough the official controller sets the data line within 0.3us of the clock transition.

The problem is that some revisions of the PSX hardware don’t wait for the low to high transition to read the data line. They read at some random point during the clock cycle.

It seems to be some kind of bug because Sony fixed it in later revisions. That is of course assuming that the information on the net about the controller protocol is correct. It may be that the controller is supposed to assert the data line within a few hundred nanoseconds but that seems somewhat unlikely. It would force you to use a hardware SPI bus and thus limit the choice of microcontroller. Maybe Sony don’t care about the needs of third party developers…

I saw a PSX dev-kit for sale last year and wish I had it now. Oh well, it’s sorted now. Make sure the data is there before the transition, just like the PSX does with the command line, and it works.

Anyway,

Atari/Commodore/Sega controllers are working and I will add support for NES and SNES too. I will probably do N64 as well. The button mapping is not ideal but is usable. I experimented with having the RA re-enumerate as two separate controllers but it is not ideal to do on the fly. The current system is a good compromise.

It occurred to me that I can use the same PCB for a Wii/Gamecube version, so I am now working on the Retro Adapter Wii. It will support all the same controllers as the Retro Adapter, and will in fact use the same code where possible. One thing I’m not sure about is firmware updates, I need to look into the options.

I will put together a complete assembly guide with photos at some point in the next week or two, as well as releasing V1.0 of the firmware complete with USB update facility. I am still considering options for the update facility as it needs to be triggered somehow. At the moment the best option looks like holding a fire button on the controller, but the problem is that due to very limited space in the bootloader section it will have to be a simple controller like an Atari/Amiga joystick, Neo Geo joystick/pad or maybe a Sega Saturn pad. In case you don’t have one, a very simple update “plug” made from a DB9 and 1 wire to simulate the fire button being held could be used.

With a bit of luck the Retro Adapter will be on sale soon in time for xmas :-)

I just need to finish a few things off with the code before doing the first small run of boards,

One issue I have found is that it takes a little while to assemble these things. I think it should get quicker if I do them in batches. A good PCB holder is going to be essential I think – the “helping hands” thing with crocodile clips I have now is not really up to the task. Heat-proof soldering gloves make things a lot easier too, as you can hold components in place with a finger while soldering them.

The package is quite nice. You get the Logic, which is tiny, probes and carry case. The probes are in the forum of a header with 9 wires (8 data + GND, so you have to have a common ground) and individual “E-Z-Hook” clips. The wires are very flexible and easy to work with, and the clips are the best I have come across. They have little pincers which fit nicely on to component legs, breadboard, DIP IC pins etc. They even clip on to trimmed component leads which have been soldered to a PCB, such as the underside of pin headers.

The pincers retract into the clip’s plastic body so they do not short with each other, even on neighbouring pins of a DIP IC. Saleae also sell replacements at reasonable prices, although so far they seem very robust.

The software provided (simply called Logic) is a bit of a mixed bag, but overall not bad. One attractive feature is that it includes decoders for RS232, SPI, I2C and 1 wire protocols at no additional cost. Future updates and new protocols will be free too, and there is an SDK which I have yet to experiment with. You can download the software from the Saleae web site to try out with some demo data.

Logic is written in .NET so takes about 10 seconds to load on my XP x64 system with 6GB RAM and a 3.1GHz Core 2 Quad CPU. Once it’s loaded though it is very quick and responsive. Not all companies bother to support XP x64 (Vista x64 is mandatory for all signed Vista drivers), so it’s nice that Saleae made the effort.

The Logic interface is non-standard, being skinned. Normally that’s a Very Bad Thing as it can break all the familiar UI elements, but fortunately the developers have stuck to the standards here. Navigation via the mouse is pretty fast, with the mouse wheel used for zooming and simple dragging used to scroll. Hovering the mouse over the recorded data gives you various bits of useful information, such as width of bit, period, binary decoding and more via configurable options.

On my system I can reliably run the Logic at 24MHz without issue. In fact, there is little reason to go any lower since 24MHz, the maximum, gives the most accurate timings. Using a lower frequency allows for longer sampling periods, although even at 24MHz several seconds of recording are possible. I was able to capture complete hardware detection, handshake and polling cycles of various games consoles without any problems. The software handles massive amounts of data with little effort.

Triggering is configurable for each data line individually, and sampling starts when any line is triggered. The Logic also gives you up to a few ms before the trigger which is handy. Trigger can be set on either a logic 1 or logic 0, but not on transitions (e.g. low to high, high to low) explicitly. In practice since most buses are held in one state until communication is started it’s not a major issue, and the Logic does not sync it’s clock to the transition edge anyway.

There are a few things missing that would be helpful, such as being able to compare two data sets side by side. You can take screenshots but it’s not quite the same. You are also limited to only two markers which you can place anywhere, but more would be helpful. The view parameters are reset every time you take a reading, so you have to re-position the display and zoom every time. Luckily the defaults are not that bad.

Saleae are quite helpful and were happy to receive my comments. A new version of the software is in the works which promises to address these issues.

Overall I am very impressed. At $150 the price is pretty good. There are seemingly higher spec’ed and cheaper USB logic analysers available from Chinese companies, but when you look closely at them they tend to have either poor software or arbitrary limitations such as the protocols you can decode (with more available at a price). The openness of the Logic via the SDK is quite attractive too.

The usefulness of the device more than justifies the expense if you do much protocol based work. The ability to see exactly what is going on is invaluable, and makes it easy to get all the timing perfect. It’s also very helpful for debugging, since you can use unused pins on your microcontroller as debug outputs that take only one instruction cycle to access. I have found that some protocols I had working already could be made much more compatible just by checking the timings instead of trying to estimate them based on instruction cycle counts.

I hope Saleae are successful with this project, as they deserve to be.

The main reasons for the change are not wanting to have to drill lots of holes in the cases and wanting to reduce the amount of external components required to support certain controllers. You can now plug Neo Geo pads in directly thanks to having both 9 pin and 15 pin connectors. Having a 15 pin connector makes supporting things like PC Gameport devices easier too.

The AVR has been upgraded to an ATmega168. 16k flash ROM and room for a boot loader, so firmware updates are possible over USB. There are also more I/O pins available.

Finally, the USB port has been done away with in favour of a captured cable. The USB spec says you must have a captured cable for USB 1 devices anyway, and now a USB port won’t easily fit. Since the cable is flexible it also means drilling holes is a lot easier as they don’t have to be exact. The only potential issue I can foresee is strain relief.

Seeed Studio is doing a special offer with 30% off, so I’m getting prototypes made up.

Spot the deliberate mistake :) It’s not a problem though, you can easily read the backwards text.