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.

As was common at the time, a line like “10 PRINT 1+1” would get tokenized. In this case, each line would get a pointer to the next line, a two-byte line number, a single-byte token for “PRINT” and then more bytes to represent the rest of the line. In the case of text in a string or a remark, the bytes were just the text with a zero to terminate the string.

The first line entered would always be at address 469. So? If you consider the format of the REM statement, there will be a pointer at 469 and 470, the line number at 471 and 472, and the REM token at 473. That means the other bytes just get poured into address 474 and beyond.

That might seem like an odd number until you look at the pokes in line 40. Keep in mind that POKE works on bytes, not words. So poking 1 into 261 gives you an address of 256 + whatever is in the low byte, in this case 218. Add 256 and 218, and you get… 474! So USR is going to call that odd string in line 10!

There is more to the detective story, but if you want to know exactly what the REM did, you can read the original post.

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.

After recovering an installer for the Dallas Semiconductor’s IB-DE IDE from the Wayback Machine, this posed the next problem. As it was a 32-bit Java binary, which didn’t play nice with the modern Java 25 runtime and belying the ‘write once, run anywhere’ marketing phrase of back then. Downgrading to 32-bit Java 1.8 with since removed communication APIs helped here.

With the IDE in place, the traffic between the Java Ring and the PC-based software could be analyzed to figure out what was going on. This revealed CRC errors that pointed to the built-in lithium backup battery having expired. Unfortunately the stainless steel case is meant to be sealed and thus turn into e-waste the moment said battery calls it quits. Here fortunately a Japanese TV program picked up on these efforts and featured his efforts on national TV.

This led to the happy ending, with some help with others in replacing this battery. This also answered the question of which parts of the firmware and data were in the battery-backed RAM and which in ROM. Although full details of the findings here are a bit scarce, it seems that the original data was lost along with the dead back-up battery, but the ROM retained the JVM and allowed for a new program to be eventually written to the device and retained across reader sessions.

Although these days the various NFC standards have made bulky devices like iButtons rather obsolete, they’re still a fun look at an era when it was thought that lugging a tiny computer as a (key) ring around for authentication was the future. Of course these days we mostly lug an entire 6″ smartphone for that purpose, so maybe the joke is on us after all.

Thanks to [Wood] for the tip.

Perhaps the saddest thing about the Zilog Z80 is that this humble 8-bit microprocessor wasn’t allowed to live until its 50th birthday. This, fortunately, doesn’t prevent people like [David Oberhollenzer] from reminiscing on this influential processor and what it means to them personally.

First released in July of 1976, this humble 8-bit miracle would go on to power not just a range of home computers, but also be found in everything from industrial controllers to arcade systems. Despite this success, the new owner of Zilog — Littelfuse — decided to put an end to this winning streak in 2024 for the stand-alone processor and its peripherals.

Although the original Z80 ecosystem ceased production, this didn’t prevent hobbyists from creating new operating systems for it, let alone entire new development toolchains, or demonstrate multitasking on the Z80.

Meanwhile, the Z80 architecture is still very much alive and kicking, such as in the form of the eZ80 SoC in the TI 84+ CE calculator that [grubbycoder] ported Sonic 2 from the Z80-based Sega Master System.

Among all of this modern-day Z80 goodness, we also have a few gems from the past to admire, such as the OS that Zilog made for this architecture in the form of Z80-RIO, which was sadly not as successful as the hardware.

In the old days, you either swore by BASIC or you swore at it — but just about everybody got their start on the educational language. Nowadays, the kids are learning Python, but there’s a case to be made for BASIC — either for education, or just for nostalgic fun. BASIC-256 fills that niche, and now that it’s being ported to the oh-so-portable QT6 by [UglyMike], there’s even a webAssembly version that will let you run BASIC in your browser.

