softHARDsoft

The Machine That Changed the World

2009-07-12T15:50:00.002-04:00

Another detour from the creation of our virtual computer:

On waxy.com, Andy Baio has uploaded the series The Machine That Changed the World. This 5 part miniseries from 1992 feels dated for obvious reasons but the history is as relevant as ever. The making of this documentary was particularly well timed -- there are interviews with several computer pioneers -- many of whom passed away within a few years of its filming.

It was digitized from VHS so the image quality leaves something to be desired. However, this is the first time this classic series has been digitized at all and Waxy.com was kind enough to put it online so we can all enjoy it. You can stream the videos online as flash or download the high-quality MP4 files via BitTorrent.

Much thanks to Waxy.com for making this gem accessible to all!

Reckoners

2009-07-09T15:08:00.002-04:00

We're examining the base elements of a computer to build a conceptual one of our own. In the post How to make a machine "think" we settled rather easily (too easily?) on the idea of using binary for the basis for our computer's anatomy. There are very good reasons for this but the main one is that we're constructing a modern styled computer and are thus doing stuff like they do it. Is this the only way? Have computers always been this way?

The answer to both questions is a resounding NO.

To see how we got where we are, we simply have to look to our history. The era of the very first digital computers is one place to look. By definition, these machines were built before computer science or such theory. The pioneers had no roadmap to follow. Great ideas, trial and error, and creative minds had to fill in all the gaps without Charles Petzold to be their muse!

Would the pioneers have chosen to use binary? Did the first general purpose computers have memory parts separate from arithmetic parts? Why did some choose binary and some choose decimal? These are not trivial questions. The answers show us where we started, how we got where we are, and why.

Maybe we should totally stop designing a computer for a while and review these innovative decisions. Maybe we should, but we won't. We've had quite enough detours for a while. However, I highly encourage you to read up on the matter.

