Binary object files on the Atari 8-bit

[Rybags]

I missed the point a bit... what I meant is you should be able to have a start address of $FFFF and that it shouldn't just ignore successive occurrences of that.

 

e.g.

FF FF - indicate binary

FF FF - start

FF FF - end

nn - data

 

What I was going against is this sort of thing...

 

FF FF - indicate binary

FF FF - indicate binary again

FF FF - and again

A0 00 - start

FF FF - end, this time allowed since "valid" start is provided

nn nn ... etc. - data

[flashjazzcat]

Yep: that's exactly the crux of it, but I'm among those who can't envisage why that would be useful. Moreover, few DOSes can handle such files. My loader only handles them by accident of its design, and therefore (to my surprise) exhibits the robust behaviour being advocated, albeit for no practical reason whatsoever.

[Rybags]

Yep, loading data into the hw IRQ vector is madness at best - regardless of how you implement a replacement OS you still need those valid interrupt vectors .

 

I suppose the other questions to ask might be, what to do if start address is greater than end. Attempt read and do wraparound, read just one byte, skip section altogether.

But I guess really, supporting "bad" binary file behaviour can just encourage more of it.

[xxl]

@flashjazzcat: even if it is not much useful don't say it's not binary file...

 

 

Yep, loading data into the hw IRQ vector is madness at best - regardless of how you implement a replacement OS you still need those valid interrupt vectors .

 

not true. if you use xB SIO you can switch off NMI, IRQ, ROM and still fine work with files.

[flashjazzcat]

Oh, it's binary file alright: just one you can't load in 9/10 situations.

[phaeron]

The problem with supporting $FFFF loads is that it's incompatible with files that are valid to DOS. If you're creating executables, then there's no reason to use $FFFF headers in the middle and it should be avoided for maximum compatibility. On the other hand, a loader can't support the $FFFF load without breaking an executable like this:

FF FF
FF FF
FF FF
40 40 42 40 4C 77 E4
E0 02 E1 02 40 40

Sure, it's bad practice, and not actually guaranteed to work according to Atari's docs either, but that doesn't rule it out from actually existing in a published executable somewhere. I've already seen a fair number of executables that have junk at the end and work because Atari DOS ignores certain I/O errors during exe loads. The executable format is defined by the executables and behavior of DOSes that have been published in the past thirty years, not what we would like the format to be.

 

It's similar to the situation with EXEs that have no run address. The official Atari spec says you can omit it and it will be equivalent to doing an RTS from the run address. The practical spec is that you always need a run address unless you're OK with crashing under SpartaDOS.