Adding Portals To Quake

For those who have played Quake extensively, adding portals seems unnecessary, as teleporters are already a core part of the game mechanics. What [Matthew Earl] accomplishes is more of the Portal style of portal by rendering what is on the other side of the portal with a seamless teleportation transition.

Of course, Quake is an old game with a software renderer. Just throwing another camera into the scene, rendering to another texture, and then mapping that texture to the scene isn’t an option. Quake uses an edge rasterizer and generates spans along scanlines that track where edges intersect the current scanline. Rather than making expensive per-pixel comparisons, [Matt] stashes the portal spans and renders them in a second render, so even with multiple portals, only a single screen’s worth of pixels are rendered.

However, this technique has no near clipping plane, which means objects can appear in the portal that don’t make any sense as they are in front of the portal’s viewpoint. Luckily, Quake has an ingenious method for polygon occlusion: the BSP. While [Matt] is manually checking polygons, the BSP is the perfect tool for bisecting a room along a plane. It’s an incredible hack, and we’re excited to see Quake expand into a puzzle game. [Matt] dives into greater detail on how the software renderer works in another video that’s well worth a watch.

Perhaps the most incredible aspect of this technique is that it could run on original hardware. If you want to bring a little more Quake to life, why not get the Quake light flicker in your house? Video after the break.

Continue reading “Adding Portals To Quake” →

It’s A Humble ‘Scope, But It Changed Our World

A few years ago on a long flight across the North Atlantic, the perfect choice for a good read was iWoz, the autobiographical account of [Steve Wozniak]’s life. In it, he described his work replicating the wildly successful Pong video game and then that of designing the 8-bit Apple computers. A memorable passage involves his development of the Apple II’s color generation circuitry, which exploited some of the artifacts of the NTSC color system to produce a color display in a far simpler manner than might be expected. Now anyone seeking a connection with both Pong and the Apple II can have one of their very own if they have enough money because [Al Alcorn]’s Tektronix 465 oscilloscope is for sale. He’s the designer of the original Pong and used the instrument in its genesis, and then a few years later, he lent it to [Woz] for his work on the Apple II.

This may be the first time Hackaday has featured something from the catalogue of a rare book specialist, but if we’re being honest, for $135,000, it’s a little beyond the reach of a Hackaday scribe. The Tek 465 was a 100 MHz dual-trace model manufactured from 1972 to the early 1980s and, in its day, would have been a very desirable instrument indeed. This one is in pretty good condition with accompanying leads and manual and comes with a letter of authenticity and a hand-written annotation from [Al] himself on its underside. It can be seen up close in the video below the break.

As a ‘scope it’s an instrument many of us would still find useful today, but as the instrument which set in motion not one but two of the seminal moments of our craft, its historical importance can’t be overstated. We hope it will find its way into a museum or similar place where the story of those two developments can be told and that [Al] profits handsomely from its sale.

Continue reading “It’s A Humble ‘Scope, But It Changed Our World” →

The I960: When Intel Almost Went RISC

The i960 KA/KB/MC/XA with the main functional blocks labeled. Click this image (or any other) for a larger version. Die image courtesy of Antoine Bercovici. Floorplan from The 80960 microprocessor architecture.
The i960 KA/KB/MC/XA with the main functional blocks labeled. Click this image (or any other) for a larger version. Die image courtesy of Antoine Bercovici. Floorplan from The 80960 microprocessor architecture.

From the consumer space it often would appear as if Intel’s CPU making history is pretty much a straight line from the 4004 to the 8080, 8088 and straight into the era of Pentiums and Cores. Yet this could not be further from the truth, with Intel having churned through many alternate architectures. One of the more successful of these was the Intel i960, which is also the topic of a recent article by [Ken Shirriff].

Remarkably, the i960 as a solid RISC (Reduced Instruction Set Computer) architecture has its roots in Intel’s ill-fated extreme CISC architecture, the iAPX 432. As [Ken] describes in his comparison between the i960 and 432, both architectures are remarkably similar in terms of their instruction set, essentially taking what it could from the 432 project and putting it into a RISC-y shape. This meant that although the i960 could be mistaken as yet another RISC CPU, as was common in the 1980s, but integrated higher-level features as well, such as additional memory protection and inter-process communication. Continue reading “The I960: When Intel Almost Went RISC” →

Quantum Computing On A Commodore 64 In 200 Lines Of BASIC

The term ‘quantum computer’ gets usually tossed around in the context of hyper-advanced, state-of-the-art computing devices. But much as how a 19th century mechanical computer, a discrete computer created from individual transistors, and a human being are all computers, the important quantifier is how fast and accurate the system is at the task. This is demonstrated succinctly by [Davide ‘dakk’ Gessa] with 200 lines of BASIC code on a Commodore 64 (GitHub), implementing a range of quantum gates.

