Stories with Tag Bootloader

• The DOS 3.3 Sys.com Bug Hunt

  permalink

  Posted: 2025-02-24 00:01:53

  Verbose tl;dr

  The author meticulously debugged a mysterious issue where transferring Apple DOS 3.3 system files to a blank diskette sometimes resulted in a bootable disk, and sometimes a non-bootable one, despite seemingly identical procedures. Through painstaking analysis of the DOS 3.3 source code and assembly-level debugging, they discovered the culprit: a timing-sensitive bug within the SYS.COM program related to how it handled track zero formatting. Specifically, SYS.COM occasionally failed to wait for the drive head to settle after seeking to track zero before writing, resulting in corrupted data on the disk. This timing issue was sensitive to drive mechanics and environmental factors, explaining the intermittent nature of the problem. The author's fix involved adding a small delay within SYS.COM to ensure the drive head had stabilized before writing, resolving the frustrating bug and guaranteeing consistent creation of bootable disks.

  This blog post by Eric Brutman recounts a fascinating deep dive into the inner workings of Apple DOS 3.3's SYS.COM utility, a program designed to make a disk bootable. The author sets the scene by describing the seemingly simple task of transferring SYS.COM to a newly formatted disk, a process which unexpectedly failed when attempted on an Apple IIe. This anomaly sparked a multi-faceted investigation into the precise mechanics of the utility and the underlying reasons for its failure.

  Brutman begins by meticulously outlining the expected behavior of SYS.COM. It should copy specific sectors containing the boot loader and DOS kernel from itself to the target disk, making it bootable. He leverages a disk imaging tool to analyze the contents of both a known working boot disk and the malfunctioning disk created on the Apple IIe. This comparative analysis reveals a critical difference: a single byte discrepancy in the boot sector of the problematic disk. This tiny error, a value of 00 where 03 was expected, effectively rendered the disk unbootable.

  The quest to pinpoint the root cause of this byte corruption takes Brutman down a rabbit hole of assembly code analysis. He painstakingly disassembles the SYS.COM utility, scrutinizing every instruction related to the writing of the boot sector. The investigation leads him to a section of code responsible for moving data from memory to a specific location on the disk, a process involving the Apple II's sophisticated memory addressing modes. Specifically, the bug is traced to an indirect indexed addressing mode instruction interacting with zero page usage and a subtle side effect related to how the code handles track sector lists. This particular instruction, designed to calculate the memory address for the next sector to be written, inadvertently modifies a zero page location used by the disk write routine, ultimately corrupting the crucial byte in the boot sector.

  Brutman further clarifies that this bug manifests only on the Apple IIe, a machine with a slightly different memory map compared to its predecessors. He pinpoints the root cause to a hardware change: the relocation of the firmware involved in disk I/O operations to a different memory address. This shift, coupled with the specific way SYS.COM was written, creates the unforeseen side effect that corrupts the boot sector.

  The post concludes with a proposed solution: a patched version of SYS.COM that circumvents the problematic instruction by using a less ambiguous addressing mode. This corrected version successfully creates bootable disks on the Apple IIe, resolving the initial mystery. Brutman emphasizes the value of understanding the intricacies of hardware and software interactions, showcasing how even a single byte error can unravel the functionality of a seemingly straightforward utility. The entire investigation stands as a testament to the power of meticulous debugging and the complexities hidden beneath the surface of vintage computing systems.

  • DOS
  • DOS 3.3
  • Apple II
  • Sys.com
  • Bootloader
  • Assembly Language
  • 6502
  • Retrocomputing
  • Debugging
  • Operating Systems
  • software bugs
  • vintage computing

  Summary of Comments ( 5 )
  https://news.ycombinator.com/item?id=43154451

  Verbose tl;dr

  Several Hacker News commenters praised the author's clear and detailed write-up of the bug hunt, appreciating the methodical approach and the insights into early DOS development. Some shared their own experiences with similar bugs and debugging processes in other systems. One commenter pointed out the historical significance of relying on undocumented behavior, a common practice at the time due to limited documentation. Others discussed the challenges of working with older hardware and software, and the satisfaction of successfully solving such intricate problems. The overall sentiment reflects admiration for the detective work involved and nostalgia for the era of simpler, yet more opaque, computing.

  The Hacker News post "The DOS 3.3 Sys.com Bug Hunt" has a modest number of comments, generating a discussion focused primarily on the technical details of the bug and the debugging process.

  Several commenters express admiration for the author's detective work in tracking down the obscure bug. One commenter describes the process as "a fantastic example of really digging into a problem and not giving up until it was solved." Another echoes this sentiment, highlighting the satisfaction derived from "carefully isolating a subtle, difficult to reproduce bug" and emphasizing the methodical approach required in an environment with limited debugging tools.

  The technical discussion delves into the intricacies of the 6502 processor and Apple II disk controller hardware. One comment explains the bug's root cause as an unexpected interaction between interrupt handling, DMA timing, and the specific behavior of the RWTS (Read/Write Track Sector) routine in the DOS code. This comment details how the bug manifested as a race condition that only occurred under very specific circumstances related to track sector reads and the interrupt timing. Another commenter adds further technical depth, explaining how the exact timing of the DMA and interrupt sequence could lead to the corruption of a critical variable used in the DOS file system operations.

  Beyond the technical analysis, some comments reflect on the challenges of debugging in the early days of personal computing. One user recounts personal experiences with similar debugging struggles on the Apple II, emphasizing the patience and creativity required in such resource-constrained environments. Another comment points out the historical context, noting that the availability of source code and detailed hardware documentation, which are taken for granted today, were valuable resources that greatly aided the author's investigation.

  While the majority of comments focus on the technical aspects of the bug, some users share anecdotal experiences related to the Apple II and early DOS versions, contributing to a sense of nostalgia for the early days of personal computing.

