Yes, I have some experience with 65c816 CPU. I made simple 86c816 Adpater (http://hardware.atari8.info/65816.php) and Turbo816. Here are files for GALs:

GAL1
*IDENTYFICATION
 clk_man;
*TYPE
 GAL16V8
*PINS
  PHI1S         = 2,     
  PHI1F         = 5,     
  SLOW            = 6,     
  Reset         = 7,     
  Halt            = 8,     
  RDY            = 3,     
  RW_in         = 9,     
  Q0.r            = 16,    
  Q1.r            = 17,    
  Q2.r            = 15,
  PHI1.t        = 18,     
  Clock.t       = 19,
  Bank_L.t      = 13,
  RW_out.t      = 14,
  A_Bus_EN.t    = 12;

*BOOLEAN-EQUATIONS
  /Q2 = /Q1 & Q0 & Reset;
  /Q1 = /Q1 & Q0 & Reset + Q2 & /Q0 & Reset;
  /Q0 = Q2 & Q1 & Reset + /Q2 & /Q1 & Q0 & Reset;

  Clock.e = Vcc;
  Clock = Q2 & Q1 & Q0 & SLOW & /PHI1 + Q2 & Q1 & /Q0 & PHI1F
    + Q2 & /Q1 & /Q0 & /PHI1F + Q2 & /Q1 & Q0 & /SLOW & /PHI1
    + /Q2 & /Q1 & Q0 & PHI1S + /Q2 & /Q1 & /Q0 & /PHI1S
    + /Reset;

 %Outputs%

  PHI1.e = Vcc;
  PHI1 = Q2 & Q1 & Q0 & PHI1S + Q2 & /Q1 & Q0 & PHI1F;

   Bank_L.e = Vcc;
  /Bank_L   = /PHI1 + /RDY;

   RW_out.e = Vcc;
  /RW_out   = Q2 & Q1 & Q0 & Halt & /RW_in
        + /Q2 & /Q1 & /Q0 & Halt & /RW_in;

   A_Bus_EN.e = Vcc;
  /A_Bus_EN   = Q2 & Q1 & Q0 & Halt + /Q2 & /Q1 & /Q0 & Halt;
*END 

 Bankdecoder and AV generator (GAL2)
*IDENTYFICATION
 bankman;
*TYPE
  GAL16V8;
*PINS

 %Inputs%

 BA7    = 1,
 BA6    = 2,
 BA5    = 3,
 BA4     = 4,
 BA3    = 5,
 BA2    = 6,
 BA1    = 7,
 BA0    = 8,
 PHI2F  = 9,
 DCLK    = 11,
 PHI2    = 17,
 A_Bus_EN  = 13,

 %Outputs%

 AV    = 12,
 Data_EN = 16,
 OE = 15,

 RAM    = 18,
 SLOW    = 19;

*BOOLEAN-EQUATIONS

 /AV     = /DCLK & /PHI2F + PHI2F;

 /SLOW = /BA0 & /BA1 & /BA2 & /BA3 & /BA4 & /BA5 & /BA6 & /BA7;

 /Data_EN = /A_Bus_EN & PHI2;

 /RAM = BA1 & /BA2 & /BA3 & /BA4 & /BA5 & /BA6 & /BA7;

 /OE  = PHI2F & /DCLK + /PHI2F & DCLK;

*END

I had some problems with Turbo816 so I designed Warp4 with 1MB linear memory (schems soon).

Now I'm working on a double CPU card.

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 ... :/

Draco, when the first alpha will be sent to betatesters?

Stryker, wyjasniam: pan mowi o procesorze teraz ;)
Tylko patrzec jak ktos napisze:
"Don't know for others but I'll probably finish preparing Doom for Atari XL/XE tonight." ;)
(4 english people: it was joke :)

a po to, że ten topic jest lekcją angielskiego z native speakerem (wyjaśnienie: to taki człowiek, który potrafi po swojemu, ale nie idzie mu po naszemu). :twisted:

Draco - to jak będzie to już możliwe - to testowy OS podżuć mi na maila - jeśli można. :D

When I read about this new OS, I read sometimes that there isn't enough room in the original OS. But it must be possible to have a bigger ROM somewhere between $10000 - $FFFFF and run 16-bit code from there...

Yes, this is something I would like to see, this new ROM can be a FLASH rom. An update could just loaded without re-programming an eprom  8)
A bigger OS Rom could add more features aswell...

The problem for me is, I can't read polish so I can only read/write english I don't hope it will be a big problem overhere. I must say this is the most interesting forum I've visited until now. Nice to see so many real active 8-bit users  :lol:

:mrgreen:

jurgi ty nie boj nic:
"Dokumentacja jest jak seks, gdy jest zajebista - jest zajebista, gdy jest cieniutka, jest lepsza niz nic"

Tlumacz i nie piernicz :)

Well, here:

http://82.210.159.30/xlos.zip

There are two binaries, xlos.bin is earlier and it's interrupt routines are at the same place as in the original XL OS rev. B.

In the xlos2.bin the IRQ and NMI routines are moved to new locations. This version will be developed further and I would prefer this version to be tested.

Ok, what it should already do:

1) start up successfully ;-)
2) the CPU native mode should be now available without switching interrupts off;
3)  there's a test for extended linear memory, peek(591) should return a number of *additional* (i.e. beyond the first 64k) 64k memory segments;
4) the FP functions should be a bit faster than in the original;
5) the boot drive number is no longer initialized inside the BOOT routine, it is done while initializing other disk related variables. The new device can now effectively change the boot drive number simply updating the DUNIT.

The vectors I've described previously (in the "specifications") should be correctly initialized at reset time and work properly. This wasn't yet tested.

The OS revision number is BB 01.90. The release date is the Independence Day.

There are changes all around the first 4k of ROM, in the FP ROM and at the end of the second ROM block too. The interrupt vectors located in RAM will point to different locations. The ROM-based vector tables may contain different values. Some of the jump table entries may be changed as well.

Ok, what does not work:

1) The Self Test will definitely not work correctly;
2) the rev. number, OS release date etc. is not available in the second ROM part ($d800-$ffff, close to the top of memory, I don't remember the address);
3) the second ROM block checksum is available at $FFDE, not $FFF8;
4) Encounter (the game) probably will not work due to different ROM checksums; this is fixable.

I already have this version of ROM (the xlos2.bin) in my computer and it starts up properly and appears to work correctly. Please test and report problems. Thanks.

Polish version:

Panowie, chyba rozumiecie po angielsku :-)

[ Dodano: 13.11.2004 02:33:20 ]

So what about learning some polish finally? The language is quite easy ... and polish :D

[ Dodano: 13.11.2004 02:48:20 ]

Well, there is some place even in the original OS.