![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)
This week has been working on the 6502 still. I’m currently in the process of getting the open-source test suite working with the Verilog 6502’s interface. I’ve also been doing more research on the graphics modes, which seem like the biggest hurdle after this. For MVP, I think that just implementing low-resolution graphics mode seems reasonable. It is fairly straightforward, while high-resolution graphics is pretty complex to implement exactly as it was done in the past. While it is well-documented, there are many quirks in its implementation that I can foresee being hard to debug.
Team Status Report for 3/14
Currently, our main focus/risk is on integration. The DOS and drivers are mostly complete, so the main issue is that they need to work together. The logic of the DOS does rely on the drivers functioning in a certain way, and if these guarantees are not met, the logic may need to be updated. The peripherals’ RTL is written, but the drivers still need to be written to integrate. The peripherals also rely on signals from the MMU to interface with the 6502 and the DOS.
Overall, the project is generally on schedule, but the next few weeks will be critical to integrating on time for the interim demo.
Aaron’s Status Report for 3/14
This week, I continued work on the DOS. I designed the majority of the file manager interface. Currently, I have implemented the ability to create, seek, read, and delete files. The underlying systems for tracking free sectors and such are also done.
Currently, I am about on schedule. The file manager’s core operations: create/open, changing position, R/W, and deletion are complete. The next step is to test it.
This coming week, I intend to test it and refine it. I already know there are some operations that are not optimal (for instance, there is code that I would like to reuse between some functions).
Will’s Status Report for 3/14
I spent this week testing the FDD control card in simulation. The testing process has come with some challenges, especially because the FDD control card is meant to be controlled by the 6502 (which is not included in the test structure). Instead of using the 6502, I am carefully toggling the signals on the control card to emulate RWTS sequences and making sure the output of the control card follows as expected. There are a handful of output waveforms available online that can be used to check if the emulator is working properly.
Overall, this portion of the project is on track for our “Testing and Verification” weeks.
For next week, I hope to have the FDD control card fully tested and have some testing done on the other peripherals. I also would like to start writing the peripheral drivers.
Rudy’s Status Report 2/28
The only thing of note here is that progress is now occurring for the Verilog implementation of the 6502. The microinstructions and diagram were fully flushed out and are now being translated into Verilog. Currently this is eating into the MMU time, so I am behind, but the MMU implementation is expected to be easier than initially anticipated since it is basically just MMIO. Below is the diagram with control signals labelled:
Will’s Weekly Status Report 02/28
This week the RTL for the floppy disk control card was completed and I began testing it in simulation. Alongside finishing the RTL, some testing was done with the FDD emulator in preparation for integration testing coming in a few weeks. There were some challenges associated with the timing requirements of the FDD, but many of these were resolved after some coordination with Rudy on the 6502 microinstructions associated with disk reads and writes.
On the project management side, the FDD is on track to be completed on time for the upcoming testing and verification weeks.
Team Status Report for 2/28
Individual work was done this week, information is in their respective posts. The overall schedule is on track and all is going well.
A was written by Rudy, B was written by Aaron, C was written by Will.
Our product solution goes about meeting the specified need with respect to global factors by establishing itself as easily accessible and easy for the general public to use, even without intimate knowledge of the design. We have been documenting each of our modules in-depth, including the reasoning for our decisions, rather than just noting down the final product. We feel that this helps contribute to the accessibility of the project greatly, since individuals without much engineering knowledge could read this documentation and gain a great grasp of the decisions made and what they led to in the final design. Even if they don’t desire to learn more about the underlying technology, our design is intended to work just like an original Apple ][, meaning that we are maintaining accessibility to all in a physical manner as well.
Part A: … with consideration of global factors. Global factors are world-wide contexts and factors, rather than only local ones. They do not necessarily represent geographic concerns. Global factors do not need to concern every single person in the entire world. Rather, these factors affect people outside of Pittsburgh, or those who are not in an academic environment, or those who are not technologically savvy, etc.
With respect to cultural factors, this project supports communities of people who are big on computer history and old computers. For many people, the Apple ][ was an introduction to computers. Additionally, by recreating accurate hardware for the 6502 processor, we also give people who like other old machines a chance to recreate their own devices, such as the Atari 2600. These devices played a big part in early computing, providing people with some of the earliest video games, for instance, and as such represents a major cultural phenomenon that we wish to contribute to.
While our project is based on recreating the functionality of the Apple ][ computer in a hardware emulator, there is still a connection to environmental concerns. This is because the current project uses an FPGA to recreate the Apple ][ instead of individual components. This can potentially reduce the environmental impact by reducing the number of individual components used to build or replace an original computer with numerous individual integrated circuit components. Another potential environmental impact is that modern digital hardware can run more efficiently than older hardware used to build the original Apple ][ computer. This will greatly reduce the overall power consumption of our implementation compared to an original device.
Aaron’s Status Report for 2/28
This week, I mainly worked on the file manager for the DOS. Last week I created a disk simulator and an initial file manager. This week, I created a ram simulator, which will be used to simulate the file buffers that are used to “cache” sectors as they are read in from the disk. I also had to rewrite part of the file manager due, as I realized the interface would not work with a disk (I accidentally used pointers instead of track/sector tuples when using disk locations).
Currently, I am still on schedule. The file manager should be finished right after break ends, and with most of the logic/testing mechanisms built, it should just be a matter of putting it together.
After break, I would like to have a fully finished file manager. This will allow us to move on and make the bootloader and device drivers, which will then allow us to integrate.
Will’s Weekly Status Report 02/21
This week I began implementing the floppy disk controller in RTL as well as submitted order forms (or will be submitting order forms) for most parts related to the Apple // peripherals. After spending last week primarily on documentation for the FDD control hardware and software, I am feeling confident that the floppy disk interface will be functional in synthesis (on the Altera DE2-115) by the time we have access to a real disk drive to test with.
Alongside the FDD RTL I wrote this week, I have also been documenting some of the software quirks associated with the RWTS (Read or Write, Track and Sector) protocol of the DOS. Because the floppy disk is not clocked (and is technically largely controlled by internal analog signals) there are some unique timing constraints associated with syncing the 6502 to a floppy disk during writes. These are mostly handled by a timer on the FDD control card, but the clock period connected to this tuner may need to be ‘tuned’ so that the data reading/writing rate is correct.
Beyond the above notes, the completion of the peripherals is on schedule and should be ready to be integrated on schedule.
Rudy’s Status Report 2/21
This is the last week on schedule for the 6502 redesign. So far, things seem to still be on schedule and I expect to finish the redesign by Sunday evening. While I thought I was done with the microinstructions last week, upon listing out all of the register transfers I realized that things were very unoptimized, leading me to go back and redo quite a few of them. I expect to have much more utilization of the ALU for each instruction as a whole now, while also reducing the sizes of the muxes for each register’s input. The expectation is that this will smoothly translate into Verilog, then pass the test suite we’ve found for 6502 implementations.