Thursday, May 26, 2016

Tasman Turtle - Restoration




After all the time I spent trying to find information on early turtle robots I didn't think that I would ever get to see a working Tasman Turtle. The ones I knew about were incomplete and non functional. I wanted to put one together but even if I had been able to get my hands on one, due to lack of information, I would have struggled trying to restore the thing. That is why a few years ago I built WALTR, a LOGO turtle robot, using modern day components (http://lukazi.blogspot.com.au/2012/01/waltr-introduction.html, http://lukazi.blogspot.com.au/2012/04/waltr-update.html). This is well and good. WALTR can do more things and do them easier than an original turtle robot but it just doesn't command the same presence. Well, this year that all changed. I was extremely lucky to have come across this particular Tasman Turtle for sale. It was non functional but all the main parts were there, including documentation that I had been trying to find for a number of years. The gentleman that I purchase it off, Chris, told me the story of how he had saved the robot from ending up in a dumpster and ended up storing it for fifteen years. Thank you Chris for making this fabulous piece of Australia's education history available. I figured that if I didn't pick it up then it may have ended up sitting in some collector's garage for the next few decades. My aim was to restore the robot, document it and share the information.


WALTR and his old mate Tasman Turtle.



The first step in the restoration process was to find out if the floppy disks still worked and if so then the information that they contained. In a project such as this, getting the software working is just as critical as getting the hardware going. Looking at what was in front of me, I had a pretty good idea of what I was going to be dealing with except knowing what was on those floppy disks. With floppies you never know what you are going to get until you do the restoration. Floppies are also the most likely part of the system to have failed. Saying that, I have had a greater rate of failure with my 3.5inch floppies than I have with the 5.25 inch ones so this gave me a bit of hope that the data was still there. However when I noticed how warped some of the disks were and the magnetic part would not spin around inside the disk jacket, I had grave concerns. Before attempting to cut open the disk jacket and place the inner magnetic disk into an alternate jacket, I thought I would just try them out as they were. It turned out to be just fine. From the provided three disks, two sides were not used, one had an incomplete copy protection program on it, one contained a few simple primary school games (this side was corrupt so I was unable to extract all the software from it), one had the Tasman Turtle Robot LOGO procedures on it and one contained the Turtle Programming Language software (I later worked out that this is a screen based turtle drawing program and would not be used with the Tasman Turtle). Therefore only a single side had any relevance to the robot. It contained setup software which helped out a lot but unfortunately no project examples like I was dreaming of finding.



Scanning the manuals to PDF was next on my "to do" list. This was a straight forward exercise and it was something I was able to do while waiting to sort out the turtle's power supply situation. I also found a few broken wires on the turtle but it wasn't difficult to work out what went where. It was a quick and easy job to clean the wires up and resolder them.



The robot uses the Apple II for control but to drive any of the robot parts requires an independent 12V power source. This robot did not come with a power supply so I needed to source or build one myself. I was thinking about purchasing a modern day regulated 12V 2Amp caged power supply. This would have been the simplest thing to do however it would have looked out of place with the Apple II and the robot being the age that they are. I decided to try and track down an age specific power supply and it was not too difficult to do so. I picked up a Panther Power CB radio power supply which would have been a typical power supply used with the robot in its day. Anyone who was into CB radios back then would have had at least one of these, or something similar, lying around in the back shed. Even though it gives out 13.8V this is still well within specification for the turtle robot. However being the age that it is I didn't want to stress out any of the turtle's components more than I needed to so I decided to make a simple modification to the power supply. The power supply's generic printed circuit board makes this very easy to do. This allows me to vary the voltage from 11V to 15V. It's currently set around the 12V mark.

