From: fachat (afachat_at_gmx.de)
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? Andre Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.