"It’s Christmas 1982 Again!" Topic

And under my tree was a shiny new Commodore 64 computer!

Yep, no joke.

Well, technically it's a reproduction of the Commodore 64, but it functions like the originally— only with internal storage, USB ports, and a HDMI port.
Also comes with a nicely done reproduction joystick with 8 buttons.

Set it up immediately, dabbled with a couple of the built-in original games… but my main thing is programming it in BASIC, a joy I haven't had in a long time.
Already working on a brief text adventure game. My BASIC skills are a bit rusty, but I think I'll be in full swing pretty soon.

What fun. My inner 15 year-old geek is ecstatic (okay, I was older when the C64 came out, but my geek heart beats at 15).

So theoretically there's now a wider market for some of my old C64 wargames, right? Red Storm Rising, Battles of Napoleon, etc.?

Only if you can get ‘em on a flash drive, or there's a USB external floppy drive out there that will work with the reproduction.
I'm not at home to examine mine, but I don't think there are any other ports on it (aside from the HDMI to a modern monitor/TV).

What will likely happen is that the company will acquire rights, if they can, and offer the games as a firmware update.

In other news, I just found out they're planning to reproduce the Amiga next year!!!

Here's a link for the C64: retrogames.biz/thec64

I wrote an amortization program for my dad and a marching band drill planner on my C-64 back in the day.

Maybe some nostalgia would make my current mortgages seem less heinous. I suppose I could go to my mom's and get the old C-64 if I wanted to do that.

In related news, my first computer is on display in the Smithsonian Museum of American History. Well, not mine, but the same make/model TRS-80. Mine proper is either in my brother-in-law's garage or in the dump. Possibly someplace at VA Tech on display …

If you want some real Nerdstalgia …

That's the TI Dataman from '77. It was a one year only product that was a calculator with some games and limited memory function. The best thing is I was watching some of my dad's super 8 movies of Christmas that year with my wife and kids after returning from our tour of duty in Japan. When an 8 year old me unwrapped the Dataman, SWMBO pointed at the screen and yelled, "That's Dataman! I had one of those!".

I learned BASIC on a Trash-80! My high school had TRS-80 IIs and IIIs, and a close friend had a Model 1 (which he and his father seriously souped up).
My grandfather had a Commodore 64, and loaned me his VIC-20, which I tried to program a video game for, but alas the whole PEEK and POKE memory map thing was beyond me.
I was the proud owner of a Timex Sinclair with 16k Memory expansion brick!

Mine was a Model 1/Level 2 (the one with the 500 baud rate on the tape).

16K holds a lot of stuff when you only have 16K.

I found the original Commodore 64 User's Manual in PDF, and I've been reading it. Got to the chapter on PEEK and POKE, and I finally understood ‘em. (Surprisingly well-written and readable manual, both clear and detailed, but with a good casual tone.)

Looking forward to "POKE"-ing around in it!

Hard at work on creating a text adventure.

The variable restriction is a bit annoying (limited to two-letter combinations for significance, and can't use the first two letters of any BASIC command word. ) Makes coding confusing, as I have to remind myself how LD$ differs from LS$, and then I'll have to go back through my variable list and confirmed I haven't slipped up and used an abbreviated command code…

BUT, the logic juices are flowing and I've worked out a near-to-true-English parser (imperative sentences only, and I'm cheating in that the parser simply strips out articles, prepositions and adjectives, thus treating them all as identical in meaning. If the user types in a grammatically correct command sequence: "Tie the rope to the gnarly tree," the parser will convert it to: "Tie Rope Tree", but the user won't notice any difference in result or response.
But the user could type "Tie a rope with the gnarly tree" and the result would be treated as correct, even though the sentence doesn't make sense.)
I'd have to check, but I also think a command like "Tie Tree Rope" would produce the same effect as "Tie Rope Tree." (What I've set up as code is a bit hard to recall off the top of my head.)
As a quirk, "Glue the rope to the tree with the paste" would produce the same result as "Tie the rope to the tree," as the parser treats all "attaching" verbs as identical, and ignores anything after the second noun entered.
So you could type some funky things in and have the game treat them as valid responses with off-kilter results compared to what was literally commanded, but I figure most players will follow the logical patterns expected and never know or notice the difference.
I've got to make adjustments for 64K after all!

But it's fun to be doing and thinking about- and it proves after all these years that when it comes to BASIC programming, I've still got it!

CRIVENS!

Apparently, Commodore 64 BASIC can't compare string variables!
It can compare a variable to a string— IF A$="Yes" THEN…— is valid code. But IF A$=B$ THEN… is not.
So in order to check whether the player has entered a valid command in my text adventure game I can't loop through the list of valid commands with a simple comparison of variables on a single line of code, as IF FIRSTWORD$ = WORD$(X) THEN… …NEXT X.
No, I've got to enter each comparison as a separate line of check code for every single verb and noun in the game.
IF FIRSTWORD$ = "Go" THEN…
IF FIRSTWORD$ = "Take" THEN…
And on and on and on.

Fortunately, I can still use most of my subroutines which operate not on the actual string but with a numeric variable array tied to an ordinal numbering of the words ("Go" = 1, "Take" = 2, etc.) but that initial check for validity is going to be tedious to code, not to mention a memory hog.

Maybe I'm missing something?

*facepalm*
Ignore the rant. C64 BASIC compares string variables just fine. Looks like I must have entered a two-letter variable combination that was a BASIC reserved word, or committed some other syntax or type mismatch faux pas.
"Baaaaaa. I feel sheepish."— Genie

So after a couple of days of pointless frustration due to my own incompetence, I'm back on track…

I'm pretty sure my lowly ZX81 allowed multi character variables!

Commodore Basic "allows" multiple character variables, but ignores everything after the first two characters. So HEYSAILOR and HENPECK would be treated as the same variable, as the system only "sees" HE as the variable name. Also, due to the limited memory, it's the best practice to restrict variables to two characters, as even if the extra bits are ignored, they still take up program memory.

As such, by my calculations there are 631 potential variables (allotting for the reserved words that can't be used). So sufficient room to mess about, though it's a pain trying to remember what the heck "IA" is supposed to stand for while I program (I do have notes, but still…).

,,,and I just slammed into the 64K memory limit, the curse of a text-heavy BASIC program. Darn it.

I recall years ago on the TRS-80 putting all the text data in a separate file (i think just DATA statements) and then loading from that file to the variables when the game began. The game program itself manipulated the variables but didn't directly contain their text.
For that to work, though, I think I'd have to only load portions of the text as needed— might work to put my "rooms" into chunks based on "entry points"— hit the entry point, and the program stops to load the next section, then clears it when you leave that section.
Lots of work to do, and I haven't even coded the command routines…

Addendum: Reading a bit, I think I can "daisy chain" the game into multiple programs which pass the variables along while clearing the program itself from memory. If I'm understanding it correctly, I can have a Loader program (as it were) to establish all the variables and then give them content, which then calls a Game program, effectively erasing the Loader program from memory but passing along the variables (and their content) to the Game program, which then handles receiving player instructions and manipulating the variables. Thus, only the Game program would be in RAM, along with the variables and their content, rather than having the full listing of the data in RAM concurrently with the variables containing the same information— in the latter case essentially doubling up the RAM usage on the exact same things.
Work to do, work to do…

Daisy chaining it is!
I've got a short title page and instruction program, which then loads the data loading program (with less than 2K to spare!, hence the separate instruction program), which (will) in turn load the main game (the part that interprets instructions and carries them out).
Right now, that part is solely on paper.

Code, code, code…