Once the power supply was sourced and modifications were done I had to perform three smoke tests.
  1. Power on just the power supply. Great, no smoke.
  2. Power on the power supply and robot with the card unplugged. Great, no smoke. Crapped myself on the solenoid engaging (I wasn't expecting it to be that loud). I also thought something was wrong with the speaker because the horn was stuck on. I later found out that this is normal although very annoying. The horn becomes silent after loading the LOGO software.
  3. Power on the power supply with the robot and card plugged in. Great, no smoke.

It took a little bit of time to get rid of those cob webs out of my head and refresh my LOGO language knowledge. While playing around I found that the Apple LOGO Tool Kit disk also contains Tasman Turtle LOGO commands but a more comprehensive version than the one I received with this robot. It contains commands to change the slot location of the robot interface card as well as the extra commands needed to drive the extended Tasman Turtle features such as the Electronic Compass. I didn't have to use LOGO. Using Basic or Assembly would have been just as suitable however because I already had the LOGO setup examples it fast tracked getting the turtle going.

Once that was done I was able to test out the robot's features. What I didn't realise is that during the smoke tests I had removed a screwdriver from my hobby box which was holding up the robot, allowing the wheels to move freely. Therefore the robot ended up being placed directly onto the table. My first test was the move forward command which worked well and all I saw was the robot heading straight for the table's edge. I jumped over the table and grabbed the robot just as it was heading over. The project was nearly finished even before it had a chance to get going. I'm lucky the robot is no speed daemon. The direction commands worked well. So did the horn, the solenoid (pen holder) and the bumper sensors but the two front lights would not come on. So at that stage the remaining tasks were to fix the lights and the bumper bar which was broken in two and twisted. I knew these issues were minor and that they were repairable but the problem was deciding on how these repairs were to be done. I'm sure it's a common dilemma when restoring an item and knowing certain parts are no longer available. Do you keep the item in its original state even if that means putting up with non working parts or do you replace the parts with reproductions, if available, or attempt to repair the items even if that means potentially destroying something in the process?



With the broken bumper bar I was considering replacing it with a newly constructed one made from MDF. MDF was the closest material I could think of which would be light enough (original bumper weighs just 128g), strong enough and easy to work with. I took the dimensions before attempting to restore the bumper in case I screwed it up. MDF would be my fall back in case I could not fix the original one. The bumper is made from a foam product that is set hard. The cross section looks like the honeycomb part of a Crunchie chocolate bar. I used a hairdryer to heat the material and bit by bit pushed the material back to how it was meant to be. Super glue was then used to join the parts together. Only time will tell if this is an adequate fix.



To investigate why the lights were not working I needed to disassemble the robot, not all the way but just enough to get to the lights. I used this opportunity to clean the robot and documented the printed circuit boards. The power was going to the lights so it was just an issue with the bulbs not working. I found the bulbs glued into the indicator light holders. This would help the bulbs from coming out due to vibrations but it becomes a maintenance nightmare. The only way I was able to get them out was by breaking the glass and using pliers to unscrew the remaining base. I damaged the light holders in the process. The light holders come in several sections and when they are all screwed together the broken section is not visible from the outside. I would rather replace the whole holder and I did attempt to contact the manufacturer but I'm yet to hear back from them. Incandescent light bulbs are also becoming difficult to source so I could have replaced them with LEDs but again I decided I wanted to be true to the original design. Since the UK still has a large doll house and model train market I was able to get the bulbs I needed by importing them.



A standard Input/Output card can be used to talk to the robot however it was nice having the Turtle Addressing Board so that I didn't have to go about working out all the connection cable wiring.



The connection cable is wired directly to the interface board. It was designed and built like this because the early Apple II models have the slot holes open at the top. It makes it a pain to use on the IIe and IIGS models because these have closed slot holes.

A quick video demonstration of the turtle can be found here https://docs.google.com/open?id=0B5PVarmqxaOnLVQxNVp1U2EwTE0.

I was going to complete this blog at this point but I thought how wonderful it would have been to have included the extended options that were available for the robot, like the Turtle Talk Board and/or the Electronic Compass. Obtaining information on these proved even more difficult. Sometimes Google just doesn't have all the answers but it does provide leads. I was able to do research the old fashioned way and that was to let my feet do the walking. I ended up at the State Library from which I was then able to access old magazine articles. From these articles, along with the LOGO software examples which I already had and a bit of re-engineering thrown in, I was able to piece together the schematics for both boards.



The electronic compass isn't really a compass. Not in the same sense that we would consider an electronic compass these days. It's just sixteen LEDs from which one is lit up based on a four bit number that is supplied to it by the computer. It's up to the computer and the programming language to keep track of the compass direction based on a starting location, usually just the initial power up location. I've created a functional equivalent schematic but it would be nice to find information to see how it was actually done.

The turtle talk board is based around the National's DT1050 Digitalker. This was one of several affordable speech chips from the early eighties. The other two big ones being the Texas Instruments' TMS-5100 which ended up in the "Speak and Spell" products and the Votrax's SC-01 which in an updated form ended up in the Sweet Micro Systems' Mockingboard cards. The Digitalker has the best sounding speech but at the cost of needing more storage then the other methods. However, only a modest amount more. From the top view of the PCB, partial schematics and LOGO software examples I was able to pull together the schematic for the board which I believe is pretty close to the original. I would love to find the bottom section of the PCB so I could verify my assumptions. If anyone can help out then please contact me. Otherwise I'll just have to build the card and debug it on the fly. Thanks to Jonathan I also have the standard ROM dumps SSR1 and SSR2 however I would love to get my hands on the extended ROM images SSR5 and SSR6. Maybe these will turn up one day.

Here is an attached file with schematics and pictures of each board, disk images, Tasman Turtle manuals, LOGO tutorials and more. Hopefully enough information to get any other Tasman Turtle restored to working order. https://docs.google.com/open?id=0B5PVarmqxaOnWXVlZlJFNU5Mem8

In the end, not only did I get to see a working Tasman Turtle but I got to restore it, program it and play with it. The perfect outcome.

Saturday, May 21, 2016

Apple II 4play Joystick Card RevB





Introduction:

The original 4play card was built around Atari joysticks. They were the only digital joysticks that I was familiar with and had access to. For a game like Kaboom! and the few games that I converted, this was more than adequate. However through discussions, two main issues were brought to my attention that I had not considered. One was with the renewable supply of cheap digital controllers and the other was the fact that playing with dual trigger joysticks was ingrained into Apple II culture. I looked into these issues and found that it would not be too difficult to modify the 4play card and address these limitations. A large supply of today's digital controllers could be used directly as well as still supporting many of the classic controllers. Also by looking more closely at the newer controllers I found that in their backward compatibility modes they support two triggers thereby being able to cater for the second issue. Since I only had a few pre-production cards they were all converted to 4play RevB.

To obtain the best possible experience from the 4play card it's important to select the right controller. I wanted to see for myself what the supply of digital controllers was like so I got hold of a few to test out. Not everything stood up to my expectations. I've learn't a lot about the different digital controller formats and I found that controller quality can make a big difference to how a game feels.


4play RevB Specification:

The card can be used in any Apple II model that supports slots.



Joysticks supported (using the normal extension cables ie for 2 button controllers):-

Atari Joystick
  Up, Down, Left, Right, Trigger 1

C64 Joystick
  Up, Down, Left, Right, Trigger 1

C64 Extended Joystick
  Up, Down, Left, Right, Trigger 1

C64 Extended Joystick plus adapter
  Up, Down, Left, Right, Trigger 1, Trigger 2

Amiga Joystick
  Up, Down, Left, Right, Trigger 1

Amiga Extended Joystick
  Up, Down, Left, Right, Trigger 1, Trigger 2

Amiga CD32 Joystick (Red = Trigger 1, Blue = Trigger2)
  Up, Down, Left, Right, Trigger 1, Trigger 2

Sega Genesis (Maga Drive) 3/6 button Gamepad (Button B = Trigger 1, Button C = Trigger 2)
  Up, Down, Left, Right, Trigger 1, Trigger 2

Sega Master System Gamepad
  Up, Down, Left, Right, Trigger 1, Trigger 2

If you want schematics and more information on how the controllers work then these are great staring points.
General 9pin digital joysticks. http://wiki.icomp.de/wiki/DB9-Joystick

Amiga CD32 schematics. http://gerdkautzmann.de/cd32gamepad/cd32gamepad.html

SEGA Genesis (Mega Drive) schematics - 3 button. http://gamesx.com/wiki/doku.php?id=controls:megadrive_genesis_controller_3

SEGA Genesis (Mega Drive) 6 button specification. https://www.cs.cmu.edu/~chuck/infopg/segasix.txt

Building a card that reads all the digital gamepad buttons is certainly possible. However the hardware, firmware and software becomes more complicated. The aim of this project was to keep it simple and allow anyone to feel confident in adding digital joystick support to their software (not just the software developers).


Software:

Card identifier bytes :- $20, $20, $20, $20
Status byte (MSB to LSB) :- Trigger1 : Trigger2 : Not Used (always high) : Trigger3 : Right : Left : Down : Up

Trigger2 will be zero unless joystick supports two trigger buttons.
Trigger3 will be zero unless joystick supports three buttons and the three button extension cable is used.

A simple pseudo code example :-

S = 4 :Set the slot number, 4 in this example
J1 = 49280 + (S*16) :PEEK(J1) to get the status of Joystick 1
J2 = J1 + 1 :PEEK(J2) to get the status of Joystick 2
J3 = J1 + 2 :PEEK(J3) to get the status of Joystick 3
J4 = J1 + 3 :PEEK(J4) to get the status of Joystick 4

You can find programming examples here (including how to use the identifier bytes to work out which slot the 4play card is plugged into):- https://docs.google.com/file/d/0B5PVarmqxaOnRVQxT0FLQnNoYWc

Other uses for the card:

For those who tinker with hardware and can do their own modifications.



As a special case a three button extension cable can be constructed however it will not work with the active controllers ie the Amiga CD32 or the Sega Genesis (Mega Drive).

Joysticks supported :-

Atari Joystick
  Up, Down, Left, Right, Trigger 1

C64 Joystick
  Up, Down, Left, Right, Trigger 1

C64 Extended Joystick
  Up, Down, Left, Right, Trigger 1

C64 Extended Joystick plus adapter
  Up, Down, Left, Right, Trigger 1, Trigger 2, Trigger 3

Amiga Joystick
  Up, Down, Left, Right, Trigger 1

Amiga Extended Joystick
  Up, Down, Left, Right, Trigger 1, Trigger 2, Trigger 3

Sega Master System Gamepad
  Up, Down, Left, Right, Trigger 1, Trigger 2

The design of the card was left so that with a bit of soldering one could convert the card into a 32bit digital input card.


Controller Investigations:

Classic

The classic controllers (Atari, C64, Amiga, SEGA Master System) are still supported. To cover for a broader range of joysticks which would allow direct connection, a sacrifice had to be made and that was with the multi trigger C64 joysticks which will now require adapters to work. A small price to pay when you consider the up side.

Traditionally these are single trigger joysticks but they will still have their place. Many Apple II games are single trigger and some don't rely on the trigger at all. Then there are those games that only use the second trigger for auxiliary functions ie starting or pausing a game.

If you intend on using the 4play to play multi trigger games then take note when obtaining classic joysticks. Just because you see a joystick with two buttons does not mean you will be able to play multi trigger games. Many of the joysticks with multiple buttons are actually wired up using the one trigger signal to the computer. Unless you want to do you own rewiring to split the signals check carefully that your joystick contains the independent triggers.


Active Controllers: SEGA Genesis (Mega Drive) and the Amiga CD32.

I call these active controllers because unlike the passive classic controllers, which are just switches, these babies contain chips that allow them to operate in multiplexed and special serial modes. The 4play takes advantage of the backward compatible mode these gamepads contain. To do that these gamepad need to be forced into this mode by supplying power to the pin that would normally be trigger 3 pin in a classic controller.



My first purchase was a good quality second hand SEGA Genesis SGProPad gamepad ($18 plus postage from the UK). It works extremely well. None of the cheaper controllers come close to matching this one.



I tested a cheap SEGA Genesis clone gamepad ($5 including postage) and it does work however I would not recommend it. It feels horrible. The plastic is cheap and nasty, the buttons wobble, it's very noisy when the buttons are pressed and the cord length is very short (It's about 70cm long which is a lot shorter than all my other joysticks cables. Their lengths range from 1.2m to 1.5m). I thought I did well by not picking the cheapest of the bunch in this category. The picture in the Ebay listing showed a mode button on the top ridge of the controller which I assumed would result in a better built controller. Well, I got shafted. Mine didn't come with the mode button and I suspect it's just the same cheap controller like all the others in the extra low price range. I guess in this case I got what I paid for. Because the cable is so short, practically, you need an extension cable to go with it so by the time you do that you may as well have spent the same amount of money on a better quality controller.

