It's about time!

Here is what I have been working on the last few/several days. Another scrolling gradient but this time it is fully stored in the SD RAM. Double buffering wouldn't be too hard at this point but I will avoid it if I can.  A custom DMA controller has priority on the bus and transfers the next line on horizontal sync.  A number of tiny issues kept me from calling this done, subtle timing issues caused the image to be shifted right 2 pixels. Fixing some bugs made it appear worse even though it was closer to correct.

My colleague who is also using the OR1200 has been kind enough to keep a record of issues he had with building the toolchain (additional packages needed, using git for the first time, etc). I will be working with him to revamp my earlier post. I will also later be checking in code for this and finally be able to move onto implementing the SDCard.


Picture Time

This is an old program on the board (before the inclusion of the processor) it just shows the touch position.
This is the current program. The gradient is scrolling from right to left. Also note how the screen is upside down. This is due to the way Terasic setup the headers, it will only sit flat upside down relative to the development board.
Lastly the DE0 development board. You can see the SDCard slot that I have yet to implement as well as the ribbon cable leading to the touchscreen. I also find it odd that they cut the plastic shield such that it covers two of the momentary contact switches.


OR1200, Cygwin, SDRAM, Interrupts & the Red zone

So I didn't quite reach my goal of procedural images on the touch screen. I did run into some setbacks along the way that slowed me down but all of that is now resolved and I will go into that more below. The highlights of the week have been getting the SDRAM working, Getting interrupts enabled on the processor, learning about the red zone and just moments ago compiling the toolchain on Cygwin.


After much frustration I was unable to get a core from OpenCores that worked with the SDRAM. I had to port a bunch of code to compile on Quartus since it's Verilog support is incomplete. But all was for nothing since it didn't work at all. In the end I ripped the SDRAM module out of the DE0 SPOC example. The issue with that is that it is for the Avalon bus and a 16 bit one at that. With some finagling I built a bridge between it and the wishbone bus that takes care of most everything. There is still a bug in reads that causes more transactions to the ram than needed but I will look into that later. I will also probably need to use a wishbone-wishbone bridge to run the ram at 100MHz since at present it is taking 9 clock ticks to do a read. I am unsure if this will be fast enough to operate the ping-pong buffer for the touch screen but only time will tell.


I am not certain but it would appear that interrupts 0 and 1 are non-maskable. However unmasking them in the PICMR (Programmable Interrupt Controller Mask Register) is not enough. Interrupts in general must be enabled in the Supervisor Register. It is worth noting that the supervisor register can only be modified using a Read, Modify, Write method. Thus use GREAT CARE if you ever decide you need to modify a setting in the register. You need to be careful that you do not modify the register in an interrupt or exception whilst a lesser priority interrupt or the normal flow of execution is also modifying it (Your changes will be lost). My recommendation is set it and forget it. After that, only modify the register for critical sections (disable/enable interrupts) and everything will be fine.

Red zone

It is a little known fact (I didn't know it till 4AM this morning) that the OR1200 toolchain utilizes a Red zone. This means that code is free to use 128bytes beyond the stack pointer for temporary data. Which also means that your interrupt/exception handlers need to decrement the stack pointer by 128 on entry or you will screw something up (makes for a psychedelic experience on my touch screen). This isn't really documented and only after I asked the IRC about why GCC was generating negative stack references did I find out about it.


I got back to trying to make Cygwin work, I had long abandoned the subversion repository in favor of the one in GIT for my compilation on my laptop. I tried this on Cygwin and the results were less than satisfying. After some digging I found out why.

So heres how to get a working toolchain in Cygwin that can compile both c and c++ for the OR1200.
[Check comments for better tips on setting up cygwin from scratch]

Clone the GIT repository (Do not build!) following the instructions at

It is about 600MB so it will take a while.

Now we need to patch the uClibc build process.

So modify in the uClibc folder.

This bug has the lines that need to be changed.

Make sure you have the flex package in Cygwin

Now run "make". Thats it, no command line parameters.

Wait 1-3 hours.

When it is done the toolchain-out directory should have everything you need. I am still refining my makefile so there may still be kinks in that department.



That is basically the conclusion, don't do it. I have made so many subtle changes to the example it isn't even funny. BootReset.S in my firmware directory is the modified/fixed/hacked remanence of that example. At the very least take it but I recommend salvaging as much of the helper stuff from my code as much as possible. I am still working on it so I should improve over the next month and a half.

As always you can find my latest code here:
Till next time,



OR1200, Github, Touchscreen

I worked out the kinks that I was tracking down. Turns out that while I was going to change the clock edge of my RAM after I found the kink I should have just done it anyway. I was corrupting random memory with every write, fun times.

So here is where I am placing code now:

I am using the TerASIC Touch Screen for my user interface. This is finally hooked to the processor in some fashion. At time of writing the ping pong buffer is only partially implemented and the off chip ram is not yet used at all. This means it just displays one line of the screen across the entire screen. It also does a small animation to make sure it is working.

I hope to have the off chip RAM and procedural images by the end of the week. Then I can move onto the SD Card and PNGs.


OR1200 & Altera

It has been a while since my last post. I came across some bugs in the Quartus II software that severely slowed down my progress. Some of that was my fault since I just couldn't let it go and spent hours trying to find a work around only to fail.

So in the end instead of having a parameterized traffic cop for the bus I ended up with coding every signal on the bus into the traffic cop. This means every time I add a new device on the bus I get to add more wires by hand which is not speedy and is error prone (Killed a few hours because I had a typo when I made it bigger). I suppose it is better that using Xilinx and not having SystemVerilog at all.

This is even more motivation to make my own HDL compiler which I am pushing forward as my Software Engineering Senior Project next year. I need to buckle down and write the idea proposal that is due next week.

The other bug in Quartus that is annoying me is array literal syntax for interfaces '{ interface_a, interface_b } is broken. Nothing gets wired, sorta. From what I could tell a few signals were half hooked up when I inspected using SignalTap. 2 wires got a value but the other end of those wires didn't. It was weird. I have sent these off to Altera and they acknowledged them after a bit of a hissy fit about me not using a supported linux distro (Even though, they could reproduce the problem themselves).

I've been working on the boot loader the last few days but it still has a few kinks in it I want to fix before pushing any changes. Not totally sure whats going on but it may be a problem with the traffic cop (though I hope not).