New draft version of o65 file format

From: fachat (
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?


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.