One excellent (and free) resource is Reckoners by Paul E. Ceruzzi and it's free online. Reckoners looks at the creation and anatomy of some of the worlds first general purpose digital computers. It can be a bit dry at times when it delves into too much detail, but overall it is a fantastic book. If nothing else, it's absolutely worth reading the chapter on the very first completed digital computer. Only a German engineer could possibly have conceived of and then built computer memory units using moving parts -- no transistors (they didn't exist yet), no relays, just machine!

The ancient history of computers is absolutely fascinating. Anyone interested in a grassroots project like softHARDsoft will love reading about the original beasts.

Inputs and Outputs 4: output limitations

2009-03-26T20:31:00.002-04:00

We're now clear on the limitations of inputs. What about limitations on outputs?

We actually kinda covered this in the bottom diagram back in Art Imitating Life. This was a diagram of sequential logic.

Notice the output of the left-most element. It splits and gives its value to the inputs of multiple other elements. One could argue that the node where the split occurs is its own element, but I think that's overkill. For our design purposes, let's just say that an output can give its value to any number of inputs. Or to use our new terminology about the observer pattern: a subject (i.e.: an output) can notify any number of subscribed observers (inputs).

Short post this time. Not much to say about this topic but it still needed to be said.

Inputs and Outputs 3: subscriptions

2009-03-25T15:53:00.004-04:00

There was a major to-do item from our last code post (9-11-08): how does the input find out about the value of the output? We know from the "push or pull?" post that the outputs will push their value to the inputs -- but how? Whenever an output changes it needs to know who to tell. The input that wants this information needs to tell the output: as soon as you change, tell me. This relationship (as implied by the title of the post) is that of a subscription service (outputs) and subscribers (inputs).

An output needs to provide a way to:

add a new subscriber
unsubscribe a current subscriber
notify subscribers
make its state known

An input needs to:

be updated when a change occurs

In the programming world, this is not a new problem. There is a time-honored solution to this called the "observer pattern." The pattern describes Subjects and Observers which correlate exactly to our Outputs and Inputs. This problem is so common that in .NET they built in a way to do most of this work for you: .NET, "Events" will give you all of this. Since we're doing this in C# anyway, I'm opting for events. Events have added benefits which we may also take advantage of later.

CODE: http://downloads.softhardsoft.com/2009-03-25.zip

Inputs and Outputs 2: input limitations

2009-03-21T13:20:00.007-04:00

It seems obvious that an output can push its charge to any number of inputs. What's less obvious is whether multiple outputs can feed into a single input.

Expanding on our trusty light bulb setup from last time: instead of having 1 power source + switch before the bulb, lets have 2 sets like this in parallel. Now if either switch (or both) are closed then the bulb lights up.

Stand in awe of my mighty illustration skills!

There are a few ways to handle this:

The bulb's input can accept from multiple output sources
The output sources combine into 1. If either or both sources are charged, the bulb lights up. This is an "OR" relationship. Expanding on that:
The sources must enter an OR gate and the single output from that gate will be the bulb's input

These solutions go from most simple to most complex, so why don't we choose the 1st and simplest? Actually, there is a reason and it's largely academic. What we're doing in sHs is an exercise in "sequential logic." That is: using boolean (on/off) values, we're moving in a linear sequence, evaluating as we go. This is a very old idea and there are certain conventions that are used. #3 above follows said convention.

Make no mistake, we are in no way bound by these conventions. There are no teachers standing over our shoulder ready to whack our knuckles for doing our program in an unorthodox or colloquial way. Back in Transistor choice when we were trying to choose whether to use MOSFET+CMOS logic, I had no problem justifying a simpler way of doing things. However, in this case, I'm still going to opt for #3 anyway because it makes sense in my mind.

Regardless of which option you prefer though, we should all agree on one important point: the multiple inputs must resolve to a single collective ON or OFF value before we can determine whether the bulb should light. Any of the 3 above can achieve this.

Inputs and Outputs 1: push or pull?

2009-03-16T23:09:00.005-04:00

Pushing vs. Pulling

I made an assumption in the last post: that outputs would give their values to inputs. Why couldn't it be the input's job to get their value from the output? (In programming, this give vs. get distinction is often referred to as pushing vs. pulling.)

The first reason to push is because it's intuitive. Why is it intuitive? Because that's how it works in real life. Why not make our programming metaphor follow reality when we can?

Here's a simple example: Let's say we have a simulation with a power source, an open switch, then a light bulb. Now we'll close the switch.

Push: when the switch is closed, it pushes its new "on" state to the light bulb and the bulb lights up.
Pull: when the switch is closed, the light bulb somehow knows to inquire whether the switch's state has changed. If the switch is still open, the bulb stays out, else it lights up.

To me, the pull method seems backwards. How does the light bulb know to inquire? There are actually plenty of common and logical solutions to these kinds of problems, but for now I see no reason why we shouldn't stick with the push method.

Code Downloads!

2008-09-11T21:23:00.004-04:00

Downloads of all softHARDsoft code can now be found here: http://downloads.softhardsoft.com/

Reminder: the license I'm releasing the code under is Creative Commons: Attribution-Share Alike 3.0 Unported

The page will remain pretty Spartan but functional. Enjoy!

Zen of a Virtual Circuit

2008-09-11T17:11:00.008-04:00

In How to make a machine "think" we considered a basic logic where:

Any piece's output can be another's input.
Use only 0 and 1 (boolean: TRUE and FALSE).

By meeting our second requirement (ie: by only passing around boolean values), we also satisfy our first requirement. If some items only accepted numbers, some only letters, and if outputs were similarly varied, then we'd have to specialize families of circuits right off the bat. As it is, all inputs and outputs are of the same type: boolean. Need the output of an OR gate to be the input to a transistor? No problem. Any output can go to any input as-is.

We now have the foundation for an infinitely modular system -- Logic LEGOS!*

So what is a circuit?

In a general sense, any piece of logical hardware can be a circuit. Any collection of circuits can also be considered a circuit:

transistor
inverter
full adder
Pentium processor

This is the beauty of our modular, LEGO-like architechture. With "circuit" being such a flexable term, we can build any manner of abstraction, and to us it's still just a circuit. It can still connect with any other circuit irrespective of how work is being done inside each one.

Not that there aren't differences. Never mind the stuff inside. The outsides are very different too. Transistors have 2 inputs and 1 output. Inverters: 1 in, 1 out. Full adders: 3 in, 2 out. The Pentium processor, lots of each. Obviously we won't be able to statically define how many inputs and output a circuit can have. But we do now have some basic definitions for our first interfaces:

Circuit: has some number of inputs and some number of outputs
Input: accepts a boolean value
Output: each emits a boolean value

All of our circuits, no matter how simple or complex, will boil down to this. They'll have some number of inputs, some outputs, and stuff hidden in the middle to turn inputs into outputs.

That's about all there is to say about this layer of the onion. Next we'll dig deeper on how our inputs and outputs need to relate to each other.

CODE: http://downloads.softhardsoft.com/2008-09-11.zip

* From wikipedia: "The word LEGO® is a brand name and is very special to all of us in the LEGO Group Companies. We would sincerely like your help in keeping it special. Please always refer to our bricks as 'LEGO Bricks or Toys' and not 'LEGOS.'"

Yeah, well build a bridge and get over it. I've never met anyone who calls them "LEGO Bricks or Toys." Like it or not, everyone outside of that company calls them "LEGOS." I have nothing but the greatest admiration for these toys, but I have no use for their PR pride.

Art Imitating Life

2008-09-10T20:43:00.006-04:00

In Transistors: Our Lowly Beginnings, I said:

I'm going to spend as much time as necessary getting a rock solid transistor emulator working.

I really meant not so much the emulation of the transistor proper, but rather the infrastructure that will be the foundation for the whole project. The first decision to be made about our architecture is:

How do we want circuits to work?

In circuitry schematics (which is to say: in real circuits): electricity travels in a closed loop. If the loop is opened (ie: interrupted, broken), then the electricity ceases to flow. The electricity always has to come from somewhere and go to somewhere. If we put a wire against a battery's terminal and touch the other end to a light bulb, the bulb stays dark. If we use another wire to go from the bulb's other terminal back to the battery's unused terminal, the bulb lights up.

In logic diagrams: there's a linear source/input and destination/output. The output is not required to go anywhere. If you connect a lamp to the output of a circuit yielding "on" (alternately: "high", "1"), then the lamp lights up.

Either choice would be acceptable. Creating a viable circuit would involve creating not only transistors, but also resistors and all other electrical components that make the physical processor function. softHARDsoft is ambitious enough without starting out that complex. In fact, I very much doubt we'll ever get that complex: at the beginning or otherwise.

The assumption behind our goals so far has been: we'll make a program that simulates a computer's logic at the most fundamental level. To this end, let's model our circuits not on real circuitry, but on logic flow. Let's use a non-looping system.

The August of Crickets

2008-08-12T21:11:00.006-04:00

Man, it's so dead on this blog you can almost hear crickets. What happened? Are we running out of ideas? Did we lose ambition? Was it the car wreck?

No. There are 3 reasons why softHARDsoft has been so dead lately:

Time is being split between this project and another one.
Work has been stupidly overbearing and exhausting.
sHs is now starting to move beyond casual blog posts and into the realm of real planning (so writing would be less frequent anyway).

sHs has certainly not been abandoned nor forgotten about. It just needs to take a back seat for a short time. We'll be back in full swing soon enough. To our few readers at this point: thanks for staying with us so far, and we promise to be back as soon as we can!

Transistors: Our Lowly Beginnings

2008-07-25T08:28:00.006-04:00

The lowest level that softHARDsoft will implement is transistors. They work on pure physics and going any more basic than that seems a bit silly for our purposes.

Transistors can be used as amplifiers or switches. They are the bedrock of the rapid advancement of electronics over the last 60 years. These tiny wonders can be used to amplify signals (as they are used in transistor radios and hearing aids) and can act as on/off switches (as is the basis for computer logic).

In Transistor choice, it was explained that we'll start with bipolar junction transistors (BJT transistors). These have the most basic construction of all transistors and for our purposes, they'll work as well as any of the others. In fact, they'll work better than the others because they'll be the easiest for which to to write emulation software. I'm going to spend as much time as necessary getting a rock solid transistor emulator working. It cannot be emphasized enough that all computer logic comes back to transistors. Everything.

Anatomy
A BJT transistor has 3 regions: emitter, base, and collector. Here's how an NPN* BJT transistor works: When current is available at the collector, applying a tiny current to the base causes the emitter to emit an amount of current equal to the sum of the other 2. The sum of the currents is how amplification occurs. More importantly to us: the transistor acts as an on/off switch when we add power to or remove power from the base.

Now that we have a switch that is activated by electricity, we can use electricity to take action on other switches.

* There are 2 types of BJT transistors: NPN and PNP. The choice for which to use is arbitrary so we're using NPN.

How to make a machine "think"

2008-07-18T22:38:00.000-04:00

Logic
I know we've really already predicted the answer to the question "what do we need?": we need the parts that make up a computer. But we haven't determined why those parts the most appropriate? Why transistors? What benefit do we gain from them? What will they allow a computer to do? For that matter, what do we need our computer to do in the first place?

What computers do is obvious. It's right there in the name. They compute. They take input data, make decisions, and give output data. To make decisions, there needs to be some kind of predictable logic.

What kind of logic can a machine use? This logic needs to be a type that a non-thinking thing can do on its own. There needs to be well-defined concrete input data. If we want to make complex decisions then we need a type of logic where the output data from one decision can be the input to another. To that end, no output can be undefined. If it were so, then we could have undefined input which we've already said we don't want. Our options for well-defined input/output is seemingly limitless: letters, numbers, words, etc. Is one type of input more useful than another?

Conveniently enough there is an existing logic we can turn to for help. This type of logic is well established, is fundamental in math and language, has very few rules, and the rules it does have are all simple: Boolean logic (also known as binary logic).

In Boolean logic, data can be either TRUE or FALSE (alternatively: 1 or 0, on or off). Our TRUE and FALSE can relate to each other in a small number of rules that resemble pre-algebra. In keeping with the obvious minimalist theme of this logic, there are only a few relationships (aka: operations) and each is based on only 1 or 2 inputs at a time. With the NOT operation, you can turn one input into its opposite. You can also see if two inputs are the same as each other (XNOR), if both inputs are true (AND), if at least 1 is true (OR), or if one is true but not the other (XOR). Really, XOR and XNOR can be derived from the other 3, so there are only 3 fundamental operations.

That's it. There's 100% of the basics of Boolean logic.

Although this feels very limiting compared to the possibility of using numbers and words, this is in fact all we need. For now please trust me. It'll be more apparent later.

Switches
Enough with the theoretical stuff, how do we get a machine to implement binary logic? Obviously, the on/off state of our data calls to mind light bulbs and light switches. All that remains is to figure out how to implement the 3 logical operations mentioned previously (NOT, AND, OR).

It turns out that the key to implementing the logical operations with electricity is just a matter of using switches wired up certain ways. If you want an AND situation, hook up 2 switches in serial. For OR, hook up 2 in parallel. For NOT, just change the switch's current position.

Electronic Switches: FINALLY, Our 1st hardware
Unless you want to sit there manually toggling switches all day, we need a way to have that part done for us automatically. We want switches that themselves can be controlled by electricity.

Enter: transistors.

And that's where we'll pick up next time.

Transistor choice

2008-07-15T19:27:00.007-04:00

As I said in I know nothing, the inspiration for softHARDsoft comes from Charles Petzold's Code: The Hidden Language of Computer Hardware and Software. Throughout the book, Petzold designs a computer out of relays. Toward the very end of the book he reveals that transistors and not relays make real computers these days.

Although I knew this fact, what I didn't know until fairly recently is that the transistors of modern computers are not just the common BJT transistors* described in hobbyist electronics books. In actual processors, MOSFET transistors are used. Especially when MOSFET transistors are arranged in CMOS logic, there are significant gains in electricity usage and heat released. These are huge concerns when you're stuffing a few hundred million of these jokers into a couple of square inches. Not such a concern for sHs where all hardware is virtual.

However, that leaves me with a dilemma: do I try to really emulate a processor by creating the internals of my logic gates using MOSFET+CMOS logic, or just plain old BJT-styled transistors? For now I'm going to do the latter and revisit the issue later if I feel like it. I feel I can justify this choice because I am in fact looking at design a computer. It doesn't have to be accurate to modern computers. In fact, this whole project is ambitious enough without trying to hold myself to such standards; especially at the beginning.

* I realize that "BJT transistor" is redundant since the T stands for "transistor." But to amateur ears like mine, the sentence flows better than calling them "BJTs." Likewise with "MOSFET transistors" vs. "MOSFETs."

Follow-up to Code?

2008-07-10T14:24:00.006-04:00

Almost a decade after the fact, it's no real surprise that Charles Petzold doesn't intend to do a sequel to Code, however it was still disappointing to hear when I asked him directly. His email reply to me:

I don't think this is precisely the book you're looking for, but I *do* think of my new book as a sequel to code:
http://www.TheAnnotatedTuring.com

Oh well. I'm sure I'll still read this book when I find time.

You can purchase The Annotated Turing from Amazon or through links on the official site.

[Update: Charles Petzold stated as much here a year ago but I only just became aware this post of his.]

Hiatus

2008-07-07T17:03:00.002-04:00

I got into a pretty severe wreck over the holiday weekend. We're all ok but this has left me with a long to-do list of things more important than sHs. I'll still post here when I get around to it but who knows how frequent that will be.

Ford Crown Vics don't get very good gas mileage but they protect you really well from damage. This easily could have been fatal.

I know nothing part 2: A tribute to Dion Polk and Robert Rodriguez

2008-07-02T08:15:00.005-04:00

In college I had one class with a guy who did webpages as a hobby: Dion Polk. He was an older guy ("older" compared to a kid fresh out of high school) that I hung out with after class quite a bit. I owe him a lot. What did he do for me? Very little actually. We'd talk after class, I'd ask him questions about how he wrote webpages, and he enthusiastically answered my questions. The big thing he did for me was write down a url for an online tutorial for HTML. You can hardly go online now without tripping over a million such tutorials, each one equally as good as the one I saw then, but back in the pre-Google days of the internet, such wasn't the case. Back to my point: Dion's can-do, can-learn attitude reinvigorated my passion in technology.

Flash forward some [mumble, mumble] years to watching the extras on the DVD of Sin City. Love it or hate it, Sin City is a visual masterpiece. On the DVD, co-director Robert Rodriguez spends some time explaining his mantra of "Mariachi-style" movie making -- where "creativity, not money, is used to solve problems." He talks about how he got into the movie biz and tells how he did pretty much all jobs himself. Then he casually mentions how the viewer can do pretty much all effects seen in Sin City using an inexpensive camera and the free software that's probably already on their laptop. I was floored! He's really suggesting that your average person can do this. In fact, he himself did this in many professional movies -- including for all the stunning visuals in Sin City.

Although I was interested in computers since childhood and got pretty good with certain aspects, especially for a kid, I largely abandoned computers for my teenage rock n' roll years where I spent most of my non-school time playing in bands. In fact, throughout high school the only programming I did was writing pseudo-BASIC scripts on a graphics calculator to figure out my math formulas for me. Learning all this "computer stuff" in college was really starting from scratch. But I did it. One step at a time. From then until now I have faced countless times where I started out completely deficient in the knowledge needed for my desired field. Until I learned more. Now I have a fledgling skill-set I'm starting to be proud of. Not because I'm special or overly smart - I'm not. Not because I learned it in school - I didn't. It's because I said I can - and I did.

I know nothing 1 of 2: Confession

2008-06-30T09:00:00.006-04:00

"I know nothing except the fact of my ignorance."
- Socrates

Time to come clean: everything I've said so far is true but potentially misleading. Although I really am a professional software developer, and have been for years, my hardware experience amounts to reading 3 or 4 books and as many dozens of articles. I know the concepts of assembly but have never written a complete usable program. C++ made me almost pull my hair out and I've only written rudimentary programs in C. So what the hell makes me think I can remotely have a chance at accomplishing my goals in softHARDsoft?

I got my initial inspiration for this project after reading what is hands-down the most amazing computer book I've read in my life: Charles Petzold's Code: The Hidden Language of Computer Hardware and Software. Code takes you step by step from the basics of electronic circuits to a conceptually viable computer in 400 pages. His attitude is that anyone can understand this if it's properly explained. I completely buy into this. After reading Code the first time, a little idea started swimming around in the back of my head. I wanted to pick up a lot of relays and build a simple computer. It didn't take long to realize that buying just a few thousand relays at $2-3 a piece wasn't going to happen. (Not to mention the electrical engineering aspect, on which I've only ever read 2 or 3 books.) However, I knew I could learn just as much by building my computer from the one resource that was essentially free: I could write it all in code. The benefits of doing it in code are too many for me to ignore:

