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 560x191 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.

Sunday, April 19, 2015

A2 Video Streamer - Prototype


Whether it's a purchase of a computer without a monitor or that last composite monitor that bites the dust or changing screens as a space saving exercise, every vintage computer enthusiast will have to deal with the display issue at some point in time. As screen technology has progressed, video adapters have been built to take up the slack from dwindling numbers of original display monitors. Trying to adapt the old computer technology to new devices and produce respectable results has been a challenge for many enthusiasts. As a monitor replacement solution I believe that it's the tablet market that holds the greatest potential going forward. Devices such as the iPad with their well proportioned screen sizes and high resolutions are ripe for image manipulation and can produce fantastic results.

The A2 Video Streamer is an alternate way to display Apple IIc or IIe video. It's made up of hardware that samples and sends video signals over high speed USB and software which runs on a computer (including tablets) and interprets those signals to produce a perfect display, at the full frame rate, in an application window. All this can be achieved with low cost, readily available parts and a page full of control code.

The aim of this project was to obtain a portable display for my Apple IIc. I wanted to turn a luggable solution into a portable one. At first I was considering a hardware solution, like a composite panel however I could not find any information on anything that looked reasonable and I figured that there was a good probability that after purchasing several panels I still would not have been happy with the end result. This was way before seeing what Quinn and Javier had done with their systems. I considered other options too like the original IIc flat panels, DVD players and USB streamers. Nothing provided the results that I was after. I had an iPad sitting on the table and thought that it would make a great monitor due to its size and high resolution. I thought that it would just be an attachment that I needed but after looking into it more deeply I was shocked to find that it had no support for live video input.

Some further investigation turned up details on WiFi streaming and USB streaming. WiFi streaming looked like quite a bit of work to develop and I suspected that the lag would be quite bad. Considering that Apple II's are now mainly used for games the lag time is critical so I turned my attention to USB streaming. There weren't many solutions in this space but I did come across two examples that were implemented so I knew it that technically it could be achieved.

I wanted to see what signals I could get out of the IIc. I remembered how simple the circuit was on the IIc video port to component converter when I was looking into getting colour on a PAL Apple IIc. Compare the two schematics above. It looks so much simpler not having to deal with composite video. I set about to understand the IIc serial video signals.

Using an oscilloscope I checked out the signals and determined that they were ok for digital sampling. I was surprised to see the 14Mhz (approx) being displayed as a saw toothed signal. The trigger point could have been an issue but at least the error would have been consistent and worst case only be out by one clock cycle. It turned out to be just fine. On went the logic analyser and I tested the video to see if I could see the "HELLO" text as displayed on the monitor.

The sync signal was the first thing I checked. It turned out that the WNDW signal was simpler to deal with and so I didn't need the SYNC signal after all. Zooming in on the waveforms gave me a bunch of pulses at the top of the sync and then a bunch at the bottom. This corresponded with the text at the top of the page and the flashing cursor at the bottom. I zoomed in again on the first group and from the pattern I could instantly recognize it as the top row of the "HELLO" text. Some of the pulses looked thicker than they should have been but that was because the logic analyser did not have a sampling frequency of 14MHz or multiple there of. This will not be an issue once the Apple II video clock is used as a timing reference.

Once I knew that it was possible to get the video signal out of the IIc I had to find a way of displaying them on a screen at the other end. I needed a package that was portable and OpenGL fitted that very nicely. I became familiar with several methods of displaying test patterns on the screen of my PC. There seems to be a lot of OpenGL setup code needed just to get a simple 560x192 picture on the screen however it will come into it's own later when scaling and rendering the image.

The next step was to get the data to the PC. Since the video out of the IIc streams at 14MHz a microcontroller was needed with high speed USB capability. The Cypress EZ-USB FX2LP microcontroller (CY7C68013A) was the best choice, not only because it is an amazing bit of kit but compared to the other high speed USB capable microcontrollers the FX2LP is well documented and there are plenty of examples from the manufacturer and of personal projects. Because it's so versatile and flexible it can be quite daunting at first. I obtained the FX2LP chip via a development board from ebay for a few bucks. It's basically just a breakout board for the microcontroller and an EEPROM added for firmware storage (I use firmware loosely here). There are several ways of making the firmware operate. The program can be burnt into the EEPROM or another method can be used that makes this device awesome. By default the microcontroller comes with a very basic USB layer that allows an application to interrogate it and find out some simple details like the manufacturer name and device model number. This facility can be used to send it the firmware from the application. Imagine what this means for the developer. This means that the firmware does not have to be set in stone. It can be downloaded to the FX2LP every time the application starts up. This also means the FX2LP can be different devices to different applications. Say a video streamer today and maybe an Apple II joystick to USB connector for your favorite PC/Mac emulator tomorrow. I still haven't decided if I'm going to use the FX2LP in this way.