Much like a transistor in classical computing, the qubit forms the core of quantum computing, and we have known for a long time that a qubit can be simulated, even on something as mundane as an 8-bit MPU. Ergo [Davide]’s simulations of various quantum gates on a C64, ranging from Pauli-X, Pauli-Y, Pauli-Z, Hadamard, CNOT and SWAP, all using a two-qubit system running on a system that first saw the light of day in the early 1980s.

Naturally, the practical use of simulating a two-qubit system on a general-purpose MPU running at a blistering ~1 MHz is quite limited, but as a teaching tool it’s incredibly accessible and a fun way to introduce people to the world of quantum computing.

There’s Always Room For Another Cycle Accurate PC Emulator

While many Hackaday readers will have their own pieces of classic hardware lovingly preserved, it still remains that most of us get our fix of retro goodness through emulation. And while there are emulators aplenty for almost every platform imaginable, the world of emulation is never complete. Thus we’re happy to encounter a new player in the form of MartyPC, a cycle-accurate 8088 PC emulator written in Rust.

It’s a project that started only in April 2022, but alongside such in-depth processor support it has the full range of PC and XT peripherals including CGA and VGA cards to the extent that it will run even the most hardware-demanding demos. Below the break you can see it running the fiendishly hardware-specific PC demo Area 5150 — thought to be the first time an emulator has managed this task.

If there’s a snag it’s that the releases are so far Windows-only, though it’s claimed that it should also compile on other major platforms. There’s also a WebAssembly version, though sadly the link to it doesn’t work. We look forward to this emulator maturing, because we’re sure it will become a PC standby. After all, not everyone managed to snag one of the recent batch of new hardware.

Continue reading “There’s Always Room For Another Cycle Accurate PC Emulator” →

A Commodore 128 with a video capture device attached

Hacking The Commodore 128 To Capture Almost Real-Time Video

Although watching and editing videos may be among the primary tasks of many PCs today, it wasn’t that long ago that working with video required powerful processors and expensive video capture hardware. Even in the 1980s, home computer users were looking for ways to connect video sources to their Commodores and Ataris despite their hardware limitations. [Cameron Kaiser] has a mid-1980s consumer-grade video capture device, which he has managed to turn into an almost real-time video capture system.

A distorted video image on a C128's monitor
Allowing the graphics chip to interrupt the CPU mid-capture results in a severely distorted image

His work revolves around a device called “ComputerEyes”, a 1984-vintage hardware interface that made it possible to connect a composite video source to a home computer. The limitations of mid-1980s CPUs meant that it took around six seconds for the computer to do a quick scan of a single video frame, or a multiple of that if you wanted a higher-quality image. Another limitation, at least on Commodore machines, was that the screen had to be turned off during video capture – otherwise, the video chip would interrupt the CPU halfway through the process, causing it to lose its synchronization with the video source.

[Cameron] however, plugged his ComputerEyes into a Commodore 128. This machine, largely designed by Hackaday contributor [Bil Herd], has an unusual hardware architecture consisting of two different CPUs and, crucially, two separate video chips. The primary 8564 “VIC-II” graphics chip is used to keep compatibility with existing Commodore 64 programs, while the secondary 8563 “VDC” is mainly aimed at newer high-resolution text-based software. The VDC is also much more independent from the main system bus than the VIC-II, allowing it to display an image without disturbing the CPU.

More after the break.

Continue reading “Hacking The Commodore 128 To Capture Almost Real-Time Video” →

Fujitsu Proprietary Keyboard Goes PS/2 With A Pico

One of our favorite retro-computing YouTubers, [Clint] from LGR, found himself a very interesting Fujitsu keyboard while thrift store shopping. It was a beautiful unit, but confusing, as this keyboard comes with an 8-pin DIN connector. A 5-pin DIN plug or 6-pin Mini-DIN would be easy to work with, but what was this odd connection? Turns out the Fujitsu N860-2500-T111 came with an Olympus CV-100 Video Processor, which was designed for medical imaging, potentially among other uses. And as often happened with old specialized hardware, the keyboard used a proprietary protocol for sending keystrokes.

[Clint] put out a call for anyone that could help him build an adapter, and [Andy] from Element14 answered the call. But this problem requires more than an adapter, mainly because the Fujitsu doesn’t have key rollover. It’s one key at a time, and that just doesn’t work for the sort of things [Clint] shows off on LGR. So, the electronic guts of the keyboard were removed, to be replaced with a Raspberry Pi Pico, wired directly to the keyboard matrix.

Continue reading “Fujitsu Proprietary Keyboard Goes PS/2 With A Pico” →