From: Gabor Lenart (lgb_at_lgb.hu)
Date: 2005-03-31 11:48:04
On Thu, Mar 31, 2005 at 10:41:41AM +0200, Ullrich von Bassewitz wrote:
> > 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.
>
> It would be good to specify that it depends on the implementation if this bit
> is honoured or not.
>
> > I would like to specify two more header mode bits as "CPU" bits:
>
> Which bits are these? It seems that the web document is unchanged.
>
> > 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?).
>
> There are quite some bits left in the mode word. If this is the final 1.x
> version, why not spend a few more bits for more CPUs? This would help Gabor
> and not harm anyone else. Just a suggestion:-)
Yes. If we have enough bits :) However the whole CPU type issue is not
a problem, I think we have enough bits to use in mode word for current
needs and if it become not enough ... well. Maybe tomorrow :)
By the way I need specifying Z80 and some Intel CPUs (8086/128/286) ...
> > - o65 is currently not suitable as object format for
> > cc65 - I don't know the reason, but maybe this could be
> > fixed as well.
>
> I doubt that, because it would require adding more features than there are
> currently in o65:-) Here is an incomplete list, of what would be necessary:
Well, cc65 and its object format and its linker is my favourite toolchain
even compared to the eg GNU toolchains :)
However this is exactly my problem: there is a very good object format used
by cc65 only for development (eg to get object files you want linker to feed
with to get something OTHER which can be used to execute/load/etc by the
target system). And we have .o65 which is used by cc65 too (and by other
projects) to load 'drivers' run-time and such.
As I've written, modern OS'es does linking when 'execute' something for
real, this is done by the run-time linker, so there is no major difference.
However asserts, and expression trees are something which would be VERY
costly to implement eg in an OS designed for a 8 bit computer ...
Exactly this is why I'm thinking about a COMPLETE specification, but
'profiles' to allow to implement only a given subset of the full
specification, mainly useful when using the format for 'executables' or
'libraries' on the target system. Of course the full specification can be
easily implemented in cross-development tools because there is no problem of
code size and speed when running development tools on a PC for example ...
The problem is that this theory is quite far from .o65 (well, at this point)
it would be more simple to say that object format used by cc65 would be
the new standard and some subset of it would replace .o65 :)
> > - GeckOS
> > - opencbm
>
> Contiki (uses o65 for "programs" on 6502 platforms), maybe Lunix once it wakes
> up from its hiatus:-)
Tough I've only checked Lunix for a while some years (?) ago, Lunix Next
Generation (LNG) site (http://lng.sf.net) say that site is updated
at 2004 Sep 10, so it is not so old and dead? From the site:
* Support for o65 object format (it means that apps can be written using cc65 asm and (soon) C suite)
> Only speaking for me: As long as the current advantages of o65 are kept, and
> the new format has useful new features, I would support it. I have to admit
> that there are not many things that I could imagine to be useful but no
> additional overhead. More CPU types are an example, maybe more segments - but
> the latter case is almost crossing the border to "loose advantages of the
> current format" (depends on the actual implementation).
Of course multiple segment support should kept as optional feature, I mean
why the hell you should complicate your loader if the current scheme is
more than enough for _your_ needs?
- Gábor
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.