Improvements on BarelyMVC

So this weekend I decided to work on BarelyMVC more. I've decided it's nowhere near done(though it is usable). So far I've implemented:

  1. Caching for Route group lists(hint: fairly expensive to generate all of them on each request)
  2. XML documentation so now Intellisense works on most everything
  3. Testing (and fixing) for running under Visual Studio 2010/Cassini
  4. Reworked ViewEngine a bit so now the core code for it is in a separate file(hint: updating is much easier now)

Hopefully tomorrow, I'll have time to implement maybe "type matching" on route variables with regular expressions, and test it under Visual Studio 2012 and maybe Windows Server 2012.

Haven't got this site updated to use the new features yet, but after I do get it updated, I suspect my requests/second capacity will go up by quite a bit.

Posted: 10/7/2012 2:59:49 AM

MbedConsole -- Build Report

Well, I think I should finally document how to actually build the MbedConsole. It's very simple...

A full overview schematic(which I think I did a horrible job on) is below:


I think this design is simple enough that it doesn't need much further explanation. One note though is that you can possible increase or decrease the resistance for the 470ohm resistor connected across RGB. Having more resistance decreases the brightness, having less increases it.

Now then, a picture's worth a thousand words... so: (in chronological order)

Taya typing

Taya typing at the basic serial-vga repeater thing


Shell is mostly working, though still gets input from serial and not PS/2


Finally received the PS/2 breakout board and wired it up


Another angle


My final "impressive" feat. Drawing pretty pictures!

Anyway, the code is accessible at mbed and my portion of the code is BSD licensed. The projects current status:

  • PS/2 keyboard completely works except for the caplock and such LEDs
  • The PLEarlz language thing can function as a simple stack calculator. Other than that, it's still a deep work in progress.
  • VGA signal is extremely stable and consistent. 640x480 monochrome graphics updated at 60hz.
  • Interrupts are re-prioritized at startup so that the VGA signal never stutters.
  • Tons of RAM and Flash left over. Just have to find something to do with it!
  • No ethernet/USB support. The VGA framebuffer uses the memory that is reserved for those components

Anyway, if anyone would like to contribute, I'd love it. Right now my top priority is a simple interactive programming shell using some usable language. I've evaluated Scheme, Forth, and Basic, but haven't found anything I can directly port to the mbed. If anyone would like to try their hand porting a language or even writing something from scratch, I'd most appreciate it! (Also, extra points for using a BSD-style license :) ) I'm really bad at implementing a language in C.

Other than that there is a ton of resources left in this tiny microcontroller to tap. Next on my list:

  1. SD card support
  2. file management commands in the shell
  3. possibly bitmap support for reading from the filesystem
  4. a simple game
  5. Maybe even add a speaker for some basic sound support

And tons of other ideas. What do you think would be cool to implement?

Also, if you want to read more about my latest MbedConsole stuff, or look at the history of it, just look at the MbedConsole tag

Posted: 9/30/2012 5:20:38 PM

Displaying Images On MbedConsole

So, I finally got MbedConsole to display a fairly awesome monochrome graphic. Surprisingly, I had a very hard time finding any decent converters from an image to a monochrome byte array in C.

What I ended up finding a tool that works decently enough. The image appears to require a bit of massaging to like to work with it though.

  • Make the image's width a multiple of 8
  • Turn the image into grayscale and then turn the contrast all the way up to convert it to monochrome
  • Don't use indexed colors. Use grayscale or RGB
  • Use a decent format like GIF or PNG

Also, it requires (in my opinion) a bit of massaging to print it to the screen. The bits in each byte are arranged backwards in my opinion. So, my print loop ends up looking like this:

int tmp=0;
for(int y=0;y<HEIGHT;y++)
    for(int x=0;x<WIDTH;x++)
        int byte=tmp/8;
        int bit=tmp%8;
        bit=bit-7; //bits are reversed! Those bastards!
        vga_plot(x,y, (graphic[byte]&(1<<bit))==0);

Also, don't try to compute tmp using X and Y. Just don't, I wasted 2 hours before I gave up and just made it increment for each loop.

I would show the image now, but it's a bit of a surprise :) Don't want to spoil it.

Also, I think I'm going to scrap the programming environment for right now. It's just taking too long and I want to release this thing already.

Anyway, more news later.

Posted: 9/30/2012 5:41:16 AM

