The idea is to see how far I can go with this assembler, to the point of including a version of it in the new machine itself. So part of the fun is to see how far I can push it ... if it because too slow at some point, fine, I want to do some more serious coding in Julia (http://julialang.org/) anyway, and that would be the base for a two-pass assembler.

Between the half-finished assembler and some first routines from the emulator, I had enough stuff to throw together a disassembler (which I probably should of started off with, but whatever). It's at https://github.com/scotws/tdis65816 , and though feature-complete, not extensively tested.

It turns out that getting forward branches -- unresolved future references -- to work generically is a wee bit more complicated than I would have imagined, up to the point that if I had know just how much work that was going to be, I probably would have done something more sane. But I didn't, and so now I can just use <? for everything: Even worse was getting branches to work with basic math for things like The whole program including comments has expanded to about 24.5 kbyte of Forth code, which is still less than the GDL license file. The whole project is now offially in BETA now, and I'm going to work on getting some real-world experience with it before I think about adding new features.

There are so many changes that I'm going to depreciate the "normal" 65c02 assembler. And now I can get back to the emulator.

After a bit more experience with the assembler, I'll be reverting to the old "<b" and "<jl" format for forward references instead of "<?". Here's the problem, illustrated with the PEA example on page 188 of the manual. In Typist's Notation, this would be: This is a method to pass parameters to a subroutine, in this case for string comparisons; "compare" ends with a RTS.

For this to work, phe.# would have to be "futureproofed" like the jmp and bra instructions, which means lots and lots of complicated code to figure out what kind of unresolved forward reference we are dealing with. In fact, we end up with pretty much every non-single byte instruction futureproofed. We could factor it out with something like but that would mean four chacters for a simple foward reference. Also, futureproofing is ugly in itself on a code level, because it involves things like passing a flag foward. You will remember that Thinking in Forth actually memtions that as an example of bad coding. Ahem.

If this were a program for some normal user, it might be worth it, but since I'm the only one using it now (and probably forever, grin), I'm just going back to as an absolute reference, probably with "<a" as a synonym for "<j". That way, the 65816 instructions themselves don't need to know jack about future references, and the code is far simpler and cleaner all around. Repeating the kind of reference we have is the lesser to two evils, it turns out.

In the end, this was a very instructional dead end, because I learned a lot about tradeoffs in the code, not to mention that the Forth routines themselves are the most complicated I have written to date. Which should have probably been a warning sign .

Since I was fooling around with my .vimrc anyway, I added a syntax file for the Typist's Assembler Notation (TAN). See the screenshot attached and the code at https://github.com/scotws/Typist-VIM-Syntax .

Since TAN is basically Forth, it worked fine enough with the Forth syntax plugin. However, the mnemonics were were not given any special formating. Here, they are bold, with a few special cases, like jumps and branches. Some of the more important directives are coded as well.

I've put together a small text (still with draft status) about Typist's Assembler Notation (TAN) at https://docs.google.com/document/d/16Sv ... SojNTm4SQ/. Not quite grandiose enough to be a manifesto, I'm afraid, but a bit more systematic than the notes here.