Free, other than time.
All components are the ideal versions of themselves. No shorted circuits. No size constraints. No interference from other parts. No decay, breaking, or burnout. Many real world inconveniences disappear.
The state of any part can be examined at any point.
Components I don't feel like doing yet can be ignored and I can write a good-enough approximation until I want to come back to it.
Parts can be swapped effortlessly. This will be especially relevant for the previous point as well as for writing improved versions later.
Code is what I know best. I don't have to spend months getting passably good with electrical engineering just to get to the point that I can physically construct a half adder.
Any component, no matter how rare or expensive in the real world, is at my disposal as long as I can learn enough about it.

There are more reasons but you get the idea.

The other reason I think I can accomplish a lot of my goals for sHs is: this is all learn-able, I just haven't learned it yet. This is the life story of anyone self-taught at anything. There was a time when none of us knew thing one about computers. Now we do. We learn. And that's all I need to do to make this work as well. Learn.

Licensing

2008-06-27T08:07:00.000-04:00

This post is brought to you by the letter 'C.'

I didn't want this licensing decision to be hanging over my head forever so I picked one that looked good enough for now. This Creative Commons license I've selected basically says the following about this software:

You can share, copy, distribute, and transmit it.
You can remix, adapt, and alter it.
If you alter it, give credit to the source and extend these same rights to others.
Don't use it in commercial stuff.
If you want exceptions made for you personally, just ask. The copyright holder can grant additional privileges.

