Posted on

Team’s Status Report (09/26)

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.

Posted on

Govind’s Status Report (09/26)

This week, I spent most of my time working on the design presentation and practicing, since I will be presenting for our team. I focused on explaining how the CPU, memory, peripherals, and software fit together, along with our design choices and testing plan. I also worked on making the presentation clearer and keeping it within the time limit.

I followed up on our discussion about using Vitis HLS to generate RTL from C/C++ for testing. The main issue is that converting our BIOS or DOS into hardware would bypass the custom 8088 that is supposed to run it. HLS can test the hardware it generates, but that would not tell us whether our software runs correctly on Josh’s CPU or works with our memory and peripherals. For our project, maintaining that separate implementation would add work without answering the main integration questions.

I identified Open Watcom v2 as a candidate compiler for our software. Its 16-bit C/C++ compilers can generate 8088-compatible instructions using the -0 option. We would still need assembly startup code and a linker configuration for the BIOS ROM. My next step is to validate this with a small program before building more software around it.

I also looked into MartyPC for testing before our hardware is ready. My proposed setup would load our BIOS ROM and a disk image containing our boot code, DOS, and test programs. A build option could select between an emulator-compatible disk driver and a driver for Ben’s microSD interface. This would let me test software behavior, including loading files from an emulated disk, while developing the hardware separately. It would not verify our CPU or storage controller; those still need RTL and board-level tests. I have researched this setup but have not completed it yet.

My software work is behind the original schedule, which called for MartyPC setup during the week of September 14 and BIOS/disk-adapter tests during the week of September 21. To catch up, next week I will prioritize compiling a minimal 8088 program, loading our own ROM in MartyPC, and beginning disk-read tests. I will also work with Ben on the storage interface. These are prerequisites for the DOS file-service tests, so I will update that milestone based on what is working next week.

Posted on

Josh’s Status Report (09/26)

This week, I began RTL implementation of our custom CPU in SystemVerilog, building and verifying the first vertical slice of the datapath. I implemented and tested the general-purpose register file, including byte-register access. I also built an ALU that performs 16-bit ADD and generates all six status flags (carry, parity, auxiliary carry, zero, sign and overflow). It passed over 20,000 directed and reference-model checks. Next, I implemented a decoder subset for MOV r16, imm16 and register-to-register ADD. It consumes instruction bytes through a valid/accept handshake and waits correctly when bytes are unavailable or when execution is not ready. I then built an execution unit that connects the decoder, register file, ALU and writeback through a small instruction controller. The controller retains each instruction’s operation and destination until it finishes. The unit correctly executes a short demonstration program (MOV AX,3; MOV BX,4; ADD AX,BX; ADD AX,AX, leaving AX = 14) and a longer flag-focused program, and it stops safely on unsupported instructions. To check that the tests are meaningful, I injected deliberate bugs into each module and confirmed the testbenches catch them. This also exposed a remaining gap in the execution-unit tests that I will fix. I set up a repeatable local simulation flow with Vivado’s XSim and Make targets for each module, and recorded the test results. I also drafted the CPU-side bus ports (single-byte transactions with explicit completion, plus the interrupt inputs) for review with Ben. The CPU cannot yet fetch instructions from memory, so only these two instruction forms run, fed directly by a testbench. Next week, I plan to review the bus interface draft with Ben. I then plan to build the instruction fetch path (instruction pointer, segment registers, prefetch queue and a minimal bus interface unit) with a simulated memory model, so the CPU can run programs from memory. I will also start extending the decoder and ALU to the full family of arithmetic and logic instructions.

Posted on

Ben’s Status Report (9/26)

This week, I split my time between working on our design presentation slides and continuing to refine the memory subsystem for our project. For the presentation, I helped improve the system architecture, requirements, testing plan, and overall organization of the slides so that the design and interfaces between the CPU, memory, peripherals, and software were clearly explained. On my individual work, I continued working through the CPU-to-memory interface, the initial RAM and BIOS ROM organization, and how address decoding will select between memory and peripheral accesses. I also started outlining the tests I will use for RAM reads and writes, ROM initialization, and address-decode boundaries before integrating with the CPU. My progress is currently on schedule, and next week I plan to finalize the CPU/memory interface with Josh, lock down the first version of the memory map, and begin implementing and testing the RAM, ROM, and address-decode modules before moving further into the storage and peripheral interfaces.

Posted on

Team Status Report (09/19)

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.

Posted on

Ben’s Status Report (09/19)

This week, I focused mainly on completing our proposal presentation and getting a better understanding of the memory and peripheral portion of our PC/XT recreation. On my individual portion, I started planning the memory subsystem, including how the BIOS ROM and system RAM will connect to the custom 8088 processor and how address decoding will determine which component responds to a CPU request. I also looked into the peripherals I will be responsible for, including video, keyboard, timer logic, interrupts, and microSD-backed storage, and started thinking through how these pieces will connect to the CPU bus. I began outlining the memory map and the interfaces between the CPU, RAM, ROM, and peripherals so that the different components can be developed independently and integrated later. I also started planning how I will verify the memory system, including RAM read/write tests, ROM initialization checks, and address-decoding tests before integrating it with the CPU. My progress is currently on schedule, and next week I plan to finalize the CPU/memory interface with Josh, define the initial memory map, and begin implementing and testing basic RAM and ROM modules before moving on to the storage and peripheral interfaces.

Diagram generated with Chat GPT

Posted on

Josh’s Status Report (09/19)

This week, I focused mainly on researching the Intel 8088 specification and creating a block diagram for our custom CPU. I worked through how instruction fetching, decoding, operand reads, address generation, execution, and writeback connect, using an ADD instruction as a concrete example. I also studied how the bus interface unit shares memory access between instruction fetching and execution, along with how interrupts save processor state and redirect execution to a handler. While reviewing the diagram, I corrected inconsistencies in instruction decoding and address calculations and added missing data paths and control logic. This work helped me break the CPU into manageable components and better understand their interfaces before beginning RTL implementation. Next week, I plan to refine the control sequences and coordinate with Ben on the CPU bus interface so that our CPU and memory subsystem designs agree on how requests and responses are handled.

Posted on

Govind’s Status Report (09/19)

This week, I primarily worked on the project proposal slideshow for our FPGA-based IBM PC/XT recreation. I also began expanding its high-level software design into the individual components shown in the diagram below. These include BIOS device support, DOS file and program services, and the shell, with .COM applications as the required target and .EXE support as a stretch goal.

To guide implementation, I looked into Microsoft’s BIOS call reference, DOS system-call reference, and Ralf Brown’s Interrupt List. These document the software-interrupt interfaces, arguments, results, and error behavior that our software needs to support. My implementation plan is to work from basic BIOS and disk access upward to filesystem operations, program loading, and the shell. I plan to test each component using known inputs and expected outputs before integrating the next layer.

MartyPC will provide an emulated PC environment for developing our software and comparing program behavior. After verifying the setup, I plan to load a minimal custom ROM and inspect a known result in memory before adding BIOS functionality. Our FPGA-specific device interfaces will also require testing in RTL simulation and on the board.

I am behind on the scheduled MartyPC setup and sample code because this week’s effort went toward the proposal and design. Next week, I aim to complete the emulator setup, establish the custom-ROM test, and agree on the disk-access interface so I can begin BIOS and storage-adapter implementation.

Image credit: Created with GPT-6 Astra.