Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

26 Excellent

1 Follower

About JesperGravgaard

  • Rank
    Space Invader

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I honestly did not really consider portability from cc65's library when creating the headers. I made a quick check, and it seems the macro-based solution above generates the same ASM as the current pointer-to-struct solution. So it would probably be possible to make the chipset headers more portable by using the same member names and using a macro instead the pointer-to-struct. The lack of unions in the current version of kickc may result in some compatibility issues - if the cc65 structs utilize unions. If anyone here in the forum want to have a go at creating the header-files I will gladly merge them into kickc. In any case I will add a TODO to my list.
  2. The C standard is pretty clear that the signedness of char is implementation dependant. See for instance A.4.2 in https://xuron.com/uploads/Kernighan_Ritchie_Language_C.pdf The 6502 CPU is better at performing unsigned numeric operations than is it at at signed numeric operations. This is especially true for comparisons. Try looking at section 5 in http://www.6502.org/tutorials/compare_beyond.html This is the reason I decided that a C-compiler targetting the 6502 platform should have unsigned char as the default. The aim of the compiler is to help people create C-code that runs as fast as possible on the 6502, and unsigned chars run faster than signed chars. So I felt unsigned was the best default. The authors of cc65 seems to have made the same choice. /Jesper
  3. The headers for the ATARI chipset included in the KickC release is based on pointers to structs. // Atari GTIA write registers struct ATARI_GTIA_WRITE * const GTIA = 0xd000; The compiler recognizes that GTIA->GRACTL is in fact a static address and generates code poking directly to that. The struct-based approach was primarily chosen because I prefer the registers of each chip grouped together and I like that is is clear that code is addressing a register a specific chip. Some editors also offer code completion after you have entered GTIA-> which helps find the register you are looking for. The struct in the header-file also serves as a place to dump a little documentation describing each register. See https://gitlab.com/camelot/kickc/-/blob/master/src/main/kc/include/atari-gtia.h If you prefer a different notation it is pretty easy to create another header-file supporting that.
  4. Thank you @fenrock ! I will be merging your conio.c implementation into KickC master, and it will be included in the next release.
  5. @fenrock These are the 2 files you need: https://gitlab.com/camelot/kickc/-/blob/master/src/main/fragment/mos6502-common/_deref_pwuc1=vbuaa.asm https://gitlab.com/camelot/kickc/-/blob/master/src/main/fragment/mos6502-common/_deref_pwuc1=_word_vbuaa.asm
  6. @fenrock You probably want something like the following code then. Notice that SAVMSC is now a pointer to a pointer (char**). char * const ROWCRS = 0x54; // Row on the screen that the cursor is currently on word * const COLCRS = 0x55; // Column that the cursor is on, ranging from 0 to 319. char ** const SAVMSC = 0x58; // The lowest address of the screen memory, corresponding to the upper left corner of the screen void main() { char* cursor = *SAVMSC + (word)*ROWCRS*40 + *COLCRS; *cursor = 'x'; }
  7. @fenrock You have found a bug! It affects address-of, when used on some expressions. This forced the compiler has to create an anonymous variable to hold the value to be able to get a pointer - and this then fails for some expressions. I will make a fix ASAP https://gitlab.com/camelot/kickc/-/issues/536 You are welcome to continue posting here. You can also report any problems directly into the KickC issue tracker if you prefer that. In the meantime the following works because w3 is now a "normal" named variable. word w3 = *SAVMSC + (word)(*ROWCRS)*40 + *COLCRS; word *wp3 = &w3;
  8. Hi @fenrock, The (word) should not be needed, however since KickC is missing a fragment you have found a very nice work-around tricking it to use a fragment it already knows. If you add the following file to the /fragment/mos6502-common/ folder of KickC the code will compile and work without the (word) cast. The fragment in question handles the case word z1, z2, *c1; *z1=*c1+z2; where z1 and z2 are located on zeropage and c1 is a constant. https://gitlab.com/camelot/kickc/-/blob/master/src/main/fragment/mos6502-common/vwum1=_deref_pwuc1_plus_vwum2.asm The last compile-phase in KickcC generates ASM code based on small ASM fragment files matching simple C statements. It almost never fails on 8bit numbers - but is still learning to handle all combinations for 16bit numbers. By the way KickC can create the multiply by 40 code for you. So the following also works, and generates code that is very similar to your mul40(): word screenAddress1 = currentTop + (word)currentRow*40 + currentCol;
  9. Thank you for the LBL-format description! If you have sed you can convert the VS-file to the LBL-format using the following command: sed 's/al C\:/al 00/' helloxl.vs > helloxl.lbl I may have a look at offering the conversion directly in the C-compiler as a command-line option.
  10. You can achieve this by reserving the zero-pages you do not want the compiler to use. To start at 0x80 add the following pragma #pragma zp_reserve(0x00..0x7f)
  11. The choice to use screencodes as default charset encoding was made to align with the other platforms supported by the compiler (such as C64) and because the current KickC atari 8bit library focuses on the chipset of the atari and does not have any ROM wrappers. If you prefer ATASCII as the default charset you can achieve this pretty easily. Simply change the "encoding" setting in the /target/atarixl.tgt file in your KickC installation, or create a new platform target by making a copy of the tgt-file and changing the settings in that copy. After this you can compile to the platform you have configured using the -t xxx commandline option or the #pragma target(xxx) where xxx is the name of your tgt-file.
  12. The underlying assembler i KickAssembler. As @Wrathchild writes KickAssembler can produce a .vs symbol file for the VICE emulator if you pass it the –vicesymbols option. I don't know Altirra well enough to know the format it expects, but the VICE symbol file is in a pretty simple format that would be easy to modify using a script. I will be adding a command-line option to KickC that passes -vicesymbols on to KickAssembler (if you use -a to assemble or -e to assemble and run an emulator). In the meantime you can choose to call KickAssembler manually. As an interesting aside. The VICE symbols file primarily contains symbols (variables / labels in the code) but it can also contain breakpoints. If you want to place a breakpoint in your KickC-code that will be output into the VICE symbol file this is currently possible using kickasm {{ .break }}
  13. It seems I have missed handling the case when comparing two boolean constants! That is an oversight on my part. I have fixed them problem, and the fix will include it in the next release. https://gitlab.com/camelot/kickc/-/issues/527 In the meantime, if you want a pre-release version please let me know. Then I will help you get one. Thank you for reporting the problems you encounter!
  14. @Wrathchild You are right! There is a problem with macros where the body starts with a parenthesis in the current version - the compiler erronously believes you are trying to declare a macro with parameters. It has already been fixed and the fix will be in the next version. https://gitlab.com/camelot/kickc/-/issues/518 If you want a pre-release version please let me know. Then I will help you get one.
  15. @fenrock The default encoding on the ATARI XL platform is screencode_atari. I can see you already found the way to select the ATASCII encoding! #pragma encoding(atascii) As you saw in the linked issue there is a problem with the encoding of the newline right now, but it is already fixed and the fix will be in the next release. If you want a pre-release version please let me know. Then I will help you get one.
  • Create New...