Author: gmalasan

Josh added CPU memory accesses, stack operations, and CALL/RET. His tests covered memory delays, reset recovery, and original-8088 stack-pointer behavior, and caught all 16 deliberately introduced faults. Ben refined the design report’s memory/peripheral organization, interfaces, and testing plan. Govind extended EXE loading across the program arena and passed the expanded emulator regression.

Our main risk is CPU/firmware integration: remaining decoder, ALU, and interrupt work could delay BIOS execution. We will start with small diagnostic ROMs, then integrate BIOS services, while software development continues in the emulator. Ben reports his work is on schedule and will resume memory RTL integration next week. The next planned checkpoints are the October 19 FPGA diagnostic and October 26 BIOS/disk test; board-level verification remains pending. This week’s report revisions clarified interfaces without changing the overall architecture.

A was written by Ben Schlossman, B was written by Joshua Smith, and C was written by Govind Malasani.

Part A: Global factors
Our system is intended to help students and hobbyists beyond CMU study and modify a complete computer. Documented interfaces and emulator tests let others explore the design before obtaining an FPGA board. Hardware and tool access remain barriers, so our build instructions should state dependencies and avoid assuming access to a university lab. These access concerns are also identified in UNESCO’s educational-resource guidance.

Part B: Cultural factors
Our project serves the retrocomputing community’s interest in preserving older software and machine behavior. We check original-8088 behavior and document compatibility limits so users can assess which programs may work. We also write our own BIOS/DOS implementation and exclude copyrighted ROMs and game binaries from the repository. This approach reflects UNESCO’s digital-heritage principles, which recognize software’s cultural value alongside creators’ rights.

Part C: Environmental factors
The EPA identifies electronics reuse and recycling as ways to conserve resources and avoid air and water pollution. We plan to keep the FPGA board and peripherals reusable after the project and use existing compatible peripherals where possible. Emulator-based development lets us test software without additional hardware prototypes. System power consumption and lifecycle impacts remain unmeasured.

Progress this week

This week, each part of the project moved further into implementation.

Josh connected the CPU’s instruction fetching and execution so it can run a short program from simulated memory. The program correctly moves and adds values, including when memory takes extra time to respond. He also added short jumps and tested that the CPU discards instructions from the old path when a jump changes where execution continues. He deliberately introduced bugs to check whether the tests caught them and documented the remaining test limitations.

Ben started implementing the memory system, including RAM, BIOS ROM, and the logic that directs each CPU request to the correct location. He also began tests for reading and writing RAM, reading ROM, and accessing the boundaries between memory regions. He and Josh are working through the timing rules for communication between the CPU and memory.

Govind’s software can now start in MartyPC using our own BIOS, bootloader, and C kernel. The kernel can open, read, and close files on a virtual disk, with tests for both successful reads and damaged data.

These are separate milestones. Our CPU has run small test programs in simulation, and our BIOS and kernel have run in MartyPC. We have not yet run the BIOS and kernel on our own CPU or demonstrated the complete system on the FPGA.

Main risks and backup plans

The largest near-term risk is connecting the CPU, memory, and software. Each has been tested separately, but differences in timing or expected behavior could cause failures when they are combined. Josh has written draft rules for CPU-to-memory communication and built checks for them. Ben is testing the memory modules against their expected behavior. The next step is to agree on those rules and connect the pieces using small programs before attempting a full boot. If integration fails, these smaller tests will help locate the problem.

Storage is another important risk. The selected DE10-Standard board’s microSD slot is connected to its ARM processor rather than directly to the FPGA. We therefore still need to settle how the FPGA will access storage. The emulator’s disk remains useful for continuing software development while this is resolved. A possible fallback for early integration is a small test image stored in FPGA memory, although that would not complete the final storage requirement.

The amount of work needed for DOS compatibility is also a risk. File reading works in the emulator, but keyboard input and loading programs are still unfinished. We plan to prioritize a small test program and the services it requires before expanding to more programs.

We also need to improve our code quality/practice. Although AI has been largely beneficial in terms of code development, we are falling behind on reviewing each others code which may be just as important. We hope to keep code review no more than a week behind implementation as well.

Design changes and their cost

The project documentation now identifies the Terasic DE10-Standard as our board. Its microSD wiring creates an additional storage-design decision that must be resolved before hardware integration.

For software testing, our BIOS currently uses the disk controller provided by MartyPC. This allows software work to continue, but the hardware-specific disk code will need to be adapted for our board. Keeping that code separate from the file-reading code limits how much software will need to change.

Schedule and next steps

We are continuing with the proposed schedule without a revision this week. Ben reports that the memory work is on schedule, and the CPU and software work have reached initial testing milestones. Storage access remains an open dependency that could affect later integration.

Next week, Josh plans to review the memory interface with Ben, define how devices will request the CPU’s attention, and add conditional jumps and more arithmetic and logic instructions. Ben plans to finish the initial memory modules and tests, connect them to the CPU interface, and begin device-address selection and storage work. Govind plans to continue keyboard input and program-loading work while reviewing the hardware-facing BIOS code with the team.

Evidence