This version of BASIC is based on KidBASIC, which was aimed at the educational market. It’s got some handy-dandy graphics routines, 64-bit variables, and other quality-of-life features you can find in the docs. The new port is multi-platform, though the MacOS version has only been compiled for Apple Silicon — less of an issue than it used to be — and the web version naturally can’t get access to hardware for, e.g., serial ports, so it is somewhat more limited than a full install. There’s a second ARM build for Raspberry Pi along with the ubiquitous x86, but the project is open source, so if you really want to run this on an UltraSPARC system, you are welcome to compile it there. That said, this is a beta version, and the dev is actively looking for problems — so give it a go and let them know.

This isn’t the only open source BASIC out there — even Microsoft released their source code, at least for the 6502.

Thanks to [UglyMike] for the tip!

Modern video games are nothing short of amazing. My son and I were playing through the one of the latest Zeldas, which involve a mix of combat and puzzle-solving that’s pretty much the hallmark of the franchise. But the most recent open-world Zelda is simply massive. Made by around 1,000 people at a development expense of $150,000,000, it takes probably 60-80 hours to play through if you’re not rushing, and more if you’re taking it easy. It has layers of game mechanics, and worlds in the sky, on land, and underground. It’s big in every way.

Contrast the games of my youth, which were a lot smaller. Written by a pair of people or maybe a handful, with playtimes in the single-digit hours, and of course fitting in the limited computing resources of the time. But the low-stakes nature of the early phases of the industry meant that software developers could take risks, and many of the games were consequently kinda idiosyncratic in this more innocent time.

I think there’s something to be said for small games. They don’t require a lifestyle commitment just to get through. They can still be fun, without taking all of your time. And honestly, when you’re done with a game quickly, you have more time for other stuff. Granted, some of this spirit lives on in the small indie games of today, but even so, game developers have the big studios’ products in the backs of their minds when they are working on their smaller oeuvres.

We were talking about preserving old games for posterity around Hackaday and on the podcast, and our conversations reminded me of a couple of educational games that, despite their rudimentary graphics, are still pretty good today. Both were electronics related, and both are still playable today thanks to efforts on emulation and software preservation. To get a feel for the 1980’s, give Rocky’s Boots a try. (I like the TRS-80 Color Computer version the best, but that may just be nostalgia.) Most of you grownups out there will get through it in an hour or so.

And if you want a challenge, try Rocky’s harder sequel: Robot Odyssey. If you already have a background in digital circuits, you’ll find it doable. Younger me hit a wall about two-thirds of the way through.

Both of these games stick with me because they taught me something, but also because they were simply quirky in a way that a game can only be when it’s written by a small team of folks who are just having fun programming it. If you pitched “a puzzle game about a raccoon who builds logic circuits to activate robot boots”, the boardroom would look at you like you’re out of your mind. But it’s just exactly the quirkiness and individuality of some of these early games that I cherish the most.

If you find yourself knee-deep in an endless modern game, take a side-quest off into a more naive time, and you’ll appreciate why people are putting efforts into archiving them.

There’s an interesting thing about retrocomputing — the moment that you realize your 25-year-old machine can do almost everything your average person uses a computer for. The problem is that the average person mostly uses a computer as an internet appliance, and the big missing piece for most old machines is hooking up to the modern internet. HTTPS is good to have, but isn’t so easy to implement when your browser gets megabytes of RAM instead of gigabytes.

That’s why MacSurf by [mplsllc] is so interesting, especially version 2.0 just released-– its explicit goal is to get as much of the modern web onto an OS 9 equipped PowerPC Macintosh as physically possible.

Before you get too excited– no, you won’t be hitting up YouTube.com or even GitHub. That’s just too big and bloated now, even if you can get past the HTTPS hurdle. You will, however, be able to access, say MacintoshGarden.org, whose out-of-order HTTPS certificates sent the last version for a tizzy. The forums at 68kMLA work, and threads load quickly thanks to the as-needed image loading added this version.

Other nice things added include a proper history and bookmark manager.  There’s still no tab support, but have you seen the modern web? You’re not fitting more than one webpage into RAM on a G3 no matter how hard you try. You can, however, download the web browser directly from the http-only MacSurf.org homepage.

