The design consists of two PCBs, the first plugs into the computer’s cartridge slot and the second is designed to plug along the edge of a standard 2.54mm pitch breadboard. The two boards are connected by a length of 50-way ribbon cable.
The cartridge header board groups the various signals from the Acorn cartridge edge-connector into 3 logic groups, namely data bus, address bus and signals. This makes the organisation of the signals on the breadboard much easier to work with. The board also provides a 500mA polyfuse on the 5V supply and a 200mA polyfuse on the -5V supply. Both polyfuse ratings can be adjusted to individual requirements (and the 500/200mA ratings are just a suggestion). The polyfuses can also be completely omitted and bridged using wire (if not required).
Connection to the breadboard adapter is supplied by a standard 50-way IDC connector (similar to that used by SCSI-1 cables). The schematic is as follows:
As the signals are logically grouped by the cartridge adapter, the breadboard adapter is a simple 50-way IDC to SIL header adapter that can be plugged directly into a breadboard. As the interconnection is via a 50-way IDC connector, other end-adapters can also be developed to plug into the cartridge adapter if required. The schematic is as follows:
The cartridge adapter PCB provides an edge connector that is inserted into the cartridge slot of the Acorn computer. The PCB is shown in the following picture:
As the cartridge adapter uses an edge connector it is recommended that the PCB be finished with ENIG (gold plating) to ensure a good (and long-lasting) connection. The following specifications are recommended for manufacture:
The breadboard adapter provides a 50-way IDC connector routed to the 44 signal pins used by the cartridge interface. The signal pins are arranged as a single-row with 2.54mm pitch so the board can be directly inserted into a breadboard as shown in the following picture:
The following specifications are recommended for manufacture:
The breadboard adapter is clearly labelled and shows the signal names in accordance to the cartridge interface pin-out provided by the New Advanced User Guide:
All project files are available from the project’s GitHub repository. Ready-made gerber files for the PCB can be found in the releases section.
]]>
SmallyMouse2 provides a smaller PCB footprint compared to the original SmallyMouse and, in addition, has quadrature output headers suitable for both the Acorn BBC Micro (a 20 pin IDC) and a 10 pin SIL header suitable for custom-made cables for retro computers. SmallyMouse2 also supports the Atmel FLIP DFU bootloader (pre-programmed into the AVR chip by Atmel) and can be flashed via USB allowing both initial programming and firmware upgrades without the need for Atmel programming hardware.
SmallyMouse2 also provides an expansion header with 8 GPIO pins. This allows general purpose IO as well as access to the I2C and UART serial hardware of the AVR microcontroller. This header can provide the ability to add a serial debug console as well as other hardware such as status LEDs and additional configuration switches.
SmallyMouse2 has been tested with the following machines (please see the cable pinout section below for details):
If you have successfully tested SmallyMouse2 with a computer that is not in the list above please leave a comment (stating the exact model of computer and the firmware version either below, or as a GitHub issue for the present firmware release – if this involves a pinout which is not provided below, please send a note of the pinout also if possible).
SmallyMouse2 uses an AT90USB1287 microcontroller from Atmel that supports both USB device (used for bootloader programming) and host mode (used for mouse support). Host mode support is required as a USB mouse is a device and therefore needs SmallyMouse2 to act as the host computer. The schematic design for SmallyMouse2 is available from GitHub in KiCAD format:
For details of the various interfaces provided by the SmallyMouse2 design please see the interfaces section below.
The PCB design can be seen in the following picture:
The PCB is designed to be fabricated as a double-sided PCB. Due to the tolerances of the traces and vias on the PCB it is recommended that the board is produced by a professional fabrication service. The required Gerber files for fabrication are included in the GitHub project files.
The PCB design also includes 4 mounting holes for M3 size screws or PCB stand-offs. The USB port is extended over the edge of the PCB to facilitate mounting the board inside an enclosure.
All required components are mounted on the top-copper surface of the board to provide compatibility with pick-and-place machines (and to simplify hand population of the board).
The following components are used by the PCB design:
When powering SmallyMouse2 from the host computer attention should be given to the required amount of current consumed by both SmallyMouse2 and the connected USB mouse. The USB specification generally limits the maximum USB device consumption to 100mA and this figure should be used as the ‘normal’ consumption of USB mice in general. The SmallyMouse2 device (running firmware v1.1) was measured in the range of 59mA to 61mA (the power consumption varies depending on the activity levels of the mouse).
A safe assumption is that the total required current supplied by the host should be 180mA (in total for both the mouse and SmallyMouse2).
In addition, the following mice were physically tested (power consumption includes the SmallyMouse2 board):
The SmallyMouse2 hardware provides 5 interfaces; USB, JTAG, BBC Micro user-port AMX mouse, generic quadrature mouse (10-pin) and a 10-pin expansion header.
A development board fitted with all available interfaces is shown in the following picture (please note that the JTAG header is only required for development and debug functionality and should not be fitted to general purpose boards):
The USB interface can act in both USB host and USB device mode. When acting as a USB device (i.e. for bootloader programming) the board should not be externally powered (SmallyMouse2 will take power from the host device, so no other power supply should be used). When acting as a USB device it is recommended that all other interfaces are disconnected.
In USB host mode SmallyMouse2 can be connected to any USB 1.0 or 2.0 compatible mouse that uses the USB HID protocol. Note that the USB host mode support is only limited by the firmware; the USB host interface can also be used to support other USB devices (such as keyboards and non-standard mice) provided appropriate firmware support is added.
The USB interface provides a female USB A type connector. For use as a USB device (for example, when programming via the bootloader) a USB A-A style cable is required. In host mode the male USB A connector of the device plugs directly into the available connector.
The JTAG interface is used for direct programming of the AVR microcontroller and is useful for either development work (where the USB bootloader is inconvenient) or board recovery in the unlikely event that the USB bootloader is corrupted or unavailable.
Since the JTAG header is optional (it is not necessary for general use) the interface is provided by 7 solder pads along the top-edge of the PCB. To use the JTAG header you will need to solder an appropriate 2×10 pin-header via wires connected to the available pads in accordance to the pinout of your programmer.
The BBC Micro User-Port interface is a 20 pin IDC connector (2×10) as used by the Acorn range of 8-bit computers (BBC Micro Model A and B, BBC Master 128, etc.). This interface allows SmallyMouse2 to be connected to the Acorn computer using a straight 20 wire ribbon cable with appropriate IDC connectors.
The pinout of the interface follows the AMX mouse standard and is compatible with all AMX software as well as the Acorn VFS implementation (used in the BBC Domesday project). The interface also provides power to the SmallyMouse2 board via the host machine, so no external power supply is required.
This interface is optional and can be left unpopulated if Acorn user-port support is not required.
The generic quadrature mouse interface is provided by a 10 pin SIL header. 4 pins are used for quadrature output to the retro computer, 3 pins are used for mouse button output and 3 pins are used for power input.
For the quadrature output each direction (X or Y) uses 2 pins marked X1/X2 and Y1/Y2. There is no standard for such pins on retro computers and they are sometimes called Xdir/Xref etc. If you are creating a cable for a retro machine then the mouse pointer movement will be inverted if the pins are connected in the wrong order; simply swapping the pins will correct the direction. It is possible to correct the mouse movement direction in software however this is not recommended as it will make the device incompatible with other cables.
Most retro computers expect either two or three button mice. If your computer supports only 2 buttons then the middle-button (MB) signal should be left unconnected.
SmallyMouse2 is designed to be powered from the retro computer where appropriate power is available. To correctly power SmallyMouse2 ensure that both the 5V and 0V (ground) pins are connected.
Care should be taken to ensure the retro computer can supply the required voltage and current. Typically, SmallyMouse2 requires 5 volts (+- 0.1V) and 180mA current (including the USB mouse). If you experience unreliable USB connectivity (i.e. the USB mouse either does not connect, or disconnects intermittently) check the power supply to the board. USB is more sensitive to incorrect power than PS/2 based solutions.
If the host retro computer cannot supply the required power, it is possible to power the SmallyMouse2 board externally. In this case one of the 0V pins should be connected to the retro computer (there must be a ‘common’ ground between SmallyMouse2 and the computer), the other 0V and the 5V pins can then be connected to an external power source. Any external source should be regulated to exactly 5 volts (as there is no regulation provided by SmallyMouse2). Alternatively, it is also possible to use a DC-DC converter (for example a charge-pump circuit) to bring the retro computer supply to the correct values for SmallyMouse2 by placing the converter in-line with the mouse interface.
An externally powered configuration is shown in the following picture (the board is populated and configured for connection to an Acorn Archimedes A400 using an external power supply connected via a DC jack):
Note that the SmallyMouse2 board should be powered only from a single source. If a 5V external supply is connected to the board, the host retro machine should not be connected to the 5V pin simultaneously.
The 10-pin expansion header is a general-purpose interface for custom extensions to SmallyMouse2 and allows for non-standard retro computer interfaces. The expansion header provides 8 general purpose IO pins and two power pins (that can be used for supplying power to add-on boards or as a power input) via a 10-pin SIL header (optional).
The expansion header also provides access to the serial UART and I2C features of the AVR microcontroller. The standard firmware provides a serial debug console via the UART. This console is useful for debugging information and provides information about the status of the USB device (device connected, enumeration, etc.). The serial console can be accessed by connecting a USB to serial converter (such as the Arduino USB2Serial board) to the expansion header; only 2 wires are required, Tx (pin 4) and 0Vs (pin 9). The Tx output from the AVR should be connected to the Rx input of the serial adapter. Serial output is 9600 8N1.
Note: For firmware release V1.2 and above the D7 pin is used for a DPI divider header (the header is placed over D7 and 0V to turn on the feature). See the section below about mice with high DPI.
SmallyMouse2 has 3 board links that can either be left unconnected or made accessible using 2 pin headers and appropriate jumpers. The link marked ‘Slow’ is used to configure the quadrature rate limitation feature. When SmallyMouse2 is used with slower retro machines (especially 8-bit), fitting a jumper to the link will configure the software to limit the maximum speed of the quadrature output (this prevents the host ‘missing’ quick mouse movements due to the limited update speed of VIA chips in such machines).
The two links marked RST and HWB provide access to the reset and hardware bootloader pins of the AVR and are not required for general use. Placing a jumper on either header will make the corresponding signal active to the AVR. These links are used for programming the AVR via the USB bootloader and should be left unconnected for normal use; please see the firmware programming section below for more details.
The SmallyMouse2 firmware functions by using the LUFA USB stack to communicate and control an attached USB mouse device using the USB HID protocol. The USB mouse periodically sends position update reports to the host (at a rate of between 100-125 reports a second when the mouse is moving; the actual update speed depends on the implementation of the mouse). This style of updating generates problems for quadrature emulation since, in a quadrature mouse, the output would be a constant flow of information with the frequency of the pulses indicating how far the mouse has moved.
SmallyMouse2 emulates the quadrature output using the AVR’s timers (one timer for X and another for Y) – and sends the quadrature at a variable rate depending on how fast the mouse is moving. The quadrature output is timed so the device can send as much of the movement information as possible before another USB report is received.
The output of a quadrature mouse has 4 phases (hence the name) and the speed of the phases are dependent on the mechanical encoders present in the mouse. Modern USB mice no longer use mechanical encoders so the output is digital. A modern USB mouse sends continuous reports stating how far the mouse has moved in both the X and Y direction (since the last report).
The SmallyMouse2 firmware emulates the analogue nature of the quadrature output by using variable timers that control the time between phases. For each unit of reported movement (from the USB report) the firmware advances the appropriate axis by one phase. This has the effect of providing a 4:1 reduction in the overall output speed without the loss of any ‘information’ about movement. If a USB mouse reports at a rate of 100 reports per second at the maximum movement speed (127 movement units per report), SmallyMouse2 is receiving 12,700 movement unit updates per second. This results in a quadrature output rate of 3175 Hz. Due to variations in USB mouse report frequency (and limitations of the AVR’s timer resolution) SmallyMouse2 is written to support a maximum quadrature frequency of about 3900 Hz – this is more than sufficient to provide lag-free movement.
With 8-bit retro computers it was possible to move the mouse faster than the host computer could detect – this would cause spurious updates with the mouse pointer seeming to bounce around the display. SmallyMouse2 contains a rate limiting algorithm that prevents the device from overrunning the host computer. Two definitions in the firmware control this, namely Q_RATELIMIT and Q_BUFFERLIMIT. The rate limit sets the maximum frequency of the quadrature output generated by SmallyMouse2 and is specified in Hertz (i.e. the number of quadrature signals per second). This prevents the device from outputting faster than the 8-bit host can count. Since there is only a limited time between USB reports, any extra position updates that cannot be sent to the host will be lost. The buffer limit parameter specifies how much overrun should be allowed before updates are disregarded. By altering these two parameters it is possible to tune the quadrature output for a specific computer. By default, the firmware provides a ‘safe’ value that should work with a wide-range of machines.
The Q_RATELIMIT is only applied to the output when the ‘slow’ configuration header is shorted (i.e. a jumper is placed on the 2 pin header). The Q_BUFFERLIMIT is always applied; however, this should have no effect if the slow configuration header is open (as the normal output rate should allow the output to keep up with the USB reports).
Some USB mice have extremely high DPI and can cause SmallyMouse2 to output mouse movement too fast. As of firmware V1.2 you can place a jumper between D7 and 0V on the expansion header to turn on the DPI divider feature. If turned on, SmallyMouse2 will divide the incoming USB mouse movements by 2 to decrease the rate at which the mouse moves. This can be combined with the quadrature limiting feature described above.
For development or troubleshooting SmallyMouse2 provides a serial debug output that can be used to monitor the status of the USB interface. This output is available on the expansion header (see the expansion header section above for details).
The expansion header D0 pin also outputs a pulse every time a USB report is processed (the pin is raised at the start of processing and lowered at the end). This allows monitoring of the rate at which USB reports are received (useful for debugging).
When the SmallyMouse2 board is first made the AT90USB1287 will automatically power-up into the Atmel FLIP DFU bootloader. In this mode the microcontroller can be programmed using the USB bootloader programming utilities published by Atmel (ensure that you install the USB drivers for the application too!). In addition, Atmel Studio is also compatible with the bootloader and will recognised SmallyMouse2 as a programming device.
For initial programming SmallyMouse2 should be connected to the host computer using a USB A to A cable. No other connections should be made to the board and no external power is required.
After initial programming SmallyMouse2 will configure the USB port in host mode and the bootloader will not activate by default. Further programming requires use of the RST and HWB headers on the SmallyMouse2 board (these headers can be omitted for production runs where subsequent programming is not required). To overwrite the firmware jumper connectors should be placed on both the RST and HWB links before connecting the board to the host computer via USB. Once connected via USB the RST jumper should be removed (leaving only the HWB jumper in place). This will cause SmallyMouse2 to initialise the bootloader ready for programming. Once programming is complete SmallyMouse2 should be disconnected from USB and the HWB jumper should be removed.
SmallyMouse2 was designed to provide USB mouse connectivity to the widest possible range of retro machines and it is expected that many cable variations will be made available. As more verified cable designs are made available they will be added to this section.
The connection cable for the BBC Micro and Master range of 8-bit connectors is a direct 20 pin IDC to IDC ribbon cable. Both the BBC Model B and the Master 128 have been tested successfully with release v1.1 of the SmallyMouse2 firmware.
The following pinout is used to connect SmallyMouse2 to the Acorn Archimedes A400 and RISC PC range of computers:
The Acorn Archimedes A440/1 computer and the Acorn RISC PC 600 has been tested successfully with release v1.1 of the SmallyMouse2 firmware.
The following pinout is used to connect SmallyMouse2 to the Commodore Amiga range of computers:
The Commodore Amiga A600 has been successfully tested with release v1.1 of the SmallyMouse2 firmware (testing and pinout kindly provided by Bas of BetaGamma Computing).
Note: The rated maximum output of the Amiga mouse/joystick port is only 50mA; so technically you will need to externally power the SmallyMouse2 board (leaving pin 7 from the port disconnected); however testing shows that the port is generally capable of supplying enough power (previous PS/2 based adapters have been used with Amigas and these will have a power draw similar to the SmallyMouse2 board).
The following pinout is used to connect SmallyMouse2 to the Atari ST range of computers:
The Atari 520 ST has been successfully tested with release v1.1 of the SmallyMouse2 firmware (testing and pinout kindly provided by Bas of BetaGamma Computing).
Note: The power output from the Atari 520ST mouse/joystick port was measured at only 4.5V (on the machine used for testing). This can cause unreliable USB connectivity. An external 5V power supply is recommended (leaving pin 7 from the port disconnected).
The SmallyMouse2 logo is a monochrome rendering of a mouse with the tail representing the number 2. The logo was drawn in Adobe Illustrator and can be downloaded from the GitHub repository.
SmallyMouse2 was designed due to the encouraging response and feedback from the original project. There seems to be a big demand for an interface to allow retro computers to use even the most modern mice. The project has been released as open-source and open-hardware to allow anyone to make the device either for personal use or for resale. All such activities are positively encouraged and even commercial sale is allowed by the licensing (however anyone intending on such activities should ensure they understand the share-alike nature of both the GPL and CC licenses intended to ensure the project remains open to all).
If you liked this project or came to the site for firmware updates or other information, please consider leaving a PayPal donation to help fund this and future projects! As a non-commercial open-source, open-hardware project only your donations to this site fund development.
All project files are available from the GitHub repository:
Please note that any firmware enhancements will be made available via GitHub in the releases section of the project.
SmallyMouse is an open-source, open-hardware project. Everything you need to make your own board is available from the GitHub repository. WaitingForFriday.com doesn’t supply ready-made boards or kits (just the actual work of designing and development!) – if you’d like to buy a SmallyMouse2 then you are welcome to try the following resources (note: these resources are not associated, supported or endorsed by WaitingForFriday.com and are provided for your convenience):
BetaGamma Computing in the UK is making and selling completed boards. Please see their Facebook group page for details:
BetaGamma Computing (Facebook)
The renown Acorn shop CJE Micros is also producing completed boards in the UK. More information is available on their web-shop:
User [dnotq] has posted the board design on OSH Park (a service where you can order the bare PCB for making your own board):
If you know of any other sources for SmallyMouse2 please post in the comments and I will add them to this list.
]]>Please note that replacement of this supply involves wiring and components that will be handling mains electricity and should not be attempted unless you know what you are doing. If you are unsure, please find a qualified engineer and ask them to perform the modifications for you. Please note that the author does not guarantee accuracy and, as with any modification to the Acorn Master you run the risk of inadvertently breaking your computer. Please ensure that you use the correct ESD protection when performing any service work on the computer and take adequate safety measures when dealing with mains electricity.
The replacement power supply is a Mean Well PT-65A 3 output switch mode power supply unit which is widely available from electronic component distributors. To assess the suitability of the power supply it is important to compare the output characteristics of the original supply to the PT-65A.
The BBC Master service manual does not contain details of the power supply however it is very similar to the supply found in the BBC Model B and B+ machines. The service manual for these machines gives the following power supply specifications:
The power consumption of the computer itself can be estimated by subtracting the rated maximum current from the external power connector (located under the computer) which is labelled as follows:
This indicates that the computer uses approximately 2.25A @ 5V, 0.025A @ -5Vs and 0A @ 12V (since the 12V power is only used by the external connector).
The Mean Well PT-65A datasheet states the following specifications for the replacement power supply:
It can be clearly seen (from the datasheet) that the new power supply out performs the original both in terms of output power and efficiency. The PT-65A also provides short-circuit protection, overload protection and over voltage protection.
In order to connect the power supply and make the required wiring loom for the BBC Master you will need a number of parts, wire and tools.
The following list shows the required parts for the power supply modification:
In addition you will need appropriate crimping tools for both the blade/ring terminals, the Molex crimp terminals and the TE connectivity terminals. You will also require access to a 3D printer or 3D printing service in order to create the required brackets (see below).
In order to fit the new supply into the original Acorn power supply case you will need to first remove the original power supply board from the case.
To connect the mains power to the PT-65A you will need 3 equal (17cm) lengths of mains cable. Strip one end of each cable and crimp a 6.3mm blade to each. For the earth cable (the green/green-yellow cable) you will need to crimp a ring terminal. On both the blue and brown cables crimp a molex crimp contact to each.
The pin-out of the mains and earth connector on the PT-65A is shown in the following picture, make sure you put the cables on the correct sides of the 3 pin molex connector:
Once complete the cables should look like the following picture:
The mains cable is fitted to the metal case of the original Acorn power supply as shown in the following picture:
The PT-65A provides 3 different power output levels and ground for the computer. The pin-out of the PT-65A is as shown in the following picture:
The pin assignments (from the datasheet) are as follows:
In order to connect to the power supply you will need to cut the following cables and crimp them into the connector for each pin (most pins require two cables connected to the same pin):
You will also need to cut an additional 5cm black cable for the external power connector.
The cable should now look like the following picture:
Seperate out the 8cm cables (these are all for the external power connector) and crimp the TE connectivity connectors to the wires. For the black cable from pin 4 of the Molex connector you will need to crimp the cable along with the extra 5cm black cable and then crimp a connector to the other end of the 5cm cable as shown in the following picture:
The crimped connectors should then be inserted into the TE Connectivity Miniature Rectangular II crimp connector housing according to the following diagram:
Next strip all of the unconnected wire ends and crimp 6.3mm blade recepticals to all of the cables. The finished cable should look like the following picture:
Since the PT-65A is a smaller board than the original Acorn power supply it is necessary to use 2 brackets that adapt the original case to the new foot-print. These brackets can be simply 3D printed from the STL file supplied below. Each bracket takes about 30 minutes of printing time and can be printed using PLA with 20-25% in-fill.
PT65A bracket for Acorn BBC Master
Note that the latest version of the bracket (which will probably be better to use than the link above) is available from the project GitHub. The GitHub repository also includes the original OpenSCAD source files allowing you to customise the bracket if required:
Attach the two printed brackets to the PT-65A using the M3 screws, washers and nuts. Use a washer on either side of the screw to avoid damaging the plastic when the nuts are tightened. The brackets should be mounted as shown in the following picture:
Once the brackets are fixed, flip over the power supply board and attach both the mains and computer power cables made in the previous steps (don’t forget to connect the earth cable to the connector on the power supply. It must be earthed for correct and safe operation!). The mains cables should be long enough that you can do this with the power supply next to the power supply case as shown in the following picture:
Next you will need to thread the long cables through the hole in the side of the power supply case, then flip the power supply board on to the top of the case and push the external power connector into the case (note: Make sure you get the power connector the right way up, the curved part of the connector should be at the bottom of the case. Pushing the connector though can be quite tough, but it does fit). Once the long cables are fitted, slide the rubber grommet over the cables and fit into the side of the metal case to prevent the wires from rubbing on the edge of the metal.
Once the external power connector is in place you can place the power supply down into the case and align the screw holes with the bracket. Be careful to fold the excess wires out of the way so they don’t prevent the power supply board from fitting correctly. Once aligned simply screw the board in place using the original 4 screws from the case. You will need to liberally apply zip-ties to the various cable lengths to make sure it is neat and the cable runs don’t easily tangle. The finished power supply unit should look like the following picture:
To mount the power supply back into the Master simply place it back in its original location and wire it up as per the original supply. Make sure the ground, 5V and -5V connectors are in the correct place.
Once connected it is a good idea to check the power output of the new supply by measuring the 5V power output (this must be done while the power supply is under load). If the power output is not 5Vs you can simply adjust the output level using the potentiometer on the power supply board. This can be accessed (at an angle) through the left screw hole on the top of the power supply case (which originally screwed into the heat sink of the old supply). The finished supply should look like the following picture:
]]>Back in the dark and distant past of 2009 (ish) I set up WFF as a simple Wiki so I could have a place on the web to scribble down the random ideas and projects I was working on. Over the years the site has grown and now regularly handles 800K-1M unique hits a month. Clearly this has meant that I’ve been spending more and more time maintaining the site (and therefore less and less on electronics). To combat this, I’ve changed over to WordPress to lower the maintenance overhead. In addition, the site can now have a fresh new look that takes care of more modern web technologies.
I hope you like the new site and you are welcome to leave a comment if you spot a mistake (all of the original Mediawiki articles have been painstakingly moved over, but it’s a mainly manual process so something may be wrong here and there) or if you have a suggestion for improvement.
The site has redirection in place to ensure that all of the original MediaWiki URLs still point to the correct web pages but, if you find a 404, please let me know!
/Simon
]]>Update: Please note that this project has been superseded by SmallyMouse2. Please follow the link to the project for details!
Although the adapter is designed for Acorn computers, the quadrature emulation is suitable for a wide-range of machines sold during the same era (such as the Acorn Archimedes, Commodore Amiga, etc.). Before the advent of serial and PS/2 mice, nearly all mice and trackball devices worked by sending a stream of pulses from a mechanically based quadrature encoder arrangement. The host computer would simply count the pulses from the mouse and convert this into movement on the screen.
The design fits in a small case and is connected to the BBC Micro or Master by a short 20 pin ribbon cable. The USB Host supports both wired and wireless mice provided they follow the industry-standard USB HID Mouse protocol. You can see SmallyMouse in action in the following YouTube demonstration video:
SmallyMouse uses an AT90USB1287 microcontroller from Atmel that supports both USB device and host modes. A host-mode compatible processor is required as SmallyMouse acts as the ‘computer’ rather than the device; it supplies power and control to the USB mouse device. The following EagleCAD schematic shows the required components and connectivity:
As can be seen in the schematic, SmallyMouse consists mainly of two halfs; the USB host interface is provided to a female USB A-connector along with the required supporting components and the AVR is then connected to the Acorn user-port for communication with the 8-bit computer. 10 GPIOs are connected to the user-port IDC connector in order to make the creation of adapters (for other 8-bit machines) as simple as possible.
The design also contains a 500mA PTC which acts as a fuse to protect the Acorn computer’s user-port and power supply. The PTC will automatically cut-out if more than 500mAs is drawn from the user-port. PTCs are ‘self-resetting’ so, if the PTC is tripped, removing and reconnecting the power will reset the device.
The design also includes a switch (for selecting the emulation mode) and a JTAG header in AVR standard format for both debugging and programming the microcontroller.
The PCB design can be seen in the following diagram:
The PCB is designed to be made either double-sided (if you are using a PCB fabrication service) or single-sided (where the bottom-copper traces can be replaced by link wires). Tolerances are suitable for UV transfer production of the board. Full EagleCAD schematics and PCB design are provided at the end of this article.
The PCB fits in a G026N case from Kemo Electronics, you will need to cut holes in the case for the USB connector, the switch and the ribbon cable.
Note that the IDC connector, the USB socket and the header pins are mounted on the lower side of the board (i.e. inverted), this is to allow for hand-soldering (since it is not possible to solder under the devices) – therefore the device is mounted ‘upside down’ in the case.
The SmallyMouse firmware functions by using the LUFA USB stack to communicate and control an attached USB mouse device. The USB mouse periodically sends position update reports to the host (at a rate of around 120 reports a second when the mouse is moving). This style of updating generates problems for quadrature emulation since, in a quadrature mouse, the output would be a constant flow of information with the frequency of the pulses indicating how far the mouse has moved.
SmallyMouse emulated the quadrature output using the AVR’s timers (one timer for X and another for Y) – and sends the quadrature at a variable rate depending on how fast the mouse is moving. The quadrature output is timed so the device can send as much of the movement information as possible before another USB report is received.
With the original AMX and RB2 devices it was possible to move the device faster than the host computer could detect – this would cause spurious updates with the mouse pointer seeming to bounce around the display. SmallyMouse contains a rate limiting algorithm that prevents the device from overrunning the host computer. Two defintions in the firmware control this, namely RATELIMIT and LAGLIMIT. The ratelimit sets the maximum frequency of the quadrature output generated by SmallyMouse. This prevents the device from outputting faster than the 8-bit host can count. Since there is only a limited time between USB reports, any extra position updates that cannot be sent to the host will be lost. The laglimit parameter specifies how much overrun should be allowed before updates are disregarded. By altering these two parameters it is possible to tune the quadrature output for other computers.
The firmware supports both the AMX mouse and the Marconi RB2 trackball; although these two devices were electrically identical the pin-out used to the BBC computer was not the same. The firmware uses simple GPIO reconfiguration to be able to support either pin-out as required. A toggle switch controls which pin-out is currently in use.
SmallyMouse is part of a larger project I am working on to recreate the BBC Domesday hardware (a BBC Computer Literacy project from 1986). The Domesday project used a Marconi RB2 trackball as the primary control device. However, the ability to replace legacy 8 and 16-bit mice with modern USB devices is potentially very useful, so I designed the firmware/hardware to be as simple as possible to modify. Since this is an open source project you are, of course, welcome to make your own, or even make them for others.
This zip file contains the Atmel Studio 7 firmware project files for the project:
SmallyMouse_1_1_Studio_7_files
This zip file contains the EagleCAD files for the project (schematic and PCB design):
]]>This design, like the original, is very economical in terms of components, the only IC used is an ATtiny45. As additions to the original project, this design includes two on-board Econet DIN connectors and an on-board power supply jack. The design includes headers for both Econet (2 DIN sockets) and power so you can choose if you wish to mount the connectors on the PCB or externally. In addition you can also choose to connect both the on-board and external DIN sockets allowing 4 sockets to be connected. This is useful if you want a compact clock and hub for up to 4 machines with minimal cabling.
The primary additional feature is the DIP switch which allows you to choose from 8 preset clock configurations. Although the original project allowed you to set the clock configuration in firmware, this project adds a DIP switch for users that do not have access to an AVR programmer (for example, when the clock was supplied to you by someone else). Of course, by altering the firmware, you can choose your own presets and the code comments explain how to do this.
The schematic for Acorn Econet clock v2 is based on the Atmel ATtiny microcontroller which is a small 8 pin device available in DIP format. Although the microcontroller is clocked from its internal 8MHz oscillator, the PLL and PWM features of the processor are used to clock an internal timer to 64MHz that is more than adequate for producing the 200-400 KHz asymmetric differential clock signal required by Econet.
Previously the Econet clock designs included a differential line driver (such as the defunct SN75159N in the BBC Micro and the AM26LS30 found in later Econet modules). The differential line driver takes a non-inverted clock signal from the clock generator and splits it into the positive (non-inverted) and negative (inverted) signals required for a two-wire differential output. This design takes advantage of the ATtiny45’s PWM output feature that can supply a differential output directly from the OC1B and !OC1B (NOT OC1B) outputs removing the need for an external IC.
Note that the power input to the circuit ”’must”’ be a regulated 5V supply; as the circuit does not contain a regulator. Since the power supply sets the voltage on the clock signals it is very important to ensure the supply does not exceed the TTL levels required by Econet.
The design does not need a differential line driver since the AVR can generate both the positive and negative clock signals using it’s on-board PWM module. This has the advantage of both simplifying the circuit as well as improving the signal (since a line driver is essentially an opamp it does not drive the output signal rail-to-rail (i.e. from 0V to 5V) – however the AVR’s PWM can. This drives the line with more mW of signal than possible with a line driver which should improve the clock’s performance in longer/larger networks).
The schematic for the clock design is shown below:
The clock is built on a single-sided PCB with a large ground plane area to reduce signal noise. The PCB design is suitable for making using the UV transfer technique:
If you wish to use external DIN connector and/or power connectors the pin out and cable construction is the same as documented in Acorn Econet Clock. The on-board DIN footprint is suitable for 2 styles of DIN socket (with either wide or narrow earth pins). The wide-pinned version is the same as used in the BBC micro itself. These sockets are also common in MIDI devices so they are widely available.
The firmware project can be downloaded from the bottom of this article and contains a GPL licensed firmware project which can be opened in Atmel Studio 7. The firmware configures the ATtiny Timer/Counter1 to produce the require differential clock signal depending on the position of the DIP switches. The overall frequency of the clock and the length of the mark (the positive pulse) for the presets can be freely altered in the source code; the source code is heavily commented and contains all the instructions required to make simple modifications to the clock settings. As the ATtiny is clocked by its internal 8MHz oscillator there is some noticeable jitter and inaccuracy in the clock output, but perfectly within tolerance of the required Econet clock signal (and has been tested using both a BBC micro and an Archimedes A440/1). There are 8 preset clock configurations available in the firmware:
DIP SW – Period (uS) – Mark (uS)
Note that the 4th DIP switch (the right-most) is not used, only the first 3 switches have any affect on the generated clock. The left most switch is the most significant bit of the configuration number and the right-most is the least.
The following image shows the output from all 8 configurations (captured on a DSO) along with the actual measurements (note that, since the AVR is internally clocked, there will be some variance between chips):
The top channel (channel 1) shows the non-inverted clock output and the bottom channel (channel 2) shows the inverted output.
The PCB also includes a 6 pin AVR programming header to allow the ATtiny to be programmed without removing it from the PCB. When programming the ATtiny all DIP switches should be set to ‘off’ to prevent the circuit from interfering with the SPI programming.
The PCB is designed to fit into a G027N case from Kemo Electronics. The case is 72 x 50 x 35mm. The top part of the case will need to be cut to allow access to the DIN sockets and the 5V power jack. Mounting the clock in a case is, of course, optional, but helps to protect the clock circuitry from dirt and metal objects that could case a short-circuit. The completed clock mounted in it’s case is shown in the following picture:
I hope you find this design both useful and flexible.
As the design is open-source and open-hardware I positively encourage you to embrace, modify and even build and sell the design. My intention is to help as many Acorn enthusiasts as possible!
The source code, project files and Eagle CAD schematics and board files are available on GitHub:
]]>The design fits in the BBC micro’s PHROM socket and required no modifications to the BBC Micro in order to work. The board consists of only 7 components; 3 capacitors, a crystal, 2 resistors and the microcontroller.
You can hear the emulator and the TMS5220 in action in the following YouTube video:
The TMS6100 is an unusual ROM in that it provides a parallel address bus along with a serial data transfer (the original ROM was also capable of 4-bit parallel data transfer, however this is not used by the TMS5220 processor).
The following schematic diagram shows the TMS6100 header pins and the connections to the ATmega32U2:
As can be seen in the schematic, there are 4 ‘ADDx’ pins that act as the address bus. ADD8 also doubles as the MISO (Master In Slave Out) SPI pin. In addition, there are two ‘command’ pins M0 and M1 that act together to tell the TMS6100 which command to execute and (in the case of M0) act as the SPI asynchronous clock for data transfer.
Due to this dual use of M0, it is connected both to the SCK (SPI clock in) of the microcontroller as well as PB1 (external interrupt 1). The hardware design uses a combination of the ATmega’s SPI peripheral (for the high-speed data transfer) and the INT1 (for M0) and INT2 (form M1) external interrupt pins (for detecting and reacting to incoming command pulses). The TMS6100 also has a clock input (CLK) which receives a clock signal from the TMS5220 to ensure the logic in the PHROM was synchronized with the processor. In this application the CLK signal is not required (as the ATmega can asynchronously react to the SPI CLK alone), however it is connected in the hardware for future use/expansion.
To allow the ATmega to be programmed (using in-circuit programming over SPI), the rest of the SPI pins and the !Reset pin are also exposed on the ‘Not Connected’ pins of the TMS6100.
The original TMS6100 was powered from a dual-supply -5V – + 5V power supply; obviously this is not suitable for use with a modern processor such as the ATmega32U2. In order to power the microcontroller the design draws positive voltage from the TM6100’s Vss pin and relies on the presence of a ground through the !CS pin (which is connected to 0V ground in the BBC Micro).
The TMS6100 requires very few components and (with the exception of the AVR chip) there are many types to choose from:
In order to program the AVR the TMS6100 should be placed in a breadboard. Ensure that the following connections are made:
You will also need to connect pins 13 and 14 to a 5V supply in order to power the AVR during programming.
The PCB design can be seen in the following diagram:
The PCB is designed to be made double-sided using a PCB fabrication service). Full KiCAD schematics and PCB design are provided at the end of this article.
The TMS6100 provides 3 commands for the TMS5220 to use (and therefore, the host microcomputer). The commands are as follows:
Note that the Indirect Address command is not used by the TMS5220 and is therefore not implemented in the emulation firmware.
The read data command has two primary forms a ‘real’ read (where the TMS6100 initiates data transfer to the TMS5220) and a ‘dummy’ read command. In order to provide a ‘real’ read the TMS6100 must have a valid address from the TMS5220. This address is sent as a 20-bit value using 5 nibbles of data sent from the processor. If the processor sends a read data command before transferring 5 nibbles of data, the TMS6100 resets into a known state (clearing any partial address nibble writes).
The BBC microcomputer causes the TMS5220 to send 16 ‘dummy’ read commands whenever the computer is reset (power on or CTRL-Break). This action can be seen in the following logic analyzer trace:
Once the TMS6100 is in a known state the microcomputer waits for a speech command to be issued either by the user or by a running program.
The BBC Micro provides two primary methods of selecting and playing back a voice sample; the first method is by providing an ‘absolute’ location for the sample which results in the TMS6100 receiving a single address followed by a read data command. The Load Address command execution can be seen in the following logic analyzer trace:
Here you can see M1 go high and the load address command is triggered by the rising edge of M1. The TMS5220 sends 5 nibbles of data 4-bits at a time over the ADD1-8 address bus pins. The address is sent from the least significant nibble to the most significant. The 2 most significant bits are ignored by the TMS6100 and the 4 remaining MSBs are the chip select bits. The remaining 14 bits are the address the TMS6100. Since the Acorn PHROM also contains look-up tables to the sample pointers, it is also possible to provide a ‘word number’ that causes the microcontroller to issue a load address (into the pointer table), a read data (to search for the require absolute address), another load address (to point to the sample) and, finally, another read data to read the actual sample data. An example of this can be seen in the following trace (caused by a SOUND -1, 160,0,0 command):
Once a valid address is loaded, data transfer is started by a single pulse of M0 (as can be seen in the previous two traces). This signals the TMS6100 to go into transfer mode. In the emulation this is used to turn on the SPI peripheral and hand control of ADD8 and M0 over to SPI. If the emulator detects a pulse on M1 control is handed back and the SPI is turned off ready for load address and dummy read commands again.
The SPI format used by the TMS6100 is a little unusual in that the clock phase is not in sync with either the rising or falling edge of the SPI clock (and in that the M1 phase is leading edge and the M0 phase is trailing edge). This can be seen in the following timing diagram from the TMS6100 data sheet:
This is not possible to emulate using the SPI peripheral of the ATmega32U2 so, instead, the data is sampled on the rising edge of M0. Since this delay is very short it has no effect on the read data command and functions as shown in the following trace of the emulator performing a read data command (mid-data transfer of 8 bits):
The trace above also shows the approximate transfer rate of the SPI clock which is around 75KHz.
For complete details of the firmware please see the numerous comments in the source code that attempt to explain all of the emulation functions.
The function of the TMS6100 is common across all types of microcomputers that use the TMS5220 chipset and the PHROM data can be easily modified to represent data other than the Acorn PHROM. If you would like to use the emulator in machines other than the BBC Micro, care should be taken to ensure that the CS pin of the TMS6100 is tied directly to ground as the emulator relies on this for 5V power (the original chip used 5V and -5V). Only the features required by the Acorn implementation are included in the firmware; the comments in the firmware source-code state both the supported and unsupported features, so please examine the code for detailed explanation of the implementation.
By default the firmware will compile to include the Acorn Speech System PHROM data however, if you define the pre-processor symbol PHROM_US, the firmware will compile using the TI American PHROM data (see the source code for details).
Building this emulator was an interesting exercise in reverse-engineering (especially since I don’t have an original TMS6100 PHROM) and allows BBC Micro enthusiasts to provide a low-cost upgrade to their computers. The design is deliberately simplistic in that I tried to keep the component cost and PCB complexity to a minimum to make it as easy and cheap as possible to build. Since this is an open source project you are, of course, welcome to make your own, or even make them for others.
The Atmel Studio 7 firmware project files for the project and the KiCAD files for the project (schematic and PCB design) are available on Github:
]]>There are several designs for Econet clocks available on the Internet and even a few commercial providers of clocks, however most designs are based-on (or derived from) Acorn’s original design and require a complex, high-component count circuit in order to operate.
The clock created by this project consists of only 3 primary components (an ATtiny45-20 microcontroller, a capacitor and a resistor) and is therefore much easier to build – in fact, the clock circuit can be quickly built on stripboard saving even the hassle of PCB production. Furthermore, the design is both open-hardware and open-source allowing anyone to duplicate and build the clock (unlike the commercial solutions).
The schematic for Acorn Econet clock is based on the Atmel ATtiny microcontroller which is a small 8 pin device available in DIP format. Although the microcontroller is clocked from its internal 8MHz oscillator, the PLL and PWM features of the processor are used to clock an internal timer to 64MHz that is more than adequate for producing the 200-400 KHz asymmetric differential clock signal required by Econet.
Previously the Econet clock designs included a differential line driver (such as the defunct SN75159N in the BBC Micro and the AM26LS30 found in later Econet modules). The differential line driver takes a non-inverted clock signal from the clock generator and splits it into the positive (non-inverted) and negative (inverted) signals required for a two-wire differential output. This design takes advantage of the ATtiny45’s PWM output feature that can supply a differential output directly from the OC1B and !OC1B (NOT OC1B) outputs removing the need for an external IC.
Note that the power input to the circuit ”’must”’ be a regulated 5V supply; as the circuit does not contain a regulator. Since the power supply sets the voltage on the clock signals it is very important to ensure the supply does not exceed the TTL levels required by Econet.
The schematic for the clock design is shown below:
In order to make the clock as simple as possible to build the circuit is created on a 6 column by 15 row piece of stripboard. The wiring and component layout is shown in the following picture (created using the fritzing application):
The required components are an ATtiny45-20PU, a 10Kohm 1/4W resistor (5% tolerance) and a 100nF capacitor. Optionally you can choose to add a socket for the ATtiny (so you can remove it and reprogram the clock for different speeds) and header pins to connect the 5-Pin DIN sockets required to connect the clock to the Econet bus and a DC jack for the 5V regulated power supply.
The cut-pattern for the stripboard is shown in the following picture:
As can be seen from the schematic diagram, the header pin output is in the same order as the pins in the DIN connector. The pin order (from right to left, with the header at the bottom of the board) is 3, 5, 2, 4 and 1. The DIN connector wiring can be easily made and colour coded as shown in the following picture:
An advantage of both the Econet connector header pin order and the power supply 3-pin header is that reversing the connections (accidentally of course!) will not damage either the clock circuit or any interconnected devices.
If you decide to use pin headers (rather than directly soldering the connectors to the stripboard) then you can use Dupont F connectors to connect the Econet and power jack to the circuit as shown in the following picture:
The firmware project can be downloaded from the bottom of this article and contains a GPL licensed firmware project which can be opened in Atmel Studio 7. The firmware configures the ATtiny Timer/Counter1 to produce the require differential clock signal. The overall frequency of the clock and the length of the mark (the positive pulse) can be freely altered; the source code is heavily commented and contains all the instructions required to make simple modifications to the clock settings. As the ATtiny is clocked by its internal 8MHz oscillator there is some noticeable jitter and inaccuracy in the clock output, but perfectly within tolerance of the required Econet clock signal (and has been tested using both a BBC micro and an Archimedes A440/1). The following picture shows an oscilloscope trace and measurement for the clock with the default settings in the firmware linked below (target clock speed is 250 KHz and the mark period is 0.75 uS):
The top channel (channel 1) shows the non-inverted clock output and the bottom channel (channel 2) shows the inverted output.
Please note that the stripboard design does not include a programming header for the ATtiny’s programming pins. The microcontroller will need to be programmed before being inserted into the stripboard. Programming AVR chips is very straight-forward and can even be performed using an Arduino board. There are many good sites on the Internet that cover such subjects, so I shall not repeat the instructions here.
I hope you find this design both useful and flexible. Obviously I haven’t been able to test the clock extensively (since I only have a limited number of retro-Acorn machines) so I welcome your reports of working implementations in the comments.
As the design is open-source and open-hardware I positively encourage you to embrace, modify and even build and sell the design. My intention is to help as many Acorn enthusiasts as possible!
This zip file contains the Atmel Studio 7 firmware project files for the project:
]]>The primary reason to use FHT over FFT is that the real number input represents a significant saving in RAM (since only a single array is required) and it is relatively easy to implement the FHT efficiently on low-power microcontrollers such as the AVR. There is a lot of information on the web comparing FFT and FHT however that is not the aim of this project; the aim is to provide a FHT library suitable for 8-bit (low RAM) microcontrollers and demonstrate its use in audio analysis.
Fourier transformation is useful for applications such as audio frequency (spectrum) analysis where you would like to analyse a sample of sound in order to work out what relative amplitudes of the various frequencies are. Applications include visualisation and analysis of music, speech and other sound sources as well as sound to light applications.
The inner workings of the FHT algorithm are not covered by this article. The FHT used is based on the FHT document written by Ullmann and should be used as a reference for those interested in how the FHT algorithm actually works (a link to the original article is provided below).
Please note that, whilst the library is primarily tested on the ATmega328P and ATmega32U4, it is suitable for any GCC compatible environment and will function well on other boards such as the Raspberry Pi, the Arduino Due, etc.
The FHT library is designed to compile on both AVR GCC and regular Linux GCC. As the library is completely written in C it should be very easy to port to other architectures and microcontroller types. The disadvantage of C is that it is not as efficient as coding the library in assembly language; however the desire (of the author) was to provide pedagogic code which could easily be sped-up by substituting core C functions with assembly equivalents. Having said this, the library is easily fast enough to provide real-time Fourier analysis even on a 16Mhz ATmega328P and requires around 17 ms to both permute the input and perform the FHT (of 256 inputs). Performance can be significantly improved by clocking the ATmega at its full 20Mhz if required.
By targeting both Linux and the ATmega328P the library could be more easily tested for overflow issues and portability issues (the library has also been tested on the ATmega32U4 which is found on the Arduino Leonardo board). It should be noted that some previous version of GCC had bugs in the 32-bit multiplication routines; so ensure that your compiler is up-to-date. When compiling with Atmel studio you must use at least version 6.1 to avoid the previously mentioned compiler bugs.
The library is configured using the fht/fhtConfig.h header file. The header file contains the various configuration options and explanations of what they do. The library also includes debugging functions which stream information about the FHT and associated functions to stdout. This allows the library to be tested on an Arduino Uno board using the serial output to monitor the results.
In addition to the library itself the Atmel Studio project and source code included with this article also provides an automatic testing tool for the FHT library which shows the generated input sample, the FHT output and the result of applying various window and scaling functions to the data.
The test results for the library are given in the following PDF files which show the output for FHT of lengths 32, 64, 128 and 256. Some rounding errors can be seen in the 256 length tests however these are mainly due to the way in which the input data is generated; with real audio data the library should function amicably even for lengths of 256.
FHT_Library_1_2_32_test_results
FHT_Library_1_2_64_test_results
FHT_Library_1_2_128_test_results
FHT_Library_1_2_256_test_results
The FHT requires a sample of audio for processing. It is important that the samples are accurately spaced (i.e. have a consistent sampling rate) and the number of samples must match the input length of the FHT. The ADC function samples the audio intensity which can be considered as the average audio intensity over the duration of the sample. The result is a set of values which represent the intensity of the audio over the duration of the sampling.
The ATmega32U4 has a 10-bit ADC. This means that the range of results from the ADC is 0-1024. Since the audio input is AC this means our sample is in the range of -511 to +512 centred around 0.
The FHT function uses 16-bit integers however the FHT algorithm requires that the inputs are added and subtracted from each other. In order to do this in a 16-bit space the input to the FHT cannot exceed half the range of a 16-bit number i.e. -16384 to -16383. This limits the FHT resolution to 15 bits. Note that the FHT also requires multiplication of inputs, however this is performed using 32 bit temporary variables to preserve resolution and minimise RAM usage.
This means that, in order to get the maximum possible resolution from the FHT the 10 bit input samples need to be scaled up to 15 bits before being passed to the FHT.
The frequency range which can be supported by the FHT is based on the sampling rate of the input data. The highest frequency possible is limited by the Nyquist limit which states that the highest frequency which can be sampled is exactly half of the sampling rate. In other words, if you sample the audio at 20Ksps (20,000 samples per second) the maximum frequency you can detect is 10KHz. Any frequencies present in the input sample over the Nyquist limit will result in erroneous output by the FHT. Therefore care must be taken (in the hardware) to limit any frequencies over the Nyquist in the input signal to the ADC.
The library code includes a function generateSample() which simulates the sampling of audio data for testing purposes. When given an amplitude and frequency it passes back a sample of a pure sine-wave.
When sampling audio data using an ADC the samples are already windowed as sampling applies a rectangular window to the input audio. The issue with this is that, since the edges of the window are rectangular, the window can cause unwanted leakage of spectral components in the output of the FHT. This means that frequency components of the audio which get split between samples can result in errors from the FHT as the frequency components get spread out. The following diagram shows a 20Ksps sample of a 1500 Hz sine-wave without windowing:
To reduce this effect we can apply windowing functions to the input audio data. Windowing functions typically roll off the edges of the samples in order to reduce the spectral leakage (actually the spread the error across the sample to lessen its effect).
The FHT library supports 2 windowing functions (well, 3 if you include the default rectangular window), namely the Hann window and the Hamming window. These are popular windowing shapes for audio processing. The advantages and disadvantages of either are well documented on the web if you are interested in learning more about windowing functions.
The same input sample shown above looks like the following diagram after having a Hamming window function applied to it:
The diagram below shows the same sine-wave input, this time with a Hann window applied:
It is worth noting that windowing functions come at a cost; whilst they improve the overall accuracy of the FHT output they also attenuate the input signal (i.e. remove some gain) which causes an overall drop in the resolution of the FHT.
To apply a Hann window to the sampled data you simply call applyHannWindow() and for a Hamming window you call applyHammingWindow().
The window function is applied using a look-up table to which the original sample is multiplied. The look-up tables are only half of the full window function (in order to save space) since both the Hann and Hamming window functions are symmetrical.
The FHT function accepts an input sample with a maximum of 256 components and each component must be in the range of -16384 to +16383. Any inputs outside of the accepted range will cause overflows in the FHT function and therefore unpredictable output. Care should be taken to scale the input data up to the maximum input range when possible as this ensures you get the maximum resolution from the FHT with minimum rounding errors.
The FHT is a decimation in time (DIT) transformation which takes the time-based intensities of the input sample and converts them to a frequency based representation. The output from the FHT is a set of complex numbers which represent the intensity of various frequencies ranges from the input sample.
The output from the FHT is a set of complex numbers with both real and imaginary parts. The first half of the output contains the real components of the output and the second half contains the imaginary components. This means that the output from FHT is exactly half the number of inputs (i.e. for a 256 component input you get 128 outputs).
To interpret the output from the FHT it is important to consider the sample rate of the processed audio. The FHT function operates on 32, 64, 128 and 256 sample inputs. The higher the number of inputs the more granular (narrow) the frequency ranges are. The output from the FHT is a series of frequency ‘bins’, the value of each bin represents the intensity of the input signal within the range of frequencies the bin represents. The exceptions to this are the first and last bins; the first bin is half as wide as the others (since it starts from 0 Hz) and the last bin contains the intensity at the Nyquist frequency (usually the first and last bins are ignored for most purposes). To demonstrate this (since it is at least a little confusing!) let’s consider an FHT with 32 input samples which were sampled at a rate of 20Ksps (thousand samples per second). The output bins represent an even spread of the frequencies from 0Hz to the Nyquist (in this case 10KHz) therefore the output bins have the following centre frequencies:
Note that in the table above the first and last bins are narrower than the others. What this means is, for 32 input samples into the FHT, you get 14 usable frequency bins ranging from 312.5Hz to 9062.5Hz.
From an implementation standpoint it’s important to consider that the intensity of the input to the FHT is distributed across all bins in the output. Unless you are dealing with pure sine-waves of a single frequency the result of this is that, as you increase the number of inputs to the FHT, the average output intensity per bin drops. If you consider a complex input signal with equal intensities across all frequencies from 0Hz to the Nyquist (for the sake of example we will state that all frequencies have a input intensity of the maximum allowed by the FHT function i.e. +16384) then the output for a 32 bin FHT will be 16384/32 = 512, however for a 64 bin FHT the average will be 16384/64 = 128. This is an issue when interpreting the output since higher number of bins will result in smaller average outputs; since the input resolution from the ADCs is fixed you get less and less resolution in the output as you increase the number of bins.
Usually this effect is avoided by showing a smaller range of output at less resolution and clipping any results over a certain intensity (which is what the complexToDecibelWithGain() function does – see below). This is ok if you are just after a visual representation of the audio, but not suitable for audio analysis applications where the actual intensity is required. Even though the FHT function can support more than 256 FHT inputs the resolution becomes so little in the output that it is not really useful unless you can increase the resolution of the input to compensate.
In order to keep the FHT calculations in the range of a 16 bit integer the FHT function continuously scales the output of the calculations (by dividing them in half). The net result of this is that the output is exactly half the value of the input (i.e. if you put 16834 in you get 8192 out).
The FHT is called using the fhtDitInt() function. Care must be taken to ensure that the FHT_LEN and FHT_SCALE parameters are set at compilation time to ensure the length of the FHT input data is correct.
For audio sample analysis the output of the FHT is not useful unless it is converted into a linear or logarithmic representation of amplitude. You will need to run either the linear or decibel conversion functions (see below) on the FHT output to get meaningful results.
Since the output from the FHT is in the form of complex numbers you need to convert the complex numbers into real numbers before displaying the output from the FHT. To do this you need to take the power of 2 of both the real and imaginary parts, add them together and take the square-root of the result (this is the absolute of the complex number):
fx(k) = SQRT( (fx(k)^2) + (fx(-k)^2) )
This formula gives the linear intensity of the FHT output bin and has to be applied to all output bins.
The library function complexToReal() performs the formula above on the input data and also provides the ability to scale the output. By default (with a scale of 0) the function will output scaled results in the range 0-8192. This output can be further scaled by providing a positive scaling factor to the function. For example, a scale of 7 causes the output data to be scaled by 2^7 = 128 giving results in the range of 0-63. This scaling is very useful if your output device is a display since you can easily scale the output to the resolution of the display using this function.
The following chart shows the output from a 1990Hz sine-wave sampled at 20Ksps through a 128 point FHT with rectangular windowing. The result is linear and has been scaled to a range of 0-63:
When analysing frequencies the linear intensity is useful but does not give a representation which mirrors how we hear sounds. In reality if you want to double the ‘loudness’ of a sound you must double the linear intensity at each step, for example, if you double the loudness of a sound with an intensity of 512 the intensity becomes 1024, if you want to double it again it becomes 2048. This logarithmic representation of the sound intensity is typically given in decibels.
To get from a linear intensity to a decibel representation you need to first convert the complex number into a absolute number and then scale it into decibels according to the following formula:
linear intensity = sqrt(re * re + im * im)
dB = 20 * log10(linear intensity)
Since decibel is a relative measurement we have to consider the ADC input when converting. The two important factors are the maximum input value (refV which is 5V or +16383 units into the FHT) which represents the maximum intensity (and therefore 0dBs) and the actual input value which is in the range of 0 to refV. So, in reality our input signal in dBs is represented by the following formula:
dBV = 20 * log10(V / refV)
To produce a decibel look up table we need to take into account the smallest amount of input we can measure (since the decibel scale is from 0 dBs to infinity). This is the ‘noise floor’ of the signal (i.e. below this level the real signal is indistinguishable from the noise level).
The complexToDecimal() function uses a look up table with values representing steps of linear intensity which represent decibel amounts. If you reverse the formula above to represent it in terms of the linear intensity you get:
V = refV * 10^(dBV / 20)
This is the formula that is used to generate the required linear to decibel look up table. The function simply steps through the table to find the required intensity and then takes the array index as the decibel equivalent. If the scale is -75 dB to 0 dB and the array is 64 values then each index of the array represents -1.172 dBs (-75 / 64). It should be noted that the result is relative to the actual input intensity i.e. what 0 dBs really represents is whatever the input signal is at maximum intensity.
The size of the look-up table provides the overall scale of the result. With N_DB set to 64 the output is 0-63, alternatively you can set N_DB to 128 for an output of 0-128. If you require other ranges you must regenerate the required look-up tables using the provided table generation functions.
The following chart shows the output from a 1990Hz sine-wave sampled at 20Ksps through a 128 point FHT with rectangular windowing. The result is logarithmic and has been scaled to a range of 0-63 where 0 dB is 63 and -78 dB is 0:
The complex to decibel conversion with gain function is similar to the previous function however the table is modified to scale the output differently. By raising the noise floor value or lowering the maximum intensity in the look up table you can increase the gain on smaller intensities at the expense of clipping intensities which are over the maximum. This allows you to use the function to ‘zoom in’ on a part of the output. Although this is not really useful for audio analysis it is useful when displaying the FHT output as a representation of the input sound sample as it provides more detail about smaller intensities when displaying the results. In order to be useful the table needs to be tweaked based on the expected intensity of the input and the average intensity of the FHT output which is very application specific.
The following chart shows the output from a 1990Hz sine-wave sampled at 20Ksps through a 128 point FHT with rectangular windowing. The result is logarithmic and has been scaled to a range of 0-63 where -30 dB is 63 and -78 dB is 0:
The zip file provided below contains all the required source code for the library in a Atmel Studio 6.1 project. To run the library without alteration use Atmel Studio to program the code (via ICSP) to an Arduino Uno development board. The only architecture dependent code is the USART routines which provide debug output via the Uno’s USB to serial converter. If you wish to run the code on another board then start by altering the usart.c library to your target chip.
You can also use the source-code as the basis for an Eclipse project under Linux. You can set the configuration of the fhtConfig.h header to target either AVR or Linux; the library will automatically change the required include files and use either stdio.h or the usart code for printf output. The library will also only attempt to put the pre-calculated tables in PROGMEM when targeting AVR environments, otherwise the tables are loaded into RAM.
Make sure you use either Atmel Studio 6.1 or an up-to-date version of GCC as older versions contain 32 bit multiplication bugs which can prevent the library from functioning correctly.
The library contains a function called generateTables() which calculates the data for all of the tables used in the library. The output is ready formatted as C code so you can simply cut and paste the output back in to the source files. The generateTables.c file includes lots of comments about how the table generation works which should give you the information you need if you want to alter the tables for your own purposes.
The FHT function in the library is based on “An Algorithm for the Fast Hartley Transform” by Ronald F.Ullmann and adapted from the Ratfor example code. The original article can be downloaded (as a PDF) from the following link:
[http://sepwww.stanford.edu/theses/sep38/38_29_abs An Algorithm for the Fast Hartley Transform]
An Algorithm for the Fast Hartley Transform
I’d like to thank the kind help and advice given over at Open Music Labs Forums and for their AVR assembly FHT library for the Arduino which was a great help when developing my own library:
This zip file contains the AVR Studio 6.1 firmware project files for the FHT library and the test code:
]]>The circuit board used in this article is a drop-in replacement for the original PCB; you simply remove the major components from the original board (the joystick connectors and switches) and solder them back in to the new board. The new board allows you to reassemble the Four Score without changing the look of the device. Even the turbo buttons and the 2/4 player switch is reconnected and functional.
The replacement board and firmware provides 4 HID compliant joysticks which work under Linux, Mac or Windows. All of the buttons are de-bounced on and off to give a solid feedback during game-play.
The schematic for the Four Score USB is based on the Atmel ATmega16U2 microcontroller which is easily adequate for the task and has an on-board USB transceiver. The joystick ports all share clock and latch lines which allows the microcontroller to latch the controller data, poll the clock and then read all 4 joystick states in one go. Apart from the 16Mhz clock and the standard required USB hardware the microcontroller is connected to the four joystick ports, the DPDT 2/4 players switch and the 2 Turbo buttons. The design also includes an ISP programming header to make flashing the device firmware easy. The finished schematic is shown below (and is available for download in Eagle CAD format at the bottom of this article):
Since the new PCB needed to fit exactly in the same place as the original PCB it was important to measure and recreate the original board closely so that all of the switches and ports lined up when fitted into the case. The first step was to strip all of the components from the original board to allow it to be measured accurately:
The easiest way to remove the various components is to use a wide-tip on your soldering iron and some de-soldering braid (which is also shown in the picture above). The braid allows you to cleanly remove the solder from the board and then you simply prise the parts out. Once the board was stripped and measured the boards dimensions and the placement of the major components was drawn in Eagle CAD starting with drawing the component foot-prints based on the measurements of the removed joystick ports and the three switches. The measurements and alignment could then be tested by printing the board design onto transparency sheets (such as those used for overhead projectors) and then the sheet can be overlaid on the original board to check everything is in the right place.
Once the component layout and board dimensioned were correct the rest of the required components are added resulting in the PCB design shown below:
The PCB is designed as a single-sided PCB to make it easier to produce. All of the surface mount components are mirrored in Eagle so that they are mounted on the underside of the board. The board is assembled by starting with the wire-links, then the SMT components and then finally the switches and ports from the original board. Here is a picture of the underside of the board after assembly:
The firmware project can be downloaded from the bottom of this article and contains a GPL licensed firmware project which can be opened in Atmel Studio 6. The firmware is based on the LUFA USB library and implements a composite USB device with 4 separate joystick HID interfaces. The joystick device can be seen in ‘devices and printers’ under windows 7:
Right clicking on the Four Score USB device and selecting ‘Game Controller Settings’ will show the four available game controllers which are in order of ports 1 to 4 on the device itself. If you select the first device and click on properties you will see the following window:
The button mapping is as follows:
Note that this mapping is only for the first joystick. For joysticks 2-4 there are only 4 buttons representing the joystick buttons.
The firmware function is quite easy to follow; it scans the four score buttons and then scans the buttons for each one of the joysticks. There is then a simple de-bounce procedure (de-bouncing switches helps to ensure the the button is fully pressed before it sends an ‘on’ to the computer – since mechanical switches can be noisy the ATmega may receive a number of random on/off results before the button is completely pressed or released). The rest of the firmware is involved in detecting when the host requests a HID report for a joystick and then sending the joystick report back.
The Four Score USB interface is a great hit; I fitted the unit with a 4m USB cable which allows the kids to sit comfortably on the sofa and connect the interface to the HTPC (modern LCD TVs allow you to sit a lot further back than the original TVs the games were designed for). My HTPC is running Ubuntu and the interface is very easy to map as controllers for the emulator. Once the kids have finished with the Four Score it is nice and small, so it’s simple to store until the next retro gaming session. The biggest advantage with the design is that the joysticks are all original controllers and since the alteration is all in the Four Score the original controllers still function with the NES console.
This zip file contains both the AVR Studio 6 firmware project files for the project:
This zip file contains both the Eagle CAD project files for the project:
]]>