======Week 3 Update======
As we go into Week 3... just want to make sure we're all on the same boat.

As of 2:12pm Sunday Feb 6th, the repository is at revision 41. If you're not at or above 41, please do an "svn update".

Also-- any errors or problems encountered with subversion, let me know ASAP. I'm more than happy to help resolve any problems.. usually they're just conflict-related.

At this point, it would appear as though all the 7 basic logic gate classes are complete (check them out, under the boolops/ directory- they should all have working test applications that will display a truth table).

We'll be using these gates, and other components (some built with these gates) to continue building bigger things.

There is also a NOR-based flip flop (under the flipflop/ directory). This is by no means the only flip flop, so feel free to contribute others (a lot of stuff is built with the NAND-based flip flop / D-flip flop).

Of anything you'll encounter in this class, don't be surprised if flip flops seem to throw you for a loop. You'll need to stare at the logic for a bit to start grasping it.

Basically- a flip flop is essential to electronics because it allows for the ability to "remember" (ie memory).

The truth table for a flip flop often deals with "setting" a value, and "resetting" it (we're only dealing with one bit-- it is either on or off, and its purpose is to "remember" its setting). Additionally you'll note some extra combinations (including invalid combinations-- for example it makes no sense to set AND reset a flip flop at the same time)... some input combinations need to be considered with respect to time.

Take a look at the NOR-based flip flop to see how the truth table was pulled off.

I've heard a half-adder class is on its way, so be on the lookout for that.

Some items we can read up on and look at starting to implement:

  * half-/full-/adder circuit (understand what they do)
  * NAND-based flip flop
  * register (series of flip flops) -- aim for an 8-bit register
  * shift register (same but with ability to "shift" bits)
  * adder circuit (be able to "add" two registers together)
  * subtractor circuit ("subtract" two registers)
  * negation circuit (inverts a register)
  * copy circuit (copies a register)
  * clear circuit (clears a register)
  * memory (we'll want a few kilobytes at least)

======Subversion commits======
A behavior I'd like to tweak is to encourage everyone to commit a little more often (maybe with the exception of Anthony, he commits just enough).

What I'd like for you to do is consider committing after each "attempt", versus committing once everything is done.

I'd much rather see your implementation take the form of 5 commits over a few days than wait and wonder and then see it come in at the end in 1 commit. Plus, others can then have a chance to look at the code and use that as an opportunity to ask questions, tweak things, etc.

Feel free to leave comments in your code saying "this doesn't work / this needs fixing / need to do XYZ"... and add such things to the wiki TODO list as well. You don't have to be 100% responsible for things you start- you are responsible for being active on the repository and wiki.

With that said, if you find an opportunity to make changes to something "in progress", consider having a chat with the person or people who have put in some work to get any coordination issues out of the way before proceeding.

There are ways to look this information up.

For example, if you want to see who has worked on the boolops/nand/nand.cc file, go into that directory and type:

<code>
svn log nand.cc
</code>

This will give you the svn transactions specifically involving that file... revision #s, users responsible, and description.

If you wanted to go even deeper, there's the "svn praise / svn blame" command... for this, hop over to include/ and let's look at and.h:

<code>
svn praise and.h
</code>

At this point in time, we can see that 3 people have modified this file. You can use this to identify who is responsible for specific pieces of code, the revision this took place in, and the line of code itself (use "svn praise" when you want to do this to commend someone-- "svn blame" when something has gone wrong-- they both output and do the exact same thing).

======Adding files to Subversion======
Just to clarify- when you add a brand new file to the repository, you'll need to do an "svn add filename" and "svn commit" it.

On any further changes to that file, you only need to do an "svn commit"... it has already been added, so there's no need to add it again.

Again... try to commit after each attempt, work chunk, coding session, etc. that way there will exist a snapshot of the codebase as it evolves.

Let me know if you have any questions.