16-bit branch (target out of bounds) Ophis

[Ben-401]

in kickstart_dos, PGS has previously experienced:

    ; XXX - 16 bit BNE should be fine here! Why doesn't it work?
    ;   bne partitionerror
    beq ddop11ok
    jmp partitionerror
ddop11ok:

Now I have experienced this too.

    lda [sd_sectorbuffer+$1FF]  
    cmp #$AA
    bne partitionerror

fails because function "partitionerror" seems out of bounds.

SO: Why doesnt this instruction get converted properly by Ophis to the 16-bit branch like other detected branches?

[gardners]

Hello,

A fine question, and one that is best solved by us moving to ca-65 instead
of Ophis, now that ca-65 has 4510 support.

Paul.

On Thu, Sep 8, 2016 at 12:23 PM, Ben-401 notifications@github.com wrote:

in kickstart_dos, PGS has previously experienced:

; XXX - 16 bit BNE should be fine here! Why doesn't it work?
; bne partitionerror
beq ddop11ok
jmp partitionerror

ddop11ok:

Now I have experienced this too.

lda [sd_sectorbuffer+$1FF]
cmp #$AA
bne partitionerror

fails because function "partitionerror" seems out of bounds.

SO: Why doesnt this instruction get converted properly by Ophis to the
16-bit branch like other detected branches?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#19, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAonT0rN4b-VoHknKXLr5iko0-rvQYcBks5qn3iwgaJpZM4J3j0k
.

[lgblgblgb]

Wow! :) I forked cc65 some weeks ago to put 4510 support into ca65, but since it's kinda complex for my taste (maybe to my knowledge as well), I only did "simple" things so far, without dealing the 16 bit relative jumps too much and similar "minor" :) issues. Nice to hear that ca65 has "sane" 4510 support already then! I would vote for CA65 too, for many reasons. Just one note in general: it's important that even things like m65dbg (and my wannabe M65 emulation) currently uses list file produced by Ophis.

[gardners]

Hello,

Right, we need to make sure the m65dbg and anything else that depends on
Ophis is provided with the required patches to allow it to work. And we
must, of course, convert the kickstart and other programs from Ophis to
CA65 format. Not too hard on either front, I suspect.

Paul.

On Fri, Sep 9, 2016 at 1:07 AM, LGB notifications@github.com wrote:

Wow! :) I forked cc65 some weeks ago to put 4510 support into ca65, but
since it's kinda complex for my taste (maybe to my knowledge as well), I
only did "simple" things so far, without dealing the 16 bit relative jumps
too much and similar "minor" :) issues. Nice to hear that ca65 has "sane"
4510 support already then! I would vote for CA65 too, for many reasons.
Just one note in general: it's important that even things like m65dbg (and
my wannabe M65 emulation) currently uses list file produced by Ophis.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#19 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAonT-sOAlctq-G0tAs9CKvgUoRXG7zKks5qoCuxgaJpZM4J3j0k
.

[Ben-401]

Sorry, but I suggest we stay with Ophis as we know it currently works, mostly.

[gardners]

As discussed, we should move to cc65/ca65, so that everyone is using the
same tools for everything. ca65/cc65 has 4510 support now, thanks to Svolli
and others.

Paul.

On Thu, Sep 29, 2016 at 12:01 PM, Ben-401 notifications@github.com wrote:

Sorry, but I suggest we stay with Ophis as we know it currently works,
mostly.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#19 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAonTzHDeIMGNg6F33sKYxBQyhddFOjsks5quyLygaJpZM4J3j0k
.

[rdpeake]

Ophis no longer in use