Building RAM Expansions For The DEC Rainbow 100

It’s hard enough to get your hands on a forgotten computer from yesteryear. It’s even more difficult to get accessories like RAM expansions and graphics cards, because half the time they’re just discarded as random e-waste when they’re outside of their original context. [na103] has solved this problem for the DEC Rainbow 100 to a degree, by building new RAM expansions and graphics cards from scratch.

In the case of the RAM expansion, the design [na103] built is capable of boosting a Rainbow 100 computer to a full 896KB. This is more than other contemporary IBM machines like the 8088 XT, which had an architecture-enforced limit of 640 KB.  It was rebuilt from some notes and original DEC schematics.

Continue reading “Building RAM Expansions For The DEC Rainbow 100”

Book8088 Slows Down To Join The Demoscene

As obsolete as the original IBM Model 5150 PC may appear, it’s pretty much the proverbial giant’s shoulders upon which we all stand today. That makes the machine worth celebrating, so much so that we now have machines like the Book8088, a diminutive clamshell-style machine made from period-correct PC chips; sort of a “netbook that never was.”

But the Book8088 only approximates the original specs of the IBM PC, making some clever hardware hacks necessary to run some of the more specialized software that has since been developed to really stretch the limits of the architecture. [GloriousCow]’s first steps were to replace the Book8088’s CPU, an NEC V20, with an actual 8088, and the display controller with a CGA-accurate Motorola MC6845. Neither of these quite did the trick, though, at least not on the demanding 8088MPH demo, which makes assumptions about CPU speed based on the quirky DRAM refresh scheme used in the original IBM PC.

Knowing this, [GloriousCow] embarked on a bodge-fest aimed at convincing the demo that the slightly overclocked Book8088 was really just a 4.77-MHz machine with a CGA adapter. This involved cutting a trace on the DMA controller and reconnecting it to the machine’s PIO timer chip, with the help of a 74LS74 flip-flop, a chip that made an appearance in the 5150 but was omitted from the Book8088. Thankfully, the netbook has plenty of room for these mods, and with the addition of a little bit of assembly code, the netbook was able to convince 8088MPH that it was running on the correct hardware.

We thoroughly enjoyed this trip down the DMA/DRAM rabbit hole. The work isn’t finished yet, though — the throttled netbook still won’t run the Area 5150 demo yet. Given [GloriousCow]’s recent Rust-based cycle-accurate PC emulation, we feel pretty good that this will come to pass soon enough.

Clock Hack Gives DEC Rainbow A New Lease On Life

In retrocomputing circles, it’s often the case that the weirder and rarer the machine, the more likely it is to attract attention. And machines don’t get much weirder than the DEC Rainbow 100-B, sporting as it does both Z80 and 8088 microprocessors and usable as either a VT100 terminal or as a PC with either CP/M or MS-DOS. But hey — at least it got the plain beige box look right.

Weird or not, all computers have at least a few things in common, a fact which helped [Dr. Joshua Reichard] home in on the problem with a Rainbow that was dead on arrival. After a full recapping — a prudent move given the four decades since the machine was manufactured — the machine failed to show any signs of life. The usual low-hanging diagnostic fruit didn’t provide much help, as both the Z80 and 8088 CPUs seemed to be fine. It was then that [Joshua] decided to look at the heartbeat of the machine — the 24-ish MHz clock shared between the two processors — and found that it was flatlined.

Unwilling to wait for a replacement, [Joshua] cobbled together a temporary clock from an Arduino Uno and an Si5351 clock generator. He connected the output of the card to the main board, whipped up a little code to generate the right frequency, and the nearly departed machine sprang back to life. [Dr. Reichard] characterizes this as a “defibrillation” of the Rainbow, and while one hates to argue with a doctor — OK, that’s a lie; we push back on doctors all the time — we’d say the closer medical analogy is that of fitting a temporary pacemaker while waiting for a suitable donor for a transplant.

This is the second recent appearance of the Rainbow on these pages — [David] over at Usagi Electric has been working on the graphics on his Rainbow lately.

Linux Fu: The Old School Terminal

Maybe you have a vintage old-school computer. Maybe you have a replica. Maybe you just want to run SIMH and relive the glory days of CP/M or VMS. The problem is, it looks kind of silly to have CP/M running in your beautiful X11 terminal window full of 3D animations, opacity effects, and special fonts. You could buy an old CRT monitor. That would be cool, too, because on a modern screen, you don’t get scan lines and all the crummy artifacts that go along with an electron beam and phosphor display device. Or you can grab retro-cool-term.

