Exploring Texas Instrument’s Forgotten CPU

Texas Instruments isn’t the name you usually hear associated with the first microprocessor. But the TI TMX 1795 was an 8008 chip produced months before the 8008. It was never available commercially, though, so it has been largely forgotten by most people. But not [Ken Shirriff]. You can see a demo from 2015 of the device in the video below, too.

The reason the chips have the same architecture is they were built to replace the same large circuit board inside a Datapoint 2200 programmable terminal. These were big beasts that could be programmed in BASIC or PL/B.

Datapoint asked Intel to shrink the board to a chip due to heating problems — but after delays, they instead replaced the power supply and lost interest in the device. TI heard about the affair and wanted in on the deal. However, Datapoint was unimpressed. The chip didn’t tolerate voltage fluctuations very well, since they had replaced the power supply and had a new CPU design that was faster than the chip would be. They were also unimpressed with how much stuff you had to add to get a complete system.

So why did the Intel 8008 work out in the marketplace but the TI chip didn’t? After all, Datapoint decided not to use the 8008, also. But as [Ken] points out, the 8008 was much smaller than the TI chip and, thus, was more cost-effective to produce.

As usual, [Ken]’s posts are always interesting and enlightening. He’s looked at a lot of old computers. He’s even dug into old space hardware. Great stuff!

Continue reading “Exploring Texas Instrument’s Forgotten CPU”

The MOS 7600 Video Game Chip Gives Up Its Secrets

A good chip decapping and reverse engineering is always going to capture our interest, and when it comes from [Ken Shirriff] we know it’s going to be a particularly good one. This time he’s directed his attention to the MOS 7600 all-in-one video game chip (Nitter), a mostly forgotten device from the 6502 chipmaker which we featured a few weeks ago when it was the subject of a blogger’s curiosity. The question then was whether it contained a microprocessor or not and even whether it was another 6502 variant, and the answer revealed in the decapping answers that but will disappoint the 6502 camp.

On the chip is a mixture of analog and digital circuitry, with some elements of a more traditional game chip alongside a ROM, a PLA, and a serial CPU core. The PLA stores pixel data while the ROM stores the CPU code, and the CPU serves to perform calculations necessary to the games themselves. He hasn’t fully reverse-engineered either, but the two areas of the chip are mask-programmed to produce the different games with which the chip could be found.

So the answer to the original question is that there is a CPU on board, but it’s not a 6502 and the operation is a hybrid between dedicated game chip and CPU-controlled chip. What we find interesting is that this serial CPU core might have as we mused in the previous piece made the heart of a usable 1970s microcontroller, was this a missed opportunity on the part of MOS? We’ll never know, but at least another piece of early video game history has been uncovered.

Down The Intel Microcode Rabbit Hole

The aptly-named [chip-red-pill] team is offering you a chance to go down the Intel rabbit hole. If you learned how to build CPUs back in the 1970s, you would learn that your instruction decoder would, for example, note a register to register move and then light up one register to write to a common bus and another register to read from the common bus. These days, it isn’t that simple. In addition to compiling to an underlying instruction set, processors rarely encode instructions in hardware anymore. Instead, each instruction has microcode that causes the right things to happen at the right time. But Intel encrypts their microcode. Of course, what can be encrypted can also be decrypted.

Using vulnerabilities, you can activate an undocumented debugging mode called red unlock. This allows a microcode dump and the decryption keys are inside. The team did a paper for OffensiveCon22 on this technique and you can see a video about it, below.

Continue reading “Down The Intel Microcode Rabbit Hole”

Scott’s CPU From The Bottom Up

It isn’t for everyone, but if you work much with computers at a low level, you’ll probably sooner or later entertain the idea of creating your own CPU. There was a time when that was a giant undertaking, but with today’s tools and FPGAs it is… well, not easy, but certainly easier. If you have the urge to try your own, you might have a look at [Simply Explained’s] video series called “Building Scott’s CPU.

