cc65 breaks on devices or configurations where the 'zero page' is not at 0

[EtchedPixels]

In various pieces of compiler generated code you find patterns of the form

STA $08
STX $09
JMP $0008

which breaks on the HuC (DP at $2000) and also on 65c816 if you are running code outside of bank 0.

I was thinking about adding a compiler option --unaliased-zp which would

1. Make the linker warn if asked to use a .zp variable for 16bit addressing
2. Tweak the compiler so in that case it generates

PSHX
PSHA
RTS (1 clock longer)

for this case and for -Os on 65C02 as it's also half the size

(it needs something uglier on 6502 - but you'd not normally build 6502 with this option...)

Thoughts ?

[groessler]

What's the current status of PR #319? Anyone working on this?

[EtchedPixels]

Having dug a bit the offender seems only to be in the runtime. so for now I've patched my runtime and I will link my fixed routine in crt0 so it gets used and found before the buggy cc65 one.

Using the existing jmpvec helper fixes the problem nicely (but leaves the jmpvec and interrupt bug even more of a problem)

[oliverschmidt]

Thoughts ?

A pull request with the described change would be in general welcome.

Using the existing jmpvec helper fixes the problem nicely.

I can't follow you. Please elaborate.

[EtchedPixels]

I'll send you a pull request once I've tested a bit more and looked for other cases.

[oliverschmidt]

Sorry but I lost track of what aspects of this issue having maybe been solved in the meanwhile. @EtchedPixels: Could you please provide a short feedback on the status of this issue from your perspective?

[EtchedPixels]

@oliverschmidt My current status is that I have a 'sufficiently rigged demo' that I can build my Fuzix kernel on 65C816 with the kernel code in bank1, data in bank2 and ZP / S in bank 0.

To do that I've had to

• Do some hacks around jmpvec and the C support code
• Add a custom setjmp
• Ensure I don't place any data in 00xx otherwise the compiler/assembler optimises it to ZP
• Some tweaks where the compiler tries to write self modifying code and assumes code == data

To do it all properly also needs a compiler tweak. I want to spend the time to get it all working and right and tidy first

[oliverschmidt]

Thanks for the quick feedback :-) So we'll just keep this issue open as-is you'll come back with news when you're ready...

[EtchedPixels]

https://github.com/EtchedPixels/FUZIX/wiki/Using-CC65-on-the-65C816

is where I am today

[pinobatch]

Related bugs include #194 and #317.

[mrdudz]

I wonder if/how we could create a testcase for this... tricky :)

[EtchedPixels]

Not very - use a 65C816.

[mrdudz]

I mean a testcase for our regression testbench :)

[EtchedPixels]

What are the requirements for the regression setup - there are plenty of 65C816 emulators out there, and some of them even work.

It ought to be trivial to hack https://github.com/EtchedPixels/v65c816 into whatever your test suite needs if you can let me know what you require.

[mrdudz]

it uses the simulator from the cc65 toolchain, no external tools allowed - so probably has to wait until someone adds 65816 to it.

[EtchedPixels]

I'll try and find time to product a compatible 65C816 simulator with the same PV API (or similar). Your current PV API allows the tested code to overwrite and access arbitrary file paths which is bad - worse yet PvOpen has a buffer overflow so your test can actually execute arbitrary native code on the host !

[oliverschmidt]

As @mrdudz already pointed out, we're not going to make use of any external tools in our CI.