We featured the first release of this netsurf-based browser, and have to admit we’re impressed with the speed of development. If you want a totally modern system on PPC instead of just an up-to-date browser, you might want to check out MorphOS.

CD+Graphics was a format that never really caught on. It let music discs pack some graphics, maybe liner notes, and mostly song lyrics into the otherwise empty space on a CD. It was never intended for displaying full-motion video, but that didn’t stop [Adam Gashlin] from getting a Bad Apple, with lyrics, running on any device that will play CD+G.

The main challenge is that CD+G gives you 300 screen commands per second, which is plenty for updating text on the 48×16 blocks as the lyrics scroll by. But if you want to send custom blocks and draw images, that’s 2.5 seconds per screen: a lousy framerate.

[Adam]’s first trick is to drop the resolution way down, which gets him into the 8 FPS range. Only update the blocks that change pushes this up to a respectable 17-20 FPS. But you can see the updates, and that’s distracting. It really needed buffering.

If you don’t know Bad Apple, it’s in black and white. And like many old graphics engines of the day, CD+G uses a dynamic palette of colors. [Adam] uses this to pack four frames into one, switching between them using palette swapping. (Absolutely check out his “rainbow” version of the video to see how the palette-swapping trick works.)

In the end, his demo has audio, triple-buffered video, and lyrics at 16.3 FPS. It’s slower than the fastest video-only version, but it looks so good, and [Adam]’s explanation of all of the graphics tricks he uses to get there is the real star of the show.

If you want to see Bad Apple running on yet more minimal hardware, how about a 16×2 LCD? Or a much more ridiculous implementation? How’s regexes in Vim for absurd? Got any Bad Apple hacks of your own? Let us know in the comments or the tips line. You can never have too many.

Just when you thought we’d run out of things to port DOOM to, here comes [Ahmed Amer] with his CSS-DOS, a massive 300 MB CSS style sheet, that runs not just DOS, but Windows 1.0 and, of course, DOOM. The CSS sheet isn’t holding a DOOM port this time, though — it’s holding a full IBM PC compatible, with a simulated 8086, 640 kB of RAM, floppy and VGA controllers. Yes, in one style sheet. We did mention it was 300 MB, right?

CSS is not a very good programming language. It’s got functions and if statements nowadays, but it doesn’t really do programs in the usual sense. That is, lists of instructions that feed one into another. You can’t change a variable without jumping through hoops. The sort of static behavior you get from a CSS sheet actually matches hardware architecture better than software, which was the key insight [Ahmed] had to make the project possible. It’s still not easy, or elegant, or perhaps even sane, as you can find out from the excellent write-up he has describing how he pulled this off. We particularly like the interactive guide to the full mountain of madness that is the .css file.

Now, we admit that “runs DOOM” may be an exaggeration — even if the maddeningly massive CSS sheet ran an IBM-AT full speed, that hardware can’t handle the game at any playable speed. It doesn’t emulate at anything close to full speed, though. Because this is such a gratuitously weird hack, it only runs at two instructions per second. No, not FPS, instructions, as in at the CPU level. Well, it could be worse, at least it’s not clock ticks. Still, if you’re time-dilated enough you can wait the 3 weeks to boot DOS, and the 3 months to load a level, you can play DOOM at 0.0001 FPS.

Look, we didn’t make the rules — they say everything has to try and run DOOM. They don’t say everything has to run it well.

Many older hackers will have at some point gotten rid of an old piece of hardware that they later ended up regretting. All those ISA cards were next to useless back in 2006, but now their relative rarity plus the popularity of retrocomputing makes them sought-after. But if it’s a sound card you’re after then never fear! [Schlae] has got you covered, with the Beavis Ultrasound. It may have a name reminiscent of a ’90s cartoon series, but it’s a clone of the Gravis Ultrasound from back in the day.

