Thursday, December 8, 2016

Archiving "Convict" and dealing with data corruption




Every now and again I get asked to do archiving of Apple II disks for people who don't have their physical computers anymore. I've archived personal files, commercial software and even disks for court cases. In all that time I've never come across disk corruption when archiving disks for others. That is until now. These disks tended not to be the your everyday usage disks but instead the ones that got written to once and were stored away. So I guess the probability of corruption was low. Sure, I've had corruption on my own disks but I've always been able to work around it by having backups or having software that is readily available from other sources such as online archives. As time goes by and disk media degrades further, having a bit of knowledge on disk corruption can't be a bad thing. This is a write up of my experiences in rescuing a particular software package. I hope it gives others confidence in attempting to repair their own disks when needed.

A few weeks ago I responded to a request that came through from the Australian Apple II enthusiast's email list. Matt was looking for someone local to archive software that had been written by the local state education department. He managed to obtain the physical disk by contacting the developer. This software was used locally in schools so it was not wildly dispersed. I had a decent search for information about this software but I could't find any references to it. Since I have an Apple II system setup that can easily generate images from disks or the reverse I didn't hesitate to call and offer my assistance.



The disk that Matt handed me is the game "Convict" by Paul Holland. It comes in two parts. The first being the research part which I could best describe as an interactive history book. The focus of which is on early European settlement in Brisbane, Queensland, Australia. The second part is a penal colony simulator where your objective is to allocate resources and punishment in the pursuit of setting up and growing a convict settlement. Even before evaluating the contents of the material I prefer to do the copying. That way if the disk is fragile and on it's last legs this will result in extracting the best possible information before the disk gets any worse. So far this hasn't been the case. Most 5.25 inch disks that I have dealt with have stood up pretty well.

Side A of the software copied without a hitch. I was on a roll and thought that within a few minutes I'd be finished. Well that didn't go to plan. Side B had corruption. At first three sectors were showing up as containing errors. To my surprise, the more I tried copying the disk the better it got. It got to a stage where only one sector was showing up as being corrupt. I then tried using different disk drives and different software packages to copy the software but with no luck. The bad sector was there to stay. I wondered if this was a copy protection issue so I tried to run the software to see what I got. The software would not run. Not in the sense that it was broken but in the way that it gave me a warning saying "Do no Write-Protect Program Disk!". The software was protected from being run off this floppy. This was a master disk. This disk was meant to be copied and yet it was now corrupt.



