Category: Govind’s Status Reports

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.

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.

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.

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.