Posted on

Team Status Report for 2/21

As with last week, the main risk is with the drivers. Because hardware for the drivers is not here yet, we can’t fully develop the software level of the drivers. This may cause issues with the DOS, as I/O is done by polling the devices. For developing the DOS, the risk is being managed by defining an interface (and simulating the disk) to develop the DOS first, then to fill in the interface with code that will actually interact with the hardware once we have everything we need to implement it.

There are currently plans to spend the beginning of next week coordinating peripheral hardware (especially the FDD interface) with the DOS implementation in preparation for the upcoming more software focused weeks.

No changes were made to the schedule this week. As such, our schedule is the same.

Posted on

Aaron’s Status Report for 2/21

This week, I began work on the DOS. Will and I created an interface between the disk control software and the file manager. I had already figured out the file manager process from last week, so I created a disk simulator based off the interface and am using that to develop the file manager. The interface has a read function, which reads a sector into a specified location in memory, and a write function that writes to the “disk”, along with functions needed to set up a disk simulator during testing.

Currently, we am on schedule. The file manager is mainly logic, so I’m developing and testing it entirely in C. We intend to develop the lower level drivers/bootloader once our hardware comes in and the 6502 is closer to being done.

I’m aiming to have the file manager done by next week. That way, Will and I can work on the drivers for the disk after break, then integrate that into the DOS.

Posted on

Rudy’s Status Report for 2/14

This week I continued on with research on the 6502. After last week’s discussion, I set out to make a document with microinstructions of each valid instruction + addressing mode combo. This is almost done, with just two instructions left to go now. After this, the processor diagram will be drawn up and there will be much more to start coding with. These are my future goals for this week.

BRK and RTI were really odd cases when drafting up microinstructions. It turns out that documentation does not describe all behavior of the instruction, so I went down a rabbit hole googling and using a cycle-accurate representation of the 6502 to figure out behavior of the BREAK flag in these instructions. I eventually found out that there is no real BREAK flag in the P register. It is almost always set to 1 since PLP and RTI both set the B flag no what processor status they pull off of the stack. So determination of an interrupt being software or hardware based can only be found through bit testing of the value off of the stack, not the value in the P register.

Schedule-wise we are doing fine since we still have a week for the 6502, but I personally wanted to be a bit more ahead with my portion by this time. I intend to work more this weekend to try and meet these personal goals.

Posted on

Team Status Report for 2/14

Currently, the most significant risk that could jeopardize our project is the complexity of the drivers. Because we are going to be interfacing with the real hardware, our software level drivers need to be completely correct. This is especially difficult, as our driver software timing also relies on our 6502 being cycle accurate to the original one. To mitigate this, we are making our 6502 cycle accurate. We also intend to test our software on a floppy disk emulator. Using a driver from an old program would be a contingency. We are reaching a point in our project where the 6502, DOS, and FDD need to be designed to work together despite being implemented separately. Any risks associated with this integration focused design are already being mitigated by frequent internal design and code reviews.

No changes were made this week. As such, the schedule is the same.

For this week’s questions, A was written by Aaron, B was written by Rudy, and C was written by Will.

Part A: Our product solution will be designed to be safe. Because we are trying to interface with real hardware components like a floppy disk driver, we need to ensure that we do not damage the device. Doing so could potentially create a physical hazard to the user, as it is an electrical component.

Part B: The purpose of our product is for both historical and educational purposes. So with this, we hold the responsibility of representing history accurately and ensuring that this educational opportunity is accessible to as many people as possible. Historical accuracy is quite clear-cut, but educational accessibility is a bit more complicated. This is because it involves making the project available to all who have an interest in it, regardless of their level of familiarity with the subject.

To support this, we’ve been very thorough in our documentation of the 6502 redesign; noting down our own confusions and hidden gems of information we’ve come across. This documentation allows somebody with basic familiarity of CPUs to follow along and learn about the underlying details of the Apple II in the same way we have been, which is much preferred to reading source code. Once past the 6502, we intend to continue our extensive documentation for the Apple II’s intricacies, whose design is even more complicated.

