Quake In 276 KB Of RAM

October 5, 2024 by Bryan Cockfield 20 Comments

Porting the original DOOM to various pieces of esoteric hardware is a rite of passage in some software circles. But in the modern world, we can get better performance than the 386 processor required to run the 1993 shooter for the cost of a dinner at a nice restaurant — with plenty of other embedded systems blowing these original minimum system requirements out of the water.

For a much tougher challenge, a group from Silicon Labs decided to port DOOM‘s successor, Quake, to the Arduino Nano Matter Board platform instead even though this platform has some pretty significant limitations for a game as advanced as Quake.

To begin work on the memory problem, the group began with a port of Quake originally designed for Windows, allowing them to use a modern Windows machine to whittle down the memory usage before moving over to hardware. They do have a flash memory module available as well, but there’s a speed penalty with this type of memory. To improve speed they did what any true gamer would do with their system: overclock the processor. This got them to around 10 frames per second, which is playable, but not particularly enjoyable. The further optimizations to improve the FPS required a much deeper dive which included generating lookup tables instead of relying on computation, optimizing some of the original C programming, coding some functions in assembly, and only refreshing certain sections of the screen when needed.

On a technical level, Quake was a dramatic improvement over DOOM, allowing for things like real-time 3D rendering, polygonal models instead of sprites, and much more intricate level design. As a result, ports of this game tend to rely on much more powerful processors than DOOM ports and this team shows real mastery of their hardware to pull off a build with a system with these limitations. Other Quake ports we’ve seen like this one running on an iPod Classic require a similar level of knowledge of the code and the ability to use assembly language to make optimizations.

Thanks to [Nicola] for the tip!

Giving The Original Xbox 256 MB Of Memory

July 10, 2024 by Lewin Day 20 Comments

The original Xbox forever changed the console world, because it was basically just PC components laced together in a slightly different architecture. It featured a Pentium 733 MHz CPU with just 64MB of RAM. [Prehistoricman] has been hard at work, figuring out how to up that to 256MB instead.

This isn’t [Prehistoricman’s] first rodeo. Previously, he managed to up the Xbox’s RAM to 128 MB. To figure out how to go further, he had to figure out the addressing scheme. A datasheet for the Xbox’s original memory chip was a help in this regard, as was the envytools project and an Xbox source code leak.

A BIOS hack was needed to move the auto-precharge pin to free up more address pins for the higher memory space. Furthermore, the only available memory chips that were suitable used BGA packages, so a small PCB with castellated edges was needed to adapt the chip to the Xbox’s motherboard, which expects a TQFP package.

Ultimately, getting this hack to work involved a lot of bare-metal hacking. It also won’t help the performance of commercial games at all, as they were all designed within the limitations of the original console. Still, it’s impressive to see this now-ancient platform hacked to do more. It’s also hilarious to compare it with a contemporary PC, which could simply accept 256 MB of RAM by using additional memory slots. Video after the break.

Continue reading “Giving The Original Xbox 256 MB Of Memory” →

Build Your Own Core Rope Memory Module?

June 24, 2024 by Dave Rowntree 15 Comments

[Luizão] wanted to create some hardware to honour the memory of the technology used to put man on the moon and chose the literal core of the project, that of the hardware used to store the software that provided the guidance. We’re talking about the magnetic core rope memory used in the Colossus and Luminary guidance computers. [Luizão] didn’t go totally all out and make a direct copy but instead produced a scaled-down but supersized demo board with just eight cores, each with twelve addressable lines, producing a memory with 96 bits.

The components chosen are all big honking through-hole parts, reminiscent of those available at the time, nicely laid out in an educational context. You could easily show someone how to re-code the memory with only a screwdriver to hand; no microscope is required for this memory. The board was designed in EasyEDA, and is about as simple as possible. Being an AC system, this operates in a continuous wave fashion rather than a pulsed operation mode, as a practical memory would. A clock input drives a large buffer transistor, which pushes current through one of the address wires via a 12-way rotary switch. The cores then act as transformers. If the address wire passes through the core, the signal is passed to the secondary coil, which feeds a simple rectifying amplifier and lights the corresponding LED. Eight such circuits operate in parallel, one per bit. Extending this would be easy.

Continue reading “Build Your Own Core Rope Memory Module?” →

Homebrew Computer From The Ground Up

May 26, 2024 by Bryan Cockfield 12 Comments

Building a retro computer of some sort is a rite of passage for many of us, with some building replicas or restorations of old Commodores, Ataris, and other machines from decades past. Others go even further back, to the time of the Intel 8008 or earlier, and a dedicated few will build something completely novel. This project from [3DSage] falls squarely in the latter category, with his completely DIY computer built component by component from scratch, including the machine code needed to run it.

[3DSage] starts with the backbone of every computer: the clock. He first demonstrates how a pair of NOT gates with a set of capacitors can be used as a rudimentary clock pulse, then builds a more refined version with a 555 timer and potentiometer for adjustable rates. Then, it’s on to creating a binary counter, which is a fundamental part of the memory system for this small computer, and finally, allows this circuitry to behave like a normal computer. Using a set of switches to store values in memory and stepping through them with the clock, the computer can be programmed to do plenty of tasks just like a modern microcontroller.