The 11 videos cover everything from basic transistor logic to sequential circuits and moves on to things like ALUs, clock units, and how jump instructions work.

Continue reading “Scott’s CPU From The Bottom Up”

Calculating Pi On The 4004 CPU, Intel’s First Microprocessor

These days we are blessed with multicore 64-bit monster CPUs that can calculate an entire moon mission’s worth of instructions in the blink of an eye. Once upon a time, though, the state of the art was much less capable; Intel’s first microprocessor, the 4004, was built on a humble 4-bit architecture with limited instructions. [Mark] decided calculating pi on this platform would be a good challenge. 

It’s not the easiest thing to do; a 4-bit processor can’t easily store long numbers, and the 4004 doesn’t have any native floating point capability either. AND and XOR aren’t available, either, and there’s only 10,240 bits of RAM to play with. These limitations guided [Mark’s] choice of algorithm for calculating the only truly round number. Continue reading “Calculating Pi On The 4004 CPU, Intel’s First Microprocessor”

Now The V In RISC-V Stands For VRoom

Hundreds of variations of open-source CPUs written in an HDL seem to float around the internet these days (and that’s a great thing). Many are RISC-V, an open-source instruction set (ISA), and are small toy processors useful for learning and small tasks. However, if you’re [Paul Campbell], you go for a high-end super-scalar, out-of-order, speculative, 8 IPC monster of a RISC-V CPU known as VRoom!.

That might seem a bit like word soup to the uninitiated in the processor design world (which is admittedly relatively small) but what makes this different from VexRISC is the scale and complexity. Rather than executing one instruction at a time sequentially, it executes multiple instructions, completing them concurrently in whatever order it can handle. The VexRISC chip is a good 32-bit modular design that can run Linux. It pulls a solid 1.57 DMIPS/MHz with everything turned on. The VRoom already clocks in at mighty 6.5 DMIPS/MHz, with more performance gains. It peaks at 8 instructions every clock cycle with a dual register file and a clever committing system to keep up.

VRoom is written in System Verilog to leverage Verilator (a handy linting and simulation framework), and while there is some C that generates different files, we’d wager it is pretty run-of-the-mill compared to a TypeScript based project. VRoom currently boots Linux thanks to an AWS-FPGA instance (a Xilinx VU9P Ultrascale), though it has to be trimmed to fit. [Paul] has big plans working his way up to a server-class chip with lots of cores and a huge cache.

It’s all on GitHub under a GPLv3 license; go check it out! [Paul] also has a talk with lots of great details. If you’re interested in getting into RISC-V but a server-class isn’t your speed, we heard Espressif is starting to use RISC-V cores in their ever-popular ESP series.

Tilting At Windmills Nine Bits At A Time

In the old days — we are talking like the 1960s and 1970s — computers were often built for very specific purposes using either discrete logic or “bit slice” chips. Either way, more bits meant more money so frequently these computers were made with just enough bits to meet a required precision. We don’t think that was what was on [Mad Ned’s] mind, though, when he decided to implement a 9-bit CPU called QIXOTE-1 on an FPGA.

Like many hobby projects, this one started with an FPGA board in search of a problem. At first, [Ned] had a plan to create a custom computer along with a custom language to then produce a video game. A quick search on the Internet led to that being a common enough project with one guy that we’ve talked about here on Hackaday before knocking it out of the park.

[Ned] then thought about just doing a no-software video game. Too late to be the first to do that. Not to be deterred, he decided to duplicate the PDP-8. Whoops. That’s been done before, too. Wanting something original, he finally decided on a custom CPU. Since bytes are usually — if not technically — 8 bits, this CPU calls its 9-bit words nonads and uses octal which maps nicely to three digits per nonad.

This first post talks about the story behind the CPU and gives a short overview of its capabilities, but we are waiting for future posts to show more of what’s behind the curtain in what [Ned] calls “Holy Nonads, Part 010.”

The downside to doing a custom CPU is you have to build your own tools. You can always, of course, duplicate something and steal your toolchain. Or go universal.