Re: New draft version of o65 file format

From: fachat (
Date: 2005-03-29 10:26:41


On Tue, Mar 29, 2005 at 09:37:04AM +0200, Gabor Lenart wrote:
> Hello!
> Nice. However I've got an idea.
> The method .o65 format encodes the CPU "platform" the object code /
> executable was created for is very limited. I mean, the .o65 format _is_

This is indeed a good point. I see a number of options of which I am not
clear of and which should probably be discussed here:

* "compatible options"
  (i.e. old 6502 files still work, and new 6502 files work on old machines)

  1) re-define an existing mode bit to define an "extended" header, that 
  allows for two new header bytes (length to be discussed), e.g.
  with one byte CPU family ($65 = 65xx, $80 = Z80, $68 = 6809 etc)
  and one byte CPU model (e.g. 6502 vs. 65C02)
  The mode bits in question to be redefined would be 65816 or the "size" bit.
  (is the format used for 65816 or 32bit code anyway?)

  2) another version would be to declare the 65816 bit deprecated
  and require a new CPU-type optional header as already defined. 
  Which would be different from the OS type, as there are systems with 
  multiple types of CPU in one system.

  Either of this could be defined in a v1.4 version.

  Unfortunately this defines some "asymmetry" between the 6502 and
  other CPUs. However, I see no compatible way to change that

* incompatible changes

  3) remove the 65816 bit, and add a CPU family type byte and CPU model
  type byte (as above) in the header.
  This could be put into a v2 version of the format. However, I wonder 
  how much this version would be accepted with this incompatible change.

Currently I am more into option 2 (i.e. optional header), but I may be
convinced otherwise.

Looking for comments.


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.