Commander X16

Just not related to prog8 but to Elite. You may want to lookup how the 256 planets worked in Elite. (check the source code I linked) It has a very good writeup how that works.

In short:

You have a pseudo random generator that is seeded by the galaxy seed (4 bytes). This seed is then taken through iterative random numbers to allways generate the same parameters for a specific planet. 

So if you feed in 240 into this generator (System Number), it will allways get the same result back to you, which is then feeded into the the System generator and gets you the name and the description. All of that is also generated and not stored anywhere. 

The marked prices are as well generated but also only varried with a random difference. 

/Edit: ah forgot the galaxies ... So if you jump the galaxy. the 4 bytes above will be all rotated left by 1 bit. That results into a different seed for each galaxy and will also return back to 1 for if you jump through 8 galaxies back to the first one. 

@SerErris thanks for the insights it will help to unravel the source code from text elite http://www.iancgbell.clara.net/elite/text/

I have started to clean that up and have encountered these various mechanisms and with your tips they are now more clear to me how they work and why some things are done in the code like they are ?

The whole procedureal generation is the real secret sauce in Elite ... besides the unparalleled graphics of that time.

Also need to correct - the Seed is 6 bytes = 3 words. 

Start reading here:

Sub TT20 and Sub TT54 gives you more or less the whole picture.

TT24 is then calculating the real system data.

Everything comes together than with the tokenized text routines (which is a masterpiece in itself). That will put out the information based on the system data. None of the strings you see on screen can be found anywhere in the code. They are also generated.

That code and description can be found in QQ18.

https://raw.githubusercontent.com/markmoxon/elite-beebasm/master/sources/elite-source.asm

But now enough on that here... it is confusing the original post with non relevant data.

 

On 8/27/2020 at 4:30 PM, desertfish said:

One improvement I'm already thinking of, is perhaps making the set of 16-bit pseudo registers part of the language so you don't have to access them anymore as zeropage variables.

That is a great idea and one of the things that should be used and abused!

On 8/31/2020 at 5:52 PM, desertfish said:

It would be cool if people would use Prog8 for larger projects, but other than the few dozen example programs I've not actually written a large piece of software in Prog8 yet ?    Mostly because I'm still too busy tinkering with the compiler itself and fixing bugs, and now, CommanderX16 support for it.

I have been thinking about NOT starting yet another 6502 BASIC compiler but instead HELP out with Prog8! Gives me a reason to learn yet another programming language (actually two... Kotlin and Prog8). After Googling Kotlin I read that it drastically reduces boilerplate code which was the big reason why I kept Java away from me with a ten-foot pole! I hope to be able to sift through your code without getting bamboozled...

That's a bold decision but I really appreciate your interest in helping me with Prog8 !   Any sort of help is welcome.  Documentation improvements, actual compiler code, example programs, usage suggestions, whatever ?