Star Trek on CP/M

Even if you don’t have an old computer, the program will work fine to simply run your shell for everyday use. Confound the youngsters when they see your terminal with scan lines and CRT jitter updating the latest packages.

What Is It?

If you want a shell in a GUI, you used to use xterm, although most people use something more modern. I use Konsole, but some like RXVT or whatever terminal your distro favors. Cool-retro-term is just a replacement for this. By default, it only opens a shell prompt.

Continue reading “Linux Fu: The Old School Terminal”

Ask Hackaday: Why Retrocomputing?

I recently dropped in on one of the Vintage Computer Festival events, and it made me think about why people — including myself — are fascinated with old computer technology. In my case, I lived through a lot of it, and many of the people milling around at VCF did too, so it could just be nostalgia. But there were also young people there.

Out of curiosity, I asked people about the appeal of the old computers on display there. Overwhelmingly, the answer was: you can understand the whole system readily. Imagine how long it would take you to learn all the hardware and software details of your current desktop computer CPU. Then add your GPU, the mass storage controllers, and your network interface. I don’t mean knowing the part numbers, specs, and other trivialities. I mean being able to program, repair, and even enhance it.

Continue reading “Ask Hackaday: Why Retrocomputing?”

Automation For The NES

Old hardware might not be anywhere close to as powerful as modern technology, but it does have a few perks. Aesthetics can of course drive the popularity of things like retro gaming systems, but the ease of understanding the underpinnings of their inner workings is also critical. The Nintendo Entertainment System, now nearly four decades old, is a relatively simple machine by modern standards and this lends the system to plenty of modifications, like this controller that allows the system to be somewhat automated.

The original NES controller used a fairly simple shift register to send button presses to the system. The system outputted a latch signal to the controller, the shift register would take as input the current state of the buttons, and then would send them one-by-one to the system at a rate of around 1000 times per second. These signals can be sent without a controller easily enough, too. This build uses a CD4021 shift register, which is the same as the original controller, but instead of reading button states it accepts its inputs from a separate computer via a latching circuit. In this case, the separate computer is a custom design that came about through adapting cassette storage for a 6502-based computer, but it could come from anything else just as easily.

With this system in place, it’s possible to automate gameplay to some extent. Since the system can’t get feedback about the game in its current state, it requires some precise timing to get it to play the game well, and a lot of tuning needs to go into it. This isn’t just a one-off, either. Similar methods are how we get tool-assisted speedruns of games and although these are often done in emulators instead of on real hardware, they can result in some interesting exploits.

Continue reading “Automation For The NES”

Stuffing A 32-Pin Chip Into A 28-Pin Socket

What’s the difference between a 64k ROM in a 28-pin DIP and a 128k ROM in a 32-pin DIP? Aside from the obvious answers of “64k” and “four pins,” it turns out that these two chips have a lot in common, enough so that it only takes a little bodging to make them interchangeable — more or less.

For a variety of reasons revealed in the video below, [Anders Nielsen] use the SST39SF010, a Flash ROM in a 32-pin DIP, in place of the old standby W27C512, an EEPROM in a 28-pin DIP. To deal with those pesky extra pins on the Flash ROM, [Anders] dug into the data sheets and found that thanks to JEDEC standards, almost everything about the pinouts of the two chips is identical. The only real difference is the location of Vcc, plus the presence of a 16th address bus line on the more capacious Flash ROM.

Willing to sacrifice the upper half of the Flash chip’s capacity, [Anders] set about bodging the 32-pin chip to work in a 28-pin socket. The mods include a jumper from pin 32 to pin 30 on the Flash chip, which puts Vcc in the right place, and adding a couple of pull-up resistors for write-enable and A16. Easy enough changes, but unfortunately, [Anders] chose a Flash ROM with heavily oxidized pins, leading to some cold solder joints and intermittent problems while testing. There’s also the fact that not all boards have room for overhanging pins, a problem solved by adding a socket to create a little vertical clearance.

We found this to be a neat little hack, one that should make it a bit easier to use the wrong chip for the job. If you want to see where [Anders] is using these chips, check out his 6502 in an Arduino footprint or the bring-up of an old XT motherboard.

Continue reading “Stuffing A 32-Pin Chip Into A 28-Pin Socket”