PCBs for USB Datasette and Wiimote2Amiga arrived

My USB Datasette and the Wiimote-Amiga-Joystick-Adapter (now better called "Wiimote2Amiga") finally reached the state of being implemented on professional PCBs using the company PCB-Pool.

2 "USB Datassettes" and 3 "Wiimote2Amiga" Boards are left

USB Datasette

Top: Old version with stripboard and cables. Bottom: New version with just one PCB.

The cables that were required for the connection to the datasette and the C64 itself are now gone and replaced with an edge connector and a female connector. This way it's a little bit more compact and less "wiry".

It even has a "feature" that you get if you design hardware without looking at the port locations.

WHY THERE IS IEC PORT? - Rage-Face from http://alltheragefaces.com

But as the main purpose of the device is the connection to the datasette without the usage of the c64 itself this is not that of a matter.

Wiimote2Amiga

Left: STEITEC Evalkit Version, Right: New PCB with everything in one.

The board equipped to my 1200 with plugged in bluetooth stick.

As this project never leaved the evaluation board before, this was my first circuit board with an LPC1768 controller. And of course this leads to some errors that are clearly visible in the photo.....
The current needed to drive this project is reduced by a fifth to 70mA (@5V) which is great for the Amiga 1200 which has a resistor in series at the joystick port effectively reducing the possible current you can draw.
Also the size of the device is now greatly reduced to 48x48 mm and should be small enough to be placed inside the "rear trap door" of an Amiga 1200 to make it even more compact.
To reduce problems with the C64's sound this board offers the possibility to disconnect the power supply of your computer from the device and a port to connect an external 5V source.

Conclusions

In the past I preferred designing with stripboards as they could be developed and debugged easily and incremental. But the beauty and cleannines of real etched PCBs is just untouchable.
As I had a minimum order quantity with boards as small as this I decided to sell the remaining unequipped boards for the cost price if there is interest.

Of course there is no warranty and I'm a little bit pedantic about releasing source code. ;-)

Schematics and Binaries for the USB Datasette

As there seems to be interest for the USB Datasette I would like to publish the schematics and the other stuff you need to operate it. The pictures in this blog are rather low res. Please download the package at the bottom for high res versions.

But first....

Disclaimer and Advises

The device is dc coupled to the PC and there is no galvanic isolation. Also the device is dc coupled to your c64, zx spectrum, tapedeck and datasette. Keep in mind that it's possible to have multiple grounds which leads to ground loops. This might destroy your PC, your c64 and other stuff you loved to connect to it.

If something is destroyed by usage with this device I'm not responsible for it! So use it with your mind and at your own risks.

If you want get sure to have no ground loops don't operate it with a grounded PC. Use it with an ungrounded notebook!

Also there is no windows driver at the moment.....

The board is very old and the schematic was reverse engineered just right now. I don't claim that it's totally correct. It should be though......

For me the system worked with every tape image I've tested. But that doesn't means it works with all of them!

Schematics

To build it you need:

1x PIC18F2450
1x Oscillator 48MHz
1x LED Bar with 10 LEDs (not needed but you see that a transmit is going on)
1x 1 PNP transistor (only if you want to use it with a c64 datasette)
1x 3.5mm Jack Port (if you want to connect it to a normal tape deck)
1x female header with 6 pins (optional)
1x male header with 6 pins (optional)
1x switch
1x USB B Port

and of course a few resistors. Please look inside the sheet to decide which one you need as some could be keeped out if you don't want to use a particular feature. The circuit is very variable and you can modify it as you need for your services. The connections to the spectrum are not part of this schematic. But If you are able to build this you will find the pinout. The most important part is the PIC18F2450 which receives the pulses from your PC and transmits them. Then you need a switch to activate the bootloader (if you use one), the oscillator and the USB B port.

The possible connections are offered using two connectors. I differentiated using the gender of the ports to be sure that nothing is connected wrong.

Speaking for the tape signals both ports are the same.

The first is designed for a connection to a tape device and offers the control of the motor and has an input for the sense signal ("PRESS PLAY ON TAPE").

The second is used for a connection to a computer and has a SENSE OUT to tell a c64 that you have pressed play by starting the driver and a MOTOR IN to tell the driver that the c64 wants data.

The LED bar only has one LED active at a time. This way you need only one resistor at the cathode. The light wanders with a speed that correlates to the pulses per second.

Software and Stuff

Click here to download the package.

