I remember long ago writing a small machine language routine that would flip the screen pointers around to make a C64 think it is a PET. It worked for many BASIC games but caution was needed as some PET games poked into various odd places. I also had something similar for the Vic20 but there was no way beating 22char Vic20 line limit. Those were the days!
Wow, I'm impressed you found that bug! I had forgotten about all the global and short variable names we had back in the day. It's so much easier to write readable code today.
I did a simple benchmark - It's 43.63s for the L-1023-R version, and 34.12s for the L-AX-1-R version (5k iterations). However, that was in a program with no other variables aside from "I", which was declared AFTER the O/L/AX/R variables. Spamming in two dozen fake variables ahead of the actual variables slowed it down to 56.95s and 51.92s respectively. Which is still faster, but the gap is closing. My understanding is that the variables are basically kept in a simple list or array and they're searched for when referenced by a simple linear search, thus the cost goes up for variables declared later in a program. The original version has two references, and the uh, more correct one has three...so eventually the cost of walking the variable list will overcome the cost of the four-character constant. I'd prefer the L-AX-1-R version (ideally it could be changed to L-AX-R in some manner), as that's more portable/easier to adjust than having to dig constants out of the code...
1:03 I always wondered if someone had ported this game. Now there needs to be a VIC-20 version ;-) 2:05 It’s completely fine to put your name on the port. I have to believe that Brian would like that you did this 17:10 Oh good catch Dr Bruce 26:15 O=L-AX-1-R is about 20% faster than O=L-1023-R
S is a random number, but in the original version, the random generator wasn't randomized - so it was getting the same potentially non-zero number each time. The C64 version truly randomizes now (line 90), so s in 520 is different each time. Adding the randomization in 90 "broke" the PET version.
Well you could have also not done this at all in which case there wouldn't even be a C64 port. Nice work Robin. I'm sure the original programmer would be proud.
Love the joystick addition, although having the cursor keys could also make it usable without, if implemented. Also, I think walls of a room should be visible in some way when you're next to it, so you don't have to waste a move in that direction. Adding a torch to be found, to see the entire room size when you enter one, would be an excellent addition, but attract beasts in the room immediately ^^ ...and some form of level/hit point min/max per type of beast, with the worst being farthest away (perhaps I play too much WoW :^) RUN does CLR, but you can start/continue with GOTO or CONTINUE if you hit a STOP command or press STOP Hard coding the top work fine on C64, but for PET, you'd have to some model recognition to lower the top of BASIC, or look at the value and if it's uneven in KB, do not lower more. I think only the VIC20 had a top pf BASIC that was at 7.5Kb :)
It looked like you can phase through the walls to avoid the monsters. Jump out and attack! I don't know if that is a reasonable approach because the monster may gain back hp's but it can save the monster chasing you when you are low.
I was literially fiddling with this the other day after wathching your first video, but figured I'd have to set quite a bit of time. Still, at least I can try it on real hardware now!
0:51 Seems like it would be straightforward to port a game from the PET to C64: move the End Of BASIC and the Screen RAM to match the 32K PET and fill the color memory with Green. Does the PET game have sound? 3:33 May the RNG be with you! …Nope. 5:05 Shouldn't a dragon be tougher than a spider? 11:36 It might be more obvious to «PRINT"{Green}";». Does your program work on all versions of the C64 Kernal w.r.t. the character color? You could fill the color RAM with «FOR I=1 TO 49:PRINT"{20 Spaces}";:NEXT:PRINT"{19 Spaces}{Left}{Insert}{Space}{Home}";». 13:07 "Fuzzing". 14:29 BASIC 7.0 and BASIC 3.5 use two bytes for some tokens. 15:49 It could be the case that a program would use CLR to wipe everything clean if you want to play again. There could be a GOTO 0 somewhere in the program. 16:07 You could do a «PRINT CHR$(142);» to make sure the C64 is in uppercase mode. 18:15 For this particular application, you could just leave the top of BASIC alone and use the $C000 RAM for the "shadow screen". 19:40 RND(-TI*RND(0)) would be even more scrambled. 20:45 It's not clear from the video editing if you ever actually press RETURN on the new line of BASIC. But you keep teasing it! 24:20 A big limitation of BASICs of the era is that all variables are global. 27:17 «60300 … GOSUB{next line}:RETURN» seems pointless. 27:28 You just got rid of the definition CR$=CHR$(13). 31:53 Interestingly, ABS(A>127) is twice as fast as -(A>127).
@@DaveF. - Indeed! BBC BASIC is probably the best (built-in/official) BASIC there is on the 8-bit machines. Not only is it loaded with features like the mid-late eighties machines, it's also faster. It's three times faster than the C128 in FAST mode! All this in 1981, too. Not-quite-yet-a-teenager-me would have been very jelly!
Ah.... Didn't realise the C64C has the colours on the keys, nor did I realise the PETSCII symbols are on the top of the keys rather than the side. Interesting.
17:06 Could you not store ramtop in a variable so you know what it was to start with? That way you would only be decreasing ramtop by the same amount, and you really need to setup ramtop before the main program loop. You might even want to restore ramtop back the way it was before you exit to basic. Great to see this old program getting a new port.
I wonder how hard it would be to port this to the VIC 20. I realize the 22 column screen would force a smaller dungeon, but it looks like the game should fit in a VIC 20 that has even just a 3K memory expansion. Not sure how much POKE-ing goes on in the BASIC program but even then, I would think it would be doable. Might be a fun challenge.
Sooner or later you're gonna review Vision Basic, it seems pretty amazing. Would be cool to see a port using that (without using the "built in" assembler). How many lines of code would it take vs BASIC 2.0? How much faster would it be? Either way, I sure hope you make a video about it.
I seem to remember a so-called dungeon in the basement in UBC's Buchanan building when I was there about 20 years ago. Is that a reference in the song?
Wow. The legibility of this basic program is extremely low with no spaces? Why multiple commands on a line? Is it memory related? I commend you for doing this without a real text editor, with simple "find" capability for instance.
As I understand it, the program listing itself (line numbers, spaces and all) is run directly by the basic interpreter. So it's not even just memory related, it affects speed too. I didn't know anything about the internals back in the day (still doesn't know very much), but I remember we found out that using 1,2,3 as line numbers instead of 10, 20, 30 would make programs run noticeably faster. At the cost of making it much harder to insert a line later on...
@@Mnnvint yes it's true, I experienced this too (sometimes I write BASIC programs...). It seems as the C64 BASIC interpreter not "skips" the non existing lines, but is running them one by one. Try to use a little program which prints the time at 1...10...100...1000 spaces between the lines, it should show some difference. IDK if other BASICs do the same, but remember that many BASICs of that time came from the same company - MICROSOFT ;-)
the line number is parsed while inputting and stored on binary in 2 bytes, so high or low line numbers don't matter there. Where they matter is when parsing a goto o gosub: the decimal literal is not parsed, but stored and you need convert the decimal literal to decimal (lots of x10 floating point) before performing goto/gosub so lower line numbers will help speed.
I was just wondering if it would make sense to compile it with Petspeed 64 which is a BASIC compiler to give this a significant speed boost. I've got a copy, but have never used it. The thought of writing code in non-functional BASIC seems as antiquated as coding in assembly. As an aside, in terms of C64 development, I came across a C compiler for the C64 a little while back which actually runs a full IDE and C64 in a browser. Can't find it now. I used to be able to code in C and was considering having a go. You might want to consider a video on it some day, if you haven't already.
Unrelated question, but I’m curious about the screen fulls of garbled text that sometimes display quickly when loading some games. Is there a reason for that (is it intentional) or is it just that they didn’t program in a way to keep it hidden?
I think some fastloaders did this, or it's the "decrunching" of some part of the program? My friend CREB (ex swapper for C64 software, now inactive) found his handle/name in one of those scrambled texts, thought it would be a cool name, and used it for years...
S=0... it seems like the smallest little errors cause the biggest problems. For me, in C programming, I have had more headaches with a misplaced semicolon than anything else I think. ;)
Hi Robin, on the topic of ports, as a kid I always wondered why some of the old Sierra games weren't available on the C64. I suspect it may have to do with available memory issues, but early titles like Kings Quest 1 and Space Quest 1 don't seem very resource heavy. Are these titles able to be ported to the C64? If so, what might a port look like for them? And if not, why?
Yeah, as far as I know the main problem is that even the earliest Sierra Quest games needed 128K of RAM. I'm sure ports could be done nowadays by supporting either REU or EasyFlash cartridges, but like the fan-made Prince of Persia C64 port it's a massive undertaking to do just for the love of it. I hope somebody eventually does it as those games might be the last few "killer apps" that the Apple II family has that never made it over to the C64.
Yeah, I thought it was stupid of Commodore to use a lower version of BASIC and slower disk I/O (serial and low-density only; never mind the slowness bug) for their otherwise upgraded computer! A sensible upgrade would have had at least as high of every feature as a lower version has. How was the BASIC in PET, their second computer line, but first to make it big in the market, higher than 1.0 anyway? Was the KIM-1 using anything higher than BASIC 1 at any point too?
@@Doug_in_NC There still remains confusion over the "naming" of the versions of BASIC. Of course BASIC 4 says it's BASIC 4, but I believe it's best to refer to "***" BASIC as "Original" BASIC, and "###" BASIC as "Upgraded" BASIC.
@@MattKasdorf what is on the C64 and VIC 20 is (I think) the same as PET BASIC V2. PET BASIC V4 added a load of disk handling commands that were removed to save money (there wasn’t a 1541 drive until a year after the VIC 20 came out) on the ‘home’ machines. Why the C16 had BASIC 3.5 and the C128 had BASIC 7 is anyone’s guess though
@@MattKasdorf: It's not _actual_ naming, and the original isn't actually _original,_ according to you? Why the quotes? Yes, 64's BASIC isn't as complete as PET 4. That's why all the wonky disk stuff that the PET 4000s don't have to deal with. Stupid downgrade!
@@Doug_in_NC: Thanks for your replies. But Nahh, why 128 has BASIC 7 is pretty obvious, actually. But why stop there if the 65 was protoed with BASIC 10?
I think you should document your changes in the code or another document describing the changes. I think when you add a constant, if you don't actually use a variable, document what that value is... 1023 is blah blah blah, 32765 is blah blah blah, 198 is blah blah blah.
I remember long ago writing a small machine language routine that would flip the screen pointers around to make a C64 think it is a PET. It worked for many BASIC games but caution was needed as some PET games poked into various odd places.
I also had something similar for the Vic20 but there was no way beating 22char Vic20 line limit.
Those were the days!
Thanks for this! So neat that you did this. I loved the c64 but never got around to porting it, so cool that u did !
41-year-old bug fixed, love it!
Wow, I'm impressed you found that bug! I had forgotten about all the global and short variable names we had back in the day. It's so much easier to write readable code today.
00:28 Temple of Apshai… I can remember standing in Radio Shack playing that to completion on a TRS-80. Fun times!
I did a simple benchmark - It's 43.63s for the L-1023-R version, and 34.12s for the L-AX-1-R version (5k iterations). However, that was in a program with no other variables aside from "I", which was declared AFTER the O/L/AX/R variables. Spamming in two dozen fake variables ahead of the actual variables slowed it down to 56.95s and 51.92s respectively. Which is still faster, but the gap is closing.
My understanding is that the variables are basically kept in a simple list or array and they're searched for when referenced by a simple linear search, thus the cost goes up for variables declared later in a program. The original version has two references, and the uh, more correct one has three...so eventually the cost of walking the variable list will overcome the cost of the four-character constant.
I'd prefer the L-AX-1-R version (ideally it could be changed to L-AX-R in some manner), as that's more portable/easier to adjust than having to dig constants out of the code...
1:03 I always wondered if someone had ported this game. Now there needs to be a VIC-20 version ;-)
2:05 It’s completely fine to put your name on the port. I have to believe that Brian would like that you did this
17:10 Oh good catch Dr Bruce
26:15 O=L-AX-1-R is about 20% faster than O=L-1023-R
A VIC-20 version would be interesting for sure!
@@8_Bit I might play with it. I’ve been on a VIC-20 thing the last few months. The screen dimensions will something to wrestle with
26:15 Every additional digit in a constant will execute another floating-point multiply-by-10, which is a slow operation on the C64.
@@csbruce makes sense
@@MichaelDoornbos …including the first digit, which is why "." is faster to parse than "0".
The first time I played this game, it stuck with me.. it was one of the reasons I wrote Trogue64.. I love those rogue-likes
Such a cool game dungeon. I played it on my commdore 4032 in 1982. wow, where is the time. I loved it.
S is a random number, but in the original version, the random generator wasn't randomized - so it was getting the same potentially non-zero number each time. The C64 version truly randomizes now (line 90), so s in 520 is different each time. Adding the randomization in 90 "broke" the PET version.
It does not graphically distinguish between a wall and unexplored fog-of-war. That's confusing.
BASIC and beauty in one sentence? That's funny 😄.
Just like D-Day, this will be forgotten by oblivious generations who want their myspace.
Thank you very much for the converting, and for every work you do with my FIRST LOVE C= 64 👍😍😘💗
“Dungeon” for the C64 40 years later. Talk about delayed wish fulfillment! Thank you so much!
Well you could have also not done this at all in which case there wouldn't even be a C64 port.
Nice work Robin. I'm sure the original programmer would be proud.
Hey thanks for this. I tired to get the original PET version to work on the MiSTer core but gave up. This works perfectly on the C64 core though
Love the joystick addition, although having the cursor keys could also make it usable without, if implemented.
Also, I think walls of a room should be visible in some way when you're next to it, so you don't have to waste a move in that direction.
Adding a torch to be found, to see the entire room size when you enter one, would be an excellent addition, but attract beasts in the room immediately ^^
...and some form of level/hit point min/max per type of beast, with the worst being farthest away (perhaps I play too much WoW :^)
RUN does CLR, but you can start/continue with GOTO or CONTINUE if you hit a STOP command or press STOP
Hard coding the top work fine on C64, but for PET, you'd have to some model recognition to lower the top of BASIC, or look at the value and if it's uneven in KB, do not lower more.
I think only the VIC20 had a top pf BASIC that was at 7.5Kb :)
It looked like you can phase through the walls to avoid the monsters. Jump out and attack! I don't know if that is a reasonable approach because the monster may gain back hp's but it can save the monster chasing you when you are low.
I was literially fiddling with this the other day after wathching your first video, but figured I'd have to set quite a bit of time. Still, at least I can try it on real hardware now!
Hi Robin, this needs a Csdb release. ! ( and a proper crack ) to always kill spiders, snakes and dragons. 😜
0:51 Seems like it would be straightforward to port a game from the PET to C64: move the End Of BASIC and the Screen RAM to match the 32K PET and fill the color memory with Green. Does the PET game have sound?
3:33 May the RNG be with you! …Nope.
5:05 Shouldn't a dragon be tougher than a spider?
11:36 It might be more obvious to «PRINT"{Green}";». Does your program work on all versions of the C64 Kernal w.r.t. the character color? You could fill the color RAM with «FOR I=1 TO 49:PRINT"{20 Spaces}";:NEXT:PRINT"{19 Spaces}{Left}{Insert}{Space}{Home}";».
13:07 "Fuzzing".
14:29 BASIC 7.0 and BASIC 3.5 use two bytes for some tokens.
15:49 It could be the case that a program would use CLR to wipe everything clean if you want to play again. There could be a GOTO 0 somewhere in the program.
16:07 You could do a «PRINT CHR$(142);» to make sure the C64 is in
uppercase mode.
18:15 For this particular application, you could just leave the top of BASIC alone and use the $C000 RAM for the "shadow screen".
19:40 RND(-TI*RND(0)) would be even more scrambled.
20:45 It's not clear from the video editing if you ever actually press RETURN on the new line of BASIC. But you keep teasing it!
24:20 A big limitation of BASICs of the era is that all variables are global.
27:17 «60300 … GOSUB{next line}:RETURN» seems pointless.
27:28 You just got rid of the definition CR$=CHR$(13).
31:53 Interestingly, ABS(A>127) is twice as fast as -(A>127).
"A big limitation of BASICs of the era is that all variables are global" - not on a BBC micro.
@@DaveF. - Indeed! BBC BASIC is probably the best (built-in/official) BASIC there is on the 8-bit machines. Not only is it loaded with features like the mid-late eighties machines, it's also faster. It's three times faster than the C128 in FAST mode! All this in 1981, too. Not-quite-yet-a-teenager-me would have been very jelly!
@@LordRenegrade Did we mention you write assembly code inline with the basic too?
@@DaveF. - We forgot to mention that, until you brought it up. But we also forgot native support for hexadecimal numbers! It really was a great BASIC.
Ah.... Didn't realise the C64C has the colours on the keys, nor did I realise the PETSCII symbols are on the top of the keys rather than the side. Interesting.
Huh, this reminds me of The Sword of Fargoal. Is it the direct precursor?
17:06 Could you not store ramtop in a variable so you know what it was to start with? That way you would only be decreasing ramtop by the same amount, and you really need to setup ramtop before the main program loop. You might even want to restore ramtop back the way it was before you exit to basic. Great to see this old program getting a new port.
Great videos!
Add in your description the reference to The Complete Commodore Inner Space Anthology by Karl Hildon
I wonder how hard it would be to port this to the VIC 20. I realize the 22 column screen would force a smaller dungeon, but it looks like the game should fit in a VIC 20 that has even just a 3K memory expansion. Not sure how much POKE-ing goes on in the BASIC program but even then, I would think it would be doable. Might be a fun challenge.
Sooner or later you're gonna review Vision Basic, it seems pretty amazing. Would be cool to see a port using that (without using the "built in" assembler). How many lines of code would it take vs BASIC 2.0? How much faster would it be? Either way, I sure hope you make a video about it.
I seem to remember a so-called dungeon in the basement in UBC's Buchanan building when I was there about 20 years ago. Is that a reference in the song?
Wow. The legibility of this basic program is extremely low with no spaces? Why multiple commands on a line? Is it memory related? I commend you for doing this without a real text editor, with simple "find" capability for instance.
As I understand it, the program listing itself (line numbers, spaces and all) is run directly by the basic interpreter. So it's not even just memory related, it affects speed too. I didn't know anything about the internals back in the day (still doesn't know very much), but I remember we found out that using 1,2,3 as line numbers instead of 10, 20, 30 would make programs run noticeably faster. At the cost of making it much harder to insert a line later on...
@@Mnnvint yes it's true, I experienced this too (sometimes I write BASIC programs...). It seems as the C64 BASIC interpreter not "skips" the non existing lines, but is running them one by one. Try to use a little program which prints the time at 1...10...100...1000 spaces between the lines, it should show some difference. IDK if other BASICs do the same, but remember that many BASICs of that time came from the same company - MICROSOFT ;-)
the line number is parsed while inputting and stored on binary in 2 bytes, so high or low line numbers don't matter there. Where they matter is when parsing a goto o gosub: the decimal literal is not parsed, but stored and you need convert the decimal literal to decimal (lots of x10 floating point) before performing goto/gosub so lower line numbers will help speed.
@@ideegeniali Goodness me.... So you even have to work the basic listing for speed. Fantastic. Thanks!
I was just wondering if it would make sense to compile it with Petspeed 64 which is a BASIC compiler to give this a significant speed boost.
I've got a copy, but have never used it. The thought of writing code in non-functional BASIC seems as antiquated as coding in assembly.
As an aside, in terms of C64 development, I came across a C compiler for the C64 a little while back which actually runs a full IDE and C64 in a browser. Can't find it now.
I used to be able to code in C and was considering having a go. You might want to consider a video on it some day, if you haven't already.
Nice, that's almost a roguelike. 1979!
Unrelated question, but I’m curious about the screen fulls of garbled text that sometimes display quickly when loading some games. Is there a reason for that (is it intentional) or is it just that they didn’t program in a way to keep it hidden?
I think some fastloaders did this, or it's the "decrunching" of some part of the program? My friend CREB (ex swapper for C64 software, now inactive) found his handle/name in one of those scrambled texts, thought it would be a cool name, and used it for years...
I REALLY LOVE C64 👍🥂🎩
S=0... it seems like the smallest little errors cause the biggest problems. For me, in C programming, I have had more headaches with a misplaced semicolon than anything else I think. ;)
Hi Robin, on the topic of ports, as a kid I always wondered why some of the old Sierra games weren't available on the C64. I suspect it may have to do with available memory issues, but early titles like Kings Quest 1 and Space Quest 1 don't seem very resource heavy. Are these titles able to be ported to the C64? If so, what might a port look like for them? And if not, why?
Yeah, as far as I know the main problem is that even the earliest Sierra Quest games needed 128K of RAM. I'm sure ports could be done nowadays by supporting either REU or EasyFlash cartridges, but like the fan-made Prince of Persia C64 port it's a massive undertaking to do just for the love of it. I hope somebody eventually does it as those games might be the last few "killer apps" that the Apple II family has that never made it over to the C64.
Should looking for upper and lower case checking be done?
NICE
Cool! :-)
Yeah, I thought it was stupid of Commodore to use a lower version of BASIC and slower disk I/O (serial and low-density only; never mind the slowness bug) for their otherwise upgraded computer! A sensible upgrade would have had at least as high of every feature as a lower version has.
How was the BASIC in PET, their second computer line, but first to make it big in the market, higher than 1.0 anyway? Was the KIM-1 using anything higher than BASIC 1 at any point too?
There were 3 versions of BASIC for the PET V1, V2 on the 2000 series and V4 which was released on the 4000 series.
@@Doug_in_NC There still remains confusion over the "naming" of the versions of BASIC. Of course BASIC 4 says it's BASIC 4, but I believe it's best to refer to "***" BASIC as "Original" BASIC, and "###" BASIC as "Upgraded" BASIC.
@@MattKasdorf what is on the C64 and VIC 20 is (I think) the same as PET BASIC V2. PET BASIC V4 added a load of disk handling commands that were removed to save money (there wasn’t a 1541 drive until a year after the VIC 20 came out) on the ‘home’ machines. Why the C16 had BASIC 3.5 and the C128 had BASIC 7 is anyone’s guess though
@@MattKasdorf: It's not _actual_ naming, and the original isn't actually _original,_ according to you? Why the quotes?
Yes, 64's BASIC isn't as complete as PET 4. That's why all the wonky disk stuff that the PET 4000s don't have to deal with. Stupid downgrade!
@@Doug_in_NC: Thanks for your replies. But Nahh, why 128 has BASIC 7 is pretty obvious, actually. But why stop there if the 65 was protoed with BASIC 10?
I think you should document your changes in the code or another document describing the changes. I think when you add a constant, if you don't actually use a variable, document what that value is... 1023 is blah blah blah, 32765 is blah blah blah, 198 is blah blah blah.
👍
Should have been pretty easy, the platforms are pretty similar and the basic too.
Is the code available in txt format please anyone x
The petcat utility, included with the VICE emulator, will convert from tokenized Commodore BASIC to txt format.
@@8_Bit thanks I will have a look
C64 rulez
Exactly.
MSX rules!
Haha, "PEE"!
He's obviously still a boy at heart.
Hehe! That's OK, because I think a lot of us are, or girls (depending...).
Compsit? What?
en.wikipedia.org/wiki/Composite_video
"And there we drop out to BASIC." Ummmm... you were already and still _in_ BASIC during the game.
You "drop out" when a program stops running.
@@theannoyedmrfloyd3998: Not from a BASIC program "to BASIC."
This a trump guy or no?