More Progress for MbedConsole

Well, I've been making more and more progress on Mbedconsole.

For starters, I finally got the PS/2 keyboard working completely. So now getc and friends now point to the PS/2 keyboard and not the serial port. Also, I've added a few more commands than what I had. I also did a lot of other small things like resetting interrupt priorities so that the VGA console should only be disrupted during semi-hosting events(ie, LocalStorage), and probably if the mbed crashes.


As you can see, there is also plearlz. That's actually less of a work in progress than you'd think. I don't have anything "working" right now because it's in the middle of refactor, but it can function as a simple stack calculator so far. I'll consider it complete when I can add words, create "local" variables, and have looping support(which is nearly there, but not quite)


As you can see, the wiring for this project is extremely simple. Ridiculously simple really. I don't have a single real component on my breadboard! All I have are a few resistors. The only thing I might consider adding in the future is a few caps on the power and ground lines of each component.

Don't worry! I'm not just hyping you up for nothing! I expect to release the code along with a more detailed build report probably in a week or two. It's getting very close to "complete" now. What I consider complete is a self-hosting development environment. I'll of course continue improving on it after I release it :)

Also, in case anyone is searching for a PS/2 scancode set 2 map in C source code, here you go. A complete scancode set 2 to ASCII translation table/array. Also BSD licensed. I had to make this by hand. I've come to the conclusion that no sane individual should ever have to do this! Scancode set 2 is SOOO much more complicated compared to set 1!

Posted: 9/28/2012 5:00:56 AM

MbedConsole Status

I just felt I should update on the status of MbedConsole. A formal release is coming soon! I'll probably release it before my Forth interpreter is completely done after all though.

Anyway, I received my nice PS/2 Keyboard Breakout today. I soldered some pins on it and got it to read scan codes from a keyboard with a bit code. So that part is working pretty well. The next big thing is getting it to correctly translate those scancodes to ASCII text. I've done this kind of thing before, so it shouldn't be too hard.

So far, about 8K of RAM is used up in all of the overhead, which I don't think is too terrible. My goal is to have 20K available to the Forth compiler/interpreter thing and I think I will be able to easily manage that even with a couple of utilities. Of course, I'm also already up to 32K of Flash, but that's no big deal since I have 512K

Anyway, I expect to release the code in probably another week or two. Hopefully with some small demo of how awesome it is.

Posted: 9/26/2012 3:28:54 AM

Mbed Status Update

So, I've been working more and more on my recent mbed project. I've decided to go for something really interesting and not too hard.

The project is named MbedConsole because I'm bad at names. Anyway it will feature

  1. PS/2 keyboard support
  2. Monochrome VGA. 640x480, with text and/or graphics
  3. A simple shell
  4. A Forth programming environment
  5. About 20K or so of usable RAM for the Forth environment
  6. SD card support of some kind maybe

All of this works with no external components but a few resistors. This means, it's going to be awesome!

About the Forth environment:

I'm not aiming at all for Forth compatibility, but it definitely has a Forth feel to it(everything is in a stack). The big thing that this is enables is semi-self hosting.. That means I can write some system software in Forth. Because Forth programs don't constantly occupy RAM, this means I can make a "real" computer with a whole 20K of memory. After getting the Forth environment created I'd like to rewrite my shell to use Forth as well. If I really want to get awesome I could even write my Forth implementation in Forth and leave on the virtual machine in native code... I'm not that brave.

Anyway, the Forth environment was at first planned to be interpreted only. Now however, I've found that compiling to a virtual machine is about 10 times easier than trying to interpret it directly. It also will save memory, and probably will be faster. The virtual machine is extremely simple. and should already be Turing complete. Forth however is not quite there yet. It's easy to parse, but string handling in C is never quick to implement.

The end goal for me is to have a very retro-feeling operating system running on the mbed powered by it's Forth interpreter. Things I want to have:

  • A simple command shell for file management
  • A way to save the Forth programs you write
  • A simple text editor of some sort
  • At least one super simple game

