Vectrex EPROM Cartridge finished

Today the PCBs of my EPROM Cartridge arrived. Of course I soldered and tested it directly. The EPROM used here is the 272001 which is programmed using the already mentioned RR-Prommer.

The image to burn is generated by a small linux tool written in C, which reads a list of pathes to ROM images and arranges them according to the limitations of the hardware.
The Cartridge contains 256kb of memory. Supported ROM sizes are 8kb, 16kb and 32kb. ROMs which don't fall into one category are expanded by the tool to fit one.

The hardware is rather simple but offers some glue logic to support the various ROM sizes. All Images need to be aligned on their size. The used algorithm places the bigger ones at the beginning to simplify this problem.

At last the tool generates a list likes this here to tell you how you need to set the dip switches to select the wanted game.

Wormhole              -----

Gravitrex             --.--
Thrust                -.---
Protector + Y.A.S.I   -..--

Sadly I can't test the save feature yet as I've forgotten to add the needed EEPROM to the basket >_< doh.

And yes it does work like a charm. At first I did have a fear that my beloved Vectrex explodes (or implodes) but electrical engineering did again win this time.

Yaaayyy !!!! To convert the graphic of my snail I've written myself a tool in Java that grabs a SVG file and then fetches the koordinates of pathes out of it. I think they will be also one post about this soon.

Limitations compared to the a lot better VecMulti:

• No Bank-Switched Games
• Image not allowed to be larger than 32kb
• Only one EEPROM for savegames.
• So only one saving game on one cart.
• Still: EEPROM has TO92 package and can be removed easily.
• No Debugging-Port

RR Prommer V1.0 EPROM Burner User Manual

For building the Z80 Minisystem I needed a cheap EPROM burner. I searched and found one. It was the "RR Prommer V1.0". This was back in 2008 or 2009. For the Vectrex Cartridge I will need it again as I wanted to have a simple design at first as I'm not possessing much knowlege about the internals of the Vectrex and the 6809 cpu.

But what is this? I can't find the manual. Just look at the programmer.

