[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions on EDASM reloc ($FE) files
In article <1144805973.921665.137090@t31g2000cwb.googlegroups.com>,
"mdj" <mdj.mdj@gmail.com> wrote:
> Actually, a2central/syndicomm take care of file type assignment these
> days... see file type note zero on a2central...
Thanks! I didn't know they were maintaining the list:
<http://www.a2central.com/programming/filetypes/index.html>
> My opinion anyway - cc65 object code files are a significant enough
> entity to deserve their own file type, or at least auxiliary type
> within one of the existing types...
You're right cc65 & Contiki are significant entities in active
development.
> To me, reusing a type in a way that's unlikely to cause any problems is
> just plain 'wrong', and really, doesn't save enough effort to make it
> worthwhile 'polluting' the filetype space. If you try to use EDASM
> tools on a cc65 object file it won't work, and the whole point of the
> filetype scheme is to make it easy to identift the type of a file!
Indeed, the huge variety of subtypes in LBR ($E0) can be a problem when
the metadata gets lost in transit.
> It does get kind of tricky to figure out 'correct' assignments...
> There's three generations of filetypes in the SOS/ProDOS filetype
> scheme... older types used up primary type numbers wastefully as if
> didn't seem necessary to allocate primary/seconday, as became the
> trend with GS/OS.
EDASM is one of the original wastrels. It uses the auxiliary type for
origin metadata, so it appears to "own" the entire REL ($FE) type. In
practice, EDASM declines to generate a REL file with auxiliary type in
the range $0000-$00FF. Although the related RLOAD tool doesn't reject
auxiliary types in this range, I would consider the range open.
> Matt
--
John
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/