Looking at the bad sector can be done with the software like Copy ][+ however I prefer to use more modern solutions like CiderPress and Omnivore because these reduce the high ASCII codes into lower ones which results in being able to view readable characters. Looking at the corrupt sector and surrounding sectors I could see that this area is comprised of text data. This means that restoring the corruption was going to be easier than restoring program data. The text would be instant confirmation that the reconstruction was moving in the right direction. With the corrupt sector itself I could see that the first few lines looked fine but then a third of the way through the sector it reaches the corrupted area.

I ran with what I had imaged in an emulator and the game was playable but I knew that at some point into the game it would either crash or display unexpected behaviour. I wasn't confident in being able to restore the disk as I had no idea as to how corrupt the data might be. However I decided that until I ran out of options I would give it my best shot.



I exhausted all the copy programs that I had available and since I did not have any specialist archiving tools such as a KryoFlux or an EDD Plus card (not that these would guarantee success) I went with the only option I had left. That was with a logic analyser and some software I had written four years earlier for diagnosing CHED, a floppy disk emulator, I had built at the time. The logic analyser samples the disk data that is being transferred between the Apple II and the Disk II while the software that I wrote processes and evaluates that bitstream.



While using a sector editor on the Apple II I was able to reread the corrupt sector (Track $18 Sector $C) at the same time as using the logic analyser to record the bitstream. The analyser records multiple input lines such as the stepper motors pulses, read request and write data however we are only interested in looking at one line, the data read line. I had already loaded the "AppleIIDiskIIAnalyzer" analyser into the logic analyser software so it processes the Disk II data bytes as soon as the data is sampled. This shows up as disk bytes above the bitstream.

I exported the disk byte data into a text file then loaded it into a Microsoft Access database application for processing. I've built the processing around a database and not just a text file so that I could view the data at each of the conversion steps. It also makes it easy for me to modify the data in the database to test different scenarios, without having to reload the data each time. After processing the data I found that I had gone backwards. The corruption was worse then before. The reason for this was that "AppleIIDiskIIAnalyzer" was treating the timings as being close to optimum like all the other disks I had played around with. However the "Convict" disk was different. The timings had greater variances.



To understand what corruption is and how to fix it the above two diagrams are the most critical parts to understand. Since I'm only dealing with fixing a single corrupted sector I didn't need to worry about sync bytes, the address field or sector skew (Dos 3.3 reads a physical sector then skips two physical sectors to give itself time to processes the data hence Dos 3.3 sectors are numbered differently to physical sectors) so if you wish to cover these parts of the disk II protocol then the best book to read is Don Worth's "Beneath Apple DOS". http://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Books/Beneath%20Apple%20DOS.pdf
I'll just be covering the data field. Each disk sector is just a stream of bits. "Convict" is a 16 sector per track disk (not the older 13 sector) so each disk byte is eight bits long, it always starts with a high bit and there can be no more than two consecutive zeros (absence of a high bit). Therefore all "AppleIIDiskIIAnalyzer" does to convert bits to bytes is to wait for a high bit at the start of the byte then process three different types of gap lengths (approx 3 microseconds to denote two consecutive high bits, 7 microseconds to denote a low bit and 11 microseconds to denote two consecutive low bits). Corruption happens when the magnetic structure of the disk is changed so that a high bit is read as a low bit or a low bit is read as a high bit (possibly less likely) or the gap length timings expand / contract. Once the disk bytes are calculated one has to look at the data field as a whole and follow the steps that the disk operating system would take to convert disk bytes into user bytes ie the memory bytes that the Apple II users would be used to when dealing with memory at the assembly language level or peeking / poking in higher level languages. The conversion process takes disk bytes, runs them through a lookup table with a one to one translation, exclusive ORs the result then performs a 6and2 prenibbleisation calculation. All these stages help in determining where the corruption is in the sector.

a. The one to one translation can help by determining if a disk byte is valid because it has to match only one of the sixty four valid disk bytes.
b. The exclusive OR step is probably the best at determining if corruption has happened because every byte is included in the calculation to determine the checksum.
c. The 6and2 prenibbleisation stage is helpful if corruption is contained to a small area because this stage splits the user bytes into different parts of the disk sector.

Because of the corruption in the data, when importing and processing the data bytes we end up with an invalid data field. The prenibble byte calculations get pushed past the checksum and field end bytes. To fix the field size I inserted in some dummy bytes to make the size equal 342 disk bytes plus the checksum.



I rewrote parts of the "AppleIIDiskIIAnalyzer" so that it was more forgiving on timings. What I ended up with was what had initially been produced by the copy programs.

To track the corrupt data all I needed to do was to find the bytes "6F 66 20 61 67" within the "Disk II Data Stream Processor". This I knew had been read without corruption. This gave me the start time of the data field within the bitstream recording. After counting 3 bytes for the data field header then 86 disk bytes which comprise of the compressed "0 0 C0 C1 B0 B1 A0 A1" bytes put me at the beginning of the user prenibble bytes. Traversing another eighty odd characters I arrived at the corruption area. Counting the bitstream bytes showed that indeed this was true. The "AppleIIDiskIIAnalyzer" has difficulty converting the bytes when it hits the bitstream containing the corruption. Looking further afield, the bitstream seems to suggest that the corruption is contained to one area and the protocol finally recovers towards the end of the sector.



To recover the bottom part of the sector I setup the processing to work backwards. If we assume the checksum exclusive OR result is zero and run the exclusive OR calculation in reverse we get the above result. Again I had to tinker with the "AppleIIDiskIIAnalyzer" timings to get a better outcome. The protocol does not recover straight way after the corruption area but a least we have a good chunk that can be worked out automatically. At this point we are left with just seventeen bytes to fix.



Still working from the end of the sector towards the corrupted area the rest of the calculations needed to be done manually. Out came the pen and paper. Working with two or three bytes at a time I was able to reconstruct the data all the way to the corrupted area.



The remaining eight bytes would end up being the most difficult to recover because the actual data was missing ie the disk was corrupt in this area. I placed a template of good looking bytes over the top of the corrupted bytes to give me an idea of how long normal byte lengths were. From this I continued to do byte recognition based from optimal timings. I was more confident over some bytes than others. I played around with different combinations until I stumbled across a solution that fulfilled the exclusive OR calculation. The displayed text was "caibu,ne". I didn't believe I had the right combination of bytes but the exclusive OR calculation worked. I could now turn off the reverse processing code and only deal with processing the data in one direction. The last two bytes made sense in the text so I was confident I was down to six bytes.



How hard can it be to brute force six bytes ie find every valid combination of data bytes? It turns out to be harder than it looks. The program is not just a bunch of "for" loops but instead something that knows the available disk bytes to use, 6and2 byte processing and the bytes it needs from the first 86 bytes of the data field. By brute forcing just two bytes I got a result that showed me sixty four possible combinations that satisfied the exclusive OR calculation. When four bytes were brute forced it generated a file that was half a gigabyte in size. It would have taken me months just to go through the results. I did notice that patterns were appearing in the output results and therefore I didn't need to process all six bytes at a time. In terms of just readable characters I determined that the lists (c,g,k,o,s,w), (a,e,i,m,q,u,y) and (b,f,j,n,r,v,z) could be used so I modified the program to output all the possible readable options. This didn't take too long and only took me about fifteen minutes to go through the results. The only word that worked well was "many" in terms of size and matching the existing converted text. Hooray that was the all the text worked out. I thought I was done.



Omnivore was used to fix the sector on the corrupted disk image. All I had to do now was to check and see if this worked. In the emulator I played the game several times and worked out where Track $18 Sector $C was being used. My celebrations were shorted lived. I realised that the fix did not work as expected. It didn't crash but it cut short the line in question ("build" was displayed instead of "buildings"). So even though the text was fixed, the character in front of the word "many" needed adjusting. I thought this character was a page or paragraph separator but in fact it must be some sort of length descriptor.



I changed the program to only look at solutions that contained the word "many" however it still produced a huge list of results that satisfied the exclusive OR test. I was lucky yet again. The corrupted sector and the text within it formed the part of the game where you were reading a letter (a message of your progress). After you read the letter you were asked if you wanted to read the letter again. I produced several disk images with what I thought may have been the correct replacement bytes. Back in the game I confirmed that I wanted to reread the letter and every time it showed me the letter I was able to swap another disk image and test out another option. Some options produced text but with incorrect line lengths, some options produced blank lines but one option got it spot on. Finally the right bytes were found and tested. I was able to use this same method to test the original disk and sure enough when the letter (message) was being displayed the hard drive generates that distinctive grinding sound and stops the program from continuing. When attempting to continue it keeps trying to reread the corrupted sector.





The images above show the six bytes used in the final cut and their results. I also generated a physical disk with the reconstructed image and then used the logic anlayser to read Track $18 Sector $C. The corrupted bitstream can now be compared with the reconstructed bitstream. The bitstreams do not differ by much. I knew that there were missing bits within the corrupted gaps however what threw me was the gap length variations. In hindsight it looks like I should have been able to reconstruct the bitstream without having to do the brute force option. Next time that may be the case.

You may be thinking this is all well and good but not everybody has a logic analyser. That's true but I think a device could be constructed for under $20 to do the job. I have used a Cypress FX2LP (a $10 breakout board) to sample video signals at 14MHz and send them over USB to a modern computer. To do the same with slow disk drive signals would be a push over. Think poor mans EDD Plus solution. This maybe a project I'll tackle in the future some day.  

The "Convict" software can be located here. https://docs.google.com/open?id=0B5PVarmqxaOnT2pJbGZZUUtfMkE
My tools can be found here if one wishes to check out the source code. https://docs.google.com/open?id=0B5PVarmqxaOnYmJ0cTFfaldyMEk

Good luck with you own endeavours.

Tuesday, September 13, 2016

Apple II 4play Joystick Card - Available




The printed circuit boards and parts arrived. I put a few boards together so that I could get a few pictures made up for the blog, website, kit construction instructions and to test out distribution options.



The only thing that concerned me at first was the rainbow ribbon cable I received from Futurlec. Compared to what I was used to, it was more rigid and transparent between the cores. Looking into it further I found that it has the same gauge, 28AWG, as the stuff I was sourcing locally except the insulation around the cores is reduced. It's more than adequate for the 4play card but I'm happy to use the more popular grey AWM2651 cable if one prefers that option. Just make a note when ordering. The locally sourced rainbow ribbon cable is roughly three times the price of the other two.



A fair bit of time was spent in trying to find cost reductions so as to make the product as affordable as possible. Some changes resulted in small savings but others surprised me as to how much of a difference they made. For example, by removing the non functioning gold fingers from the card's edge connector resulted in savings of more than a quarter of the printed circuit board's production costs. Also one of my pet hates when purchasing goods is unnecessary high postage costs. When looking at packing options for the 4play card I was able to determine that if the packaging was no more than 2cm thick then I was able to use padded envelopes instead of parcels to cut postage costs in half or even more depending on the destination. I'm hoping that by delaying the product's availability and time spent sorting everything out has payed off as I'm all for providing the best product at the best possible price.



My biggest dilemma was what to do about an ordering system. One thing about the retro computer community is that there is no shortage of examples. The variety of different solutions ranging from using the email system all the way through to full on web stores is amazing. I listed all the things I wanted out of the system and it became clear that the best solution for me was going to be a custom website. I just wasn't sure about how much effort was going to be needed to pull it off. I was already familiar with Blogger and found that people have used it to turn their blogs into web stores. I didn't want to go to that extreme straight away so after a crash course in HTML hacking and a weekend of playing around I managed to put together a webpage where I can customise the order to each customer's situation. It's flexible enough for any unexpected changes and it will be able to provide up to date product availability information. At this stage it's not capable of handling multiple products and it's not going to win this year's most impressive website award but I'm hoping it will be enough to get the job done.

The site is called "Lukazi's Loot" and the link to it is here. http://lukazisloot.blogspot.com.au/

I plan on keeping only the parts available on hand. Each card will be put together on an order by order basis so by doing this I'm hoping it will result in the product being available on a more regular basis than just being batch driven.

Construction instructions for those that wish to built the product themselves can be found here. https://docs.google.com/open?id=0B5PVarmqxaOnS2ZxZWRKSDg5WE0

In today's fast paced world where the norm is to find technology products being developed by large teams of people it's great to find a place such as the vintage computer community where one can immerse themselves into all levels of a product's life cycle, be it software, hardware or both and still have fun at the same time. I really enjoyed the experience of taking a product from concept to the final product stage but I could not have done it alone. Thank-you to everyone who provided assistance with the project, advice or just support.

Do yourself a favour. Experience something different.

Apple II 4play Joystick Card - Joyport Conversions


From the time I recreated the Sirius Joyport device (the digital joystick part of the card) in 2009 I have wondered if producing a Sirius Joyport clone would have been a good idea. Several people have asked me about it but I have turned them down. The Joyport works well on the Apple II and II+ machines but not on the IIe and IIGS which accounts for the majority of today's Apple II users (the IIc doesn't count because it can't use the Joyport ie it doesn't have the 16 pin Game Port socket). When attached to a IIe or IIGS the Joyport causes the machine to go into self test mode on reboot. This happens because the self test mode is tied to the Open and Close Apple keys / paddle buttons and the Joyport sets these paddle buttons to high by default. This problem is not only an annoyance but it could be causing the computer harm. I'm happy to take that risk with my own computers but I don't want to be doing that with other people's machines. There is no signal on the Game Port to let you know that the computer is rebooting so on my Joyport hardware I have added a power button. Even with this power button it's difficult to get into the habit of turning it off every time you want to reboot. The best thing I was able to come up with is possibly adding some sort of pressure pad where the joystick, when placed on the table, is powered off but when it's picked up it turns on.