The type of EPROM you want to use has to be set using 5 jumpers. But without a manual it's rather difficult to know which settings is the right one.
So I googled a little bit and guess what. The Manual just has disappeared. The Internet actually has forgotten something. (At least I'm unable to find It with 20 minutes of searching >_<)

Luckily I digged It up again from a harddrive of my last pc so I have it again. As other people als might have this problem I like to share it for download here.

Also If you are unable to find the software this guy here has developed a linux program to use it. zprommer.
It works as the "RR Prommer" is actually a clone from an old Batronix EPROM burner. I don't know anymore how I got this one. But It works great using the EPROMs 27C256. I can't say more now and I hope It works also with 27C2001. If not I'm pretty screwed :-D

Vectrex Homebrew Cartridges

Last year I got myself the famous Vectrex console.For those who don't know it: The Vectrex made by MB is the only homeconsole with a real vector graphics display as It was used in early arcade games like Asteroids, Lunar Lander and Tempest. Because of this design it's impossible to use a standard television with this system as these devices are only able to rasterize a picture line by line. Vector systems on the other hand directly control the beam of the cathode ray tube to draw dots and lines.
This is why the vectrex has a built-in monitor ... which can be destroyed by software.

Here is a picture of my unit.

 

Here is another picture of my units tube.

This "hole" is not photoshopped. The small dot indicates that the fluorescent layer was burned away at that point. Talking about "Killer Pokes" here. It's like a damaged pixel on a TFT monitor. It's always there and you have to look at it. Anyway....

According to Wikipedia the Vectrex has only 20 official games released in europe which is sadly not a lot. To overcome this problem and because programming games with vector graphics is awesome as hell this platform got a great homebrow community. A lot of these games are released on custom manufactored cartridges and also a few with integrated non-volatile memory for highscore savings (which is not common on this device). But not all of them.

As this device is not that popular not a ton of "flash cartridges" exist that let you burn your own games onto. A very good example is the VecFlash and the VecMulti made by Richard Hutchinson. Sadly both are sold out at least since 2012-08. I tried to contact him at that point but the status hasn't changed since then. Both cards were very sophisticated. In special the VecMulti which offers to load games from MicroSD and has a debugging port for homebrew development.
Another alternative would be to destroy an existing card by replacing the rom by an eprom and then use this one. Also you can use extra adress lines to select different games. This is how a lot of "MultiCarts" are designed.

A lot of time passed since then and I thought myself it would be funny to make a EPROM based solution myself. It will not be as great as the "VecMulti" but it will suit most of the needs. I finished a long ago started design today and ordered the PCB. So stay tuned.

The only downside with my design is the lack of backup memory which is used at least by the games Thrust, Protector and Y.A.S.I which are one of my favourites. I couldn't find schematics which show how that works and where the needed EEPROM is applied but the design is made flexible so it may be possible to add that later.

Not much new content at the moment

Someone might wonder why there is not a lot content in the last 2 months. The reason is a small phase of change in interest. At the moment I'm making some music for my YouTube channel which of course also takes some time. In parallel I've an ongoing masterthesis at the moment. So there is not much time left to hack some hardware and software. My interests are like sin() and cos(). So at some point there will again be more of that stuff here. I just want to let anyone know that I'm not gone or something like that. There is still a queue of posts I like to do. Especially my FPGA projects.

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.

Let the FPGA experiments begin - Part 1

Tinkerings with FPGAs

Shortly before finishing the "Z80 Minisystem" I read about FPGAs and for the moment I thought that these devices are "the most awesome thing you ever see in your life". So of course I wanted to do a project with them. Again I was inspired by phil from retroleum as I instantly became a fan of his work.

So how do you start? I was so crazy I didn't even thought about buying a evaluation kit! I've discovered that you can get a simple FPGA like the XC3S50 (Spartan-3) from Xilinx inside a QFP144 package. I never etched a printed circuit board before as I always worked with strip boards. Also I didn't wanted to start etching. So a solution for this has to be found...

And I went simply nuts as I got myself some solder adapters from Elk-Tronic to solder the FPGA onto it. After that, some really dirty work started as I took this naked adapter board and connected it with a lot of wires to a strip board having the power supply (3.3v,2.5v,1.2v) and a little bit of sram.

Now we are talking about tinkering (25.2.2009)

It's like a chip with pink tentacles attacking the stripboard (25.2.2009)

The programming over the "Slave Serial"-mode of the spartan-3 was done using a simple parallel cable and a self written Linux driver. The protocol is a very simple serial clocked one that can be implemented rather fast. But the transfer rate was slow because of the bit-banging. So I created a serial variant using a PIC.

But as you might know a FPGA loses it's configuration without the power supply. Normally you would buy some xilinx platform flashes to save the configuration. But I had a better idea. I got myself some XC3S50AN (Spartan-3AN) FPGAs which do offer an internal SPI flash that can be used for configuration.

So fragile... :'-(

Luckily I got a reason for desoldering the FPGA for a new one as at this point my workplace started being possessed by an evil demon that causes my Spartans to be killed....

Naah of course not! Sooner or later you will discover that FPGAs are rather fragile components. They break very easily. Let me list some reasons:

• unstable power supply
• the core voltage is 0.05v to high
• mistakes inside the datasheet 
• floating inputs
• the weather is cloudy
• it's friday
• because they want to

As it turned out the power regulator (LM117) that was in use for generating the 1.2v core voltage delivered 1.25 volts. This was too much for this little thing and it just died .... :'-( .... I burned just 15€.
So I removed it with a hot air gun and soldered a new one. As I didn't knew the fault was inside the power supply I just continued using it and ... after a few days I got the dead FPGA number 2 ....
The fact that this was causing it was clouded by the fact the FPGA can run with 1.26 at maximum. But it seems the regulator was just to unstable for this purpose. So i got myself some expensive ones that gave exactly 1.19v.

So I continued working on it and guess what. A copper wire broke of and this was an input on the FPGA. As the driver was missing a got an antenna and you know what this means..... floating inputs lead to higher current inside the chip and the next FPGA was destroyed. Just by open inputs. At this time I got really depressed for losing all my money on this stuff.... but I of course bought another one. (At this point I wasn't aware of the feature that you can enable internal pull-ups)

In midtime I switched from the XC3S50 to the XC3S50AN with integrated flash. These also don't need the 2.5v supply anymore which is great. What I didn't knew is that the I/O has changed in matter of clamping diodes. As you might know the Spartan-3 is a 3.3v only device. When interfacing 5v you need to levelshift. If you have a device with clamping diodes on it's input you can apply a 5v signal with a resistor in series. The voltage that is too much will overflow into the 3.3v supply and just disappears (talking simple). These clamping diodes are removed at Spartan-3A and Spartan-3AN devices which is not told explicitly inside the datasheet. So.... I burned about two devices until I read about it.

My working place became some sort of graveyard for spartan devices. I was sure that the Spartans from the movie 300 were a lot more resistant.

Back to work

After telling you about all the dying Spartans in my room lets continue on our journey.

Before buying all this stuff I experimented a little bit with the webpack edition of Xilinx ISE (version 10.x at this time if I remember....). But of course for development you need a language.

Choosing a language

At this time we hadn't any courses in university about "hardware description languages" so I was not biased.

If you look around there are two important languages: Verilog and VHDL. At this time I only knew that Verilog is more used in America and VHDL in Europe. I looked at both languages and tried to decide. I don't want to start a flamewar here as this is a well and emotionally discussed topic in forums.
But for myself I decided that Verilog is the better language as the Description of behaviour seemed to take a lot less code lines and the code itself was not very blown up. If you look at VHDL you have to write a lot of code to accomplish your task.

So I went for Verilog and studied it. Today I do believe that this choice maybe was a mistake as I live in Europe in which VHDL is the preferred language. It may be more difficult to get a job If i tell my hypothetical boss that I learnt Verilog in university :-D. But this is just a wild guess. The truth is these languages are very similar. If you understand Verilog you can read VHDL with ease most of the time. It's like reading C++ with Java knowledge.

At this point I will make a break as some of the last posts are just to big to be readable.