Macintosh Plus/10

The Macintosh Plus is one of the first Apple Macintosh computers and the first Macintosh I ever owned. The Macintosh Plus is normally powered by a Motorola 68000 microprocessor.

To the right is a picture of the motherboard of one of my Macintosh Plusses upgraded to a 68010 microprocessor. After the 68030 powered Macintosh SE/30, I think Macintosh Plus/10 is an appropriate name.

The 68010 does not bring much improvement, multiply/ divide is supposed to be somewhat faster.

The cpu upgrade is interesting, but Plus/10 is mostly meant as a start to do some hardware experiments with this classic Macintosh.

The bottom side of the upgrade board with plenty of empty space for more hardware is pictured below.

More to follow…

LM75 Temperature Sensor Library for NodeMCU

In all my excitement about the ESP8266 modules, I almost forgot that I had some boards made to create nice standalone temperature sensors with the ESP8266 using LM75 i2c temperature sensors.

Before my boards arrived, I had already made the central heating temperature logger and forgot about them. Today I soldered one of these boards as a test, the result is in the picture to the right. The board is mounted on a simple breakout that I made for my ESP8266 experiments. The sensor itself is not visible, as it is on the bottom side of the black PCB, so that it can easily be mounted to a surface and make proper thermal contact.

Compared to the DS1820 one-wire sensors, the temperature resolution is not that great, only 0.5 °C resolution, but interfacing these is a lot easier. To make interfacing even easier, I created a small Lua library to read an LM75 sensor from NodeMCU, it’s available in the public domain on Github.

Usage is easy:


-- GPIO indexes of i2c signals
sda, scl = 4, 3
lm75:init(sda, scl)

The temperatures can then be read as either a sting repreenting a floating point value or scaled to an integer (temperature in °C is value/10.)

For example:

> =lm75:strTemp()
> =lm75:intTemp()

Using this library, a sensor node that emits temperatures in mrtg external script format to a TCP client can fit in this tiny snippet of code:


sda, scl = 4, 3
port = 27315

lm75:init(sda, scl)

                local temp
                temp = lm75:intTemp()
              " ticks\n"
                        function(conn) conn:close() end

See my previous post about how to easily integrate this into mrtg using netcat.


More ESP8266 Lua Projects

I had some more fun with Lua on the ESP8266 wifi modules. These things are so cheap and so versatile that I have already reserved a dedicated subnet for sensor nodes in the house.

The latest ESP8266 projects are a temperature logger for the water temperature of the central heating and a meter reader for water consumption.

The NodeMCU Lua firmware has native support for onewire, making it trivial to add some DS18B20 temperature sensors. A bit of Lua glues these to a TCP socket and outputs the sensor values when a TCP connection is made. This way it is very easy to grab the sensor values from MRTG.

MRTG Then generates pretty graphs like the one below. In this graph the red line shows the hot water from the central heating boiler, the blue area is the return water temperature.

The code behind this is too dirty to publish, some cleaning up needs to be done first. The water usage logger is a better example.

ESP8266 Lua Adventures

After appearing on Hackaday the ESP8266 wifi modules took the world by storm. No wonder; for a few Euro a piece, these modules are already cheap as embedded wifi adapters. But with an SDK available, the ESP8266 is absolutely amazing.

Development for these modules has recently gotten even better with the release of Lua firmware for these modules. Not that I’m particularly fond of Lua as a language, but it is lightweight and its not too hard to whip up some code in it without much experience. And that is what I’ve been doing today, I wrote some Lua code that runs unattended op the module, scanning for nearby wifi access points and sending these, along with the signal strength (RSSI) value to a server in my home network.

I hope to build a rudimentary location based service with this, tracking the location of the ESP8266 module through the house.

RS-422 Transputer Link, First Packets

This week another of the familiar yellow bubblewrap envelopes from China dropped on my doormat, delivering some ds89c21 rs-422 line driver chips.

The ds89c21 chips fit the board designed in the previous post and led to some first tests with a rs-422 differential link. First of all, I found that I had omitted the bias resistors necessary for the rs-422 link on the link input in my design. These were easily bodged to the board for a quick test, the ugly results of impatient soldering shown to the right. But no success, the link input remained pinned to a logic high signal.

