[cc65-devel] HuC6280 zero-page addressing problem.

[John B. <jo...@te...>]

Hi guys,

I've been using CA65 for a while now, and it's finally time to bring
up the problem of zero-page addressing.

On the HuC6280, the regular zero-page addressing modes actually refer
to locations $2000-$20FF.

As such, it's more like the 6809's direct-page addressing ... but
limited to a single page.

CA65 is assuming that all one-byte addressing modes refer to a
location in the range $0000-$00FF, i.e. the high byte is zero.

I've been trying to fix this so that CA65 will correctly use the
direct-page/zero-page addressing for constant symbols in the range
$2000-$20FF, and could use some advice.

It only looks like I have to modify CA65 in 3 locations to get this to work.

1) in studyexpr.c at approx line 449 when CA65 is deciding whether a
constant symbol should use 1 or 2 byte addressing.

This looks like a safe change to make.

2) in segment.c at approx line 394 when CA65 is checking for range errors.

Disabling this check for the HuC6280 seem like the only option.

It doesn't look like this would to cause any problem, because the
range checking is done again anyway during code output in objcode.c

3) in objcode.c at approx line 71 when the assembler is emitting an
instruction with a 1 byte argument.

This is where I have a question.

I can disable the range check for the HuC6280, but then we'd lose the
safety of range checking on immediate instructions.

There's no addressing-mode information being passed into Emit1(), so
the only thing that I've got to differentiate between a direct-page
reference and an immediate byte is the opcode.

Does it sound OK to folks for me to put a 256-byte
opcode-to-addressing-mode table into objcode.c to see if the check
should be for $2000-$20FF (direct-page), or $0000-$00FF (immediate)?

It sounds a bit kludgy to me, but I can't currently think of a better solution.

Can someone else think of a preferable way to fix this issue in CA65?

Best wishes,

John