Jump to content

Jesper Gravgaard

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

14 Good

Recent Profile Visitors

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

    That looks really smooth! It also looks like the beginning of an interesting game.
  1. Version 1.0.0

    17 downloads

    An attempt at creating the classic raster bar effect for the CX16. This is implemented by timing the delay between changing border color exactly right to change the color on each line (in the r38 emulator). The timing may be off on the real hardware - depending on whether the emulator is exact. The source code is written in KickC, and included as an example when you download the compiler. https://gitlab.com/camelot/kickc/-/releases
  2. Rasterbars View File An attempt at creating the classic raster bar effect for the CX16. This is implemented by timing the delay between changing border color exactly right to change the color on each line (in the r38 emulator). The timing may be off on the real hardware - depending on whether the emulator is exact. The source code is written in KickC, and included as an example when you download the compiler. https://gitlab.com/camelot/kickc/-/releases Submitter Jesper Gravgaard Submitted 01/20/21 Category Demos  
  3. There is no direct support (like a keyword) for this at the moment. However, it can be achieved, with a little linker trick. By creating a linker specification that declares a segment that is not included in the generated binary file then we can use the main() function to call all the ROM functions - but ensure that the main function itself is not included in the binary. I have created an example C-file and linker configuration file that creates a ROM at $F000 with three functions. The example also shows how to pass parameters and return values in three different ways: - through the stack - through zeropage - through registers (and/or zeropage) You can see the code here: https://gitlab.com/camelot/kickc/-/tree/master/src/test/kc/examples/rom Let me know if this makes sense, or if it leads to new questions.
  4. I am glad you got everything to compile! How ASM and C works together can still use some work - both improvements of the features allowing for for inlining ASM easily and the documentation of how you use it. I believe that is a good starting point! If they are common enough to be easily portable to the other commodore platforms maybe they should be called cbmopen, cbmgetc, ...
  5. I have tried to create a minimal example re-creating your problem - but it seems my programs cannot reproduce your problem. The following is my C-program __address($02) word R0; void main() { char* buffer = 0x0400; R0 = (word) buffer; asm { sta (R0),y } } And this is the resulting ASM of the main function, when compiling with version 0.8.5: main: { .label buffer = $400 lda #<buffer sta.z R0 lda #>buffer sta.z R0+1 sta (R0),y rts } I believe this is what you wanted to see. Could you show a little more of your code (or share the entire file). Then I will look into the problem you are facing. /Jesper
  6. The documentation is a work in progress. I am working on getting it up-to-date with the features that have been added. That sounds like a very useful tool! It would be great if you create some of the libraries that are missing for KickC. If they can be useful for others I will gladly merge it into my repository and include them in future releases.
  7. @kktos Thank you for the kind words and the feedback. If you have more feedback or suggestions please let me know. Here are my short answers to your points I agree with you! In the start the language has more ASM-features mixed in - but over time the compiler has gradually been improved and moved close and closer the standard C. I believe it is important to have the feature of addressing individual bytes - and the current solution is not very readable when used on 16bit or 32bit data. Also as you point out it confuses IDEs. So I want to find a different solution along the line of your proposals. My TODO is here: https://gitlab.com/camelot/kickc/-/issues/221 That would be a fine way to add support for floats. I have added a description here https://gitlab.com/camelot/kickc/-/issues/619 There is a bunch of stuff in the pipeline, so for now it will be put into the pile of ideas. There are keywords for changing the calling convention on a single function. Currently there are two supported calling conventions: - __phicall - passes parameters through shared variables. - __stackcall - passes parameters on the stack. __phicall is the default and allows the optimizer to optimize parameter passing quite a lot. __stackcall works for the test programs I have created - but I have not done very extensive testing. There is also a pragma for changing it in the entire program #pragma calling(__stackcall) I am working on adding the more advanced stuff, like calling conventions, to the documentation. Thank you. It is extremely useful when loading images or generating tables. I have been steadily adding platforms. The last additions have been Atari XL/XE, MEGA65 and CX16. The next ones I am considering are C128, Acorn Electron and PC Engine. I prefer to have the actual hardware myself so I can test that the compiler produces programs that run on the hardware. I do not have an Apple II yet. However, the Apple II would be an obvious addition at some point.
  8. At compile-time you can change the string encoding of your literal strings in two ways. The pragma changes it for all strings following the pragma: #pragma encoding(petscii_mixed) If you just want a single string in petscii then you can use the magic suffix "pm" after your string - which is surprisingly close to your own proposal "abcABC1"pm If you want ASCII instead, then the name is "ascii" and the magic suffix is "as" There is currently no library code offering run-time conversion.
  9. You can restrict the zeropages used through #pragma zp_reserve() However, the compiler avoids 0 and 1 by default - and starts allocating from 2 upwards. So I believe there is something different causing the issue you are seeing. If you would share the program with me I can help find the issue.
  10. You might want to have a look at the example program /examples/kernalload/kernalload.c It loads a file on the C64 using the C64 KERNAL.
  11. If you add a volatile to ret it will not optimize it away. The compiler is not clever enough to recognize that you are modifying it inside the ASM. It might be possible to examine the ASM instructions being applied to variables used inside ASM to detect if they can modify the variable. I will add that as a TODO.
  12. I am afraid there is no basic file I/O functions currently included the library. I do not know the CX16 well enough yet. What type of storage does it support and how does it read/write files?
  13. @TomXP411 "-scale 2" works for me, when I add it to /target/cx16.tgt . Just make sure you do not add it at the end of the command string. This is because the "-prg" option at the end of the string expects the filename of the generated PRG-file to follow immediately after. This is my working emulator-setting "emulator": "x16emu -debug -scale 2 -run -prg", As for printf() you are completely right that it is implemented on top of conio.h. Printf itself calls only cputc and cputs. If you would contribute a conio.h implementation written on top of CHROUT that would be awesome! I will gladly merge it into KickC's CX16 library. I will have to read up a bit more on printf(), cprintf() and best practice on other platforms before deciding exactly how to do the merge. It might be the optimal solution to have some way of specifying which implementation to use. Maybe some #define or a #pragma.
×
×
  • Create New...

Important Information

Please review our Terms of Use