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.

Hopefully the next batch of RAs will arrive soon and I can get on with selling them.

The acknowledge pulses come after the next data byte has started. Official controllers can cope with that, but some third party ones don’t work. I’m fairly sure it’s an error as Sony fixed it after a couple of minor revisions. I suppose the probably noticed that some third party controllers didn’t work on one port of the console.

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,

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.

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

This is the first PCB I have had professionally made, and the first time I’ve tried to do a kit or sell anything. Fingers crossed all will be well!

As well as PCBs for the main Retro Adapter, I have designs for the individual controller adapters too. These are needed for controllers which do not use a 9-pin female sub-D type connector such as the Famicom/NES/SNES or PC-Engine, and for controllers which require extra circuitry such as PC Gameport joysticks, Atari Paddle controllers and Neo Geo controllers.

I’m still trying to work out the best way to do some of these adapters. PCBs make construction a lot faster than having to wire the connectors up by hand, but sometimes it’s unavoidable due to PCB mount connectors not being available (e.g. Sega Saturn / Playstation). Where PCBs are possible the question becomes how big to make them. Smaller PCBs save money on manufacturing but don’t fit in a case so have to be used “bare”, while larger ones cost more to produce but will fit in standard cases like a DB9 shell.

There are other issues still to be resolved. The way I am going to implement multi-taps is going to need some experimentation to find the best solution. At the moment I’m thinking that the best thing might be to use a dynamic HID config, and when a multi-tap is plugged in have the Retro Adapter disconnect, change the config and re-connect. The implementation of Atari driving controllers is dependent on emulator support and I’m waiting back to hear from the authors about that. I need to test out bootloaders as well for firmware updates, so I can add more controllers as I acquire them.

Things are moving along well and I’ve now proven that the modular design can cope with pretty much any controller imaginable. It is also possible to connect DIY controllers using a variety of methods, which could either replace the “pad hack” method or complement it by offering dual console/USB support.

There are two major changes. I have abandoned the idea of using a DB25 in favour of a DB9, with a DB9-DB9 jumper box being used as the case. I managed to cram everything in to the space, with only one surface mount component (the microcontroller). The µproc has changed to an ATtiny861.

Due to the code being written in C, the code size has increased. I was originally using an ATtiny461 but ran out of code space.

An LED changes colour to show the current mode

I have tested all of the controllers that the original Retro Adapter supports. I have also added support for MegaDrive 6 button pads and Playstation 1/2 controllers in both digital and analogue modes. PSX arcade sticks and dance mats also work. I have some more controllers (PC-Engine, FM Towns, N64, Atari 2600 paddles, Saturn Analogue (NiGHTS) pad) ready to go and am looking for some others (X68000/MSX, Gamecube, Virtual Boy etc). I am particularly interested in getting a Playstation train controller and Saturn arcade/steering wheel controllers. I saw a train controller in Japan, but it was too large to bring back :(

For Dreamcast pads, I’m sure it’s possible but I really need a logic analyser to do it. There are also issues with the amount of code space it could take up.

More details on the Retro Adapter V2 to follow. Hopefully when I’ve finished working on the prototype I will be able to so a small run of kits. From the volume of email I get it seems like there is demand.