Apple II Projects

Friday, July 25, 2014

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 http://lgauge.com/ and http://www.burf.org.uk/%202012/11/24/lego-dacta-interface-a-vb6-control/. 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 :- https://docs.google.com/open?id=0B5PVarmqxaOnbVVDbmxVSk0xT0U
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.

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.

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.

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.

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 best place to get LEGO parts is to raid the kid's Technic sets. If that fails, then head straight over to BrickLink http://www.bricklink.com/. 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 http://www.brickowl.com/ and ebay http://www.ebay.com 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 http://www.toysperiod.com/. 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 http://www.brickforge.de/software/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 http://buildingoutloud.com/brickficiency.php 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.

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.

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.

Wednesday, May 29, 2013

I have finally got CHED to work. I did a working presentation at OzKFest (www.ozkfest.net) which was held on 27-28 July 2013. A summary of my presentation is as follows :-

There are many solutions providing mass storage for the Apple II. Many of them have come about since I began construction on my own solution. I have tried to list and classify the ones that I am aware of. You can see where CHED fits into the picture.

IDT72125 Parallel to Serial FIFO chip handles the read signal data because there is not enough CPU time left to bit bang this out of the Atmega128.

LCD and keypad allows selection of which disk files to use.

ATA hard drive stores the dsk and nib images under FAT32.

USB to IDE converter allows easy access to files on the hard disk.

Currently only the reading of disk files has been implemented ie writing to disk files is yet to come. The USB to IDE interface has yet to be implemented. Using SD media would simplify the design but I'm still committed to creating a more durable solution.

With this design I have found that the amount of memory has been limiting. More memory would allow a better implementation of FAT32 (specifically having directories) and implementing caching so that the hard drive can reduce the amount of reading it needs to do. Also adding a buffer between the LCD/Keypad and the Atmega32 would improve the feel of the user operation.

With these issues in mind I have embarked on trying a different platform to make things easier for myself.

I'm currently playing around with a Cypress Development board to see if I can improve on my previous design.

Friday, February 1, 2013

It wasn't until my last working IIGS Monitor died that I went looking for alternate solutions. In the meantime a composite monitor would suffice but for the long term an RGB solution was certainly needed. It's times like these that you consider the thought that you can never have too many spares.

I have included here a summary of links to several solutions. Each solution works in varying degrees compared to the original. To obtain an alternate solution the cost in time and money will greatly depend on what other resource you already have or can get a hold of easily.

After checking out the available options I decided that the best solution for me was to get a replacement monitor. Some solutions came close but nothing gives a picture that is as good as the original. I'm also used to having a monitor that looks like it goes with the other parts of the system, especially when it's on display. Being in Australia and needing the 240 volt version (A2M6014X), it was going to be very difficult to track down. These monitors don't come up for sale very often so while I keep my eyes out for a replacement I was going to try and repair the ones I already had.

The first thing to do was to get hold of some schematics. The closest I could come up with where the ones for the 110 volt model (A2M6014). The schematics are available from here :- http://apple2.info/downloads

I removed the monitor casing and the only circuit board that I had a clear view of both sides was the power supply. This was the section I was mostly concerned about so it was a good starting point. I compared the schematics and to my surprise I was able to follow along quite nicely. I was able to see where the 110 volt parts where meant to go because the circuit board had been designed for both 110 and 240 volt systems. The relevant parts were populated and the alternate power parts were missing but there was room for them on the board and the vias were there too. I quickly realised that the diagnostics and repair was beyond my current skill level. However I now had greater confidence in the possibility of getting it repaired. I wasn't going to pull the monitor apart any further so I don't know if the rest of the schematics matched my setup but I figured it would be pretty close.

I set about finding someone who was able to repair the units. My first thought was to find a TV repairer. All the ones that I contacted were not interested in repairing my devices. I did however manage to track down a repairer who specialised in arcade machines and he was located only a few suburbs away. His website is :- http://members.optusnet.com.au/~paul_ridgway/
He was keen on giving it a go. I supplied him with two faulty monitors, the A2M6014 schematics, a IIGS and instructions on how to perform a diagnostic self test (this displays a test pattern). I was hoping that, from the two faulty ones, he could get at least one monitor up and going. He blew my expectations out of the water when he informed me he had fixed both. He also had the pleasure in telling me that these monitors were designed to be worked on, the circuitry was straight forward and all the parts were still readily available or easily replaced with compatible components.