The easiest way for two systems of different speeds to communicate with each other is via a FIFO (First In First Out) buffer. This is another great feature of the FX2LP. The microcontroller has a FIFO buffer in parallel with the CPU. Once the CPU finishes setting up the USB communications it is no longer needed. That's right, when sending data over USB there is no CPU processing involved. Running this way is called 'Slave FIFO' mode and this is the method I have used for this project. This mode can be used because we are not processing the data on the FX2LP. There are other modes such as 'Ports' mode which is basically bit banging the Input/Output pins using the CPU and 'GPIF - General Programmable Interface' mode which is useful when communicating to more complex devices such as FPGAs, cameras, IDE drives etc and extra logic is needed.

Firmware: Keil uVision2               Tools                               Software: Microsoft Visual C++ 2008

There are many configuration options when setting up USB on the FX2LP so lets just say that if all the rules are not followed to the letter then communication just does not work.

Cypress provides tools for testing USB transfers but there is a lot of ground to cover before being able to use these tools with confidence. Most of the examples from the manufacturer use the Keil uVision programming environment but since the free versions are very limiting many people have converted over to open source environments. There were examples that I wanted to use from several projects but I didn't want to create multiple environments so I stuck it out with a limited free version of Keil uVision and hacked away until I got parts working that I needed. I experienced the same issue with the application side ie the Visual C++ 2008 Express Edition. Several Cypress examples that interested me did not compile with the free version. However, I wanted to stick with this compiler because I had the OpenGL working in it. Again code was hacked to get bits working.

There are two types of high speed USB transfers that can be used BULK and ISOCHRONOUS. Currently I have only been able to get BULK transfers working. This means that the application will work so long as the USB bus does not get overloaded. Keyboards and mice are not going to add too much extra traffic but add a few drives, a printer and a web camera and the BULK method will start to throttle back the available bandwidth for our application. This results in some interesting results like screen glitches. I plan to change to ISOCHRONOUS transfers at some point to guarantee a given amount of bandwidth at all times.

The FX2LP runs on 3.3V but even though the inputs and outputs are 5V tolerant and it will work without level shifting resistors it's probably safer to include them.

Sample format.

14MHz                  -> Clock

WNDW      Bit[0]   -> Line and page sync
SEROUT    Bit[1]   -> Data bit
GR            Bit[2]   -> Determines when to process colour ie mixed graphics modes
Spare        Bit[3]   -> Maybe for colour - CREF?
Spare        Bit[4]   -> Maybe for colour - TEXT?
Spare        Bit[5]   -> Maybe for colour - SEBG?
Spare        Bit[6]   -> Maybe for colour - LDPS?
Spare        Bit[7]   -> Spare

