[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questions on EDASM reloc ($FE) files
John B. Matthews wrote:
In article <voOdnfM3qdn3YqTZnZ2dneKdnZydnZ2d@comcast.com>,
"Michael J. Mahon" <mjmahon@aol.com> wrote:
John B. Matthews wrote:
Contiki could check the auxiliary type for validity, while existing
EDASM RLOAD wouldn't need to do anything different. I would advocate
choosing an auxiliary type that would be an unlikely ORG of a
relocatable segment: e.g. $FFFF.
That would be a good choice if the assembler can be convinced, but I
think it's REL file format is already settled. At this point, it would
just be up to the "consuming" programs to check for what they expect.
It seems likely that any "loader" program would do some validity checks,
since they have the potential to overwrite almost anything if they work
"blindly".
Indeed. The RLOAD program checks the file type, which presumably was
created by EDASM, not Contiki:-) The question is how to use the REL file
type for two different formats without requiring a change to the
existing tools that use the type.
I agree, moderated by the probablity that any real confusion would
ever occur in practice.
Empirically, when EDASM creates a REL ($FE) file, it sets the auxiliary
type to the value of the (last) ORG directive. As described in Appendix
E of the ProDOS Assembler Tools manual, the file includes the code
length, the code itself and an appended relocation dictionary. At
runtime, RLOAD lowers HIMEM and loads the relocatable file. It uses the
auxiliary type and the relocation dictionary to relocate the code.
The auxiliary type is used by RLOAD as the base address for relocation.
In the worst case scenario, a user would have to mistakenly use RLOAD
(via USR(0)) on a Contiki REL file. The result is hard to predict. A
cursory look suggests that RLOAD would "relocate" a single byte and
return its address, depending on the value of mode.
So RLOAD contains no "reasonableness" checks on the file's contents?
Even so, the result you describe seems relatively benign (compared
to BRUNning a .GIF file ;-).
I've implemented a few linker/loaders in the past, and the relocation
and external fixup data streams were complex enough to warrant some
validity checking, even if only to confirm that the "producer" got it
right. Ah, but the micro world was a "restart" of our computer
experience, as I recall...
While the "right" answer is not to recycle the type at all, that surely
is overly restrictive. Because an auxiliary type must be defined when
the file is created, it only makes sense to choose the auxiliary type
that is least likely to break existing code. In practice, EDASM forbids
using an ORG < $100 for a relocatable file, so an auxiliary type of
$0000 would be a reasonable alternative.
I agree with you in principle, John, but there is now so little new
development in the Apple II world that hijacking a rarely used file
type doesn't bother me much, particularly when the potential for
mischief is so remote. (How many REL files are available for
download, I wonder? And how many current users would know what
to do with them if they were?)
And the "REL file" proposed for Contiki use--a *very* limited use--
is already defined as the relocatable file format for the cc65
cross-platform assembler, which is more influenced by the C=64 than
by Apple conventions.
It appears that the first five bytes of a cc65 "REL" file are
$01 $00 $6F $36 $35, and I don't know how the file is stored
(filetype and auxtype) on an Apple system. Since it's a cross
assembler, perhaps when the file is moved to an Apple II, the
mover has complete freedom in assigning an auxtype.
As I see it, the risk of undesired effects is so small, and the
convenience factor is sufficiently high, that re-purposing REL for
Contiki seems acceptable.
The file typing system on the Apple II, even as extended by ProDOS,
is relatively weak. The designers of ProDOS recognized this when
they made it possible to BLOAD and BSAVE from/to any file type, to
make general tools more useful.
There are many more "typed" files now in the world, even the Apple II
world, than Apple "allocated". The vast majority of these files are
stored as "BIN" files, and the actual "typing" resides outside the
file system as file naming conventions and programmed validity checks.
This is a case in which the PC convention of associating file types
solely with a naming convention has proven more adaptable and robust,
particularly in the absence of a central type control authority.
-michael
Music synthesis for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it is seriously underused."