Bluetooth Card - Proof of Concept

Bluetooth Card using the MP3 board and source code.

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.

CHED - Update

Project CHED (Combined Hardware Emulated Drives)

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

1. Saleae Logic 1.1.15 software from here http://www.saleae.com/downloads (no licence required to view data). 

2. CHED_MasterBoot.zip from here https://docs.google.com/open?id=0B5PVarmqxaOnUGJINWd4N2RsRkk. File contains :-
    a. Instructions.txt - Instructions on getting started.
    b. AppleIIDiskIIAnalyzer.dll - DiskII Protocol for the Saleae Logic analyser.
    c. MasterBoot.logicdata - Captured data from a real Apple II master boot disk. View using Saleae Logic 1.1.15 software.
    d. DiskIIDataStreamProcessor.mdb - Microsoft Access 2003 application for processing and viewing the DiskII data stream. You will need MS Access 2003 or above to run this application.

There is still plenty of work to be done. However, I am currently looking into another platform which, if it works out, could fast track CHED's development.

WALTR - Update

Project WALTR (Wireless, Apple II, Logo, Turtle, Robot)

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

  FMSLogo (free Windows package)
  Apple Logo II by LCSI [1984]
  Apple Logo by LCSI [1983]
  Terrapin Logo V1.0 [1981]

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.


Pen lifter.

I was lucky enough that several people have already constructed pen lifters for the S2 robot. It gave me plenty to think about. My inspiration came from these three implementations.
http://www.savagecircuits.com/forums/content.php?297-Episode-9-Pen-Lifter-for-Scribbler-Robots
http://forums.parallax.com/showthread.php?128367-S2-internal-Pen-Lifter-and-a-couple-questions-for-Phil
http://forums.parallax.com/showthread.php?138538-Advanced-S2-pen-lifter-kit

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.



All the project files are contained here. https://docs.google.com/open?id=1-13822jXvuGfinGyO7wEAGmBtdWIGXIo

WALTR - Introduction

Project WALTR (Wireless, Apple II, Logo, Turtle, Robot)

From my early computing days I remember wanting a computer controlled robot (either a turtle robot or a robotic arm). Robot control using home computers started becoming popular in the 1980s however not popular enough in my part of the world as the only ones I ever got to see were the ones in magazines. They were very expensive and since we were unable to afford an original Apple II the chances of getting a robot was even more remote. Over the past few years I have been getting back into the Apple II world and my desire to obtain or build a turtle robot has grown.

I considered purchasing an original turtle robot but they are still very expensive due to their collective appeal. If you can find one they are most likely incomplete and/or require restoration. Rebuilding one from scratch using the plans from magazines also sounded like a huge job. With today's cheap robotic toys I wondered if anything existed that could easily be retrofitted and made to work like an old robot. When I came across the Parallax Scribbler 2 (S2) I knew it would be a great fit.

I had other Apple II projects on the go but Peter's Logo presentations at the last KansasFest resparked my interest and I was pleasantly surprised that I was not the only one looking in this direction and wanting to find a solution.

When looking at the S2 robot it looked like lots of fun even without having it hooked up to the Apple II but I think I have learnt more in a shorter amount of time by having a defined goal. The bonus has been having other fun gadgets to play with along the way. To make the S2 into a Logo controlled turtle robot it was going to need a few modifications. The main one being a pen lifter. The horn, lights and touch sensors could be emulated by using the existing S2 objects. Finally, since I am not trying to build an authentic replica, in today's world a turtle robot would not be complete without having a wireless interface.




Serial wireless (Bluetooth) connection for the Parallax Scribbler 2 Robot.

When I first looked into making the S2 wireless I concentrated on finding something that would plug into the S2's RS232 port (like the IPRE Fluke). Basically I wanted to swap the programming cable with a seamless wireless alternative. The Bluetooth RS232 modules looked rather expensive so I looked around and found the less expensive XBee modules and Bluetooth TTL modules. My preference was to get Bluetooth over XBee so that one day I could control the robot using my mobile phone. Bluetooth TTL modules use the RS232 protocol but at the hardware layer they use TTL signals. They cannot be plugged straight into an RS232 port. TTL and RS232 use different voltage levels (TTL: Off = 0V, On = +5V. RS232: Off is between -3V and -25V, On is between +3V and +25V). However they can be plugged into the S2 hacker port. The disadvantage was that the S2 could not be programmed wirelessly but it had several advantages. It was by far the cheaper option, it was hidden away inside the S2 case and it bypassed the RS232 hardware layer so potentially could be run at higher speeds.

I didn't know much about Bluetooth communication before I started this project and the funny thing is that I still don't. That is the beauty of these modules. The setup is miles easier than trying to pair a Bluetooth device with a computer. The default settings are adequate for a serial connection and the only setting that I needed to make was to the working mode. By default the modules come preprogrammed as slaves so I needed to change one of them into a master. This was achieved by connecting the module up to the "USB to TTL converter", setting it into AT Command mode and sending it "AT+ROLE=1" using a terminal program (I used HyperTerminal). That was the PC side done.

The type of Bluetooth TTL modules that I purchased needed to work with five volt signals and the settings needed to be easily changed in case I did wish to learn more about Bluetooth and reprogram them so that they could talk with other Bluetooth devices. The connection of the slave module to the S2's hacker port was straight forward. To test the S2, via the serial cable and wirelessly, I used the demo code titled S2_test.spin. It's a great utility that allows you to test all the objects of the S2 including the motors. Only one line needs to be changed in S2_test.spin to make it work wirelessly ie "sio.start(s2#RX, s2#TX, 0, 19200)" to "sio.Start(s2#P0, s2#P1, 0, 9600)".

I was very impressed with how quickly I had the S2 moving about. The support for the S2 is amazing. A lot of low level functions have already been written for the S2 objects (speaker, motors, sensors, LEDs) so all one has to do is to include these and call the higher level functions. The serial protocol has also been written and there are plenty of good examples detailing how to interface with other objects like servos. I managed to get the S2 up and running in no time and my simple serial control test only takes around twenty lines of code (not counting the included libraries).

Parts
2 x 5V Bluetooth module ("Mini Classical Serial Bluetooth Module" from eBay) - WARNING, sleep mode, see next blog entry.
1 x USB to TTL converter ("PC USB to RS232 RS485 UART TTL Signal Converter New" from eBay)






Apple II Control

Once I had the control of the S2 down pat using the PC I moved over to getting it working with the IIGS. I had an adapter (IIGS Serial Mini-DIN 8-pin to RS232 DE-9) already made up from when I was using ADTPro to transfer disk images over to the IIGS. I made the adapter so that I could connect up the IIGS to serial devices that have the DE-9 connection.

The Bluetooth TTL module could not be plugged straight into the RS232 port. An RS232 to TTL converter was sourced to do the job. This converter and the Bluetooth module require an external five volt supply but an RS232 port can not supply power (not without software and hardware modifications) so currently I have it externally connected but I have plans to source the power from the IIGS. Once the hardware was setup all I had to do was use a terminal program (I used ZLink because it was the first one that I found lying around) to send the commands through.

There are a number of remaining sections to get working including the pen lifter and the interface with the Logo language. There are a few implementations of the pen lifter already constructed for the S2 so I have some examples to work with. The first lot of turtle robots for the Apple II used parallel cards for communication however I will be trying to get my robot talking via a serial connection. Finding a serial protocol that has already been implemented in an Apple II Logo program is proving to be a challenge.

Parts
1 x RS232 to TTL converter ("RS232 MAX232 COM Serial to TTL Converter Module Board" from eBay)