Additional information requiring reorganization - retrotruestory/M1DEV GitHub Wiki

Construction and Operation

In a nutshell, this computer is built with 5 cards (Double Eurocard format):

ALU/Register: 74LS374, 74F381, 74LS244, 74F382 Control: 5x 27C256 Device: ICs 8255, 16550, boot-ROM, 1.482 MHz Memory: HM628512ALP-7 4M SRAM (512 KWORD X 8 BIT), UM61256FK-15 61256 32K x 8-Bit High Speed SRAM Front Panel

Each card is connected by 2 DIN 41612 (type C, 96-pin) connectors to 2 BUS cards equipped with connectors for linking the cards, acting as a bus connecting signals from all the cards. The entire computer can be powered using any +5V 2A power supply; I use an old ATX 200W computer power supply.

The computer uses two IC 16550s serving as serial ports: one for communication (telnet, for receiving and entering data), and the other (SLIP, Serial Line Internet Protocol - for the computer's communication with the world, such as the Internet).

The microcode is located in high-speed EPROMs like AMD 27C256-55.5V 32kx8, DIP-28, 55ns.

The basic code is located in three places:

1.Bootloader: Code that loads the monitor, operating system, and IDE driver. 2.EPROM/PROM: A set of micro-instructions loaded into the computer's RAM during Magic-1 startup.

Note

I don’t think it would be accurate to say the microcode is loaded into the computer’s RAM. The microcode has no connection with the system’s data and address busses. It is read-only and is used only by the decoding logic.

3.CF/IDE: A set of partitions and the modified version of the Minix 2.0.4 operating system, which the user uses to boot the computer, load the system, and log in to the system operator console.

Tools

The system would not be complete without a set of tools that allow the development of new software for this architecture. In this case, we have two sets of tools: one that can be used, for example, on a laptop equipped with Linux, and the second set of tools available on the Magic-1 computer itself.

ISA (Instruction Set Architecture)

ISA, or Instruction Set Architecture, is part of the abstract model of a computer that defines how the CPU is controlled by the software. The set of instructions is divided into groups (according to their application type). I will describe their functions, such as data type/addressing method and the possibility of combining instructions.



Here’s a detailed explanation of the verified facts regarding the "Magic Architecture" as described in the text:

One-Address Architecture: This means that the architecture uses a single address in its instruction set to specify the operand for operations. In a one-address architecture, instructions typically involve a single memory address, which is used for both the source and destination of data. The operations can be either 8-bit or 16-bit, indicating the size of the data being processed.

Address Space: The architecture provides each process with a virtual address space of up to 128K bytes. This space is organized into 32 pages for data and 32 pages for code, with each page being 2K bytes in size. This organization allows for efficient memory management and access, as the system can easily map these pages into physical memory.

Physical Addressing: The virtual address space is mapped into a physical address space that is 22 bits wide. This means that the architecture can address up to (2^{22}) bytes of physical memory, which is approximately 4MB. When considering device space, it effectively extends to 23 bits, allowing for additional addressing capabilities.

Page Table: Each process has a dedicated page table that consists of 64 entries, with each entry being 16 bits. This page table is crucial for translating virtual addresses to physical addresses, enabling the operating system to manage memory efficiently. The page table is located in dedicated memory, and each process has a base pointer to its own page table.

Memory-Mapped I/O: The architecture employs memory-mapped I/O, meaning that certain memory addresses are reserved for I/O devices. The top 128 bytes of memory are specifically allocated for device control blocks, allowing the CPU to interact with hardware devices as if they were part of the memory space.

Interrupts and DMA: The architecture supports external interrupts and Direct Memory Access (DMA). This means that hardware devices can signal the CPU to interrupt its current operations, allowing for responsive handling of events. DMA allows devices to transfer data directly to and from memory without CPU intervention, improving performance.

Note

I would say the top 128 bytes of the low 64K of device memory. In other words, addresses 0xFF80 through 0xFFFF.

Endianness: The architecture uses big-endian format for data storage, meaning that the most significant byte of a word is stored at the lowest memory address. This affects how multi-byte data types are read from and written to memory.

Addressing Modes: The architecture supports a variety of addressing modes, including register indirect, frame local, global, immediate, push, and pop. These modes provide flexibility in how operands are accessed and manipulated, allowing for more complex data structures and operations.

Atomic Instructions: The architecture includes atomic instructions such as "compare and branch" and "test and branch." These instructions are executed as a single, indivisible operation, which is essential for maintaining data integrity in multi-threaded or interrupt-driven environments.

Note

This statement is basically true, but uses “atomic” in a non-standard way. In most technical literature “atomic operations” are those that do an atomic read/modify/write on memory location. This is what Magic-1’s “ldclr.8 a,(b)” is for. See: https://en.wikipedia.org/wiki/Semaphore_(programming) Incidentally, Magic-1 does have a few instrucitons that are not atomic. Memcopy, for example, can be interrupted. It uses C as a count register and can be interrupted at each byte copy boundary. But, because it’s progress is recorded in register C, it can correctly resume after the interrupt is processed.

Microcode: A significant amount of microcode is utilized in the architecture, with five 512x8-bit Programmable Read-Only Memories (PROMs) dedicated to storing microcode. Microcode is a layer of instructions that translates higher-level machine instructions into sequences of operations that the hardware can execute, allowing for more complex instruction sets and functionalities.

Conclusion

The Magic Architecture is characterized by its one-address design, efficient memory management through paging, and support for various operations and commands. The architecture's use of microcode and atomic instructions enhances its capability to handle complex tasks while maintaining data integrity. The examples of processor commands illustrate how instructions are structured and executed within this architecture.

Here’s a detailed explanation of the additional 20 facts regarding the "Magic Architecture," focusing on the microcode and its implications for the architecture's design and functionality:

  1. Extensive Use of Microcode

The architecture employs microcode extensively, which means that many higher-level instructions are implemented as sequences of lower-level micro-operations. This allows for more complex instructions to be broken down into simpler steps that the hardware can execute.

  1. Non-Orthogonal Opcode Encoding

The architecture uses a non-orthogonal opcode encoding scheme with 8-bit opcodes. This means that not all combinations of opcodes and operands are valid or meaningful, leading to a reliance on microcode to handle the variations and complexities of instruction execution.

  1. Dedicated Microcode Region

There is a specific area in memory designated for microcode, where instructions are further divided into multiple micro-operations. This separation allows for efficient execution and management of complex instructions.

  1. Microcode Instructions for Memory Operations

Microcode instructions include specific operations for reading from or writing to different parts of memory registers. For example, instructions like READLO and WRITEHI indicate operations that target the lower or higher parts of a register, respectively.

  1. Annotated Micro-Operations

Each micro-operation is annotated with specific operations that may apply to registers, such as INC_TO_Z (increment to zero) or DEC_TO_Z (decrement to zero). This level of detail allows for precise control over register states during execution.

Note

In a separate document, I’ll try to explain the microcode a little better. The “INC_TO_Z” and other similar operators are simply macros I defined to make creating the microcode a little easier. It is not very clear, but it probably made sense to me at the time I did it 20 years ago. I will have to spend a little time looking at it myself to remember how it all worked.

  1. Documented Opcodes with Hexadecimal Addresses

Certain opcodes are documented with hexadecimal addresses (e.g., 0x1E0 to 0x1FF), indicating that there are multiple implementations of microinstructions for different opcodes. This allows for flexibility in how instructions are executed based on the context.

  1. Variants of Multi-Word Processing

Commands are labeled with designations like "Mop16," "Mop16a," or "Mop16Carry," which indicate different variants of multi-word processing operations or operations that specifically affect the carry flag in arithmetic operations.

  1. Special Microcode Entries for Error Handling

The microcode includes special entries such as "UNUSABLE" and "Unreachable" to manage error conditions or invalid states. This helps ensure that the system can gracefully handle unexpected situations.

Note

I think the “UNUSABLE” microcode position exists because there is logic in the microcode section of the control card that u ses microcode address 0x1FF for a special condition. Thus, the micocode word at 0x1FF will never be used. I don’t immediately remember the details. There is probably something similar going on with address 0x1FE.

  1. Control Flow Emphasis

Microcode emphasizes control flow, with each instruction concluding with a NEXT directive (e.g., NEXT(FALLTHRU) or NEXT(PCtoMAR)). This defines how control is transferred to the next instruction, ensuring proper sequencing.

Note

I did this because it seemed simpler to me at the time. For many microcoded CPUs, there would exist a special microcode program counter to control execution flow through the microcode. Instead, I simply have each microcode instruction declare which microcode instruction be executed next. This allowed me to not bother with added a microcode PC.

  1. Distinction Between Data Movement and Control Operations

The microcode clearly differentiates between data movement operations (e.g., transferring data from memory to the accumulator) and control operations (e.g., branching to a different instruction). This distinction is crucial for maintaining the integrity of program execution.

  1. Combined Memory Access and Arithmetic Logic

Several operations combine memory access with arithmetic logic, as seen in commands that invoke Arithmetic Logic Unit (ALU) functions (e.g., ALU(OP_IR13, WORD, NO_CARRY)). This allows for efficient execution of complex operations.

  1. Partitioned Use of Registers

The architecture features a clear partitioning of registers, including R_A (the primary accumulator), R_B, and R_C. R_C is often used for branching or condition tests, which helps streamline control flow in programs.

Note

Register C is mostly used as a count register for instructions that repeat, like memcopy and the variable shifts. Otherwise, it is often used as temporary storage. Register B can be through of as the secondary accumulator.

  1. Page Table Design and Addressing Modes

The design of the page table and the addressing modes reflects a balance between hardware simplicity and the requirements of compiler output. This ensures that the architecture can efficiently support a variety of programming languages.

  1. Trade-off in Design for Efficiency

While the original one-address design was straightforward, later additions of additional registers (like B and C) improve efficiency for hand-compiled code and non-optimizing C code generation. This trade-off enhances performance without overly complicating the architecture.

  1. Microcode Scheduling

Microcode schedules indicate that even simple operations may be split across several micro-steps, with each step carefully sequenced. This allows for precise control over the execution timing of operations. 16. Specialized Commands for Atomic Operations

Note

The compare-and-branch instructions exist largely to reduce code size. In most programs, it is extremely common to do a compare, followed by a branch to a nearby location. By combining the compare instruction with the branch instruction we can reduce program size (and make more things fit in our 64K-byte code space).

The use of microcode enables specialized commands for atomic operations, such as "compare and branch" and "test and branch." These commands ensure that operations are executed in a way that maintains data integrity and correct sequencing.

  1. Big-Endian Bit and Byte Ordering

The architecture strictly adheres to big-endian ordering for both bits and bytes. This design choice is not only a technical specification but also a philosophical statement, as it reflects a preference for a certain way of organizing data in memory.

Note

In truth, there is no real advantage to either bit-endian or little-endian. I chose big-endian because of personal preference. And, for what it’s worth, it would not take much effort to change Magic-1 into a little-endian machine. Just a few dozen microcode routines would need to be changed.

  1. Rich Instruction Set

The architecture supports a rich instruction set that allows for a variety of operations, including complex data manipulations and control flow instructions. This richness is facilitated by the microcode structure.

  1. Flexibility in Instruction Execution

The reliance on microcode allows for flexibility in how instructions are executed, enabling the architecture to adapt to different programming paradigms and optimize performance for specific tasks.

  1. Emphasis on Compiler Optimization

The design considerations reflect an emphasis on optimizing the output of compilers, ensuring that the architecture can efficiently execute code generated by high-level programming languages.

These points collectively illustrate the complexity and thoughtfulness behind the Magic Architecture's design, emphasizing its reliance on microcode, the careful structuring of operations, and the balance between simplicity and functionality.

⚠️ **GitHub.com Fallback** ⚠️