From: fachat (afachat_at_gmx.de)
Date: 2005-03-31 00:13:02
Hi all,
here some "final words" :-)
I think the o65 file format is a very simple (for a relocatable
format) and should stay like this.
It is not intended for other CPUs (although it can be used there),
but other CPUs have other requirements which are not handled.
I have now added a new "chain" bit in the header mode word, to
signal that the o65 is followed by another o65 file, e.g. for
another memory segment.
I would like to specify two more header mode bits as "CPU" bits:
if 6502 mode:
00= 6502 original 6502 core [illegal opcodes]
01= 65C02 CMOS 6502 /w some bugfix, no illegal opcodes
10= 65SC02 65C02 enhanched, with Z register (always zero!), some new opcodes
11= 65CE02 some 16bit ops/branches, Z register is modofiable
but if accepted here, this would be the final change to the
v1.x set of releasesi (for now?).
I don't think that any of the requested features (see below) can
be implemented in an easy, compatible way into the file format.
Therefore there should be a new set of releases, say "o65ng" or o65 v2.
It should be derived from o65, in most parts compatible (esp. when
producing code for the 6502). A goal should be to minimize the
(6502) code to load the file.
[don't worry, if I do this, it will have the same building
blocks as o65 already has, in mostly the same or compatible way]
As new features it should have these additional
features (that I read from the mail discussion here):
- multiple CPU types (different CPU families), e.g.
6502, 65816, Z80, 6809, 6802, 80286
This *may* have consequences in the relocation tables
e.g. with different types of entries
probably a new file extension would be ok then.
- more flexible segment handling, i.e. more than the
current fixed number of segments. However, if there is
to be cross-referencing between segments with relocation,
the relocation table needs to address all segments, and
this may impose a restriction on the number of segments
(would 14 be enough?)
However, maybe making the "simple" file format required
is not an option, but it should be kept as an option.
- o65 is currently not suitable as object format for
cc65 - I don't know the reason, but maybe this could be
fixed as well.
Did I miss anything? However, I am still wondering, what
happens to a format with a almost non-existent toolchain:
- cc65
- xa65
- assemblers for other CPUs?
and which systems will support it:
- GeckOS
- opencbm
I wonder, if I define a new - incompatible - format, how many
people will actually use it?
Andre
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.