The lion's share of what I've learned about programming has come from open source communities with licenses such as the one above. It's only fair that I reciprocate in kind.

Version control 3 of 3: installation

2008-06-25T10:05:00.003-04:00

I'm kinda getting tired of talking about version control software. As I said before, my interest is for it to be a means to an end, not a focus itself. To that end, I'm going to go through my installation then get on with the real purpose of softHARDsoft.

What I'm actually installing is Fortress. It's an ALM (Application Lifecycle Management) software suite that is made by SourceGear: the same company that makes Vault. It has everything Vault has and then some and is also free to single users. To use for a single user, simply do not enter any serial numbers (license keys) and it will default to single license mode. The official setup guide is here.

Download Server and Client from SourceGear.

FORTRESS SERVER
To set up a Fortress (or Vault) server, you need:

Windows XP Pro or Windows 2000 SP3 or above
IIS 5 or above (included in any above OS)
.NET Framework 1.1 or 2.0 (free)
SQL Server. 2000, MSDE 2000 (free), 2005, or 2005 Express (free)

I'll be using XP Pro, IIS 6, .NET 2.0, and SQL Server 2005 Express.

IIS
I already have XP and .NET set up. Next, I'll install IIS. Although I long ago removed an old web server I was no longer using (Apache), for some unknown reason I'm unable to start IIS on port 80 -- so I set IIS to 8080. When you install .NET after IIS, the .NET installation does some configuring of IIS automatically. When you do it in the reverse order as I have, you have to run aspnet_regiis.exe -i to get it configured.

