So you actually were able to measure the difference ... cool! I have a slightly different use case for my current coding exercise. It's for my new version of MSBASIC's FIN, which I cheekily renamed atof:
Here, I assume that we're still in the land of NMOS, that the current string of interest is smaller than 256 bytes, and that scanned decimal digits will be used as binary immediately.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I've started looking at what changes I can make to the Commodore 64's BASIC to take advantage of the new instructions in my 65020 design (which I'm working on again, slowly).

Profiling a simple test program showed that a huge amount of time is spent in CHRGET / CHRGOT. This routine always struct me as overcomplicated. Surely you don't always need to know if the character you've fetched is a digit - why go through that lengthy test every time, only to ignore the carry flag when you return?

If you have an LDA (zp) instruction without indexing, it's possible to replace many (but not all) calls to CHRGOT with an inlined LDA (TXTPTR). There's no need to test for space and loop, because CHRGOT can never be called on a space.

So I tried that on one instance, and ... well, it does work, and it does make difference. But in the process I've discovered a latent bug. The program would crash with a "NEXT WITHOUT FOR" error, unless I followed the LDA (TXTPTR) with a NOP.

Here's the code responsible:


The JSR PUSHF1 pushes the address of (one byte before) the next instruction. PUSHF then pops this address, increments it, and stores it in INDEX1. Later on there's a JMP (INDEX1). Can you see the problem?

It's only incrementing the low byte of INDEX1. My changes placed the instruction after JSR PUSHF1 at the start of a page, so the address pushed to the stack ended in $ff. Increment just the low byte of that, and JMP (INDEX1) will take you 256 bytes from where you should be.

It's not a problem in the Commodore 64, because that instruction is normally nowhere near the start of a page. I just got very, very unlucky.

They also published Olympic Decathalon for the Apple ][...

And also Multiplan, a pretty good spreadsheet program.

Let's not forget their CP/M card for the Apple II. That was a big seller for them for a while.
I'm sure it had custom ROM code at the very least.

_________________
Cat; the other white meat.