Would you believe that the first large-scale virtual meeting happened as early as 1916? More than a century before Zoom meetings became just another weekday burden, the American Institute of Electrical Engineers (AIEE) pulled off an unprecedented feat: connecting 5,100 engineers across eight cities through an elaborate telephone network. Intrigued? The IEEE, the successor of the AIEE, just published an article about it.

This epic event stretched telephone lines over 6,500 km, using 150,000 poles and 5,000 switches, linking major hubs like Atlanta, Boston, Chicago, and San Francisco. John J. Carty banged the gavel at 8:30 p.m., kicking off a meeting in which engineers listened in through seat-mounted receivers—no buffering or “Can you hear me?” moments. Even President Woodrow Wilson joined, sending a congratulatory telegram. The meeting featured “breakout sessions” with local guest speakers, and attendees in muted cities like Denver sent telegrams, old-school Zoom chat style.

The event included musical interludes with phonograph recordings of patriotic tunes—imagine today’s hold music, but gloriously vintage. Despite its success, this wonder of early engineering vanished from regular practice until our modern virtual meetings.

We wonder if Isaac Asimov knew about this when he wrote about 3D teleconferencing in 1953. If you find yourself in many virtual meetings, consider a one-way mirror.

Before flat screen technologies took over, we associate TV with the CRT. But there were other display technologies that worked, they just weren’t as practical. One scheme was the Nipkow disk, and [Bitluni] decided to build a working demonstration of how such a system works.

Essentially, there’s a spinning disk with a spiral pattern of holes in it. As the disk spins, a light behind it turns on or off. If you time everything right, you get an image that can move. This particular model uses stepper motors, which is a bit of a modern concession.

The result was actually much better than you might guess, but a far cry from a modern display device, of course. The screen material needed a little tweaking, but even the initial results were very impressive. If this were trying to be practical, it would probably require a bit more work on the light source and screen.

Interestingly, the Nipkow disk arrangement was just as suitable for scanning as displaying. Instead of a light behind the wheel, you simply used a light sensor. Of course, in practice, getting everything synchronized and mass-producing high-resolution sets would have been a tremendous challenge a century ago.

Not that people didn’t try. There were even color systems using mechanical wheels. In the 1930s, people were sure your TV would contain spinning disks.

[David Shadoff] has a clear soft spot for the NEC console systems and has been collecting many tools and data about them. When developing with these old systems, having a way to upload code quickly is a real bonus, hence the creation of the PC-FX Dev Cart. Based on the Raspberry Pi RP2040, the custom cartridge PCB has everything needed to run software uploadable via a USB-C connection.

While the PC-FX is a CDROM-based system, it does sport a so-called FX-BMP or backup memory port cartridge slot, which games can use to save state and perform other special functions. Under certain circumstances, the PC-FX can be instructed to boot from this memory space, and this cartridge project is intended to enable this. Having a quick way to upload and execute code is very useful when exploring how these old systems work, developing new applications, or improving the accuracy of system emulators. The original FX-BMP cartridge has little more inside than a supercapacitor-backed SRAM and a custom interfacing IC, and of course, it would be quite a hassle to use this to develop custom code.

The RP2040 isn’t really being too tasked in this application, with one core dedicated to emulating a 128K x 8 SRAM, handling the PC-FX bus interface, and the other doing duty on the USB side. At the top of the PCB are a pair of 74LVC16T245 16-bit level shifter ICs, which need to be translated from the 5 Volt console voltage domain into the 3.3 Volts at which the microcontroller operates. Power for the board is taken from the USB, not the console, enabling code to be uploaded before powering up the target. This way, the power budget of the console isn’t compromised, and the cartridge can be initialized before powering up and booting.

[David] Needed to overclock the RP2040 to 240 MHz, way beyond the specification limit of 133 MHz, because despite the PIO block being fast enough to emulate the required interface timing, the latency passing data between the PIO and the CPU core was too large, hence the need for GPIO-based solution. The project was created in KiCAD; the design files can be found here, and only one mistake has been found so far!

[David] is also heavily involved with documenting and collecting all the PC-FX resources available in the wild. These can be found in this GitHub repo. It doesn’t look like we’ve covered the PC-FX before, but we have seen a few hacks about its older sibling, the PC Engine and the closely related TurboGrafx-16. Here’s a simple PC engine-to-TurboGrafx converter board for starters. If you lack the genuine hardware, do not despair; here is an FPGA-based emulator.

Over at the University of Wisconsin’s Undergraduate Projects Lab (UPL) there’s been a way to check whether this room is open for general use by CS undergraduates and others practically for most of the decades that it has existed. Most recently [Andrew Moses] gave improving on the then latest, machine vision-based iteration a shot. Starting off with a historical retrospective, the 1990s version saw a $15 camera combined with a Mac IIcx running a video grabber, an FTP server and an HP workstation that’d try to fetch the latest FTP image.