After being disappointed with my last purchase I ordered a better quality SEGA Genesis controller ($13 including postage). This controller comes in the same looking box as my previous purchase except it has a label saying "Made in Japan" as opposed to "Made in China". If this controller ever arrives (it's been five weeks now) I am hoping this controller will rival the SGProPad.

For the SEGA Genesis controllers the trigger 1 button is button B on the controller and trigger 2 is button C. You may be wondering why it's not buttons A and B. Well I was wondering the same thing. It's just how the designers of the gamepad decided to make the controller work in the backward compatibility mode.

Jesse tested an Amiga CD32 compatible controller for me and from all accounts it works great. Thanks Jesse.


Custom

Even though the SEGA Genesis controllers are a great option I wanted to see how easy it would be to rewire a USB or a proprietary gamepad into a standard Atari joystick configuration. I wanted at least one controller with three trigger buttons in case an application for a three button controller ever arose. Note: To use three triggers a different connection cable going from the 4play card to the gamepad is required.







I picked up a USB gamepad of Ebay ($4 including postage) in the hope of easily rewiring it. I cut the end of a serial extension cable and used it to replace the USB cable from the controller. I wish I could say that it worked well but I can't. The plastic case didn't feel all that bad however the buttons didn't work well. I found that I had to press the buttons harder compared to other controllers. Pressing on the bottom half of the trigger button worked well however pressing the top half did not work at all. The wires I added were interfering with the membrane so I tried moving them from the copper side of the circuit board over to the other side but that did not help. I tried cleaning the contacts with PCB cleaner but that did not help. I tried adding an extra layer of contact paste to the membrane but that did not help. I tried moving the wires away from the contact points but that did not help. I tried replacing the membrane buttons with others that I found in my junk box but that just made things worse. It made the buttons sit at an angle. This last modification clearly showed me why it had not been working all along. The PCB board didn't line up with the controller case (the direction buttons were ok but the trigger buttons were way out). This controller is now destined for the bin but at least I'll be able to salvage the cable for when I get hold of a better quality SNES controller.


Arcade





I've been wanting to put together a handheld arcade controller for quite a while now. Especially one where I could set it up for 4way gameplay. I was going to use my ANKO controller and reuse it's tactile trigger buttons however I just couldn't bring myself to destroying a working joystick. I came across this brilliant build and constructed it using similar components. http://dannygalaga.com/db9.html. I've been looking at these project boxes for decades but never considered using them to house an arcade joystick. Not until I saw this write up. To be able to configure the josytick for 4way action I purchased the Sanwa JLF replica from here http://www.ozstick.com.au/product/sanwa-jlf-joystick/. The joystick is a bit larger than the one used in the example so it was a bit more difficult to get it to fit. It did fit but with no room to spare. I added a switch to the back of the joystick so that I could swap the buttons around. I'm stoked with the final outcome. The great thing is that it also doubles as my MAME controller (using a simple digital to USB converter).


Conclusion:

Thank-you to everyone who helped out.

Jesse has released Kaboom! v1.03 to support the new card revision. You can find it here:- http://www.ninjaforce.com/html/products_kaboom.html.

Now that I have that out of the way I can concentrate on getting a batch of production cards made up.

Thursday, April 28, 2016

Apple II 4play Joystick Card





Introduction:

The 4play card plugs into any Apple II model that contains physical slots. Each card allows up to four digital (Atari configured) joysticks to be connected.


Background:

When was the last time you played a simultaneous multiplayer Apple II game with a group of friends? Was it on a keyboard with everyone squeezed around, each player trying to keep to their part of the keyboard or was it using the dual analog joystick configuration? Simultaneous multiplayer games give players a totally difference experience compared to single player games. The head to head challenge and comradery can lift gameplay to a whole new level. I've got great memories of doing this on other systems like arcade machines, home consoles (Nintendo 64, Wii, XBox), home computers (Commodore 64) and even on a Nintendo Game Boy using a link cable but not on the Apple II. I feel that the Apple II has always been lacking in this area.

The Apple II is designed with analog joysticks in mind but this doesn't stop it from supporting a multiplayer setup. In fact two joysticks can be connected using a Y splitter cable to give you that function. However, I'm only aware of a few games that took advantage it. One on One, SPY vs SPY and Superstar Ice Hockey are the few that come to mind.

Using special adapters the Apple II also supports digital joysticks. Several different methods have been derived to perform this task. A popular method was to map the digital signals to the analog axis limits. The beauty of this method was that certain games would just work with no software modifications required. The PQ Party Game system took this method a step further and instead of mapping the digital signals to the analog axis limits it instead divided up the analog ranges into multiple digital signals. This resulted in sixteen different digital positions ie four buttons for each of the four players. The big problem with all of these methods is that they are using the analog part of the game port interface. The analog interface is very slow compared to being able to drive digital signals straight onto the Apple II bus. For most cases this results in a practical limit of two simultaneous players.

Another common method of using digital joysticks with the Apple II is called the Atari Joyport option. This method uses the digital section of the game port interface. It uses multiplexing to turn three inputs and two outputs to obtain the ten digital signals required for two player gameplay. The games needed to be specially programmed to perform the multiplexing. There are quite a number of Apple II games which provide this option but due to the digital limitations of the game port interface this method is also limited to only two digital joysticks. It also suffered from a case of bad luck when the Apple IIe computer was released because the Apple IIe self-diagnostic test conflicted with the Joyport hardware. You can find more information on this method in this previous blog entry. http://lukazi.blogspot.com.au/2009/04/game-controller-atari-joysticks.html

The next logical progression would have been to use digital joysticks via the peripheral slots. There were digital joystick interfaces that took advantage of this. The one that I can think of is the Digital Joystick Interface by West Side Electronics. It only supported a single digital joystick but it was able to be used with either interrupt driven or polled communications. However I don't know of any commercial software which supported this setup. Why wasn't more effort put into supporting this type of interface method? In my opinion this is one of the easiest of hardware modifications you can do to a computer and the simplest in terms of software support. Perhaps it was due to the fact that there were different digital standards around and no one really knew which one would win out, or perhaps the chicken and egg problem played a big part ie most people would have had analog joysticks and the software base for analog joystick support was so extensive that also supporting digital may have been considered too big of a leap. I believe that digital joystick systems could have been supported with more ease than what most people realise.

Fast forward thirty odd years. Why would anyone be wanting to introduce yet another digital joystick interface at this point in time. Well, basically because none of the existing methods can provide four player gameplay. In early 2015 the group Ninjaforce released the long awaited game Kaboom! (a Bomberman clone). It was at the last OzKest gathering that we were given the opportunity to take advantage of this game's multiplayer features but I was disappointed in seeing this game being displayed more as a demo than the great multiplayer experience that it should have been. The keyboard interface just wasn't inviting enough to make this game shine to its fullest potential. I slept on it but didn't do anything about it. A few months later I attended a local Commodore 64 games night that is held annually. At this event I ended up playing Bomberman with a group of friends for a good part of the night. After that I wanted to give Kaboom! the interface it deserved.



If one was going to build a multiple joystick adapter, for the Apple II, that currently is not supported by any software where better to start than a blockbuster title and where software is still fresh in the developer's mind. I contacted Jesse from Ninjaforce to see if he was up for the project. He loved the idea so over several emails we worked out a design that both of us were happy with. I built the prototype and after a few hiccups it worked just as expected. The next problem was to get the solution to Jesse so he could test any Kaboom! modifications. I wasn't confident in the prototype surviving the trip so the other two options were to develop the card in an emulator or to build another card and send that. I was worried about timing issues popping up if choosing the emulator option so instead I concentrated on getting another card made. It was the right call as we did have some trigger debounce issues to sort out later on. The card is a really simple design so I took the opportunity to develop my printed circuit board design skills as someday I would like to get some of my other projects developed as well. The PCB was designed and sent off to a board manufacturer. When the boards arrived back I soldered one up only to find that it did not work. I was spitting chips (not literally) when I realised that I had made a schematic error that flowed through to the PCB design. I'm glad now that I only ordered a few boards. A short modification later and the card was working as expected. Off to Jesse it went.    




Debounce timing if required needs to be done in software.


Hardware specifications:

The hardware design of the card is extremely simple. It's a straight forward 32 bit digital input/output card with the output part stripped out. Cables have been added to support the Atari style digital joystick format. Due to popularity of the Atari/Commodore computers as game machines the Atari digital joysticks are still readily available, either in their original form or reproductions sold by third party manufactures. It was decided that the card should provide power for joysticks with auto fire and support joysticks with two/three fire buttons. Not that Kaboom! would need this but any future games should be given this option. We decided to build the card using simple TTL logic (as opposed to using chips such as the 6522 VIA) so that the boards would be easy to maintain, the replacement parts would be available for a long time to come and software would be easy to configure and program for.


Schematic of the Apple II 4play Joystick Card including supported joysticks and adapters.

The following is a list of joysticks and their supported functions:-

Atari Joystick
  Up, Down, Left, Right, Trigger 1

C64 Joystick
  Up, Down, Left, Right, Trigger 1

C64 Extended Joystick
  Up, Down, Left, Right, Trigger 1, Trigger 2, Trigger 3

Amiga Joystick
  Up, Down, Left, Right, Trigger 1

Amiga Extended Joystick
  Up, Down, Left, Right, Trigger 1

Amiga Extended Joystick plus special adapter
  Up, Down, Left, Right, Trigger 1, Trigger 2, Trigger 3

Amiga CD32 Joystick
  Not supported without an adapter

Amiga CD32 Joystick plus adapter (see above schematic)
  Up, Down, Left, Right, Trigger 1

Sega Genesis (Maga Drive) 3/6 button Gamepad
  Not supported without adapter

Sega Genesis (Maga Drive) 3/6 button Gamepad plus adapter (see above schematic)
  Up, Down, Left, Right, Trigger 1, Trigger 2

With more adapters other digital joystick standards may also be supported.

Note: When processing extended triggers the logic is inverted compared to Trigger 1. This is the result of how the Commodore 64 joysticks were wired up (digital signals were made from the POT pins). If using Amiga joysticks then the standard ones will work fine since they are wired in the Atari joystick format. Some Amiga joysticks have multiple buttons but these buttons are all wired to the Trigger 1 pin. These joysticks are ok use as well. However the Amiga joysticks that have been modified to provide extended triggers will not function correctly. This is because the wiring on the Commodore 64 extended triggers is different from the wiring on the Amiga extended triggers. You can plug these Amiga joysticks into the 4play card and it will not damage the card. The directions and Trigger 1 will work correctly but the extended trigger buttons will not function. Special adapters can be used (placed in between the specific Amiga joysticks and the 4play cables) if one would like to add the extended trigger functionality.

Different joystick standards can be supported via adapters. By not trying to support every digital format with the actual card allows the hardware to stay simple. The Amiga CD32 joysticks fall into this group. These joysticks are part digital and part serial therefore a special adapter is required to lock them into working as digital joysticks. The Sega Genesis (Maga Drive) 3/6 button gamepads use multitasking to read more buttons than there are lines going to the computer hence this gamepad requires an adapter to keep it sending only one set of signals which results in the Atari joystick format plus and extra trigger.


Software specifications:

To read the card, the first address of each slot is $C0N0 where N = 8 + slot number. (Slot1 = 49296, Slot2 = 49312, Slot3 = 49328 etc)
Joystick 1 is read from the first byte address, joystick 2 is read from the second byte address etc
The bit representation of each joystick is as follows :-

Bit 0 = Up, Active High
Bit 1 = Down, Active High
Bit 2 = Left, Active High
Bit 3 = Right, Active High
Bit 4 = Not Used, Always Low
Bit 5 = /Trigger 3, Active Low
Bit 6 = /Trigger 2, Active Low
Bit 7 = Trigger 1, Active High

The default value for each joystick is $60 (96 in decimal) ie a joystick that is not being used or an empty joystick port.

So to test which slot the card is in you just read the first four consecutive addresses for each slot and test to see if they all equal $60 (96). If peek(49296)=96 and peek(49297)=96 and peek(49298)=96 and peek(49299)=96 then the card is located in slot 1. If the joystick card is in slot 1 and you want to find out if the trigger is pressed on joystick 2 then you would read the byte using peek(49297). If bit 7 of this byte is 1 then the trigger is pressed. That is as complex as it gets. Now who wouldn't be able to add that into their software?

I believe that modified or specifically written software that supports this card should be given compliance. For example, if it supports a single digital joystick then it should be 4play-1 compliant, if it supports two joystick then it should be 4play-2 compliant, and so on. Most of the existing Apple II software is single player so a label like this would have been unnecessary however I see this card as a multiplayer tool so being able to instantly determine which games you would want to play given the number of people you have about would be ideal. Game developers take note. The interface is now available so porting those multiplayer games to the Apple II may now warrant a new look in.



In looking at converting some old software I started with an old favourite of mine ie the game Star Blazer. It is easier to convert the keyboard handler of the game than it is to convert the joystick handler. All one needs to do is to find the keyboard entry point then just use a hex editor to convert the keyboard direction keys to the 4play direction positions. If you don't mind hard coding the 4play to a specific slot and selecting 4play operation by selecting the keyboard option within the game then this is an extremely effective hack. The resultant code is smaller than the original keyboard handler code so you can fit it all into the existing game memory. The picture above shows the original code in the yellow square and the converted code in the red square. Given a bit more time and a bit more memory a better conversion could be performed without too much more effort.

My next set of conversions were on SuperPuckman and Pac-Man (Atari version). I chose this software for a very special reason. Pac Man was one of several arcade games that were designed to be played using a 4 way joystick. I've yet to hook this up and see if I can replicate the way this game was meant to be played. A 4 way joystick mechanically limits only one direction to be active at a time (compared to a standard Atari joystick which is an 8 way joystick ie when you select a diagonal position two directions are sent to the computer simultaneously).


Conclusion:

The 4play printed circuit board makes it easy to resolder the few pull-down resistors into pull-ups so that with different attachment cables the board becomes a 32 bit digital input card.

In the attached file you can find the schematics of the 4play, Y cable and the Digital Joystick Interface by West Side Electronics. Disk images containing examples and converted software are also in this file https://docs.google.com/file/d/0B5PVarmqxaOnUUN6OVIteWFqalk.

This project took a lot longer to implement than I had expected. Thank-you Jesse for being there to bounce ideas off, your effort in converting Kaboom! and your patience.

Jesse has done a outstanding job of converting Kaboom! to be 4play-4 compliant. Not only is the gameplay converted but so is the menu navigation. This makes playing, configuring and starting games a breeze even if you are sitting back in your lounge chair, away from the computer. You can get the latest version of this amazing game here http://www.ninjaforce.com/html/products_kaboom.html.

Thank-you to everyone else who helped out with tools, advice, testing and the product release. Your time and effort is greatly appreciated.

As I write this blog I'm itching to get back to my testing (huge smiley face). Happy gaming.


Update 4th May 2016.

The schematics have been modified with the card now being able to support two triggers from the Sega Genesis (Megadrive) gamepad (via the adapter). We are also looking into other controller options.

Friday, August 14, 2015

A2 Serial Video to HDMI Converter - BBBlack




While the A2 Video Streamer boards were away at KansasFest I figured I would try and answer a question I had been given and had pondered over for while. Is it possible to use the Raspberry Pi as a microcontroller instead of the FX2LP board and have it display HDMI? There are two main problems to overcome if using the RPi directly. The first is GPIO access speeds. To sample the A2 video stream you need at least twice the video frequency ie 28MHz. From looking around on the web this seems to be borderline capable. The other problem is that if using the Linux operating system which is not time deterministic then there is a good probability that you are going to miss samples especially when using sampling speeds in the MHz range. This results in a jittery picture. There is always the option of using a real time operating system on the RPi but is it going to have HDMI drivers for displaying the processed result? The other option which is more likely to work is sampling the data using an external device say the FX2LP and feeding the data through the USB port. In a similar project the BitScope people chose to do it that way (http://bitscope.com/pi/). That is the easiest way I can think of doing it. If using the direct method you would probably use a bus switch and a level shifter between the RPi and the external device anyway so how much are you really loosing by having an FX2LP do the job? Other groups have tried using different options like the high speed camera port but they have also come across limitations and have had to revert back to using the USB port (http://www.auvidea.com/index.php/theme-styles/2013-06-22-21-23-34/raspberry-pi-hdmi-in).

So what is the answer? Yes, it can be done but possibly not as directly or easily as one would have hoped for. The other answer is not to use a RPi at all but instead go with a BeagleBone Black.

The BBBlack is a credit card single board computer that is similar in concept to the RPi. Where the RPi is a personal computer reduced in size the BBBlack is more like a hotted up microcontroller. The BBBlack's video capabilities are not as good as the RPi's but it's the input/output capabilities that make it stand out. The CPU comes equipped with two high speed (200MHz) microcontrollers on chip called PRUs. These have been used to sample data up to 100MHz (http://beagleboard.org/project/beaglelogic/). If I was going to get a HDMI solution working, my money would be on the BBBlack.

That is exactly what I did. I was able to get an A2 serial video to HDMI converter working by using the real time capabilities of the PRU to sample data. I found that the CPU was not even needed, for a monochrome picture that is. The PRU can sample and dump the data directly into the frame buffer. The loop is tight with only 14 clock cycles available between sampled pixels but that's just enough to do monochrome video processing. For colour video the second PRU or the CPU would be needed. I suspect the CPU would definitely be needed if we wanted to render the output to look like these TV simulators http://wsxyz.net/applewin.html or http://bogost.com/games/a_television_simulator/.

Surprisingly I had more issues with the electronics on this project than the programming. It was recommended that any signals going into the BBBlack be suppressed while it was booting so a dual purpose device was needed, a bus switch for isolating the signals and a level shifter to convert the A2's 5V signals to the BBBlack's 3.3V inputs. At first I tried using a TXB0108 chip but the so called Auto-Direction Sensing capability caused havoc. Creating random garbage on the composite monitor and causing the IIc to reboot was not a good sign. I switched over to using the 74LVC245 chip which is great for level shifting at low frequencies but in the MHz range it passed the 5V straight through. I went back to using resistors for level shifting, like I had done on the A2 Video Streamer project, but left the 74LVC245 in there for signal isolation.

So is this the best way of making an A2 to HDMI video converter? I don't think so. Not unless you were going to build an all in one device where the BBBlack supplies multiple services such as video, serial, Ethernet and/or disk drive support to the A2. I have some more hardware on the way which hopefully can be used to build a simpler and even cheaper converter.

Digital to digital conversion is great. It gives you the option to view a prefect picture or view it rendered and made to look like the TV or monitor display that you remember. It puts the control in your hands for scaling and picture positioning on the screen. It should be cheap and relatively easy to build since there is no complex filtering or approximations to adjust and better yet it's not going to matter if you have an NTSC or PAL motherboard.

A quick video demonstration can be found here https://docs.google.com/open?id=0B5PVarmqxaOndHpZNVJldVZfdms.





Here are a few zoomed in photos comparing composite and HDMI. The photos don't do it justice. The HDMI picture looks much sharper on the screen than in the photos. It's also the case that the photos don't show how bad composite really is. In the photo you don't get to see the shimmer around the text next to the cursor and the fact that sometimes it can't sync correctly and displays random colours on a monochrome picture.



A cape was built to make it more user friendly. The application and source files can be found here https://docs.google.com/file/d/0B5PVarmqxaOnb3JoSlRra0RlcTg.