From: fachat (afachat_at_gmx.de)
Date: 2005-03-29 10:26:41
Hi,
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.
Andre
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.