The fun we had going through this process was absolutely worth it, tears in my eyes laughing Robin taking it up another level in reviewing this! - David is so super creative and Jim's "extra Space" would just drive David bonkers - he had it coming !
What i have just seen is pushing me to do the same for my 10 line game too! :D I placed 12th, same category (PUR80) Congratulations for the excellent analysis, Robin!
@12:06, yeah, those were put in to trigger my OCD when reviewing the code. Jim writes: "The extra space is to drive my friend David crazy." ( bunsen.itch.io/trick-shoot-ten-by-jim-happel )
The extra spaces started the jokes. David wanted me to remove a space in that line, but just to trigger him I secretly added a bunch more spaces and noted it in my entry. Once the entry was published, I pointed it out to him. : ) But he got me back by secretly packaging my stoopid 10 line game as if it was deserving of a physical release!
BASIC 7 on the 128 had ELSE, and BEGIN...BEND let the THEN and ELSE parts span multiple BASIC lines, but there still wasn't a mechanism to "go the other way" from BEGIN/BEIND and have additional unconditional code after the IF on the same BASIC line. Using ON..GOTO as a way to do that is absolutely brilliant; I'm kicking myself for not thinking of it back in the day. I never really played with ON..GOTO at all, and I sort of assumed that it would error out when the value was out of range (even if not negative) instead of just falling through to the next statement...even if it's on the same line! Fantasitc.
24:22 Ok, someone help me make out these lyrics. Here's what I got so far: trick shoot-ten is a great game made by my friend jim happel also my friend dave ? ? ? ? ? amazing what you can do to ? ? ? it's no ? ? ?
I've always found it interesting how similar *and* how different the C64 BASIC and AppleSoft are - even sharing memory locations, which is bizarre given the very different (other than CPU) hardware. Here one of the differences is the removal of spaces - AppleSoft reformats; it seems by contrast C64 largely keeps them intact. Weird.
Yeah, as far as I know C64 BASIC only strips any spaces between the line number and first command, and after the last command, keeping everything between the two. And then when LISTing it insists on printing a single space after the line number even though that's not stored in RAM.
Impressive! 🇨🇦 Now, quick, do the PET 2001 conversion. Spending 30 seconds per line will probably be sufficient, eh. 😜 Then invent a cartridge system too. 😱
0:30 The cover art is reminiscent Lister playing planetary pool in the "White Hole" episode of "Red Dwarf". 10:40 Line 0 is longer than "Pure 80"; I guess they allow abbrevs. 11:27 Line 1 has some unnecessary semicolons in its PRINT statement.
Yeah, I think PUR-80 specifies an input limit of 80 characters per line; it can be longer once listed whether due to abbrevs. or whatever else. It occurs to me that CBM BASIC insists on printing a blank space after the line number, so even without abbrevs. an 80 character input can cause an 81 character line when listed. I can't think of any other non-abbrev. reason that extra characters would be shown, can you?
Regarding the unnecessary semicolons - you are right! I just took them out and it runs fine. I guess that's a 38 year old habit I need to break in compos like this! : )
I only found out about most semicolons being unnecessary in the last few years. It'd be interesting to figure out all the cases where they are necessary. I think it's mainly when there's two float variables next to each other; integers, strings and arrays seem to be sufficiently delimited by their % $ () symbols, as are variables trailing functions. But maybe some floats up against functions would be misinterpreted too. As a general rule, I suppose, don't use semi-colons unless you get the wrong results without them?
@@8-bitshowandtell247: The behaviour would depend on how the expression parser is implemented. PRINT 2BPEEK(3)4 displays four results. I wrote a parser previously that when fed something like "2B" would tokenize "2" and "B" as separate expressions and then add them to the root parse-tree node (where there should only be one attached expression). BASIC probably stops parsing an expression when the next token isn't an "infix" operator. In the PRINT statement, it will keep trying to parse additional expressions, but in something like A=2B, it stops after "A=2" and then tries to parse "B" as a statement separator.
The epilepsy warning is a bit of an anachronism; those CYA exhortations/disclaimers only became a thing later. Btw., I wonder if the C64 could have been sufficient to drive a 3D-printer with enough relevant software development.
Instead of using the BASIC routine to copy the BASIC program into $0801, would it be possible to use the following method? 1. Load the BASIC program from disk into regular BASIC memory, but don't run it. 2. Save the entire BASIC program from $0801 to the end as a binary block using TMP 3. Store that block anywhere on the cartridge, say $9000 on an 8K cart 4. Using the cart's bootloader code, move the BASIC block from $9000 to $0801 using a simple indexed loop 5. Then run the BASIC program via the "r(shift)U" method called by the cart's routine. Maybe I'm way off, but at least I was thinking about it. heh
I'm thinking of renaming this 2nd channel to "Robin's Show And Tell" and covering whatever I'm interested in; would solve this name problem and also let me expand my scope a bit more.
Did you ever figure out why the whitespace was inserted into the basic line? Also, the order of setup on the ROM "header" code (.elf's long lost ancestor) is confusing, I cannot figure out why basic setup would be done after the program is copied into RAM, the normal system bootup would have done that already... maybe a better alternative would be the feed the basic program in through the keyboard buffer? Probably would take longer though... Cheers,
The extra spaces started the jokes. David wanted me to remove a space in that line, but just to trigger him I secretly added a bunch more spaces and noted it in my entry as "The extra space is to drive my friend David crazy." ( bunsen.itch.io/trick-shoot-ten-by-jim-happel ). Once the entry was published, I pointed it out to him and our other friends. : ) He posted "You win this round Happel". Little did I know he launched into this secret over-the-top packaging of my stoopid 10 line game, recruiting Jorie and our other friend David to help too! I got a copy of this in the mail, my daughter was there when I opened it, we were laughing so hard! Oh, and then he pushes it to Robin to take this to even a higher level of fun!
Fantastic job Robin. I love how you went thru that machine code so us NON-Programmers can understand it. Thank you.
The fun we had going through this process was absolutely worth it, tears in my eyes laughing Robin taking it up another level in reviewing this!
- David is so super creative and Jim's "extra Space" would just drive David bonkers - he had it coming !
This is why I like the retro community, that much thought and attention to detail going into making something like this for a surprise!
What i have just seen is pushing me to do the same for my 10 line game too! :D I placed 12th, same category (PUR80)
Congratulations for the excellent analysis, Robin!
This is great, love the action figures. The packaging is so over the top. Funny meme like graphic on the cover. Right down our alley.
Looks like good fun among friends. Making a playable game in 10 lines of BASIC is very impressive, reminds me of the old 1k demo competitions.
@12:06, yeah, those were put in to trigger my OCD when reviewing the code. Jim writes: "The extra space is to drive my friend David crazy." ( bunsen.itch.io/trick-shoot-ten-by-jim-happel )
Also, thanks to Joeri for the circuit boards and action figures :)
The extra spaces started the jokes. David wanted me to remove a space in that line, but just to trigger him I secretly added a bunch more spaces and noted it in my entry. Once the entry was published, I pointed it out to him. : ) But he got me back by secretly packaging my stoopid 10 line game as if it was deserving of a physical release!
Okay, this extra space thing is my favorite thing I’ve seen this week. Well played.
So is the randomly capitalized JSR instruction in the "OLD" code inside the cartridge loader a reverse-OCD-trigger to get revenge? :)
I saw Jim's face and immediately it was like "wait... I know that guy!"
Man, I need this. For... science. Yeah science.
Yeah I would really like to hear more about this 10-liner competition. Instant classic, reminds me of the 1970s demos!
BASIC 7 on the 128 had ELSE, and BEGIN...BEND let the THEN and ELSE parts span multiple BASIC lines, but there still wasn't a mechanism to "go the other way" from BEGIN/BEIND and have additional unconditional code after the IF on the same BASIC line. Using ON..GOTO as a way to do that is absolutely brilliant; I'm kicking myself for not thinking of it back in the day. I never really played with ON..GOTO at all, and I sort of assumed that it would error out when the value was out of range (even if not negative) instead of just falling through to the next statement...even if it's on the same line! Fantasitc.
I can't believe you CRACKED the game and showed the source code!! Horrible! :)
The 10 liner contest is great fun, I recommend giving it a go. I got 7th in extreme-256 last year and 6th this year, so I'm going for 5th next year :)
Oh ! What a nice cart case ! 😊 😁😎
You definitely need to make a physical version of a game, if 8BG can do it so can you Robin! 💾💾💾
24:22 Ok, someone help me make out these lyrics. Here's what I got so far:
trick shoot-ten is a great game
made by my friend jim happel also my friend dave ? ? ? ? ?
amazing what you can do to ? ? ?
it's no ? ? ?
Wow, I had not heard that until you pointed it out!!
You're on the right track :)
I'm wondering about those spaces on line 3 now!
I found out since making the video that Jim mentions it in his code commentary for line 3 here: bunsen.itch.io/trick-shoot-ten-by-jim-happel
@@8-bitshowandtell247 Hahaha! Poor David :)
I've always found it interesting how similar *and* how different the C64 BASIC and AppleSoft are - even sharing memory locations, which is bizarre given the very different (other than CPU) hardware. Here one of the differences is the removal of spaces - AppleSoft reformats; it seems by contrast C64 largely keeps them intact. Weird.
Yeah, as far as I know C64 BASIC only strips any spaces between the line number and first command, and after the last command, keeping everything between the two. And then when LISTing it insists on printing a single space after the line number even though that's not stored in RAM.
Impressive! 🇨🇦
Now, quick, do the PET 2001 conversion. Spending 30 seconds per line will probably be sufficient, eh. 😜
Then invent a cartridge system too. 😱
I think Jim already made a PET version! But yeah, the cartridge part will be difficult :)
I need to know. The opening... When you wave your hand like that. Is that the same thing obi wan does???
0:30 The cover art is reminiscent Lister playing planetary pool in the "White Hole" episode of "Red Dwarf".
10:40 Line 0 is longer than "Pure 80"; I guess they allow abbrevs.
11:27 Line 1 has some unnecessary semicolons in its PRINT statement.
Yeah, I think PUR-80 specifies an input limit of 80 characters per line; it can be longer once listed whether due to abbrevs. or whatever else. It occurs to me that CBM BASIC insists on printing a blank space after the line number, so even without abbrevs. an 80 character input can cause an 81 character line when listed. I can't think of any other non-abbrev. reason that extra characters would be shown, can you?
Regarding the unnecessary semicolons - you are right! I just took them out and it runs fine. I guess that's a 38 year old habit I need to break in compos like this! : )
I only found out about most semicolons being unnecessary in the last few years. It'd be interesting to figure out all the cases where they are necessary. I think it's mainly when there's two float variables next to each other; integers, strings and arrays seem to be sufficiently delimited by their % $ () symbols, as are variables trailing functions. But maybe some floats up against functions would be misinterpreted too. As a general rule, I suppose, don't use semi-colons unless you get the wrong results without them?
@@8-bitshowandtell247: The behaviour would depend on how the expression parser is implemented. PRINT 2BPEEK(3)4 displays four results. I wrote a parser previously that when fed something like "2B" would tokenize "2" and "B" as separate expressions and then add them to the root parse-tree node (where there should only be one attached expression). BASIC probably stops parsing an expression when the next token isn't an "infix" operator. In the PRINT statement, it will keep trying to parse additional expressions, but in something like A=2B, it stops after "A=2" and then tries to parse "B" as a statement separator.
The epilepsy warning is a bit of an anachronism; those CYA exhortations/disclaimers only became a thing later.
Btw., I wonder if the C64 could have been sufficient to drive a 3D-printer with enough relevant software development.
Instead of using the BASIC routine to copy the BASIC program into $0801, would it be possible to use the following method?
1. Load the BASIC program from disk into regular BASIC memory, but don't run it.
2. Save the entire BASIC program from $0801 to the end as a binary block using TMP
3. Store that block anywhere on the cartridge, say $9000 on an 8K cart
4. Using the cart's bootloader code, move the BASIC block from $9000 to $0801 using a simple indexed loop
5. Then run the BASIC program via the "r(shift)U" method called by the cart's routine.
Maybe I'm way off, but at least I was thinking about it. heh
The channel's name is being truncated on the mobile RUclips - hence no chance to see if video uploaded to main or secondary channel ☹️
I'm thinking of renaming this 2nd channel to "Robin's Show And Tell" and covering whatever I'm interested in; would solve this name problem and also let me expand my scope a bit more.
DOOD!
Did you ever figure out why the whitespace was inserted into the basic line?
Also, the order of setup on the ROM "header" code (.elf's long lost ancestor) is confusing, I cannot figure out why basic setup would be done after the program is copied into RAM, the normal system bootup would have done that already... maybe a better alternative would be the feed the basic program in through the keyboard buffer? Probably would take longer though...
Cheers,
The extra spaces started the jokes. David wanted me to remove a space in that line, but just to trigger him I secretly added a bunch more spaces and noted it in my entry as "The extra space is to drive my friend David crazy." ( bunsen.itch.io/trick-shoot-ten-by-jim-happel ). Once the entry was published, I pointed it out to him and our other friends. : ) He posted "You win this round Happel". Little did I know he launched into this secret over-the-top packaging of my stoopid 10 line game, recruiting Jorie and our other friend David to help too! I got a copy of this in the mail, my daughter was there when I opened it, we were laughing so hard! Oh, and then he pushes it to Robin to take this to even a higher level of fun!