6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Nov 22, 2024 12:11 am

All times are UTC




Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Fri Mar 31, 2017 8:25 pm 
Offline
User avatar

Joined: Fri Mar 31, 2017 7:52 pm
Posts: 45
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:

Code:
     ldx #TEMP1-FAC+1
L230B:
     pla
     sta FAC,x
     inx
     bmi L230B


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:

Code:
pup_osi_bas.asm:588:17: error: can't convert to a 8 bit unsigned integer '-8'
         ldx     #TEMP1-FAC+1
                 ^


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.

Code:
00C236  1  A2 F8                ldx     #TEMP1-FAC+1
00C238  1               L230B:
00C238  1  68                   pla
00C239  1  95 AC                sta     FAC,x
00C23B  1  E8                   inx
00C23C  1  30 FA                bmi     L230B


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


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 9:31 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1748
Location: Sacramento, CA
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/


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 9:36 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
jim30109 wrote:
I'm new to the group but a long time 6502 enthusiast. (Although, admittedly, a bit rusty.)

Welcome!

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

Code:
     ldx #TEMP1-FAC+1
L230B:
     pla
     sta FAC,x
     inx
     bmi L230B


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:

Code:
pup_osi_bas.asm:588:17: error: can't convert to a 8 bit unsigned integer '-8'
         ldx     #TEMP1-FAC+1
                 ^


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.

Code:
00C236  1  A2 F8                ldx     #TEMP1-FAC+1
00C238  1               L230B:
00C238  1  68                   pla
00C239  1  95 AC                sta     FAC,x
00C23B  1  E8                   inx
00C23C  1  30 FA                bmi     L230B


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.

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!


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 9:47 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
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?


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 10:07 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8504
Location: Midwestern USA
GARTHWILSON wrote:
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!

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!


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 10:22 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
GARTHWILSON wrote:
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!


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


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 10:29 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
jim30109 wrote:
... 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?

...

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.


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 10:33 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
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?


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 10:40 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
Why no loop? X = $F8. INX => $F9, BMI is taken, PLA, ... loops until X is incremented to $00.


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 10:47 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
GaBuZoMeu gets it! BTW, does this version of OSI BASIC still have the nasty little garbage collection bug?

Mike B.


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 10:57 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
GaBuZoMeu wrote:
Why no loop? X = $F8. INX => $F9, BMI is taken, PLA, ... loops until X is incremented to $00.

From the source code:
Code:
        ldx     #FAC-TEMP1-1
        tya
L2300:
        pha
        lda     TEMP1,x
        dex
        bpl     L2300

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?


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 11:18 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
Of course Garth, you are right - I was only looking at:
jim30109 wrote:
I'm new to the group but a long time 6502 enthusiast. (Although, admittedly, a bit rusty.)

...
Code:
00C236  1  A2 F8                ldx     #TEMP1-FAC+1
00C238  1               L230B:
00C238  1  68                   pla
00C239  1  95 AC                sta     FAC,x
00C23B  1  E8                   inx
00C23C  1  30 FA                bmi     L230B


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


there stood a BMI not BPL.

______________
(edit: shortened citation)


Top
 Profile  
Reply with quote  
PostPosted: Fri Mar 31, 2017 11:43 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1949
Location: Sacramento, CA, USA
#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.


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 01, 2017 12:59 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
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?


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 01, 2017 8:41 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
@Garth: IMHO your contributions I have read so far were allways use- but never wasteful :)
@Mike B.: indeed, the title IS misleading :D


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 17 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron