RETROTrek - Early Development Thread

[TomXP411]

2 hours ago, Starsickle said:

Ah, thank you. That solves that. That will enable some greater control over things.



Hmm...As a quick aside - would you say this is a good reference?

https://www.c64-wiki.com/wiki/C64-Commands



It seems that I've run into a few hiccups and mistakes having followed it in the last few days. If there is a better reference out there, feel free to throw some my way.



Can you expand on that? I've seen RND(), but you're saying there's some seeding based detail surrounding this one? I was just planning on calling it each time I needed a new number.



Traveller, eh? I might have to look that one up. I might have heard of it in passing. Always up for good ideas.

Yes, that's a good reference. Use that in conjunction with the Programmer's Reference Guide that comes with the emulator, since some new commands have been introduced into the language.

are you new to BASIC, or just to the Commodore flavor?

 

[rje]

RND() is something I learned only in the last several years.  And... it's well documented in the C64 wiki you quoted (yeah, I think that's a good reference!).

A negative number seeds the PRNG.  A positive number returns the next random number.  And a zero... just doesn't work well.

So you want to seed it with TI, the system timestamp.  So, negative TI.  But, you want a human element to effectively randomize WHEN that seeding happens... hence "press any key to continue".  I note that this also works really well:

...
INPUT "YOUR NAME"; NA$
R=RND(-TI)
...
	

...that way, you've also gathered info by which to record his score for the leaderboard...

 

[Starsickle]

11 hours ago, TomXP411 said:

Yes, that's a good reference. Use that in conjunction with the Programmer's Reference Guide that comes with the emulator, since some new commands have been introduced into the language.



are you new to BASIC, or just to the Commodore flavor?



 

Just to Commodore - I can't say opening up the manual when I was about 9 was legitimate programming experience. =P It's been about 28 years since I've touched the keywords POKE and PEEK. I've been tinkering with SMILEBasic4 after it came out (it's fun!) and I have some experience with VB/VBA, but VB is high level compared to C64. I deal mostly in High level languages. You won't see me doing assembly. I C'd my way through that course.

Slowly but surely I'll get it all figured out. This morning I just finished the message queue, but with a funny quirk - because the dimensioned array is filled with lines of nothing, a nothing gets shifted at the boundary the first time anything is added to it, resulting in a single gap. The queue otherwise works fine, though, and is ready to be integrated into the game's Report-spam window. I can fix that later.

Quote

 



RND() is something I learned only in the last several years.  And... it's well documented in the C64 wiki you quoted (yeah, I think that's a good reference!).



A negative number seeds the PRNG.  A positive number returns the next random number.  And a zero... just doesn't work well.



So you want to seed it with TI, the system timestamp.  So, negative TI.  But, you want a human element to effectively randomize WHEN that seeding happens... hence "press any key to continue".  I note that this also works really well:



 

Oohhh, I see what you're talking about. You have to seed system before pulling from RND and that requires the -TI, which is the system's current time. Not sure why I was confused, now. Lack of sleep and coffee.

[rje]

Quote

You won't see me doing assembly. I C'd my way through that course.

I got a C in 8086 assembly (it was a four credit course!  ouch!), a million years ago, but that doesn't stop me from writing assembly when I think I can get away with it.  6502 is easier anyway.  For me though it's a matter of necessity: I won't write it unless I have significant runtime delays I need to seriously reduce.  Or if I can do something useful in 256 bytes or less.

And I do work high level in my real job.  As in, React, and Java.  And I write Perl for fun.  Actually, I wrote Perl utilities to get around the limitations of BASIC 2.0... including a filter that lets me code with labels, no line numbers, and combines multiple source files (all of which is EXTREMELY helpful), and even a thing that simulates simple data structures (I don't use the latter -- it's really hacky).

 

[Starsickle]

22 hours ago, rje said:

And I do work high level in my real job.  As in, React, and Java.  And I write Perl for fun.  Actually, I wrote Perl utilities to get around the limitations of BASIC 2.0... including a filter that lets me code with labels, no line numbers, and combines multiple source files (all of which is EXTREMELY helpful), and even a thing that simulates simple data structures (I don't use the latter -- it's really hacky).

I would find that ability very useful, as I like to create parts and pieces and then assemble them. With organizing and convention, you can make larger and larger things more quickly.

[rje]

On 9/6/2020 at 5:39 PM, Starsickle said:

I would find that ability very useful, as I like to create parts and pieces and then assemble them. With organizing and convention, you can make larger and larger things more quickly.

And the two-letter variable limitation really causes a problem for long BASIC programs, when I start to lose track of my variables, because I don't have a separate document with a dictionary of variables I'm using and where they're used, etc.

[Starsickle]