If I remove graphics support, I can also add in network support, but I highly doubt there will be anywhere near enough RAM to be useful for Forth after including a TCP/IP stack. I believe it takes about about 16K by itself :(

Anyway, this project will eventually be released under BSD license. I want to get it half way working before I release it.

Posted: 9/21/2012 5:10:27 AM

New mbed project

So, I recently discovered that the mbed is capable of generating VGA signals without dedicating the entire processor to the task. This is the VGA library I'm using. It has quite a few limitations.

  1. No ethernet/USB/CAN because it uses one of the reserved RAM blocks
  2. Monochrome only. This actually is fine for every application I have in mind.
  3. Using the local filesystem screws it up pretty bad. Basically whenever a filehandle is open, the screen will vary from flickering to not syncing at all. After all handles are closed it acts normal though

Anyway, after I got it hooked up the first thing I wanted to get on it is a simple console. I have that now. In the picture below though I set it up to just print characters typed into a serial terminal.

Taya typing

Here, Taya is enjoying typing and is begging me to let her "play a game" heh. So, now I know what the next step is I suppose.

Anyway, when I get something that actually does something useful, I'll post the source code as BSD licensed.

Posted: 9/17/2012 4:59:39 AM

ILDump -- New mini project

I've created a new little project now which hopefully fill a small niche.

Basically, at my work I'm currently debugging an issue where subtle IL changes(such as adding a nop or slightly reordering a switch) exposes a bug in Microsoft's JIT compiler for .Net 4.5. I have two assemblies. One that works, and one that crashes. The only difference between them is subtle IL changes. They both do the same thing, have the same methods, etc.. and they work fine on a JIT compiler that isn't 4.5.

So far, my attempts at figuring out what's going on has been going very poorly. The main reason is that there aren't a ton of tools out there for working with IL. I know, I could dump the IL as C# or something with ILSpy, but the IL is so similar that it turns into the same C# code. Attempts to reproduce it in a smaller test case have went poorly so far as well.

My options were as such:

  1. Use ILDasm and then a diff program to figure out the difference between the programs
  2. Use Reflector to dump out IL like ILDasm, but also put it in separate files.
  3. Pound my head against the wall

So far, option 3 has been showing the most promise. The problem with dumping IL and then trying to diff it is that current disassemblers will prefix a label for the address of every line... this is fine except for when you prefer that every line doesn't have a difference when a nop is added that changes the address.

So, how does ILDump solve this problem? Well, first off it won't print out labels on each line unless another instruction "points" to that label. Also, because addresses don't stay constant, it can rename labels to something like Label1 instead of IL_0012, to make less false differences. Also, it includes a small option for trimming out NOPs, sorting by method name, and constraining it's output to a class/namespace.

Anyway, ILDump is BSD licensed over at BitBucket. It uses Mono.Cecil for it's IL parsing, and compiles/works on Mono and Microsoft .Net. Also, if you want to download a precompiled version, try out

It's a very simple tool, so there hasn't been a whole lot to do on it, but it's still improving by the day(hour).

Posted: 9/2/2012 6:57:05 PM

VT100 Terminal Interface

Long time, no blog. I've finally been getting settled down here in Cleveland, so expect to see a bit more posts here.

Anyway, my recent project has been a bit of an interesting thing on the mbed. I built a super simple curses "replacement" named TermControl. It's not really a curses replacement. It's basically just a very dumb class that prints out arbitrary escape codes that just happen to control a VT100 compliant terminal(emulator). It's pretty cool though. I made it because ncurses was just way too huge for the job I needed. All I need is a way to control cursor position and occasionally clear the screen.

Anyway, It's MIT licensed so use it, extend it, whatever.

Posted: 8/28/2012 4:46:28 AM

Moving To Cleveland

Well, if you're wondering why I haven't been around here for a while the past week or so I'll finally tell everyone why. I ended up accepting a job in Cleveland, Ohio. The company I'll soon be working for is PreEmptive Solutions. I'll be working on their Dotfuscator team. This means, I'll get to have a ton of fun learning .Net's IL.

This move also means I'll be going back to my "work mode". When I work as a programmer, I don't like to come home after 8 hours of programming and do more programming. So, my open source projects will likely see a decrease in activity as will this blog. Though, I do like having small weekend projects sometimes as well. Also, my work on the NVG510 will most likely completely stop. I'll have internet options up there other than U-Verse and won't be stuck with that crappy modem.

Also, this website will most likely end up getting relocated as well. I use Linode for my hosting; with this, I get my choice of data centers. Currently, it's located in Dallas, TX. I'll most likely move it though to New York, NY so that I have less latency.

Posted: 7/27/2012 1:04:06 AM