Posted on

Team Status Report (10/10)

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.

Posted on

Govind’s Status Report (10/10)

This week I extended the MZ EXE loader beyond its original 64 KiB limit to use the existing 320 KiB program arena. I added reads and relocations across segment boundaries, checked code and stack addresses, and tested recovery from disk failures after partial loads. The full emulator regression passed all 22 guest profiles and 23 host tests. An earlier run timed out at 90 seconds; the unchanged code passed with an explicit 180-second process deadline. Evidence: https://github.com/JoshuaSmith1227/ibm-pcxt-fpga/pull/18.

The loader extension is complete. The November 2 shell/COM milestone still needs keyboard input and a minimal shell. Next week I will prioritize those features and their emulator tests while CPU and memory integration continues.

Posted on

Josh’s Status Report 10/10

This week, I took the CPU from register-only programs to reading and writing memory, using a stack, and calling subroutines.

I gave the bus interface unit a second client, so data accesses share the bus with instruction fetch, with data going first when both request. I then added MOV loads and stores with BX-based addressing, a DS register and an address-generation unit. Each 16-bit access is two byte transfers on the 8088’s 8-bit bus, including words that cross a segment boundary or the top of memory.

Next I added the stack: an SS register, PUSH and POP, and near CALL and RET, which redirect instruction fetch like a taken jump. I checked PUSH SP and POP SP, where the 8088 differs from later x86 processors, against 10,000 recorded real-8088 cases each. A second write port for the stack pointer lets each instruction update everything on one clock edge.

Two repeatable demonstrations check registers, memory and every bus transaction under varied memory delays. The second runs two levels of subroutine calls and restores every register, including the stack pointer. Resetting the CPU in the middle of transfers exposed a bug where an interrupted load still wrote its register, which I fixed. The tests also caught all 16 deliberately broken versions of the design.

I also corrected our design report and added a CPU block diagram. Next are the full decoder, the remaining ALU operations, and interrupts, which the BIOS needs.

Posted on

Ben’s Status Report (10/10)

This week, I focused mainly on working on our design report and making sure my portion of the memory and peripheral system was clearly documented. I helped refine the system architecture, memory organization, interfaces, and testing approach so that the report accurately reflects how my subsystem will connect with the CPU and software. I also continued reviewing the RAM, ROM, and address-decoding design to make sure it is consistent with the rest of the system. My progress is on schedule, and next week I plan to return to the RTL implementation and continue integrating the memory subsystem with the CPU interface.

Posted on

Team’s Status Report (10/3)

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)

Posted on

Govind’s Status Report (10/3)

Progress this week

I spent about 10 or more hours on the project this week, focusing on getting our BIOS and DOS software started and tested. I also spent four hours in class peer reviewing design review presentations, and additional time preparing for our presentation.

Our software can now start in MartyPC, an emulator that acts like an older IBM PC, using our own BIOS. The BIOS sets up the machine and reads our bootloader from a virtual disk. The bootloader then loads our kernel into memory and starts it. Earlier tests used an existing BIOS called GLaBIOS, but the current custom boot tests use our own BIOS.

I also worked on the C compiler setup and the code needed to start C programs without an existing operating system. This lets us write most of the kernel in C while using assembly for the low-level startup and hardware access.

The kernel can now find files by name and open, read, and close them. These operations are also available through a small set of DOS-compatible requests. Tests cover reading files spread across different parts of the disk, reaching the end of a file, opening missing files, and handling damaged disk data. This is still a test system: keyboard input, a command prompt, and loading existing DOS programs are not implemented yet.

Finally, I worked on making the implementation easier to understand and review. The documentation now explains how the emulator, BIOS, bootloader, and kernel connect, and the assembly comments explain what each instruction does.

Evidence:
– [Software explanation and review guide](https://github.com/JoshuaSmith1227/ibm-pcxt-fpga/blob/govind/software-review/docs/software-review.md)
– [Custom BIOS boot test results](https://github.com/JoshuaSmith1227/ibm-pcxt-fpga/blob/govind/software-review/docs/test-results/2026-10-03-custom-boot.md)
– [DOS file-service test results](https://github.com/JoshuaSmith1227/ibm-pcxt-fpga/blob/govind/software-review/docs/test-results/2026-10-03-dos-files.md)

Schedule

My progress is on track for the initial software setup and BIOS testing in our proposed schedule. Basic DOS file operations have also started. However, there is still substantial work before we can run existing programs, and all software testing so far has been in the emulator rather than on our FPGA.

Next week

I plan to check the display output directly, add basic keyboard input, and begin loading a small test program from disk and returning to the kernel when it finishes. I will also review the hardware interfaces with the team, especially how the BIOS will access storage on our board.

Posted on

Josh’s Status Report (10/3)

This week, I took the CPU from a set of separate units to a working processor that fetches programs from memory and executes them, including branches and loops.

I started by defining the CPU side of the bus interface: single-byte transactions, where the CPU holds each request stable until memory signals completion after any number of wait cycles. I drafted these rules for review with Ben and built a simulated memory to stand in for his memory system.

On the CPU side, I implemented the bus interface unit, which captures instruction-fetch requests and returns each byte as memory completes it. In front of it I built a fetch controller with the 8088’s four-byte prefetch queue. It tracks its own fetch position and reserves queue space for requests already in flight, so the queue never overflows. I connected the fetch path to the execution unit in the CPU top level and added an architectural instruction pointer, kept separate from the fetch position, which runs ahead. The instruction pointer advances by each instruction’s length when it completes.

I then added control flow: the short unconditional jump and the conditional jumps JZ and JNZ, which test the zero flag. When a branch is taken, the execution unit sends the target address to the fetch controller, which redirects fetching there. It discards queued bytes and partially decoded instructions from the old path. Memory requests already on the bus can’t be cancelled, so it lets them finish and drops their bytes. A branch that isn’t taken simply continues to the next instruction.

With these pieces in place, the CPU runs a short counting loop loaded from an instruction-memory image at the 8088 reset address. It produces the correct final register values and instruction pointer, regardless of how slowly memory responds. One design observation is that the CPU is currently limited by instruction fetch rather than execution, since the bus delivers one byte every two cycles. That will matter when we tune timing.

I also updated our documentation for the team’s board choice, the Terasic DE10-Standard. Its microSD slot is wired to the ARM processor rather than the FPGA, which affects how we design storage access.

Posted on

Ben’s Status Report (10/3)

This week, I focused mainly on starting the RTL implementation of the memory subsystem and turning the architecture I had planned over the previous weeks into actual modules. I worked on defining the CPU-to-memory interface with Josh and started implementing the basic RAM, BIOS ROM, and address-decoding logic that will sit between the 8088 and the rest of the system. I also worked through how memory reads and writes should be handled and how the decoder will determine whether a CPU request should go to RAM, ROM, or eventually one of the peripheral interfaces.  I also started setting up simple directed tests for RAM read/write behavior, ROM reads, and address-boundary cases so that each piece can be verified before integrating it with the CPU. This helped clarify some of the timing and interface details that still need to be agreed on between the CPU and memory sides. My progress is currently on schedule, and next week I plan to finish the initial memory modules and tests, connect them more closely to Josh’s CPU interface, and begin working on the next layer of the peripheral system, starting with the I/O decode and storage interface.