neo6502: output runnable .neo files

[bcampbell]

neo6502 has file format for executable files which looks like it should be the default output for llvm-mos: http://neo6502.com/reference/formats/#neo-load-file-format

I think it's a mostly simple change to the linker script neo6502/link.ld, but I'm a bit stuck on the details. Here's what I've got so far- the ???? bits are where I'm a bit hazy. I know there are probably some symbols defined somewhere I use to calculate things (_start, _end kind of thing), but I really don't know what the conventions are.

OUTPUT_FORMAT {
    BYTE(0x03)          /* magic cookie (not a valid 65c02 opcode) */
    BYTE(0x4E)          /* 'N' */
    BYTE(0x45)          /* 'E' */
    BYTE(0x4F)          /* 'O' */
    BYTE(0x00)          /* min version - major */
    BYTE(0x00)          /* min version - minor */
    SHORT(????)        /* execute address (start LMA of ram section) */
    BYTE(0x00)          /* ctrl bits. bit 7=another block follows (could load graphics data directly into vram with a second block) */
    SHORT(????)        /* load address (also start LMA of ram section) */
    SHORT(????)        /* size in bytes of the _trimmed_ ram section */
    ????                        /* ASCIIZ string (comment, filename, whatever). Variable length, ideally definable in the C. I'd guess this'd involve adding a special "identifier" memory section and having TRIM(identifier), BYTE(0x00) here? */
    TRIM(ram)
}

Any ideas?

[asiekierka]

I followed the standards (particularly in execution format) set by the cc65 example I found when I was working on the code, as I had no physical hardware to access and validate behavior on otherwise.

I agree that if there's an executable file format now, this should be preferred.

I haven't tested this, but the ????s should be, in order:

• _start
• ORIGIN(ram)
• __data_end - ORIGIN(ram)

As for the identifier, you're generally right, though I would probably just stick to BYTE(0x00) for initial attempts as to not complicate things further.

[mysterymath]

Fixed by #345