There is of course a snag, to build one you need an AMD AM78C201. Assuming you’ve found one in a surplus supplier though, the rest of the card is analogue, some glue logic, and a ROM for samples. There is also a GAL for driving the IDE CD-ROM interface, from the days when sound cards came with such things.

New ISA cards are cropping up here from time to time, such as this very handy storage and network card.

There was a time in the early 1980s when it was common to see home made keyboards for 8-bit machines that came with membrane or rubber keyboards. Though we’ve seen any numbers of home made modern ‘boards, it’s been decades since we saw one for an 8-bit micro. Until today, that is, when we saw [Vlad]’s Sinclair Spectrum. It’s a Spectrum with all that Sinclair glue logic that was in the ULA replaced in software by an RP2050, and that keyboard with the Spectrum decals.

The machine is a charming mixture of new and old, with a traditional cassette port alongside VGA, gameport joystick, and Sinclair joystick. The aim is to also have HDMI, though it’s not yet implemented. Sadly there is no Spectrum edge connector for period peripherals though. He admits it’s not cycle accurate to the original, but given that it runs all the games he’s given it this seems not to matter. Meanwhile that keyboard which caught our eye is a true period piece, sitting as it does on a piece of phenolic stripboard, and those decals are the perfect finishing touch.

The Spectrum receives quite a bit of love today, and if this one takes too many modern liberties for your liking, you can still make one using proper logic.

[lcamtuf] is not just a calculator superfan, but also a skilled builder. That much is evident in the fabulous  design of Calcumator 2000, an electromechanical calculator that uses voltmeter readouts as digits (plus one at the bottom to represent decimal place). There are plenty of high-quality build images, so give it a look!

Calcumator 2000 is a bit of a love letter to a time when display technology hadn’t quite yet produced anything suitable for calculator use. This resulted in calculator designs that are generally unrecognizable compared to the 7-segment display based devices we see today. The Calcumator 2000, in all its electromechanical glory, would have fit right in that era.

The Calcumator 2000 has all the usual buttons one would expect from a simple calculator and drives a total of seven readouts, one of which acts as the decimal point. The idea of using voltmeters as digit displays came from [lcamtuf]’s voltmeter clock, an earlier work with a similar attention to detail in its design and assembly.

We want to take a moment to admire how clean the blue panel is. [lcamtuf] made it by painting one side of an acrylic panel, cutting the letters and design out on a CNC mill, then filling with white paint. The depth of the cuts gives the white elements a nifty multi-layer effect that really complements the design.

Want to see it work? Oh yes, you do. Check out the video, embedded just below.

MicroPython, for the uninitiated, is a pared-down version of python meant to run on today’s powerful microcontollers. As impressive as it was for its day, the SNES is not quite in their league in terms of computing power. Time marches on, and so while there may be other indie releases worth mentioning, we’re declaring the hottest SNES game this season to be [Fabian Kübler]’s port of MicroPython.

Well, except he didn’t exactly do the porting himself: the Antrhopic LLM Claude generated the code, and performed most of the testing, as [Fabian]’s test of its new Fable 5 model. A brief pause during an export ban showed that Opus would crash and burn on the same task, but Fable was able to get things quickly back on track. It might be “AI slop” by some definitions, but the port scales 430 out of 468 on MicroPython’s core test/basics, which makes it usable to play some simple python games… slowly.

As you can see for yourself in an embedded emulator if you check out [Fabian]’s blog, spooling up MicroPython takes about twenty seconds at 3.58 MHz, and after that you can watch some sprites bouncing around at a blistering 0.8 FPS. [Fabian] seems satisfied with that performance, and impressed with Fable’s efforts at optimization. What to you think? Does the hardware have much more to give, or is that about it, given the nature of the Pythonic beast? Perhaps some plucky human could become a digital John Henry by producing a better, faster port — if you do, please let us know. If you’d rather just to see what Fable can do, the project is available on GitHub, so you can judge for yourself how sloppy the code is or test out the ROM.