This was fantastic news. Now I'm back to where I wanted to be. However, I'm not ruling out the possibility that I'll find and use a great alternate solution some day.

Power supply board showing the space for alternate power components and a IIGS Monitor showing the self-test.

Update: 5th January 2015.

I was asked to help convert one of these monitors from a 110 to a 240 volt version. I took apart my monitor and documented the differences between it and the schematics that I had of a 110 volt model. I suspect it's just the power board that needs converting. Here are the details of what I could make out.

Thursday, July 26, 2012

At KansasFest 2009 when Vince Briel (of Briel Computers http://www.brielcomputers.com/) unveiled his MP3 card I was instantly captivated and eager to find out how this cool little card functioned. After learning its little secrets, like many of the other Apple II developers, I saw great potential for enhancing this card into other USB and serial communication uses. During the construction of WALTR, my wireless turtle robot, I had toyed with the idea of running the Bluetooth from a card inside the Apple II instead of the current external setup. There were many distractions to keep me from having a crack at it. That was until this week.

Since I was attending this year's KansasFest event I was asked by a fellow Aussie Apple II enthusiast to bring back one of Vince's MP3 cards. Since Vince did not have any pre-made cards remaining I signed myself in to the kit building session and put the card together. Vince had a few spare MP3 boards which I quickly snapped up. I put forward the idea of a Bluetooth card and after a quick discussion we realised we had the resources to pull this off.

The spare board came in handy (easier than starting from a Veroboard). The Bluetooth module part was sourced from my WALTR project and the rest of the parts were pulled from a few super serial cards. We had finished construction by the end of the kit building session. All that was left was the software and testing.

Unlike the MP3 card which shows a flashing LED when working, the Bluetooth module's working state can not be determined by just looking at it. It does have a LED but that's used to show the pairing status with the other Bluetooth devices. We needed to show that data could be sent over the medium. In WALTR's latest program changes I had one of the LEDs change colour depending on which mode is selected i.e. green equals LOGO and red equals direct control. This was going to be the test case. If the LED turned from green to red after sending the character "2" and a carriage return then we would have our proof of concept.

The following day, between sessions, we worked out what was needed to initialise the 6551 chip and the software was written on the Apple II to perform the test case. The theory was there but the card just would not work. We kept at it and it was way past midnight before we had any indication that we were close. We were delighted when the logic analyser showed pulses coming out of the 6551 chip even though they didn't look quite right. Also using the MP3 software to talk to the card, made WALTR's wheels go nuts. We struggled through the night. Finally at 4am, Eureka, we got the light to go red. So after running on empty, having floppy disk corruption issues, wiring issues, two faulty 6551 chips and programming hiccups it was finally done. It should have been difficult to fall asleep after being on such a high but I passed out faster than I could say "Good night".

Thank-you to my team members Vince, Wayne, Alex, George and Sean in getting this project completed in such a short time. It was truly a group effort. It seemed like the right people came together at the right time. It was great to see. I had a ball. Also a big thank-you goes out to all the KansasFest attendees who encouraged us throughout all hours of the day and night.

In conclusion, the card in its current state needs to be initialised manually (dedicated software). It would be nice just to be able to type "PR#2" and then be able to type in the transmission string. For this to occur, an EPROM would need to be programmed and added to the board. Also in this instance of the project we have demonstrated the use of Bluetooth however it would be just as feasible to use XBee or Wi-Fi. Even though KansasFest is over for this year I know that the brainstorming and discussions will continue and we will attempt to develop this hack into a functional product.

Sunday, June 3, 2012

It has been a while since I have worked on the hardware part of this project. A few months back I hit a stumbling block. The load on the microcontroller was too great when bit-banging the serial output and at the same time handling all the other tasks. To free up the controller I added a parallel to serial FIFO chip. Even though the bitsteam generated by CHED looked correct I was still unable to the get the virtual master disk to boot. With the tools I had at my disposal I was unable to pinpoint the cause of the problem. The logic analyser I was using was capable of high speed captures and was great for viewing the 16 bit data bus but it had a shortcoming. The buffer was too small for analysing data that had high frequency bitstreams on one channel but low frequency ones on another. The analyser software was also limiting when analysing non popular protocols. By changing a few settings on the standard serial protocol analyser I was able to get it to produce some promising results. Unfortunately only a few dozen bytes get converted before it looses the plot and produces invalid results. Some better tools were required if I were to continue.

I sourced a new analyser. It's not as fast as the other but high speed is not required when dealing with Apple II signals. The great thing is that it is not limited by its own memory. It uses a connected computer to store the captured data. The downside is only having eight channels but that should be enough for this project. The reason I selected this package was because of its great software development kit (SDK) that allows you to create custom protocol analysers. Using the examples provided it was not too difficult to create the AppleIIDiskII protocol analyser. Being able to the record the entire boot process was a fantastic sight to see. Seeing the results is one thing but interpreting the data is another. The data frame processing of the SDK is yet to be fully developed so my best option was to export the byte stream and process it myself.

I generated a simple Microsoft Access application to process the data and produce a sequential view of the information that is read by the Apple II. These two tools have given me a better understanding of what is going on. So far I have only captured the data from a real DOS3.3 master disk booting. I have yet to use these tools to diagnose my own device.

For those of you who wanted screen captures of the DiskII protocol I can go one better. You can download my tools and have a look at the data yourself. You will need :-

Wednesday, April 25, 2012

WALTR is a Parallax Scribbler 2 (S2) robot that takes in direct action or interpreted Logo movement commands via a serial connection and executes them. Although I designed WALTR to be run from an Apple II computer any computer with a serial port and a Logo software package that supports serial communications can be used. WALTR can still be used as a Logo robot even without its pen lifter and Bluetooth enhancements.

Overview of how it works (once the S2 robot is programmed up):-

WALTR in Logo mode.

- Start up your favourite Logo software package. (Only a few Logo software packages are supported at the moment. Each package will most likely need a different WALTR.LOGO file)
- Load in the file WALTR.LOGO. (This file opens the serial port and overrides the turtle graphics commands. Each turtle graphics command will perform its original function as well as outputting the correct serial protocol information to the serial port.)
- Type in the Logo commands or load in and execute your favourite turtle graphics file.
- WALTR listens to the serial port and waits for a command. When a command is received eg "$70 $00 $C8 $13" WALTR will execute it. ($70 or "F" = forward command, $00 and $C8 make up the distance of 200 units and $13 = command termination.)

WALTR in Direct mode.

- Open a terminal program like HyperTerminal or Parallax-Serial-Terminal.exe. (Currently all devices are set to communicate using 9600 baud, no parity, 8 data bits and 1 stop bit)
- Type "2" to turn WALTR into Direct mode. (Typing "1" will revert it back into Logo mode.)
- Type the required command ie "a" (forward), "z" (back), "," (left turn), "." (right turn), [space] (stop) etc.
- WALTR listens to the serial port and waits for a command. When a command is received WALTR will start and continue that command until a new one is received.

Logo control.

Each version of Logo contains different commands for interfacing with the serial port. Each version also has its own quirks and Logo commands that it does not support. Therefore the example files for each Logo version are different. These are the versions I have covered so far:-

WALTR is not an interpreter so it does not accept Logo commands directly eg "FORWARD 200" instead it accepts interpreted commands in a specific format which you can find in the protocol specification document. Currently the communications are in one direction, that is, to the robot. The problem with this is that Logo does not check to see if WALTR has enough buffer space to hold the sent command. The current buffer of 8192 bytes should be good for about 2000 commands. At some stage I plan to modify the communications protocol so that Logo can be informed as to when the robot is ready to receive information. This will allow WALTR to process an unlimited amount of commands.

In regards to the Apple II Logo versions, these needed a bit of work to get them going. I prefer using Apple Logo II because it is ProDOS based which means I can run it from the hard drive. Apple Logo and Terrapin Logo need to be run from floppy disks. These last two packages are screen based hence they only send out 7bits instead of 8bits per character. The robot code ie WALTR_r01.spin needs to be modified. I have provided a constant in the declaration section called FORCE_7BIT_DATA. This needs to be set to to TRUE if using WALTR with Terrapin Logo V1.0 or LCSI's 1983 Apple Logo. Terrapin logo V1.0 is the oldest of the Logo packages and the most difficult to work with. It does not support command overrides so new commands were created ie TPD instead of PD for Pen Down, TFD instead of FD for forward etc. It also does not support sending out the ASCII character $0 so a work around was required for this. When working with Terrapin Logo V1.0 the parameter TERRAPIN_V1 needs to be set to TRUE.

I have included instruction files and Apple II "dsk" files with the examples.

Direct control.

Direct control allows real time control of the robot. Direct control starts a robot movement then just waits for the next command. The robot keeps performing the command until a new command is issued. This allows WALTR to be controlled from a keyboard, mobile phone etc. The easiest way to control WALTR is to open a terminal program and just send the keyboard keystrokes. Alternatively I have provided a simple program showing how the robot can be controlled on an Apple II using a joystick. Again this program is screen based so the declaration FORCE_7BIT_DATA needs to be set to TRUE in WALTR_r01.spin.

Bluetooth issues.

The cheap Bluetooth modules that I purchased are specified to operate at 5V however the signal lines are still only 3.3V. There is a voltage divider on the back board however from my calculations it only reduces the signal by about 0.1 of a volt, nowhere near close enough to the 3.3V needed. Technically I should place some resistors on the module's RX line to protect it, but looking at other people's projects, this mostly goes unimplemented. These cheap modules seem quite tolerant of the higher voltage.

These modules have not stacked up as well as I had expected. The firmware on the modules has been programmed to use power saving mode. This feature places the module into sleep mode if no data has been received after a given amount of time (this is somewhere in the vicinity of 15 to 30 seconds). I found that I was missing characters during the time the module was coming out of sleep mode. I tried to disable this feature as per the manual but it did not work. I contacted the module manufacturer and they informed me that disabling of the power saving mode has not been implemented. To get around this issue I programmed a heartbeat into the communications driver ie a dummy character sent every few seconds to keep the modules from going to sleep.

For now the module is working, be it in a not so desirable way. I could try reflashing the firmware or desoldering it from the back board and replacing it with an alternate unit however if I had my time again I would probably try purchasing a more refined product like the ones from Sparkfun.

Wiring to the Bluetooth module was cleaned up and the Bluetooth module plug was hot glued to the robot's top casing. It's a nice clean fit and since the module is only attached by the plug I can easily replace it if required.

Serial to Bluetooth (for the Apple II).

I built a transparent container for the serial to Bluetooth module and constructed a plug that allows me to source 5V externally from the Apple II. The plug is just a straight through male to female DE-9 with the ground and 5V signals brought out. The plug gets attached to the Apple II's game port. The construction of the custom moulded plug allowed me to try a new product that I have had my eye on. The product is called Sugru. It's like Play-Doh but it sets hard after a day or so. Initially I thought that the product would set like concrete but I discovered that in fact it turns hard and has a rubbery feel to it like an eraser. That's not a bad thing. It makes it easy to trim with a hobby knife.

Custom moulded plug. Before and after adding Sugru.

Serial to Bluetooth converter attached to the Apple IIe and to the Apple IIgs.

After doing some testing I found that just one paper clip bent in just the right way could be used to hold up the pen. I was able to get away with not having to modify the S2 casing. However since there is only a small gap of about 3mm to 4mm between the top and bottom sections it took me many attempts to get it just right. The current ring will support itself in the pen hole once the robot is put together but it takes some effort when joining the top and bottom sections.

The up and down movement is handled by a "NARO" sized servo motor. I wanted to build a container for the servo so that I could replace it if needed. I wasn't going to bother unless I could find a light weight and easy to construct solution. Sugru came to the rescue yet again. I was able to mould a casing and trim it after it hardened to get the end result, a perfect fitting glove. Adding to the servo holder a bent paper clip, some Velcro and an elastic strap makes it all hold together quite nicely. I am extremely happy with the result. Tuning the up and down positions is very easy. You can hear when the paper clip makes contact with the case. Small servo adjustments are required until this noise is reduced or eliminated.

The pen holder ring in this picture is one of the initial unsuccessful ones.

Since I can't attach WALTR's source code and example files to this blog I have added them to OBEX at the Parallax website. You can find the link to it below. Enjoy.