About Prog8 if you want to get a hang of how the compiler works don't hesitate to ask me stuff about it, it's a test for me too to see if the code is understandable for others (It should be, if it's not , it has to be improved).  I strongly suggest ignoring the  optimizer folder altogether for a while.   Maybe start with familiarizing yourself with the classes that make up the AST (see the ast folder)  because almost everything else uses that?

About Kotlin: it's WAY nicer than the Java I remember from the past and which I'm avoiding strongly, as you do.  (although Java has had some important improvements since)  Kotlin's overtaking Python for me as a favorite programming language, to be honest.  You can notice that Kotlin is inspiredby Python and the "feel" is somewhat similar.    I needed a fast, good solid language and IDE to support the scale and the dozens of large refactorings I was doing in   the Prog8 project and Kotlin + IntelliJ IDEA fit the bill nicely.

 

About the 16 pseudo registers:  Well, they're not (yet) first class citizens in the Prog8 language. However, because Prog8 allows you to define memory-mapped variables they're pretty close to what I wanted anyway. Youc an already simply write :

cx16.r0 = 32
cx16.r1 = 10
cx16.r2 = 256
cx16.r3 = 185
cx16.r4 = 0
cx16.GRAPH_draw_rect(true)

I suppose the "ideal" way to write this is:

cx16.GRAPH_draw_rect(32, 10, 256, 185, 0, true)

but to support that would require quite hefty changes to the parser and those changes don't really blend well I think with the original language as it should work for the C64

7 hours ago, desertfish said:

Maybe start with familiarizing yourself with the classes that make up the AST (see the ast folder)

I think I'll start with the grammar file... just gotta find it.

7 hours ago, desertfish said:

Kotlin + IntelliJ IDEA

I hope it's emacs-friendly (they do have a Kotlin major-mode available). Edit: It is...

7 hours ago, desertfish said:

About the 16 pseudo registers:  Well, they're not (yet) first class citizens in the Prog8 language. However, because Prog8 allows you to define memory-mapped variables they're pretty close to what I wanted anyway.

I was thinking of using them as "use-once and throw away", i.e. used as a mechanism to transfer paramenters to functions, and once in the function routine, the function copies the value into its local static memory reserved for these paramenters. In this manner, the calling program does not need to know the address of the static memory of the paramenters of any function (but needs to know how many parameters and of which type). Passing objects is also possible if used to pass a pointer to the object. Does Prog8 support pointers? 

7 hours ago, desertfish said:

but to support that would require quite hefty changes to the parser and those changes don't really blend well I think with the original language as it should work for the C64

Supporting both the C64 and X16 was a negative point for me. It adds more complexity than is needed especially since they have different design. If we focused just on X16 (or make a fork) things would progress much faster. Trust me, when the X16 comes out, I will never ever touch a C64 again!

12 hours ago, geek504 said:

grammar file

Look for Prog8.g4  -- it's in the parser subproject.  Antlr is used to generate the parser (and we process it into a kotlin based AST later)

12 hours ago, geek504 said:

the calling program does not need to know the address of the static memory of the paramenters of any function

Currently this is "solved" by the code generator that avoids having to copy stuff to intermediary places, the call site directly pokes the required arguments into the static storage of the subroutine's parameters, via appropriate labels in the generated assembly.     Only if the arguments involve evaluating expressions, temporary evaluation stack storage is used before the resulting value is copied into the subroutine's parameters.    See the FunctionCallAsmGen class if you want to study the details of the current implementation.

Maybe the subroutine calling convention can be improved.  The return value is now always processed via the evaluation stack which is not optimal and subroutines cannot be reentrant because they have static allocation of their parameters rather than a new stack frame for each call , but I don't consider the latter a real problem on 6502 machines. Just write a loop instead of recursion.

12 hours ago, geek504 said:

If we focused just on X16 (or make a fork) things would progress much faster

Perhaps - but don't forget that commanderX16 support only arrived a few weeks ago and this project is much much older ?     Also the effort to include a second compilation target forced me to improve various internals of the compiler and fix a heap of bugs as well that I discovered by doing so.   I do agree that a specialized fork  is the only way to fine tune it for CommanderX16 for the short term, but I really would like to see the changes made in the main compiler eventually to support multiple targets.    There's the concept of Compilation Targets and Machine Defintion in the compiler that teach it about the properties of the target machine.

The obvious first thing though that I will do is to create a specialized cx16 branch that can be used for developments focusing on the CX16 !

On 9/30/2020 at 11:07 AM, desertfish said:

Perhaps - but don't forget that commanderX16 support only arrived a few weeks ago and this project is much much older ?

Forgot about this detail!

It might take a while to start digging inside Prog8's source code... I'm getting familiarized with Kotlin and ANTLR while fooling around with IntelliJ IDEA... all new tech to me! Being a hacker at heart, I just *have* to write a small interactive calculator using Kotlin and ANTLR to test my newfound knowledge!

Edit: I am seriously consierding ditching Python and C# for Kotlin. It'll be just C, Kotlin, and Assembly (6502, 68000, x86, and ARM) for me!

PROS: JVM, Java libraries, clean code like C# (a tad cleaner than Python),  I prefer { } instead of indentations, statically typed, Android, better job opportunity in the JAVA field?

CONS: JVM (who wants to be dependent on Oracle?), not well integrated with other technology, i.e. less mature, Kotlin/Native still being developed (iOS!)

Released new version: 4.4

I've just released a new version of Prog8. It contains various improvements and bugfixes that you can read about on the release page in Gitub.  Also quite unexpectedly I've managed to optimize the generated code even further and Prog8 is now actually a little bit faster  in some microbenchmarks than optimized  compiled C from cc65 ?

See the initial post in this thread for download and documentation links.

 

Is it just me or am I alone in having this great aversion to LL grammar, and thus an aversion to using ANTLR?

LALR(1) just makes sense to me and is so elegant especially when using EBNF notation.

After checking out most lexers/parsers it seems to me that Lark is the sweetest thing since apple pie!

But I am still convinced to learn Kotlin ?