Posted on

Team Status Report for 4/4

Currently, our main focus/risk is on integration. As with before, the DOS still needs to be integrated, which requires writing the software level floppy disk driver.

Overall, the project is generally on schedule. We were able to test the hardware after integration by running old programs, which allowed us to play snake and a system monitor. 

Now that you have some portions of your project built, and entering into the verification and validation phase of your project, provide a comprehensive update on what tests you have run or are planning to run.

We have run a large test suite on the 6502 processor. This tested every instruction, verifying that all of the instructions execute as per the ISA. Additionally, we create testbenches and test vectors for all of the drivers. The keyboard and video drivers were fully tested. The software is being tested through test cases.

One of the main validation methods we have done is running old code. We were able to run a system monitor, game, and some other programs on our hardware (6502, keyboard, and video drivers). This matches the requirements of our project, as we wanted to be able to run old software.

Posted on

Aaron’s Status Report for 4/4

This week, I was focused on doing integration. We integrated our keyboard, monitor, and 6502 processor together. I focused on running and testing our own keyboard/video drivers on the integrated hardware. We were able to get a “text editor” working.

This next week I will focus on continuing to test the DOS. We also intend to integrate the floppy disk drive, which requires us to write the driver for that.

Posted on

Rudy’s Status Reports 2/28

This week I completed testing of the 6502 by testing against the standard Klaus6502 test program. This program tests all instructions for correct behavior, including flag setting. A few modifications to my original system diagram occurred, primarily with adding a few additional control signals. The most significant one was the need to create an is_BRANCH signal for the ALU so that it sign-extends the offset being added to the PC. This was an oversight on my part since only the PC needs its second operand to be sign-extended, as it is the only 16-bit operation that our ALU performs.

After testing in simulation, I synthesized the core with BRAM initialized to the same program. The program executed as expected and for the correct amount of time. Integration is now occurring with Will’s peripheral modules and Aaron’s software.

We are on schedule, with integration going much smoother than expected.

Posted on

Will’s Status Report 03/28

This week I made a module to display the contents of video memory to a monitor in LOWRES and TEXT graphics graphics modes. This module was adapted from the vga module written earlier this semester by adding hardware to raster through video memory and adding translators from byte data to graphical data. I also updated the keyboard interface to work with the rest of our integrated design.

 

Posted on

Team Status Report for 3/28

One of the main risks right now is the DOS. While preparing for demo, we are integrating running simple software (just a command line interpreter) onto the processor, which has revealed problems with compiling/building/linking programs together. Building a larger system, like the DOS, may present many issues. One mitigation is for us to manually link pieces of code together, which would be rather annoying.

A major milestone was getting graphics working. We have the ability to display something on VGA.

No changes were made to the schedule.

Posted on

Aaron’s Status Report for 3/28

This week, I focused on testing the DOS. All DOS operations have been implemented, and I found the causes of various bugs that I was tracking last week. I continued writing test cases, but this week I shifted more to work on integration because demo is coming up. I wrote a GUI to allow for user input, as well as keyboard/video drivers. I also spent some time figuring how to compile to 6502 assembly.

I am still about on schedule. I’m still doing verification on the DOS in the background, but right now we are all working on integration.

For the next week, I am focusing more on integrating everything together.

Posted on

Rudy’s Status Report 3/21

Revisions to the 6502 have continued to be made throughout its development this week. The original design used a “timing state generator” that described the current cycle of the instruction, alongside the instruction itself to form a state machine. This translates to rather ugly Verilog, so we’ve instead switched to a FSM for each possible state. This is 135 states, which is certainly still ugly, but allows for much easier debugging and understanding of the design when used alongside the design documents I’ve created.

In addition to this, I have changed our Absolute, X addressed microinstructions to work with Will’s FDD module. The original Disk Drive used the fact that the address was valid on the line for multiple cycles to drive its own state machine, but I removed this side-effect when writing the microinstructions. This and holding the data on the line for an additional cycle were added. In general, progress is continuing on and debugging is occurring.

Posted on

Will’s Status Report 03/21

This week I almost completely finished verifying the floppy disk control card in simulation ensuring that it is compatible with both the Disk ii FDD and our implementation of the 6502. During testing I found several issues with the FDD firmware that were re-written to align with the microinstructions of our implementation of the 6502. Further changes may need to be made for the read sequence to function properly, but testing so far indicates that the FDD is fully functional.

Moving into next week, I need to spend time starting to write device drivers for the peripheral modules. Aaron and I plan to meet and talk about the FDD drivers, as they are a critical and significant part of the DOS.

Posted on

Team Status Report for 3/21

One of the main risks right now is the bootloader. We cannot yet test it, as we cannot yet interface with the disk. Additionally, the complexity of the file manager has been revealed through testing, as various bugs have cropped up during stress testing. The risks to the DOS are being managed by creating extra tests and testing extra combinations of behaviors. The bootloader can be mitigated by putting the DOS directly into memory if the bootloader cannot be fully tested.

A major milestone reached this week was the completion of the FDD module simulation testing. The disk module being completed will allow us to begin with integration testing once the 6502 RTL is done. With the 6502, we can write more complicated assembly programs to test the FDD and begin testing the bootloader and other critical parts of the DOS.

No changes were made to the schedule.

Posted on

Aaron’s Status Report for 3/21

This week, I focused on testing the DOS. I wrapped up all of the implementation (finished the close() functions), and focused mainly on testing read/write/open. Currently, we are able to create over 220 files. This works out to be about the max we could possible make given the limitations of disk. We need 1 data sector, 1 t/s sector per file, and 1 catalog sector per 7 files, which lets us make 7 files per 15 sectors. With 32 * 16 = 512 sectors, we can make at most (512 / 15) * 7, which is about 240 files. However, there remains a bug with the interaction between read and close that I am still chasing.

I am still about on schedule. I need to fix this last bug, and continue writing test cases. As I am going to be testing for the rest of the semester, I am probably going to write 2-3 test cases per week.

For the next week, I am focused on fixing this bug, and working with Will to integrate drivers into the DOS.