SQL SERVER
I installed SQL Server 2005 when I first installed Visual Studio 2005. However, I never use it and have long since set its Windows service to Manual. I set it back to Automatic and started the service. I'm not that familiar with SQL Server so I hope Fortress's installer file takes care of most of the SQL Server configuration for me.

After finally being done with the prerequisites, time to install the server. One oddity on my computer, when it asks for a SQL Server, the default "(local)" option isn't working. I downloaded the free Microsoft SQL Server Management Studio Express to get a better idea of what my server may be called. The default in SQL Server Management Studio is "COMPUTER-NAME\SQLEXPRESS". (Hmm, maybe I have SQL Express after all.) When I try this in the Fortress installer, it works.

The last step of the install took a while to run, but it worked.

FORTRESS CLIENT
Although it takes a couple of minutes to run, it's a no-brainer install.

Enough of this stuff. I want to start the real planning of sHs.

Version control 2 of 3: selection

2008-06-23T09:44:00.004-04:00

At work I use a source control system, ClearCase, that integrates very well into my IDE, Visual Studio 2005. What I really want is a cheap or free integrated version control system to use at home. My other need is that I'm setting up a tool to be a means to an end. I'm not looking to invest any more time than possible to learning the nuances of it. I want it to be intuitive. I also want it to be popular so when I hit a snare that I have to Google, there will be plenty of available information addressing my problem.

