Diagnostic Serial Console
 | This article is currently under constant change. The contents of this page may be innacurate. (22/08/2025) |
The Macintosh Plus, SE and SE/30 feature a built-in diagnostic console accessible via a serial connection, which can be used for detailed hardware troubleshooting. Originally designed for use with specialized Apple diagnostic tools, this diagnostic mode can also be accessed via a standard serial connection using software such as PuTTY or similar serial terminal programs. Adrian Black's spreadsheet on this topic provides the most useful breakdown of how to use the diagnostic console Macintosh Diagnostics / Test Manager
Quick Start Guide
[edit | edit source]For users who want to quickly test their SE/30:
Basic Memory Test
[edit | edit source]*A ; Switch to ASCII mode *S ; Stop banner output *000000000 ; Set start address to 0 *1003FFFFC ; Set end address for 4MB *T000600010001 ; Run Extra RAM Test *R ; Read results (00000000 = pass)
Test Specific Memory Range
[edit | edit source]*A ; ASCII mode *S ; Stop banner *0FE000000 ; Start of video RAM *1FE00FFFC ; End of video RAM *T000200010001 ; Run Mod3 test *R ; Check results
Entering Diagnostic Mode
[edit | edit source]There are several methods to enter diagnostic mode:
Method 1: Interrupt Button (Programmer's Switch)
[edit | edit source]- Power off the SE/30
- Connect serial cable to modem port
- Power on while immediately pressing the interrupt button (programmer's switch)
- Listen for the "chimes of death" - indicates diagnostic mode entry
- Check serial terminal for
*APPLE*output
The programmer's switch is a plastic insert that clips onto the SE/30's case, providing access to two buttons:
- Interrupt button (⎉) - Triggers Non-Maskable Interrupt (NMI) to enter diagnostic mode
- Reset button (◁) - Performs system reset
Method 2: Sad Mac
[edit | edit source]If the system displays a Sad Mac icon at boot with error codes, it automatically enters diagnostic mode. The Sad Mac will display hexadecimal error codes that can be interpreted for troubleshooting.
Method 3: Forced Entry
[edit | edit source]Some hardware failures will automatically trigger diagnostic mode entry. This includes severe memory failures, ROM checksum errors, or critical hardware component failures.
Method 4: Command-Power
[edit | edit source]On SE/30 models without a physical programmer's switch, pressing Command-Power during startup can trigger the same NMI interrupt.
Verification
[edit | edit source]To verify diagnostic mode is active:
- Type
*A- if it echoes back, you're in diagnostic mode - Type
*V- should display ROM version information - Type
*S- stops the continuous*APPLE*banner output
Diagnostic Architecture and Hardware Integration
[edit | edit source]The SE/30 diagnostic interface operates through sophisticated ROM-based routines embedded at address 0x40800000, implementing a comprehensive hardware testing framework that bypasses normal Mac OS operations. The system utilizes the modem serial port for bidirectional communication with diagnostic equipment, enabling direct memory manipulation, register access, and component-level testing through specialized command protocols originally developed for Apple's TechStep professional diagnostic hardware.
The diagnostic ROM routines perform direct 68000 assembly operations using register A6 for return address management during early boot phases when no stack is available. Critical system components,, including the Glue Logic Chip (UI8), F258 RAM multiplexers, and PAL chips (UH7, UI6) participate in diagnostic operations through carefully orchestrated bus control and timing relationships. The 68030 CPU's integrated Memory Management Unit works in conjunction with address decode logic to enable precise hardware validation at the component level.
Serial Communication Protocol
[edit | edit source]The diagnostic interface implements a specialized serial protocol operating at 9600 baud with 8 data bits, no parity, and 2 stop bits, differing from standard Mac OS serial communication, which uses 8-N-1 formatting. Upon entering diagnostic mode, the system outputs an identification string in the format *APPLE*876543210000*1* where the final *1* serves as the machine identifier. This handshake protocol establishes communication between the Mac and diagnostic equipment, with the Mac continuously transmitting status information until commands are received.
Hardware handshaking is disabled in diagnostic mode, and commands may not echo exactly as typed due to the continuous output stream. The relatively slow 9600 baud transfer rate reflects the technological constraints of 1989, though community members have developed two-stage transfer methods to accelerate data uploads for modern applications.
Connecting to the Diagnostic Console
[edit | edit source]Connect your Macintosh to another computer using a serial cable (via the modem port):
- Set your serial terminal (such as PuTTY) to the following:
- Baud Rate: 9600
- Data bits: 8
- Stop bits: 2
- Parity: None
- Once connected, restart your Macintosh while holding the interrupt switch or issuing an interrupt command to enter diagnostic mode.
Commands & Tests
[edit | edit source]Memory Control Commands
[edit | edit source]The diagnostic interface provides direct memory manipulation through specialized commands that enable precise hardware-level testing and validation:
| Command | Function | Technical Implementation |
|---|---|---|
| *L<address> | Set memory location pointer | Establishes base address for subsequent memory operations, address specified in hexadecimal |
| *B<count> | Set byte count for operations | Specifies number of bytes for write operations, read operations ignore this and always return 4 bytes |
| *D | Deposit/write data to memory | Writes specified hexadecimal data to current memory location, respects byte count parameter |
| *M | Memory read command | Reads 4 bytes from current location and auto-increments address pointer, ignores byte count setting |
| *G<address> | Go/execute code at address | Launches code execution at specified memory address for dynamic testing |
| *G | Continue execution | Resumes execution from current program counter location |
| *R | Read/status command | Returns diagnostic status information and memory configuration data |
Additional Diagnostic Commands
[edit | edit source]| Command | Function | Technical Implementation |
|---|---|---|
| *0<address> | Load A0 register | Sets start address for memory tests, loads 32-bit value into D6 then A0 |
| *1<address> | Load A1 register | Sets end address for memory tests, loads 32-bit value into D6 then A1 |
| *A | ASCII mode | Switches to ASCII hexadecimal input mode for command arguments |
| *H | Hex/Binary mode | Switches to binary input mode (default) for command arguments |
| *S | Stop banner | Stops continuous *APPLE* identification string output |
| *V | Version | Displays diagnostic and ROM version information |
| *C | Checksum memory | Calculates checksum of memory at address set by *L for bytes set by *B, result in D6 |
| *4 | Clear result | Clears the result of any previously performed test |
| *5 | Start boot message | Restarts *APPLE* boot message display, commands can still be entered |
| *N<test><count> | Non-critical test | Runs non-critical test with format *NXXYY where XX=test number (hex), YY=repetitions |
| *2 | Cache control | On SE/30, enables instruction cache. On later models, takes 32-bit argument for CACR |
| *3 | Cache off | On SE/30, disables instruction cache. On later models, disables MMU |
| *6 | CPU Reset | Resets the CPU with the reset instruction |
| *7 | Prevent Sleep | Prevents Mac Portable from going to sleep while in Test Mode |
| *P | Power Manager command | Send commands to Power Manager (Portable/PowerBook models) |
| *E | Echo commands | Possibly enables printing of entered command parameters on serial console |
| *I | Restart Test Manager | Restarts Test Manager, will boot if VIA_TEST not asserted and no errors |
Preprogrammed Diagnostic Test Commands
[edit | edit source]| Command | Test Description | Technical Details |
|---|---|---|
*T |
Runs preprogrammed diagnostic tests. Use with specific codes to run targeted tests. | Base command for accessing ROM-based diagnostic routines |
| *T0000 | No operation (null test) | Verifies command interface without hardware interaction |
| *T0001 | Data Bus Test – Tests the 32 data lines (D0-D31) | Writes patterns like 0x00000000, 0xFFFFFFFF, 0xAAAAAAAA, 0x55555555 to verify physical data connections |
| *T0002 | Mod3 RAM Test – Algorithmic memory testing | Performs modulo-3 pattern testing requiring full address space access, fails at 8MB boundary on 4MB systems |
| *T0003 | Address Line Test – Verifies RAM addressing capability | Tests address line integrity using walking bit patterns, verifies each address line can be driven independently |
| *T0004 | ROM Checksum – Verifies ROM integrity | Calculates and verifies ROM checksum, errors indicate corrupted or damaged ROM |
| *T0005 | Reverse Mod3 RAM Test – Inverse algorithmic testing | Reverse pattern of T0002, also fails at 8MB boundary due to address space limitations |
| *T0006 | Extra RAM Test – Extended memory validation | Tests memory beyond base configuration, typically crashes when accessing unmapped address space |
| *T0007 | ModInv RAM Test – Memory inversion pattern testing | Tests memory inversion patterns, typically passes as it stays within smaller address ranges |
| *T0008 | Front Desk Bus Test – Verifies access to Front Desk Bus components | Tests communication with peripheral components |
| *T0009 | NuBus Access Test – Ensures NuBus communication is functional | Validates NuBus slot communication (SE/30 PDS equivalent) |
| *T000A | SCSI Chip Test – Confirms proper operation of SCSI controller | Tests SCSI controller functionality and register access |
| *T000B | IWM Chip Test – Verifies floppy drive controller functionality | Tests Integrated Woz Machine floppy controller |
| *T000C | SCC Chip Test – Tests Serial Communications Controller | Validates serial port hardware operation |
| *T000D | VIA Access Test – Checks VIA chip operation | Tests Versatile Interface Adapter functionality |
Test Execution Times
[edit | edit source]| Test | Approximate Duration | Notes |
|---|---|---|
| *T0001 Data Bus | < 1 second | Nearly instantaneous |
| *T0002 Mod3 RAM | 30 seconds per MB | Full 4MB takes ~2 minutes |
| *T0003 Address Line | 10-20 seconds | Depends on RAM size |
| *T0004 ROM Checksum | 2-5 seconds | Fixed duration |
| *T0006 Extra RAM | 45 seconds per MB | Most thorough test |
Custom Non-Critical Tests
[edit | edit source]Non-critical tests use a different format:
Format: *NXXYY
- XX = Hexadecimal test number
- YY = Number of repetitions
Example: *N8401 runs test 0x84 once.
| Hex Code | Test Description |
|---|---|
| 80 | Video RAM Test – Tests VRAM operation (Macintosh II). |
| 81 | Video Interface Test – Checks functionality of video hardware interface. |
| 82 | VIA Test – Comprehensive VIA chips test. |
| 83 | SCSI General Test – Tests general SCSI functionality. |
| 84-86 | SCC (Serial Communications Controller) Tests – Checks serial communications. |
| 87 | SCSI General Test – General SCSI device communication test. |
| 88 | Sound Test – Verifies audio hardware function. |
Memory Read/Write Behavior Analysis
[edit | edit source]The diagnostic interface exhibits specific behavior patterns that reveal the underlying hardware architecture. When writing data patterns longer than 4 bytes, the system requires multiple *M commands to read back complete data sets. Each *M command returns exactly 4 bytes and automatically increments the address pointer by 4 bytes, creating an auto-incrementing memory dump capability that ignores the *B byte count parameter during read operations.
For example, writing 8 bytes using *L00000000, *B0008, *D1122334455667788 followed by *L00000000, *M returns 11223344 (bytes 0-3), while a subsequent *M returns 55667788 (bytes 4-7). This design reflects the 68030's native 32-bit word size and provides efficient memory dumping without manual address specification.
Common Error Codes and Solutions
[edit | edit source]| Error Pattern | Likely Cause | Solution |
|---|---|---|
FFFFFFFF0005 |
Memory addressing beyond physical RAM | Normal if testing beyond installed RAM |
00080000xxxx |
Bit 3 stuck high in second byte | Check SIMM in corresponding slot, clean contacts |
0000FFFF000E |
Only slots 1-2 populated | Install SIMMs in all 4 slots of Bank A |
Continuous *APPLE* output |
Normal diagnostic mode entry | Type *S to stop banner |
| No response to commands | Not in diagnostic mode | Ensure proper entry via interrupt button at boot |
? response |
Invalid command or unsupported on SE/30 | Check command syntax and SE/30 compatibility |
0F000D |
NMI button pressed during boot | Normal indication of interrupt button activation |
0000000E 000000FF |
Bad PRAM battery or memory issue | Replace PRAM battery, check SIMM seating |
Sad Mac Error Codes
[edit | edit source]When a Sad Mac appears, it displays error codes in hexadecimal format:
- Class Code (First 2 digits): Identifies the diagnostic test or CPU exception that failed
- Subcode (Last 4-6 digits): Gives specific details about the error
Common SE/30 Sad Mac patterns:
0000000F: Reserved for user interrupt (NMI button)00000001: Bus error00000002: Address error00000003: Illegal instruction- Memory test failures show affected SIMM slot numbers in subcode
Memory Architecture and Address Mapping
[edit | edit source]The SE/30 employs 8 × 30-pin SIMM slots organized in a dual-bank architecture that directly affects memory addressing and diagnostic behavior. Bank A consists of the front 4 slots closest to the motherboard edge and must be populated first, while Bank B contains the rear 4 slots behind Bank A and remains optional unless installing more than 4MB RAM. The 32-bit data bus requires 4 SIMMs per bank for full width operation, with memory interleaving supported when using matched SIMMs for improved performance.
Critical configuration rules mandate that all 4 SIMMs within a bank must match capacity and speed (120ns minimum), while banks can have different capacities provided individual bank SIMMs match. A notable exception exists for the 17MB configuration using 256KB SIMMs in Bank A plus 4MB SIMMs in Bank B, which optimizes 1MB video memory allocation. For large capacity installations, the general rule places smaller SIMMs in Bank A and larger SIMMs in Bank B.
Address Space Organization
[edit | edit source]The standard SE/30 memory map allocates System RAM from 0x000000-0x3FFFFF (first 4MB base), with 1MB reserved from the system RAM pool for video memory. ROM Space occupies 0x400000-0x4FFFFF, I/O Space spans 0x500000-0xEFFFFF, and Slot Space extends from 0xF900000-0xFEFFFFFF when operating in 32-bit addressing mode. The Glue Logic chip (UI8) controls address decoding through specialized logic working with F258 RAM multiplexers above the ROM slot, with address translation occurring through the 68030's Memory Management Unit.
Address wrapping and mirroring behavior occurs when SIMM slots are partially populated, causing incomplete address decoding where upper address bits become ignored. Address wraparound manifests when accessing beyond physical memory limits, creating specific bit patterns based on which exact address lines are affected. The system wraps to lower addresses when accessing beyond available memory, with the video controller expecting continuous address space that produces visible patterns when address decode fails.
Memory Testing Algorithms and Diagnostic Procedures
[edit | edit source]Automatic Memory Detection and Configuration
[edit | edit source]During Power-On Self Test (POST), the Glue Logic (UI8) initiates system reset and address decode validation while the 68030 CPU performs basic memory access at reset vectors. The memory controller validates SIMM presence and configuration, followed by System ROM execution of built-in diagnostic routines and video memory allocation reserving 1MB from the available RAM pool. Bank detection and validation occurs automatically for installed SIMM configuration, with memory allocation optimization based on available modules and address bus integrity testing through POST sequences.
The diagnostic system reports memory configuration through hexadecimal codes that reflect addressing architecture. A typical 4MB configuration produces the diagnostic code 004000000000, where the significant portion 00400 converts to 4,194,304 bytes (exactly 4MB). The trailing zeros 0000000000 likely represent diagnostic status information, error flags, or formatting padding used by Apple's diagnostic tools rather than additional memory size data.
Manual Memory Testing Command Sequences
[edit | edit source]Pattern testing algorithms include Walking Ones Tests using the 32-bit sequence 0x00000001, 0x00000002, 0x00000004, 0x00000008, continuing through all 32 bit positions to 0x40000000, 0x80000000, designed to detect stuck address bits and adjacent bit interference. Walking Zeros Tests employ the inverse pattern sequence 0xFFFFFFFE, 0xFFFFFFFD, 0xFFFFFFFB, 0xFFFFFFF7, continuing through all inverse positions to 0xBFFFFFFF, 0x7FFFFFFF, identifying stuck-at-one faults and coupling issues.
The March C- Algorithm implementation follows these steps: initialize all memory locations with 0s, read 0 and write 1 in ascending address order, read 1 and write 0 in ascending address order, read 0 and write 1 in descending address order, read 1 and write 0 in descending address order, and conclude with read 0 verification pass in descending addresses. This comprehensive algorithm detects various memory cell failure modes including data retention, coupling effects, and address decode problems.
Diagnostic Error Analysis and Hardware Troubleshooting
[edit | edit source]Memory Configuration Detection Patterns
[edit | edit source]The diagnostic system provides precise SIMM slot detection through specialized response codes that accurately reflect physical memory installation. When testing partial SIMM configurations, the *R command returns specific patterns indicating slot population status. With 1MB SIMMs installed in slots 1 and 2 only, the system reports 0000FFFF000E, while installation in slots 3 and 4 only produces FFFF000000E. These codes provide immediate verification of physical SIMM installation and can diagnose installation errors or socket problems.
Memory addressing behavior reveals precise hardware functionality when writing test patterns to address 0x00000000. With 1MB SIMMs in slots 1 and 2 only, writing the pattern 11223344 reads back xxxx3344, indicating that slots 1-2 correspond to the lower 16 bits of the 32-bit data bus. Moving the SIMMs to slots 3 and 4 results in reading back 1122xxxx, confirming that slots 3-4 handle the upper 16 bits. This demonstrates that the diagnostic interface can access each SIMM slot independently and reveals the precise relationship between physical slot positions and data bus bit assignments.
Address Boundary and Wrapping Analysis
[edit | edit source]Diagnostic testing reveals specific address boundary behavior that differs from normal operational limits. The system consistently reports end address 1003FFFC for 4MB configurations, where the prefix 10 indicates diagnostic metadata while 03FFFC represents the actual end address at 4MB (0x400000 - 4 = 0x3FFFC). This confirms accurate memory size detection for installed configurations.
However, algorithmic memory tests (T0002, T0005, T0006) consistently fail at address 800000 (8MB boundary) even when testing smaller ranges such as 64KB (0xFFFF). This indicates that these diagnostic routines are hardcoded to test up to 8MB address space regardless of installed memory or specified test parameters. The external addressing test failure (error code 0005) occurs because the diagnostic attempts to access the 8MB boundary when only 4MB is physically installed, representing normal diagnostic behavior rather than hardware failure.
Hardware Failure Mode Identification
[edit | edit source]Specific hardware failures produce characteristic diagnostic patterns that enable precise component identification. Data line failures manifest as consistent bit patterns in memory read operations, such as data line D3 constantly toggling while the system is idle, indicating signal integrity problems including floating data lines, bad buffer/driver ICs, power supply noise, PCB trace issues, clock crosstalk, or defective SIMM output drivers.
When algorithmic memory tests write 0xFF patterns successfully but fail when writing 0x00 patterns, reading back values like 00080000 instead of 00000000, this indicates a stuck bit failure where specific bits can be pulled high but cannot be driven low. The second byte stuck at 0x08 suggests bit 3 failure in that data path, potentially caused by a specific SIMM with failing memory cells, buffer IC problems, socket contact issues, or motherboard trace failures.
Response Code Interpretation
[edit | edit source]The console returns hexadecimal response codes that provide detailed diagnostic information:
| Response Code | Meaning | Technical Interpretation |
|---|---|---|
004000000000 |
4MB memory detected | 00400 = 4,194,304 bytes, trailing zeros = diagnostic metadata |
0000FFFF000E |
Slots 1-2 populated | Bit pattern indicating SIMM presence in Bank A front positions |
FFFF000000E |
Slots 3-4 populated | Bit pattern indicating SIMM presence in Bank A rear positions |
000000800000*R |
8MB boundary access error | Attempt to access unmapped 8MB address space during testing |
FFFFFFFF0005*R |
External addressing test failed | Error code 0005 indicates addressing capability beyond installed memory |
| 0F000D | NMI button pressed during boot | Normal indication of interrupt button activation |
Systematic Diagnostic Procedures
[edit | edit source]Comprehensive hardware validation requires systematic testing approaches that isolate specific failure modes. Individual bank isolation testing involves removing all SIMMs from Bank B, booting with Bank A only using 4 matched SIMMs, running comprehensive memory test suites, and documenting failures with specific SIMM slot positions. Bank B testing requires moving known-good SIMMs to Bank B positions, using diagnostic software for Bank B specific testing, and cross-referencing failures with physical SIMM locations.
For suspected SIMM failures, systematic replacement involves testing each SIMM individually in a known-good slot position, swapping SIMMs between slots to determine if failures follow specific memory modules or remain at fixed memory addresses, and using multiple test patterns to verify intermittent failures. Socket and motherboard issues require testing with known-good SIMMs to isolate socket problems, visual inspection of SIMM socket contacts for corrosion or damage, and verification of power delivery to each socket position.
RAM Chip Identification (Subcode Explanation)
[edit | edit source]For memory tests, subcodes identify specific faulty chips:
| Data Bit | Chip Location | Subcode Bits (Hexadecimal) |
|---|---|---|
| 0 | F5 | 0001 |
| 1 | F6 | 0002 |
| 2 | F7 | 0004 |
| 3 | F8 | 0008 |
| 4 | F9 | 0010 |
| 5 | F10 | 0020 |
| 6 | F11 | 0040 |
| 7 | F12 | 0080 |
| 8 | G5 | 0100 |
| 9 | G6 | 0200 |
| 10 | G7 | 0400 |
| 11 | G8 | 0800 |
| 12 | G9 | 1000 |
| 13 | G10 | 2000 |
| 14 | G11 | 4000 |
| 15 | G12 | 8000 |
Apple TechStep Professional Integration
[edit | edit source]Hardware Architecture and ROM Cartridge System
[edit | edit source]The Apple TechStep diagnostic tool, released in 1991 for $999 exclusively to authorized Apple dealers and service centers, represents the professional implementation of the SE/30's diagnostic capabilities. The TechStep features a specialized hardware architecture built around a Motorola 68HC11 8-bit microcontroller with a 4-line by 16-character LCD display and 15-key keypad. The system includes comprehensive connectivity with two ADB ports, two mini DIN-8 serial ports, SCSI, and stereo audio connections, enabling complete system diagnosis without requiring functional Mac hardware.
The TechStep employs a modular ROM cartridge system similar to Game Boy cartridges, with the device capable of holding two ROM cartridges simultaneously in slots A and B. Each ROM cartridge contains test routines for specific Macintosh computer families, with the sticker on each ROM listing compatible models. The ROM cartridges use either AM27C512 (64KB) or 27C1000QC (128KB) 28-pin PLCC chips, with different ROM revisions requiring specific chip types due to pinout differences.
ROM Cartridge Specifications and Content
[edit | edit source]The documented TechStep ROM cartridges include:
ROM Pack 661-0150: CPU Tests Vol. 1 v1.01 supporting Classic, SE, SE/30, II, IIx, IIcx models. This cartridge contains comprehensive logic board testing routines specifically designed for 68000 and early 68030-based systems.
ROM Pack 661-0157: SCSI HD Tests v1.0 providing specialized testing for Apple SCSI drives with detailed controller validation and media verification routines.
ROM Pack 661-0147: CPU Tests Vol. 2 v1.0 supporting LC, LC II, Classic II models with testing routines optimized for cost-reduced Mac architectures.
ROM Pack 661-0148: CPU Tests Vol. 3 v1.0 covering IIci, IIsi, IIvi, IIvx, Performa 600 models with advanced testing for 68030 systems with integrated video and memory controllers.
Community preservation efforts have successfully archived most TechStep ROM images, enabling reproduction of cartridges using modern EPROM programmers. The reproduction process requires careful attention to chip selection, as larger ROM files designed for 27C1000 chips cannot be directly substituted into sockets designed for 27C512 chips due to pinout differences.
Professional Diagnostic Procedures
[edit | edit source]The TechStep implements sophisticated diagnostic sequences through its ROM-based test suites. MacTest Logic I performs hardware component verification without loopback connectors, while MacTest Logic II provides RAM-specific testing with configurable duration parameters. Short RAM Tests execute for 3 minutes per 512K of installed memory, while Long RAM Tests extend to 6 minutes per 512K for comprehensive validation. Continuous Testing mode enables automated detection of intermittent problems through extended operation cycles.
The TechStep's diagnostic interface integrates directly with the Mac's serial diagnostic capabilities, utilizing the same 9600 baud communication protocol and command structure documented for manual terminal access. However, the TechStep provides automated test sequence execution, result logging, and professional report generation through its dedicated hardware interface rather than requiring manual command entry.
Modern Reproduction and Community Projects
[edit | edit source]Contemporary vintage computing enthusiasts have developed sophisticated reproduction capabilities for TechStep cartridges and complete TechStep hardware. Community projects on platforms such as TinkerDifferent and 68kMLA provide comprehensive build guides, gerber files for PCB reproduction, and archived ROM images for all documented cartridge types. Modern reproduction efforts have successfully reverse-engineered the cartridge connector specifications and developed compatible PCB designs for custom ROM cartridge creation.
The TechStep's internal architecture includes notable components such as a Motorola 68HC11 microcontroller (often mislabeled as 68882 FPU due to sticker placement), HM62256 32kB static RAM, and a 68HC24FN microcontroller evolution of the HC05 series used in EGRET implementations. The absence of custom chip markings suggests Apple used standard commercial components without hardware security measures, facilitating modern reproduction efforts.
Diagnostic Interface Programming and Implementation
[edit | edit source]ROM-Based Diagnostic Code Architecture
[edit | edit source]The SE/30's diagnostic capabilities are implemented through sophisticated 68000 assembly language routines embedded within the system ROM at address 0x40800000. These diagnostic routines operate independently of Mac OS, providing direct hardware access and component-level testing through carefully structured assembly code that bypasses normal operating system abstractions.
Boot Sequence and Diagnostic Entry Points (from ROM disassembly projects):
; SE/30 ROM Boot Vector Table (typical structure)
ORG $40800000 ; ROM base address
DC.L $40810000 ; Initial stack pointer
DC.L BOOT_START ; Initial program counter
DC.L BUS_ERROR_HANDLER ; Bus error vector
DC.L ADDR_ERROR_HANDLER; Address error vector
; ... additional vectors
BOOT_START:
; Disable interrupts and initialize CPU state
ORI.W #$0700,SR ; Disable all interrupts
MOVE.L #$40810000,A7 ; Set stack pointer
; Test ROM checksum first
BSR ROM_CHECKSUM_TEST
TST.L D0
BNE ROM_FAILURE
; Initialize diagnostic state
MOVE.L #DIAGNOSTIC_VARS,A6 ; Base pointer for diagnostic variables
CLR.L ERROR_CODE(A6) ; Clear error accumulator
; Begin hardware initialization sequence
BSR INIT_VIA_CHIPS
BSR INIT_SCC_SERIAL
BSR INIT_MEMORY_CONTROLLER
; Start memory testing if in diagnostic mode
BTST #DIAG_MODE_BIT,SYSTEM_FLAGS
BNE DIAGNOSTIC_MAIN
; Normal boot continues here...
BRA NORMAL_BOOT_SEQUENCE
Serial Diagnostic Interface Handler:
DIAGNOSTIC_SERIAL_HANDLER:
; Check for incoming serial command
MOVE.B SCC_STATUS,D0 ; Read SCC status register
BTST #RX_READY_BIT,D0 ; Check receive ready
BEQ.S CHECK_OUTPUT ; No input, check output
; Read command character
MOVE.B SCC_DATA,D0 ; Get character from SCC
CMPI.B #'*',D0 ; Check for command prefix
BNE.S STORE_DATA ; Not command, store as data
; Process diagnostic command
BSR READ_COMMAND_STRING
BSR PARSE_DIAGNOSTIC_CMD
BSR EXECUTE_DIAGNOSTIC
BRA.S SEND_RESPONSE
STORE_DATA:
; Store data for memory operations
MOVE.L CURRENT_DATA_PTR(A6),A0
MOVE.B D0,(A0)+
MOVE.L A0,CURRENT_DATA_PTR(A6)
RTS
CHECK_OUTPUT:
; Check if we need to send data
TST.B OUTPUT_PENDING(A6)
BEQ.S HANDLER_EXIT
BSR SEND_DIAGNOSTIC_DATA
HANDLER_EXIT:
RTS
Diagnostic Command Parser:
PARSE_DIAGNOSTIC_CMD:
; Input: Command string in buffer pointed to by A0
; Parse command type (*T, *L, *D, *M, etc.)
MOVE.B 1(A0),D0 ; Get command character after '*'
CMPI.B #'T',D0 ; Test command?
BEQ HANDLE_TEST_CMD
CMPI.B #'L',D0 ; Location set command?
BEQ HANDLE_LOCATION_CMD
CMPI.B #'D',D0 ; Data deposit command?
BEQ HANDLE_DEPOSIT_CMD
CMPI.B #'M',D0 ; Memory read command?
BEQ HANDLE_MEMORY_READ
CMPI.B #'G',D0 ; Go/execute command?
BEQ HANDLE_EXECUTE_CMD
; Unknown command
MOVE.L #CMD_ERROR,RESPONSE_PTR(A6)
RTS
HANDLE_TEST_CMD:
; Parse test number (*T0001, *T0002, etc.)
ADDQ.L #2,A0 ; Skip "*T"
BSR PARSE_HEX_NUMBER ; Parse test number into D0
MOVE.L D0,TEST_NUMBER(A6)
; Dispatch to appropriate test
CMPI.L #$0001,D0
BEQ DATA_BUS_TEST
CMPI.L #$0002,D0
BEQ MOD3_RAM_TEST
CMPI.L #$0003,D0
BEQ ADDRESS_LINE_TEST
; ... additional test dispatches
RTS
The diagnostic ROM implementation utilizes direct register manipulation and bus control to achieve precise hardware validation impossible through higher-level software interfaces. Memory allocation operates through direct address specification rather than dynamic allocation, with the system using register A6 for return address management during early boot phases when no stack is available. Critical timing relationships are maintained through carefully calculated instruction cycles and NOPs to ensure proper hardware setup and response timing.
Assembly Language Implementation Details
[edit | edit source]The diagnostic interface implements memory testing algorithms through sophisticated 68000 assembly routines that directly manipulate memory controller hardware. Based on ROM disassembly projects and vintage computing research, the implementation follows structured patterns typical of professional diagnostic code from Apple's era.
Memory Test Loop Structure (typical implementation):
MEMTEST_LOOP:
MOVE.L #$00000000,A0 ; Initialize base address pointer
MOVE.L #$003FFFFC,A1 ; Set end address (4MB boundary)
MOVEQ #$55,D0 ; Load test pattern (0x55555555)
LSL.L #8,D0
OR.L #$55,D0
LSL.L #8,D0
OR.L #$55,D0
LSL.L #8,D0
OR.L #$55,D0 ; D0 now contains $55555555
WRITE_PHASE:
MOVE.L D0,(A0)+ ; Write pattern to memory, increment pointer
CMPA.L A1,A0 ; Compare current with end address
BLS.S WRITE_PHASE ; Continue if not at end
MOVE.L #$00000000,A0 ; Reset to base address
READ_PHASE:
MOVE.L (A0)+,D1 ; Read memory value, increment pointer
CMP.L D0,D1 ; Compare with expected pattern
BNE.S MEMORY_ERROR ; Branch if mismatch found
CMPA.L A1,A0 ; Check if at end
BLS.S READ_PHASE ; Continue if not at end
RTS ; Return if test passed
MEMORY_ERROR:
SUBA.L #4,A0 ; Back up to failing address
MOVE.L A0,D2 ; Store error address
MOVE.L D1,D3 ; Store read value
EOR.L D0,D3 ; XOR with expected (shows differing bits)
RTS ; Return with error information
Walking Bit Pattern Test Implementation:
WALKING_ONES_TEST:
MOVE.L #$00000000,A0 ; Base memory address
MOVEQ #31,D7 ; Loop counter (32 bit positions)
MOVEQ #1,D0 ; Initial walking bit pattern
WALK_LOOP:
MOVE.L D0,(A0) ; Write pattern to memory
MOVE.L (A0),D1 ; Read back immediately
CMP.L D0,D1 ; Compare written vs read
BNE.S BIT_ERROR ; Branch if mismatch
LSL.L #1,D0 ; Shift bit left for next position
DBRA D7,WALK_LOOP ; Decrement and branch if not done
RTS ; Return success
BIT_ERROR:
MOVE.L D0,D2 ; Store failing pattern
MOVE.L D1,D3 ; Store read value
RTS ; Return with error data
Error Code Generation Routine:
GENERATE_ERROR_CODE:
MOVE.L D2,D0 ; Error address in D2
LSR.L #8,D0 ; Shift to get upper bits
LSR.L #8,D0
ANDI.L #$0000FFFF,D0 ; Mask to 16 bits
MOVE.W D0,ERROR_HI ; Store high word of error code
MOVE.L D3,D0 ; Failing data pattern in D3
ANDI.L #$0000FFFF,D0 ; Mask to 16 bits
MOVE.W D0,ERROR_LO ; Store low word of error code
OR.L #$FFFF0000,D0 ; Set error flag bits
MOVE.L D0,DIAGNOSTIC_RESULT ; Store complete diagnostic code
RTS
Address decode testing routines utilize the 68030's addressing capabilities to systematically validate memory controller functionality across the complete address space. The implementation includes specialized routines for bank switching validation, address line testing through walking bit patterns, and data bus integrity verification through structured pattern testing. Error reporting utilizes hexadecimal encoding for compact representation of complex diagnostic states.
March Algorithm Implementation (based on community diagnostic ROM projects):
MARCH_C_MINUS_TEST:
; Step 1: Initialize all memory with 0s (ascending)
MOVE.L #MEMORY_BASE,A0
MOVE.L #MEMORY_END,A1
MOVEQ #0,D0
INIT_LOOP:
MOVE.L D0,(A0)+
CMPA.L A1,A0
BLS.S INIT_LOOP
; Step 2: Read 0, Write 1 (ascending)
MOVE.L #MEMORY_BASE,A0
MOVEQ #-1,D1 ; $FFFFFFFF pattern
STEP2_LOOP:
MOVE.L (A0),D2 ; Read current value
TST.L D2 ; Should be 0
BNE.S MARCH_ERROR ; Error if not 0
MOVE.L D1,(A0)+ ; Write 1s pattern
CMPA.L A1,A0
BLS.S STEP2_LOOP
; Step 3: Read 1, Write 0 (ascending)
MOVE.L #MEMORY_BASE,A0
STEP3_LOOP:
MOVE.L (A0),D2 ; Read current value
CMP.L D1,D2 ; Should be all 1s
BNE.S MARCH_ERROR ; Error if not 1s
MOVE.L D0,(A0)+ ; Write 0s pattern
CMPA.L A1,A0
BLS.S STEP3_LOOP
RTS ; Test passed
MARCH_ERROR:
SUBA.L #4,A0 ; Back up to error address
MOVE.L A0,D4 ; Store error location
MOVE.L D2,D5 ; Store unexpected value
RTS ; Return with error info
Integration with Hardware Testing Tools
[edit | edit source]The diagnostic ROM includes interfaces for professional testing equipment through specialized communication protocols implemented in assembly language. TechStep integration occurs through standardized command sequences that enable automated test execution and result retrieval. The ROM-based diagnostic routines provide programmatic interfaces for external test equipment to control test parameters, execute specific diagnostic sequences, and retrieve detailed results for professional analysis.
Modern disassembly efforts using tools such as FDisasm and resource_dasm have revealed the internal structure of these diagnostic routines, enabling detailed analysis of Apple's testing methodologies and hardware validation approaches. Community projects have successfully reverse-engineered significant portions of the diagnostic ROM code, providing insights into Apple's systematic approach to hardware validation and failure mode detection.
Diagnostic Code Modification and Enhancement
[edit | edit source]The diagnostic ROM's assembly language implementation enables sophisticated modifications for enhanced diagnostic capabilities. Community projects have demonstrated the feasibility of creating custom diagnostic ROMs with enhanced error reporting, additional test patterns, and improved hardware identification capabilities. ROM modification techniques utilizing tools such as the ROM-inator II enable deployment of enhanced diagnostic capabilities while maintaining compatibility with original hardware.
Custom diagnostic implementations can extend the original testing algorithms with modern understanding of hardware failure modes, providing enhanced detection of intermittent failures and aging-related issues common in vintage hardware. Modified diagnostic ROMs can implement custom beep codes for specific failure conditions, enabling more precise hardware fault identification during repair procedures.
Advanced Diagnostic Examples
[edit | edit source]Complete Memory Testing Procedure
[edit | edit source]Here is an example of testing 4MB of memory using the comprehensive diagnostic interface:
*A *R *4 *3 *000000000 *0003FFFFC *T000600010001
Once the system returns *T, issue the read command:
*R
The system should return all 0s if memory is functioning correctly. Any non-zero values indicate specific bit failures that can be correlated with the RAM chip identification table to pinpoint faulty components.
Memory Boundary Testing Sequence
[edit | edit source]To systematically test memory boundaries and address decode logic:
*L00000000 ; Set address to start of memory *B00000004 ; Set 4-byte operation *D12345678 ; Write test pattern *L00000000 ; Reset to start address *M ; Read back pattern (should return 12345678) *L00100000 ; Test 1MB boundary *B00000004 *DDEADBEEF ; Write different pattern *L00100000 *M ; Read back (should return DEADBEEF) *L00400000 ; Test 4MB boundary (may fail on 4MB systems) *B00000004 *DCAFEBABE *L00400000 *M ; May return error or wrap to beginning
This sequence systematically tests address decode functionality and identifies the exact point where address wrapping or failures occur, providing precise information about memory controller limitations and installed memory boundaries.
Important Notes
[edit | edit source]- Not all diagnostic tests work on every model; compatibility varies with ROM version.
- SE/30 and other 256k ROM Macs do not support certain diagnostic commands listed here.
- There is NO overflow protection when testing memory. If you attempt to address memory space beyond what is installed, the system will write to and read from wrapped memory locations, typically the first byte of memory. This is normal opperation and actually how the system calculates the RAM capacity.
- If you are testing with any 1MB installed, the memory won't overflow. This can be an issue if you're testing RAM manually.
- if you enter diag mode via NMI button, the Identify (5) will report 000001300F, so won't tell you RAM size, but if you ask for RAM size (T000000010001) then it works and subsequent Indentify (*5) calls work again.
- Algorithmic memory tests (T0002, T0005, T0006) are hardcoded to test 8MB address space and will fail on systems with less memory installed. This represents normal diagnostic behavior, not hardware failure.
- The diagnostic interface operates independently of Mac OS memory management and can access hardware directly, enabling component-level troubleshooting impossible through normal software methods.
- Modern reproduction boards such as the SE/30 Reloaded may exhibit identical diagnostic behavior to original Apple hardware, confirming that diagnostic failures often represent normal responses to hardware limitations rather than board-specific issues.
- The "Simasimac" pattern (vertical stripes at startup) is a common SE/30 issue often caused by leaking capacitors on the logic board causing circuit corrosion.