Part C: Considering economic factors, our product meets the needs of lower income people and organizations who want to teach about the history of personal computing. To purchase an original Apple //, it costs at MINIMUM $2000, a price that is not accessible to most people. Our product will recreate the functionality and user experience of the Apple // while costing drastically less that buying an original machine.

We also intend to make the majority of our RTL, software, and other design elements and documentation entirely open source. This will allow people to make their own FPGApple // at home, only needing to cover the cost of materials. Our product will ultimately lower the economic burden on people who aim to learn about and experience early personal computing technologies.

Posted on

Will’s Status Report for 02/14

This week I continued to work on documenting and implementing peripheral modules for our Apple //. My time was especially spent researching the different pieces of software and hardware used to control the floppy disk drive (FDD).  One of the quirks of the Apple // was that the FDD is primarily controlled by software and the DOS – a control scheme that was not conventionally used in other floppy disk based systems. The Apple // was implemented in this way to minimize hardware costs, meaning the Disk // control card should be relatively simple to implement. Our main concern with implementing the Disk // control card is that because the FDD is primarily software defined, our hardware must perfectly match the original Disk // control card.

In addition to working on the FDD controller, I implemented some useful modules for interfacing the 6502 with a keyboard and monitor.

Currently, we are on schedule to finish the peripheral modules and drivers as planned.

Posted on

Aaron’s Status Report for 2/14

This week, I worked on the design and code for the 6502 processor. I worked with Rudy to figure out the overall design for the processor, which mainly consisted of figuring out how to manage the 13 different addressing modes, as well as maintaining the same cycle counts for all of the instructions. I wrote some initial code, but it is incomplete. Additionally, I began planning the design for the DOS. The architecture for the file system will follow the original design. I intend for the disk to be broken up into 35 tracks, with the DOS itself living on tracks 0-3, and the VTOC and file system catalog living on track 17.

Currently, we am on schedule. We were aiming to complete the processor this week, but did not achieve that goal. Finishing it up this next week keeps us on our original schedule. Work on the DOS has also begun, in accordance to our schedule.

We aim to have the 6502 done by next week. Additionally, I intend to have documentation detailing how the DOS will operate by next week.

Posted on

Rudy’s Status Report for 2/7

On my end, this week consisted of research about the ISA and internal architecture of the 6502. Quite a few interesting things popped up during this research:

 

ISA-wise:

  • Clock cycles are listed alongside each instruction, indicating that instruction timing is part of the ISA. This means that the implementation must be cycle accurate if we wish to run old, arbitrary programs.
  • 13 addressing modes, one of which is “implicit” and is specific to each instruction of that addressing mode type.
  • 56 instructions, plus some undefined instructions that were used by some programmers. We will not be supporting these.

 

Architecture-wise: (Referencing Donald Hanson’s 1979 Diagram here)

  • Used two clocks, phase-shifted such that operations were functionally occurring on the rising and falling edge of a single 1.023 MHz clock. Meaning that 2 micro-operations could occur in each clock cycle.
    • Poses a problem because FPGA architecture is generally not receptive to operating on both the rising and falling edge of a clock in a single logic element.
    • Could mitigate by simply doubling the frequency and then implement based off of the block diagram. Not a viable solution though due to the other complications.
  • Latches were often used, some are referred to as “registers” in the diagram such as the A, B, and ADD “registers.”
    • Again, poses a problem because FPGA architecture is not really receptive to latches. Their behavior is not as predictable as a register since they are just implemented as a feedback loop between 2 LUTs.
  • Asynchronous memory was assumed. Waveforms indicate that in the same cycle an address was presented, data from memory would become available in the data latch.
    • Again, poses a problem because FPGA BRAM does not function like this. Data becomes available on the cycle after an address was presented.
  • Otherwise, somewhat straightforward for the time period. Just oddities like a BCD addition mode, and an extra cycle when crossing page boundaries due to using 8-bit adders for a 16-bit address.