After poking around online, I found, not surprisingly, that everyone has a favorite and theirs is objectively the best. Seriously though, what I found that matched my criteria the closest is: Subversion + TortoiseSVN + AnkhSVN. I'm heavily influenced by those I respect and I was also swayed by Subversion etc. being recommended by several people who I admire in the coding world. Namely Scott Hanselman, Jeff Atwood, and a CodeProject article with an incredible 4.73/5 rating.

No sooner had I settled on Subversion et al than I found out that my old friend Vault is free to single users! I've heard great things of it and honestly I still feel a little guilty that I never gave it a fair chance at my last job. What about all of those recommendations? That actually almost kept me sold on Subversion but Vault comes with a great recommendation as well. It was started by and is promoted by the amazing Eric Sink.

I still think Subversion + TortoiseSVN + AnkhSVN sounds like a good combination but I'm going to try Vault.

Next: I'll detail my the success, or lack thereof, of the Vault installation.

In case these should be useful later, here are my collected links for the Subversion based trio:

Source Control with Visual Studio .NET
Setting up Subversion on Windows
Visual Studio 2005 and TortoiseSVN Subversion Integration - and other posts
Guide to Versioning a Visual Studio Solution with Subversion, TortoiseSVN and AnkhSVN
Hack Attack: How to set up a personal home Subversion server
Hack Attack: Using Subversion with TortoiseSVN
Get up and running with TortoiseSVN and Subversion in 15 minutes
AnkhSVN: Using Subversion within Visual Studio
Version Control with Subversion - free online O'Reilly book
Visual SVN - another highly recommended Subversion with Visual Studio integration

