From: Gabor Lenart (lgb_at_lgb.hu)
Date: 2005-03-30 09:44:26
Hello,
On Tue, Mar 29, 2005 at 09:40:21PM +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.
Yes, I think the integrated 6 bit IO port on 6510 (as far as I can remember
there is integrated 8bit I/O port in CPU used by C= Plus4 which is also a
CPU /w 6502 core of course, 8501/7501 was the name maybe, and no NMI pin
of the CPU by the way). Anyhow I also think that handling this integrated
IO port is the job of the OS. So only incompatibility at the core should
treat as a new CPU (like 65C02 has opcodes over 6502 also some modifications
like bugfixing of jmp indirect at page boundaries if I remember correctly
at least)
> 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
.. and 65SC02 also exists
And 65CE02 for example (used by the unfinished Commodore-65, however
some 4510 or whatever was labelled which is actually a micro controller
based on 65CE02).
So for 65xx familiy we have the following cores:
6502 original 6502 core [illegal opcodes]
65C02 CMOS 6502 /w some bugfix, no illegal opcodes
65SC02 65C02 enhanched, with Z register (always zero!), some new opcodes
65CE02 some 16bit ops/branches, Z register is modofiable
65816 16bit CPU, /w emulation/native mode, etc
Others?
The 68xx familiy is quite unkown for me, so I can't comment that.
For Zilog, there're more CPUs as well should taken, like
Z800, Z8000, Z180, even eZ80, however again: I'm not familiar with this
topic (only Z80). Also for 8080.
Maybe CPU type can be represeneted in one byte, but the highest X bits
denotes to the CPU family (like 65xx, Zilog, Intel, 68xx), and lower bits
is the CPU withing the familiy. This is usefull, for example when someone
want to introduce eg 65CE02 in the format, and in this way this remains
groupped together at least. However note, that 8 bit can eaisly become
to restrictive to describe lots of CPUs in lots of CPU families :)
However I don't think we should represent ALL possible CPUs (there're many,
but familier ones worth this I think).
>
> - 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.
Hmmm, maybe too few. Anyway, because fixed header (not the optional) size
should not be altered (this would be a major modofication) maybe only
ONE bit should be used denotes to 'obsolates old 6502/65816 type bit if this
set' and use optional header to mark CPU type. Old tools can easily ignore
optional header so not a compatibility issue.
>
> What do you think?
>
> André
>
>
>
> 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.