Putting Python onto limited hardware may not to be to everyone’s taste, but there’s a good case to be made for it. The SNES may actually be too limited, though. It makes sense — the kind of micros you run MicroPython on can emulate the SNES.

If you think RAM is expensive now, try putting yourselves in the shoes of a Commodore engineer, circa 1981. RAM was eye-wateringly expensive by modern standards, and Jack Tramiel wanted 64K of the stuff for the next computer– hence the name, Commodore 64– but he didn’t want to pay for it. The solution was to use cheaper dynamic RAM over the more expensive static RAM that later took over the market in the kilobyte range. That’s a small problem for retrocomputer hobbiests, because while we’re complaining about the price of gigabytes of the stuff, you can’t buy new DRAM chips that fit a Commodore at any price. That’s why [Fabio Battaglia] aka [hkzlab] came up with an adapter board to fit easily-available SRAM chips onto aging C64s. 

Nothing lasts forever– not cold September rain, and not DRAM chips. Heat damage? Internal corrosion? There are probably multiple failure modes, but someday the old stock of chips will run out and the retrocomputer community is going to be ready for it. [Keith Olson] sent us a tip on a video by [The Retro Shack]– embedded below, and thanks for the tip, [Keith]!–about this very problem, that serves as a good demo of what you get when you put SRAM into a C64. That said, the adapter board on offer is only good for C64s with the 250407 motherboard. If yours is different, you may have to modify the board– but hey, it’s open source, so go ye and do that thing. Let us know via the tips line if you do.

Back in the 1990s IBM had a pretty sizeable presence in the PC market, including its rather spiffy Aptiva series of PCs. Naturally their PCs had to feature heavily in another consumer-related thing that was popular in the 1990s, being smart home automation in the form of IBM Home Director. Recently [Ionic1k] took a look at this blast from the past, starting with one of the original IBM commercials.

At its core it used the same X10 protocol that similar solutions from RadioShack and others used, with many modules and packages you could get to use with it. You could also get a more bespoke installation performed at your home to move beyond mere X10, which some people are still finding when they’re buying a house.

Since this uses powerline communication, it required no wires to be run, just the requisite modules to be plugged into a power outlet, with the video demonstrating the basic setup and installation. The PC itself is plugged into the control module via the serial port, from which the Home Director control software can be used to create a configuration and control the state of connected modules.

Although X10 has the same issues as any kind of powerline communication, overall it seems like a very nice system, with a wide range of modules and absolutely easy to set up even for a casual Windows user.

Among the many forgotten might-have-beens of the games console world, the Atari Jaguar occupies a special place. It was the final gasp of Atari Corporation, the Jack Tramiel-era incarnation of the famous pioneering game console brand that brought us the ST line of computers, and like Marlon Brando’s Terry Malloy character from On the Waterfront, it coulda been a contender. But the early ’90s games business wasn’t kind to the console from Sunnyvale, and it was squeezed from behind by the SNES and Genesis/MegaDrive, and in front from the PlayStation. Thirty years later then, can it run Linux? [Cakehonolulu] is here to show us how.

With only 2 megabytes of RAM and space for 8 megabytes of ROM, this is hardly a powerhouse. But its 16-bit 68000 processor is a supported Linux architecture, albeit with the -nommu flag on compilation. The “Jerry” DSP chip has the required serial port and timer to boot a first Linux kernel, and after a bit of hackery to make it jump to the ROM location, something boots. There’s no init process until the flat executable file for a -nommu kernel is navigated, but with that past a BusyBox userspace and a graphics driver for the “Tom” graphics chip gives it a chunky on-screen console. The code can be found in a GitHub repository, for the curious.

It seems to be the moment for 68k consoles to receive the Linux treatment, as it’s only a few weeks since we saw it on a MegaDrive. Other ’90s consoles aren’t far behind though, with the Nintendo 64 falling to the penguin a few years ago. Meanwhile, the Dreamcast had Linux running decades ago.

