[cc65] Odd problems creating a new target.

Hi folks!  'Tis interesting to be back on the 6502 after retiring the ][e
years ago. :P

I apologize for my ignorance, but I am having some odd problems trying to
create a new target.  The "machine" I am trying to target is the "65EL02",
which is a virtual machine included in a certain module for Minecraft.  It
very closely resembles a 65816, except a few opcodes have been changed
(namely those that are used to access memory above 64k).

Anyway, after the bootloader runs, the CPU is in 6502 mode, so I figure I
can tell cc65 that it's just a 65c02 and everything will be a-ok...

Here's a little background, before I link to my code and describe the
problem I am having:

The machine's memory map looks like this:
0000-0099 zeropage
0100-0199 p-stack
0200-0299 r-stack (I /think/ this is just used by the bundled FORTH
interpreter, but I'm not entirely sure yet).
0300-0399 device output (there may be 7 devices attached, but the
bootloader defaults this to the screen).
0400-0499 device input (this also contains the bootloader code, which loads
the program at 0500, then switches itself off to change this area to device
input).
0500-ffff RAM.

The CPU does not implement interrupt vectors.  It supports the WAI
instruction, and the interrupt is hooked to a timer, but it does not branch
to an interrupt vector when an interrupt is raised.  Just halts the CPU
until the timer fires.

More details of this machine can be found at http://www.eloraam.com/?p=255
A virtual machine that emulates this virtual machine outside of Minecraft
(head-explode!), which I am using to test my code, can be found at the
bottom of this page: http://bigfootinformatika.hu/65el02/

I've been following the documentation on the cc65 website regarding setting
up a new target, using the supervision lib as a base.

Here are the files I have created:
rpc8e.cfg: http://pastebin.com/5CedRuQT
crt0.s: http://pastebin.com/Wz4sTSPP (note that init and exit code is
commented out. 6502 housekeeping is done by the bootloader and not needed,
as well).
test.c: http://pastebin.com/nLnkvZNF
build.sh (a temporary thing until I get things working, then I'll write a
makefile): http://pastebin.com/vsvEF7Tn
(the dd stuff at the end of build.sh makes sure the file is padded out to
at least 128 bytes; otherwise the bootloader won't load it)

Aaaaand, here's the weird problem:

If you look in test.c, you'll see that there is a block that "works" and a
block that "breaks".  When I do not initialize or assign to the local
variable 'c', everything works swimmingly.  However, if I try to initialize
c in its declaration (ie char c = 0x23;), or try to assign to it (as is in
the for loop), things get weird.

I end up with a main routine fragment that looks like this (in the
emulator's disassembly of the memory at the IP):

0513 lda #$23 ; Prints a '#' character on the screen.
0515 sta $0310

0518 jmp $051E ; Not sure what is going on here.  The for loop happens
after this block...  I think. >_>
051B jmp $0518
051E ldx #$00
0520 lda #$20
0522 ldy #$00
0524 sta ($00),y
0526 ldy #$00
0528 ldx #$00
052A lda ($00),y
052C cmp #$80
052E jsr $0587
...
0587 00 brk
0598 00 brk
<etc etc etc>

See, at the end of that fragment, the code JSRs to a zeroed section of
memory, resulting in Unhappiness.  I'm at my wit's end trying to figure out
why.  I have a feeling there's something wrong with my memory map
definition in the .cfg, but I've piddled it around to no avail.

Here's a disassembly of the whole image: http://pastebin.com/xGnQskM9

Thanks for reading!  Any insight would be greatly appreciated. :3

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.