I remember programming something similar on my Commodore 64, only it was the reverse as yours. I had asterisks and such which represented the obstacles (trees), and I used a pair of those lines to represent a skier. The idea was that you were skiing downhill. When you went to the right, it printed \\ when you went to the left, it printed // at the player position so you had all these asterisks and other objects scrolling up, and your ski tracks going through them. I would place the player more near the middle of the screen so you seen the ski tracks where he was scrolling up. There was more freedom to choose where you went as there wasn't ONE path to travel. It was simple to code and fun. You could easily go further with some sprites etc. A good first programming project for anyone learning.
I loved this. I like to write games in basic (something I used to do alot of in the '80's) and now I have a c64maxi and I'm back doing one of my favorite things again writing games. I learned alot from your video and I love this style of gaming using nothing but basic. Thank you very much.
i know this episode is almost a year old, i typed your games into the c128 with the changes and got a score of 629 first try. interesting little game. thanks
Quite similar to a game which my second cousin and I made on his Texas Instruments TI-99 4/a. It was more like him writing it, because his TI-99 was actually my very first introduction to Basic and programming, probably about a year before I got my own 48k Spectrum. Anyway, the game had a very similar look and mechanics, also utilising the Print commands scrolling feature. Although it wasn't a maze, it was solid blocks and 45° triangles, and the asterisk was a small downwards facing car. All of which he had made by changing some of the characters. A feature I know the PET doesn't have. But that was where he lost me, with all those hexa-codes. It took a while before I understood those on my Speccy.
Like to have it get narrower then wider then narrower, so you only have to survive "narrowest" for a period ... and have the narrower / wider be shrinking with each cycle. For that, the number of lines at the same width would be a lot less, to get through several shrinking / widening phases.
I love how comprehensive and thorough your explanations are for each and every line in a program to describe exactly what its purpose and function is. Really well done!
I wrote one game that did something similar, but it was on a different 8-bit machine. Your game is comparable to Stage 3 of 3 of my game, and it was called "N.A.E.R.". Stage 1 drew blocks on the screen that you had to dodge, and Stage 2 drew "Galactic Rifts" you had to fly through. Some of my stages went from start to finish using a FOR/NEXT loop in a single line of code. I explain the logic I used in another one of your videos.
Great video about a really fun basic game. Thanks for making this, both the video and the game. I've just adapted it for C64, next I'm going to re-adapt it for Vic20 (taking into account the reduced screen space) and then even fire up the C128 80 column mode in WinVice and re-adapt it to that too, just for fun. I noticed one thing while I was following your video and editing it for the C64, and that is to do with the score. You use the D variable for the score but since it draws the road 25 times before you get control of the car, this means that you have a score of 25 points before you actually start driving! And since the road is constantly being updated at the bottom of the screen while your car is at the top, this means your score is actually 25 points higher than the actual distance you have travelled in the game. You can check this by manoeuvring your car off the road right at the start... I did this and instead of the distance I had travelled (which was 6 in the case when I tried) it said my score was 31. To edit this, you could of course just deduct 25 points from the score in line 200 before doing the high score check, but instead what I did was set the D variable in line 10 to -24 and updated the check in line 70 to 0. This way the screen still fills with graphics before the game proper starts but starts with your score actually at 0 rather than 25. Because of this "bug" (If you want to call it that) this also means you move from level 1 to 2 prematurely, after you have only driven 25 lines instead of 50, so I also changed the L variable in line 20 to start at -24 as well to compensate and make sure you drive a full 50 lines before narrowing the road width for the first time. I also have a question, is assigning the peek of the car position in line 90 to a variable then doing a check of the variable faster than checking the value by doing a peek directly? What I mean is, could line 90 be rewritten as 90 IFPEEK(S+C)32THEN200 Would this be faster or is it faster the way you have written it, assigning the variable P to it first then checking that variable?
@10:48 Code reviews are awesome! I've found so many problems, optimizations, and simplifications just by trying to explain to someone else what I was doing, that I started pretending to explain my code to someone (in my head).
I never had a C64 growing up - my first computer was an old Atari - but I do remember being fascinated learning to code in BASIC on my first 386. Watching some of the videos on your channel has reignited that interest and the other day I wrote a version of your famous maze program in QB 4.5 in DOSBox. It's nowhere near as elegant as yours but it gets the job done. Since the ASCII codes are completely different than the PETSCII codes I couldn't just use the simple 205.5 trick you do. Also since the slashes are shaped and spaced a little different the output doesn't quite look like your maze does, but that's just something to play around with and see what I can come up with! Anyway, thank you for your videos and reigniting my interest in coding for BASIC...Keep up the great work!
In any of the flavors of BASIC on a PC, you could define a two-character string so the desired characters are adjacent to each other, then use the RND function to select either the first or the second character. I just tested it with the following code - it doesn't look as nice as on a Commodore due to the line spacing, but it works... {CBMBASIC} 10 A$="/\" 20 PRINTMID$(A$,RND(1)*2+1,1);:GETK$:IFK$=""THEN20 {QBASIC / QUICKBASIC} A$ = "/\" WHILE INKEY$ = "" PRINT MID$(A$, RND(1) * 2 + 1, 1); WEND
You know, ever since I've been re-introducing myself to the C64 this year, I've been kind of bugged by MS/CBM BASIC's incredible limitations and slowness (taking often 1000 cycles per statement). Line numbers have been especially frustrating to me, after experimenting with Pascal, C, Unix Shell, Perl, and Python for most of my life (in that order! ;) ... THEN I started learning a little bit of 6502 assembly. Now I'm amazed at every bit of software I see, especially BASIC. I haven't even figured out how to count beyond 255 yet!!! 😅
You make it look so easy. I always thought of myself as a decent C= BASIC coder (back in the day, anyway). This is brilliant -- always learning from you. A fun little anecdote, my mother always shopped at a large Toronto area mall back in the 80s. I used to always make my way to the display C64s at EATONS and Simpsons and quickly type in and run 10 PRINT and always added POKE 808,252 so people couldn't look behind the wizard's curtain. 😂 On a few occasions, an _adult_ would ask how I did that -- felt good as a kid.
Reminds me of what I used to do back when I was a kid, rather than go out and play with freinds I would spend days on end indoors writing games in basic!
Interesting. I wasn't aware of the Print .. SPC(W) command in BASIC (admittedly I haven't used BASIC since about 1986) .. which from the look of it prints a number of spaces as specified by the variable W. I'm a bit fuzzy on how the collision detection test and 'road' narrowing worked .. better go watch the video again. Thanks for the upload mate.
For the collision detection test, in line 90 he was PEEKing directly into screen memory in line 90, looking in the location that the car was about to move into, for any non-space character. As for the road narrowing, that's in line 60. The variable W is used to keep track of how wide the 'road' is (in line 10 he initializes W to 15). The variable L keeps track of how many lines of graphics have been printed. After every 50 rows (L>49), L is reset to 0 and the width of the road is reduced by 1 (W=W-1) to a minimum of 3.
love it...dont' see many pet games on here...reminds me of a ismpler game in grade school that consisted of a magnet, a staple, a piece of paper and a maze drawn out with a pencel. magnet on the bottom of the paper, staple on top and you move the paper to guide the staple through the maze. Low tech days.
Nice job. This is very similar to a program I wrote for the C64. The sides kept closing in until the end of the game. Nice program. Nice how you saved every byte to speed things up. Good job. Please keep up these simple, but informative programs for the young ones to understand programming.
I wonder what we would've thought if someone told us back in the 80s that 40 years into the future, people from all over the world would watch videos where someone codes simple Basic games on a CBM PET... :D Completely awesome. I love this channel.
Last Starfighter! This reminds me of the first program source code I ever saw. Someone in my high school wrote a BASIC program on the TRS-80 Model I that was similar to this but had you flying a spaceship through a meteor storm. Thanks for triggering that memory!
A thought on optimization; instead of using S=32768, C=20, and poke/peek to S+C, set C directly to 32788 and poke/peek directly to C. This avoids a few additions and variable lookups :-)
Hi Robin, I admire your programming skills on the C64. As a kid I was quite deep into Basic, but I never understood assembler. I love to dit down in my "cave", turning on the old machine(s) and programming some stuff, just for fun. I even try some assembler language (and sometimes it even works ;-)). I find your videos about programming very interesting. Keep on your good work!
And yet a 3rd speed optimization (for readability I am adding useless spaces here): 90 J=S+C: If Peek(J)=32 Then PokeJ,42: Next Now get rid of line 100 entirely. I haven't touched CB< BASIC in 35 years but this should be much faster. IIRC, you can speed it all up by using variables instead of numbers like 32 (for space) and 42 (asterisk). I cannot recall for sure if variables are fastest when defined in the first line of the program but I think so.
This is a nice fun little game. One minor point. At the end you update the high score held in variable H but the variable was never intialized. As there was no complaint from BASIC on this machine it was ok but on other machines (and in other programming languages) you should set an initial value rather than assuming it will default to 0.
I begun programming basic back in 1986 on my Commodore 64 and I miss the days when we made things like that ourself. Of course I was programming my ATARI computers in basic until 1998 and even after in emulators. But using an emulator is not always confortable, so I did not do much programming for years now. O.o
If you had included the listing in the description, I could then copy and paste it straight into VICE using the right mouse button. It would take literally a few seconds. You'd need to make the listing all lowercase though otherwise the listing when pasted produces business graphics. Love programming on the PET. Thanks!
This is a nice little program. Thanks for taking me back in time. I didn't know a FOR/NEXT loop ran faster than a GOTO. Maybe that's just on the CBM computers but I wish I had known that back in the 80s when I programmed games in Z-80 BASIC. Just a couple of suggestions to make the program run even faster: Put your setup at the end of the program and use a GOTO to call it from the first line. Many BASIC interpreters scan the entire program, line by line, to find the current execution line. Relegating set up code to the higher line numbers (particularly with complex set up routines) can make the game loop run faster. Rather than putting an IF/THEN/NEXT at line 70 to test for the first 24 lines, run a short FOR/TO/NEXT loop in the setup section (possibly with a different, non-random "race start" pattern?). It uses a bit more memory but saves a few m/sec in the game loop.
CBM BASIC only scans the program line by line for GOTO or GOSUB, and because I'm using the infinite FOR/NEXT for the main game loop, instead of a GOTO, there's no gains to be found by moving the main game loop closer to the top of the program. You're right about the potential speed savings in line 70 though!
I always thought it would be cool if there were fanzines around emulating the old commodore magazines, where you can code the games and play them. It could even adjust to some simple modern code to diversify.
I've been searching for such magazine clips for my CoCo2 and VIC-20. There's lots of stuff on abandonware archives, but they're all in audio format (for cassette) or program files which I have no practical means of transferring to these systems.
Google: “usborne 1980s computer books”. The publisher for these has released the 1980s books as free PDF! These are the books I used back in the day! Also google “The Computer Magazine Archives” at The Internet Archive has they have magazines scanned and uploaded.
This reminds me a lot of the game "Piggy" that you extracted from a vinyl record a few months ago. Great video, I really enjoyed you going through the logic of the program. I'll definitely try it on my C64 and have fun modifying it. ☺ BTW, that old-fashioned green monochrome monitor makes for a nice-looking video.
Good explained. Sir. Very nice. The 4032 was my first computer. I sold it to buy the commodore 64 and floppy 1541. thanks for your content. Keep,up the good work. Stay safe.
I think the lowest possible score there is 25, because it's already D=25 when the car starts moving , might be more accurate to have H=D-25 so you know how many lines the car travelled, rather than how many lines have been printed.
What I admire most about this, is that, by using a computer that for most at first feels simple and odd, It takes quite a lot of time to understand what a program does even being that is written in a "simple to understand" lenguage. Makes me think in all the new genereation of young people that think they understand computing, being really they just are used to instagram and such. Computing science keeps being complicated and very interesting. Hope some others get the point. Regards and thanks for this amazing content!
An idea for eliminating the flickering effect on the last row: maybe the R6 register of the 6545 chip could be used to hide the last row, so that the printing of the new character line actually happens in the character memory but appears on screen at the next loop only.
Really cool! Thank you for the detailed explanation and BASIC hacks. Love hearing the PET chirp and the sound of the keyboard. I am going to open up my emulator and give it a try!
One of my first computer books was "The Star Wars Question & Answer Book About Computers" (D'Ignazio, 1983 -- www.amazon.com/Star-Question-Answer-About-Computers/dp/0394864417). There is a BASIC program listing for a similar program in this book, albeit much less interesting than your implementation and without the narrowing of the road. I recall a bug where if the edge of the road gets to column 40 (or the edge of the screen), then it would wrap to the next line and mess up the whole game.
I'm glad RUclips showed me your "Anti Microsoft Easter Egg" video awhile back. It inspired me to try something similar on my Radio Shack Color Computer. And, this 10 PRINT RACER will be the subject of something I'll be posting later this week to my site. Nicely done and explained. I was impressed with some of your optimizations, like using "." for a faster zero. Good work!
Bet if you tried, you could make the road scroll the other way! I have an idea - something I did back on my TRS-80 to get the Millennium Falcon through the asteroid field. Can't remember what it was....
The program is checking for a collision *before* it draws the car at its new location. The PEEK that checks for a collision is in line 90. The POKE that draws the car is in line 100. The car scrolls off the top of the screen as new lines are drawn at the bottom of the screen, which is why it doesn't need to POKE S+C,32 to erase the car before checking for a collision.
Does the BASIC interpreter handle it cleanly when FOR loops start over (regarding your conditional NEXT, you don't execute NEXT when the user crashes, instead you start over the FOR Z afterwards)? EDIT: Oh, question answered at 16:20 👌
I give it a go when my pet is working again. Have cut out video ram as it seems to have a problem, waiting for two new replacement chips. 4016 upgraded to 4032, old board 2nd cassette port near large cap on left hand side. Screen was trying to show start message but lots of changing garbage.
I have had the problem with the string too long makes it scroll problem, I fixed it by making a string the entire length of the screen and put a ; at the end. It was in quick basic, so I dont know if it would work on a commodore
Successfully "ported" this to a C64. It worked fine, except some odd behavior: When the Epyx Fastload cart is enabled via a 1541UltimateII+ it would mostly work fine, but occasionally and sporadically it'd print crazy extraneous characters or change the color of the printed characters during the display of the maze. Disabling the Fastload cart seemed to eliminate this unexplained behavior and the program runs perfectly. Anyone know what might be going on?
I tried the c64 file on Vice and it doesnt work properly- the "car" is not showing at all, after the screen is fully drawn it goes to Crash, hiscore stays at 25. Also it doesnt wait for keypress to start again. So basicaly it works as one screen maze generator, without any interactions. Does anybody know why?
It's currently a PET game. You'll need to change S=32768 to S=1024 and POKE158,0 to POKE198,0 and it should run on the C64. You might want to change the "4" and "6" to better controls for left and right on the C64 keyboard.
@@8_Bit oh man, my bad! I quickly looked at the files and saw d64 as c64 and I assumed it is the c64 version hahaha. Sorry for bothering and thanks for reply!
Wouldn't it be neat to draw the initial 25 lines starting from the bottom line and letting them scroll up, so the game starts with what would look like approaching the road/walls?
Leaving the goto in line 70 will make L=0 when the game actually starts. By changing it to a next, L will be 25 when the game start. I don’t think the goto was an error but rather that you forgot why it was there :)
Works perfect on the the c64. i kept getting an error on line 50. turns out i made a mistake on line 40 :). .. on the "the c64"? on the "c64"? on the "maxi"? Is there a better name? doesn't matter. thanks heaps for the upload :D 🕹️ Going to add a little colour to it then get back to typing in listings. Very slowly working my way through the listings in compute gazette, anyone know of any other vintage listings magazines i should be on the lookout for?
RUN, Ahoy!, and Commodore's own in-house magazine were dedicated to Commodore computers. If you lived in the UK, Commodore Force and Zzap!64 were also very popular. There were other magazines that had program listings for the Commodore computer, such as Home Computer Magazine (formerly the TI-99'er), Family Computing, Byte, and several others. By the way, if you want collision detection to work properly on the C64, you need to change the value of S in line 10. On the C64, S=1024 instead of 32768.
Does "Compute Gazette" have checksums on each line of code listing? If so, then you might like to check "Compute", issue 70, for a program that displays the checksum for what you have typed in, so that you can confirm with the listing to see if you typed it in correctly. Also, there is a machine language entry program. I can give you a link, if you need it.
@@SpearM3064 Thanks for the info on the magazines. Yeah Robin talks about s=1024 and in line 210 we need to poke198 for thec64, thanks for the heads up anyway as i sometimes miss important info like that :D
@@eugenetswong They do. Both magazines were from the same company. As a side-note, if you have JiffyDOS installed, the newer version of Proofreader doesn't work.
Sorry, a few years late here discovering your channel and catching up with these awesome and educational videos. Very impressed and humbled at your ability to create a rather fun mini-game with just a screenful of code! Added a few minor tweaks for the C64 based on comments I read here - reassigned the left and right navigation keys as "," and "." respectively (not a big fan of the ubiquitous WSAD input key arrangement being that I'm not left-handed 😣). Also couldn't resist the urge to use a couple custom characters to simulate alpine trees and skis in place of the asterisk... 😁 1 rem 10 print racer: 8-bit show & tell 3 gosub300:rem set up custom chars 5 r$="":forx=1to200:ifx49thenl=0:w=w-1:ifw
I just got a Deja Vu! Have you been on the Evoke demoscene party in Cologne in the last years with the PET? I can swear I played either this or a very similar game on a PET which was installed there.
Interesting! I haven't been to any EU demoscene parties, but I did post a screenshot of an earlier version of this code to Twitter in 2018 so maybe somebody typed it in? :)
Hi Rob, I don't put code on GitHub, but I frequently have .d64 or .prg files for download, with links in the description for each video, including this one :)
11:02 Line 40. Wouldn't printing to column 40 also invoke that horrible C64 bug where the editor reacts to a 40th column print by converting the line to an 80 column logical line, thus forcing the cursor down one too many lines. And so, gaps between lines. There ought to be a way to toggle that nannying off during program execution. It's only needed for editing prior to starting the interpreter. Did they fix that in the C128 and Mega65?
40 columns would otherwise be fine as long as the print in the 40th column has a semicolon after it. The next print would continue on the next physical line, and there wouldn't be any double-spacing. The only problem would be the double-line scroll as it scrolls by logical lines, not physical lines. I think it's kept active during program execution as INPUT also uses the editor's logical lines to allow an input up to 80 columns. No idea if they changed that behaviour on the 128 and Mega65, I'd have to research that.
There must be a poke or three to disable that. There is a kludge using C='s active control codes where you get to print on the 39th column, use the back(left) cursor code, then an insert code to push the last char to occupy the 40th column. Finally you print in the 39th column again to fill the gap made by in insert.
I'm not sure if it would speed up the game a bit more to use integer variables. The % tells BASIC that the variable is an integer, so it might process a bit faster, the drawback is that the parser has to read an additional character but overall might be faster. Also a common trick is to use a GOTO to a higher line number starting at line 0 and reserve lower line numbers for GOSUBs or GOTOs since they take up less program space and the parser scans the fewer number of digits, *and* it less time for BASIC to find the line as it scans for the line number starting at the top of the program - each time! BTW: I'm an old VIC-20 Game programmer from back in the day and wrote a couple of games sold by Video Wizards... Cheers!
Hi Ray, that's really cool that you made VIC-20 games. I looked and found "Muncher". Looks like Centipede with a little twist of Missile Command, neat! Unfortunately integers are converted back to floats for all operations in C= BASIC so they're actually slower. The only real advantage is when using integers in arrays, as they only require 2 bytes per element instead of 5. I made a video about it a while ago: ruclips.net/video/wo14rDnGUbY/видео.html You're right about the low line number trick although since I ended up using an infinite FOR/NEXT loop instead it means GOTOs are used for the game over sequence where it doesn't matter. Thanks for your comment!
@@8_Bit That's a very good explanation and demonstration, I was not aware of these limitations with integer variables... or if I was, I've forgotten or never ran into them. So after all these years I learned yet another facet of the Commodore BASIC. Thanks! So, yes, the game was inspired by those two games, and the "Blue Meanies" was part of the inspiration too. Some code was written in 6502, but the logic and scoring was in BASIC. in 1980's my assembly skills weren't fully formed and I struggled with 8-bit coding, I was a self-taught newbie... Luckily I had some tutoring from Tom Griner who was an absolute 6502 wizard. He knew the opcodes by heart and could poke a program in from BASIC. I am still in awe of him today. So I still have my old Commode equipment and hope one day to restore it, this channel brings back a lot of memories!
soo. considering that we have just concluded that the start of basic address and next line pointers don't matter when loading any basic program on any model commodore :P... here is the stuff that makes it run on all of them... pet, c64, plus4, b series, whatever.. as long as it's 40 columns wide (so no vic-20 or 8032 pets but there only the display would look weird and it would still run, also no max machine as that has no basic) 6 FOR V=0 TO 65280 step 256 7 IF(PEEK(V)=9 AND PEEK(V+1)=14 AND PEEK(V+2)=9)THEN S=V 8 NEXT V it simply searches all pages for 'INI' out of the INIT: you print and then that is the video ram.. it won't accidentially detect the 'INIT:' in the basic program if that magically ends up being page aligned as that is in actual ascii, not character rom character numbers like they are in video ram... one can ofcourse do the same with machine code and simply not use any JMP's only BXX branches which are relative. and only use zero page. we can be sure there is ram wherever basic would load the basic stub and then at least 3kb after that (vic, really old pets).. as long as you print something to the screen using the kernal routine first so the video ram can get detected on that (can even be made invisible with the same color as the background, or just chars which don't print anything at all , space, some others ;)
so... basically.. if only out of all that crap they usually store in variable space under $400 or so (they literally have entire book pages of basic and kernal variables there ) at least 1 would have been standardized to be video ram offset and 1 as screensize... literally ALL software could have been made compatible with all of them for all those years. :P at least the business software... gee thanks for not informing us the basic start address doesn't actually matter (it's not even in that computes first book on cbm i think ;)
Reminds me a lot of a classic TI calculator game. In case someone has a c64 (emulated, recreated, original, or otherwise) and is feeling lazy: www.dropbox.com/s/j0csrhaspl5atbs/10PrintRacerC64.d64?dl=0 It uses the A and D keys (classic WSAD arrangement, basically)
0:12 I made a similar style of game as a teenager to learn to program in BASIC and then in machine language: ruclips.net/video/mHtBnwOkKvA/видео.html . 1:34 Pro tip: every day has a 3am! 2:45 It'd be more random to use RND(1), especially since this is only executed during the initialization. That said, is RND(π) faster than RND(.)? I suppose it wouldn't be, since beyond the parsing, it needs to do some extra floating point operations while RND(0) just reads from a couple of VIA registers on the PET. 15:18 Did PET games standardize on 4-6/2-8 before the IBM-PC came along? 16:45 Would a reverse "H" look more like a car than an asterisk?
Your game looks neat - I like the addition of extra points to pick up. I should add something like that to my game. That's great that every day has a 3 am, as I'll be using a lot of them as I work through my backlog of videos to make! I did some testing and RND(.) appears to be faster than RND(π). I think the 2-4-6-8 controls were fairly standard before the IBM PC, yes. I should try the reverse-H, thanks.
Unfortunately, it wouldn't be possible to smooth scroll this on the PET. Smooth scrolling can be faked with solid blocks on the PET, but not these characters. But a C64 version sure could smooth scroll!
![GEEK TIMË [OFFICIAL AUDIO]](http://i.ytimg.com/vi/ry-6RvkH880/mqdefault.jpg)
![OhGeesy x Lefty Gunplay - What It Iz [Official Music Video]](http://i.ytimg.com/vi/L0yzW9t2ixk/mqdefault.jpg)
Terrific to see these little kernals (sic) of knowledge. +1 for the “emptying the keyboard buffer” tip!
I remember programming something similar on my Commodore 64, only it was the reverse as yours. I had asterisks and such which represented the obstacles (trees), and I used a pair of those lines to represent a skier. The idea was that you were skiing downhill. When you went to the right, it printed \\ when you went to the left, it printed // at the player position so you had all these asterisks and other objects scrolling up, and your ski tracks going through them. I would place the player more near the middle of the screen so you seen the ski tracks where he was scrolling up. There was more freedom to choose where you went as there wasn't ONE path to travel. It was simple to code and fun. You could easily go further with some sprites etc. A good first programming project for anyone learning.
I loved this. I like to write games in basic (something I used to do alot of in the '80's) and now I have a c64maxi and I'm back doing one of my favorite things again writing games. I learned alot from your video and I love this style of gaming using nothing but basic. Thank you very much.
What a cool little BASIC program. It's always nice seeing new stuff being done with PET computers. Nicely done and thank you for sharing!
i know this episode is almost a year old, i typed your games into the c128 with the changes and got a score of 629 first try. interesting little game. thanks
Just programmed it on my CBM 4032 from 1981. So much fun, thanks for that perfect introduction! :)
I remember writing such programs back in 1980 on a PET, with names like ski patrol and (car) racer. Your program is a lot interesting and tiny.
Quite similar to a game which my second cousin and I made on his Texas Instruments TI-99 4/a. It was more like him writing it, because his TI-99 was actually my very first introduction to Basic and programming, probably about a year before I got my own 48k Spectrum.
Anyway, the game had a very similar look and mechanics, also utilising the Print commands scrolling feature. Although it wasn't a maze, it was solid blocks and 45° triangles, and the asterisk was a small downwards facing car. All of which he had made by changing some of the characters. A feature I know the PET doesn't have.
But that was where he lost me, with all those hexa-codes. It took a while before I understood those on my Speccy.
Like to have it get narrower then wider then narrower, so you only have to survive "narrowest" for a period ... and have the narrower / wider be shrinking with each cycle. For that, the number of lines at the same width would be a lot less, to get through several shrinking / widening phases.
I love how comprehensive and thorough your explanations are for each and every line in a program to describe exactly what its purpose and function is. Really well done!
I wrote a version of that game when I was 11 on my C64 in about 1986. I called it Longdrop.
I wrote one game that did something similar, but it was on a different 8-bit machine. Your game is comparable to Stage 3 of 3 of my game, and it was called "N.A.E.R.". Stage 1 drew blocks on the screen that you had to dodge, and Stage 2 drew "Galactic Rifts" you had to fly through. Some of my stages went from start to finish using a FOR/NEXT loop in a single line of code. I explain the logic I used in another one of your videos.
Great video about a really fun basic game. Thanks for making this, both the video and the game.
I've just adapted it for C64, next I'm going to re-adapt it for Vic20 (taking into account the reduced screen space) and then even fire up the C128 80 column mode in WinVice and re-adapt it to that too, just for fun.
I noticed one thing while I was following your video and editing it for the C64, and that is to do with the score. You use the D variable for the score but since it draws the road 25 times before you get control of the car, this means that you have a score of 25 points before you actually start driving! And since the road is constantly being updated at the bottom of the screen while your car is at the top, this means your score is actually 25 points higher than the actual distance you have travelled in the game. You can check this by manoeuvring your car off the road right at the start... I did this and instead of the distance I had travelled (which was 6 in the case when I tried) it said my score was 31.
To edit this, you could of course just deduct 25 points from the score in line 200 before doing the high score check, but instead what I did was set the D variable in line 10 to -24 and updated the check in line 70 to 0. This way the screen still fills with graphics before the game proper starts but starts with your score actually at 0 rather than 25.
Because of this "bug" (If you want to call it that) this also means you move from level 1 to 2 prematurely, after you have only driven 25 lines instead of 50, so I also changed the L variable in line 20 to start at -24 as well to compensate and make sure you drive a full 50 lines before narrowing the road width for the first time.
I also have a question, is assigning the peek of the car position in line 90 to a variable then doing a check of the variable faster than checking the value by doing a peek directly?
What I mean is, could line 90 be rewritten as
90 IFPEEK(S+C)32THEN200
Would this be faster or is it faster the way you have written it, assigning the variable P to it first then checking that variable?
@10:48 Code reviews are awesome! I've found so many problems, optimizations, and simplifications just by trying to explain to someone else what I was doing, that I started pretending to explain my code to someone (in my head).
I never had a C64 growing up - my first computer was an old Atari - but I do remember being fascinated learning to code in BASIC on my first 386. Watching some of the videos on your channel has reignited that interest and the other day I wrote a version of your famous maze program in QB 4.5 in DOSBox. It's nowhere near as elegant as yours but it gets the job done. Since the ASCII codes are completely different than the PETSCII codes I couldn't just use the simple 205.5 trick you do. Also since the slashes are shaped and spaced a little different the output doesn't quite look like your maze does, but that's just something to play around with and see what I can come up with! Anyway, thank you for your videos and reigniting my interest in coding for BASIC...Keep up the great work!
In any of the flavors of BASIC on a PC, you could define a two-character string so the desired characters are adjacent to each other, then use the RND function to select either the first or the second character. I just tested it with the following code - it doesn't look as nice as on a Commodore due to the line spacing, but it works...
{CBMBASIC}
10 A$="/\"
20 PRINTMID$(A$,RND(1)*2+1,1);:GETK$:IFK$=""THEN20
{QBASIC / QUICKBASIC}
A$ = "/\"
WHILE INKEY$ = ""
PRINT MID$(A$, RND(1) * 2 + 1, 1);
WEND
_Just plain cool!!_
For the sake of a speed comparison, will you please adapt the code to the VIC 20 and a machine with 80 column mode? *_Thanks!_*
You know, ever since I've been re-introducing myself to the C64 this year, I've been kind of bugged by MS/CBM BASIC's incredible limitations and slowness (taking often 1000 cycles per statement). Line numbers have been especially frustrating to me, after experimenting with Pascal, C, Unix Shell, Perl, and Python for most of my life (in that order! ;) ...
THEN I started learning a little bit of 6502 assembly.
Now I'm amazed at every bit of software I see, especially BASIC. I haven't even figured out how to count beyond 255 yet!!! 😅
You make it look so easy. I always thought of myself as a decent C= BASIC coder (back in the day, anyway). This is brilliant -- always learning from you. A fun little anecdote, my mother always shopped at a large Toronto area mall back in the 80s. I used to always make my way to the display C64s at EATONS and Simpsons and quickly type in and run 10 PRINT and always added POKE 808,252 so people couldn't look behind the wizard's curtain. 😂 On a few occasions, an _adult_ would ask how I did that -- felt good as a kid.
Reminds me of what I used to do back when I was a kid, rather than go out and play with freinds I would spend days on end indoors writing games in basic!
Sir, you are a Commodore legend. I bow to your greatness.
Interesting. I wasn't aware of the Print .. SPC(W) command in BASIC (admittedly I haven't used BASIC since about 1986) .. which from the look of it prints a number of spaces as specified by the variable W. I'm a bit fuzzy on how the collision detection test and 'road' narrowing worked .. better go watch the video again. Thanks for the upload mate.
For the collision detection test, in line 90 he was PEEKing directly into screen memory in line 90, looking in the location that the car was about to move into, for any non-space character.
As for the road narrowing, that's in line 60. The variable W is used to keep track of how wide the 'road' is (in line 10 he initializes W to 15). The variable L keeps track of how many lines of graphics have been printed. After every 50 rows (L>49), L is reset to 0 and the width of the road is reduced by 1 (W=W-1) to a minimum of 3.
love it...dont' see many pet games on here...reminds me of a ismpler game in grade school that consisted of a magnet, a staple, a piece of paper and a maze drawn out with a pencel. magnet on the bottom of the paper, staple on top and you move the paper to guide the staple through the maze. Low tech days.
Very cool!
Nice job. This is very similar to a program I wrote for the C64. The sides kept closing in until the end of the game. Nice program. Nice how you saved every byte to speed things up. Good job. Please keep up these simple, but informative programs for the young ones to understand programming.
I wonder what we would've thought if someone told us back in the 80s that 40 years into the future, people from all over the world would watch videos where someone codes simple Basic games on a CBM PET... :D
Completely awesome. I love this channel.
THE best comment so far :D
Last Starfighter! This reminds me of the first program source code I ever saw. Someone in my high school wrote a BASIC program on the TRS-80 Model I that was similar to this but had you flying a spaceship through a meteor storm. Thanks for triggering that memory!
A thought on optimization; instead of using S=32768, C=20, and poke/peek to S+C, set C directly to 32788 and poke/peek directly to C. This avoids a few additions and variable lookups :-)
Nice suggestion, even if the increased efficiency makes the game a bit harder. 😄
I love how hauntingly quiet classic computers were. Its music to my ears.
Hi Robin, I admire your programming skills on the C64. As a kid I was quite deep into Basic, but I never understood assembler. I love to dit down in my "cave", turning on the old machine(s) and programming some stuff, just for fun. I even try some assembler language (and sometimes it even works ;-)). I find your videos about programming very interesting. Keep on your good work!
And yet a 3rd speed optimization (for readability I am adding useless spaces here):
90 J=S+C: If Peek(J)=32 Then PokeJ,42: Next
Now get rid of line 100 entirely. I haven't touched CB< BASIC in 35 years but this should be much faster.
IIRC, you can speed it all up by using variables instead of numbers like 32 (for space) and 42 (asterisk). I cannot recall for sure if variables are fastest when defined in the first line of the program but I think so.
This is a nice fun little game. One minor point. At the end you update the high score held in variable H but the variable was never intialized. As there was no complaint from BASIC on this machine it was ok but on other machines (and in other programming languages) you should set an initial value rather than assuming it will default to 0.
I begun programming basic back in 1986 on my Commodore 64 and I miss the days when we made things like that ourself. Of course I was programming my ATARI computers in basic until 1998 and even after in emulators. But using an emulator is not always confortable, so I did not do much programming for years now. O.o
Very cool :-) ! But why does the PET beep when crossing a specific column?
If you had included the listing in the description, I could then copy and paste it straight into VICE using the right mouse button. It would take literally a few seconds. You'd need to make the listing all lowercase though otherwise the listing when pasted produces business graphics. Love programming on the PET. Thanks!
1 rem 10 print racer: 8-bit show & tell
5 r$="":print"Sinit:";:forx=1to75:m$=chr
$(205.5+rnd(.)):r$=r$+m$:printm$;:next
10 print"S":c=20:r=13:w=15:d=0:s=32768
20 l=0:forz=0to1step0:x=rnd(.)10
30 ifx37thenr=37-w
50 rn=rnd(.)35+1:printmid$(r$,rn,r);spc
(w);mid$(r$,rn,39-r-w)
60 d=d+1:l=l+1:ifl>49thenl=0:w=w-1:ifw
Trying to write my first game in DOS right now. Thanks for the informative video
No Man's Road - billions of unique tracks
I have this game on my calculator already where it is called “tunnel”, IIRC.
It reminded me a bit of roadrace for the trs-80. I still mess with an emulated version in dosbox.
This is a nice little program. Thanks for taking me back in time. I didn't know a FOR/NEXT loop ran faster than a GOTO. Maybe that's just on the CBM computers but I wish I had known that back in the 80s when I programmed games in Z-80 BASIC.
Just a couple of suggestions to make the program run even faster:
Put your setup at the end of the program and use a GOTO to call it from the first line. Many BASIC interpreters scan the entire program, line by line, to find the current execution line. Relegating set up code to the higher line numbers (particularly with complex set up routines) can make the game loop run faster.
Rather than putting an IF/THEN/NEXT at line 70 to test for the first 24 lines, run a short FOR/TO/NEXT loop in the setup section (possibly with a different, non-random "race start" pattern?). It uses a bit more memory but saves a few m/sec in the game loop.
CBM BASIC only scans the program line by line for GOTO or GOSUB, and because I'm using the infinite FOR/NEXT for the main game loop, instead of a GOTO, there's no gains to be found by moving the main game loop closer to the top of the program. You're right about the potential speed savings in line 70 though!
Awesome. That explains the shorter time delay in FOR/TO loops :)
Nice work! I REALLY wish I had a PET, but I can just imagine how rare and desirable they are!
I know it's not the same as the real thing, but there's some nice PET emulators for Windows.
I always thought it would be cool if there were fanzines around emulating the old commodore magazines, where you can code the games and play them. It could even adjust to some simple modern code to diversify.
I've been searching for such magazine clips for my CoCo2 and VIC-20. There's lots of stuff on abandonware archives, but they're all in audio format (for cassette) or program files which I have no practical means of transferring to these systems.
Google: “usborne 1980s computer books”. The publisher for these has released the 1980s books as free PDF! These are the books I used back in the day!
Also google “The Computer Magazine Archives” at The Internet Archive has they have magazines scanned and uploaded.
usborne.com/browse-books/features/computer-and-coding-books/
archive.org/details/computermagazines
@@howard81 Nice! Thanks!
This reminds me a lot of the game "Piggy" that you extracted from a vinyl record a few months ago. Great video, I really enjoyed you going through the logic of the program. I'll definitely try it on my C64 and have fun modifying it. ☺ BTW, that old-fashioned green monochrome monitor makes for a nice-looking video.
Good explained. Sir. Very nice. The 4032 was my first computer. I sold it to buy the commodore 64 and floppy 1541. thanks for your content. Keep,up the good work. Stay safe.
I think the lowest possible score there is 25, because it's already D=25 when the car starts moving , might be more accurate to have H=D-25 so you know how many lines the car travelled, rather than how many lines have been printed.
What I admire most about this, is that, by using a computer that for most at first feels simple and odd, It takes quite a lot of time to understand what a program does even being that is written in a "simple to understand" lenguage. Makes me think in all the new genereation of young people that think they understand computing, being really they just are used to instagram and such. Computing science keeps being complicated and very interesting. Hope some others get the point. Regards and thanks for this amazing content!
An idea for eliminating the flickering effect on the last row: maybe the R6 register of the 6545 chip could be used to hide the last row, so that the printing of the new character line actually happens in the character memory but appears on screen at the next loop only.
Really cool! Thank you for the detailed explanation and BASIC hacks. Love hearing the PET chirp and the sound of the keyboard. I am going to open up my emulator and give it a try!
I have a PET 8032. So in theory, you could get twice the game with extra characters for the single screen. :-)
One of my first computer books was "The Star Wars Question & Answer Book About Computers" (D'Ignazio, 1983 -- www.amazon.com/Star-Question-Answer-About-Computers/dp/0394864417). There is a BASIC program listing for a similar program in this book, albeit much less interesting than your implementation and without the narrowing of the road. I recall a bug where if the edge of the road gets to column 40 (or the edge of the screen), then it would wrap to the next line and mess up the whole game.
I wrote something similar to that on my C64 back in the day. The road didn't get progressively narrower though, which is a good idea by the way.
I'm glad RUclips showed me your "Anti Microsoft Easter Egg" video awhile back. It inspired me to try something similar on my Radio Shack Color Computer. And, this 10 PRINT RACER will be the subject of something I'll be posting later this week to my site. Nicely done and explained. I was impressed with some of your optimizations, like using "." for a faster zero. Good work!
I love the sound of the "clicky" keyboard.
You need to publish this into a pdf fanzine, along with the CRC checksum at the end of each line to have a proper retro printed magazine game!
Another, alternate speed optimization that should work, which is intended to span lines 90 and 100.
90 J=S+C:IfPeek(J)32Then200
100 PokeJ,42:Next
Bet if you tried, you could make the road scroll the other way! I have an idea - something I did back on my TRS-80 to get the Millennium Falcon through the asteroid field. Can't remember what it was....
Download? I'm quicker in typing it new into my C64 than it would take me to download and transfer it to the computer. :)
more fun also :D
@@edabean007 Funnier than playing it.
Very cool, trans-coding to assembly would also make some great content
when I was a kid I wrote a version of this on a Timex Sinclare. I called it a skying. I did not have it get narrower, but it got faster.
Robin, how does the code prevent that it finds the car itself when checking for a collision?
The program is checking for a collision *before* it draws the car at its new location. The PEEK that checks for a collision is in line 90. The POKE that draws the car is in line 100. The car scrolls off the top of the screen as new lines are drawn at the bottom of the screen, which is why it doesn't need to POKE S+C,32 to erase the car before checking for a collision.
Thanks @SpearM75503!
@@SpearM3064 Thanks. That makes sense :)
That's cool... I have a few that I wrote when I was in high school that I'd love to make available. Not saying that some of them aren't crap. lol
ah memories! 😊 just some thoughts: since you're using 39 columns then C=19 and R=12 at the start, to start perfectly at the center? also R+W
Does the BASIC interpreter handle it cleanly when FOR loops start over (regarding your conditional NEXT, you don't execute NEXT when the user crashes, instead you start over the FOR Z afterwards)? EDIT: Oh, question answered at 16:20 👌
I give it a go when my pet is working again. Have cut out video ram as it seems to have a problem, waiting for two new replacement chips. 4016 upgraded to 4032, old board 2nd cassette port near large cap on left hand side. Screen was trying to show start message but lots of changing garbage.
I have had the problem with the string too long makes it scroll problem, I fixed it by making a string the entire length of the screen and put a ; at the end. It was in quick basic, so I dont know if it would work on a commodore
🎵 Here's a little game I wrote 🎵
🎵 You might want to run it poke for poke 🎵
🎵 Don't worry, be happy 🎵
Successfully "ported" this to a C64. It worked fine, except some odd behavior: When the Epyx Fastload cart is enabled via a 1541UltimateII+ it would mostly work fine, but occasionally and sporadically it'd print crazy extraneous characters or change the color of the printed characters during the display of the maze. Disabling the Fastload cart seemed to eliminate this unexplained behavior and the program runs perfectly. Anyone know what might be going on?
One Dutch magazine had some kind of program like this to type in. But instead of the screen, it printed on paper.
Always cool to see this kind of optimized Basic code on your channel! Not exactly easy (for me) to read, but fun seeing how dense it can get. 😄
It's only fun when it works. Semi optimized BASIC, much like obfuscated C is a real bear to debug.
I just realized that i suggested your own game to yourself in another video 😐 thats how great it is 😅
Nice "The Last Starfighter" quote there :-)
It was on my mind because we had just released an episode all about The Last Starfighter on my Growing Up '80s podcast: www.patreon.com/posts/35336518
I tried the c64 file on Vice and it doesnt work properly- the "car" is not showing at all, after the screen is fully drawn it goes to Crash, hiscore stays at 25. Also it doesnt wait for keypress to start again. So basicaly it works as one screen maze generator, without any interactions. Does anybody know why?
It's currently a PET game. You'll need to change S=32768 to S=1024 and POKE158,0 to POKE198,0 and it should run on the C64. You might want to change the "4" and "6" to better controls for left and right on the C64 keyboard.
@@8_Bit oh man, my bad! I quickly looked at the files and saw d64 as c64 and I assumed it is the c64 version hahaha. Sorry for bothering and thanks for reply!
Wouldn't it be neat to draw the initial 25 lines starting from the bottom line and letting them scroll up, so the game starts with what would look like approaching the road/walls?
Do you have a GOTO 10 line???!!! Nice program optimization, I would have been tempted to do it in assembly.
Great content love the old school gear. Cheers :)
Leaving the goto in line 70 will make L=0 when the game actually starts. By changing it to a next, L will be 25 when the game start. I don’t think the goto was an error but rather that you forgot why it was there :)
So... I created a (minor) bug! I think you're right.
@@8_Bit You're welcome. And thanks for all the good content you produce. I learn stuff that puzzled me back then but I never figured out.
remember playing. a similar game on a DEC VAX/VMS called tunnel
Works perfect on the the c64. i kept getting an error on line 50. turns out i made a mistake on line 40 :). .. on the "the c64"? on the "c64"? on the "maxi"? Is there a better name? doesn't matter. thanks heaps for the upload :D 🕹️ Going to add a little colour to it then get back to typing in listings. Very slowly working my way through the listings in compute gazette, anyone know of any other vintage listings magazines i should be on the lookout for?
RUN, Ahoy!, and Commodore's own in-house magazine were dedicated to Commodore computers. If you lived in the UK, Commodore Force and Zzap!64 were also very popular. There were other magazines that had program listings for the Commodore computer, such as Home Computer Magazine (formerly the TI-99'er), Family Computing, Byte, and several others.
By the way, if you want collision detection to work properly on the C64, you need to change the value of S in line 10. On the C64, S=1024 instead of 32768.
Does "Compute Gazette" have checksums on each line of code listing? If so, then you might like to check "Compute", issue 70, for a program that displays the checksum for what you have typed in, so that you can confirm with the listing to see if you typed it in correctly. Also, there is a machine language entry program.
I can give you a link, if you need it.
@@SpearM3064 Thanks for the info on the magazines. Yeah Robin talks about s=1024 and in line 210 we need to poke198 for thec64, thanks for the heads up anyway as i sometimes miss important info like that :D
@@eugenetswong i think the early issue have no error checking but i know later ones have it. The compute gazette proofreader its called.
@@eugenetswong They do. Both magazines were from the same company. As a side-note, if you have JiffyDOS installed, the newer version of Proofreader doesn't work.
Why don't you use the same RND calculation for both the roads x coordinate and the substring?
Sorry, a few years late here discovering your channel and catching up with these awesome and educational videos. Very impressed and humbled at your ability to create a rather fun mini-game with just a screenful of code! Added a few minor tweaks for the C64 based on comments I read here - reassigned the left and right navigation keys as "," and "." respectively (not a big fan of the ubiquitous WSAD input key arrangement being that I'm not left-handed 😣). Also couldn't resist the urge to use a couple custom characters to simulate alpine trees and skis in place of the asterisk... 😁
1 rem 10 print racer: 8-bit show & tell
3 gosub300:rem set up custom chars
5 r$="":forx=1to200:ifx49thenl=0:w=w-1:ifw
I just got a Deja Vu! Have you been on the Evoke demoscene party in Cologne in the last years with the PET?
I can swear I played either this or a very similar game on a PET which was installed there.
Interesting! I haven't been to any EU demoscene parties, but I did post a screenshot of an earlier version of this code to Twitter in 2018 so maybe somebody typed it in? :)
1:17 N I C E
Hi Robin, I'm a newish subscriber so sorry if this is a frequently asked question. Do you put your code on GitHub?
Hi Rob, I don't put code on GitHub, but I frequently have .d64 or .prg files for download, with links in the description for each video, including this one :)
11:02 Line 40. Wouldn't printing to column 40 also invoke that horrible C64 bug where the editor reacts to a 40th column print by converting the line to an 80 column logical line, thus forcing the cursor down one too many lines. And so, gaps between lines. There ought to be a way to toggle that nannying off during program execution. It's only needed for editing prior to starting the interpreter. Did they fix that in the C128 and Mega65?
40 columns would otherwise be fine as long as the print in the 40th column has a semicolon after it. The next print would continue on the next physical line, and there wouldn't be any double-spacing. The only problem would be the double-line scroll as it scrolls by logical lines, not physical lines. I think it's kept active during program execution as INPUT also uses the editor's logical lines to allow an input up to 80 columns. No idea if they changed that behaviour on the 128 and Mega65, I'd have to research that.
There must be a poke or three to disable that. There is a kludge using C='s active control codes where you get to print on the 39th column, use the back(left) cursor code, then an insert code to push the last char to occupy the 40th column. Finally you print in the 39th column again to fill the gap made by in insert.
Add a score bonus for staying in the center of the road. 2 for dead center, 1 for 1 character away from center.
lol and now I need to dust off my blu-ray of last star fighter.
In case you want to hear me and a friend talk about The Last Starfighter, we released this podcast recently: www.patreon.com/posts/35336518
Such a kind of game was one of my first programming approaches on the Sharp MZ-80K (no rom BASIC) back in 1979 (being 10 years old)
you have the best end music...
I have to agree with that !
Perhaps you’re navigating through a canyon?
Definitely, Print 10 Canyon Racer
Call it Canyon Crawl.
I love it...can’t wait to try it on my pet
I'm not sure if it would speed up the game a bit more to use integer variables. The % tells BASIC that the variable is an integer, so it might process a bit faster, the drawback is that the parser has to read an additional character but overall might be faster. Also a common trick is to use a GOTO to a higher line number starting at line 0 and reserve lower line numbers for GOSUBs or GOTOs since they take up less program space and the parser scans the fewer number of digits, *and* it less time for BASIC to find the line as it scans for the line number starting at the top of the program - each time! BTW: I'm an old VIC-20 Game programmer from back in the day and wrote a couple of games sold by Video Wizards... Cheers!
Hi Ray, that's really cool that you made VIC-20 games. I looked and found "Muncher". Looks like Centipede with a little twist of Missile Command, neat!
Unfortunately integers are converted back to floats for all operations in C= BASIC so they're actually slower. The only real advantage is when using integers in arrays, as they only require 2 bytes per element instead of 5. I made a video about it a while ago: ruclips.net/video/wo14rDnGUbY/видео.html
You're right about the low line number trick although since I ended up using an infinite FOR/NEXT loop instead it means GOTOs are used for the game over sequence where it doesn't matter. Thanks for your comment!
@@8_Bit That's a very good explanation and demonstration, I was not aware of these limitations with integer variables... or if I was, I've forgotten or never ran into them. So after all these years I learned yet another facet of the Commodore BASIC. Thanks! So, yes, the game was inspired by those two games, and the "Blue Meanies" was part of the inspiration too. Some code was written in 6502, but the logic and scoring was in BASIC. in 1980's my assembly skills weren't fully formed and I struggled with 8-bit coding, I was a self-taught newbie... Luckily I had some tutoring from Tom Griner who was an absolute 6502 wizard. He knew the opcodes by heart and could poke a program in from BASIC. I am still in awe of him today. So I still have my old Commode equipment and hope one day to restore it, this channel brings back a lot of memories!
Can't you add a ; to the last print to avoid extra scrolling?
soo. considering that we have just concluded that the start of basic address and next line pointers don't matter when loading any basic program on any model commodore :P... here is the stuff that makes it run on all of them... pet, c64, plus4, b series, whatever.. as long as it's 40 columns wide (so no vic-20 or 8032 pets but there only the display would look weird and it would still run, also no max machine as that has no basic)
6 FOR V=0 TO 65280 step 256
7 IF(PEEK(V)=9 AND PEEK(V+1)=14 AND PEEK(V+2)=9)THEN S=V
8 NEXT V
it simply searches all pages for 'INI' out of the INIT: you print and then that is the video ram.. it won't accidentially detect the 'INIT:' in the basic program if that magically ends up being page aligned as that is in actual ascii, not character rom character numbers like they are in video ram...
one can ofcourse do the same with machine code and simply not use any JMP's only BXX branches which are relative. and only use zero page. we can be sure there is ram wherever basic would load the basic stub and then at least 3kb after that (vic, really old pets).. as long as you print something to the screen using the kernal routine first so the video ram can get detected on that (can even be made invisible with the same color as the background, or just chars which don't print anything at all , space, some others ;)
so... basically.. if only out of all that crap they usually store in variable space under $400 or so (they literally have entire book pages of basic and kernal variables there ) at least 1 would have been standardized to be video ram offset and 1 as screensize... literally ALL software could have been made compatible with all of them for all those years. :P at least the business software... gee thanks for not informing us the basic start address doesn't actually matter (it's not even in that computes first book on cbm i think ;)
it's only step 256 because on the vic-20 it's not 1024 aligned. afaik that's the only one. :P
My kids and I added a starting line on C64 with char 168, and used Char216 as a car. We cannot understand where the "For" is for line 100.
The FOR is way up on line 20. It's just a way of generating an infinite loop without having to GOTO the beginning of line 20.
@@8_Bit Oh, I see, and line 70, but that's a conditional.
@@8_Bit Thanks so much!
Can you make more games in BASIC like:Pacman,Tetris,Snake?
Reminds me a lot of a classic TI calculator game.
In case someone has a c64 (emulated, recreated, original, or otherwise) and is feeling lazy:
www.dropbox.com/s/j0csrhaspl5atbs/10PrintRacerC64.d64?dl=0
It uses the A and D keys (classic WSAD arrangement, basically)
Forgot (or never knew) so much of cbm v2 Basic
Now I want to see this game written in assembler...
0:12 I made a similar style of game as a teenager to learn to program in BASIC and then in machine language: ruclips.net/video/mHtBnwOkKvA/видео.html .
1:34 Pro tip: every day has a 3am!
2:45 It'd be more random to use RND(1), especially since this is only executed during the initialization. That said, is RND(π) faster than RND(.)? I suppose it wouldn't be, since beyond the parsing, it needs to do some extra floating point operations while RND(0) just reads from a couple of VIA registers on the PET.
15:18 Did PET games standardize on 4-6/2-8 before the IBM-PC came along?
16:45 Would a reverse "H" look more like a car than an asterisk?
Your game looks neat - I like the addition of extra points to pick up. I should add something like that to my game.
That's great that every day has a 3 am, as I'll be using a lot of them as I work through my backlog of videos to make!
I did some testing and RND(.) appears to be faster than RND(π).
I think the 2-4-6-8 controls were fairly standard before the IBM PC, yes.
I should try the reverse-H, thanks.
How about a machine code rewrite and some smooth scrolling?
Nice, thanx for this episode.. now try to smooth scroll up with some extra ml code. 🤓😍
Unfortunately, it wouldn't be possible to smooth scroll this on the PET. Smooth scrolling can be faked with solid blocks on the PET, but not these characters. But a C64 version sure could smooth scroll!
Cool video, never had a PET, want one though.