Amiga Bluetooth

Bluetooth came in around 1996 with Intel, Ericsson and Nokia developing a plan to standardize short range radio technology.

The A1200 and A600 were built with a PCMCIA 16 bit card slot and capable of supporting newer technology targeting laptops of the period before 32bit Cardbus tech was introduced. 

These Amiga models are capable of using these cards for exactly the same purpose, but no one wrote (at least survivable code) drivers to support. One of the reasons would likely be due to his period being the bankruptcy of Escom in 1996 just as Bluetooth was emerging. The other challenge would have been the task of building a suitable software stack when vendors were now targeting PCs x86. 

Out of curiosity, I wondered if this would be possible in 2024. What happens if a driver is built and a software stack is in place? Will the Amiga be able to match the capabilities of 1996-2000 laptop radio communication? 

Suitable Hardware

Many PCMCIA cards are now hard to find as users would have tossed these into the bin once this technology became phased out of PC laptops. There are the odd cards on eBay for known brands like IBM, Toshiba and TDK. One manufacturer has (probably had if reading this well into the future) many cards for sale. These are the Sphinx Elektronik cards which are very early Bluetooth 1B versions. This is the card used to develop against.

The Sphinx cards use Ericsson radios over UART. Developing a driver was the easy part to talk to the radio chips and get HCI communications up. 

Software Stack

This was the most complex piece of work after the driver development. The driver is a simple Amiga serial device for the stack to talk to. The stack then supports the many multiplexed protocols over the HCI established connection. 

As the hardware uses just the Classic Bluetooth protocols, then there's no additional support needed for LE (at this point). Although 'Classic' sounds quite antiquated, it's still in regular use when higher data rates and robust connections are required. LE is more suited to smart home, fitness tracking and general wearables. Note that Classic is also good at these applications, but not if you need to run off batteries.

For the Amiga, I just wanted to get something up and running to gauge performance. To get to any end user protocols there are a few layers that need building:

HCI

Pretty much the entry point to talk with the radio and establish a link layer. With this layer the Amiga can scan for devices, establish authentication, encryption and connections. 

L2CAP

This is a foundational layer for anything else going on in Bluetooth. Other protocols sit on this layer and make use of it's modes to support basic, flow control, reliability and enhanced packet features. The Amiga stack just supports basic data frames at this time. 

SDP

This is the service discovery protocol, which sits on L2CAP. Think of this as your directory services to provide connectivity or establish a connection to a remote system. PCs and mobile phones expose different capabilities to share files, networks and application data. Some of these services are only visible if enabled. The Amiga stack can query these capabilities, but limited to certain protocols it can use at this time.

RFCOMM

This is a serial protocol layer to hide all the underlying stuff and allow simple protocols to exists without much care about packet sizes and reliability (if appropriate). The implementation of this supports all the basics. Without the L2CAP reliable data packet support, this can lose packets and drop data. It's not a major issue for some protocols like OBEX when used for simple transfers. 

OBEX

This is an application layer protocol and is sometimes implemented outside of a stack when RFCOMM is present. There are 2 main versions with the older one talking with RFCOMM and the other talking direct to L2CAP. 

OBEX provides HTTP like data transfers. It supports FTP and data push services. If you send a file from one mobile phone to another then there's a strong chance it will use OBEX Push protocol. 

The Amiga stack supports RFCOMM older version and allows data to be sent or received. This is a neat implementation to prove connectivity, but is slow over RFCOMM (in general for phones, PCs and the Amiga due to the additional layer). About 1kb/sec in test implementations.

Limitations, possibilities, etc

Files can be sent to and from an Amiga or with more modern Android and Windows OS. MacOS is a bit fussy with it refusing to connect at the HCI/link-layer. This is either due to the old 1B radio capabilities or some other config. This will be explored further. 

Next steps are to complete the SDP layer to allow full service searching and inbound connections (sort of RFCOMM hardwired at present). The whole stack needs wrapping in an API for further expansion of protocols. ATT would be great to see running for quick data info such as battery levels or fitness data. 

Video of a file transfer

This video shows the UI searching for other devices and connecting to establish a file transfer over OBEX and RFCOMM. All software has been written by me and doesn't reuse any existing stack code from 3rd parties. The goal is to build the stack to work with Amiga data types and communication. All code is built in C.