From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-11-28 21:16:42
On Thu, Nov 28, 2002 at 04:24:46PM +0100, MagerValp wrote:
> But more bytes are pushed on the stack in native mode
This is not a problem, because the 3 low bytes (that may be accessed in an
interrupt handler) are the same as in 6502 mode. The additional byte that is
pushed by an IRQ is poped by the RTI, so it is invisible for the programmer
and does not need special care.
> and the hand-
> ling of the BRK bit is different, so the kernal IRQ handler needs to
> be completely rewritten.
Even this is not a problem as long as there are no BRK instructions in your
code (which should be the usual case).
> Also the new IRQ vectors ($FFE5..$FFEF)
> collide with the kernal jump table.
The COP vector at $FFF5/$FFF6 is unused. It needs special hardware to be of
any use. The new BREAK vector at $FFF7/$FFF8 would be a problem, but since
normal code does not have BRK instructions, this vector will never be used.
The new BREAK vector will NOT collide with the kernal jump table (the last
byte of the kernal jump table is at $FFF5). The 4 bytes at $FFF6 are unused in
the C64 kernal, and I would assume that the CMD kernal for the SCPU has a
valid BREAK vector in that location that is routed to the indirect kernal
vector. I'm not sure about this, but since the space where the vector resides
is not used anway, it would have been plain stupid not to do so.
> Having the DBR set to a bank
> different than 0 breaks many kernal routines.
In the small memory model described in my earlier mail DBR is set to zero, so
even this is not a problem.
I've used the method described above to run Elite 128 in 65816 native mode.
All that was needed was detection of the 816 and the additional SEP
instruction.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-11-28 21:17:00 CET