mycontroller – done

This was my final architecture project from a couple years ago. I had several posts in here about it, so I figured I’d post the final as well.

The goal of this project was to integrate all parts covered throughout the lab. Similar to lab7, lab8 fetches microcode from a second memory device. Extending lab7, however, it also performs very basic operations, including add, eq, nop, ld, skipz, and halt. There are 4 physical registers, which will be referred to as 00, 01, 10, and 11.

lab8report.pdf <– Write up

Logicv12 <— Multimedia Logic Source <– contains the default program loaded into ram, etc

The circuitry is pretty simple – most the hard work was in decompiling the microops. Here are some shots of the circuitry.


avr interrupts

This was also for homework..

From the specifications:

The purpose of this assignment is to give you experience with the AVR’s timers and the use of interrupts. You are to repeat assignment #1, this time performing the timing using an interrupt-driven timer. You are to write an interrupt service routine (ISR) for one of the hardware timers on the AVR. Each time the timer interrupts, you should update a counter variable. Then, when determining the amount of time that the switch is held down, use the counter value. Then, use the counter again to determine how long to turn on the LED. As before, in addition to writing the code, determine the size of the code in your program, including main and the ISR.

I found this site hugely helpful:

For reference, all the first assignment did was to time how long you held down a button, wait a second, then to light up the lights for the same duration. The difference is this assignment uses timers and interrupts wheras the other just looped.

Here is a link to the source.

mycontroller – Cache

Download the mmlogic schematic here, the memfile here, and the cache file here.

The clock is run at a very slow speed so you can see what is happening.  I didn’t bother to stop the memory/cache from outputting, so there is a constant read.

The input is a memory address, which is fetched from Cache (if the data is in Cache) or RAM (if the data is not in Cache).

The part of the system not being used (RAM or cache) is always doing stuff, but this system just throws it away if it is not relevant, and keeps it if it is.

The Cache is done using a direct addressing scheme.  The addresses are stored in the “higher” half of the addresses.  For example, the data at 0000xxxx in the cache has the address in RAM stored at (in the cache) 0001xxxx.

Sample Run

At first, the program begins.  Because there is a default read, the instruction is to read 00000000 out of RAM.

The Controller will check to see if this value is in cache (page 4).  It checks this using an ALU and zero flag.  It is not, so memwrite (the zero flag output) will be set to +1.  This indicates to output the value from RAM.  The value is output from RAM, and put in cache.

Because there is a constant read, the value at RAM 00000000 is read again, but this time, it is in cache.  The ALU will compare the value at Cache 00010000 with the address, and they are equal, so ZF flag is set.

Flip any switch, the process above repeats.

Flip the switch back so the address is once again 00000000, and notice that the value is only read from cache.


The logic analyzer will be a mess, because of my use of oscillators.  I recommend debugging by sight and LEDs.

The oscillators function as a system clock. This is a synchronous system.

The cache writing flag is oscillated only if the memwrite flag indicates that there must be a cache write (if the system had to retrieve something from RAM)

The control address oscillator is constantly moving back and forth between where the data is stored and where the address is stored in cache. It oscillates at a slower speed than the write oscillator.

mycontroller – DMA

This is part of a project to build a complete, functional, extremely basic microcontroller. It is built using multimedia logic.

This section is a simulated very simplified DMA.

Example Run

The test of writing back and forth bytes seems to work.

Also, the example from the lab specification seems to work. Namely:


  • Select head 1, track 2, sector 3, block 4 on the disk.
  • Select address AB on the RAM.
  • Select 6 bytes to transfer.
  • Select download.
  • Disable the master clear.
  • Hit the transfer button. The yellow download LED should illuminate.
  • Hit the clock at least 7 times. Your transfer should stop after the 6th cycle, illuminate the green completion LED, and deactivate the yellow download LED.
  • You should see 6 different bytes transfer from disk blocks 4 through 9 from head 1, track 2, sector 3 to RAM addresses AB through B0, respectively. The particular bytes depend on how you organized the address space on your “disk.”


  • Select head 2, track 3, sector 4, block 5 on the disk.
  • Select address AC on the RAM.
  • Select 2 bytes to transfer.
  • Select upload.
  • Hit the transfer button. The yellow upload LED should illuminate.
  • Hit the clock at least 3 times. Your transfer should stop after the 2nd cycle, illuminate the green completion LED, and deactivate the yellow upload LED.
  • You should see 2 bytes transfer from RAM addresses AC and AD to disk blocks 5 and 6 on head 2, track 3, sector 4.
  • These should be the second and third bytes you saw in the download example.

Known Issues

You can’t have reads/writes across different tracks or heads, which will produce (perhaps to the user) unexpected results, overwriting the same sectors rather than proceeding to the next track. In short, reading/writing across tracks requires multiple reads/writes.

I made a conscious decision to not worry about the clock wrapping around at this point. If the clock does wrap around, it may screw stuff up.

Screen Shots

Here is a link to the source.

mycontroller – RAM

This is part of a project to build a complete, functional, extremely basic microcontroller. It is built using multimedia logic.

This is a functional subsystem that manages a small RAM in our architecture speed across 2 128 byte memory addresses.

All the Input and output can be viewed from the first page.

The tristate devices on the input (address and data pages) are probably not necessary, and on the solution I saw were not there. However, they were the only way I could think of to have an active disconnect rather than a zero or one.

There is a lot of complexity added because of this.

Also, there would have been additional complexity that would have been added if the read were not active. But because of the email sent earlier modifying the specifications, this is not the case and I have left the read in active mode (if you are not writing, you are reading).


Here is a link to the source.