Been taking it easy last day or so. Discovered a strange problem with the message queue, where the last line will force the top screen lines to be drawn at the bottom and render the game unresponsive. Definitely a baddie, but likely caused by a logical problem when PRINT and LOCATE are used before the next loop at the last queue line. The queue functioned fine before, so it must be something elsewhere. Will track it down and smash it.

There is another bug with game start repeating Self-Destruct Entry Code, ut this is related to the program segments in lines being disorganized. It's time for some code cleanup.

Otherwise - with the Mission start and game over screens complete, I though I'd implement the "PRESS ANY KEY" as advised, but I've found that...it doesn't work. It just goes right through.

I've tinkered with pic below and a few guides on GET just to see if I'm not using it correctly, but code below seems to be on mark with what I was told would work.

10 PRINT "TESTING ANY KEY TO CONTINUE!"
11 A$ = "A"
20 GET A$: PRINT "YOU TYPED: "A$
21 IF A$="" THEN 40
30 PRINT "NO NO NO STOP" : STOP
40 PRINT "CONTINUING" : END

As a note: I've tried this by initializing A$ to "", "1", ""0", and "A". I've looked around the site for comparable code to see what I might be doing wrong, but have not yet found a piece to draw from. I don't want to post problems like this in programming help, as it's not clear if it's something with the emulator, something with the way I'm using it, or something else. I just wanna let everyone know I am looking things up and tinkering before posting here with a programming-related issue. I figure I'll find an answer by asking faster than staring at things that are 40 years old.

[Starsickle]

3 minutes ago, rje said:

And the two-letter variable limitation really causes a problem for long BASIC programs, when I start to lose track of my variables, because I don't have a separate document with a dictionary of variables I'm using and where they're used, etc.

Absolutely - it's one of the most annoying and infuriating parts of designing a C64 program to me so far. If this could be overcome, being able to use meaningful names would be a godsend. Sadly, I'm not sure how absolutely committed the interpreter for BASIC 2.0 on this new platform has to be to the hardware that AB$ is the same as ABC$

[rje]

25 minutes ago, Starsickle said:

Absolutely - it's one of the most annoying and infuriating parts of designing a C64 program to me so far. If this could be overcome, being able to use meaningful names would be a godsend. Sadly, I'm not sure how absolutely committed the interpreter for BASIC 2.0 on this new platform has to be to the hardware that AB$ is the same as ABC$

It's committed to Commodore BASIC, forked and modified from version 2.0.  

It can have many improvements, such as better garbage collection (stolen from BASIC 4.0).  Michael's already added drawing commands, a feature-rich set of "DOS" commands, and prefixes for hexadecimal($dc) and binary numbers(%11011100).   It can have a MOD infix (needed!).  It could conceivably have improvements from Simon's BASIC, or from Compute! magazine's SuperBASIC, or any number of alterations of Commodore BASIC.  Heck, maybe it could even have native integer operations. But unless someone is going to dive into the interpreter and modify it for long variables, I doubt it's going to have that. Same goes for some modern control flow syntax.

 

A tool could potentially help here too.  I've thought about this one: my raw listing could have long variable names mapped to valid, short ones.  The easiest way to do that would to have actual data dictionary entries that looked like this in the raw source:

var mylongvarname$ ml$

Every time the translator would find one of these, it would check its hashtable to make sure the long variable and short variable aren't already declared -- and would die if they were.  Otherwise, it would create new entries, and replace the long variable name with the short one in the transpiled BASIC.

This would force me, ahead of time, to declare the variable mapping, and force me to change the mapping when there's a collision.

Hmmm.  The more I think about it, the more I like it.

[Starsickle]

7 minutes ago, rje said:

It's committed to Commodore BASIC, forked and modified from version 2.0.  



It can have many improvements, such as better garbage collection (stolen from BASIC 4.0), and drawing commands, and a feature-rich set of "DOS" commands.   It could conceivably have improvements from Simon's BASIC, or from Compute! magazine's SuperBASIC, or any number of alterations of Commodore BASIC.  But unless someone is going to dive into the interpreter and modify it for long variables, I doubt it's going to have that.



A tool could potentially help here too.  I've thought about this one: my raw listing could have long variable names mapped to valid, short ones.  The easiest way to do that would to have actual data dictionary entries that looked like this in the raw source:

var mylongvarname$ ml$

Every time the translator would find one of these, it would check its hashtable to make sure the long variable and short variable aren't already declared -- and would die if they were.  Otherwise, it would create new entries, and replace the long variable name with the short one in the transpiled BASIC.



This would force me, ahead of time, to declare the variable mapping, and force me to change the mapping when there's a collision.



Hmmm.  The more I think about it, the more I like it.

That's encouraging to hear! Perhaps put this in Issues or feature requests? The good news is not everything in software is monolithic and set in stone.