Maxing Out Your MacIntosh With A 4 MB Memory Stick Kit

One fun aspect of retrocomputing is that you get to max out all aspects of these systems without having to take out a bank loan, as tended to be the case when these systems were new. Less fun is that decades after systems like the Apple MacIntosh SE/30 were last sold, the 30-pin SIMMs that form the expandable RAM for these systems has become rather scarce. This has led many to make their own SIMM PCBs, including [Kay Koba] with a PCB for 4 MB SIMMs along with information on which memory and parity ICs are suitable for these SIMMs.

For systems like the MacIntosh SE/30 with 8 30-pin memory slots, the maximum capacity is 128 MB, but this comes with many gotchas due to its ROM being ’32-bit dirty’. While this can be circumvented by swapping in a ROM from a later MacIntosh variant, the less invasive way is to enable the MODE32 system extension and install eight 4 MB SIMMs for a total of 32 MB RAM. RAM chips for such 30-pin SIMMs can be scavenged from the far more common 72-pin SIMMs, along with any old new stock one may come across.

These 4 MB SIMM PCBs are offered for sale by [Kay] with optionally the SMD components (capacitors, resistors and LED) included in the package. The original PCB card edge design is credited to work by [Zane Kaminski] whose GitHub profile also leads to e.g. this 30-pin SIMM project.

Have you modded your MacIntosh or other retro system yet to the maximum RAM and storage limits?

An assortment of MemoryStick cards and devices, some of them, arguably cursed, like a MemoryStick-slot-connected camera.

Hacker Challenges MemoryStick To A Fight And Wins

It’s amazing when a skilled hacker reverse-engineers a proprietary format and shares the nitty-gritty with everyone. Today is a day when we get one such write-up – about MemoryStick. It is one of those proprietary formats, a staple of Sony equipment, these SD-card-like storage devices were evidently designed to help pad Sony’s pockets, as we can see from the tight lock-in and inflated prices. As such, this format has always remained unapproachable to hackers. No more – [Dmitry Grinberg] is here with an extensive breakdown of MemoryStick protocol and internals.

If you ever want to read about a protocol that is not exactly sanely designed, from physical layer quirks to things like inexplicable large differences between MemoryStick and MemoryStick Pro, this will be an entertaining read for hackers of all calibers. Dmitry doesn’t just describe the bad parts of the design, however, as much as that rant is entertaining to read – most of the page is taken by register summaries, struct descriptions and insights, the substance about MemoryStick that we never got.

One sentence is taken to link to a related side project of [Dmitry] that’s a rabbithole on its own – he has binary patched MemoryStick drivers for PalmOS to add MemoryStick Pro support to some of the Sony Clie handhelds. Given the aforementioned differences between non-Pro and Pro standards, it’s a monumental undertaking for a device older than some of this site’s readers, and we can’t help but be impressed.

To finish the write-up off, [Dmitry] shares with us some MemoryStick bit-banging examples for the STM32. Anyone who ever wanted to approach MemoryStick, be it for making converter adapters to revive old tech, data recovery or preservation purposes, or simply hacker curiosity, now can feel a bit less alone in their efforts.

We are glad to see such great hacking on the MemoryStick front – it’s much needed, to the point where our only article mentioning MemoryStick is about avoiding use of the MemoryStick slot altogether. [Dmitry] is just the right person for reverse-engineering jobs like this, with extensive reverse-engineering history we’ve been keeping track of – his recent reverse-engineering journey of an unknown microcontroller in cheap E-Ink devices is to behold.

Linux Fu: Reading Your Memory’s Memory

Linux users have a lot of software to be proud of. However, there is the occasional Windows program that does something you’d really like to do and it just won’t run. This is especially true of low-level system programs. If you want to poke around your CPU and memory, for example, there are tons of programs for that under Windows. There are a few for Linux, but they aren’t always as complete or handy. Recently, I had half the memory in my main desktop fail and I wanted to poke around in the system. In particular, I wanted to read the information encoded in the memory chips configuration EEPROM. Should be easy, right? You’d think.

Not Really Easy

One nice tool a lot of Windows users have is CPU-Z. Of course, it doesn’t run on Linux, but there is a really nice imitator called CPU-X. You can probably install it from your repositories. However, the GitHub page is a nice stop if for no other reason than to enjoy the user name [TheTumultuousUnicornOfDarkness]. The program has a gtk or an ncurses interface. You don’t need to run it as root, but if you press the “start daemon” button and authenticate, you can see some extra information, including a tab for memory.

Continue reading “Linux Fu: Reading Your Memory’s Memory”

Showing the end result - a Defender machine copy in all its glory, with a colourful front panel with joysticks.

Defender Arcade Rebuilt To Settle A Childhood Memory

[Jason Winfield] had a nemesis: the Defender arcade machine. Having put quite a number of coins into one during his childhood, he’s since found himself as a seasoned maker, and decided to hold a rematch on his own terms. For this, he’s recreated the machine from scratch, building it around the guts of a Dell laptop, and he tells us the story what it took to build a new Defender in this day and age.

