6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 4:58 pm

All times are UTC




Post new topic Reply to topic  [ 20 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sat Apr 01, 2017 1:30 pm 
Offline
User avatar

Joined: Fri Mar 31, 2017 7:52 pm
Posts: 45
The version of the source I'm looking at does have the garbage collect bug. (There are comments that call it out.) But it is supposed to be the code that is in the original 8K ROM BASIC for OSI from Microsoft. I was going to see if I can find a ROM image and check whether this is actually what made it in or not.

So if you wanted to index from -8 to -1 (or something similar), can you actually do that? I hadn't thought about the page wrap behavior (this would have originally been on an OSI C1P with an original 6502), so it seems like for processors that don't page wrap this would be possible (whether intended or not) but for those that don't page wrap would it actual index to +248.

So from an OSI C1P perspective, the various comments here lead me to believe that 1) it would drop through the first time without looping, 2) since it is on an original 6502 it would have page wrapped so maybe it ended up where it should have for the first pass, and 3) but it must either have been an error (because it clearly means to loop) or the source has been modified in some form or fashion and doesn't match what was actually implemented on the C1P.

Grant says he used ca65 to assemble the code and apparently he did not receive a warning or error on it.

I appreciate everyones insight!

Thanks,
Jim W4JBM


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 01, 2017 3:26 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
jim30109 wrote:
So if you wanted to index from -8 to -1 (or something similar), can you actually do that? I hadn't thought about the page wrap behavior (this would have originally been on an OSI C1P with an original 6502), so it seems like for processors that don't page wrap this would be possible (whether intended or not) but for those that don't page wrap would it actual index to +248.

Grant says he used ca65 to assemble the code and apparently he did not receive a warning or error on it.

Hi Jim,

you can't -index on a 65xxx, all indexes are treated as a positive number. But in cases where a page wrap occurs (all zeropage addressing) adding $FF effectively means -1. So knowing this indexing from $F8 to $FF is equivalent to indexing from -8...-1. (On 65xxx only the relative addressing used in branches treats the displacement as a signed value.)

For the 65C816 in native mode, there are exceptions. The offset is still treated unsigned, but page and block limits can (sometimes) be crossed.

So to me the code snippet you show (and the one Garth refers to as well) looks correct. In this case only your assembler have a problem, not knowing about these weird stay-in-page-behaviour on one hand, but knowing that negative offsets are impossible for an 65xxx on the other hand. Perhaps using the CA65 might be a solution for this.

If you are willing to run this on a 65C816 in native mode it won't work w/o modifications.

Arne


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 01, 2017 3:30 pm 
Offline
User avatar

Joined: Sun Jun 30, 2013 10:26 pm
Posts: 1948
Location: Sacramento, CA, USA
jim30109 wrote:
... So if you wanted to index from -8 to -1 (or something similar), can you actually do that? I hadn't thought about the page wrap behavior (this would have originally been on an OSI C1P with an original 6502), so it seems like for processors that don't page wrap this would be possible (whether intended or not) but for those that don't page wrap would it actual index to +248 ...

It (-8) will wrap around fine for zp,X but not for the $aaaa,Y mode in the thread title. As I stated before, the source is not wrong, just a bit eccentric.

Mike B.


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 01, 2017 4:51 pm 
Offline

Joined: Tue Jul 24, 2012 2:27 am
Posts: 679
By the way, another option to convert -8 to $f8 should be (number) & $ff. Or (number) & $ffff for 16-bit values, ie converting -8 to $fff8.

This works on pretty much every assembler I've tried, and is a lot safer than an extraneous +/- 256.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor


Top
 Profile  
Reply with quote  
PostPosted: Sat Apr 01, 2017 11:13 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8479
Location: Midwestern USA
GaBuZoMeu wrote:
For the 65C816 in native mode, there are exceptions. The offset is still treated unsigned, but page and block limits can (sometimes) be crossed.

The offsets computed by relative branch instructions cannot cross bank (not "block") boundaries. BRL has a range of -32,768 to 32,767. All other relative branches have the same range as with the eight bit MPUs. When assembled, the operand to the PER instruction is converted to a signed displacement, also with the range of -32,768 to 32,767. When the '816 executes PER the displacement will be added to the next instruction's address, using signed arithmetic, and the resulting address will be pushed to the stack. Loading from or storing to that address results in the access occurring in the bank currently loaded in DB.

65C816 indexed addressing can cross page and bank boundaries and indeed that is the secret to being able to touch the full 16 MB address space without using the $bbhhll and $bbhhll,X addressing modes. Also, direct page indexed addressing, e.g., LDA <dp>,X, will index beyond the end of direct page, unlike the eight bit MPUs. Hence the sequence LDX #$FFFF -- LDA $FF,X will load the accumulator from $0100FE (and $0100FF if in 16 bit mode). In other words, both the page and bank boundaries are crossed.

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


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

All times are UTC


Who is online

Users browsing this forum: GARTHWILSON and 5 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: