4) Are there users that already have written some special programs for the 65816 maybe even a new/patches OS ?
Don't know for others but I'll probably finish preparing 65c816 OS ROM tonight.
[ Dodano: 11.11.2004 05:51:56 ]
Here is some specification, if you're interested:
The 65c816 XL/XE OS revision
============================
I. Targets
----------
1) make possible to use the 65c816 native mode on Atari XL/XE computers without problems and with interrupts enabled. The XL/OS rev. B does not contain any sensible values at the place where the 65c816 expects the native interrupt vectors, hence the crashes.
2) make the memory mapped at extra addresses ($010000-$ffffff) accessible and usable for programs. Running code in this memory requires switching to native mode, and for native mode see above.
3) provide some more extra services related to the 65c816 such as new interrupt vectors, basic memory management routines etc.
4) develop new system of entry points: current mechanism of making ROM calls is difficult to use, when the code resides above the address $FFFF.
5) update the FP routines and make them somehow faster (low priority).
6) remove the SelfTest and replace it with something more sensible.
Provide extra testing routines too.
7) prepare a 65c816-aware, loadable version of Atari BASIC (last).
8) possibly expand the printer handler, so that it could be directly used with other printers than Atari printers (low priority).
9) fix known bugs.
II. Victims
-----------
To achieve this, possibly some code that actually resides in the ROM will have to be removed. Order of doing this:
1) the removal/rewrite of the SelfTest will already release some place
right before the charset 2.
2) the actual OS code can be "compressed" using new 65c816 instructions and addressing modes. This already takes place.
3) it is expected that larger ROM areas can be reclaimed by removal of the C: (cassette recorder) handler and all the related code.
4) 1k of ROM can be reclaimed by removing the charset 2. I'd like to
avoid that.
III. Interrupt considerations
-----------------------------
The native interrupt services impose a good deal of problems. Because of the lack of free ROM space, we basically have to put things together so that the same interrupt routines serve for both native and emulation
modes.
We presume that:
1) all interrupts execute in bank 0 (both code and data); the interrupt
routine resets the B register and restores it upon exit.
2) all interrupts operate on the "real" zero-page ($0000-$00FF); the
interrupt routine resets the D register and restores it upon exit.
3) all interrupts operate on user stack; the interrupt routine does not
realloc itself to the system stack.
4) all system interrupt routines must be perfectly executable in emulation mode.
5) no system interrupt routine switches ever from native mode to emulation or backwards.
6) the same return code may be used for both native and emulation routines (this is even a must for NMI->SYSVBL->EXITVBL sequence).
Disadvantages:
1) big interrupt overhead in the native mode; the CPU state must be
accurately saved no matter what, and the 65c816 has much more registers and much more processing states than 6502. In the case of DLI the registers do not have to be saved, but the service routine must be executed in some predefined state. This takes a lot of cycles too.
2) slower interrupt processing for the 8-bit code is used.
Advantages:
1) no double interrupt service routines - we're short of ROM space!
2) stable interrupt overhead in the user selected CPU mode: the OS does not switch emulation/native modes beyond the user control (except for system call).
3) the user can employ the same interrupt routines for both modes.
At the other hand, the interrupt overhead is reduced in the emulation mode thanks to new instructions and addressing modes. For example, the NMI serivce routine, which takes 32 cycles on 6502, is shortened to 26 cycles on 65c816. Similarly the EXITVBL routine is reduced from 23 to 19 cycles, and other savings take place inside the actual SYSVBL. All this does not balance the increased interrupt overhead in the native mode, reduces it however.
IV. New system call mechanism
-----------------------------
The old system call mechanism present in the XL OS, based on a jump table and JSR calls, has a limitation that makes its usage problematic with new, 65c816 programs, which can possibly store the code beyond the 64k boundary.
Namely, the JSR instruction has a 16-bit argument, and thus cannot cross the 64k bank boundary. As a result, when you make a JSR $E459 call while your program is executing in the bank 0 (and on 6502 this is always the case), the call will reach its destination, i.e. the $00E459, where the actual ROM procedure resides. However, doing the same in bank 1 makes the call go to $01E459, which is not the place where it should actually find itself.
At the other hand, the 65c816 offers a JSL call, jump to subroutine long, which accepts 24-bit address as an argument and stores a 24-bit return address on the stack. However, the ROM routines expect a 16-bit return address to be stored, and we have to keep this behaviour to maintain compatibility with older programs. Thus, the JSL instruction cannot be used to call the system.
Providing an alternative jump table (for long calls) would solve the
problem, but first of all it would be a great waste of ROM space. Not to
mention the fact, that the jumptable metod is not considered very
flexible, as you can never change the vectors which are in ROM, thus you can't patch the OS with software, when necessary.
a) The new calling method
The new calling method is based on the COP instruction handler. COP
generates an unmaskable software interrupt, quite similar to the TRAP
instruction on the Motorola 68k. The COP accepts a constant (immediate) argument. The instructions with the arguments of the value from $80 to $FF are reserved by the WDC for future usage, possibly for new instructions. The rest, i.e. the range from $00 to $7f, is available for our definition.
b) The new OS vectors in RAM
The COP handler residing in ROM defines five new vectors in the memory. All of them are 24-bit long. These are:
VCOPE $000256-$000258
VCOPN $000259-$00025B
Two COP interrupt vectors, for the emulation and native mode
respectively. The first is not used by OS for now, it simply points to
the RTI instruction. The reason for that is, that being in emulation mode
you do not really need the new calling mechanism, you may happily use the old one, as you cannot run code behind the first 64k anyways.
The other vector, VCOPN, points to the system handler. If you change this vector, you must end your code with a JMP to the old location, or RTI if you bypass the ROM completely.
VCOP0 $00025C-$00025E
VCOPU $00025F-$000261
VCOPC $000262-$000264
These are secondary vectors jumped through by the system handler (the one pointed to by VCOPN). The code pointed to by them is called with a JSL instruction and must be ended with RTL (or a JMP to the old location).
The first vector is called, when a COP #$00 is executed. This instruction
is reserved for the usage of the operating system, details below.
The second vector is called when any COP instruction with an argument
range $01-$7F is executed. The third vector is called when the reserved COP instructions are executed (i.e. argument range $80-$FF).
The long vector at $000018 points to the argument of the instruction that caused the call (i.e. if COP #$00 was executed, the vector points to the "#$00" part of the instruction).
All the secondary vectors are called with D=0 and B=0. The VCOP0 vector is called with 8-bit registers. The VCOPU and VCOPC vectors are called with 16-bit registers. The contents of the CPU registers is unmodified and should be the same as when the COP interrupt occurred. The handler residing at the primary vector (VCOPN) is responsible upon exiting for restoring the CPU context to the state being actual prior to the call.
c) Special meaning of the COP #$00 instruction
The COP #$00 instruction has been defined as a system emulation
interrupt. The ROM handler residing behind it accepts a 16-bit address
pointing to a location within the bank 0 (first 64k), calls it with a JSR
instruction, and returns the results of the call to you. Upon exit, the
registers contain values returned by the OS. The P register bits returned by OS are preserved except for bits M and X, which are restored to the state prior to the call.
Here's an example of a system call using new calling method:
sep #$30 ;set 8-bit registers
ldx #$10 ;select IOCB #1
lda #$0c ;command: CLOSE
sta >iccmd,x ;store
pea jciomain ;push the OS function address
cop #$00 ;call the OS
pla ;pop the argument off the stack
pla
CHANGE LOG
==========
11.XI.2004.
- OS version number changed to BB 01.99;
- completed the COP handler;
- fixed bug in NMIENBL: enable the VBL after the flags are updated;
- setting the boot drive number moved from BOOT (after the PBI devices initialization) to the DISKINIT (before the PBI devices initialization);
- wrote a large part of this document;
10.XI.2004.
- the P: handler optimized with new 65c816 instructions, so that the
native interrupt vectors could fit well at the end of the ROM. Serial
number etc. removed on the same purpose.
- implemented NMI and IRQ pre-handler for native mode.
- SYSVBL modified (stack access)
- wrote most of the COP handler
- wrote most of this document
[ Dodano: 11.11.2004 05:53:18 ]
PS. Dely, wiem, to powinno iść do działu Software ... :/