Version control 1 of 3: taking the plunge

2008-06-19T11:18:00.003-04:00

Quite fitting to the mentality behind softHARDsoft, before I start any coding I want to set up source control. Before any step in the process, there always seems to be another step to do first.

In my first job out of college, I was involved in designing technologies but not actually doing the coding. In my next job, at which I worked for a long time, it was almost all coding and I was a self-taught one man army. I kept up with my code and did regular back-ups. Even our other developer teams didn't use version control so I saw no use for it.

During my last few months there, another developer and myself began working closely together and it took no time at all to realize that we needed a real system to synchronize our stuff. (I refuse to admit what we did until we broke down and came to this realization.) In his prior job, he'd used been forced to use Visual SourceSafe (VSS). For our collaborative project he recommended Vault, a version control system which is marketed as a VSS replacement. We started using Vault and I hated it immediately.
Want to change some code? Here's what I was used to:

step 1: open IDE
step 2: change code
step 3: save
step 4: there is no step 4

Now we had to do this:

step 1: open IDE
step 2: check out file
step 3: write a comment for this check-out
step 4: change code
step 5: save
step 6: check in
step 7: resolve version conflicts

Which is to say: I'd entered a real development team.

That company started to tank so I left and joined my current company where I've been for a few years. Here, from day 1, I've used a source control system called ClearCase. When ClearCase is good, you hardly notice it's there. When it's bad, things go 110% wonky and you find yourself wanting to find a new job rather than continue to use this demonic software. My only saving grace at work is that one of our founders has been using ClearCase at various jobs since the software first came out. He's a guru at it and can fix any of its idiosyncrasies.

I'm embarrassed to admit that although I code frequently at home, I have never used version control there. Every so often I'll decide to do so, find it too frustrating to set up, and put it off yet again. I've found myself wishing for the capabilities of version control countless times but my procrastination has prevented me from taking the plunge.

That ends now.