Jaguar image: Evan-Amos, Public domain.

In the early 1990s, Don’t Copy That Floppy was an anti-piracy campaign that attempted to connect with computer-savvy youth through the power of hip-hop. While somewhat difficult to imagine given our current draconian Digital Rights Management (DRM) hellscape, warning kids about the potential legal ramifications of duplicating floppy disks containing copyrighted software was seen as necessary since at the time there was usually nothing preventing users from simply copying the contents of one disk to another.

Unfortunately 30+ years down the road, we’re now finding that somebody really should have been backing up some of those disks. Which is why the University of Cambridge of launched the Future Nostalgia project and produced Copy That Floppy! — a phenomenal guide on preserving the contents of floppy disks while we still can.

There’s no telling how much data could potentially be lost to time because its stuck on such an antiquated and fragile storage media, and the situation only gets worse with the passage of time. The problem isn’t just that modern computers don’t have floppy drives. The disks themselves degrade with age, a process which is accelerated if they aren’t stored properly.

As such, Copy That Floppy! only briefly touches on the most ideal situation — that is, buying a USB floppy drive and making copies of the bog standard 3.5 inch disks you might come across. It then moves right on into more advanced topics, such as interfacing with less common drive types, how to safely clean floppies, and the use of advanced tools such as Greaseweazle to analyze captured disk images.

We’ve seen demonstrations of some of these techniques before, and a few years back Adafruit got interested in floppy preservation with modern hardware. But in-depth guides like these that pull all that information together into one place are valuable resources.

On the one hand, the original Apple II has been copied over and over again since at least the early 80s, so maybe this hack is old hat to the greybeards around here. On the other hand, this is the year 2026. When Apple released it back in 1977, who could have predicted people would still be building these things nearly five decades later?

In that sense, a homebrew Apple II in the current year is pretty remarkable. It’s a really well done project by [simonboak], nicely open sourced with a case to match, so is worth looking at on its own merits.

Unlike the later models, the original Apple II only used commercially available ICs, making it an easy target for recreation. No FPGAs required, just good old-fashioned DIPs. OK, these are modern CMOS versions of the chips, but other than that, the biggest concession to modernity is space on the board for a Raspberry Pi Pico to allow for connecting a USB keyboard.

The accompanying blog post lists some other differences from 1977’s favorite home computer: SRAM vs DRAM — because you know the Woz would have used it if he could — and omitting the composite video circuitry in favor a late-model VGA card. There’s no need for the composite output since he’s eschewing the period-appropriate CRT for a retro-styled LCD monitor, which is also 3D printed and available on Printables. It’s crazy to think that the Apple II family lived long enough not only to see the dawn of VGA but also well into its sunset.