A few days of debugging later, it suddenly dawned to me to cross the wires of the link and the link immediately sprang to life. Doh. For now the link seems to be reliable even at 20 Mbit/s, great.

I rechecked the schematic and the board silkscreen, seems that even though the ds89c21 seems to match the board, these plus/minus lines on either the receive or transmit lines are swapped in respect to the board layout.

The oscilloscope picture to the right shows that the negative signal has some nasty degradation, while the positive is pretty decent, strange. It may just as well be the terrible bodged-on bias resistors, but I can’t really explain why this would affect only one of the signal lines.

Oh well, time for more interesting tests than a simple loopback.

Raspberry Pi Inmos Link Progress

I finally found the time to work on the Raspberry Pi Inmos Link Adapter again. After spending many hours debugging the previous version without any results, I abandoned that design.

This time I managed to bring up the patience to do some quick tests on a breadboard before committing it straight to a PCB. The tests on breadboard looked promising, although I used a C012 link adaptor chip for the breadboard tests instead of the C011 used in the PCB version.

This new version is based on the Microchip MCP23017 16-bit i2c GPIO interface instead of the two PCF8574’s in the previous version.

Using only one chip makes the software side a bit easier, but the main reason I chose the MCP23017 over the PCF8574 was that I did not really trust the quasi-bidirectional IO of the latter in my previous design. The MCP23017 feels more deterministic in that respect, giving the user control over each GPIO’s direction, its default value, etc. A pretty nice chip.

All IO is now running on 5 volt, as the i2c bus is active low and pulled up to 3.3 volt by the Raspberry Pi, the MCP23017 can safely run on 5 volt without damaging the Raspberry Pi’s GPIOs.

The Inmos link, a reset line and a 5 MHz clock are available as buffered TTL signals, the link speed is selectable in software, of course with the obligatory associated blinkenlights. The IMS-C011 InputInterrupt and OutputInterrupt signals are OR-ed trough to open-collector outputs to one of the Raspberry’s GPIO’s.

I planned these signals to be available through rs-422 line drivers as well. The rs-422 transceivers I picked from Eagle’s component library seem to be either made from unobtainium or from unaffordium, though. These need to be replace with something more commonly available. As the board outline interferes with the Raspberry Pi’s ugly USB connectors as well, a third version of the board may hopefully straighten out these last few glitches.

But…does it work this time? Well, yes, it seems so, although more testing still needs to be done.

To the right is the new link interface in all its glory booting a lowly T222 Transputer.

The Raspberry’s side of things is using a little Python module to abstract the MCP23017 and C011 link adaptor from programs.

With default i2c addresses and a 10 Mbit/s link, writing a byte to the link is a simple as:

import Inmos2
link = Inmos2.Link()

The T222 booting using the new link adaptor is shown below:

hessch@archimedes ~/src/rpilink $ ./
Writing 23 bytes of boot code to Transputer:

    b1 d1 24 f2 21 fc 24 f2 
    21 f8 f0 60 5c 2a 2a 2a 
    4a ff 21 2f ff 02 00 

Read result from Transputer:

    aa aa

16-bit Transputer found

It’s alive!

Airbus MTP EPROM Repair

Last week I spent some time with an Ebay find, pictured to the right. This is a Maintenance Test Panel (MTP), presumably from an Airbus A300-600. First of all, I’m curious from which airline this unit came, as the buttons seem to have distict nicotine residue on them.

The Maintenance Test Panel is located in the cockpit of the aircraft, behind the first officer. It stores fault information from all computers that make up the automated flight system and can run tests initiated by maintenance engineers. In essence it is the debug port, or for car people, the OBD-II port of the airplanes computers.

I have close to no documentation about this unit, or its use, but it is a fun toy to play with, built with price being no issue. It is a self-contained computer system around an Intel 8085 microprocessor, a couple of Harris, now Intersil, HS-3282 ARINC-429 interfaces for communication and a two-line liquid crystal display (LCD), that is very low in contrast and lit by two good old incandescent light bulbs.

The LCD is interesting as it has no built-in character ROM, something that is rare for character LCD modules, at least nowadays where most LCD’s use a Hitachi HD44780 (or compatible) controller.