[3DSage] built this project a few years ago and has used it for real-world applications such as controlling servos, LED arrays, playing music, and other tasks. Although he has to program it using his own machine code by hand, it’s a usable computer in many ways. If you want to eschew modernity and build a retro computer in the style of the 1960s, though, this piece goes through what it would have been like to build a similar system in the era when these computers were more common. If you have a switch fetish, you might like to see how real computers worked back then, too.

Continue reading “Homebrew Computer From The Ground Up” →

Institutional Memory, On Paper

May 11, 2024 by Elliot Williams 18 Comments

Our own Dan Maloney has been on a Voyager kick for the past couple of years. Voyager, the space probe. As a long-term project, he has been trying to figure out the computer systems on board. He got far enough to write up a great overview piece, and it’s a pretty good summary of what we know these days. But along the way, he stumbled on a couple old documents that would answer a lot of questions.

Dan asked JPL if they had them, and the answer was “no”. Oddly enough, the very people who are involved in the epic save a couple weeks ago would also like a copy. So when Dan tracked the document down to a paper-only collection at Wichita State University, he thought he had won, but the whole box is stashed away as the library undergoes construction.

That box, and a couple of its neighbors, appear to have a treasure trove of documentation about the Voyagers, and it may even be one-of-a-kind. So in the comments, a number of people have volunteered to help the effort, but I think we’re all just going to have to wait until the library is open for business again. In this age of everything-online, everything-scanned-in, it’s amazing to believe that documents about the world’s furthest-flown space probe wouldn’t be available, but so it is!

It makes you wonder how many other similar documents – products of serious work by the people responsible for designing the systems and machines that shaped our world – are out there in the dark somewhere. History can’t capture everything, and it’s down to our collective good judgement in the end. So if you find yourself in a position to shed light on, or scan, such old papers, please do! And then contact some nerd institution like the Internet Archive or the Computer History Museum.

New JEDEC DDR5 Memory Specification: Up To 8800 MT/s, Anti-Rowhammer Features

April 23, 2024 by Maya Posch 5 Comments

"User:Dsimic">Dsimic</a> — “Row hammer” by Dsimic – Own work. Licensed under CC BY-SA 4.0 via Wikimedia Commons.

As DDR SDRAM increases in density and speed, so too do new challenges and opportunities appear. In the recent DDR5 update by JEDEC – as reported by Anandtech – we see not only a big speed increase from the previous maximum of 6800 Mbps to 8800 Mbps, but also the deprecation of Partial Array Self Refresh (PASR) due to security concerns, and the introduction of Per-Row Activation Counting (PRAC), which should help with row hammer-related (security) implications.

Increasing transfer speeds is primarily a matter of timings within the limits set by the overall design of DDR5, while the changes to features like PASR and PRAC are more fundamental. PASR is mostly a power-saving feature, but can apparently be abused for nefarious means, which is why it’s now gone. As for PRAC, this directly addresses the issue of row hammer attacks. Back in the 2014-era of DDR3, row hammer was mostly regarded as a way to corrupt data in RAM, but later it was found to be also a way to compromise security and effect exploits like privilege escalation.

The way PRAC seeks to prevent this is by keeping track of how often a row is being accessed, with a certain limit after which neighboring memory cells get a chance to recover from the bleed-over that is at the core of row hammer attacks. All of which means that theoretically new DDR5 RAM and memory controllers should be even faster and more secure, which is good news all around.

Flipped Bit Could Mark The End Of Voyager 1‘s Interstellar Mission

February 9, 2024 by Dan Maloney 95 Comments

Sometimes it’s hard to read the tea leaves of what’s going on with high-profile space missions. Weighted down as they are with the need to be careful with taxpayer money and having so much national prestige on the line, space agencies are usually pretty cagey about what’s going on up there. But when project managers talk about needing a “miracle” to continue a project, you know things have gotten serious.

And so things now sit with Voyager 1, humanity’s most distant scientific outpost, currently careening away from Mother Earth at 17 kilometers every second and unable to transmit useful scientific or engineering data back to us across nearly a light-day of space. The problem with the 46-year-old spacecraft cropped up back in November, when Voyager started sending gibberish back to Earth. NASA publicly discussed the problem in December, initially blaming it on the telemetry modulation unit (TMU) that packages data from the remaining operable scientific instruments along with engineering data for transmission back to Earth. It appeared at the time that the TMU was not properly communicating with the flight data system (FDS), the main flight computer aboard the spacecraft.

Since then, flight controllers have determined that the problem lies within the one remaining FDS on board (the backup FDS failed back in 1981), most likely thanks to a single bit of corrupted memory. The Deep Space Network is still receiving carrier signals from Voyager, meaning its 3.7-meter high-gain antenna is still pointing back at Earth, so that’s encouraging. But with the corrupt memory, they’ve got no engineering data from the spacecraft to confirm their hypothesis.

The team has tried rebooting the FDS, to no avail. They’re currently evaluating a plan to send commands to put the spacecraft into a flight mode last used during its planetary fly-bys, in the hope that will yield some clues about where the memory is corrupted, if indeed it is. But without a simulator to test the changes, and with most of the engineers who originally built the spacecraft long gone now, the team is treading very carefully.

Voyager 1 is long past warranty, of course, and with an unparalleled record of discovery, it doesn’t owe us anything at this point. But we’re not quite ready to see it slip into its long interstellar sleep, and we wish the team good luck while it works through the issue.