You think of digital displays as modern, but the idea isn’t that new. We had clocks, for example, with wheels and flip digits for years. The Racal frequency counter that [Thomas Scherrer] is playing with in the video below has columns of digits with lamps behind them. You just need the right plastic and ten lightbulbs per digit, and you are in business. Easy enough to accomplish in 1962.
Inside the box was surprising. The stack of PC boards looks more like a minicomputer than a piece of test gear. There were a few novel items inside, too, ranging from a glass-encapsulated crystal to an interesting method of selecting the line voltage.
We always love to see projects where you can build your own lab equipment so [CompactDIY’s] homemade seismograph caught our eye. The design uses an Arduino with an accelerometer and builds on one of their earlier projects. You can see a video of the device below.
The principle is simple. A hobby servo controls a pen and a stepper motor rolls paper, creating a makeshift strip recorder. Its software uses the Visuino system, which is a flowchart-like system, but it outputs Arduino code. Honestly, we would probably have just plotted the data on a PC, but there’s a certain charm to the strip recorder and the idea would work for other types of data recording projects, too. We thought if you rearranged the stepper motor and cut a paper disk out, you could also have a circular chart recorder easily, which wouldn’t need to friction transport the paper. A clock motor would make it even less dependent on software, too.
If this project interests you, try a Raspberry shake, which isn’t as delicious as it sounds. Or, keep an eye on the entire globe, if you prefer.
Some things go together, like chocolate and peanut butter. Others are more odd pairings, like bananas and bacon. We aren’t sure which category to put [IMSAI Guy]’s latest find in. He has a microscope with a built-in digital multimeter. You can see the video of the device in operation below.
The microscope itself is one of those unremarkable ten-inch LCD screens with some lights and a USB camera. But it also has jacks for test probes, and the display shows up in the corner of the screen. It is a normal enough digital meter except for the fact that its display is on the screen.
If you had to document test results, this might be just the ticket. If you are probing tiny little SMD parts under the scope, you may find it useful, too, so you don’t have to look away from what you are working on when you want to take a measurement. Although for that, you could probably just have a normal display in the bezel, and it would be just as useful.
At about $180 USD, it’s not exactly an impulse buy. We wonder if we’ll someday see an oscilloscope microscope. That might be something. These cheap microscopes are often just webcams with additional optics. You can do the same thing with your phone. If you don’t need the microscope, but you like the idea, can we interest you in a heads-up meter?
[Danman] has digital door phones manufactured by Tesla — or at least, a Tesla, as they’re not to be confused with the carmaker, though. The problem is if someone comes to the door when no one’s home, there’s no remote indicator. The answer? Reverse engineer the protocol and fix it.
A quick dump on a storage scope showed the data clearly, but it wasn’t obvious what protocol it was using. After a little analysis, it proved the datastream used 4 PWM pulses as symbols with three symbols: one, zero, and stuffing sequence.
Once you can read the bits, it is easy to determine that each frame consists of a 16-bit destination and source address, along with a command byte and a checksum byte. Each station can have an ID from 000 to 999 although you can only dial up to number 323. Some nodes are special, and there are ways to address particular units.
Connecting to the hardware took a transformer for isolation. Honestly, unless you have this exact hardware, this isn’t likely to be something you can directly use. However, it is a great example of how you can figure out a specialized device and bend it to your will.
LTSpice and the underlying Spice engine does a great job of simulating ideal components. But it is also capable — if you know how — of handling models of real-world devices. Inductors, for example, are one of the most imperfect components. Their constituent wire has resistance, and there is parasitic capacitance between the windings. If there is a core, it also will have many imperfections and losses. [Sam Ben-Yaakov] has a lecture about modeling real inductors in LTSpice, and he covers how you can capture some of these imperfections in the video below.
There is a bit of math in the presentation, but we liked that it relates back to datasheets for actual components. Being able to understand what the parameters on a datasheet mean is crucial, and if you ever wondered what some of these entries mean, you’ll get a lot from this video.
The main feature of the model is the flux equation. The tanh (hyperbolic tangent) function is similar to the curve you want for the flux equation, so it plays a major part. Of course, there are other parts of the inductor you may have to model, too, but this is one of the most difficult parts.
Video gamers know about cheat codes, but assembly language programmers are often in search of undocumented instructions. One way to find them is to map out all of a CPU’s opcodes and where there are holes, try those values, and see what happens. Not good enough for [Ken Shirriff]. He prefers examining the CPU’s microcode and deducing what each part of it does.
Microcode is a feature of many modern CPUs. The CPU runs several “microcode” instructions to process a single opcode. For the Intel 8086, there are 512 micro instructions, each with 21 bits. Each instruction has two parts: a part that moves a source to a destination and another that performs some other operation, such as an ALU operation. [Ken] explains it all in the post, including several hidden registers you can’t see, but the microcode can.
Searching for holes in the opcode table.
Some of the undocumented instructions are probably not useful. They are either impractical or duplicate a function you can already do another way. Not all of the instructions are there for technical reasons. For example, opcode D6, commonly known as SALC for “Set AL to Carry”, seems to exist only as a trap for anyone making a carbon copy of Intel’s microcode. When other companies like NEC made 8086 clones, having an undocumented instruction would strongly suggest they just copied Intel’s intellectual property (in NECs case, they didn’t).
Other cases happen where an instruction just doesn’t make sense. For example, you can pop all segment registers, and though it is not documented, you can deduce that POP CS should be opcode 0F. The problem is there is no sane reason to pop CS off the stack. The instruction works; it just isn’t useful. The opcodes from 60-6F are conditional jumps that are no different from the instructions at 70-7F because of decoding. There is no reason to document both identical instruction ranges.
The plot thickens when you go to two-byte instructions. You’ll find plenty of instructions of dubious value. You don’t hear much about undocumented instructions anymore. Why? Because modern CPUs have enough circuitry to dedicate some to detecting illegal instructions and halting the CPU. But the 8086 was squeezed too tight to allow for such a luxury. Good thing for people like us who enjoy solving puzzles.
Illumos is an OpenSolaris-derived Unix system, and no Unix is complete without a C compiler or two. And with a name like Portable C Compiler (PCC), you would think that would be a great bet to get up and running on Illumos. That’s probably what [Brian Callahan] thought, too, but found out otherwise.
PCC already generates x86 code, so that wasn’t the problem. It was a matter of reconfiguring the compiler for the environment, ironic since PCC probably started on true Unix but now won’t work with 64-bit Solaris-like operating system. According to the post:
It looks like some time ago someone added configuration for 32-bit x86 and SPARC64 support for the Solaris family. But no one ever tried to support 64-bit x86. So first we had to teach the configure script for both pcc and pcc-libs that 64-bit x86 Solaris