The character set for the display is stored in an EPROM on the first printed circuit board module in the unit. In the process of reverse-engineering the MTP, I made a dump of this EPROM, an Intel 2716 from the 20th week of 1981.
Why do I care so much about this date, you probaby ask?
Well, I extracted the character definitions from the ROM dump and was amazed by the amount of bitrot. Dozens of bits had clearly lost their value in this ROM. Which made for an interesting hour or so in a hex-editor, fixing the glyph definitions in the ROM dump.

After that, I tried to write the fixed ROM dump back to an EPROM. Not wanting to erase the original EPROM in the unit, I rummaged through my junk drawers and found a couple of old Soviet КР537РФ2 ROM’s. These chips should be 2716 compatibles, which was good news. Just to find that my, otherwise pretty good, TL866 programmer was not able to supply either the voltage or the current necessary to program these chips.

Already in the later hours of the evening I dug out an EPROM programmer of a vintage closer to the EPROMs to be programmed. I had bought the programmer already some years ago, but never took the time to try it. The great thing of this programmer is that it has a serial command based interface. No software on the host pc is really necessary, if you are willing to compile many arcane hex-values from bit-fields defined in the documentation and type these into a terminal, what is exactly what I did.
This is also how I had to do it, as the (although still available) software is written for long gone versions of MS Windows and I mostly use Mac OS and various other Unix flavors for my hobbies. A Windows XP virtual machine that I keep for moments like this, was certainly too recent for the programmers software, already.

Hours of fumbling with conversion to Motorola S-record formats that the programmer requires and serial line voodoo later, (my EPROM eraser running overtime in the process too) I managed to burn the fixed ROM image to the replacement EPROM chip.
If you can make out the faint text in the display in the first picture of this article, the result is just about visible.

Useful? No, certainly not, as I don’t own an Airbus A300. ;) But it made for some fun adventures with obsolete electronics, again.

A Poor Man’s PLCC Probe

Experimenting with an old Macintosh Classic, I searched for a way to easily connect my logic analyzer to its 68000 processor.

The MC68000 in the Macintosh Classic is a surface mounted 68-pin PLCC package, of course it’s possible to attach many SMD grabbers to the pins of this package, but that is far from practical.

True PLCC test adapters are far too expensive for hobbyist purposes, so I tried something else, with good results. On Ebay, I ordered a few PLCC86 sockets, and tried to placed one on top of the MC68000. This works, but not reliably, as the contact springs of the socket force the socket off the IC package.
By sanding down the PLCC socket and removing four internal notches, the socket can be pushed farther over the IC and you get a pretty snug fit.

Spot the differences in the pictures below, left the original socket, right the modified one.

The modified socket attaches tightly around the PLCC IC to be probed, tight enough that it takes some force to remove it again. Certainly good enough for probing, but it may even suffice for adding hardware permanently to the machine.

Below you can see the socket mounted on top of the MC68000 on a Macintosh Classic logic board.

Once mounted on the board, it’s easy to attach logic analyzer pods to the socket pins. But as you can see in the last picture, this becomes a ratsnest pretty fast. It suffices for now, but terminating the logic analyzer to an adapter PCB with proper header connectors for this purpose will be the next step.

Raspberry Pi Inmos Link

While I haven’t progressed much with the AVM M1 as an Inmos link adapter, I have also been designing an Inmos IMS-C011 based link adapter for the Raspberry Pi.

The Raspberry Pi link interface uses two PCF8574 I2C I/O expanders to interface to the Raspberry Pi. I2C makes development easier, as all can be done in user-mode using Python.

The software that I wrote for the AVM M1 before was not reliable, first I thought this was due to my own programming, but on more investigation it turs out that the AVM driver is interfering, but without a driver the Linux PCMCIA subsystem doesn’t allocate resources for the card.

For my purpose and because I was getting on a roll designing some other printed circuit boards in Eagle, I deciced to postpone the M1 for a while to experiment with this new link board for the Raspberry Pi.

The PCF8574 I/O expanders divide the work, one (on i2c address 0x20) handles the databus to the IMS-C011 link adapter, the other (on address 0x21) the control signals.

The circuit board shown above still has some issues, it could use a better shape to clear the composite video connector on the Raspberry Pi. I had wired the Input and Output interrupts of the IMS-C001 directly to some Raspberry GPIO’s without thinking of the 5 volt levels the IMS-C011 uses, to prevent damage to the Raspberry Pi’s GPIO’s I’ve cut the races to these GPIO’s on this board.