While waiting for the 4play boards and parts to arrive I wondered if there was a better solution to the Joyport situation. Since I'm already communicating with Atari style joysticks using the 4play card I wanted to find out how difficult it would be to convert the Joyport games into being 4play compliant. It turns out to be very easy. I have converted a few of my favourite Joyport games to work with the 4play card. These programs include Boulder Dash, Boulder Dash II, Seadragon, Spy' Demise and Wavy Navy. So now there is an alternate way to enjoy these titles using digital joysticks. Not only have I converted the games but I have improved the functionality where possible. For example take Seadragon. This game requires two triggers to play the game. Trigger 1 is for torpedoes and trigger 2 is for the screen bomb. Since the Joyport is only a single trigger solution, to play Seadragon using that device you need to play with a digital joystick but use the keyboard for the second trigger. How annoying is that! I was able to convert Seadragon to use both triggers on the 4play device. 





Each conversion was different. Spy's Demise was the easiest to convert because it only uses the left and right directions for gameplay. Seadragon was the most involved only because I wanted to improve on the dual trigger functionality. Unlike Antoine's conversion of Lode Runner or Jesse's conversion of Kaboom!, I haven't written the code to automatically check for which slot the 4play is plugged into. All my conversions assume the 4play card is inserted into slot 4. If you're using a different slot then you will need to change any occurrence of the code "AD C0 C0: LDA C0C0" to what is required by the above picture ie if your card is in slot 7 then your code should read "AD F0 C0: LDA C0F0".

I would like to thank the developers of Ciderpress, AppleWin and Omnivore for making it easy for me to perform the conversions on a modern day computer.

You can find the converted disk images and the description notes on how the Joyport games were converted here: https://docs.google.com/open?id=1U2ZaPhB8TDHceTgKS-jVUeXZNNv4KEq7

Enjoy.

Update: 16th January 2017.

I have provided a link here from Brutal Deluxe Software which contains 8-bit routines to help with programming the card and also a patched version of Lode Runner: http://www.brutaldeluxe.fr/sourcecode/4play.html

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 gamepads 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". I've never used an original Sega gamepad so I can't compare it however what I can say it that it's not as nice as the SGProPad, but then again that is reflected in the price. Great mid range solution.

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.



After trying out several different controllers I found that I prefer the Nintendo style direction button layout more than the Sega one so I purchased some more SGProPad gamepads ($22 plus postage from the USA).


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.



After reading several reviews I went with the iBUFFALO gamepad. It's amazing how much difference a little bit of quality can make. I can't be happier ($10 plus postage from Japan).


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.