65816 target...for the c64

[xlar54]

Hey there, Im the guy you have been helping over on 6502,org. I think I understand now what the issue is. You have a 6502 build of the compiler and a c64 target. But c64 (and c128) users who own a supercpu are actually needing the 65816 compiler/linker. So the prg output type is still needed in the 65816 linker.

Can this be added? The prg type should add the start bytes just as the 6502 one would.

[hth313]

Yes, that can be definitely be added. How urgent are you to get a release? Which host platform do you use?

[xlar54]

pretty urgent if possible. I tried the WDC compiler but its not really that great. would like to use Calypsi. I work from Windows, but I also use MSYS

[hth313]

I made a developer snapshot for Windows that you can try out https://drive.google.com/file/d/1OUECq9ow64ioHswAFpjWdLvYpKj2lXUM/view?usp=sharing

[hth313]

Did you try it out to see if the fix works? I have also made a real release that contains support for PRG output files, see https://www.calypsi.cc/

[xlar54]

Sorry for the late reply. Im trying now, but I get an error:

multiple program areas not allowed in prg output

Here's my rules file:

(define memories '( (memory DirectPage (address (#x0000 . #x00ff)) (section (registers ztiny zzpage zpage)) ) (memory stack (address (#x100 . #x1ff)) (section stack)) (memory program (address (#x0801 . #xbfff)) (section (programStart #x801) (startup #x80e) code switch cdata data_init_table izpage znear) ) (memory data (address (#x0c000 . #x0cfff)) (section cstack data heap) ) (memory Vector (address (#xfff0 . #xffff)) (section (reset #xfffc)) ) (memory Bank1 (address (#x10000 . #x1ffff)) (section farcode far cfar ) ) (memory ExtBanks (address (#x20000 . #x7ffff)) (section zfar zhuge huge) ) (block cstack (size #x0800)) ; C stack size (block stack (size #x0100)) ; machine stack size (block heap (size #x06ff)) ; heap size (base-address _DirectPageStart DirectPage 0) (base-address _NearBaseAddress program 0) ) )

and here's my cstartup.s:

        .rtmodel cstartup,"supercpu64"

        .rtmodel version, "1"
        .rtmodel cpu, "*"

        .section stack
        .section cstack
        .section heap
        .section data_init_table

        .extern main, exit
        .extern _Dp, _Vfp
        .extern _DirectPageStart

ifndef __CALYPSI_DATA_MODEL_SMALL__

        .extern _NearBaseAddress

endif

include "macros.h"

;;;

---

;;; ;;; The reset vector. This uses the entry point label __program_root_section ;;; which by default is what the linker will pull in first. ;;; ;;;

---

          .section reset
          .pubweak __program_root_section

program_root_section: .word program_start

;;;

---

;;; ;;; __program_start - actual start point of the program ;;; ;;; Set up CPU stack, initialize sections and call main(). ;;; You can override this with your own routine, or tailor it as needed. ;;; The easiest way to make custom initialization is to provide your own ;;; __low_level_init which gets called after stacks have been initialized. ;;; ;;;

---

.section code,noreorder
.pubweak __program_start

__program_start: ; provides BASIC startup: "10 SYS 2062" .byte 0x01, 0x08 ; always zero, load address .byte 0x07, 0x08 ; pointer to next line .byte 0x0A, 0x00 ; line number (10) .byte 0x9e ; SYS token .ascii " 2062" ; SYS address in ASCII .byte 0, 0, 0 ; end-of-program

          clc
          xce                   ; native 16-bit mode
          rep     #0x38         ; 16-bit registers, no decimal mode
          ldx     ##.sectionEnd stack
          txs                   ; set stack
          lda     ##_DirectPageStart
          tcd                   ; set direct page

ifdef __CALYPSI_DATA_MODEL_SMALL__

          lda     ##0

else

          lda     ##.word2 _NearBaseAddress

endif

          stz     dp:.tiny(_Vfp+2)
          xba                   ; A upper half = data bank
          pha
          plb                   ; pop 8 dummy
          plb                   ; set data bank

;;; **** Initialize data sections if needed. ; .section code, noroot, noreorder ; .pubweak data_initialization_needed ; .extern initialize_sections ;data_initialization_needed: ; lda ##.word2 (.sectionEnd data_init_table) ; sta dp:.tiny(_Dp+6) ; lda ##.word0 (.sectionEnd data_init_table) ; sta dp:.tiny(_Dp+4) ; lda ##.word2 (.sectionStart data_init_table) ; sta dp:.tiny(_Dp+2) ; lda ##.word0 (.sectionStart data_init_table) ; sta dp:.tiny(_Dp+0) ; call initialize_sections

;;; **** Initialize streams if needed. ; .section code, noroot, noreorder ; .pubweak call_initialize_global_streams ; .extern initialize_global_streams ;call_initialize_global_streams: ; call initialize_global_streams

;;; **** Initialize heap if needed. ; .section code, noroot, noreorder ; .pubweak call_heap_initialize ; .extern heap_initialize, default_heap ;call_heap_initialize: ;#ifdef CALYPSI_DATA_MODEL_SMALL ; lda ##.sectionSize heap ; sta dp:.tiny(_Dp+2) ; lda ##.sectionStart heap ; sta dp:.tiny(_Dp+0) ; lda ##__default_heap ;#else ; lda ##.word2 (.sectionStart heap) ; sta dp:.tiny(_Dp+6) ; lda ##.word0 (.sectionStart heap) ; sta dp:.tiny(_Dp+4) ; lda ##.word2 default_heap ; sta dp:.tiny(_Dp+2) ; lda ##.word0 default_heap ; sta dp:.tiny(_Dp+0) ; ldx ##.word2 (.sectionSize heap) ; lda ##.word0 (.sectionSize heap) ;#endif ; call __heap_initialize

          ;.section code, root, noreorder
          lda     ##0           ; argc = 0
          ;call    main
          jsr main
          rts

On Sat, May 7, 2022 at 7:04 PM Håkan Thörngren @.***> wrote:

Did you try it out to see if the fix works? I have also made a real release that contains support for PRG output files, see https://www.calypsi.cc/

— Reply to this email directly, view it on GitHub https://github.com/hth313/Calypsi-tool-chains/issues/1#issuecomment-1120319618, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOSHCV4AXILONL2H3YFFMTVI4AHFANCNFSM5PI76UMA . You are receiving this because you authored the thread.Message ID: @.***>

[hth313]

As far as I understand, multiple program areas are not part of the C64 program format. It is just a start address prepended to a single chunk that is to be loaded into memory.

[xlar54]

Understood.. But Im not trying to create multiple program areas.  Not sure why its giving me this.  If I sent you the project, could you take a look?  Its really small.   Sent from Mail for Windows From: Håkan ThörngrenSent: Thursday, June 9, 2022 4:21 PMTo: hth313/Calypsi-tool-chainsCc: Scott Hutter; AuthorSubject: Re: [hth313/Calypsi-tool-chains] 65816 target...for the c64 (Issue #1) As far as I understand, multiple program areas are not part of the C64 program format. It is just a start address prepended to a single chunk that is to be loaded into memory.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***> 

[hth313]

You can generate some other format that supports multiple areas, like PGZ, Intel-Hex or S-records, then generate a list file and see what memories you have.

However, looking at your list you seem to have a Bank1 memory with code and data bits. There is also a Vector area defined where you put reset, that is another memory.

[xlar54]

Ok, this is the output:

Name Range Size Memory Fragments

registers 000000-000013 000014 DirectPage 1 stack 000100-0001ff 000100 stack 1 code 000801-000840 000040 program 4 switch 000841-000858 000018 program 1 data_init_table 000859-000862 00000a program 1 cstack 00c000-00c7ff 000800 data 1 heap 00c800-00cefe 0006ff data 1 reset 00fffc-00fffd 000002 Vector 1 farcode 010000-01137a 00137b Bank1 32 cfar 01137b-011387 00000d Bank1 1 farcode 011388-0113af 000028 Bank1 4 cfar 0113b0-0113b7 000008 Bank1 1 farcode 0113b8-0113be 000007 Bank1 1 cfar 0113bf-0113c5 000007 Bank1 1 farcode 0113c6-0113d6 000011 Bank1 5 zfar 020000-020103 000104 ExtBanks 4

looks like switch and data_init_table are also program areas, but if I remove them, it complains that they arent bound to any memory area.

On Thu, Jun 9, 2022 at 5:42 PM Håkan Thörngren @.***> wrote:

You can generate some other format that supports multiple areas, like PGZ, Intel-Hex or S-records, then generate a list file and see what memories you have.

However, looking at your list you seem to have a Bank1 memory with code and data bits. There is also a Vector area defined where you put reset, that is another memory.

— Reply to this email directly, view it on GitHub https://github.com/hth313/Calypsi-tool-chains/issues/1#issuecomment-1151687500, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOSHCTE6O5YHFIHM6RL2NDVOJXMPANCNFSM5PI76UMA . You are receiving this because you authored the thread.Message ID: @.***>

[hth313]

You can use simplified linker files, by adding (type any), (type ram) or (type rom) to a memory as appropriate, then let the linker sort most of the sections out for you. You still need to keep the specific located programStart and startup, but the tool defined sections you can remove, provided that you add a type to the memories which you want automatic placement in.

What about farcode, it is code and it is in bank 1, that will not work with Commodore PRG format. How are you planning to load it into memory? Is there a (kernel?) loader that can load into different areas from a single executable file? Are you going to load on small program into the main memory bank00, then load separate files into other areas using code of your own?

[xlar54]

Actually you gave me an idea. I could write, using normal Commodore C code to load another program into bank 1 (or wherever I need it to be). The second program would be compiled as a 65816 C program. I might try this. Thanks

On Fri, Jun 10, 2022 at 12:53 AM Håkan Thörngren @.***> wrote:

You can use simplified linker files, by adding (type any), (type ram) or (type rom) to memory as appropriate, then let the linker sort most of the sections out for you. You still need to keep the specific locationed programStart and startup, but the tool defined sections you can remove if you add a type to the memories you want automatic placement in.

What about farcode, it is code and it is in bank 1, that will not work with Commodore PRG format. How are you planning to load it into memory? Is there a (kernel?) loader that can load into different areas from a single executable file? Are you going to load on small program into the main memory bank00, then load separate files into other areas using

? Is there a suitable executable format with multiple memories that can be loaded on your machine. In this case even 24-bit addressing, see farcode in Bank1 memory.

— Reply to this email directly, view it on GitHub https://github.com/hth313/Calypsi-tool-chains/issues/1#issuecomment-1151975110, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOSHCVAB24OYTOTM5HEQADVOLJ43ANCNFSM5PI76UMA . You are receiving this because you authored the thread.Message ID: @.***>