This week Jonathan Bennett and Simon Phipps chat with Matthew Hodgson and Josh Simmons about Matrix, the open source decentralized communications platform. How is Matrix a Git for Communications? Are the new EU and UK laws going to be a problem? And how is the Matrix project connected with the Element company?
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 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.
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.
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.
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.
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.