If a homebuilt Apple ][ doesn’t impress, what about a PC-compatible circa 1995?

The NTSC television standard is a masterpiece of mid-century engineering, to pack a color image into the transmission bandwidth of a monochrome one, and to do so while maintaining backward compatibility with earlier monochrome TV sets. In terms of its timings and choice of sync and carrier frequencies it’s elegantly thought out for maximum quality on a 1950s round-CRT color TV set.

The trouble is, that while the standards are exacting, the receivers are quite forgiving, and will display adequately even with substantially off-spec video. [Nicole Express] is here with an in-depth examination of a time when that was pushed just a little bit too far, explaining why the Nintendo Entertainment System (NES) displayed wobbly color images.

We’re treated to a run-through of the NTSC standard itself, and a look at how some of the other consoles and home computers of that era either had similar problems, or managed to avoid them. The key lies in the exacting timing required to achieve perfect interlacing, and the NES’s use of a single crystal to provide all the clocks. The dot clock on adjacent frames was almost right, but not quite, leading to a side-to-side wobble that while barely perceptible, was exacerbated by some graphics. It’s a fascinating read.

We’ve looked at composite video in detail in the past.

NES image: JCD1981NL, CC BY 3.0.

The Intel 80386 is a rather fascinating slice of computer history. It marked the first 32 bit X86 processor, and was a staple of early desktop computing. Like all chips, it has a number of quirks, one of which being the fact that all commands are executed in microcode. By this nature, it was a rather excellent prospect to be re-implemented in an FPGA core called the z386. However, it was lacking a feature native to the original 386, early start memory access. So to bring some performance to the z386 project, [nand2mario] went forth to fully implement this feature for FPGA 80386s.  

Instead of taking a cycle to find and allocate the memory required for executing the next instruction, the 386 would start this in the previous cycle. This is achieved in hardware by nature of having a separate memory management unit. In the FPGA, the key difficulty proved to be in getting the computation fast enough to execute within a single cycle. This change netted an approximate 9% performance benefit. However, for [nand2mario] this was too small a performance uplift. 

Some rewrites of the store cue allowed for cutting a cycle out of the process further improving the performance. However, more performance required slight deviations from the design of the original 386. Because code-branches are performance critical, the z386 project now computes the branch memory jump several cycles earlier than the 386, reducing the cycle time for the jumps from 9.25 to a mere 6. Some final changes to the microcode decode frontend rounded out the optimizations covered in this latest blog post.

The net result is an approximate 39% increase in performance in the all important DOOM benchmark. The z386 still not a complete project, the performance is still lacking compared to the 386, and it remains unable to boot Windows. X86 is complicated, which will take time, so make sure to stay tuned for more coverage! While you wait, make sure to check out our original writeup of the z386 project. 

Pauli Rautakorpi, CC BY 3.0.

While the original name of what much of the world knows as the NES was the Nintendo Family Computer, or Famicom for short, it was very rarely used as a family computer. Sure, there was a basic cartridge and an add-on keyboard sold in Japan, but it was always a sideshow to the games.

Nintendo recognized that when they brought their Entertainment System overseas. Most of the various famiclones — which date back to the mid-80s — are the same. BIT in Taiwan had a different idea: their Bit 79 would be a full home computer. Picture a C=64 that plays Nintendo games, and you might not be too far off. [Inkbox] tells the full story in his latest YouTube video, and it’s a must-watch for anyone interested in the history of 8-bit machines that are totally unknown in the West.

BIT were both game makers and system cloners; you may even have seen one of their NES or Atari games, as they were exported widely. By 1989 they’d already gone through a surprising number of Famicom clones, but those were pure clones and just played games. The Bit79 is obviously different — for one, it’s got a built-in keyboard in a wedge case. Apparently a pretty good one at that. For another, it starts with a bootloader that lets you choose between BASIC on ROM and loading the cartridge. For a third, it’s got a full 8K of RAM, quadrupling the Famicom’s offering– plus an additional 2K for the PPU, in what you might consider an early example of video RAM. Both CPU and PPU are knockoff chips made in Taiwan by UMC. The system even has what looks like a DB25 connect a printer. There’s also an expansion port, but no evidence that add-ons were ever sold, despite reports of a 64K memory add-on.

Back to the BASIC ROM for a moment– it’s not Famicom BASIC, as was clear in the manuals. [Inkbox] dumped the ROM to find that it is actually AppleSoft BASIC, of all things. That’s not only an odd bit of piracy, it’s also a big miss, since Apple’s BASIC doesn’t have any commands to make use of the PPU the way Famicom’s version does. POKING the registers during the vBlank interval is apparently not an easy thing to do. Perhaps that’s why we’ve never heard of this machine — well, that, and the fact we’re not located in East Asia where it was sold.

While the Bit79 didn’t sell particularly well, apparently it inspired a whole wave of “educational computer” famiclones in 1990s China that are largely unknown to the English-speaking world, making it an important part of computer history.

While BIT Corp is long gone, if you want to play around with their great experiment in turning a famiclone into a home computer, an emulator is available online, and the ROMs are preserved on the Internet Archive thanks to [InkBox].

Thanks, too, to [Stephen Walters] for the tip.