Comparing a 1980s memory map to the Raspi Pico

Hacker News Top News

Summary

A comparison of a 1989 Motorola 68000 memory map design with the modern Raspberry Pi Pico, highlighting the luxury of round-number allocation and the similar scale of memory (192KB vs 260KB), while discussing architectural differences and feasibility.

No content available
Original Article
View Cached Full Text

Cached at: 05/14/26, 12:17 AM

# How a 1980s Memory Map Compares to a Modern Raspberry Pi Pico Source: [https://medium.com/@noborutakahashi/a-40-year-old-memory-map-comparable-to-todays-raspberry-pi-pico-932c4309260d](https://medium.com/@noborutakahashi/a-40-year-old-memory-map-comparable-to-todays-raspberry-pi-pico-932c4309260d) [![Noboru Takahashi](https://miro.medium.com/v2/resize:fill:64:64/1*ugYRjhP2s1TuHk71VGV2mw.png)](https://medium.com/@noborutakahashi?source=post_page---byline--932c4309260d---------------------------------------) Press enter or click to view image in full size In the first article, I wrote about analyzing a 40\-year\-old RTOS I had built using AI\. This time, as a continuation, I look at the memory map notes from that time to understand the design approach\. Reference: [A 40\-Year\-Old System Analyzed with AI: It Turned Out to Have a Modern Architecture](https://medium.com/@noborutakahashi/a-40-year-old-system-analyzed-with-ai-it-turned-out-to-have-a-modern-architecture-83751821bf5a) [\(Japanese version\)](https://note.com/noborutkhs/n/nf991bd46571b) ### 1989 Memory Map There is a memo from 1989, when I developed the communication system for my second company\. The hardware was not custom\-made; it was built by combining general\-purpose Motorola VME bus boards\. Press enter or click to view image in full size Memory map of the second system\(It was in Japanese\)## Local RAM \(192KB\) Local RAM appears to be the memory on the 68000 CPU board\. It ranges from 000000 to 02FFFF, totaling 192KB\. There is a debug monitor called VMEBUG, on top of which the OS \(CHARM\-II\) is implemented\. The application is also placed in this area\. This is the core execution area\. ## Global RAM \(512KB\) Global RAM ranges from 080000 to 0FFFFF, totaling 512KB\. It is likely implemented as a separate RAM board\. The last line in the memo shows 0FFFF, which is probably missing one “F”\. Rewriting this area as a diagram makes its characteristics clearer\. Press enter or click to view image in full size Global RAM — reorganized memory map \(red areas are discarded\)## Round\-number Allocation and Unused Space Normally, memory is packed as tightly as possible to avoid waste\. Allocations are adjusted in units of a few kilobytes to eliminate gaps\. However, in this map: \- Memory is divided in 64KB units \- Remainders are left as\-is \- Unused regions clearly exist The design prioritizes clarity and simplicity over memory efficiency\. This was likely made possible by the addition of 512KB of RAM\. ## Message Area \(320KB\) A large portion of Global RAM is allocated as the Message Area, occupying 320KB\. At the time, this was a very large allocation\. ## 50 bps Communication Most overseas communication for this system used TELEX \(50 bps\)\. A simple calculation shows that filling 320KB would take about 20 hours\. In practice, data would almost never accumulate to that extent\. As a result, this area was effectively impossible to fully utilize\. At this point, 512KB of RAM felt more than sufficient\. This made it possible to adopt a “luxurious” memory map, using round\-number allocation and leaving unused areas without concern\. ## Comparison with Raspberry Pi Pico The current Raspberry Pi Pico has about 260KB of RAM\. The Pico 2 has about 520KB\. Compared to this, the Local RAM \(192KB\) of the 68000 system is quite similar in scale\. The access methods are also different\. At the time, RAM was accessed via the VME bus, with an effective bandwidth of a few MB/s\. In contrast, the Pico executes code while reading from external flash via QSPI\. Although the architectures differ, they can still be compared at a similar scale\. ## Feasibility on a Pico\-based System The second system was built using general\-purpose boards, resulting in a large enclosure — about the size of a full\-tower PC — and sturdy enough for an adult to sit on\. The 68000 at the time operated at around 8 MHz, whereas the Pico’s RP2040 runs at up to 133 MHz\. In terms of clock speed alone, there is more than a tenfold difference\. Additionally, while the 68000 has 32\-bit registers, its bus is 16\-bit\. In contrast, the Pico is fully 32\-bit in both registers and bus\. Considering these factors, the communication system from that time could likely be implemented today using a Pico\. ## An Era Where 1MB Was Enough Given the constraint of 50 bps communication, even 1MB of memory would rarely be fully utilized\. In this era, communication speed — not memory — was the primary bottleneck\. ## A Few Years Later: Considering 48MB Looking at notes from the early 1990s, the situation changes significantly\. Press enter or click to view image in full size Memo considering whether to expand Mac memory \(The original was in Japanese\)At that point, 16MB was not enough, and expansion up to 48MB was being considered\. By then, the system was handling image processing and print\-related data on a Mac\. ## Changing Memory Demands As the focus shifted from text\-based communication to image and bitmap processing, memory requirements increased by orders of magnitude\. Within just a few years, the required capacity changed drastically\. ## Summary Revisiting the memory map from 40 years ago reveals the design approach through its round\-number allocation and intentionally unused spaces\. With the addition of 512KB of RAM, it became possible to prioritize simplicity over memory efficiency\. However, only a few years later, even 48MB was being considered insufficient\. Memory capacity continues to grow, but so do the demands placed on it\. As a result, the sense of “not enough” never really disappears\. [\(Japanese version\)](https://note.com/noborutkhs/n/nf991bd46571b) ## Series: Revisiting a 40\-Year\-Old System - [When I analyzed a 40\-year\-old system with AI, it looked just like modern architecture](https://medium.com/@noborutakahashi/a-40-year-old-system-analyzed-with-ai-it-turned-out-to-have-a-modern-architecture-83751821bf5a) - This article:[A memory map from 40 years ago revealed an unexpectedly “luxurious” design](https://medium.com/@noborutakahashi/a-40-year-old-memory-map-comparable-to-todays-raspberry-pi-pico-932c4309260d) - [An Era When Almost Everything Was My Code — CHARM\-II and Bare\-Metal Systems](https://medium.com/@noborutakahashi/an-era-when-almost-everything-was-my-code-charm-ii-and-bare-metal-systems-0394fb119744)

Similar Articles

Watching a Z80 from an RP2350

Hacker News Top

A blog post exploring how to use a Raspberry Pi Pico RP2350 with PIO to monitor the address and data buses of a Z80 microprocessor, including timing considerations and clock speed limits.

I built a pint-sized Macintosh

Jeff Geerling

Built a pint-sized Macintosh using a Raspberry Pi Pico running Pico Micro Mac firmware, with VGA output and USB keyboard/mouse.

8086 Segmented Memory was a good idea

Hacker News Top

A retrospective analysis argues that the 8086 segmented memory architecture was a clever design that could have scaled gracefully, but software developers' insistence on treating memory as a flat space led to its perceived flaws.

News about Raspberry Pi 6 and Microcontroller Development

Jeff Geerling

Article reports on a Reddit AMA with Raspberry Pi leaders, revealing that the Pi 6 is not expected before early 2028, will focus on faster CPU/IO without a dedicated NPU, and details ongoing Pi Zero supply issues and microcontroller updates.

VGA Memory Access Is Complicated

Hacker News Top

The article discusses the complexities of VGA memory access and the challenges of emulating old hardware due to inadequate documentation.