Commander X16

Ok I think I know what the most important problems are. (based on the code I see in the zip file)

The string arrays that contain the names and scores, are in fact just uword arrays containing pointers to the strings. I think you figured that out.
A problem is that all strings are allocated in memory statically so you cannot strcopy a larger string over a shorter one without clobbering all over the data that comes after it. All your name and scores strings must be defined as long as the maximum length they can take!

The second problem is that the "shift down" logic leaves the arrays with a duplicate pointer. So if you then copy a new name and score into the strings that this pointer points to, the resulting table suddenly has TWO entries of the same name + score (pointing to the same string in memory).

Look here is the table before and after inserting a score of 7500 (and WITHOUT stringcopying the new name+score): May I suggest the following:
- make all names and scores the maximum size "buffer" they can be so no memory overwriting can take place.
- do not shift the string pointers around in both name and score arrays
- instead copy the strings themselves into the next string "buffer" of the next highscore entry.
- and then you can safely overwrite the correct line with the new name + score. No duplicates.
- (perhaps: just store the score as uword instead of string?)

(This is what I did for the highscore table in Rock Runners)

desertfish wrote: ↑Mon Jul 10, 2023 8:33 pm
May I suggest the following:
- make all names and scores the maximum size "buffer" they can be so no memory overwriting can take place.
- do not shift the string pointers around in both name and score arrays
- instead copy the strings themselves into the next string "buffer" of the next highscore entry.
- and then you can safely overwrite the correct line with the new name + score. No duplicates.
- (perhaps: just store the score as uword instead of string?)

(This is what I did for the highscore table in Rock Runners)

So just use string.copy, not string = string2? Okay

'maximum size "buffer". I'm not sure I'm parsing that correctly, isn't that what I'm doing, when I declare my string arrays and initialize them to 5 and 3 characters....which is the max size I expect....although for the names, I haven't restricted it yet...
Score is a uword, so, never more that 5 characters....and it's 'impossible' for anyone to score more than 65535 points in this game!

I've been testing different coding enviroments (cc65, KickC etc) and this really looks like a good solution.....but

I compiled the hello world, runs fine..then re-arragned the code some to my prefs, ie brackets same line and it won't compile.

by design?

I can work with it, but just wasn't expecting line spacing to be an issue.

Hi and thanks for your interest in Prog8!

You're right, it is by design that the '{' must be at the end of the current line and cannot be placed on the next line.

However, in the new 9.1 version of the compiler this is no longer the case! Using this version you will be able to compile your program as printed above!

Prog8 version 9.1 has been released : https://github.com/irmen/prog8/releases/tag/v9.1

Please read the release notes as there are a few very important changes in this version.

Nice release, don't know if you added that for me or we had the same idea of the "{" spacing.
Hands down Prog8 has been the best coding experience for the cx16 so far

still learning the syntax, so this may be stupid.
I have a pointer to memory (ftable), and trying to get the uword value into a var (size)
I increase ftable += 2 for for each value, don't need dynmaic access like an array

This works, but checking if i'm missing some of that "syntactic sugar" also your vaddr function only works for 1 offset +/-, where I needed 2
not a big deal, just copy and paste and adjust (below is my change for 2)
maybe a version with offsets would be useful

*my changes are the ora #%00100000 and ora #%00101000

Just use
size = peekw(ftable)

Interesting thought about the vaddr routine. I've not used it much myself, mostly when optimizing things it's better to just start writing the Vera registers yourself to specialize for your particular situation. But perhaps there's a way to easily allow specifying the increment/decrement size.

I've added cx16.vaddr_autoincr() and cx16.vaddr_autodecr() where you can pass any supported increment/decrement value in r2.

I really have no idea what the burdens of maintaining this language are.

Almost all of my algorithms end up depending on array syntax. It's been
awhile since I've messed with Pointers. If you implemented a HUGE. array data type
(say at least 1024 or 2048 elements possible) I would probably be working on this
language instead of relearning C. Even though I haven't written any Prog8
code yet I've been perusing a lot of it. and following the discussion's with great interest.

If such an array is meant to contain just bytes, you can more or less already do that in Prog8:
You can use array indexing syntax on a memory pointer variable (uword), and in that case, the index can be a word in size.

For example:
uword bigassarray_ptr = memory("bigass", 3000, 0) bigassarray_ptr[2000] = 99 txt.print_ub(bigassarray_ptr[2000]) ; 99.