Commander X16

On 10/7/2022 at 11:33 PM, arkorott said:

Might I be doing something wrong?

Pls disregard...not clear why yet but had to add:

%zeropage basicsafe

As I saw in other examples...Need to check more sample code

I'm glad you figured it out!

 

(an alternative might be to add an endless repeat loop at the end of your program, to keep it from rebooting the machine)

Understood. Thank you!

Will try it out more. Super intrigued. Always start coding new languages just by checking a few examples briefly ?

Time to read the docs more thoroughly

By the way. There is no specific prog8 discord but there is a prog8 channel in the x16 discord server. 

Thanks! Will check it out

Hi, I'm new around here, but I want to dive in to programming for the X16 using the emulator.

I program in C++ for my job, and am familiar with a lot of modern and old languages and some microcontroller stuff like Propeller 1 & 2, and their languages.

I've scanned through this thread, and I think I want to try using Prog8 for my retro game for the X16. What I am posting for is to ask if there are any gotchas or things I should be aware of like maybe X16 features that are not fully support (if at all), or just common things newcomers to the language stumble on?



It seems like you've done a pretty nice bit of work on the X16 target/support, so I expect I will like using Prog8 for my game. Thanks for doing this, and for any reply to my question above.

 

On 10/19/2022 at 6:52 AM, Roy Eltham said:

Hi, I'm new around here, but I want to dive in to programming for the X16 using the emulator.

I program in C++ for my job, and am familiar with a lot of modern and old languages and some microcontroller stuff like Propeller 1 & 2, and their languages.



I've scanned through this thread, and I think I want to try using Prog8 for my retro game for the X16. What I am posting for is to ask if there are any gotchas or things I should be aware of like maybe X16 features that are not fully support (if at all), or just common things newcomers to the language stumble on?



It seems like you've done a pretty nice bit of work on the X16 target/support, so I expect I will like using Prog8 for my game. Thanks for doing this, and for any reply to my question above.

Welcome to forum and to the Prog8 thread.

The main issue with the low level code is that it's a lot easier to shoot oneself in the foot. I.e. nothing preventing you from setting a random memory location and breaking everything. Expect to spend time looking for weird bugs that are hard to pin down. Prog8 is low level so it's more like C than C++. On the other hand, it's a compact and neat language that is easy to learn. Especially if you know anything about the 6502 processor.

It's easy to add in some function implemented in assembly if you need to speed up some critical parts which may be needed if you are coding a game. I you want to look at longer code example feel free to check out the source of my game Petaxian, which is written in Prog8 plus a bit of assembly : https://github.com/cyborgar/Petaxian. Feel free to steal.. I mean borrow from there. There are certainly parts here that was "inspired" by the example programs from desertfish in the first place.

Most gotchas are probably just related to the the CX16 platform and not so much about Prog8 though I have a couple things I will mention

First Prog8 currently doesn't support short-circuit evaluation, i.e. for something like

 if x >1 and x < 128 { ...

all parts of the express is evaluated even if the first fails. Using something like

  if x > 1 {

    if x < 128 {

      ...

may yield faster code. And if you have side effects in the evaluations you could even get bugs if you are to careful.

Sometimes the compiler also struggle with more complex expression (though complex has more to do with the compiler evaluation than the complexity of the statment). E.g. right now something like this

  test_fun( arr_one[i + 1], arr_two[i + 1] )

will give a compiler error ("it's not possible to use more than one complex array indexing expression in a single statement; break it up via a temporary variable for instance").

In that case I extracted out the array index calculation to

  ubyte tmp = i+1

  test_fun( arr_one[tmp], arr_two[tmp] )

Often if you run into trouble with the compiler, breaking operation down into simpler steps tend to solve issues.

And also, reporting issues here will usually get you help quickly from the Prog8 developer himself ?

borgar,

Thank you, this is exactly the kinds of things I was interested in learning about.

I am familiar with the 6502 (almost all of my early coding was on the VIC-20, C64, and C128).

I also understand the low level aspects, and mostly bare metal type programming where a mistyped address or value can break everything.



Anyway, thank you very much for the tips and I will be around here posting as I go with any issues I run into or progress update.

A little heads up for users of the rnd() and/or rndw() builtin functions.

The next release of the compiler will have some changes and improvements to the random number generation routines. For example, a way to seed the RNG's will be added. 

But also for consistency sake, it looks like I will be removing the rnd() and rndw() builtin functions and instead move them into the math module as regular functions.  This will break programs that use the builtins now, but is easily fixed by importing the math module and calling them as math.rnd() / math.rndw() instead..

 

Been doing a little dabbling in prog8. Implemented a few sprite functions, and made a little test program that looks like this.



Source can be found here:

https://gist.github.com/reltham/cb607cb91eae8bc8a7a1609e791fe6ea

Using X16EMU R41.  The birdsprites.bin file is attached, and should be place into your sdcard.img and passed into the emulator.

Thanks to @desertfish for the help in Discord.
BIRDSPRITES.BIN