I've been on an absolute tear lately. I went more than a year without doing any programming of any kind.

For whatever reason I got back into it last week.

I've got this project I've been slowly working on for 30 years. (It's actually my avatar). I got part of it finally working to where I was satisfied with it. Except, it's slow. It runs just perfect in an emulator at 200% speed. If only I could run my hardware at 200%. Well, being completely focused on this lately, I deleted three pages worth of code and wrote that routine from scratch. I don't know why I didn't write it this way to begin with. It's now three times smaller (in assembly) and runs 1.95 times as fast.

So I achieved the 200% difference, and I've got some more optimisations up my sleeves! Hopefully I don't get disinterested before I implement them.

I even pounded out a new song on the Wurlitzer/Leslie during assembly (my assembler is a little slow).

It feels good, doesn't it? I suppose obsessing about optimizing the efficiency is one of the philosophical reasons we are interested in these processors that are pretty low-end compared to the latest 32- and 64-bit offerings. When programmers can use GHz and GB and pull in huge software modules or libraries just because one has a small part they might want, they do not have much incentive to really be efficient. Volume 1 of the book "Write Great Code" by assembly-language expert Randall Hyde says, "Good assembly language programmers make better HLL programmers because they understand the limitations of the compiler and they know what it's doing with their code. Those who don't know assembly language will accept the poor performance their compiler produces and simply shrug it off."

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Great stuff! It's amazing what you can get done over a weekend, if you actually sit down to do it. For me that only happens once every few years, if I'm lucky.

Kettle Moraine -- as in Wisconsin? If so, have a big hello from an old Mukwonago guy! So, 30 years away resulted in a 200% speed increase. Good to hear you're back at it!

30 years resulted in a lot more than that. I made improvements in 1989-1991, another leap in 1997 or so. Major improvements in 2012 or so, and small steps here and there since then until last week.

It's probably closer to 2000% over 30 years.

I'm 10 minutes northnortheast of Mucktown.

I wrote the assembler. I know it better than anyone, but even I don't know that much about it. I've forgotten too much. Just last night I was wondering if I'd ever implemented a certain feature, how I did, and if it works. I'll probably have to dig through the code to figure it out, or just live without it. There might be examples of its use in other pieces of code I'll have to dig through. But for now, EA.

I shan't worry about it anyway, as one of these days I have to get back to a complete rewrite of the assembler. I have no doubt I can speed it up by 500% if I ever get round to it.

I just achieved 212%, or 2.1167x as fast.

But I have to add a few instructions to a loop to compensate for some now missing functionality. So I may wipe out that gain. But it was important because these features got lost at the 195% rate.

I'm starting to split hairs. Really none of this needed to be done; I should be working on more important things. But when you're on a roll, you don't stop rolling.

I had to add considerable logic to a less time-sensitive routine to make the gains in this time-critical one. Oddly, that less time-sensitive one appears to be running noticeably faster, too. I may be imagining it. If I get ambitious I'll time it to find out.

What did you speed up, and how did you do it?

It's a routine to display a 40x24 window of a text file.

It started out as a simple loop to step through the 916 display characters and pick out characters from the file. It got very convoluted when I at some point eliminated wrap-around, and prevented display of non-displayable characters.
Each time a character was pulled from memory, it needed to be converted from ASCII to a character number.

The biggest improvement was changing the 960 character loop to a nested loop of 40 characters by 24 lines. This allowed me to not only simplify the loop counter, but to use the loop counter as an indirect index, ie LDA (location),y to pull characters from memory, instead of incrementing two indirect references.

I can't imagine why I didn't do that in the first place. Probably I was more concerned about getting it working at that point than making it work well.

Next, instead of converting from ASCII during the display loop, I converted all the characters when loading the file to memory. This didn't cause as much of an increase as I expected, and introduced some interesting consequences. The worst of which is that I had to make two characters undisplayable. I needed one to mark line boundaries and one to mark file boundaries.

Changing the line demarcation method broke 100 lines of other code. I'm working on that currently.

Unbelievable! I wasted at least four hours debugging today.

I rewrote my assembler from scratch sometime between 2011 and 2013.

When I did, I used a mnemonic/opcode chart that I made in 1990, when I rewrote it at that time.

I checked and double checked my code to the chart.

Either I checked and double checked wrong, and my assembler since then has been wrong; or, my assembler has been wrong much longer.

I had $83 for STA(ind,X) which should have been $81.

I wonder how many headaches this caused over the years.

The table must be wrong. My disassembler doesn't recognise $81.

Good thing I haven't been trying to earn a living with my assembler.

http://www.llx.com/~nparker/a2/opcodes.html

Mike B.

Yep. I'll have to go over my chart, and see what else is wrong. From there I can fix the current assembler, the next one (which is in process), and my disassembler.

I think that's the third time I've found an error in recent years. The sad part is that when I found the first one, I went over the whole chart again. So probably what I'll find is that I already corrected this error on the chart, and already fixed the current assembler at that time. I seem to have lost several months of work on my assembler from two years ago. I think I inadvertently used an archive copy of my working disk at some point.

Things are so much nicer when everything works. I just discovered another piece of code that I abandoned a while ago. I can see why: sta ($14,x)

You should try debugging a new assembler on a new simulator with Code Not Of Your Doing, all at the same time.

"Why, everything and anything can be wrong here."

I found the error was corrected in a concurrent copy of the new version of the assembler, so I've likely corrected it already in the past but lost the originally corrected source code.

I just discovered last night that my branch math may be wrong. I don't normally do branches that I think would be too far, so I've never run into this before. But I had some proper-looking code that didn't work start working by substituting a JMP for a BEQ. I haven't investigated yet, so I don't know what's wrong. But I have verified that blatantly distant branches result in an error upon assembly. And I distinctly recall verifying branch operation years ago. But maybe I bungled something since then.

I wasted about 6 hours on that one. The sad part is that I'm working on the replacement assembler. If I can ever get that done I won't have to worry about that anymore. But there's a long way to go. I've written and rewritten the main parsing loop at least a dozen times. I keep second guessing myself. I think I'm back to the original code, or very close to it.