If you took a single visual basic class, you would be jumping up and down like a 3 year old after getting a lollypop!. I'm 55, and I learned basic on the commodore, and transitioned into visual basic and visual C++, and it was much easier for me to learn than those who had no previous basic experience (I took the classes in my early 40's).
I love the motivational pep talk discussing 'It's not bad if your code is jank, if you set your goals and finish it'. Makes me feel good about finishing my NES project. Also love the sections comparing and outlining the difference between getting your game scaffolding/mechanics built, vs polishing and tweaking till it's at 100%
Wow! this brings back memories! I tried a "space invader" game in BASIC on my TRS-80, using strings of text characters (arms up, arms down, etc). As I added each feature (gun control, firing a missile), the speed slowed to "chunk - chunk - chunk." Never finished the game - and got a C128 to have real control of visuals. Thanks for the fun.
I wrote an animated 4 player volleyball game in Atari Basic W/O any machine language code. Like you, I used strings to move the sprites vertically in memory. Although I had some writer who wrote reviews of many Atari video games in a book, he/she/it for some unknown reason, compared my game written in basic to PROFESSIONAL written games written in assembly. Considering I was moving/animating the players (not only could they move left & right but you could hold down the joystick button and press up and the player would spike the ball with animation (its legs and arms moved when it jumped), I thought it was a decent game for something written in Basic. You can Google "Softside Volleyball Bradley" and take a look using the Atari emulator Altirra.
I wrote many assembly utilities which could be called from BASIC from when I worked for MECC. I still have thousands of pages of printouts of these utilities to manipulate graphics, including sprites and do other things. I'd love to share these somehow
At 28:49 in the video, you show the fire1 function. The CMP #0 isn't needed because the previous AND instruction already sets or clears the Zero flag. LDA also sets/clears the Zero flag. One of the features I liked about 6502 was the way instructions would automatically set or clear status flags according to the data - only rarely needing a CMP instruction.
That "Stella at 20" series can also be found on UA-cam. Well worth your time (if you're interested in that sort of thing). [edit: Here's the one where David Crane talks about Pitfall (among other things) and how he was able to squeeze 256 screens into only 4k of ROM space: ua-cam.com/video/h4rU9BjLOE0/v-deo.html The part in question starts at 15:39.]
27:05 that's a common feature of the Commodore 64. It's because most lines are pulled up by resistors, so they quickly settle on high (1) if they aren't driven low (0).
this was amazing to hear discussion on how it was written and what implementation decisions were made. the most important is acknowledging mistakes and how you would do it differently in the future.
This is a great little game! I really love the aesthetics and the gameplay, and the idea of a two player game in friendly rivalry (including gentle shoving) and coop. A great study in minimalism. Well done!
Thank you so much for this amazing video, guys! I didn't even realize that coding a game in assembler on the C64 was still on my bucket list until I watched this. I do know it is on there now...
Haha I played The Last Ninja back in the 80's I even wrote a tip for the game that was published in Commodore Magazine, for which I was paid (if I remember correctly) $5.00
Thats a really good use of VICE, and sums up one of the major reason why "we" always needed a faster machine . I have programmed extremely fast web pages on really slow machines to help defeat that need .. but anyway .. .. at least the code is commented, thats probably the most "left out" part of any code, and shows good programming practices, even when that code itself is less readable. btw thanx for the MSX tribute the in the assembler listing, always nice to see ;)
My favourite way of programming is to write a bunch of comments describing what each section is going to do, and then put the actual code in between them.
Would love to see you stream creating a new ML game for c64 on your channel. You’re subscribers could vote on various features decisions, and the content would be a great tutorial for others.
Great video. It's always inspiring to see someone actually finish a game. I want to be like Darren and actually finish something for once. Loved the banter too.
Index: 0:00 Intro 2:01 Darren takes the wheel 4:27 We play a game of 1nvader 12:20 Darren’s BASIC machine language 16:40 BASIC prototype 22:15 First machine language version 36:08 The final version of the code 42:00 Linear-Feedback Shift Registers 44:50 The Awful Scoring Routine 49:00 Twinkle Routine Errata: I meant to say "Megamania" not "Megalomania"!
I still have a yellowing piece of paper with designs for a game I wanted to make on my C64 over 30 years ago. Someday I will make it. LOL. I put the paper in plastic to preserve it for posterity. I also have a space combat game I designed when I was around 14 years old around 1979 or 1980, before there was a C64. I had the TRS80 in mind at the time. Never did make it either, didn't even own a computer at the time, so I wrote out the code for it on many pieces of paper. :) I found when I made my Deluxe Pacman 2 game for the PC, the more planning I did ahead of time, the easier the actual coding went and the fewer bugs I ran into. Love your banter, brings back memories for me.
Nice. @34:46 Yes, you can, but c64 is probably in your heart. I started learning Basic (sinclair zx spec and C64) and ML (c64) at age of 8. Wrote car racing game (text based like ascii), wrote my own fonts, playing with sprites (always draw them first on the paper, "pixel by pixel"), wrote text adventure game... Good memories. During the time learned a lot: different programming languages like delphy, c#, c++, python, php, working with databases... I noticed what's the difference between "kids" today and old school programmers: they usually code in paradigm and do not understand what is "under the hood", so I saw people write good code but horrible database queries, structure, indexes and vice versa etc. After +30 years I am still learning. Have fun.
This was interesting because I recently did the same thing- realize my childhood dream of writing a C64 game. My game is Flappy Bird. I can vouch for a lot of the advice given here. I would add that it behooves you to learn to think in hex because lots of strange base addresses in decimal are round numbers in hex.
Dude, that game got some name like you wouldn't believe someone's hobby project for C=64 ever could - I heard about it first long before I learned about it in the retro community :D
Awesome video guys! Coding is like painting, its all very personal to the person creating the code so don't worry about what it looks like as long as it works the way you envisioned it.
Fun to watch! I remember when I just had an idea (to do some fun bootloader kinda hoax of thing for my friend) and that time I programmed mostly in Pascal on the Amiga 500 (why!??! long story)... and tried to make it as short as possible but I think compiled it was about 12k the shortest I could make it... and that was way to big. I wanted to make the best replication of a TV's static noise when your antenna was out/or no channel/data on the frequency... What was good in Pascal was that I did have a random number generator and I could (or had to) make it OS friendly. But it was slow and did not look or sound like the "real thing". Ah well time to go to 68k assembler, found a really fast, quick dirty random number (I was only after randomizing 1 bit), fully overscan screen with the static noise (not OS friendly at all) and it was really really fast and looked and sounded exactly like what TV looks like with just static antenna noise... In the end (even though hitting the hardware) I made it (a bit more) OS friendly and it came into 682 bytes if I remember correctly... Never actually did the actual "prank/hoax" on him though I just had to show him the amazing TV static noise I created :-) I remember I added a couple of funny things later like when you did a reset It booted from a RAD drive and played a animation with some scary music... man the late 80's :-) Anyway I started (after learning BASIC on the C64) coding with a machine code monitor, It was really hard to do anything really amazing (I'm a normal dude) so on the C64 I just did some snippets in machine code on the C64... Got an C64 assembler a bit to late, bu sure I did realize my mistake... That is how you code machine code and not in a bloody machine code monitor program :-)
Your comments about learning to program on a C64 in the '80s.... Hours and hours in my Uncle Jeff's room as a kid when he was at work. I wish I'd had any information at all about Assembly though! Aside from sprites and sound demos peeking and poking to various addresses found in the Programmer's Reference, I had no idea what was where, and what did what. It all seemed like some Dark Art, particularly when you'd try to list a game and all it said was 10 SYS and some 5 digit number.... Now with Vice and other emulators, it'd be fun to attempt a small project to get my feet wet. Also, love the the shot of the two of you talking about and holding the C64 mini(?) at the beginning makes you look like total Giants! Hehe. Nice.
This is the same reply I wanted to make. There I was programming almost this exact game on my C64 as a 14 year old kid in BASIC and it ran so slow. I wanted to take my program ability to the next level but there was no place to turn to. The programmers guide was woefully inadequate. No internet. Just a few issues of compute magazine lying around... Wish I could take videos like this back in time with me to 1984.
Well done both of you! I am finally starting to learn ML on 64 in my mid 50. I lost my 64 tragically (together with my vic20 😢) 20 years ago. So I use a the64 now.
Being in the same age group as you, I dusted off my old Merlin assembler I bought back in the 80's since I got inspired by Robin's recent ML videos. Looking forward to some fun coding to keep my brain turning to a mush. heh
This was great! Thank you both for this interesting and elaborate investigation of 1nvader and the machine code behind it. It was inspirational. I liked the War of the Hands in there too.
What a great video. I am pretty much in the same situation Darren was. I have coded tons of finished games in basic on the C64 and Amiga using Blitz basic but making that jump to machine language has always been just that little bit too difficult for me. Your videos are helping me make the first tiny steps into understanding what is going on.
Gary James the thing that got me going with assembly was the game Human Resource Machine. In some ways it’s actually harder than 6502 assembly, such as no index registers and no compares/flags register. On the flip side, it’s pure input/process/output and you get to focus on just the assembly programming itself- no system components to learn to interact with, no vblank timing, no IRQ handling etc.
27:00 The term is "active low", in that a signal is asserted when it is in the low state (i.e. 0), as opposed to "active high" which is perhaps what you would tend to think in terms of. If its easier for you to work with "active high" signals, you can always load in the button states and then complement them (if there is no dedicated complement instruction then XOR with all 1's/255/0xff), so any idle signals which are high will become 0's, and active signals then become 1's.
Love my journey of making BASIC games. Started off just playing these games showing characters and keep pressing keyboard and then I got to a GWBASIC console and thought what is this? Remembered seeing the word BASICA in my dads bookcase full of gardening, science books. Pulled out that book and saw similar keywords and decided to type out commands and some of the BASICA commands worked in GWBASIC. It was fun seeing how other people made games and I decided to go to the library to see if I could find more books on BASIC. Tried to type in similar BASIC commands for games that only worked on Z80 and sometimes it would work on my machine and sometimes not lol. The main thing was trying to understand what each BASIC command did. I wanted to later understand string manipulation and do some fancy animations. Was fun POKEing in the memory and then moving my mouse, joystick and seeing numbers change lol. Good times....
I’ve been writing code since 1982 and every time I have a lot of self criticism and learning moment. If not you’d be doing the same thing over and over again. Engineering is basically an interactive process, of improvements on improvements. Sure writing more robust code is easier now, as you know the potential pitfalls and you have algorithms in the back of your mind to do the input validation. But efficiency is something (especially with very new projects) that comes gradually.
Brilliant and insightful. And sure code can be optimized, but that shouldn’t be your goal - unless it bogs your program down. Getting finished is more important. Perfection is the demon got succes. And I laughed about the 46:30 remark about not calculating the score every frame. I recently made a shooter in Unity. First game in oh, 26 years I guess. And my colleague (a junior age 24) looked at the code and asked me: Why do you have copies of the variables with the old value of number of bullets, number of lives... And when I programmed it, I knew modern PCs have no problem updating it 60 times a second but my VIC20 and C64 wisdom taught me, to only change things when they need to be changed. A compare is often faster than calculating and updating the screen memory. The ‘kid’ looked at me as if I were a fossil. That we had to be efficient like that back in the day. The great thing though, was that this “junior” (who develops very quickly now that he’s onsite from India), was genuinely interested in best practices in coding. In college you hardly learn proper coding. You are taught the mechanics and not the real world problems and best practices. So he asked a lot to me about some of his own projects. Especially since he hears me cuss a lot about the shit others have created that is highly insecure and/or not configurable. I don’t care about small and efficient code that much, secure, flexible and maintainable are today’s ultimate objectives. And this ‘kid’ learns so quickly that he now even corrects me when I missed something during an audit or something I coded myself. It’s good to be challenged and kept sharp and focused.
You guys are my people. I was a microcomputer kid born in the 70s. I had the Timex Sinclair, trs-80 MC10, ADAM and an Atari 800XL. I always wanted to learn machine language.
That's very ambitious! Typically I'd suggest starting by making a game for the Apple II, Atari 800, C64 or similar because they're a lot more forgiving than the 2600. But at least there are a lot of resources for 2600 programming now too. Good luck!
@@8_Bit You're right, it will be very challenging, but there is something about the way Space Invaders has to manipulate the registers of the two 8-bit sprites that is super appealing to me. The hardware is oddly well suited for it despite its incredible limitations. Space Invaders on Atari 800 and C64 would be easier with character graphics (though smooth scrolling is more of a difficult on the C64), and the Apple II would be somewhat more challenging with its weird bitmap, but the constraints and simplicity of the Atari 2600 is the most alluring to me.
36:52 I know what you mean when it comes to the little things taking a lot of time. have you heard of the 90-90 principle of software? It says the first 90% of the software takes 90% of the time. The last 10% of the software takes the other 90% of the time ;) thanks so much for this video (and all of your videos). I just re-watched it a few times today and it’s one of my favorites on UA-cam.
29:45 "Machine language is so fast, you don't need to worry about it!" Unless it's something like a graphics decompression routine that needs to be executed tens of thousands of times, then badly written code adds up. Hello, Maka-maka for the Super Famicom!
Found my old c64 in my parents attic probably had not used it since 1989 90. Booted it up was like I had used it yesterday. Playing hardball. Kung fu. Blue max. I was 13 again for an afternoon. Even had def leppard playing in background.
Really enjoyed that! One basic concept that I still don't understand is vsync and statements like "we live in the vertical blank.". Have you gone into this in past videos?
Vsync is short for "vertical sync" and it's what happens after each frame is drawn; it happens automatically 50 times a second on PAL machines, and 60 times a second on NTSC. To animate smoothly and without any visual tearing on screen, games typically wait for the vertical blank to start moving sprites, scrolling the screen, etc. Darren's game does a very simple implementation of this, by waiting for raster line $ff by polling register $d012. I explain this a bit in this linked episode but should do a more focused explanation sometime: ua-cam.com/video/05vlobA3JeU/v-deo.html The "we live in the vertical blank" quote is from a podcast Darren and I listen to called "Into The Vertical Blank".
@@8_Bit Wow! I didn't expect a full explanation right now. Thank you for taking the time to do that. Congrats to Darren on finishing his first game. I have a similar task sitting in my bucket list.
I wish someone made a sort of documentary or such about early 8bit game ports, i assume many of them were pretty complete remakes, but was there some sort of cross compiling going on, was the same z80 / 6502 code at all usable across platforms with the same cpu's, what sort of tools did they have back then for transfering data between platforms, doing graphics conversions and such.
I'd be very interested in that too. Ideally it would involve the participation of a game developer from the 1980s who did that kind of work. It won't be quite the same, but I do plan to make videos about the C64 games I developed natively in the '90s and '00s.
I'm guessing that ports between different platforms often would use same codebase if they try to implement same game mechanics and the platform doesn't warrant a complete rewrite. Of course there were some games that were designed to be highly portable by the design, usually adventure games that implemented the game in cross-platform virtual machine, such as Z-engine (which was used with Zork), then simply port the virtual machine to each platform and they can easily use same game code and easily convert graphics, etc. between these platforms. Sierra and Lucasarts games come to mind - Leisure Suit Larry 1, C-64, PC or Amiga 500, it's very much the exact same game, and differences between these platforms aren't small. I think designers and teams pretty much used to write their own tools for stuff like graphics conversions and such. But I'm by no means an expert - just thought I'd chip in.
@@kke oh man, I was so sure I'd have seen a C-64 version - not that complex it couldn't quite well have been done either - the 1st LSL at least, the 2nd was already miles ahead of it technically. My bad, but the same kind implementation of kinda virtual machine for certain type games was there anyway - and I bet Zork & other Z-engine games are not the only ones :) Sorry for the poo-poo I made 💩 Edit: and it's obvious that you already know about the technology I was talking of. Lucasart (ScummVM?) games on C64? Sure I can't be wrong that they did exist? 😬
I tried to create the same game on my Atari XL.. when I finally managed to get a sprite moving on screen the code was such a mess I had no idea how to proceed. so I have to start over.. but now at least I know how the sprite system works and it is a lot more complicated than the C64. I swear there will be an Atari 8bit version of it someday :)
now FEET... i dont think i can handle it. go back to hands only please :-P super happy Darrens game is actually released now. it was incredible watching it come to life. i can personally attest as simple as it is its incredibly addicting!
Great video, guys! And Darren, congratulations! Regardless or any perceived shortcoming this is an awesome accomplishment. This video reminded me so much of me typing in and troubleshooting errors (due to my typos) the BASIC game *Tank* *vs* *UFO* from the back of the VIC 20 User's Manual. I always wanted to learn Assembly, bought the Compute magazine books (which I still have, bit.ly/30CvWiH) when I was very young but I needed proper guidance and never did accomplish anything more than cycling all the screen and border colours, something I was quite proud of at the time. So, kudos to you on completing *1nvader* - well done!
Memory unlocked, I also typed in Tank vs UFO on my VIC. :) Nice to see the prototype in BASIC first. These days, strange as it sounds, I tend to prototype complicated stuff in python first, prior to writing it in 6502 assembly. Sometimes the python generates the assembly.
Noticed only one bullet from each ship is displayed at a time press fire whilst last bullet still on screen removes that bullet meaning you use a single array to keep track of the bullets position. This could have been done in B.A.S.I.C and run just as well as your MC version since no multi dimensional arrays seem to have been used in this program for anything.
On the Atari (before it was re-labled the 2600) the Space Invaders had a "double shot" mode that I think was undocumented. You hold down one of the console switches (I don't remember which) when booting the cartridge, and it lets you have two bullets.
This is really cool stuff for someone who lived through those great C-64 and arcade game times and all other early home computers. That's a Commodore 128 though on the screen, not C-64. ;-)
The biggest software publishing houses of the 80s, Atarisoft, Access, Epyx, System 3, thalamus , accolade, Cinemaware, Activision all had modern (for the times) development tools to help them build their elaborate games, plus they had teams of people dividing up the work.....
Darren, since this is a rather easy gameplay and also features a cooperative mode for two players, could you add a kiddo-feature that basically slows don gameplay dramatically? Not the whole game though, but in such a way that the enemy movements are remarkebly slower, and the players movements are slightly slower... maybe less enemies invading at the same time, I guess you get it.
I learned BASIC as a kid then C++ Builder at secondary school then forgot almost everything I learned for about 20 years. Now as my kid got interested in programming I thought that I could learn python to help him learning and to have some fun with Raspberry Pi. I found python and modern languages a bit too frustrating for me and driven by the nostalgia I started to learn C64 machine language which I couldn't learn as a kid. It seems much more fun: learning the machine first then controlling it much more directly than on modern environments where everything is done by using libraries and dependencies.
You call this a game!?! JK guys I can't wait to get where you are if I get where you are. I have just started coding and can write Hello World. Finally seeing how someone struggled and talked about the process is wonderful. So many videos out there by people who come across as expert but this is the only one where I can really identify with you. The noob and the expert talking about the noobs project. I really hope you do more of these because I love it. Good jobs on the game and this video.
The REAL Computer Game is writing the code. Totally open ended - with a powerful surge of good-feeling hormones when it works. No one has to keep score. Success IS the score.
Here is a question, as you created the game, how did you save and load the game during the process? Where did you store it in memory? After the EOB and before SOV? Or did you just overwrite the basic memory location? Using the S and L of supermon can be subject to unexpected behavior..
I could never figure out assembly code. An editor like this might had helped. But I couldn't figure out numbers more than 255 on how to combine them and how do compares.
we now have much better tools, use an IDE for C64 development, we even have debuggers. I wrote a simple game in C64 assembler this week by coincidence. Disclaimer: I wrote some assembler code in the 80's on C64 & Amiga 500 on the bare metal (did have the final cartridge III on the C64 which was awesome).
Unfortunately I never had a C64 as a kid and the two computers I did have access to-VIC-20 and Apple IIe-were both far too slow for games written in Basic to be meaningfully playable. I made dozens of games in Basic on the VIC-20 back in the day, but the only way most of them would be considered playable by modern standards would be that "warp mode" in an emulator.
If you took a single visual basic class, you would be jumping up and down like a 3 year old after getting a lollypop!. I'm 55, and I learned basic on the commodore, and transitioned into visual basic and visual C++, and it was much easier for me to learn than those who had no previous basic experience (I took the classes in my early 40's).
I love the motivational pep talk discussing 'It's not bad if your code is jank, if you set your goals and finish it'. Makes me feel good about finishing my NES project.
Also love the sections comparing and outlining the difference between getting your game scaffolding/mechanics built, vs polishing and tweaking till it's at 100%
Yep, the 80/20 rules. ;)
Dam, I've messed around with programming for NES before. Props for following through on that.
Thoroughly enjoyed both the code review and the banter, fellas!
I wish you two were my teachers during my high school years in the 1980's.
They were probably your classmates.
Maybe if you keep asking, you too could be invited down into that basement.... good luck.
This is such a good video! As an aspiring newbie-6502-game-coder, I learned a tonne from your conversation. Please do this again!!
I have a large number of utilities for the C64 written in assembly. I'd love to digitize and share the code for these
That story of Darren making BASIC "games" that consist entirely of a title screen is uncomfortably relatable.
I think I went a bit red faced just now...
Wow! this brings back memories! I tried a "space invader" game in BASIC on my TRS-80, using strings of text characters (arms up, arms down, etc). As I added each feature (gun control, firing a missile), the speed slowed to "chunk - chunk - chunk." Never finished the game - and got a C128 to have real control of visuals. Thanks for the fun.
I wrote an animated 4 player volleyball game in Atari Basic W/O any machine language code. Like you, I used strings to move the sprites vertically in memory. Although I had some writer who wrote reviews of many Atari video games in a book, he/she/it for some unknown reason, compared my game written in basic to PROFESSIONAL written games written in assembly. Considering I was moving/animating the players (not only could they move left & right but you could hold down the joystick button and press up and the player would spike the ball with animation (its legs and arms moved when it jumped), I thought it was a decent game for something written in Basic. You can Google "Softside Volleyball Bradley" and take a look using the Atari emulator Altirra.
I wrote many assembly utilities which could be called from BASIC from when I worked for MECC. I still have thousands of pages of printouts of these utilities to manipulate graphics, including sprites and do other things. I'd love to share these somehow
If possible get the the printouts scanned and maybe uploaded somewhere
At 28:49 in the video, you show the fire1 function. The CMP #0 isn't needed because the previous AND instruction already sets or clears the Zero flag.
LDA also sets/clears the Zero flag. One of the features I liked about 6502 was the way instructions would automatically set or clear status flags according to the data - only rarely needing a CMP instruction.
That "Stella at 20" series can also be found on UA-cam. Well worth your time (if you're interested in that sort of thing).
[edit: Here's the one where David Crane talks about Pitfall (among other things) and how he was able to squeeze 256 screens into only 4k of ROM space: ua-cam.com/video/h4rU9BjLOE0/v-deo.html The part in question starts at 15:39.]
An interview show where you only see their hands! That's brilliant. Thanks Robin and Darren!
Does double duty as footage for a _VERY_ niche retro-computing hand-fetish channel
27:05 that's a common feature of the Commodore 64. It's because most lines are pulled up by resistors, so they quickly settle on high (1) if they aren't driven low (0).
this was amazing to hear discussion on how it was written and what implementation decisions were made. the most important is acknowledging mistakes and how you would do it differently in the future.
This is a great little game! I really love the aesthetics and the gameplay, and the idea of a two player game in friendly rivalry (including gentle shoving) and coop. A great study in minimalism. Well done!
You know the sequel has to be named 1NVADER2, right?
And then 1NVAD3R, and then 1NV4DER...
@@8_Bit And then 1NVADER5! heh.
Genius
Thank you so much for this amazing video, guys! I didn't even realize that coding a game in assembler on the C64 was still on my bucket list until I watched this. I do know it is on there now...
Haha I played The Last Ninja back in the 80's I even wrote a tip for the game that was published in Commodore Magazine, for which I was paid (if I remember correctly) $5.00
Why not turn the bug into a feature and make it into a single super shot after so many points?
Thats a really good use of VICE, and sums up one of the major reason why "we" always needed a faster machine . I have programmed extremely fast web pages on really slow machines to help defeat that need .. but anyway ..
.. at least the code is commented, thats probably the most "left out" part of any code, and shows good programming practices, even when that code itself is less readable. btw thanx for the MSX tribute the in the assembler listing, always nice to see ;)
My favourite way of programming is to write a bunch of comments describing what each section is going to do, and then put the actual code in between them.
That was really great thanks, the student/teacher relationship in the video is a joy to watch.
Would love to see you stream creating a new ML game for c64 on your channel. You’re subscribers could vote on various features decisions, and the content would be a great tutorial for others.
Great video. It's always inspiring to see someone actually finish a game. I want to be like Darren and actually finish something for once. Loved the banter too.
Index:
0:00 Intro
2:01 Darren takes the wheel
4:27 We play a game of 1nvader
12:20 Darren’s BASIC machine language
16:40 BASIC prototype
22:15 First machine language version
36:08 The final version of the code
42:00 Linear-Feedback Shift Registers
44:50 The Awful Scoring Routine
49:00 Twinkle Routine
Errata: I meant to say "Megamania" not "Megalomania"!
I still have a yellowing piece of paper with designs for a game I wanted to make on my C64 over 30 years ago. Someday I will make it. LOL. I put the paper in plastic to preserve it for posterity. I also have a space combat game I designed when I was around 14 years old around 1979 or 1980, before there was a C64. I had the TRS80 in mind at the time. Never did make it either, didn't even own a computer at the time, so I wrote out the code for it on many pieces of paper. :)
I found when I made my Deluxe Pacman 2 game for the PC, the more planning I did ahead of time, the easier the actual coding went and the fewer bugs I ran into.
Love your banter, brings back memories for me.
Nice.
@34:46 Yes, you can, but c64 is probably in your heart.
I started learning Basic (sinclair zx spec and C64) and ML (c64) at age of 8.
Wrote car racing game (text based like ascii), wrote my own fonts, playing with sprites (always draw them first on the paper, "pixel by pixel"), wrote text adventure game... Good memories.
During the time learned a lot: different programming languages like delphy, c#, c++, python, php, working with databases...
I noticed what's the difference between "kids" today and old school programmers: they usually code in paradigm and do not understand what is "under the hood", so I saw people write good code but horrible database queries, structure, indexes and vice versa etc.
After +30 years I am still learning.
Have fun.
This was interesting because I recently did the same thing- realize my childhood dream of writing a C64 game. My game is Flappy Bird. I can vouch for a lot of the advice given here.
I would add that it behooves you to learn to think in hex because lots of strange base addresses in decimal are round numbers in hex.
Dude, that game got some name like you wouldn't believe someone's hobby project for C=64 ever could - I heard about it first long before I learned about it in the retro community :D
Awesome video guys! Coding is like painting, its all very personal to the person creating the code so don't worry about what it looks like as long as it works the way you envisioned it.
"Maybe a little happy tree here, another one there.... " ~ Bob Ross ~
“Yeah that’s a bug”! Love it!
Fun to watch! I remember when I just had an idea (to do some fun bootloader kinda hoax of thing for my friend) and that time I programmed mostly in Pascal on the Amiga 500 (why!??! long story)... and tried to make it as short as possible but I think compiled it was about 12k the shortest I could make it... and that was way to big. I wanted to make the best replication of a TV's static noise when your antenna was out/or no channel/data on the frequency... What was good in Pascal was that I did have a random number generator and I could (or had to) make it OS friendly. But it was slow and did not look or sound like the "real thing". Ah well time to go to 68k assembler, found a really fast, quick dirty random number (I was only after randomizing 1 bit), fully overscan screen with the static noise (not OS friendly at all) and it was really really fast and looked and sounded exactly like what TV looks like with just static antenna noise... In the end (even though hitting the hardware) I made it (a bit more) OS friendly and it came into 682 bytes if I remember correctly...
Never actually did the actual "prank/hoax" on him though I just had to show him the amazing TV static noise I created :-)
I remember I added a couple of funny things later like when you did a reset It booted from a RAD drive and played a animation with some scary music... man the late 80's :-)
Anyway I started (after learning BASIC on the C64) coding with a machine code monitor, It was really hard to do anything really amazing (I'm a normal dude) so on the C64 I just did some snippets in machine code on the C64... Got an C64 assembler a bit to late, bu sure I did realize my mistake... That is how you code machine code and not in a bloody machine code monitor program :-)
Your comments about learning to program on a C64 in the '80s.... Hours and hours in my Uncle Jeff's room as a kid when he was at work. I wish I'd had any information at all about Assembly though! Aside from sprites and sound demos peeking and poking to various addresses found in the Programmer's Reference, I had no idea what was where, and what did what. It all seemed like some Dark Art, particularly when you'd try to list a game and all it said was 10 SYS and some 5 digit number....
Now with Vice and other emulators, it'd be fun to attempt a small project to get my feet wet.
Also, love the the shot of the two of you talking about and holding the C64 mini(?) at the beginning makes you look like total Giants! Hehe. Nice.
This is the same reply I wanted to make. There I was programming almost this exact game on my C64 as a 14 year old kid in BASIC and it ran so slow. I wanted to take my program ability to the next level but there was no place to turn to.
The programmers guide was woefully inadequate. No internet. Just a few issues of compute magazine lying around...
Wish I could take videos like this back in time with me to 1984.
Awesome talk through your thoughts and process. Thank you so much!
great video! really enjoyed the two of you riffing and enjoying each others company
Well done both of you! I am finally starting to learn ML on 64 in my mid 50. I lost my 64 tragically (together with my vic20 😢) 20 years ago. So I use a the64 now.
Being in the same age group as you, I dusted off my old Merlin assembler I bought back in the 80's since I got inspired by Robin's recent ML videos. Looking forward to some fun coding to keep my brain turning to a mush. heh
It's awesome. It is a great achievement. All your bases are belong to us!
Thanks for sharing you two. Very interesting and also great how you did the commenting in the code. ;)
This was great!
Thank you both for this interesting and elaborate investigation of 1nvader and the machine code behind it. It was inspirational.
I liked the War of the Hands in there too.
Anything worth doing is worth doing poorly. Thanks for sharing! I love the idea of prototyping in BASIC before trying to tackle the assembly language.
same here.. kind of like writing an outline before tackling the full essay
Fascinating video! My favorite part is "THIS IS A RED PEN" =D
What a great video. I am pretty much in the same situation Darren was. I have coded tons of finished games in basic on the C64 and Amiga using Blitz basic but making that jump to machine language has always been just that little bit too difficult for me. Your videos are helping me make the first tiny steps into understanding what is going on.
Gary James the thing that got me going with assembly was the game Human Resource Machine. In some ways it’s actually harder than 6502 assembly, such as no index registers and no compares/flags register.
On the flip side, it’s pure input/process/output and you get to focus on just the assembly programming itself- no system components to learn to interact with, no vblank timing, no IRQ handling etc.
Great video, nice banter and insight into how the game progressed 👍
27:00 The term is "active low", in that a signal is asserted when it is in the low state (i.e. 0), as opposed to "active high" which is perhaps what you would tend to think in terms of.
If its easier for you to work with "active high" signals, you can always load in the button states and then complement them (if there is no dedicated complement instruction then XOR with all 1's/255/0xff), so any idle signals which are high will become 0's, and active signals then become 1's.
Love my journey of making BASIC games. Started off just playing these games showing characters and keep pressing keyboard and then I got to a GWBASIC console and thought what is this? Remembered seeing the word BASICA in my dads bookcase full of gardening, science books. Pulled out that book and saw similar keywords and decided to type out commands and some of the BASICA commands worked in GWBASIC. It was fun seeing how other people made games and I decided to go to the library to see if I could find more books on BASIC. Tried to type in similar BASIC commands for games that only worked on Z80 and sometimes it would work on my machine and sometimes not lol. The main thing was trying to understand what each BASIC command did. I wanted to later understand string manipulation and do some fancy animations. Was fun POKEing in the memory and then moving my mouse, joystick and seeing numbers change lol. Good times....
Awesome! That was a great time. I remember playing katakis with a friend hours and hours and days and days. And we finished it. We were so proud :-)
3:35 Those beards are awesome. Nerdfactor 10 of 10
Very nice. Loved the interplay.
Nice one, esp. that Pitfall & River Raid level generation story.
Nice video, great banter, and lots of humility... I'm so tired of suffering unto coding snobs in the C64 scene, so you guys are a breath of fresh air.
Retro-Games with only one enemy on the screen is an interesting concept. And I've already spotted it in the background: "1ast Ninja"!
I’ve been writing code since 1982 and every time I have a lot of self criticism and learning moment. If not you’d be doing the same thing over and over again. Engineering is basically an interactive process, of improvements on improvements.
Sure writing more robust code is easier now, as you know the potential pitfalls and you have algorithms in the back of your mind to do the input validation. But efficiency is something (especially with very new projects) that comes gradually.
Brilliant and insightful.
And sure code can be optimized, but that shouldn’t be your goal - unless it bogs your program down. Getting finished is more important. Perfection is the demon got succes.
And I laughed about the 46:30 remark about not calculating the score every frame.
I recently made a shooter in Unity. First game in oh, 26 years I guess. And my colleague (a junior age 24) looked at the code and asked me:
Why do you have copies of the variables with the old value of number of bullets, number of lives...
And when I programmed it, I knew modern PCs have no problem updating it 60 times a second but my VIC20 and C64 wisdom taught me, to only change things when they need to be changed. A compare is often faster than calculating and updating the screen memory.
The ‘kid’ looked at me as if I were a fossil. That we had to be efficient like that back in the day.
The great thing though, was that this “junior” (who develops very quickly now that he’s onsite from India), was genuinely interested in best practices in coding. In college you hardly learn proper coding. You are taught the mechanics and not the real world problems and best practices. So he asked a lot to me about some of his own projects.
Especially since he hears me cuss a lot about the shit others have created that is highly insecure and/or not configurable. I don’t care about small and efficient code that much, secure, flexible and maintainable are today’s ultimate objectives.
And this ‘kid’ learns so quickly that he now even corrects me when I missed something during an audit or something I coded myself. It’s good to be challenged and kept sharp and focused.
You guys are my people. I was a microcomputer kid born in the 70s. I had the Timex Sinclair, trs-80 MC10, ADAM and an Atari 800XL. I always wanted to learn machine language.
This is great. I'm about to code my first 6502 game -- Space Invaders for Atari 2600!
:D but I think it might have been done already.. :P
That's very ambitious! Typically I'd suggest starting by making a game for the Apple II, Atari 800, C64 or similar because they're a lot more forgiving than the 2600. But at least there are a lot of resources for 2600 programming now too. Good luck!
@@8_Bit You're right, it will be very challenging, but there is something about the way Space Invaders has to manipulate the registers of the two 8-bit sprites that is super appealing to me. The hardware is oddly well suited for it despite its incredible limitations. Space Invaders on Atari 800 and C64 would be easier with character graphics (though smooth scrolling is more of a difficult on the C64), and the Apple II would be somewhat more challenging with its weird bitmap, but the constraints and simplicity of the Atari 2600 is the most alluring to me.
36:52 I know what you mean when it comes to the little things taking a lot of time. have you heard of the 90-90 principle of software? It says the first 90% of the software takes 90% of the time. The last 10% of the software takes the other 90% of the time ;)
thanks so much for this video (and all of your videos). I just re-watched it a few times today and it’s one of my favorites on UA-cam.
Fantastic acheivement, Darren
29:45 "Machine language is so fast, you don't need to worry about it!" Unless it's something like a graphics decompression routine that needs to be executed tens of thousands of times, then badly written code adds up. Hello, Maka-maka for the Super Famicom!
Found my old c64 in my parents attic probably had not used it since 1989 90. Booted it up was like I had used it yesterday. Playing hardball. Kung fu. Blue max. I was 13 again for an afternoon. Even had def leppard playing in background.
Great memories, thanks for sharing :)
Learning is its own achievement.
Great video!
Really enjoyed that! One basic concept that I still don't understand is vsync and statements like "we live in the vertical blank.". Have you gone into this in past videos?
Vsync is short for "vertical sync" and it's what happens after each frame is drawn; it happens automatically 50 times a second on PAL machines, and 60 times a second on NTSC. To animate smoothly and without any visual tearing on screen, games typically wait for the vertical blank to start moving sprites, scrolling the screen, etc. Darren's game does a very simple implementation of this, by waiting for raster line $ff by polling register $d012. I explain this a bit in this linked episode but should do a more focused explanation sometime: ua-cam.com/video/05vlobA3JeU/v-deo.html
The "we live in the vertical blank" quote is from a podcast Darren and I listen to called "Into The Vertical Blank".
@@8_Bit Wow! I didn't expect a full explanation right now. Thank you for taking the time to do that. Congrats to Darren on finishing his first game. I have a similar task sitting in my bucket list.
"oh what happened the--" "oh thats a bug" lmao mood
This is such an interesting retro computer video, thank you 😊🤩
How I missed this? Really fun and educational!
R: "I've only got 500 points so far.." D:"That's 'cause you're lame.". The sound of true friends.
Awesome video guys, great entertainment and the best computer ever built in the same place...subscribed
I wish someone made a sort of documentary or such about early 8bit game ports, i assume many of them were pretty complete remakes, but was there some sort of cross compiling going on, was the same z80 / 6502 code at all usable across platforms with the same cpu's, what sort of tools did they have back then for transfering data between platforms, doing graphics conversions and such.
I'd be very interested in that too. Ideally it would involve the participation of a game developer from the 1980s who did that kind of work. It won't be quite the same, but I do plan to make videos about the C64 games I developed natively in the '90s and '00s.
I'm guessing that ports between different platforms often would use same codebase if they try to implement same game mechanics and the platform doesn't warrant a complete rewrite. Of course there were some games that were designed to be highly portable by the design, usually adventure games that implemented the game in cross-platform virtual machine, such as Z-engine (which was used with Zork), then simply port the virtual machine to each platform and they can easily use same game code and easily convert graphics, etc. between these platforms. Sierra and Lucasarts games come to mind - Leisure Suit Larry 1, C-64, PC or Amiga 500, it's very much the exact same game, and differences between these platforms aren't small.
I think designers and teams pretty much used to write their own tools for stuff like graphics conversions and such.
But I'm by no means an expert - just thought I'd chip in.
@@robsku1 (There's no LSL or any other Sierra AGI engine adventures for the C64).
@@kke oh man, I was so sure I'd have seen a C-64 version - not that complex it couldn't quite well have been done either - the 1st LSL at least, the 2nd was already miles ahead of it technically.
My bad, but the same kind implementation of kinda virtual machine for certain type games was there anyway - and I bet Zork & other Z-engine games are not the only ones :)
Sorry for the poo-poo I made 💩
Edit: and it's obvious that you already know about the technology I was talking of.
Lucasart (ScummVM?) games on C64? Sure I can't be wrong that they did exist? 😬
Really great discussion! Love the simple concept of the game as well
I don't have a way to get this over to my C64 yet, but I've played it on a C64 simulator on my Samsung phone, and it's awesome!
LOL, the game at least was a perfect choice for playing with touchscreen only :)
26:19 in testing goflag, CMP #0 is unnecessary. LDA sets the N and Z flags.
Watching the game play with the BASIC version and remember using Blitz! and actually ending up with a playable game
I think this is a great video for intro to game dev for anything, not just old stuff. :)
Love this video so much. THANK YOU. Learned so much!!!
This looks great, looking forward to giving it a go.
I tried to create the same game on my Atari XL.. when I finally managed to get a sprite moving on screen the code was such a mess I had no idea how to proceed. so I have to start over.. but now at least I know how the sprite system works and it is a lot more complicated than the C64. I swear there will be an Atari 8bit version of it someday :)
That just sounds like normal development to me. So, I'd say you're on the right track and hope you share your results!
now you just need a kickass OST, make it a competition, there are tons of highly skilled trackers!
I love all of your videos and I always learn so much, but this one is my favorite.
omg he's got a slik stik..i havent see one of those in a bazillion years
best joystick i ever had back then
Oh man as soon as I read your comment I saw it. My favorite c64 joystick followed by the Epyx one.
Very cool. I really liked that. I have thought about writing something that controls sprites with machine lang too, but not an entire game.
Great video! It is interesting to see this process!
Enjoyed the episode - definitely will check out the pod cast.
now FEET... i dont think i can handle it. go back to hands only please :-P
super happy Darrens game is actually released now. it was incredible watching it come to life. i can personally attest as simple as it is its incredibly addicting!
Great video, guys! And Darren, congratulations! Regardless or any perceived shortcoming this is an awesome accomplishment. This video reminded me so much of me typing in and troubleshooting errors (due to my typos) the BASIC game *Tank* *vs* *UFO* from the back of the VIC 20 User's Manual. I always wanted to learn Assembly, bought the Compute magazine books (which I still have, bit.ly/30CvWiH) when I was very young but I needed proper guidance and never did accomplish anything more than cycling all the screen and border colours, something I was quite proud of at the time. So, kudos to you on completing *1nvader* - well done!
Memory unlocked, I also typed in Tank vs UFO on my VIC. :)
Nice to see the prototype in BASIC first. These days, strange as it sounds, I tend to prototype complicated stuff in python first, prior to writing it in 6502 assembly. Sometimes the python generates the assembly.
Noticed only one bullet from each ship is displayed at a time press fire whilst last bullet still on screen removes that bullet meaning you use a single array to keep track of the bullets position.
This could have been done in B.A.S.I.C and run just as well as your MC version since no multi dimensional arrays seem to have been used in this program for anything.
Great clip. Please more like this :)
11:35 Quarth (or Block Hole) is a puzzle game disguised as a shooter. At least the Famicom port has a two-player coop mode with a "bounce" mechanic.
Brilliant!
On the Atari (before it was re-labled the 2600) the Space Invaders had a "double shot" mode that I think was undocumented. You hold down one of the console switches (I don't remember which) when booting the cartridge, and it lets you have two bullets.
Yes, if you hold down the Reset switch while powering on, you get the double-shot. It's a lot of fun to plow through the invaders with that!
This is really cool stuff for someone who lived through those great C-64 and arcade game times and all other early home computers. That's a Commodore 128 though on the screen, not C-64. ;-)
The biggest software publishing houses of the 80s, Atarisoft, Access, Epyx, System 3, thalamus , accolade, Cinemaware, Activision all had modern (for the times) development tools to help them build their elaborate games, plus they had teams of people dividing up the work.....
HA! I was just about to ask if there's a listing for this game available, till i saw the download link you provided ^_^
Darren, since this is a rather easy gameplay and also features a cooperative mode for two players, could you add a kiddo-feature that basically slows don gameplay dramatically? Not the whole game though, but in such a way that the enemy movements are remarkebly slower, and the players movements are slightly slower... maybe less enemies invading at the same time, I guess you get it.
I learned BASIC as a kid then C++ Builder at secondary school then forgot almost everything I learned for about 20 years.
Now as my kid got interested in programming I thought that I could learn python to help him learning and to have some fun with Raspberry Pi.
I found python and modern languages a bit too frustrating for me and driven by the nostalgia I started to learn C64 machine language which I couldn't learn as a kid.
It seems much more fun: learning the machine first then controlling it much more directly than on modern environments where everything is done by using libraries and dependencies.
Great stuff from both guys!
Very clever, keep 8 bit alive, it was our foundation and a great building block you the new players
great achievement! I love the twinkle of the stars..really cool.
You call this a game!?! JK guys I can't wait to get where you are if I get where you are. I have just started coding and can write Hello World. Finally seeing how someone struggled and talked about the process is wonderful. So many videos out there by people who come across as expert but this is the only one where I can really identify with you. The noob and the expert talking about the noobs project. I really hope you do more of these because I love it. Good jobs on the game and this video.
The REAL Computer Game is writing the code. Totally open ended - with a powerful surge of good-feeling hormones when it works. No one has to keep score. Success IS the score.
Here is a question, as you created the game, how did you save and load the game during the process? Where did you store it in memory? After the EOB and before SOV? Or did you just overwrite the basic memory location? Using the S and L of supermon can be subject to unexpected behavior..
I could never figure out assembly code. An editor like this might had helped. But I couldn't figure out numbers more than 255 on how to combine them and how do compares.
we now have much better tools, use an IDE for C64 development, we even have debuggers. I wrote a simple game in C64 assembler this week by coincidence. Disclaimer: I wrote some assembler code in the 80's on C64 & Amiga 500 on the bare metal (did have the final cartridge III on the C64 which was awesome).
I love how slow the BASIC demo was
amazing ... thank you :)
Unfortunately I never had a C64 as a kid and the two computers I did have access to-VIC-20 and Apple IIe-were both far too slow for games written in Basic to be meaningfully playable. I made dozens of games in Basic on the VIC-20 back in the day, but the only way most of them would be considered playable by modern standards would be that "warp mode" in an emulator.
I would gladly pay for an online class with you as the instructor.