My recent trip to the CCARC Field Day at Wyong resulted in the purchase of a stack of random bits and pieces. The fun is, as expected, sorting through the stuff in detail, learning about it in the process and getting it working in some way if possible. With the “as-is” nature of the items, it’s almost certain to encounter some strange behaviour … so what sort of mysteries await?
Hexin 2108E Serial Device Server
For better or for worse, my busy little fingers couldn’t resist picking up this Hexin 2108E serial device server. I actually find putting serial devices onto the network quite convenient and this unit was so clearly a rip-off of the Moxa NPort 5110 I looked at earlier, I wondered if it was even any good. The case, the colouration, the LED position … everything was familiar yet … somehow strange.
The server is practically self-contained – give it Ethernet, power and a serial device and off it goes. But what’s inside, I wondered?
Removing two screws, one on each side, allows the top cover to pop off.
It reveals a base PCB with a module sitting on top. The main IC in charge of the action is obscured by a holographic label.
Looking at the rear of the PCB, there seems to be a lot of dried flux residue and some unpopulated areas, which may be for a different (RS-422/488) version. The PCB is marked HX0704. The board itself already looks poor, as close examination shows an error in the PCB resulting in the green LED’s positive leg needing to be “poked through” the hole and soldered to an adjacent leg.
Looking briefly at the design, it seems that the power input is reverse-polarity protected through a diode, filtered through L1 and a few capacitors and then regulated through a switching converter consisting of U1 (an On Semiconductor MC34063). The module houses the main microcontroller, a 3.3V AMS1117 linear regulator, a 25MHz timing crystal for the Ethernet and a 22.1184MHz crystal for the microcontroller for exact baud rate division. There seems to be an external Toshiba TC55257DFTI-70V 32kiB SRAM, with an HC373 transparent D-Type latch for the interface. The module also contains the necessary Ethernet magnetics. The output of the module drives a MAX232 Serial Line Driver to obtain the necessary drive voltage, while being protected by four TVSS diodes on the rear.
The module itself has mcuweb.com written on it, but it seems they are defunct. Underneath the label, the chip is unmarked – it probably has all its markings ground away, but I suspect it’s probably nothing special – perhaps a low-powered ARM chip (e.g. the NXP LPC-series).
Configuring the unit is a load of fun – downloading the software from Hexin’s site provoked a number of warnings of potential malware – scans above using VirusTotal showed the configuration utility was detected by a lot of engines but these were generic heuristic detections (likely false alarms) due to commonalities between the configuration software and trojans (e.g. use of packers, network access requests).
It seems the unit had been configured away from its original defaults – set to 10.1.1.7 with a baud rate of 9600 and non-standard ports. Already, we can see just how restrictive this clone is – it doesn’t have functional DHCP, nor a web interface for configuration.
In fact, in the four screenshots from Wireshark above, we can see configuration is based on a broadcast mechanism with everything in plain-text. There is no password against reconfiguration at all. While the unit claims to have VCOM mode capabilities, no VCOM drivers are supplied either and documentation is sparse. While it may look vaguely like the Moxa, its capabilities are pale by comparison.
I quickly tried to reconfigure it to what I needed – an address I could rely on, a port number I could remember and a baud rate from “this side of the 20th century”. But then I ran into a snag – I was only getting garbage from the unit. Setting it back to 9600bps, it seemed to work but not particularly reliably. Something is going on … time to crack out the oscilloscope.
We have a problem … look at that! At 9600bps with random data fired into the converter, it shows a voltage level that swings between about -0.2V and up to roughly 8V. There is also quite a long rise to the waveform too. That’s not what serial is supposed to look like – no wonder it’s tripping up devices. At 115200bps, it was practically unrecognisable as being UART. Note that above, I got the polarity of the UART decoder configuration wrong – so ignore the decoded data trace below.
Putting my thinking cap on, it looked suspiciously as if the negative part of the waveform was clamped and the positive was facing some gross capacitance-style loading. I suspected either a fault with the TVSS diodes, a bad MAX232 or bad capacitors. I probed the TVSS diodes and found one was basically shorted through. Getting out the hot air gun and removing that one diode didn’t fix it either.
I then suspected that perhaps all the TVSS diodes are bad even though they didn’t measure bad on a handheld DMM. Perhaps at higher voltage, they exhibit other behaviour or capacitance. I got out the hot air gun again and removed all the TVSS diodes.
While they are nice to have to protect the unit from ESD or induced voltages from distant lightning, their omission for indoor “at home” use is probably not a big problem in itself.
But now, the unit works as expected – the above is 115200bps showing a good swing from -9V to +9V and a very square waveform as it should be. No problems with the decode either, especially now that the decoder polarity is set correctly.
This still doesn’t solve the strange oddity that the unit has – it seems to echo everything that is sent to it back to the sender … and only sends things after a certain number of characters are received or a CR/LF is received. Without the configurability to tweak this, it can only be used for certain applications where these issues can be worked around.
Perhaps the $10 I paid for it was too much … given its capabilities and its condition. At least it’s no longer complete junk … although it is still pretty trashy.
Going along the car boot sales, I spotted some expansion cards I wanted to buy. The seller decided to take some money in exchange for me hauling off the whole box (including some cards I had no idea about), so I eventually agreed and ended up with these curiosities.
The first card of the pair looked very much like a memory card of sorts. The first four chips are NEC SRAM modules, but the next four are EPROMs – two National Semiconductor chips, a Toshiba and a Texas Instruments. A bit unusual to see mismatched EPROM vendors, but the stickers suggest that the EPROMs were used in pairs with MSB on one and LSB on the other – EXT0 and EXT1 suggest these may contain some sort of extension code for the system.
The rear of the board contains some traces, as expected. The board itself appears to be Eurocard sized, which was a fairly popular way to build industrial modular computers in the old days.
Looking at the connector, it seems to have the standardised connector as well – so I suspected it might be something like STEbus, VMEbus or similar. Unfortunately tracing the pin-outs for power already suggest that the wiring is not either one of the buses I had guessed …
It’s interesing to see that the board has jumper headers and instead of using “shunts” as we normally do, these boards have them wire-wrapped for additional rigidity.
Looking for more clues, we turn our attention to the second board which appears to be the heart of the system. This one comes complete with the front cover plate as well. The board has two mismatched EPROMs as well, an NEC and a National Semiconductor one, with the same high/low byte arrangement. It seems to say CPU V31. The pencilled “SN60” might indicate it’s part of a batch of ROMs. The board is indeed a CPU card, marked CPU-86-1 from Elcodata. Looking up Elcodata leads me to some information that seems to place them as a subsidiary of Elcom, and possibly identifying the bus as “AMS Bus”. The board has a serial number of 108021 and features an NEC V30 CPU, which is a clone of the Intel 8088. Judging from the crystal oscillator next to it, it could well be operating at 9.8304MHz but this is definitely a useful rate for division to common UART clocks.
The rear of the board has a lot of thin traces with “squiggly” routing. Some of the traces near the top have been damaged in transport, unfortunately.
The edge has the same standard type of connector, being from the same haul of stuff and having the same handwriting on the labels over the EPROMs, I’m fairly confident they are used together.
There is another crystal oscillator can near the side which is 16MHz, but this seems perhaps a little high for the V30.
The front plate has a button (presumably to reset the CPU) and nothing else. The card “handle” has CPU86-1 marked on it, being such a generic term, it doesn’t turn up much in the way of information.
The only way to cure the curiosity would be to dump the ROMs and examine their contents after reassembling the pairs of images together.
The beginning of the ROM gives us a hint – “MSP 65-EXT-ROM”. Any ideas yet?
Further along, the string “mspcpu” comes up, along with a list of error-descriptor strings. Seems like some compiled program is probably running on the device.
Looking at another ROM, again, “MSP 65-EXT-ROM” is seen, but now the words “Operating Panel” appear with a list of parameters including MEAS, OBS1, OBS2, DARK, OBJEC, REFL, AUX, AF, S1-S8, DISP, ADJU, FUNC, PARM. Based on this, it’s probably from some type of measurement device.
More standard error descriptor strings appear …
This is rather interesting – ROM copyright date of 1989 to CZO. There are a few interesting initialisation message strings, but the clue seems to be Autofocus control – something to do with a camera, but also the words Axiotron Interface.
The nut has been cracked – I suspect CZO stands for Carl-Zeiss Optics and the cards come from an MSP 65 Microscope Stage Platform Controller (one reference in a journal paper). The relevance of Axiotron is that it may have been used with Axiotron microscopes (perhaps even this one). Given that we now know what it is, we should probably still look at some of the other strings …
Judging from the above, it seems the MSP 65 may have also co-ordinated a camera along with some filters.
These error messages seem to be specific for the program.
There are a few more parameters as well. I’m still not sure exactly what the program actually does, but before looking at the ROM, I would have never imagined the cards would have come from some computerised optical equipment!
Conner CP-3040 SCSI Hard Drive
One of the rather interesting finds digging through a box at Salbay Engineering’s stand was a Conner Peripherals CP-3040 SCSI hard drive. While I do have fond memory of Conner drives in Compaq computers being reliable enough and not particularly stellar performers, to encounter one in the wild in 2019 was somewhat unexpected given that they ceased to exist in 1996 having been bought out by Seagate.
This is the drive itself from the top. A nice and clean black top, adorned with two labels. It appears to have been Assembled in Singapore perhaps in Week 28 of 1991, making the drive 28 years old.
Looking from the underside, we can see a very crowded circuit board with relatively “thick” surface mount chips. A Signetics 27C256-15A EPROM holds the firmware, copyright 1990, version SA2.47. The SCSI interface appears to be handled by the Adaptec AIC-610L, with the remainder of the drive’s functionality spread across a number of chips from Motorola, an Asic from Conner, a Plessey ULA and a mixture of other chips. It seems that the head interface involves a number of optoisolators as well. The SCSI interface had a decent amount of bent pins, but to my surprise, the termination resistor packs remain fitted which is good.
From the rear, power is supplied via a standard Molex power connector.
Looking from the sides, I was surprised to see that the top and bottom case halves meet at an angle rather than straight. I suspect other Conner models may have changed this to reduce manufacturing costs.
There are a few jumpers and connectors at the front as well.
So far, there hasn’t been any hint as to what this drive may have been used with, however, a quick search of the model seems to suggest it may have come out of an Apple Macintosh Portable or 40SC External Hard Drive or similar. Most IBM-PCs of the era used either ST-506 interface or IDE.
Powering up, the drive does spin up with a rather noisy whine. It’s even detected with its ID (probably from the EPROM). But when it comes to reading, it returns no mode-pages, no geometry and no data.
So in the end, unfortunately the Conner CP-3040 hard drive was a disappointment. While it did manage to spin-up and get detected on the SCSI bus correctly, it could not respond to mode-page queries and had no geometry at all. As a result, no data recovery seemed possible. Perhaps the low-level formatting had been lost due to demagnetisation, head damage or bearings being too loose causing run-out error. At least it still works fine as a SCSI bus terminator … so I’m not going to take it apart or throw it out just yet.
The stuff you get from a swap meet like the Wyong field-day is very much a mixed bag. Vintage stuff especially can have rather interesting stories to tell, if you delve into it deeply. But half-working and broken things are an invitation to learn, diagnose, troubleshoot and repair, which in itself, could be a rather educational endeavour.