From: fachat (afachat_at_gmx.de)
Date: 2005-03-29 21:40:21
On Tue, Mar 29, 2005 at 02:08:27PM +0200, Gabor Lenart wrote:
> On Tue, Mar 29, 2005 at 01:28:14PM +0200, Ullrich von Bassewitz wrote:
> > On Tue, Mar 29, 2005 at 10:26:41AM +0200, fachat wrote:
> > > Currently I am more into option 2 (i.e. optional header), but I may be
> > > convinced otherwise.
> >
> > In my eyes, the beauty of the o65 format is its simplicity, because this makes
>
> Right, I had similar feelings inside, when I've commented as 'solve the
You are right, simplicity was and is one of the original intentions of the file format.
However, the file format has a problem with the CPU type, as the distinction from
6502 and 65816 is not enough, even the 65C02 is not handled - which should for example
be refused in a 6502 system.
On the other hand, how many different CPUs could be used:
- 6502 core (6502, 6510, 6509, 6504, ...)
I already hear the comments on IO ports at 0/1, but....:
I think these IO ports are resources that should be handled by the operating
system. If necessary the address values for the ports should be inserted into the
executable at load time using late binding.
So if the loader does not know about the addresses e.g. in a non-6510 system the load fails.
- 65C02
6502 core with the standard CMOS extensions
- 65816
- 6802
- 6809 (e.g. SuperPET)
- Z80 core
- 8080
I think with such a number of CPUs one could deprecate the "65816" header mode bit,
but define the currently unused header mode bits 4-7 into a 4 bit CPU type flag and
define the CPU types values, so up to 16 CPU types could be handled.
What do you think?
André
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.