A little over a month ago, we featured a project from [Igor] who built 64 bits of DRAM from scratch using discrete components. Jokes about memory pricing aside, he did have a use case for such a small amount of memory — he is using it in a custom-built drum machine. But featuring the memory build and not the drum machine was perhaps putting the cart before the horse, so in this video, [Igor] shows off the construction of each part of his impressive 16- or 64-step sequence drum machine.

This isn’t Igor’s first drum machine, either, although his previous build was a bit more limited. It had fewer steps in the sequence and didn’t quite have the range of his newer model. The upgraded version can play more steps but also includes force-sensitive drum pads based on piezo sensors and more voices (drums) as well. Each voice is built electronically using various op-amps and passive components, and [Igor] has the schematics for each of them, as well as every other part of the drum machine, for those looking to recreate any part of this on their own. There’s a lot going on in this lengthy video as well, so for the musically inclined, it’s worth taking a look in full.

Now that our horse is in the correct position in front of the cart, it’s worth going back and looking at the memory build if you missed it when it first ran. A small amount of memory makes the machine programmable rather than just playable, and truly expands the capabilities of a machine like this in the recording studio.

Counterpoint says rising AI memory demand helped drive smartphone shipments to their weakest second quarter since 2013 as DRAM and NAND costs climbed.

The post AI’s Memory Boom Is Reshaping the Smartphone Market appeared first on TechRepublic.

[BillPg] has been designing a fantasy 1980s-era home computer. As part of the exercise, he’s reevaluating all the assumptions that have grown organically over time in the small computer landscape. Hindsight is, so they say, 20/20, but sometimes hindsight can also be colored by modern thinking. Sometimes an idea that seems stupid today made sense in the context of its time. In particular, [Bill] has thoughts on the much-maligned 8086 memory segments.

If you haven’t run into it before, the 8086/8088 had a problem. It wanted to be more or less conceptually software compatible with the 8080 and Z80 computers, which had 16-bit addresses, leading to a limit of 64K of memory. When Intel was designing the next generation of chips, it knew that 64K had to go, but telling developers that code would require huge reengineering was a non-starter. So the idea was to provide multiple 64K spaces broken up into segments.

As with most things, there is theory, and there is practice. In theory, a 16-bit segment provided four extra address bits to add to the existing 16-bit address, producing a 32-bit address, even though the CPU only had 20 bits of address bus. Code that fit in 64K could pretend like that was the whole world, and a tricked-out system could have 16 worlds. Future systems could, in theory, have had more.

In practice, Intel made the segment the top 16 bits of a 32-bit address and then added it to the ordinary 16-bit address. So address 0000:0010 (segment=0, address=10 hex) is the same memory location as 0001:0000. Address 0010:0010 is the same as address 0000:0110 and 0001:0100. This wasn’t really the intent, just a byproduct of how the chip worked.

Eventually, the segments would become indices into a table (like the title graphic), but by then, bad practices wiped out a good idea. It is doubtful that the original designers thought anyone would take advantage of the overlapping address, but, of course, they did.

By the time the 80286 and beyond produced segments that were really keys which defined a block of memory, everyone was already in the mode of using the segment and offset as a large pointer. C compilers even had “modes” that let you treat the segment as just more address bits. Because of that, even on newer processors, people had a tendency to build a “flat” segment and use it. That is, make a segment that starts at 0, ends at the end of memory, and then forget about segments.

In fact, many people independently discovered that you could define a flat segment in protected mode, return to real mode, and then enjoy a flat address space. This was later christened unreal mode, and a topic we’ve covered a few times before.

We agree with [Bill]. Segments were a good idea at the time and might have been more important if people had used them the “right” way. Of course, there would have been ups and downs. Proper segments might have allowed for easy virtual memory, for example. But at the price of possibly swapping in and out huge segments instead of relatively small pages. Today, most of what segments were supposed to do is part of the memory management unit and is mostly hidden from the application developer. Still, interesting to reflect on why Intel made that choice and how we got to where we are today.