As the accuracy of this system means the difference between standing all forlorn in front of a closed UPL door and happily waddling into the room to work on some projects, it’s obvious that any new system had to be as robust as possible. The machine vision based version that got installed previously seemed fancy: it used a Logitech C920 webcam, a YOLOv7 MV model to count humanoids and a tie into Discord to report the results. The problem here was that this would sometimes count items like chairs as people, and there was the slight issue that people in the room didn’t equate an open door, as the room may be used for a meeting.

Thus the solution was changed to keeping track of whether the door was open, using a sensor on the two doors into the room. Sadly, the captive-portal-and-login-based WiFi made the straightforward approach with a reed sensor, a magnet and an ESP32 too much of a liability. Instead the sensor would have to communicate with a device in the room that’d be easier to be updated, ergo a Zigbee-using door sensor, Raspberry Pi with Zigbee dongle and Home Assistant (HA) was used.

One last wrinkle was the need to use a Cloudflare-based tunnel add-on to expose the HA API from the outside, but now at long last the UPL door status can be checked with absolute certainty that it is correct. Probably.

Featured image: The machine vision-based room occupancy system at UoW’s UPL. (Credit: UPL, University of Wisconsin)

[Sebastian Mihai] is a prolific programmer and hacker with a particular focus on retrocomputing and period games, and this latest hack, adding new gameplay elements to Capcom’s Street Fighter II – Champion Edition, is another great one. [Sebastian] was careful to resist changing the game physics, as that’s part of what makes this game ‘feel’ the way it does, but added some fun extra elements, such as the ability to catch birds, lob barrels at the other player, and dodge fire. The title screen was updated for each of the different versions, so there is no doubt about which was being played. This work was based on their previous hacks to Knights of the Round. Since both games shared the same Capcom CPS-1 hardware, the existing 68000 toolchain could be reused, reducing the overhead for this new series of hacks.

Obviously, without access to the game’s source code, the hacks (all seven of them!) were made by binary modification, first learning about how the original program stores aspects of the game and hacking in a little hand-grafted assembly here and there to sneak in the extra elements without interfering too much with the original code operation. [Sebastian] stripped out some title screen effects to speed boot time and removed some in-game graphics, such as the score and the ‘insert coin’ images, to free up some graphical tiles to reuse for the new elements. [Sebastian] first needed to understand the game code, which meant disassembly and hand annotation of the entire binary, which was done using the MAME debugger. As the linked article demonstrates, saying this is a big task is somewhat of an understatement.

A simple approach was taken to the mods consisting of three types of binary patches. The first, or ‘short circuit’, are simple NOPs inserted to disable subroutine calls or RTS to force an early return in a subroutine. The second type is a blob of code residing in some unused ROM space and storing state in a spare section of RAM. This is where the main parts of the new code reside. Finally, hooks are injected into the code at key locations, which jump into the binary blob where modified behaviour is required. This can do any needed initialisation before returning to the main game logic. Making significant changes to the game would be very hard without any spare space in the system, but we guess you could do it by stripping out other game elements, but [Sebastian] didn’t need to go there. If you’re into retro gaming and particularly modding, then going deeper into [Sebastian]’s homepage will reveal an astonishing number of projects and hacks.

Sometimes, our fond memories of games of old are skewed a little over the years, and the gameplay wasn’t that great in reality. So, what can we do? How about a little Redux, Zelda II style? If you’re really down the rabbit hole of retro hardware, then dealing with all those pesky EPROM chips is getting more difficult these days. To help with that, here’s a modern take on the necessary hardware.

It’s likely that many Hackaday readers will have had their interest in electronics as a child honed by exposure to an electronics kit. The type of toy that featured a console covered in electronic components with spring terminals, and on which a variety of projects could be built by wiring up circuits. [Matthew North Music] has a couple of these, and he’s made a video investigating whether they can be used to make music.

The kits he’s found are a Radio Shack one from we’re guessing the 1970s, and a “Cambridge University Recording Studio” kit that looks to be 1990s-vintage. The former is all discrete components and passive, while the latter sports that digital audio record/playback chip that was the thing to have in a novelty item three decades ago. With them both he can create a variety of oscillator and filter circuits, though for the video he settles for a fairly simple tone whose pitch is controlled by an light-dependent resistor, and a metronome as a drum beat.

The result is a little avant garde, but certainly shows promise. The beauty of these kits is they can now be had for a song, and as grown-ups we don’t have to follow the rules set out in the book, so we can see there’s a lot of fun to be had. We look forward to some brave soul using them in a life performance at a hacker camp.