A supposedly "lost" Japanese-language ROM for the Macintosh Plus has resurfaced. While believed to be rare and possibly unique, the author discovered the ROM was actually readily available within the Macintosh Plus's "System Tools" disk all along. The ROM simply enables KanjiTalk, the Japanese language support system for classic Macs, and its existence was documented, just not widely known or easily accessible online until now. Essentially, the mystery surrounding the ROM stemmed from obscurity and a misunderstanding rather than genuine rarity.
Kicksmash32 is a dual Kickstart ROM replacement for Amiga computers, offering a streamlined way to switch between different Kickstart versions (1.2, 1.3, 2.04, 3.1, 3.2.1). It uses a compact menu activated by holding both mouse buttons during startup, allowing users to select their desired Kickstart ROM without physical hardware modifications. The project is open-source and supports various Amiga models including A500, A600, A1200, and A4000. This simplifies the process of booting into different AmigaOS versions for compatibility with various software and games.
Commenters on Hacker News largely expressed excitement and nostalgia for the Amiga, praising the Kicksmash project for its ingenuity and potential. Several users shared their personal experiences with Amiga kickstart ROMs, highlighting the challenges of managing multiple versions for different software and configurations. The convenience of switching between ROMs using a selector was lauded as a major benefit. Some questioned the legality of distributing ROMs, even modified ones, and discussed the nuances of copyright law concerning abandonware. Others delved into technical details, speculating about the possibility of running Kickstart 3.1.4 from RAM and exploring the intricacies of Amiga hardware. A few users also inquired about compatibility with various Amiga models and expansions. The overall sentiment was one of positive interest and appreciation for the project's contribution to the Amiga community.
The blog post details the author's journey in reverse-engineering the System ROM (SROM) of their AlphaStation 255/300. Driven by curiosity and the desire to understand the boot process, they meticulously documented the SROM's contents, including memory maps, initialization routines, and interactions with various hardware components. This involved using a logic analyzer to capture bus activity and painstakingly decoding the assembly code. Ultimately, they were able to create a disassembled listing of the SROM and gain a deep understanding of its functionality, including the system's initial boot sequence and setup of key hardware like the interrupt controller and memory controller. This effort allows for greater understanding and potential modification of the early boot process on this vintage Alpha system.
Hacker News users discuss the blog post about an AlphaStation's SROM, focusing primarily on the intricacies and nostalgia of older hardware. Several commenters reminisce about working with AlphaStations and DEC hardware, sharing personal anecdotes about their experiences with these systems. Some delve into the technical details of the SROM, including its functionality and the challenges involved in working with it. Others appreciate the author's dedication to preserving and documenting these older machines. A few commenters express interest in similar exploration of other vintage hardware. The general sentiment is one of appreciation for the blog post and its contribution to preserving computer history.
Retro Boy is a simple Game Boy emulator written in Rust and compiled to WebAssembly, allowing it to run directly in a web browser. It features a basic but functional graphical user interface and supports sound, offering a playable experience for a selection of ROMs. While not aiming for perfect accuracy or advanced features, it focuses on clean code and serves as a learning project showcasing Rust and WebAssembly for emulation.
Hacker News users generally praised the Retro Boy emulator for its clean Rust implementation and WebAssembly deployment. Several commenters appreciated the project's simplicity and educational value, seeing it as a good starting point for learning emulator development or Rust. Some discussed performance aspects of WebAssembly and the challenges of accurate emulation. A few users compared it favorably to other Game Boy emulators and highlighted the benefits of Rust's safety features for this type of project. Others pointed out the clever use of a single match statement in the CPU emulation code. The developer's engagement in the comments, answering questions and acknowledging feedback, was also positively received.
The author details the process of creating a ZX Spectrum game from scratch, starting with C code for core game logic. This C code was then manually translated into Z80 assembly, a challenging process requiring careful consideration of memory management and hardware limitations. After the assembly code was complete, they created a loading screen and integrated everything into a working .tap file, the standard format for Spectrum games. This involved understanding the intricacies of the Spectrum's tape loading system and manipulating audio frequencies to encode the game data for reliable loading on original hardware. The result was a playable game demonstrating a complete pipeline from high-level language to a functional retro game program.
Hacker News users discuss the impressive feat of converting C code to Z80 assembly and then to a working ZX Spectrum tape. Several commenters praise the author's clear explanation of the process and the clever tricks used to optimize for the Z80's limited resources. Some share nostalgic memories of working with the ZX Spectrum and Z80 assembly, while others delve into technical details like memory management and the challenges of cross-development. A few highlight the educational value of the project, showing the direct connection between high-level languages and the underlying hardware. One compelling comment thread discusses the efficiency of the generated Z80 code compared to hand-written assembly, with differing opinions on whether the compiler's output could be further improved. Another interesting exchange revolves around the practical applications of such a technique today, ranging from embedded systems to retro game development.
Summary of Comments ( 18 )
https://news.ycombinator.com/item?id=44017692
Commenters on Hacker News largely focused on the misleading nature of the article's title. Many pointed out that the ROM was never truly "lost," but simply undocumented and not widely distributed. Some shared personal anecdotes about using KanjiTalk in the past, highlighting its known existence. Others corrected inaccuracies in the article, like the claim about KanjiTalk's limited availability, noting that it was included on System disks. The general sentiment was one of mild amusement at the rediscovery of something not particularly hidden, coupled with appreciation for the author's enthusiasm and effort in exploring this piece of Macintosh history. A few users expressed interest in trying KanjiTalk and exploring its specific quirks and limitations.
The Hacker News post titled "The Lost Japanese ROM of the Macintosh Plus" has generated a moderate discussion with several interesting comments. Many revolve around the complexities of localization in early computing and the challenges of supporting double-byte character sets like Japanese.
One commenter highlights the technical hurdles faced by Apple in adapting the Macintosh for the Japanese market, specifically mentioning the difficulty of fitting Kanji ROMs within the limited memory constraints of the time. They also point out that early localized versions often lacked the polish and functionality of their English counterparts.
Another commenter reminisces about using these early Japanese Macs, recalling the slow performance and limitations of the KanjiTalk operating system. They elaborate on the challenges of inputting Japanese text and the cumbersome nature of early input methods.
A separate thread delves into the history of Japanese computing and the various character encoding standards used. Commenters discuss the transition from JIS to Shift-JIS and the impact these changes had on software development. Someone even shares a personal anecdote about working with early Japanese word processors and the complexities of dealing with different character sets.
Some comments focus on the article itself, praising the author's research and detailed explanation of the ROM's history. Others express excitement about the rediscovery of this piece of computing history and the potential for further research into early Macintosh localization efforts.
A few commenters also discuss the broader context of software preservation and the importance of archiving these historical artifacts. They highlight the challenges of preserving software for obsolete platforms and the value of resources like the Internet Archive in making this history accessible to future generations.
Finally, there's a brief discussion about the legal implications of distributing ROM images and the potential copyright issues surrounding this particular ROM. One commenter clarifies that while distributing copyrighted ROMs is generally illegal, discussing and researching them is typically permitted.