>I assume it's a four byte header, 2 for start and 2 for end, right?
>Sounds straightforward enough. Actually the ftohex support would be
>more complicated since it needed to convert from/to 4 formats at that
Here's the description of the file format I think we're talking about: http://www.atarimax.com/jindroush.atari.
I think he's talking about a special format 2 to xex tool. I think people have used format 2 previously for special
purposes (possibly bankswitched binaries, http://www.atariage.com/forums/index.php?showtopic=76847) and written their
About ftohex: Personally I'd just let it die. There are better whatever<->hex converters. I'm using sdcc to build a
ColecoVision version of robotfindskitten, and am just converting the intel hex output of sdcc to flat binaries using
objcopy (any host/target flavor will do, as long as it understands the ihex and binary formats, which are CPU
independent), and there's also srecord around.
And please, let's stop format numbering: we have now format 1-3, possibly soon 4. Time to introduce named formats:
2: ras (as Matt apparently called it)
I think I wouldn't even introduce new numbers for new formats...just keep numbers 1-3 around for backwards
compatibility. And there's no reason to limit format names to three letters, either.
>Well, I'd rather add support directly to dasm, if it's up to me..
That's fine with me aswell, although I really do think a lot of formats could and should be supported by the program
source code itself (see below).
>Anyone know the format of a Commodore 64 executable? That'd be a good
>candidate too... unless it happens to be the existing format 1 or 2
>(then it just needs a new name).
I'm no C64 specialist, but did some very minor hacking for it aswell. Those C64 programs I wrote were from the C64
ROM's point of view just BASIC programs. They consist of a small BASIC startup code that does nothing but jump (SYS
instruction) to the machine code embedded in the program image. When you load such a program, the kernel ROM just loads
the whole image to the load address specified in the first 2 bytes of the image and starts executing BASIC code. The
BASIC code in turn just jumps to the machine code, which already got loaded by the ROM.
This BASIC startup code can all be implemented by a few very simple data definition directives, no need to add
support for to DASM itself. You'd use format 3 to write such a program. I might be able to dig up some of that code, if
it's of interest. Or you could simply look at crt0.s from cc65's C64 library. They actually do the same thing, all in
the startup code - There's no special C64 support in the cc65 toolchain itself, it's all in the C library.
In the case of Atari 8 bit executables I do see that one might want the assembler to know how to generate them, since
you'll probably want to have a segment header automagically generated for every segment you defined in your source