Here we are, week 5– last week before our first break!

I'd like like to say, I continue to be impressed with our Computer Organization experience so far- not just the code being developed, but the interactions that have taken place, and the natural evolutions that have transpired. At this point I can say I am pleased with the efforts of EVERYONE in the class. I have had the opportunity to communicate with everyone, and even if everyone is not certain, everyone IS determined to work on the project and learn, and THAT ultimately is what is important, and will drive the successful completion of our efforts.

This was not intended to be an easy undertaking. We're in an upper level course exploring some very important concepts through the implementation of our various digital components. That we have made it this far should be viewed as nothing less than rewarding, and I look forward to the weeks ahead.

Last week saw increasing activity with regards to the 8085 and 6502 efforts, along with tweaks to existing components (the adders especially).

As of this writing, we're at revision 137.

Perhaps the 3 persistent frustrations that have been on-going in our experience semester are the following:

• “I don't understand X” - some have raised concerns that they haven't had exposure to these concepts before (AND, OR, NOT), and think they're behind. Believe it or not, knowing this stuff is not a prerequisite, and I think a lot of progress has been made in getting familiar with these new concepts (if anything, these concepts were first introduced in Computer Essentials, and have been touched on again and again in other courses). The specific gate logic is in many respects more terminology awkward than concept awkward. It is just a matter of applying the concepts to the particular application (granted, often a difficult thing, but then again that's why we're here).
• “What should I do?” - since this group development experience is still somewhat new to many of us, there has been concern over what contributions to make. Mixed with learning a lot of material for the course, how to turn around and immediately start applying it? The wiki “TODO” list and the more proactive “Who's doing what” efforts have hopefully helped to smooth this transition.
• “Other people commit over my code” - inevitably in any group development situation, as everyone is learning, mistakes are made. And I know this has happened on a few occasions. Not that it is the end of the world- if you've committed your code, it is in there, even if it is not present in the current revision. No changes are therefore actually lost, and who knows, at some point in the future some old changes could resurface. That's the beauty of a version control system, the past is not forgotten.

One of the first evolutions I witnessed was the stepping up of one of the class members to be a project coordinator. If you haven't responded to any of Sam's (sweller5) messages or updated the pertinent sections on the wiki, I'd highly recommend you do so. It is an investment that will help the overall project go much more smoothly.

Just on Friday, another evolution took place that I want to inform everyone of. Justin (jhammo13), in contemplating some of the above-mentioned frustrations, offered to take on a role of Documentation Coordinator, working to:

• fill in the gaps on the wiki for all this pre-requisite knowledge we've all been independently researching
• create a getting started tutorial to help us and future iterations of ourselves commence on a project of this nature
• flesh out the existing documentation more, so everyone can understand the contributions better
• communicate with everyone regarding particular submissions to get any specific backstory on coding implementation (reasons to the madness, etc.) to appropriate reflect that on the wiki so others can more easily work off those contributions.

The intent with this Documentation Coordination effort is to be more documentation-heavy and then balance out with coding contributions as the semester continues to unfold. Just as we have some coding-intensive groups, this is a counterbalance. I welcome those who feel somewhat closer to the frustrations to contemplate offering some services to the Documentation Coordination efforts as a means of getting more accustomed to various intrinsics.

If you'd like to take advantage of this, you need to do the following:

• notify sweller5 and jhammo13 of your intent to be more documentation heavy for the moment (even posting a message to the mailing list would likely be a good thing, as well as updating the wiki).
• communicate with jhammo13 and the documentation group to figure out a plan of attack- this can involve the whole class (ie use the mailing list), and figure out how everyone is going to tackle what.
• the 2+2 commits+wiki edits still applies (work on commenting existing code).
• help drive communication on the project, through mailing list communication, irc, or seeking out individuals to get their take on a particular piece of code. I want the focus behind this to pull out more communication and help toss ideas around.
• as you work on documenting, and you find code errors, insufficient code documentation, or missing functionality- please do take the initiative and contribute such!

For those more on the bleeding edge implementation of things– please offer up tasks that need to be done, especially if they seem repetitious or largely redundant in nature… I'm especially thinking of “op code lookup” when the 8085/6502 implementations get to that– once you get the necessary framework in place and are satisfied with having cranked out a few working instructions, offer up the task of implementing some of the instructions- add it to the TODO list, communicate with the documentation group to let them know what has to be done.

I'd like for this to strike a nice balance for everyone- for everyone to learn, for everyone to share, and for everyone to play a part in implementing the project. Like I said, I think we're off to a good start, and this latest structural tweaking is intended to assist those efforts as the code base explodes in size and complexity.

Some will be drivers- leading the development.

Others will be implementers, filling in the gaps and making complete the idea.

Yet others will round the edges and tweaking other matters (documentation, end user operation, code maintenance, etc)

In addition to the concepts unearthed in implementing this CPU simulator, I want everyone to walk away with an appreciation of working in a collaborative development environment. You will find that the more efforts invested in helping the group, the more you will learn and benefit.

Remember: nobody is on their own. If you feel like you are, or feel lost, you need to take some steps to become more involved.

Those are three new terms that should make everyone's list of topics to investigate. There has already been planning in this regard towards putting the beginnings of that together for at least the 8085. Those on the documentation group may want to talk with bewanyk and jr018429 on some of their brainstorming, and perhaps even transport some of their whiteboard diagrams to the wiki on some appropriate page.

I think the 6502 group is close at hand, and this information is fully applicable to ANY CPU implementation. So it certainly benefits everyone.

You'll be amazed at how quickly functionality will start to materialize, and clarity established with regards to implementing an interface to work with the CPU, as we get to this point.

Be excited.