[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/