From: Gabor Lenart (lgb_at_lgb.hu)
Date: 2005-03-31 10:27:30
Re,
On Thu, Mar 31, 2005 at 12:13:02AM +0200, fachat wrote:
> here some "final words" :-)
This means I should not continue to post in this topic? :)
Please warn me if this is the case I don't want to become a flame only
person here :)
> 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.
Maybe, however I haven't need any extra feature (YET) which was caused
by the CPU type only. Maybe byte order? :) But this is not an issue for
me at least, since Z80, intel CPUs and 65xx CPUs use the same byte order :)
> 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.
Yes.
> 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
Yes. As I've realized it should be VERY ugly to mess the format up
with tricks like doing some stuffs in optional header, which means
larger and more complex loaders which is not a goal. For major
feature extension I think incomaptibility changes should be done instead,
which means eg v2.0 format to show the increase of major version number
or such :)
> producing code for the 6502). A goal should be to minimize the
> (6502) code to load the file.
Yes.
> [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.
File extension is a human abstraction only, I mean in case of UNIX like
systems they're manditory eg there is not extension to sign executable
(like .EXE in DOS). Ok there is a common habbit to eg denote ".o"
string as an the "extension" (though it is not an extension, that
notion cannot be interpreted in a UNIX like system). I've only written
this because I don't know what kind of extension you're talking about
and what kind of role you want to be played for this extension.
> - 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?)
14? :) As somebody - now very rich - said before: "... should be enough
for everyone" :)
> 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.
Hmmm, I don't know this is a goal or not. cc65 package (I mean the
assember, linker, C compiler ...) is a very nice stuff, I'm using its
assembler (ca65). However I'm created programs with even dozen of
segments so of course it would be not possible when using .o65, since
it does not support multiple segments.
> 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?
I've used sdcc (http://sdcc.sf.net) to compile some C code for Z80.
The object format used by sdcc package is some kind of text based
"hexdump like" (at least of the first sight :) files. About a year
ago I've written a program which creates an assembly file from this
kind of objects which than can be compiled by ca65 to get object
file format of cc65 suite (this is similar to the co65 tool for
o65 format). Of course you can later convert this further even to
o65 format with co65 utility. However it would be nice to create possibly
independent tool to convert between famous object formats used by 8 bit
developments.
This is because I *REALLY* love the linker of cc65, it's quite nice work,
worth to use it :) Even for developments for eg Z80 which is not supported
by the cc65 package officially :)
Also (fasten seat-belt now :) tried to use Turbo C compiler (yes the old
DOS one: it's a quite nice compiler, to create code for 8086/80186 is
possible BCC used by the ELKS project but tc generated MUCH better code),
which was re-released by Borland as 'freeware'. Of course some kind of
.OBJ -> .o65 conversion needed but in this way I wanted to use .o65 format
even for PC Operating System, of course not 32 bit ones :) However I've
never played enough with this because of the lack of enough free time.
For more information I've found this: http://www.alfonsomartone.itb.it/fhlvnr.html
At this point you can easily say: "well you're crazy: wanna support all
systems from 6502 to Sun Fire V120 or something"? Of course not: but I think
if the format IS almost suitable for something it's right to use it. I mean
even 8086 (or even 80286) hehaves quite similar to a 8bit CPU, allows addressing
64K only at once, the _only_ problem is the support of multiple segments which
would be useful for eg a 65xx based system as well when doing memory banking/
paging.
> and which systems will support it:
>
> - GeckOS
> - opencbm
And Contiki&cc65 combo :)
> I wonder, if I define a new - incompatible - format, how many
> people will actually use it?
I would do this :)
>
> Andre
>
>
> Message was sent through the cbm-hackers mailing list
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.