I want source control for softHARDsoft and I want it for my other home projects as well.

Predicted path

2008-06-17T09:33:00.003-04:00

Predicted path of softHARDsoft

soft
Since it's what I'm best and fastest with, the initial hardware simulator will be written in C# (.NET 2.0) running on WinXP. There are steps below in the 2nd soft section which will require a lot of assembly and/or C programming. After that, it may be desirable to come back and redo this in non-managed code for speed. Frankly though, I'm pretty excited about starting and I want to begin with my most rapid option.

HARD
create transistors
create simple circuits
create common circuit combinations
create computer components:

memory
CPU: My original thought was to simulate a 8080 or 8086. Now I'm leaning toward a tiny custom proof of concept followed by either a 4004 or 80386. Possibly all 3 in that order.
hard drive: I haven't decided how to do permanent storage yet. Recreating flash memory would stick with it all being in circuits but simulating a regular platter hard drive may be a better starting point. More on this when this stage is reached.

soft
This will depend on the processor made. For a 386, we should be able to run any 386 compatible software on sHs. For a small custom one or a 4004, the basics will probably be hand assembled and a simple C-like/ALGOL-like programming language should be figured out when/if assembly gets tiresome. Insert here the need for a compiler.
Operating System:

if 386: We can likely strip down the Linux kernel, alter a tiny Linux distro like Damn Small Linux, or use a microkernel like QNX
if custom or 4004: a simple OS will be created

In all likelihood, this is not ever going to be efficient nor resemble a useful or modern computer. I'm learning a lot of it as I go along. Not to mention that I'm unlikely to single-handedly recreate in a few years what it took some of the greatest minds 50 years to evolve. I'm just learning, having fun, and hoping this may also be of some use to others.

Peeling the Onion

2008-06-15T14:53:00.002-04:00

Breakdown of a computer: Practically speaking, a computer is a collection of useful software applications. Software is just arranged 1s and 0s inside of complex hardware. Complex hardware is made of smaller simple pieces of electronics and machinery working together in a predictable manner. A predictable physical item can be simulated in a computer program.

Rewind.

It's possible to make a computer program emulate the basic pieces of hardware. You could use such a program to arrange basic elements into complex hardware. You could even make this program able to run software like a computer does.

So what have we made? Well, mainly the world's slowest and most inefficient computer. But also a learning tool where you can see any part of a computer. You could see and manipulate any piece and understand how these magical machines work.

softHARDsoft is an experiment to create such a program.

Notes:

This is not the same as making an emulator. An emulator is a black box that acts identically to the object it's imitating. Behind the scenes, it can use any means. Recreating the innards of a computer, as is the goal here, is much more specific and detailed. [For example: the clock display on Windows is a clock emulator. It does something behind the scenes and displays the time. Windows doesn't have a program to shift each spring and gear that would be found inside a clock.] In fact, I may create an emulator first at some point to solidify my interface or make a proof of concept before recreating the insides. The very base hardware pieces will be emulators because I'm not reconstructing physics itself to make them work.
sHs will be open source. License yet to be determined.
[UPDATE: See the Licensing post]

Disclaimer: I do not have a computer-related degree and am in no way an expert on any of this. Although I've been a professional software engineer for years, I'm still merely a self-taught programmer. The ambitious goals of softHARDsoft will go far into the realms of computer science and potentially into electrical engineering. Everything here is for my personal hobby which I hope will attract other enthusiasts. At any point, if it seems like I'm totally out of my league -- I am. I'm sure there will be times I'll be completely wrong on some things. At these times I hope others will help me out. But I don't want my inadequate starting qualifications to stop me from enjoying the experience or from learning as much as I can.

I highly recommend that anyone unfamiliar in matters of low-level hardware start somewhere other than here. I recommend Charles Petzold's Code: The Hidden Language of Computer Hardware and Software but a brief trip through Wikipedia or HowThingsWork [1] [2] would also be a good first step.

* Regarding the image at the top of this post: it's a combination of an ouroboros (a snake eating its tail) and the circuitry diagramming symbol for a transistor. The recursive idea of a snake eating its own tail seemed appropriate for this "software inside hardware inside software" theme.