No software has been written yet, but the first hardware tests seem to be ok, the 5 MHz oscillator is running and both PCF8574’s can be seen from the Raspberry Pi side of things:

hessch@leibniz ~ $ sudo i2cdetect -y -a 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

The status LED’s can be made to blink with a quick and dirty shell script:

while [ == ]
  sudo i2cset -y 0 0x21 0x40 0xff; sleep 1
  sudo i2cset -y 0 0x21 0x40 0x00; sleep 1

So far so good, to be continued…

AVM M1 as Transputer Link

From my early highschool years on, I’ve been fascinated by the Inmos Transputer and have recently acquired some Inmos B004 cards and other hardware with the idea to start experimenting with Transputers.
One problem though, these B004 cards are old 8-bit ISA hardware.

Since IBM compatible PC’s are almost the complete opposite of Transputers in interestingness, I didn’t really like to invest scarce space in my house for a boring grey PC box just to fit the B004 cards. I had already been toying with the idea of making a custom interface from ISA to something more modern, but luckily I found a better option:

Axel Muhr describes on this page ( onwards his hacks using AVM B1 active ISDN controllers as B004 sustitutes. There is a PCI version of the B1, but I wasn’t sure about compatibility and the price of these cards is still higher than what I paid for my original B004’s.

Enter the AVM M1 PCMCIA card…

This card seems to be a PCMCIA variant of the B1 hardware, has 1 MB of RAM and a IMST400 Transputer on board. Making Transputers compatible with reasonably modern laptops! Oh, and these cards can be had for a few Euro a piece on Ebay.

I did some quick reverse engineering of this card. The link adapter is implemented in a Xilinx XC3164A FPGA and the T400 seems to boot from link 0. The link adapter in the FPGA looks to be IMSC012 compatible. The config of the FPGA is fixed and stored in a serial configuration ROM. Then there is a parallel EEPROM that holds all PCMCIA parameter info and a second serial EEPROM, presumably for settings storage.

The M1 was meant to interface with Siemens GSM mobile phones and as such has no ISDN controller inside, just an UART. In our case, this is actually good news, as there is no other crap attached to our precious Transputer. A similar card, called M2, exists and has exactly the same hardware but also a Siemens ISDN chipset fitted on the board.

The UART can easily be removed from the PCB, and there is probably enough space to fit some buffers or even a RS-422 driver to feed the remaining free link (link 1) to the outside, as I plan to do when I get the software side up to scratch. From there on it would be easy to bootstrap larger Transputer networks from this PCMCIA card.

A quick test with the original CAPI drivers for Linux confirms that this card appears to the host just like a B1 (and so like a B004!):

hessch@bt:~$ dmesg
[ 9888.081914] b1pcmcia: AVM M1 at i/o 0x150, irq 3, revision 3

The only problem, as could be expected with ancient hardware, is that all Linux Transputer link drivers that I could find are equally ancient. Ancient and crufty.

As a quick test, I modified Apple II interface code, also from Axel Muhr’s I translated this to a bit of Python code that uses portio to do I/O with the M1 to test loading code to the T400 Transputer. My code is far from reliable, in its current state. Actually it seems more like it worked by accident, shown here:

hessch@bt:~$ sudo ./ 
ioperm() was successful for all C012 registers from 0x150 onwards

resetting Transputer...

ISR value: 0x0
OSR value: 0x1

writing data to Transputer:

    17 b1 d1 24 f2 21 fc 24 f2 21 f8 f0 60 5c 2a 2a 
    2a 4a ff 21 2f ff 2 0 

read result from Transputer:

    aa aa 0 0 

Yay, we have a 32-bit Transputer answering!

I’m not really bothered by the reliability of my code yet, as it would be still a lot of work to make this in something useful. Having the common Transputer link infrastructure in place should make all old userspace stuff that is still available come alive again. Probably, I will strip all CAPI/ ISDN related stuff out of the working AVM M1 driver that is in the current Linux source tree and implement Transputer link driver compatible ioctl’s in that driver, as all needed functionality is already in the existing M1 driver in Linux. While writing the Python code mentioned above I had a good few reads of the source of this module already and it is quite readable, which gives me better hopes of getting something working than trying to bring the old Linux link drivers back to the 21st century.

I’ll probably create a new page somewhere on this site to document my progress. When that happens, it will be linked from here.