Recently [Drygol] had an Amiga 1000 system over for some repairs as well as maintenance and general TLC. This is a Motorola 68000-based home computer from 1985 that also has the distinction of being the first Amiga system to be released by Commodore. At a time when the IBM PC was still strutting its monochrome and EGA graphics alongside PC speaker beeps, the Amiga 1000 featured relatively high-res graphics and advanced stereo audio courtesy of special accelerator chips.
Overall the system was in a pretty good condition, even coming with the very nifty modern Parceiro expansion that adds 8 MB of fast RAM, an SD card slot and RTC. This thus meant that they mostly just had to perform the typical maintenance task, such as recapping the PSU and mainboard, as well as recapping and lubing up the floppy drive. The original 230 VAC fan in the PSU also got swapped with a 12V unit that was much quieter.
After disassembling the keyboard for some deep cleaning and retr0brighting, a little glitch in the form of the use of a too long screw by a previous owner was addressed, as well as a broken plastic clip. With how little attention the Amiga 1000 received after its release it’s good to see some of these units still kicking.
Back in the early 1980s when 8-bit home computers became affordable educational toys for children, the traditional paper publishing industry did its best to keep up. For a few brief years, there were children’s books dedicated to the innards of a computer in meticulous detail, and courtesy of [Jason Jacques] we have a chance to look at one of the lesser-known ones.
The British publisher Ladybird made a series of four computer books, and while the first three had content for both the Sinclair Spectrum and the BBC Micro, the last in the series only featured the BBC. [Jason] took that book and re-imagined the missing Sinclair Spectrum version.
The surprise is how deep it dives into the architecture of an 8-bit computer, and it’s refreshing to see something that’s not unduly dumbed-down for kids. We’re guessing that this would have appealed to the 5% of kids who ran with their computers rather than just playing Jet Set Willy back then, and we’re sure a few grown-up 50-somethings may remember it or books like it.
After getting his hands on a rope driver module from the Apollo project era that had a big ‘Scrapped Module’ stamped on it, [Mike Stewart] was naturally left curious as to what exactly had failed in this module. Originally destined for the Apollo Guidance Computer, these Raytheon-manufactured modules were the pinnacle of space-grade high-tech of the 1960s, with requisite acceptance testing so as to not endanger a very expensive space mission.
The cool part here is that the acceptance documents for the module in question (B16-B17) have been scanned in and can be found on the Internet Archive. With the part itself being potted and very much inaccessible, this document helpfully lays out the expected measurements on the module’s pins, as well as schematics and mechanical drawings. Unfortunately the reasons for the rejection were not recorded, so replicating the failing test results is required to understand the reason.
NASA Rope Driver Module with suspicious exploration marks. (Credit: Mike Stewart, YouTube)
A slight complication here is that the testing procedure doesn’t just involve hooking up a multimeter for some voltage and capacitance measurements. There are also temperature and voltage extremes, and vibration tolerance involved, which would be somewhat complex to test, but most of all risk damaging a historical artefact. Thus a somewhat conservative testing procedure was chosen, even if this may not reveal the actual fault.
As noted in the video, sometimes modules were also rejected because someone simply dropped it on the floor along the way. However, generally if a module was found to be faulty they would open it to diagnose said fault, with a closer look at this module indeed revealing suspicious marks in the potting compound where it was apparently opened and conceivably repaired. This also might explain why they also put the ‘For engineering use only’ on it.
With multiple of such locations visible in the potting compound, these locations were mapped to the schematics for the module, to get some idea of what may have been accessed. After this, basic testing was performed on the module, as per the acceptance testing document.
Along the way an error was detected in said document, in the form of the wrong pin number. In table 4-2 the input pin 269 was mistakenly listed as having output pin number 169 when it should have been pin 168. Pin 169 is chassis ground, so this was presumably fixed in a later version of the document.
After all the testing with just stationary, room-temperature conditions, everything appeared to check out. This means that likely this was indeed a repaired module that got subsequently used for engineering purposes rather than installed in flight-ready hardware. The only issue found was that channels were out of calibration, but whether this was an original flaw or due to the module being half a century old is hard to tell in the absence of repair logs.
Overall it’s an exciting opportunity to document another part of history, since so many of the details pertaining to these original modules and related technologies got lost or muddled over the decades.
One of the disadvantages to collecting retro peripherals is that they’re not necessarily easy to use anymore. [eSPee77] changes that by retrofitting a Genius GM-6000 mouse with modern hardware, all while preserving the feel.
To make this mouse without compromising on the feel of the original, means replacing the PCB with a new one while retaining the same buttons and encoders. So [eSPee77] did exactly that. At the heart of the conversion lies an nRF52840 on a custom PCB. It uses new optical sensors to read the existing quadrature encoders, and uses the same type of switch for the mouse buttons as the original.
But from there, it diverges because–powered by the BLE capabilities of the nRF–this is actually a wireless mouse! And the modern features don’t end there, either. To support scrolling on a mouse which did not originally have it, you can press the middle mouse button while moving it forward/backward. Finally, as the cherry on the cake, it features an “air mouse” mode using an inertial measurement unit, handy for use in presentations.
When the Internet first started gaining mainstream popularity in the late 90s, many optimists claimed that it would bring people together by reducing barriers to communication. That ideal hasn’t exactly come to pass yet, as anyone who has been on the Nextdoor neighborhood social network can likely attest to. Before social media, neighbors weren’t completely in the dark about their local communities, though. Besides word-of-mouth communication, there were also local access channels on cable TV, which had none of the downsides of modern social media. And [Hans] is bringing this style channel back.
[Hans]’s project is called CABLE 82, a bulletin board channel that matches the style of these channels from the 1980s. There’s better technology available for these types of systems now, though, so instead of relying on something like a character generator he’s using a Raspberry Pi running custom software to produce the video feed. The Pi hosts a web server so the 4:3 video feed can be reserved for the bulletin board display, but users who have older Pis with the yellow composite video output can skip using something like an HDMI to RF converter on their period-appropriate CRT displays. The software also adds sound functionality, as these channels always had some sort of elevator music playing while they were scrolling through local community news.
For those looking to recreate some of the nostalgia of 1980s community and technology, [Hans] has made this project open source, with all of the files on a GitHub page. Part of the reason [Hans] got interested in building something like this is that he had been trying to source a CRT television for retro gaming, and wanted to reproduce more of that era than just a few video games. A channel like this would be a great addition to a complete cable TV recreation build like this one, which even includes a preview channel of everything playing.
We enjoyed [Beej’s] trip down memory lane looking at a BASIC game, The Wizard’s Castle, written for the Exidy Sorcerer. It appeared in a 1980 magazine that included the title graphic above. It reminded us how, back in those days, we did things with BASIC that you shouldn’t be able to do and it often looks, today, rather cryptic.
In particular, even if you know modern BASIC, these few lines might give you a pause:
10 REM"_(C2SLFF4
40 POKE 260,218: POKE 261,1: T = USR(0): T = PEEK(-2049)
80 Q = RND(-(2*T+1))
Line 10 is a comment, but a strange one. Certainly that doesn’t matter, right? Actually, it is a key part of the action. On line 40, you can see some pokes to write directly to memory and a peek to read some memory value back. The USR function calls some machine language program. You may realize the whole thing is to get some value T to seed the random number generator in line 80.
This leads to a few obvious questions. First, how does USR know what to call? Second, where is the machine language program? The details varied by system, of course, but in this case, the program knows that location 259 has a jump instruction that USR called. So poking an address into 260 and 261 was telling USR where it should go.
But what’s at that address? Keep in mind that an old computer like the Sorcerer didn’t have megabytes of memory being swapped about by an operating system. That means that things tended to be in known places and that BASIC had to be judicious about storing source code.
Back in the late 90s when absolutely everybody knew that Java was going to become the one programming language to rule them all, the Java Ring was handed out to folks at Java developer conferences as an example of how it was going to revolutionize smart wearable devices. Recently [Daisuke Yamazaki] got his mittens on one of these collector’s items to see about reviving it.
We talked about these rings and associated iButton devices before, with their intended use being primarily to act as authentication keys. For the Java Ring, this use was mostly just used as a kind of gag, whereby visitors to these conferences could specify their coffee preferences at a terminal, having this programmed into the ring so that they could get their desired cup of literal java at various bean juice dispensers around the conference site.
Talking to one of these iButton devices requires a so-called Blue Dot adapter, which [Yamazaki-san] purchased along with the ring. Although the device happily responded on the 1-wire bus, figuring out how to interact with the original Java-based firmware and answering the question of how much of the original information of someone’s coffee preferences in ’98 were retained would require more sleuthing.