• Snowdrop OS – a homebrew operating system from scratch, in assembly language

  permalink

  Posted: 2025-01-24 16:40:11

  Verbose tl;dr

  Snowdrop OS is a hobby operating system written entirely in assembly language for x86-64 processors. The project aims to be a minimal, educational platform showcasing fundamental OS concepts. Currently, it supports booting into 32-bit protected mode, basic memory management with paging, printing to the screen, and keyboard input. The author's goal is to progressively implement more advanced features like multitasking, a filesystem, and eventually user mode, while keeping the code clean and understandable.

  Sebastian Mihai's blog post details his ambitious personal project: building an operating system from the ground up, named Snowdrop OS. He emphasizes that this is a learning exercise, focusing on understanding the fundamental principles of operating system design and low-level programming. The core of Snowdrop OS is written entirely in assembly language, targeting x86-64 architecture, reflecting his desire for deep control and intimate interaction with the hardware.

  The blog post outlines the initial stages of development, starting with the bootloader, which is the very first piece of code executed upon system startup. Mihai explains his bootloader's function, which involves setting up the Global Descriptor Table (GDT) and Interrupt Descriptor Table (IDT), crucial components for protected mode operation and interrupt handling, respectively. He details the painstaking process of manually crafting these tables in assembly, highlighting the challenges and intricacies of working at such a low level. He further elaborates on the process of switching the processor from real mode to protected mode, a critical step in setting up a modern operating system environment. This includes setting up segmentation, a memory management scheme used by x86 processors.

  Mihai then describes implementing a basic keyboard driver, enabling the operating system to receive input from the user. He meticulously explains the mechanism behind keyboard interrupts and how his code intercepts and processes these signals to display typed characters on the screen. This involves interfacing directly with the hardware and understanding the intricacies of scan codes generated by the keyboard.

  The post showcases screenshots of Snowdrop OS in its nascent state, displaying characters typed on the keyboard. This visually demonstrates the functionality achieved thus far. While acknowledging the project's early stage, Mihai outlines his long-term vision for Snowdrop OS. He aspires to gradually add more features, including a more advanced memory manager, support for multiple processes, and eventually a file system. He envisions Snowdrop OS as a platform for continuous learning and exploration of operating system concepts. The blog post concludes with an invitation for others interested in similar endeavors to connect and share their experiences, fostering a sense of community among like-minded individuals. He provides a link to the project's GitHub repository, making the source code openly available for inspection and collaboration.

  • Operating System
  • OS
  • Homebrew
  • Assembly Language
  • Low-Level Programming
  • Kernel Development
  • x86
  • Bootloader
  • Bare Metal
  • Snowdrop OS
  • Custom OS
  • Hobby OS

  Summary of Comments ( 5 )
  https://news.ycombinator.com/item?id=42814820

  Verbose tl;dr

  HN commenters express admiration for the author's dedication and technical achievement in creating an OS from scratch in assembly. Several discuss the challenges and steep learning curve involved in such a project, with some sharing their own experiences with OS development. Some question the practical applications of the OS, given its limited functionality, while others see value in it as a learning exercise. The use of assembly language is a significant point of discussion, with some praising the low-level control it provides and others suggesting higher-level languages would be more efficient for development. The minimalist nature of the OS and its focus on core functionalities are also highlighted. A few commenters offer suggestions for improvements, such as implementing a simple filesystem or exploring different architectures. Overall, the comments reflect a mix of appreciation for the technical feat, curiosity about its purpose, and discussion of the trade-offs involved in such a project.

  The Hacker News post titled "Snowdrop OS – a homebrew operating system from scratch, in assembly language" generated several comments discussing various aspects of the project.

  Many commenters expressed admiration for the author's dedication and the technical achievement of building an OS from scratch, particularly using assembly language. They acknowledged the significant effort and learning involved in such an undertaking. Some saw it as a valuable learning experience, even if the resulting OS isn't practically useful.

  Several comments focused on the choice of assembly language. Some questioned its practicality for a larger project, citing the increased development time and complexity compared to higher-level languages. They discussed the trade-offs between performance and development speed, with some suggesting that C might be a more suitable choice for a project of this scale. However, others defended the use of assembly, emphasizing the low-level control and understanding it provides, which aligns with the author's stated learning goals.

  There was a discussion about the educational value of such projects. Some commenters shared their own experiences with similar endeavors, highlighting the insights gained into computer architecture and operating system principles. They emphasized the importance of hands-on experience for deepening understanding.

  A few commenters delved into technical details, discussing specific aspects of the OS's implementation, such as memory management, interrupt handling, and the choice of bootloader. They offered suggestions for improvements and pointed out potential issues.

  Some comments touched upon the project's potential future development. While acknowledging the current limitations, some commenters expressed interest in seeing the project evolve and gain more features.

  There was a brief discussion about the licensing of the code, with a suggestion to choose a license explicitly.

  Overall, the comments reflect a positive reception to the project, with an appreciation for the effort involved and the educational value of building an OS from scratch. While some questioned the practical implications and the choice of assembly language, the general sentiment was one of encouragement and interest in the author's learning journey.