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

Rapid row activations (yellow rows) may change the values of bits stored in victim row (purple row).
Row hammer” by DsimicOwn 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.

The Intel 8088 And 8086 Processor’s Instruction Prefetch Circuitry

The 8088 die under a microscope, with main functional blocks labeled. This photo shows the chip's single metal layer; the polysilicon and silicon are underneath. (Credit: Ken Shirriff)
The 8088 die under a microscope, with main functional blocks labeled. This photo shows the chip’s single metal layer; the polysilicon and silicon are underneath. (Credit: Ken Shirriff)

Cache prefetching is what allows processors to have data and/or instructions ready for use in a fast local cache rather than having to wait for a fetch request to trickle through to system RAM and back again. The Intel 8088  (and its big brother 8086) processor was among the first microprocessors to implement (instruction) prefetching in hardware, which [Ken Shirriff] has analyzed based on die images of this famous processor. This follows last year’s deep-dive into the 8086’s prefetching hardware, with (unsurprisingly) many similarities between these two microprocessors, as well as a few differences that are mostly due to the 8088’s cut-down 8-bit data bus.

While the 8086 has 3 16-bit slots in the instruction prefetcher the 8088 gets 4 slots, each 8-bit. The prefetching hardware is part of the Bus Interface Unit (BIU), which effectively decouples the actual processor (Execution Unit, or EU) from the system RAM. While previous MPUs would be fully deterministic, with instructions being loaded from RAM and subsequently executed, the 8086 and 8088’s prefetching meant that such assumptions no longer were true. The added features in the BIU also meant that the instruction pointer (IP) and related registers moved to the BIU, while the ringbuffer logic around the queue had to somehow keep the queueing and pointer offsets into RAM working correctly.

Even though these days CPUs have much more complicated, multi-level caches that are measured in kilobytes and megabytes, it’s fascinating to see where it all began, with just a few bytes and relatively straight-forward hardware logic that you easily follow under a microscope.

The Book8088 Gets A Post-Hype Review

Last year, a couple of rather unusual computers emerged from China: a 386sx-based palmtop and an 8088-based mini-laptop. The average person isn’t exactly clamoring for a DOS machine these days, but they attracted quite a bit of interest among the retrocomputing scene. Now the dust has settled, [The Retro Shack] has taken a Book 8088 and given it an honest review. Do you need portable 1980s computing in your life, and if so it this the machine to give you it?

The first impression of the machine is just how svelte it is, being like a small but chunky netbook. He explores the hardware and finds as expected an NEC V20 instead of the Intel part running the show, and what would have been a hugely expanded DOS PC back in the day with its VGA and sound card, not to mention a solid state hard drive.

We’re overcome with a bit of nostalgia here at the sight of DOS running Lemmings, and on a machine we’d have given anything to own back in the 1980s. His final conclusion is that it’s a very nice little PC but around $160 seems a little much for what is essentially a toy. We have sadly to agree with him though we really want one, though noting that such a machine would have retailed for a huge amount more than that in 1980s dollars and we’d have considered it a huge bargain then.

If you’re still curious, we covered the arrival of these machines last year.

Continue reading “The Book8088 Gets A Post-Hype Review”

Finally, An Open-Source 8088 BIOS

The Intel 8088 is an interesting chip, being a variant of the more well-known 8086. Given the latter went on to lend its designation to one of the world’s favorite architectures, you can tell which of the two was higher status. Regardless, it was the 8088 that lived in the first IBM PC, and now, it even has its own open-source BIOS.

As with any BIOS, or Basic Input Output System, it’s charged with handling core low-level features for computers like the Micro 8088, Xi 8088, and NuXT. It handles chipset identification, keyboard and mouse communication, real-time clock, and display initialization, among other things.

Of course, BIOSes for 8088-based machines already exist. However, in many cases, they are considered to be proprietary code that cannot be freely shared over the internet. For retrocomputing enthusiasts, it’s of great value to have a open-source BIOS that can be shared, modified, and tweaked as needed to suit a wide variety of end uses.

If you want to learn more about the 8088 CPU, we’ve looked in depth at that topic before. Feel free to drop us a line with your own retro Intel hacks if you’ve got them kicking around!

Decoding The 8088

There is a lot to like about open software, and in some areas, a well-thought-out piece of software can really make a huge impact. A great example of this is the Sigrok project. Creating simple devices that act like a logic analyzer is relatively easy. What’s hard is writing nice software for such a setup including protocol decoders. Sigrok has done it and since it is open, you can add your device and decode your protocol. [GloriousCow] had done the hardware part of interfacing to the 8088 in an IBM PC using an off-the-shelf logic analyzer that uses a customized version of Sigrok. But the output was a CSV file you had to process in a spreadsheet program. The next step: write a decoder for Sigrok to understand 8088 bus cycles.

The post covers the details of writing such a plug-in for Pulseview, the Sigrok GUI. It will also work for the command line interface if you prefer that. The code is in Python.

Continue reading “Decoding The 8088”

Designing A Macintosh-to-VGA Adapter With An LM1881

Old-school Macintosh-to-VGA adapter. Just solve for X, set the right DIP switches and you’re golden.

If you’re the happy owner of a vintage Apple system like a 1989 Macintosh IIci you may know the pain of keeping working monitors around. Unless it’s a genuine Apple-approved CRT with the proprietary DA-15-based video connector, you are going to need at least an adapter studded with DIP switches to connect it to other monitors. Yet as [Steve] recently found out, the Macintosh’s rather selective use of video synchronization signals causes quite a headache when you try to hook up a range of VGA-equipped LCD monitors. A possible solution? Extracting the sync signal using a Texas Instruments LM1881 video sync separator chip.

Much of this trouble comes from the way that these old Apple systems output the analog video signal, which goes far beyond the physical differences of the DA-15 versus the standard DE-15 D-subminiature connectors. Whereas the VGA standard defines the RGB signals along with a VSYNC and HSYNC signal, the Apple version can generate HSYNC, VSYC, but also CSYNC (composite sync). Which sync signal is generated depends on what value the system reads on the three sense pins on the DA-15 connector, as a kind of crude monitor ID.

Theoretically this should be easy to adapt to, you might think, but the curveball Apple throws here is that for the monitor ID that outputs both VSYNC and HSYNC you are limited to a fixed resolution of 640 x 870, which is not the desired 640 x 480. The obvious solution is then to target the one monitor configuration with this output resolution, and extract the CSYNC (and sync-on-green) signal which it outputs, so that it can be fudged into a more VGA-like sync signal. Incidentally, it seems that [Steve]’s older Dell 2001FP LCD monitor does support sync-on-green and CSYNC, whereas newer LCD monitors no longer list this as a feature, which is why now more than a passive adapter is needed.

Although still a work-in-progress, so far [Steve] has managed to get an image on a number of these newer LCDs by using the LM1881 to extract CSYNC and obtain a VSYNC signal this way, while using the CSYNC as a sloppy HSYNC alternative. Other ICs also can generate an HSYNC signal from CSYNC, but those cost a bit more than the ~USD$3 LM1881.

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.