I don't yet have a name for the Assembler language program-thingy I'm doing so I'm just going to refer to it as Assembler (giev suggestions!) for the time being. Cool? Cool.

As mentioned in a previous post, I'm taking time out from my commercial software and am instead working on fun little projects. Clearly, our definition of the word fun differs greatly.

I wrote a Turing program a long time ago and recently it occurred to me that I could get a more advanced version by essentially emulating a CPU. The Turing machine is pretty much what that is. In this case, I'd be going with a Motorola 68000. Because it's lovely, and because it seems simple enough as compared to the nightmares that are the x86 and x68 architectures. Bear in mind that I don't really know much about assembler/assembly other than tinkerings back in the mid-to-late 1990s.

Most of the time so far has been spent creating a lexer (syntax highlighter) for Scintilla. Being a .NET OOP guy and working with Scintilla.NET (which doesn't attempt to really refactor anything), its API is a complete mess. So it took me quite a while to get highlighting happening, and it's still not done. Thankfully there's a project called ScintillaNET-Kitchen that helps out.

I haven't gone for a multi-document interface or anything that you'd find in more complete IDEs - how do I even know if this project will work satisfactorily? Hell, saying that, I've (partly!) made it possible to switch in new CPUs. I think that itself is a bit much and so don't currently plan on fully adding support for such a feature. Hmm... I could also create a chipset with multiple chips...? No - NO. Stop right there.

Yeah, alright - what the eff is the point?

Fun. As said above.

I'm going to keep adding to it. Forever. CPUs don't tend to do a whole lot on their own; their instruction sets aren't very big, either. Lots of shunting of data all over the place. Of course this is simplified and from someone that doesn't really assembler-me-do, but how hard can it be?

So, if I can get the basics working then I can start adding built-in routines that a program can call to do more advanced stuff. A video display would need to be added, of some sort. Only being able to manipulate registers isn't the most exciting thing after the initial novelty wears off.

Shut up and tell me if it's done yet

Hell no it isn't done. It doesn't even parse the entered code yet. There's the editor with all its syntax highlighting tomfoolery, and there's the Registers window that displays the contents of each register. That bit works; it shows exactly what's in the registers, but they can't be set using code yet.

There's a screenshot below. That's all there currently is. Will still if I have time to get the parsing - at least started - in today.

Edit: Did the opposite of what I said and have continued working on the interface. Oops.