When the Window, OpenGL and USB code is taken out, the remaining code is quite short. The processing part is very simple.

    if (EndPt->FinishDataXfer(buffers[i], rLen, &inOvLap[i], contexts[i])) {
        BytesXferred += len;
        for (int iByte = 0; iByte < rLen; iByte++) {
            if (!bProcessData) {
                if (!(buffers[i][iByte] & 1)) {
                    if (iDisplayBlank > 8000) {
                        iDisplayY = 191;
                    else {
                        if (iDisplayY > 0)
                            iDisplayY -= 1;
//                    iDisplayX = -7; // 80 column setting.
                    iDisplayX = -13; // 40 column setting.
                    iDisplayBlank = 0;
                    bProcessData = TRUE;
                else {
                    iDisplayBlank += 1;
            if (bProcessData) {
                if (iDisplayX < 560) {
                    if (iDisplayX >= 0) {
                        if (!(buffers[i][iByte] & 2)) {
                            color[iDisplayY][iDisplayX][0] = 255;
                            color[iDisplayY][iDisplayX][1] = 255;
                            color[iDisplayY][iDisplayX][2] = 255;
                        else {
                            color[iDisplayY][iDisplayX][0] = 0;
                            color[iDisplayY][iDisplayX][1] = 0;
                            color[iDisplayY][iDisplayX][2] = 0;
                iDisplayX += 1;
                else {
                    bProcessData = FALSE;

Here are some results.

High Resolution Graphics and Double High Resolution Graphics

Notice how the double high resolution picture is shifted to left. This also occurs with 80 column text. At first I thought this was an issue with how I was processing the data but on further inspection I found the same thing was happening on my IIc monitor. Because there is a substantial black border around the picture it's not noticeable. It's only when you apply some tape to left hand margin and change from 40 columns to 80 columns you can see the missing 80 column character.

Monochrome text can be any colour including white, green or amber.

Colour display is still a work in progress.

Normal                                        50% Scan Lines
Will try and match something like AppleWin output.

Presentation was given at OzKFest 2015. Thanks Andrew for putting it up on SlideShare. You can find the link here
A quick video demonstration can be found here

Extra information :-

WNDW signal is good for synchronisation because it changes state just before the data begins but it can not be used to determine the end of line because it finishes before the data ends.

LDPS signal can be used to determine if 80 Columns/HGR or 40 Columns/GR is being used. Pulse is half the size for 80 Columns / HGR.

To determine which graphics mode is selected these signal lines are needed. Will this be needed for colour processing? I don't know yet.

Mode     TEXT      Mixed GR/TEXT       Mixed HGR/TEXT     HGR       DHGR
GR =      0           5/0                           5/0                           5           5
TEXT =   5           0/5                           0/5                           0           5*
SEBG =   pulse     5/5                           0/0                           0           0

* TEXT signal is high in DHGR mode.

Only few minor tasks still need doing. I've have them all done by next week. Only kidding.
  • Complete colour video processing.
  • Get ISOCHRONOUS transfers working.
  • Align 80 column text / DHGR with the other modes.
  • Build an adapter for the IIc video expansion port and one for the IIe expansion slot.
  • Scale up the size of picture and apply rendering to reduce pixelation.
  • Apply effects such as scan lines to resemble an original monitor.
  • For the USB library convert to using LIBUSB instead of CyUSB for greater portability. 
  • Implement an application on the Mac platform.
  • Implement applications on tablet platforms.
  • Options editor ie type of screen to emulate, RGB colour palette editor. 
Using SEROUT and accompanying signals is not difficult. I encourage you to give it a go. I’ve used this method to build a better streamer but I would like to see what others can do.

VGA cards like the Guimauve 2000 and Nishida Radio’s VGA options already process serial data. They use FPGAs to do the processing but what about using other devices such as a Raspberry Pi or a PSoC or a dedicated VGA chip?

I thought that video streaming to the iPad would take one to two days to set up. It has taken quite a bit longer and I’m only half way there.

Saturday, April 18, 2015

IIc PAL Colour

The PAL version of the Apple IIc only came out with monochrome output (at the RCA plug on the back panel and at the composite pin on the video expansion port). External circuitry is required to get colour. The external circuitry needs to interrogate the serial video signals on the video expansion port.

A number of adapters exist which use the serial video signals to produce a colour output.

The A2M4020 P/N 825-0830-A "PAL Modulator/Adapter" is not the adapter you want. This will generate PAL colour output but only from an NTSC IIc. Using a PAL IIc with this adapter will only produce a monochrome picture. Also the adapter only has RF (radio frequency) out so to display a picture it needs to be attached to a TV via the aerial connection (using an RCA to RF cable as pictured).

The easiest option is to get the A2M4023 "PAL Modulator/Adapter" if you can find one. The adapter has composite out as well as RF out. The problem is that these adapters are not easy to find.

If you fancy building a project yourself then check this out It's a IIc video expansion port to component (YPbPr) adapter. It's a relatively simple circuit and should produce a good quality picture.

Video 7 produced a couple of adapters but these are extremely hard to get a hold of and I didn't have any to test so I don't know if they will produce a PAL signal. The Video 7 Color Enhancer IIc produces digital RGB out while the Video 7 RGB converter produces analog RGB out.

There is another solution that I am playing with at the moment but that will be covered in the next few blog entries.

Friday, July 25, 2014

LEGO - LEGO's first programmable product

LEGO is among one of the world's most recognised brand names. Most people would be familiar with LEGO's passive building bricks but how familiar are they with LEGO's electronic products? When I think about electronics and LEGO I think about the upper end of the Technics range (more complicated LEGO sets based around gears, pins, rods and beams) or the MindStorms products (sets revolved around the concept of a small programmable controller allowing for robotic type creations). However, electronics and LEGO go back a long way, long before the release of MindStorms. In fact it was back in the mid 1960s that kits with motors began. As a kid I remember being very impressed by the LEGO light bricks and motor powered vehicles. It was something special compared to the other generic LEGO parts. You have to remember that going back a few decades the variety of LEGO building blocks was not like it is today and Technic sets were not all that common. These sets were powered by a battery pack (3 x 1.5V cells) resulting in the 4.5V standard which lasted in production until the mid 1990s. The sets included a motor or a light or both. It wasn't until around the mid 1980s that LEGO injected funding into extending the electronic product range and in collaboration with MIT (Massachusetts Institute of Technology) processes were set in motion that resulted in some fantastic products. These products are not limited to but include the initial Technic Control Center (4.5V) sets released in 1986, followed by the Technic Control Center (9V) sets in 1989, Control Lab in 1993 and then leading into the very popular Mindstorms from 1998 which is currently into its forth generation of products. LEGO's first programmable product, the Technic Control Center (4.5V), was built around the long running 4.5V standard and harnessed the processing power of the more common computer platforms of the time (Apple II, BBC Micro, Commodore 64, IBM-PC, MicroBee and a few others). Several commercial programs were available for controlling the equipment, LEGO Lines, LEGO TC Logo and then later LogoWriter Robotics.

The use of LEGO for home robotics started before 1986. In 1977 LEGO Technic was introduced and within a year gearboxes and better motors were available. Also from the mid 70s the micro computer market made great technological strides and so by the late 70s using LEGO for home robotics was certainly possible. However this was still the domain of the electronics enthusiast as controller\interface boards needed to be hand built and the computer manually programmed. What LEGO did with their first programmable product was to jump on the bandwagon of bringing this technology to the masses. It allowed a working robotic contraption to be built within hours not weeks or months and basically by anyone who could read a book and follow instructions.

The Technic Control Center (4.5V) series includes sets [9700-1]: Technic Control Center, [1090-1]: Technic Control I and [1092-1]: Technic Control II. However these are just the Lego brick sets and instruction cards. It gets very confusing because like many LEGO sets aimed at the education sector, to get anything going, you need a variety of different packages. In this case you would also need the computer interface card, a controller board, software (LEGO Lines, LEGO TC Logo or LogoWriter Robotics) and the teacher's guides for programming examples and tutorials. All these were sold separately. There were some sets called starter kits, such as the [951-2], which bundled all of this together. The 4.5V control series is not to be confused with the 9V control series which came after it. It is easy to do because the titles are so similar (9V series :- [8094-1]: Control Center, [8485-1]: Control Center II, [9753-1]: Technic Control Center I and [9752-1]: Technic Control Center II). The static bricks are compatible between the series but the electronic parts are not. The best way in trying to identify these sets is through the LEGO set numbers which I have enclosed with square brackets. Sometimes even this is not enough ie sometimes the Technic Control Centre set is denoted as [9700] and sometimes as [9700-1]. Also, some of the old LEGO numbers have been reused and now refer to newer Lego items.

I was interested in getting one of these sets up and going on my Apple II computer but the asking prices for the full kits was far more than what I wanted to spend. For this to work I needed to find a different source. After scanning the web every now and again over several months I came across a controller board which is the most critical part of the setup. The interface cable was missing and the power adapter did not suit my power sockets so by just taking the controller board saved me some shipping costs. The cable was easy to make up and I found a suitable power adapter in my junk box. To connect this to the Apple II I needed an interface card. I started the process of building the LEGO interface card myself as there is not much to it. It so happened that I found one listed and bought that instead. I purchased a few electronic LEGO parts off ebay and used my existing LEGO bits, not that I had much that was suitable, to build a few freestyle contraptions. This kept me happy for a while.

The Technic Control Center sets were only released via LEGO's Education arm (dacta) so in its day you were not going to find one of these sets at your local toy store. To begin with I wasn't looking at getting an entire set because I assumed the parts were difficult to get. How wrong I was. These kits were sold in huge quantities so there are plenty of the parts still around. Even the most useful part, the motor, by being available in many sets going back to the 1960s is still readily available in large quantities. The only problem is that the majority of these kits have been split up and sold off in pieces. The parts are obtainable but just not from one single source. I was able to obtain all the parts I needed for all three sets ([9700-1], [1090-1] and [1092-1]). To keep costs low I obtained mostly used parts and removed any duplicates between the sets. I still ended up with about one thousand pieces of Lego and even with shipping costs taking up about a quarter of all costs it still ended up being a fraction of the price that I have seen some kits go for. At times it was frustrating but just like most things, if you put in the effort (for the most part) you will be rewarded. Obtaining LEGO this way is not for everyone as it is a very time consuming process. Having purchased used parts as opposed to getting expensive new in the box sets I'll be more inclined to get the LEGO out and use it. I think Emmet would give that the thumbs up (if he had any that is). The following is a write up of my findings and challenges. I hope to complete it one day and keep it as a resource for others who wish to do the same.

The following is a breakdown of all the components of the system :-

1. Computing platform.

First thing needed is a computing platform. No points for guessing that my platform of choice is ... the Apple II. If an Apple II platform is used then it has to be one of the Apple II models that has an available bus for the interface card to slot into. That is if you want to use the commercial software that is available for the sets. Technically you could use the Apple IIc to control the LEGO but you would need to create a serial to parallel adapter and write your own software. If you don't have a real Apple II but you do have the Lego set pieces and the controller board then check out these websites and They shows you how to hook up to a modern day machine. Alternately, if you wanted a more compact solution you could interface straight into the LEGO controller by using a microcontroller board.

2a. Software - LEGO Lines. 

LEGO Lines is a software package that allows you to setup lines of commands which are then passed through to the controller board in sequence.

The components of LEGO Lines are as follows :-

    [950-035] LEGO Lines Teacher's Pack and Disc (APPLE II) 

Just for reference purposes [1455] is the BBC Micro version, [9536] is the Commodore version and [9537] is the IBM-PC version.

Since the Logo based software packages only came out on the Apple II and the IBM PC this software package was mainly used on the other computer systems because they didn't have a competing product.

The 5.25 floppy disk images and the manual can be found here :-
Only the "Teacher's materials" book is provided as it contains the contents of the "Resources booklet" and the "Classroom materials" plus a whole lot more, including a section on how to talk to the controller using Applesoft BASIC, machine language or LOGO II.

2b. Software - LEGO TC Logo.

LEGO TC Logo (TC stands for "Technic Control") is a cut down version of the LogoWriter software package but with the addition of the right extensions to make it interact with the interface card and ultimately the controller board.

The 5.25 floppy disk image and the manuals can be found here :-

The components of LEGO TC LOGO are as follows :-

    [952] Building cards for set [951-2] ([966] equivalent IBM-PC version)
        [198326] LEGO TC Logo - Teacher's Guide
        [198331] LEGO TC Logo - Reference Guide
        [198327] LEGO TC Logo - Quick Reference Guide
        [198323] LEGO TC Logo - Getting Started
        [198325] LEGO TC Logo - Teaching Turtle
        [198324] LEGO TC Logo - Making Machines

    or when purchase separately

    [9545] LEGO TC Logo Teacher's Pack and Discs (APPLE II)
    [9546] LEGO TC Logo Teacher's Guide (APPLE II)
    [9547] LEGO TC Logo Student Guides (APPLE II)
    [9548] LEGO TC Logo Reference Guide (APPLE II)

2c. Software - LogoWriter Robotics.

LogoWriter is a software package based around the Logo language but it contains a different working environment to other Logo implementations of its time. As well as the Logo interpreter it contains a word processor and allows for better integration of graphics and text. The first version of the software was released in 1986 but it didn't get the LEGO control extensions until the release of the LogoWriter Robotics version in 1988.

The components of Logowriter Robotics are as follows :-

    [907] LOGOWRITER Robotics - Apple IIe/IIGS 5.25" ([909] equivalent IBM-PC version)
    [908] LOGOWRITER Robotics - Apple IIe/IIGS 3.5" ([910] equivalent IBM-PC version)

If any one has the software and/or documentation for this software package then please contact me.

3. Computer interface for Apple IIe/IIGS - [9767] interface card.  

It's the controller board that does all the important work when it comes to controlling the LEGO parts and not the interface card. Instead of building different controller boards for each of the computing platforms, like what fischertechnik did with their competing robotic products, the designers here decided that they would build a universal controller board which was the workhorse of the set then develop a simple adapter for each of the computing platforms. Therefore the interface card is an Input/Output card that acts as an adaptor to the controller board. The beauty of this design is that after all these years it makes the LEGO version so much more obtainable than the fischertechnik alternative.

This card comes up on ebay every now and again but it is usually priced way above for what it actually is (probably because it has LEGO printed on the card and is for an Apple branded computer). If you have purchased the LEGO kit for one of the other computer platforms and can't get the IIe/IIGS interface card version or you just want to build the card yourself then please find the schematic here.

Instructions on how to install the card and test it can be obtained here :-

Just for reference purposes [9771-1] is the IBM-PC version of the interface card. The BBC Micro version was just a cable [9773] and so was the Commodore 64 version [9765].

4. Controller board - [70288] or [70455] LEGO Interface A.

The controller board, also known as the Interface A (Interface B being the controller board for the 9V series), contains the model number [70288] or [70455]. [70288] is the older of the two and contains LEDs that have a rounded top. The other contains LEDs that are flat on top and are flush with the casing. You will usually find these in the form of a kit [1093-1] or [9750-1]. These kits include the controller board, power adapter and the connection cable. If you can only get hold of the controller board itself then that's ok. The interface cable is easy to make and its parts are obtainable from any hobby electronics store. The cable is a straight through with 20 pin female sockets at each end.

The power requirements for the newer controller board are very versatile. It can take 7-15V AC or 12-24V DC and so long as it's rated 11VA or higher it will work well. Since the board has a bridge rectifier the plug polarity on a DC power supply will not matter. Note that the power requirements for older controller board are slightly different. I tried running the older controller using a DC supply. The outputs work but the inputs do not. The controller board comes up on ebay every now again. Otherwise there were still a dozen or so available from BrickLink (see section 5b below) last time I checked.

The control and the power circuitry on the controller board are optically isolated. It contains two digital inputs and six outputs (capable of being pulse width modulated) where each group of two outputs can be sacrificed for one bi-directional output. The board uses power transistors to do the switching which allows it to perform speed control of the motors. In contrast to many hobby controller boards and kits of the time which relied on relay technology.

Information on the setup of the Interface A can be found on these pages.
or here :-

I took the box apart and took a few snap shots of the board.

5a. LEGO parts - electronic.

With the release of these sets, new electronic parts were added to the LEGO brick family, the touch sensor switch and the optical sensor with its rotary encoder wheel.

    Output Parts
        [08010dc01] - Electric, Light Brick 4.5V 2 x 2 with 3 Plug Holes, Trans-Clear Diffuser Lens
        [6216m2] - Electric, 6216m2 - Motor 4.5V Type 2 for 2-prong connectors WITH middle pin

    Input Parts
        [x1167cx1] - Electric Touch Sensor Brick 3 x 2 4.5V Complete
        [x1161cx1] - Electric Light Sensor Brick 3 x 2 4.5V Complete, Optosensor
        [2958pb02] - Technic, Encoder Disk 3 x 3 with 4 Black Sections on One Side and 8 on Reverse Pattern

        [766c375] - Electric, Wire 12V / 4.5V with two Variable Color 2-prong connectors, 375 Studs Long (Tip color can be OldGray/Light Gray, Blue, Yellow, Black or Red)
        [766c14] - Electric, Wire 12V / 4.5V with two 2-prong connectors, 11 Studs Long
        [766c96] - Electric, Wire 12V / 4.5V with two 2-prong connectors, 96 Studs Long

Things to be careful of when looking at the LEGO set part lists on websites such as ToysPeriod. I think most of it is correct but so far I have come across some parts that are missing or incorrect in colour or incorrect in part number or have ambiguous part numbers. I will note the discrepancies that I find.

Part "[6216m] - Electric Technic Motor 4.5V" is ambiguous. It could mean "[6216m1] - Motor 4.5V Type 1 for 2-prong connectors WITHOUT middle pin" or "[6216m2] - Motor 4.5V Type 2 for 2-prong connectors WITH middle pin". The wire that comes with the kits is 2-prong with the extra plastic middle pin so the type 2 motor is required. If you have some of the old 2-prong wire without the middle pin then you can use either motor.

The light brick "[08010cc01] - Electric, Light Brick 4.5V 2 x 2 with 2 Plug Holes, Trans-Clear Smooth Lens" is listed as belonging to set [9700] but I don't think that is correct. I used "[08010dc01] - Electric, Light Brick 4.5V 2 x 2 with 3 Plug Holes, Trans-Clear Diffuser Lens" which contains the middle hole and matches the wire plugs that I have.

5b. LEGO parts - non electronic.

The best place to get LEGO parts is to raid the kid's Technic sets. If that fails, then head straight over to BrickLink Do not pass go and do not collect 200 dollars. BrickLink is a community of LEGO enthusiasts and has the biggest LEGO trading market that I have come across. From over two thousand possible vendors it has all the LEGO parts needed to create the Technic Control sets. I'll still look at other sites such as BrickOwl and ebay but I'll use BrickLink as a reference point to see if I can get a bargain. The issue with using the BrickLink marketplace is that it is very cumbersome to use. It's an interface you would expect straight from the 1990s and I can see how it would keep some people away. It is in the process of a redesign but the change over date has not been determined so I was not going to wait. It was well worth the effort in learning how to use the site.

My process of obtaining the set parts went like this :-

First of all I needed a parts list for each of the three sets and the most complete lists I could find were at ToysPeriod I know now that the ones at BrickLink are more complete but not by much. Putting these lists into a spreadsheet allowed me to remove duplicates between the sets. I also removed the parts I already had and parts that I had suitable replacements for like the minifigures.

The next step was to generate a .bsx file. This file is a structured XML file that is used by several programs when transferring LEGO part lists. I used BrickStore to generate the .bsx file of my required parts. I chose to set the condition column to "U" for used, otherwise the software that uses this list will only try and match bricks in new condition.

At this stage I could have used BrickLink to determine who had each of my required parts for the best price but each vendor has their own pricing list and each vendor only has a subset of the parts that I needed. What was needed was a way to trawl through the data and work out which parts could be purchased from which vendor at the most cost effective price. BrickLink does not provide this functionality but Brickficiency does just that. I loaded my .bsx file into Brickficiency and I let it do all the hard work. This software uses the latest vendor price lists from BrickLink (so long as you are web connected) to work out different scenarios based on some starting parameters. This program is not going to give you the correct answer first time around. It takes a while for the program to run (depends on the starting parameters) and it takes a bit of time to get the starting parameters right. My suggestion is to get a super computer to run this on if you can. The output gives you price lists including totals based on the number of selected vendors. The more vendors I selected the cheaper it was in parts but more expensive in postage costs. I factored in $10 to $15 postage per vendor which resulted in a sweet spot of five vendors.

Now that the list of vendors is determined you need to check the vendor information at BrickLink. Some of these vendors may not ship to your destination, some vendors may have a total buy price which exceeds your order price and some vendors may have lot prices which exceed your order price. If that is the case then you will need to add these vendors into what is called the Blacklist in Brickficiency's starting parameters and run the process again.

Once you have done this a few times and have not given up hope then you can go into loading the lists from Brickficiency into BrickLink. Creating a BrickLink WantedList for each list / order will make it easier later than only using the default WantedList. The loading into BrickLink process goes through a verification stage to make sure the part numbers are correct. I got stuck at this stage on a few items due to using the part lists from ToyPeriods. Even though it cost me some time I'm still grateful to those who have spent their time in compiling these lists and making them available. The second process is to create orders, one for each vendor. The process is tedious in itself because you have to match each item in your list to a lot number from the vendor. An item can have multiple lot numbers so you need to pick the best one. Sometimes the vendor has made a mistake and an item in the new condition lot is priced less than the old condition lot. Sweet, you pick the new condition lot. Other times you may find that the lot contains a description that the part is of poor quality or you wanted a quantity of two but you can only purchase the lot in quantities of ten. Also double check your order because the order may be missing parts if that vendor has sold the part in the time it took you to get this far. You may be able to massage your orders around a bit to get around these issues or worst case, which happened to me, is you may have to go back and rerun Brickficiency. These last few steps took me about two weeks, including learning how to use both systems, before I was ready to place an order.

Once the orders were placed it didn't take the vendors long to dispatch the orders and it wasn't long before I received them. I must tell you though that getting used LEGO parts was like getting a box of chocolates, you never knew what you were going to get inside, and it so happened that I did get some chocolate. There was some brown stuff stuck in one of the parts. I can think of some other brown things it could have been so I'm just going to stick with chocolate. Most of the vendors were spot on and most of the used parts were as good as new however one part was broken, a few were past their usable life, some were missing (vendor replaced with different colour or similar parts). Also one of the vendors was a heavy smoker. Out of a thousand parts and only having these few issues I thought was fantastic. At this stage I realised I was missing a few parts due to the initial incomplete list so I had to put in an extra order anyway which gave me a chance to reorder the problem parts. I washed all the used parts and they came up great.

Parts to watch
"[4459] - Technic Pin with Friction Ridges and Slots" should be changed to "[2780]- Technic Pin with Friction Ridges and Slots"
"[367a] - Baseplate 24 x 24" was missing
"[3743] - Technic Gear Rack 1 x 4" should be OldGray/Light Gray and not Black (if you are particular about using the original set colours)

6. Literature.

In terms of building the LEGO contraptions, I was creating freestyle contraptions until I was able to obtain the set's building cards.

    [9873] Building cards for set [9700-1]
        Set 9700 Activity Card 1 - General
        Set 9700 Activity Card 2 - Traffic Light
        Set 9700 Activity Card 3 - Car
        Set 9700 Activity Card 4 - Car Park Gate
        Set 9700 Activity Card 5 - Conveyor
        Set 9700 Activity Card 6 - Merry-go-round
        Set 9700 Activity Card 7 - Washing Machine
        Set 9700 Activity Card 8 - Turtle
        Set 9700 User Instructions

    [9874] Building cards for set [1090-1]
        Set 1090 Activity Card - Parts Tray Organiser
        Set 1090 Activity Card A - Ferris Wheel
        Set 1090 Activity Card B&C - Automatic door, Washing machine
        Set 1090 Activity Card D - Conveyor Belt
        Set 1090 Activity Card E - Robot Arm
        Set 1090 & 1092 User Instructions

    [9875] Building cards for set [1092-1]
        Set 1092 Activity Card - Parts Tray Organiser
        Set 1092 Activity Card A - Plotter
        Set 1092 Activity Card B, C&D - Traffic Sign, Scale & Metrics
        Set 1092 Activity Card E - Crane
        Set 1090 & 1092 User Instructions

    [959] Technic Control I Resource Guide

    [9761] ICC for IBM/Apple Computers (ICC stands for "Ideas for Communication and Control")

There are websites out there containing LEGO building instructions for sets. Great for getting freestyle creation ideas.

Here is one of my custom builds that I am working on. A single octave keyboard transmits keystrokes by multiplexing the signals through the LEGO controller and the TC Lego program plays the appropriate notes on the Apple II computer. You can see from the photos that not everything has to be a LEGO part. If you can't get the right parts then you can usually substitute by using alternate products.

Other robotic type retro LEGO builds can be found here:-

1. The robot book by Richard Pawson

2. Make and program your own robots : for the Sinclair Spectrum by William Clark (or the Commodore 64 / Vic 20 version)
Can be downloaded from here

3. Atari Robokit

4. [1038-1] ERBIE the Robo-Car

Extra info:


I find myself in a position where not only do I have some great sets to play with but I really enjoyed the challenge of putting it all together. It took me back on a nostalgic trip in several different ways. I was able to relive my LEGO days and also experience the time when not every consumer product is handed to you on a platter. Sometimes to get the things you wanted, you needed to work the system out, put bits together or even build it yourself. The road was not always easy but the journey was just as enjoyable as the end result. That is what I love about retro computing.

Enjoy and have fun.

Thank-you very much to everyone who helped out. You have helped in making this a great resource.