– [Josh’s CPU progress and tests](https://course.ece.cmu.edu/~ece500/projects/f26-teama1/2026/10/04/joshs-status-report-10-3/)
– [Ben’s memory-system progress](https://course.ece.cmu.edu/~ece500/projects/f26-teama1/2026/10/03/bens-status-report-10-3/)
– [Software implementation and review guide](https://github.com/JoshuaSmith1227/ibm-pcxt-fpga/blob/govind/software-review/docs/software-review.md)

This week, we worked on the design presentation while continuing CPU and memory development. Govind focused on preparing and practicing the presentation and researching the compiler and emulator setup. Ben helped on the slides and refined the CPU/memory interface, RAM and BIOS ROM organization, address decoding, and their test plan. Josh implemented and tested the first connected portion of the CPU datapath.

Josh’s CPU can now execute a short testbench-fed program using MOV and ADD that produces AX = 14. The ALU passed more than 20,000 directed and reference-model checks. Deliberately introducing bugs also helped check the testbenches and exposed an execution-unit coverage gap to fix. The CPU does not yet fetch instructions from memory, so this is an initial datapath milestone rather than a complete processor.

Our biggest risk is integrating the CPU, memory, peripherals, and software on time, so we will agree on shared interfaces early and test small programs before attempting a full boot. If storage is delayed, we can continue testing with preloaded programs while prioritizing disk boot, the shell, and .COM execution over optional features.

MartyPC’s emulated hardware uses different interfaces from our FPGA system, so we will need to adapt the low-level drivers for each while keeping the higher-level software shared. This lets us test software in the emulator, but the FPGA interfaces will still need separate testing.

The software work is behind the original schedule because the MartyPC setup and BIOS/disk-adapter tests are not complete. During the week of September 28, Govind will prioritize the compiler-to-emulator workflow and initial disk-read tests. This puts the planned DOS file-service and loader/shell milestones at risk. We will reassess those dates next week; October 19 remains the target for BIOS boot and disk reads on the FPGA. Meanwhile, Josh will begin instruction fetch from simulated memory and expand instruction support, and Ben will begin implementing and testing RAM, ROM, and address decoding.

Part A: Public health, safety, and welfare

Our project addresses an educational need by giving students a computer system they can inspect and modify to understand how hardware and software interact. Its contribution to welfare is mainly through learning rather than a direct health application. We do not intend the prototype for safety-critical use. For physical safety, we plan to follow the FPGA board’s power and connection requirements, secure wiring, and document setup procedures. Clear diagnostics, reset instructions, and known limitations should also make the system less frustrating to use.

Part B: Social factors

Our intended users include students, educators, and computing enthusiasts with different levels of hardware and software experience. To make the project useful beyond our team, we plan to document the interfaces and provide small examples rather than assume everyone already understands the 8088 or DOS. The project also gives people with different interests a shared system to explore: someone working on software can follow a request down into the hardware, and someone studying the CPU can see how programs use it. Emulator examples could make the software easier to explore without immediate access to an FPGA board.

Part C: Economic factors

We want the project to provide a reusable platform for studying an early computer architecture without relying on original vintage hardware. However, we cannot claim it is the cheapest option without accounting for the FPGA board, peripherals, and development tools. We plan to reuse available equipment where practical and prioritize the core functionality before optional features. Development time is another cost: keeping the emulator and FPGA software largely shared should reduce duplicated work, while simulation should help us find problems before board-level debugging.

A was written by Ben, B was written by Govind, and C was written by Josh.

This week, the team focused primarily on completing the proposal presentation and turning the high-level project idea into more concrete CPU, memory/peripheral, and software designs. The biggest risks we currently see are integration between the three subsystems, correctness of the custom 8088 implementation, and making sure the software only depends on hardware and BIOS/DOS services that we actually support. To reduce integration risk, Josh and Ben are defining the CPU-to-memory interface early so that the processor and memory subsystem agree on request, response, and address behavior before RTL implementation progresses too far. Josh is also breaking the 8088 into smaller components and studying instruction execution, bus behavior, and interrupts so that individual pieces can be tested before full CPU integration. On the software side, Govind is identifying the BIOS and DOS calls needed by our target programs and plans to develop and test the software incrementally using MartyPC before moving onto the FPGA. If compatibility issues arise, our contingency is to narrow the required software set to programs that only use the interfaces we have implemented rather than expanding the hardware/software scope late in the semester.

We did not make a major change to the overall architecture this week, but we did clarify and refine several parts of the design while preparing the proposal. In particular, we more clearly defined .COM applications as our required executable target, while .EXE support remains a stretch goal. We also refined the boundaries between the CPU, memory/peripherals, and software and began defining the interfaces that will connect them. Ben started outlining the memory map, RAM/ROM structure, address decoding, and peripheral connections, Josh refined the CPU block diagram and bus interface, and Govind expanded the software design into BIOS device support, DOS services, program loading, and the shell. These refinements do not significantly increase the project cost, but they do require time up front to agree on interfaces and supported behavior. We expect that this will reduce integration and debugging time later in the semester.

The overall project schedule has not changed significantly. Next week, Josh and Ben plan to finalize the CPU/memory interface, define the first memory map, and begin implementing and testing the CPU, RAM, and ROM components. Govind plans to continue setting up the software development environment, verify the MartyPC workflow, and begin working toward the BIOS and storage-access path. The team will also agree on the disk-access interface so that the hardware and software sides can progress against the same assumptions. At this point, we do not expect any changes to the larger semester schedule.