I'm new to the group but a long time 6502 enthusiast. (Although, admittedly, a bit rusty.)

I was cranking through Grant Searle's simple 6502 build:

http://searle.hostei.com/grant/6502/Simple6502.html

I like the fact that it uses OSI BASIC--my first computer was an OSI C1P, my second a C4P-MF, and I worked my way through college doing hardware and software work mainly on OSI C3 machines. Now I want to scratch build a 6502 (actually probably a 65c816) machine.

In the OSI BASIC code, there is a section that reads:



I have been using 64tass and when I tried to assemble the code (after some edits to make it assemble), I am left with one error message that really troubled me:



At first, I assumed I had messed up something with the labels for the tables. But Grant provided the listing code, so eventually I decided to check that and found it had, indeed, put the "-8" in as the value of X which, in turn, was then used to index from label FAC.



I can't find it explicitly, but so far as I can remember the indexing is strictly assuming the register is a value between 0 and 255, not -128 to 127.

Am I missing something or is there a deeper issue with that section of code that I need to dig into?

Any insight would be appreciated.

Thanks,
Jim W4JBM

Label FAC is located in zero page at $AC.

My guess is that TEMP1 is located at $A3.

Doing the byte math: A3 - AC + 1 = F8

F8 = -8 decimal.

To fix the problem, you could change the +1 to plus 257.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

Welcome!


I'm not specifically familiar with TASS, but can tell you that when an expression such as TEMP1-FAC1-1 evaluates negative you will get a diagnostic similar to what you are seeing. It would suggest to me that TEMP1 is lower in RAM than FAC1.

Incidentally, a negative evaluation can occur if a location such as TEMP1 is in zero page but is not declared before an instruction makes reference to it, i.e., the instruction forward-references the address operand. Most assemblers will assemble the instruction with absolute addressing instead of zero page addressing because it was a forward reference. However, I recall the old Commodore MADS assembler for the C-64 couldn't deal with forward references to zero page and apparently wrapped the ZP address to some really bizarre value.

Moral of the story is to be sure all ZP locations are declared before any code refers to them. Also, in cases where one ZP location is a derived value, such as TEMP2 = TEMP1 + 2, you have to be sure TEMP1 is defined first. Otherwise, that too is a forward reference, which the assembler may not properly handle or may flag as an error.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Very strange. Could it ever have run correctly as is? It sure seems like the FAC-TEMP1 should have been the other way around, TEMP1-FAC, since TEMP1 is several bytes later in the variables (which are already declared, so it's not a forward reference). Then there's a loop of pushing these onto the stack. If it were $F8, it might overrun the stack area, except that the looping ends when the X value is negative which means it would only go through once and not really loop!

_________________
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?

I've never know any assembler to correctly assemble an operand in which the evaluation goes negative, unless it is surreptitiously doing twos complement arithmetic. I tried assembling that code snippet in the Kowalski assembler and it flagged the result of evaluating TEMP1-FAC1-1 as an illegal operand. I wonder if somehow the source code got edited by someone who thought the two ZP locations should be reversed, but didn't realize what that would do to subsequent code.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Doesn't ZP,X wraps @ $100 ? The code was running on 65C02, not 65C816 or?

The coder seems to be simply taking advantage of zp,X wraparound to save a few cycles by counting from -8 to -1 instead of 0 to 7. Eccentric, but certainly not illegal.

Mike B.

But again, the negative X value would make the loop drop through, the first time through. There won't be any looping.

_________________
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?

Why no loop? X = $F8. INX => $F9, BMI is taken, PLA, ... loops until X is incremented to $00.

GaBuZoMeu gets it! BTW, does this version of OSI BASIC still have the nasty little garbage collection bug?

Mike B.

From the source code:

If it starts at $F8, the DEX makes it $F7, still negative, so the BPL will not be taken.

_________________
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?

Of course Garth, you are right - I was only looking at:


there stood a BMI not BPL.

______________
(edit: shortened citation)

#FAC-TEMP1-1 is +8
#TEMP1-FAC+1 is -8

You're looking at a similar but different section of the source, Garth. BTW, isn't the title of this thread a bit misleading?

Mike B.

Ok, I messed up again. I spent a long time trying to re-arrange the routine to be more readable at label "REASON" where the OP's piece of code comes from, and in the process, I mentally reversed the order of variables FAC and TEMP1 in ZP. My apologies for wasting everyone's time.

_________________
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?

@Garth: IMHO your contributions I have read so far were allways use- but never wasteful
@Mike B.: indeed, the title IS misleading