Defender was a peculiar machine — it was in cocktail table format, unlike many other arcade machines of that period. From pictures, he’s redesigned the whole thing in Fusion 360, in a way more desk-friendly format, but just as fancy looking as before.

As for the laptop, gutting it for its mainboard, screen, and speakers was a surprisingly painless procedure — everything booted up first try. A few board-fitted brackets and a swap from a HDD to a USB flashdrive for the OS later, the electronics were ready. As he was redesigning the entire arcade machine anyway, the new design control panel was also trimmed down for ease of use, while preserving the original colorful look.

All in all, an impressive build from [Jason]. After all was set and done, we don’t doubt that he went on to, let’s say, settle some old scores. It’s not the first time we see a desktop-sized arcade cabinet, and you gotta admire the skills making such a machine smaller while sticking to the old-timey aesthetic! Or, perhaps, would you like a cabinet that’s more subtle?

Continue reading Defender Arcade Rebuilt To Settle A Childhood Memory”

Modernizing C Arrays For Greater Memory Safety

Lately, there has been a push for people to stop using programming languages that don’t promote memory safety. But as we still haven’t seen the death of some languages that were born in the early 1960s, we don’t think there will be much success in replacing the tremendous amount of software that uses said “unsafe” languages.

That doesn’t mean it’s a hopeless cause, though. [Kees Cook] recently posted how modern C99 compilers offer features to help create safer arrays, and he outlines how you can take advantage of these features. Turns out, it is generally easy to do, and if you get errors, they probably point out unexpected behavior in your original code, so that’s a plus.

We don’t think there’s anything wrong with C and C++ if you use them as you should. Electrical outlets are useful until you stick a fork in one. So don’t stick a fork in one. We really liked the recent headline we saw from [Sarah Butcher]: “If you can’t write safe C++ code, it’s because you can’t write C++.” [Cook’s] post makes a similar argument.  C has advanced quite a bit and the fact that 30-year-old code doesn’t use these new features isn’t a good excuse to give up on C.

Continue reading “Modernizing C Arrays For Greater Memory Safety”

Two circuit boards connected with wires

Glow In The Dark Computer Memory Illuminates The Fundamentals

Computer memory has taken on many forms over the years, from mercury-based delay-line tubes to handwoven magnetic core. These days, volatile storage using semiconductors has become ubiquitous with computing, but what if there was a better way? [Michael Kohn] has been working on a new standard for computer memory that uses glow in the dark stickers.

Clearly we jest, however we’re still mighty impressed by the demonstration. Eight delightful star-shaped phosphorescent stickers represent eight bits of memory, totaling one byte. The glow in the dark material is stuck to the inside of short cylinders, each of which contains a white LED and a phototransistor. The memory array is wired up to an iceFUN FPGA board, which is then connected via level shifters to a Western Design Center MENSCH single board computer.

Continue reading “Glow In The Dark Computer Memory Illuminates The Fundamentals”

Hackers, Fingerprints, Laptops, And Stickers

A discussion ensued about our crazy hacker ways the other night. I jokingly suggested that with as many stickers as we each had on our trusty companion machines, they might literally be as unique as a fingerprint. Cut straight to nerds talking too much math.

First off, you could wonder about the chances of two random hackers having the same sticker on their laptop. Say, for argument’s sake, that globally there are 2,000 stickers per year that are cool enough to put on a laptop. (None of us will see them all.) If a laptop lasts five years, that’s a pool of 10,000 stickers to draw from. If you’ve only got one sticker per laptop, that’s pretty slim odds, even when the laptops are of the same vintage.

Real hackers have 20-50 stickers per laptop — at least in our sample of “real hackers”. Here, the Birthday Paradox kicks in and helps us out. Each additional sticker provides another shot at matching, and an extra shot at being matched. So while you and I are unlikely to have the same birthday, in a room full of 42 people, it’s 90% likely that someone will have their birthday matched. With eight of us in the room, that’s 240 stickers that could match each other. (9999 / 10000) ^ (240 * 210 / 2) = about an eight percent chance of no match, so a better than 90% chance that we’d have at least one matching sticker.

But that doesn’t answer the original question: are our be-stickered laptops unique, like fingerprints or snowflakes? There, you have to match each and every sticker on the laptop — a virtually impossible task, and while there were eight of us in the room, that’s just not enough to get any real juice from the Birthday Paradox. (1/10,000) ^ 30 = something with -120 in the exponent. More than all the atoms in the universe, much less hackers in a room, whether you take things to the eighth power or not.

I hear you mumbling “network effects”. We’ve all gone to the same conferences, and we have similar taste in stickers, and maybe we even trade with each other. Think six degrees of separation type stuff. Indeed, this was true in our room. A few of us had the same stickers because we gave them to each other. We had a lot more matches than you’d expect, even though we were all unique.

So while the math for these network effects is over my head, I think it says something deeper about our trusty boxen, their stickers, and their hackers. Each sticker also comes with a memory, and our collected memories make us unique like our laptops. But matching stickers are also more than pure Birthday Paradoxes, they represent the shared history of friends.

Wear your laptop stickers with pride!