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 (, 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

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.

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

Now supports the SEGA Genesis Controller directly (no adapters needed) - two trigger buttons supported.
All 4play cards are being converted to 4play RevB.
Testing of the card and joystick/gamepad options are underway.

More Information Coming Soon.

Thursday, April 28, 2016

Apple II 4play Joystick Card


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.


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.

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).


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

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

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 ( 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 (

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 ( 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 or

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

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

Monday, July 20, 2015

A2 Video Streamer - Update

I knocked up a few Veroboard adapters to make the connections look neater. Initially the Apple IIe version was wired up in the same way as the IIc version (but using the appropriate auxiliary bus pins) however I added a piggyback slot to the board after being annoyed with loosing the 80 column / double high-resolution capability. Screen scaling was fixed and so was the double high-resolution page shift. I also did up some schematics and documentation so that Michael could take the boards with him to this year's KansasFest.

Thursday, May 21, 2015

A2 Video Streamer - Colour

Just before OzKFest 2015 I had a quick go at adding colour to the A2 Video Streamer. It was obvious that it needed some work. So began my investigation. I started with double high resolution graphics because once this was working all the other graphics modes would work as well. This is an exercise  in TV/monitor emulation and the TV/monitor does not know anything about the Apple II's video modes. It just processes the signals as it sees them. Get the lowest common denominator right and the rest will follow.

A. Monochrome.                            B. Colour block per four pixels.     C. Cross A with B.

D. AppleWin version.

The above pictures show my first attempts at colour and the AppleWin version to aim for. Actually when using the IIc with a colour adapter and watching it on my 14inch Sony monitor I get a picture that is somewhere in between screen shots C and D. However for an LCD solution the AppleWin version should be adequate for now. The video signal clock is approximately 14MHz. It's different for PAL than for NTSC but the important thing is that the colour reference is always a quarter of the video signal clock. This gives us four pixels per colour (0000 for Black, 0001 for Red, 0010 for Brown etc.) which equates to 16 colours. Now if we cut up the monochrome picture, screen shot A, into four pixels per block and apply the colours to each block we end up with screen shot B. If we do the same except displaying the colour only where the signal is white we end up with screen shot C. The double high resolution of 560x192 in monochrome mode is reduced to 140x192 when colour is introduced. The Apple IIc and IIe reference manuals call this the effective resolution but they just leave it at that. However when you look at screen shot B you can see that it's very blocky and comparing that to the actual display, screen shot D, you see that there is more to it.

If we zoom into the bottom left corner of these screens. We can see how different they are. I have drawn circles showing how the AppleWin version is made up. In the middle circle we can see that the green and yellow colour is filled in as in screen shot B. The right circle shows how the blue is left thin like in screen shot C. The left circle shows how some colours can be transformed into other colours, which is unlike B or C. This evaluation does not show a clear relationship between the colours so more investigation was needed. Generation of these displays is a common problem among computer emulator developers so where better to start than the emulator developer forums.

From the information read I still did not have get a clear picture of how I was going to work out the colour relationship. Without having to trawl through emulator code or work out mathematical equations from first principles I wondered if there was a simpler way.

From Issue 89 of the Compute magazine, October 1987, I was able to get an article about Chrome which is "Double Hi-Res Graphics Commands For Applesoft" and subsequently the disk image from ASIMOV which relates to this article. This allowed me to generate a few test patterns in AppleWin. The test pattern for two consecutive blocks is inadequate in explaining the colour relationship but the test pattern for three consecutive blocks is spot on. Bingo. Every block of four pixels can be determined by looking at the previous block and looking at the next block. I was able to extract this information and place it into an array of 4096 elements. This is our lookup table. In the application I have optimised this lookup table for storage but I expand it to 4096 elements during the initialization routine. This allows simple and fast processing.

The above example is taken from screen shot B and how it is used to produce the colour as shown by the left most circle in screen shot D. In step 1 we lookup the colour blocks Black, Black and Magenta. This gives us 0000 (this is a hexadecimal number ranging from 0000 to FFFF. It represents the 16 Apple II colours for each of the four pixels) which we then colour in as Black, Black, Black and Black. In step two we lookup the value for Black, Magenta and White which returns 000D and we colour the next four pixels as Black, Black, Black and Light Blue. In step 3 we lookup Magenta, White and Dark Green which returns FFF7 and results in White, White, White and Yellow. The process goes on to complete the line and page. The result is a picture as follows.

Therefore with one extra lookup table and a bit more code we get colour output. I'm happy with the result and stoked with having achieved it with such a small amount of effort. Emulation of analog equipment such as monitors or televisions can get quite complex and requires a lot of computational power to pull off. Just check out the video rendering section of this Apple II emulator - OpenEmulator I may have to revisit rendering when it comes to optimizing a full screen display but that's something to worry about for another day.