![Team C3: FPGApple ][](http://course.ece.cmu.edu/~ece500/projects/s26-teamc3/wp-content/uploads/sites/418/2026/01/cropped-Screenshot-2026-01-31-at-5.06.59-PM.png)
I’ve been working on hi-res graphics still this week. The system is quite complicated, so some simplifications are being made for final demo. I originally wanted to replicate the NTSC color blending, but this proves to be quite hard to do on the FPGA due to the math operations involved, especially with the time left. I instead am implementing just the standard 6-color hi-res graphics mode. Oregon Trail only uses these colors, which is what we would like to use for demo, so the simplification should be fine for our use case.
Will’s Status Report 04/25
This week I focused on fixing some small bugs with the peripherals, mostly spending time pipelining the graphics to avoid spurious patches of color in both TEXT and LOWRES graphics modes. In addition to this, I spent time working on the CAD file for the computer case which will be 3D printed for our final demo on Friday, May 1st.
Team Status Report for 4/25
Currently, our main focus/risk is on integration. As with before, the DOS still needs to be integrated. We have software for interacting with the floppy disk, however, write still remains an issue.
For the processor, we ran a test suite that exhaustively tested all instructions. We also verified the instruction counts against a reference, and synthesized the design onto the FPGA with the test suite.
For the peripherals, each module was tested against its own testbench, then synthesized and hooked up to its respective device.
For the DOS, we created our own unit tests. The core operations (open/create, read, write, close) were tested in a set of basic tests first. We then incorporated larger tests that stressed certain parts of the design, such as resource usage, creating multiple files and switching between them, etc…
In integrating things together, we first tested with old software. We are able to run an old version of DOS on our hardware using a floppy disk emulator.
Aaron’s Status Report for 4/25
This week, I fixed some last problems with DOS, as well as worked on the final presentation. This coming week will mainly be focused on doing integration ahead of final demo.
Rudy’s Status Report 4/18
This week I experimented with audio on the FPGA. My initial expectation was to instantiate IP for the DE2-115, but since the original Apple II’s audio output relied on manually toggling a register to create a PWM output, we realized that we could just connect a speaker to a GPIO pin directly. This produced some standalone results, but further testing has to be done with an actual Apple II program. I’ve been running into numerous synthesis issues with GPIO unfortunately and am working to resolve them.
Will’s Status Report 04/18
This week I completed and tested the read sequence with the floppy disk emulator and worked on debugging the write sequence. The read sequence works well, but there are still some issues with writing. Particularly, it seems that the write timing is slightly out of synch between the FPGA and the floppy disk, resulting in corrupted tracks. To resolve this issue, I am using a disk image editor and a FDD-to-hex translator to identify where errors happen.
Team Status Report for 4/18
Currently, our main focus/risk is on integration. We have a working Read/Write Track Sector program, which is what we will use as our software level driver for the floppy disk.
Overall, the project is generally on schedule. We intend to be able to run an old version of DOS, after which we will try to run our version.
Aaron’s Status Report for 4/18
This week, I’ve mainly continued working on DOS. There were some issues with read/write on stress cases which I worked through. I plan to test it with the floppy disk driver in the next day or so.
I found it necessary to use assertions to check my assumptions. There were a lot of times where I made a mistake, only to have an assertion I wrote catch it early. Instead of spending time tracing a bug, I would see something go wrong early, and be able to figure it out near the source. Additionally, I found it necessary to document what I was doing. A lot of the I wrote code for the DOS is rather confusing if you’re just looking at it, so putting comments everywhere helped me get back into it after not thinking about it for a while.
Rudy’s Status Report 4/4
This week we had the interim demo, which went pretty smoothly. The 6502 worked perfectly with the original Apple II ROMs and required no internal modifications during integration and synthesis. I am still on schedule. Next steps include implementing BCD mode for the 6502, which is unnecessary for our purposes and not really a priority. Besides that, I intend to help out with the implementation of high-resolution graphics and audio for the Apple II, which we were originally going to omit. Audio seems reasonable when using the Verilog from the DE2-115 documentation for the audio codec. High-resolution graphics poses more of a problem since only 6 colors were actually supported by Apple II programs when examining the software, but 16 colors are actually possible and were used due to color blending on monitors at the time. I’m currently conduction research on this to see how to replicate the effect in a digital manner.
Will’s Status Report 4/4
This week I worked with Rudy and Aaron for early integration steps. After demo, I also made some changes to the keyboard module to make it capable of sending control characters (e.g. CTRL + C, CTRL + G, etc.). Additionally, I have begun testing the FDD control card in hardware and have formatted a handful of emulated disk images to assist in testing. Should this go smoothly, I hope to start running the DOS3.2 RWTS by the end of next weekend. More results will be available tomorrow (Sunday, 4/5).
Overall the major risk associated with testing disk is that debugging may be tremendously difficult (and will require using an oscilloscope over multiple test runs and stitching them together).