You need libusb and the program must either be used with root or you have to give a normal user access to the USB devices. You get a linux executable for 32 bit and 64 bit.

If you have problems using the software, possible suggestions or you have found an image that is not usable with this driver please let me know it. I will try to fix that.

Usage 

After plugging the device in lsusb recognises it as:

Bus 006 Device 055: ID 04d8:00ef Microchip Technology, Inc.

If you just run the driver without any parameter you get this little help.

=== Slamy's USB Datasette Userspace Driver === Build 2013-01-20

slamysdatasette <file>.raw    44100 Hz / Unsigned 8 Bit Raw

slamysdatasette <file>.tap    C64 Tape Image

slamysdatasette <file>.tap    ZX Spectrum Tape Image

slamysdatasette <file>.tzx    ZX Spectrum TZX Image

slamysdatasette test[0|1]     Timing Test

           sim                Simulation

           seek <Nummer>      Seeking to a pulse

           nosound            No sound at result

           nosleep            No 5 seconds wait at the begin

To begin with the error messages are german and english mixed. If enough people are interested in a pure english version it of course will be made.

The simulation reads a tape image completly and tells you how much minutes and seconds the image will take to write. Also this tests wether the drive is able to read the image. First simulate, then write ! ;-)

The nosleep parameter is for the usage with a computer as for the tape deck you need to surpass the part of tape that is plastic and not writable. If you know tapes you know what I mean.

You need to use nosound at the moment. The program wants to play a sound if it has finished the dumping process. But the sound I use at the moment is a piece of music I'm not allowed to upload here. Just place a "turricanwin.wav" inside /usr/share/slamysdatasette/ and it will be played...

Also place "castlevanialose.wav" there which is played in case of an error.

The sounds that I recorded from the games for this purpose are the "Turrican 2 Level 1-1 complete sound" and the sound of dying in "Castlevania" for the NES. Just for you to know :3

So that's it. If you like to build it yourself please leave a comment If you had success or not.

Slamy's USB Datasette

Let's have a look at the USB Datasette I've made about 2 years ago if I remember correctly. The purpose of this device is the writeback of legacy tape images to real tapes.

The device itself

The device is constructed using some stripboard and a PIC 18F2450. The nice thing about this PIC is that it has a complete USB device controller that has a lot more features than your average "ftdi to uart"-solution.

A linux driver was built which is able to read spectrum (.TZX and .TAP), c64 (.TAP) and cpc (.CDT) tape images. It interprets the images and extracts the pulses that are used to encode the data. The length of these pulses are transfered to the pic using libusb and interrupt transfers. The program inside the microcontroller puts these inside a fifo and gives the resulting signal to the output.

The whole kit

The device offers three connectors as seen in the first picture above.

The  left pin header next to the oscillator is used to connect to a tape

device. First a cable for the c64 datasette and then one that can be used for the internal drive of a zx spectrum +2A.

The female connector right next to it is used for a connection to a computer itself. It can be used for connecting a c64 and the internal header inside the +2A. The driver is also capable of stopping the playing process if the c64 disables the motor signal. In this case it operates as a tape emulator.

The last connector is your average line out but with reduced volume as it has to be connected the mic port of an tape recorder used for external connection to the cpc and the spectrum.

Let's have a look at some example photos.

Connected to a tape recorder

Connected to a C64c

Connected to a C64 datasette

Connected to a ZX Spectrum +2A and it's internal drive

A few words to the last picture: The Spectrum +2A doesn't offer the possibility to connect an external tape recorder like it was done with the 48k and the 128k. There exists a hack. But its a destructive one so i didn't used it. I've built myself a cable to extend the internal tape header to move it to the outside of the spectrum. This way I can connect the mainboard to the internal tape drive or an external source without opening it. Look at the photo as you can see both connectors hanging out.

Also as you can see there is a selfbuilt kempston interface as the "sinclair joystick ports" are pretty unusable if you don't own... sinclair joysticks ....

also the most games can handle kempston joysticks.

So this was everything I wanted to tell about this device, i guess. It took a few weeks to develop as a lot effort went into the linux driver. I don't know if its possible to port it to windows. The driver was written mainly in ANSI C so the only problem might be the part interfacing with libusb.

It's a very useful device and I've managed to write a few games using it. Of course these are official versions with copy protection and unmodified. I remember one game that my driver couldn't handle. It was a .CDT image with raw audio data inside. But that only happened once and an image like this is not very common.