Prog8 language and compiler topic

[borgar]

Yes, this is the same error I get.

And I will make sure I include any error messages as well if I should find any other issues in the future ?

[desertfish]

Thank you.

I don't know if you are on github, but if you are, that is maybe a better place to report bugs in prog8. If you're not, just post here

[desertfish]

I've just released a BETA version of the upcoming Prog8 6.5 , this version should be used if you're targeting the new "V39" of the commanderX16.   I'm using it to test my existing programs and write new code already for the upcoming cx16 release.



The final 6.5 release will appear shortly after "V39" is officially released and then I'll add the detailed change list as well.

Programs compiled with it may no longer work on the previous version of the emulator and roms, but I expect everyone that's writing new software to upgrade to "V39" real soon anyway

[dmc6502]

Wow! That sounds facinating! Compiles a prime number generator to 54 bytes. In any other computer that would be 5 megabytes. Once I get back up to speed on 6502, I'll be all over it.

[desertfish]

Not sure where you get the number 54 from, the primes.p8 example compiles to 923 bytes with the current version of the compiler ?   



Anyway I hope you can have some fun with prog8 and find it useful

[borgar]

I've uploaded my first version of the Petaxian game now (very much inspired by C64 Galaga). It's no where near a complete game, but it's sort of playable.

As expected in this thread it's written in Prog8 which has certainly allowed me to make this a lot faster than trying to re-learn 6502 machine language (last used in 1987 when I upgraded from C64 to an Amiga 500). Though I'm a bit tempted to look closer at assembly to see if I can speed this up enough to get it to run smoothly on C64. It can be compiled and run on C64 as well but it slows down when there are a lot of moving "bits" on screen at once.

[desertfish]

By all means look at the generated assembly code: Some things that prog8 generates are *ahem* very inefficient when compared to had written asm.   I suggest finding a few very frequently called short routines in your code and only try tor replace those with %asm  {{..}}

I'm fairly certain you only have to do this on a few places to make it run fine on the C64 as well, it already ran pretty good as it is!

It can also help to split up long one-line expressions into several steps, sometimes even using temporary variables or one of the 'virtual registers' cx16.r0..r15 ,  this sometimes avoids prog8 generating slow stack-based evaluation code

[borgar]

Thanks for the hints. I have already taken a peak at the asm output for what I think is the revelant sub and there might very well be a few things that might be possible to optimize.

But since there are no problems getting it to run on the cx16 I think I'll focus on getting a bit more of the main functionallity completed before I concentrate on C64 speed.

 

[borgar]

I've uploaded a new version of Petaxian making it a bit more like a proper game. Now loop over 8 stages, 3 different enemy types (requiring different 1 to 3 hits to kill). And some simple sound effects. I basically just copied the X16 sound code from Tehtriz.

[borgar]

I've written a couple of assembly routines as a test and this seem to work fine. However, I was wondering how to use "temp" variables in the asmsub. I.e. I could not just add

  ubyte tmpvar

in the module file and then have the asmsub use this e.g. with

  sta testvar

I figured out that this is because the compiler removes the variable since it's unused in the actual prog8 code. Is there a way to indicate that a variable is in use in a asmsub?

BTW, I used P8ZP_SCRATCH_REG since I found that in the asmsub's in textelite.p8.