16-bit branch (target out of bounds) Ophis about mega65-core HOT 6 CLOSED

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 [email protected] 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
.

from mega65-core.

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.

from mega65-core.

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 [email protected] 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
.

from mega65-core.

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

from mega65-core.

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 [email protected] 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
.

from mega65-core.

Ophis no longer in use

from mega65-core.