Archive for June, 2019

Scanning Electron Microscope reverse engineering- 8741A programmer/reader

June 7, 2019

The AMRAY 1845 FE EM we got is proving to be an interesting beast.  I has its own internal signaling network called NibbleNet.  This seems to be some variant on GPIB, but the hardware is slightly different.  We decided the best way to figure out how NibbleNet worked was to dump the program out of one of the NibbleNet control processors.  Since there are two, interchangeable instances of this IC in the microscope we think that they are generic in some way and can be helpful in figuring out the signaling protocol.  Once we’ve got an idea of the protocol we can build a sniffer and start logging data from the machine.

screenshot_20181227-145040__01

The NibbleNet processors this SEM is an 8741A, and at first it seemed like we would just be able to throw it into one of our many chip readers and read/program it but that was not the case.  The MCS-51 line of processor (the infamous 8051 line) has wide support to this day in all sorts of modern variants and vintage applications.  This is not one of that series.  The precursor to the MCS-51 is, of course, the MCS-48.  the one we have here is the 8741A (EPROM version of 8041) with 1K × 8 EPROM, 64 × 8 RAM.  Now before we get to building a reader, we should have a way to know if it read correctly.  To me, that means writing to a different processor and seeing if the board operates correctly.  We were unable to get an 8741a for this purpose, but we got an 8742 which is the double size EPROM version so it should be pretty compatible.

img_20190120_203719

I started development using the datasheet and a small stack of 8742 chips, which worked out better than you might think.  Using this for a base I built a fairly complete hardware setup that was capable of sending all the right voltages to the right pins.  The code was written from scratch, because after being unable to get the other guy’s code to do a write/verify I didn’t trust it.  Following the datasheet for the 8742 wasn’t hard and eventually I got it to the point where I was confident in the programmer.  At this point we still only have two 8741a chips, both presumably the same and containing code we can’t get back from anywhere else if we accidentally blow it away.  Turns out the 8741a is slightly different in several important ways.

8742-waveform

The first thing I wanted to do to ensure the integrity of the data was to install a hardware program/verify switch.  This physically interrupted the programming voltage from being sent to the chip so any rouge arduino couldn’t accidentally overwrite all or part of our precious chips.  I had only added the write functionality so I could validate the integrity of the tester.  The second thing that had to be done is add another switch that selected between the 8741a and the 8742 voltage on the EA pin.  On the 8742 it’s 18v, which is not the highest voltage in the system so I’m creating it with a linear regulator.  On the 8741a it’s 23v which is the highest voltage in the system so it’s coming straight off the input pins (and why I have the board labeled very carefully.  This also means that when going to the 8741a you have to run the whole board at two volts higher than when you run an 8742.

8741a-waveform

With EA sorted out it took Frank to determine that you have to bring Test0 low to reading the 8741a.  I didn’t get that from the datasheets, you can see that’s not the behavior on the 8742 and it’s not called out on the 8741a. He got it from the 8748 datasheet and it worked beautifully.  We now have the NibbleNet program memory dumped, but there’s an issue.  When we load this program into the top half of memory of the 8742, it doesn’t run correctly.  That being said, my validation of running correctly is that an LED is solid and not blinking so I’m not 100% sure here.  When we put the code into both pages of memory it seemed to work, but it may just be doing enough to keep the watchdog on the other (I’m assuming 80186) processor happy.

8742-code

The pictures are here and all the rest of the documentation for this project is here.

Arduino control over Ham radio

June 6, 2019

This is not my idea, but I finally got around to setting up and testing it so I can show you what I did and why.  When I got my ham licence I got myself a decent radio, a Yaesu ft-60r.  That wasn’t cheap, but I trust it’ll be good for quite a while and is of a good quality.  What I eventually also got was a Baofeng UV-5RV2+ but this I got as a receive only radio.  I have no intention of breaking it or making any hardware modifications, but I just don’t intend to use it as a radio to talk on.  Some people think they create a ton of interference when they transmit, but mostly there’s a dislike of cheap radios because it’s a lower barrier to entry.  That’s not the point here.  The point here is long range control of a system with minimal hardware.

20190414_204040

If you need to control something over a long distance (~2 miles away) you might choose to use wifi and the internet.  This is a reasonable choice and by far the cheapest, but it requires internet at both locations.  You might choose cellular radio modems, but those are expensive and you have to pay for a service to make them work.  You might even choose some purpose built radio modems, but those are usually unreasonably expensive and a lot of trouble to use.  I have a simple control scheme that requires no special hardware at the sending end and a cheap, small receiver using mostly commodity hardware.

20190414_204047

My initial setup uses a Ramsey TT7 decoder kit and an arduino pro mini.  The decoder kit has a logic chip that decodes what button is pressed and triggers one output, but the arduino can do that in software and not require as many pins.  My modification to the kit was to piggyback a header that exposes power, ground, the binary decoded key and the latch signal that is enabled when the data on the bus is good.  The code I have is simple and is an example that can be modified for basically any use.  The initial idea was an RF remote control for a DSLR setting the photos to be taken, focus or not, number of photos and time between them, or video start and end (or set duration).  I still like this idea, but I don’t have a camera to use like that so I’ll have some other eventual use.