Considering the 3-week timeline for the 6502, we are staying on track. I met with Aaron after conducting all of this research to make decisions regarding the inevitable redesign. This is discussed in the team status report for this week.

Posted on

Will’s Status Report for 2/7

This Week:

I spent this week researching protocols and  implementing + testing SystemVerilog modules to interface with a PS/2 keyboard and VGA monitor.  Some time was also spent researching floppy disk protocols in preparation for the next two weeks.

I found that there are various different PS2 protocol versions that exist, making it infeasible to make a PS2 driver that is compatible with all existing versions.  To remedy this, I focused on implementing the most common version of the protocol used in keyboards (detailed here). Most available PS2 keyboards only require device-to-host communication, which made implementing the module relatively simple. The device-to-host-only (DTHO) PS2 module I wrote has already been tested in synthesis and can interface with a PS2 keyboard lent to our group by Prof. Nace.

In addition to this DTHO module, I have also implemented a module capable of both device-to-host and host-to-device communication. This bidirectional communication module has been tested and shown to function in simulation, but has not yet been tested on an FPGA because I do not have access to a keyboard that requires host-to-device communication.

For VGA, I was able to quickly implement a working SystemVerilog module using code I had previously written with some small changes. The VGA module was tested in synthesis and is able to interface with a VGA monitor without any issues. Additional graphics mode modules will likely have to be added to this one once the 6502 and DOS are more developed.

Schedule:

After all of the work completed this week I am on or slightly ahead of schedule. There are no immediate concerns about the current pace of the project.

Next Week’s Plan:

Next week, I plan to add some additional functionality to the modules I have already written as well as start to implement the floppy disk module. By the end of next week there should be a minimally functional module to interface with a floppy disk drive as well as some simulation testing/waveform analysis.

Posted on

Aaron’s Status Report for 2/7

This week, I worked on setting up the testing infrastructure for the 6502. I created the testbench, as well as set up the assembler for test programs. I also discussed the processor design with Rudy. For the processor itself, we first decided to simplify the design by removing certain components we deemed unnecessary. We also decided to divide up microinstructions based on addressing mode.

Currently, we am on schedule. I am currently working through the 6502 processor with Rudy, which is expected to take 2 more weeks.

We would like to have a complete 6502 processor by next week. This will involve finishing up designing our implementation, then actually coding it up, which we intend to have done by the next week. Additionally, I would like to expand write more test cases next week to expand the amount of tests we can run.

Posted on

Team Status Report for 2/7

Writing the 6502 provided us a bit more complications than initially expected, which are described in Rudy’s status report for this week. However, since writing the 6502 was scheduled to take 3 weeks, we are still on time for this goal. These complications resulted in a discussion between Rudy and Aaron to create a plan for the redesign of the 6502, making it compatible with the requirements of a FPGA. Below are the steps we’ve decided are necessary for the redesign:

  1. Determining microinstructions for each addressing mode, this will translate into control signals
  2. Deciding necessary hardware for the functionality for each instruction, such as addition and register transfers
  3. Listing out all possible inputs into each register
  4. Translate these hardware requirements into a block diagram
  5. Translate block diagram into Verilog

For the 6502 testbench, we have set up a very basic testbench to run simulations when we start writing the Verilog. However, the only test programs we can currently run are pre-existing ones. Thus, we are also currently setting up a way to compile C code, so that we can run other benchmarks.

Currently, we appear to be on track and no significant risks pose themselves. However, if things go on a downturn with the 6502 redesign, there is a mitigation plan of using an open-source 6502 core.

Beyond the 6502, researching and implementing the FDD module may prove to be challenging. The original motherboard of the Apple ii needed an additional control card to interface with the Disk-ii floppy disk drive. Most of the functionality of the control card can be implemented on FPGA, but some additional hardware (breadboard, MOSFET, power supply, etc.) will be needed to drive the stepper motors. If it is not possible to recreate the control card using our FPGA, there is an FDD control card emulator that we can buy and use instead.

No schedule update has occurred.