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

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

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.

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

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!