Saturday, May 31, 2014

Elements of Computing Systems: Chapter 4

This has not been a great week for me. This post was SUPPOSED to be a tutorial for making fluorescent lightbulbs run on batteries. The problem being, of course, that two months and entirely too much solder into the project, my lightbulb remains unlit. Sigh. So, instead I turned to finish Chapter Four, which describes the Hack machine language you'll be using in your computer. It only has two projects at its end, so I figure I can read through it quickly and finish before I start studying for finals.

This was before I realized that in Chapter Four, ECS throws all of its rational explanations and helpful examples out the window in exchange for a list of machine language commands whose functions remain a mystery after reading the chapter three times. I didn't actually finish this project on my own. I found solutions others had programmed and studied them in order to figure out what the code actually did. And this was after studying the Hack tutorial on the Nand2Tetris website and the forums. I'll do my best to explain my problems with the chapter, but considering I'm still not sure I understand it, the explanation may not be accurate.

The first issue I encountered was in their initial explanation of machine language. Their explanation uses syntax from some language other than Hack, which was very confusing.
Then they go on to their explanation of the machine's two memory registers: A, which holds information that can be used in a command as either an address or a value, and D, which only holds values. These registers are manipulated through an @ command. The @ command is not well explained at all. The book seems to say that it works like a pointer in the A register. Actually, it loads a value into the A register. Consider this code.

@R1             // This loads the word "R1" into some space in the A register
D = M           // M refers to whatever is currently loaded in the A register, in this case R1
                      // D is the D register, which is unaffected by @ commands, so it can store values that are
                      // used by multiple @ commands.
@x                // This loads the word "x" into some space in the A register
M = D           // In a higher level language, this would translate to x = R1.
                      // The program will now read R1 everywhere you type x

Some 'memory words' (a term not defined in the book, meaning "R1" or "SCREEN" if those point to a specific memory address.) appear to be predefined addresses, but these are never listed. One of the projects involves creating multiple loops, but the syntax for loop creation is never given. At one point the chapter detours to describe how C commands translate into binary, which is both useless for the project and intensely confusing. You have to clear each memory register before you use it, but are never told to do so. The list goes on and on.

I don't understand how others were able to create their projects from this chapter. I may have done an exceptionally terrible job with the reading and missed everything I needed to know. I've never used machine language before. I had no context for how it should work. After hours of study, I was able to recreate others' solutions for the projects, and I understand the language enough now to use it. But did it really have to be that difficult?

I'm also a bit concerned that there was no chapter where we created the Assembler and CPU (unless those are created in chapter 5 and we just skipped around a bit.) I understand that they may be too complicated for the course to include, I was just expecting to build the ENTIRE computer, not just the parts of it that were convenient.

Hopefully I'll find Chapter 5 easier to understand. It probably didn't help that it was the week before finals too, and every teacher assigned every project at once. The upside is, expect project posts soon! I've got two on mindstorms and one on tech theatre costumes as soon as they get back from the school.

Then it's on to summer! And summer means robots and space camp, so you know what? Chapter Four? Still worth it for getting me that much closer to having my computer BUILT.

See you next time!

Friday, May 30, 2014

Feature Friday: Solar Roadways

I come across more and more REALLY COOL THINGS that people have designed and made every day. Really cool things that I want to share with you guys, and that I think definitely deserve the publicity. I've decided to pick a project, plan, or product every week that I want to share the sheer awesomeness of.

This week, let's talk about the recently crowd-funded Solar Roadways.

A company run by a couple, Julie and Scott Brenshaw, Solar Roadways promises to bring clean energy to the streets. The two have developed a modular solar grid system, and they plan to cover every sidewalk, highway, and streetside across America that's been wasting away under the beaming sun. It's a far fetched plan for clean energy, but it's raised 1.6 million on indieagogo already, and the funding keeps coming.

Not only that, the couple proposes that their durable solar panels be equipped with LEDs to create light up symbols and warnings on the road, heating, to melt snow on the road, powering electric cars as they drive, and so much more. 

The solar roadways project is incredible because it is able to tie in so many under realized technologies (solar panels, electric cars, etc.) I would give you the numbers, but I think it's more effective if they do it themselves. Their fundraiser was so successful, it was extended for another two weeks. Everyone should take a look at this project, because it might be the future of our roads. "Walking on Sunshine" indeed.

Sunday, May 11, 2014

The Elements of Computing Systems, Chapter 3

Finished Chapter 3, all about memory and sequential computer chips. This chapter was generally easier than chapter 2 in my opinion, mostly because all except for one of the chips were just bigger, badder versions of others. Making RAM4k isn't any fundamentally different from making RAM512, so you can't breeze through each of those chips easily. Which is good, because the outlier chip, the counter, was the most difficult chip I found to implement so far.
Unlike the ALU, where my problems were born of my own poor decision making skills, the sequential chips are just more difficult to design. They require a different kind of thinking than the combinatorial chips, because you have to account for past values emitted by the chip and compare them to the value the chip is receiving now. Be ready to make good use of your multiplexers.

The counter itself is particularly difficult for two reasons. One, unless you take the time to look at the test and the .cmp files for the counter, it can be difficult to understand the structure you're aiming for in the chip. Two, the structure itself is complicated, and relies heavily on the order of the gates. I used the debugging flag tool in the software for the first time for the counter, and I was very happy with how it worked, considering I did a LOT of debugging over the course of the chip. If you have trouble, remember its called a sequential chip for a reason. Figure out the order things should be calculated first, then go from there.

  1. Also, the tests for the memory related chips can take forever to complete. If you aren't specifically debugging a certain section of the program, run the test with no animation, otherwise you may be sitting there for ten minutes.

Monday, May 5, 2014

Elements of Computing Systems, Chapter 2

Chapter Two took me significantly longer to finish than chapter one, but mostly because I decided to get cheeky with the software. Just because you can do something doesn't necessarily mean you should in the interest of efficiency or mental health preservation.

The second chapter focuses on translating the gates you've already made into the manipulation of binary numbers. As your project you build Adders, and Incrementers, and finally, your computer's Arithmetic Logic Unit, a chip for doing simple mathematical calculations using two 16 bit binary inputs.

This section's background information is shorter than the last, but before you start the projects at the end of the chapter, I highly, highly HIGHLY recommend that you read the entire appendix, telling you all about the software and the programming language. Read it through. Read it twice. Learn  how to use the software and the language , because when it comes time to use the ALU, it can be hard to distinguish between which problems are caused by syntax and which are caused by misunderstanding the concepts.

Like I mentioned before, while working on the ALU I got a little cocky, and decided to start designing my own chips and tests to deconstruct the problem. Two hours of hair pulling later, I find out the book has a section devoted to designing tests (although it specifies that a students really shouldn't need to do so in their projects). I discovered that my problem had to do with typing the wrong number of spaces in my .cmp file. Other fun problems included: linking the ALU's OUT pins to  an component chip, making an internal pin with a value of zero, and figuring out the difference between negating a binary number and making a binary number negative. These were all problems that could have easily been avoided had I read the appendix before starting the programming. Still, I feel that much more accomplished.

Another good resource is the forum. It's still very active, and there are plenty of people there willing to help with problems. They have a strict policy of not outright stating an answer, which I think is great, but I did notice that could sometimes leave the questioner be guzzled if someone was withholding information that would make it 'too easy.' So it shouldn't be your only resource, but I am 100% pro internet collaboration, and it appears to work well for this project. I'll be sure to set up an account for chapter 3.

With my ALU finally functional and a lot more HDL know-how under my belt, I'm ready to press forward and onward in the world of binary logic. Chapter 3 awaits!