Exploring Marz: C-64 6510 Assembly Minigame Code Walkthrough
Vložit
- čas přidán 28. 05. 2024
- In 2003 I made a little 1024 byte Commodore 64 game called "Marz" for the Minigame Competition, which was an annual online 8-bit programming competition. I've found the 6510 source code to it - let's take a look through it in the Turbo Macro Pro assembler.
To support 8-Bit Show And Tell:
Become a patron: / 8bitshowandtell
One-time donation: paypal.me/8BitShowAndTell
Credits music by: bedfordlevelexperiment.bandca...
Links:
XIP (minicompressor by Steve Judd): www.ffd2.com/fridge/rad/
Marz disk image: 8bitshowandtell.com/downloads/...
Disk instructions:
LOAD"MARZ",8,1 to just play the game - it automatically starts due to tricks in the xip decompressor
Use a REU on your real C64 or emulator to follow along:
To build with Turbo Macro Pro+REU:
LOAD"TMP",8,1
SYS 32768
{back arrow} L, filename: MM29
{back arrow} Shift+R, L, filename: UFOSPRITES, location: $3F80
{back arrow} Shift+R, L, filename: LASERBEAM2, location: $3FC0
{back arrow} 3, S
Hit the RESTORE key to re-enter TMP
TMP Documentation here: turbo.style64.org/docs/table-o...
New index (from 2020.12.01 edit):
0:00 Intro - Marz source code
1:39 The Minigame Competition - my entries
2:32 Loading the source; xip compressor
3:59 Diversion: Terry Cavanagh and bad source
6:26 Loading the sprites
8:16 Playing the game
11:00 The iOS version I made once
11:32 Walking through the code: memory layout, the labels
13:55 Game initialization - once per boot
15:45 Play initialization - once per game play
19:12 Level initialization - once per level
26:21 Game loop - once per frame
27:35 Ship to building collision - game over
29:29 Bomb to building collision
36:05 Moving the ship - wrap around and descent
38:30 Ship sprite animation
40:40 Fire button, dropping bomb
43:00 Checking for end of level & end of game loop
46:34 Building the level
51:00 Some misc subroutines - raster & sound fx
53:00 Update sprite positions
54:05 Other misc subroutines
54:45 Thanks to my patrons! - Věda a technologie
4:00 - In regards to the code quality of VVVVVV - a great game with bad source code is far better than a bad game with great source code. On top of that, I bet most of the people who were complaining about the code quality haven't actually written a game themselves. Kudos to Terry (and to you!) for releasing the code at all - every game's source code has a lesson to teach.
Was thinking the same thing but one step further (as you write further down)
VVVVVV - a great game with bad source code is far better than no game
Plus if you never get to see the source code you dont know if it's "not programmed by the book"; the only 2 valid points for critizicing source code, imho, are: a) if you plan to review your code in the future (here the main problem is not documenting) and b) if you plan to share or team-develop, in which case a mess in your code will delay others in understanding/co-developing
But in the particular case of 1-man-game participating in a contest it's totally fine
It's easier to criticize other people's code than right good code, yourself. I've been looking for a QA job for years! There's nothing more fun than complaining about other people's code.
There other PC Indie game like this:"You can win the game
Undertale is another example of great games that are poorly-written code-wise. The quality of the underlying code doesn't make or break the game itself, and it's way too easy for expert programmers to analysis-paralysis themselves out of actually making a game that's fun.
Thank you patreons for allowing us to enjoy Robbin's awesome content as well :D
Yes, thank you, patrons.
lol at the Rant Processor Bar
I wish I’d known you when I was a teen. Machine code was Greek to me back then. The meta-commentary of your videos is excellent.
Thanks. Very useful video. The game reminds me of New York Blitz by mastertronic for the VIC20
I love the rant progress bar! That's a beautiful piece of "video UI."
One thing a lot of programmers don't get about source code is that you're writing for _a particular audience_, and code written well for one audience will be poor for another. A non-trivial program written for developers who are working on it for long periods of time can and _should_ depend on background knowledge and conventions that allow you to concisely express the ideas embedded in it. Without this, both authors and readers (often the same person at different times) will waste time writing and reading code and comments that are not only redundant, but actually make the code more work to understand.
And for smaller projects, particuarly those being worked on by one person, what the code needs to say explicitly (and in how much detail) will depend heavily on the person himself. If he's got a great memory and a large amount of background in the particular domain, he may not need to spend the kind of time and effort on code organization and naming that I (with my terrible memory) need to do to in order to make my future self more efficient when going back to that code.
Thank you for sharing this with us, I am amazed that games could ever be built on the C64 at all. I mean, I know they were made, ofc, but it still boggles my mind that game authors were even able to make such quality games with such a limited system. David Murray (8-Bit Guy) rekindled my interest in C64 programming (among others), but I find this series to be the most informative, and the most accessible to me anyway.
When I started with basic on the C64 (I think I was about 8 or 9 years old and my English as a Dutch boy was still very limited) I named my variables just like a, b, c etc and remembered what each was. This was because some examples I had did it that way . After not working not the code for a while I sometimes couldn't figure out how the program worked 🤣. I agree that short term code needs to work and clean code comes second, or not at all. Thanks for the great video 👍
I went back and wrote some C64 basic code after being away for a couple decades. Started out using long descriptive variable names just like I do in C, Java, etc. The program didn't work at all, then I found out the compiler only looks at the first two characters of variable names. Doh!
CMD equipment... PET machine... My god, you are loaded.
These kind of videos are very helpful! Thanks for putting your time into this. Even better (for me) would be a book that explains the game line by line. I like your no nonsense approach very much: no external libraries, no big cross compilers, no IDE, just you and the machine
I am such big fan of your clips. Great job always . Thanks for sharing and making these videos.
Well done Robin. I know from personal experience how difficult it is to analyse code without losing yourself in detail.
More detail the better! I enjoyed seeing the level management code
in the bomb-hits-building section, if you add Y to ZP0 then you can later use Y indexing to move to the building positions (#39,#40,...)
Very nice video, as usual. I'm still hopeful you'll once write a book on C64 game development or some more formal online courses :-)
I do think about making a more formalized online course sometimes, but haven't really figured out how to structure it yet.
@@8_Bit aha! There’s hope! For what it’s worth, what seems hard to me is converting basic concepts of physics (velocity, acceleration, gravity, etc) into a simple assembly game engine. Another thing that I know I lack understanding is what else needs to go into a game engine.
I know it’s not much, but I hope it helps you in some way.
If you ever release such a course, please make a video announcing it so all of us get to know about it.
PS: what I would like the most is a course that doesn’t tie to a specific GUI tool like prgstudio. Something more generic relying simply on an assembler and a text editor would be great. This is because most of the GUI tools for C64 development are windows only.
@@FelipeBalbi Ah, yes, that reminds me that I'm also stuck on what tools to use. I agree that I definitely don't want to use Windows-only tools. In a way I'd be most comfortable using the native Turbo Macro Pro like I always do in my videos, but maybe that would be a turn-off or hindrance for a more formal course.
@@8_Bit personally, I'd love to follow that approach, but I can see how it would/could reduce the target audience
@@8_Bit I know it's been a while, and this topic might not even be relevant any longer, but I say "go for it". Make it in whatever is convenient and familiar to you. I'd rather have a docuseries or book based on this, rather than not have it at all, or in an environment that you don't prefer.
I recall a game called Blitz where you controlled a plane bombed buildings below but there was also the ability to shoot in front of you and occasional enemy balloons or planes iirc
Robin, hello from Surrey, BC! I'm looking forward to making my first full blown 5p game for the Atari 400.
This video helped me to think about UI development, like thinking about the fire button at the end of the game. I also like learning about memory addresses. Unfortunately, I wasn't able to take much away from it, since I don't program in Assembly, but it was still worth my time.
Although I "insist" :) that we be given a healthy serving of game reviews, hardware reviews, and Easter eggs, I think that I benefit the most from your programming videos.
Thanks!
Fantastic job! I wish i had your programming skills.
Thanks for sharing - I really enjoyed this! I can really relate to looking at code that I wrote in the past and trying to figure out what I was trying to do. Sometimes even with comments I still don't know what I was trying to do...
Thank you for sharing this Robin! The part about sprite bit packing that you discussed at 33:30, is it possible for you to maybe do a little video with a diagram or table to describe how this works please? As you said, it's a little unintuitive to those of us who haven't been forced to learn this stuff about the VIC hardware and sprite mechanics!
Pretty please!
Thank you again, you and your Patrons for sharing this very informative and entertaining video! Every time I watch one of these, I get an itch, an urge even, to pick up an Emulator and relive those Halcyon days!
When you think of all the release games and software out there, and bad games.. just imagine how bad the code is if you could see the half if it. Nevermind the good games with bad code. Most of these early games programmers learned on the spot without good reference manuals when they were still kids, and look what they accomplished in just a couple years of learning by just doing it.
This was extremely informative! I'd love to learn more about Minima too :)
Kudos on yet another really great video! One thing though: At 16:23, since saving bytes was important you could have replaced these two code blocks with just 10 bytes of code:
lda #15
sta $0286
lda #147
jsr $ffd2
This works because printing the clear-screen char (147) also sets $d800-$dbe7 to the currently selected foreground color.
EDIT: 03:50 - I see now that jsr $ffd2 does not work properly with the xip compressor but calling jsr $f1ca instead has the same effect.
He's got a call to $FF8A, so the vectors are restored.
Or simply send a string containing .byte $93,$9B,0 [CLR][LGREY] to $ab1e as shown at 00:21:00
@Stavro Mueller That's also an excellent option. However, it would still cost us 10 bytes :-)
Also, I hate to be a total nit-picker, but we need to have [LGREY] before the [CLR], otherwise the $d800-dbe7 fill would be set with the currently selected forecolor.
lda #text ;2 bytes
jsr $ab1e ;3 bytes
text:
.byte $9b, $93, $00 ;3 bytes
Unfortunately different KERNAL revisions handle clearing the screen differently. KERNAL v. 1 sets colour RAM to white (1). Version 2 sets it to the background colour, so any characters POKE/STAd to screen will be invisible afterwards! Version 3 gets it right, finally. Because I grew up with a V2 machine, I'm pretty sensitive to this problem :)
But yes, there are definitely optimizations that could be made here and throughout the code.
@@8_Bit Wow, I was not aware of that. I guess it's' true that you learn something new every day! :)
I got my first C64 in mid-to-late 1985 and have never seen that behavior when performing a clear screen. I suppose I must have just missed out on V2 then. Do you have any idea when V3 was released?
Thanks for the video. I started to read/learn about Assembly at the beginning of 2020. So when you made this video I wouldn't have been able to follow it yet. Now it's very clarifying. :-)
haha - like the rant bar. On that subject my view is what is achieved comes first, and if you actually finish the game and you are happy with the result, who cares one jot what order the bits are within. If you have loads of time on your hands, or are looking to meet a challenge, or if you want to share code nicely with a team then maybe you can focus more on the code, but yea - getting a game completed, making it fun or achieve something is what is important and that can be very tough to do. Anyone who criticises the way you make something isn't worth talking to :)
1:32 I guess marker is safer for floppies, at least for 3.5" hard ones; I've seen many stickers ruining drive mechanisms when they start to peel off inside the drive and the gum creates a mess there! On soft 5.25" markers have to be soft point type and you dont wanna apply pressure because of the sensitive flexible case
Love the video. Please do more game development videos on the c64.
I've got a couple more that I've made during 2020 for my patrons which will be released publicly in the coming months.
Great as always
This game is fantastic animation is super i'll take a look
Great tutorial walk-through. Kind of makes me want to get the C64Max and get back to coding. (VICE on Windows 10 really sucks!) Thanks, Robin. You are something of a genius!
such great content as usual
You are a straight up genius.
Good video. Needs breaking down into multiple videos, and more details on the instruction sets. But great, and thank you!
I remember seeing that city bomber style of game in the early 80s on many different computers. I remember it being called Blitz. I think I even remember a version of it being a BASIC type-in printed in a magazine. :) Excellent job squeezing that into 1K. Maybe if the ship sprite wasn't so nice you could have done a bit on the buildings? :)
I love ur videos man!!!! Long live to c64!!!!!
I spent 57 mins going ok....... I have no idea what you're talking about, but very interesting :)
I hate code snobs. If it works, it works.
This video was over before I knew it.
G K Chesterton once said that anything worth doing is worth doing poorly.
hi Robin, love your content. Could I ask when you do these type of videos, could you show a tick list of how you got to the game loop? or what's exactly in the game loop? if possible just on pen and paper?
Your code has brought me back to programming after 40 years. My friend taught me M/C. He wrote manic miner for the C64 for BugByte however because of problems, it never released, so he wrote "Matty goes mining" which again didn't release as BUGBYTE closed down just before the final draft of the game. but your vids are massively helping me get back into it. THANK YOU FOR ALL YOU DO!
Good job! In order to really understand the math stuff, one needs to dive into the code. But that's normal, if you're not a rocket scientist 🚀
I concur with your rant. Good code is nice and efficient coder is nicer but completely finalized code is the best.
And even “good code” is relative and also very taste oriented. I tend to these days, focus on re-usability and testable code, and legible after that, then small highly efficient code.
As I found that good abstract layered code is bigger in code base but very reusable. Saving me time and frustration and my customers cost.
Yup, you pronounced Terry's name perfectly!
Very cool.
Nice deep dive! :) Two (unimportant, but lingering) questions...
1) What are the flaws in collision detection that you mentioned? (26:08)
2) Can you still fire when, on a level clear, the ship begins to vertically descend? (45:12)
1) The collision registers doesn't tell you which sprites hit which other ones, so if bits 0,1,2,3 are set, you don't know if 0 hit 1, 2, or 3; it's often not enough information to make a decision and you have to go through and compare positions of the sprites anyway, so the register often just gets ignored. Same with sprites hitting characters; you don't know what characters they hit (was it a wall, or was it deadly fire?) so again, the math has to be done anyway.
2) Yes, you can still fire while the ship is descending. I don't remember if I did that on purpose or if it was an oversight, but it's kind of fun :)
@@8_Bit wrote «and you have to go through and compare positions of the sprites anyway». If there's no hardware collision, you can save yourself the bother of looking for any software collisions.
@@csbruce Yes, it's sometimes helpful. But in the very common case of a character interacting with the level data in a platform game, for example, by the time there's hardware collision it's "too late". We can't have Bruce Lee (for example) sinking a pixel (or more) into the platform he's standing on to trigger the hardware collision, then do the software collision to move him up immediately above the platform. It looks terrible.
Also in many genres of video games we're trying to hit a full 50/60 frames per second, so we're concerned with worst-case performance. We don't want the game to sputter and slow down when there's more collisions happening. Why spend even a small number of cycles doing a hardware collision check when they could be put towards optimizing for the worst case?
The VIC-II collision detection does have its uses. But many games just don't bother with it for the reasons given above.
This is still Sorcery to me 40 years later. I’ve watched all these videos.
It boggles me how people understand this to the point of writing Demos, the way they chuck around sprites and getting SID to play music all while reading it off the disk, using self-modifying-code, and all the tricks that are known now. Quite unimpressive in comparison to the PlayStation 6 & Xbox 720. Astonishing for something invented in 1982.
Definitely not too much Robin, the more detail the better imho.
Thank gods for the existence of C#..
Another fantastic video Robin, it's been your videos that have made me invest in real c64 hardware. I have a real c64 breadbin and c64c - and of course the The c64. I don't have a REU for my real hardware so i can't follow the whole build process, I was wondering... I know you can fool The c64 in to thinking it's got a REU onboard -will it work with the Max? Keep up the great work - I think we'll all be happy when Snappy2020 is released - we'll have it all in one place. Thank you and your patreans for sharing.
Hi, It reminds me of a game for Atari 2600 called "Ram It".
Hi Robin.
Just been watching your "Exploring Marz" video, pretty cool.
I'm just getting into assembly and the TMP.
Could you please explain the .block & .bend I just can't get my head around it.
Cheers Alan (Patreon) Uk.
I'm surprised you hadn't heard of or played Blitz on the Vic-20. It's one of the most famous Vic-20 games.
I didn't know you did Splatform even though I uploaded a video of it recently and put your name in the text.
Yeah, I didn't have a VIC-20 back in the day; I went directly from the Timex/Sinclair 1000 to the C-64 and have only been picking up VIC-20 knowledge gradually since the 2000s. I now own a couple VIC-20 Blitz-type games on tape. Thanks for mentioning your Splatform video, I left a comment over there and subscribed.
What a coincidence! I watched your video today and just now I watched a video by Kite666G called "Commodore 64 - 2020 Previews" wich features a game called "Air Attack".What can I say? It´s EXACTLY the same game as "Marz", just different sprites.
I encountered this game as Bombardier, a text based game for Unix-like systems (included in Debian), and that refers back to Blitz 16, published in 1984 by Commodore UK. Wikipedia further traces its inspiration back to Atari's Canyon Bomber, 1977, but that has different rules.
Hi Robin, great video! I watched it now paying more attention to the details. I like to develop in the machine (like you) instead of cross development. I wonder which tools were (are) you using for creating the resources (loading screens, sprite design, music) on the C64. Could you share? Thanks a lot in advance.
Hi David, it's been a long time but I used to use JCH Editor for music. You can learn more about it and other options (both native C64 and cross-platform) here: chordian.net/c64editors.htm
And for screens and sprites I used Tony Crowther's 3-in-1 Editor. I demonstrate it a bit in this video and there's links to download and instructions in the description: czcams.com/video/6o9Hi_WrfIA/video.html
Thanks a lot Robin for the quick reply. That chordian.net page with the comparison of music editors is great.
Thank you Robin very informative and constructive love the game and your videos ive learnt a lot very very constructive more p[ower to you.
At 52:02... this is a pretty clever way to do this sound while not blocking the main loop. Is this typical for all sound effects? I've got a couple sounds with nested loops that I can never get to stop interrupting the main loop. I suspect I've just not written them cleverly enough to keep calling the update through every tick of the main loop yet.
I think all sound effects that dynamically change pitch need to be updated in this way, a little at a time, typically at 50/60 Hz with the vertical blank. Of course the SID will handle volume changes with the ADSR parameters automatically, so SOME sound effects are fine to be "fire and forget" where it's just triggered once and the SID takes care of it. Way back when I was only writing BASIC games that was really all that could be done.
@@8_Bit there are A LOT of resources on how to do sound in BASIC and precious few in assembly. Been doing some of the ones I like in BASIC and then reengineering them in TMP with hit or miss results. The whole SID thing still feels too much like black magic to me, but I'll eventually figure it out.
@@MichaelDoornbos I'd suspect the main challenge in converting from BASIC to ML is reworking the FOR/NEXT loops to run over multiple frames. If you want to email me one of the trickier examples I'll look at it!
the originals had a 6502 processor. I used code a lot back then
The Commodore PET and VIC-20 have a 6502, the C64 has a 6510, but it's completely code compatible with the 6502. The 6510 has extra Input/Output pins that control the advanced memory configurations that the C64 has that the VIC-20 and PET do not.
i wonder how defined the speed of ship and projectile.In games like Contra player movement and fire is faster than enemies.
Nice and educational video! I really like your game, especially the ship sprite.
I played a commercial game (Bomber - from 1982) like this on the ZX Spectrum and also copied (typed in) a simpler BASIC version with ASCII graphics from a magazine (possibly called City Bomber also from 1982).
LE: Actually, I played two commercial games on the Spectrum, Bomber (1982) and another Bomber (1985). I remembered now, only when searching for that game and finding the other one too.
Well, now I'm not that sure of the names and years anymore, as I found a long list of similar games here:
spectrumcomputing.co.uk/list?license_id=1177
You ever gone to a museum and had a guide walk you thru the story behind the lump? Sometimes they talk to their belly in an inaudible mumble other times the magic happens and you enter a world you have no right to be in, like say going thru a fire escape to see a movie for nothing! Well okay assembly is a bit niche, say like music notation or what ever it is architects speak; the loops the dec instead of inc the left shifts the nors , the zero page, alll that stuff; the meta to the operational (is that the word?) yes concept to implementation. Your Marz is just that; a museum. A work of art that without story behind it is so much flaffle so meh. Thank you so much for telling us your story
Is there a way to produce random numbers, or would a lookup table (using the timer to select the starting position) suffice for tighter code?
The SYS command - have always wondered what it is/why it is needed to run some games.
The SYS command in Commodore BASIC (and likely others) sets the CPU program counter; in assembly, that operation is more commonly known as jump. It's like GOTO, but at a processor level, executing machine code, rather than the BASIC interpreter level, interpreting statements. If the routine started by SYS later returns to the BASIC interpreter, it functions as a system call operation, which may be where it got its name.
@@0LoneTech Hey, thanks so much for such a detailed explanation. I think these were older games that were cracked and I only remember there being a few of them that I saw that needed SYS to run. I’ve been wondering about that little mystery for decades. I even just now remember I have/has a tiny utility called “SYS finder“. Apparently such a thing was needed enough that someone wrote a little utility for it. Great memories.
Poke 43331,124 Unlimited shoot range
SYS514412
Poke 31211,243 Laser shoot
Randomize Usr 65
;)
if it works flawlessly, the code is good.
Can you do a video about cross platform dev for the C64? I want to make a game but I don't own a C64 so I wanted to know what tools I could use on PC to make one
Hi, you could use these same native tools in VICE emulator on PC. But it's true there's a lot of good cross-platform tools too. I put up a video about one on my 2nd channel: czcams.com/video/ldDOqGH11e0/video.html Not sure when I'll cover more.
C64 65XE Debugger v0.64.58
czcams.com/video/Xu6EknKA7GE/video.html
@@8_Bit Thank you for getting back. If using native tools with a VICE emulator works I will give it a shot. Thank you
I LOVE C64 👍🥂🎩
Yeah if you work alone why worry about what others think of your code. Whatever you understand the easiest at a glance is usually good enough
Thank you for the walk down memory lane. Marz is almost identical to the first game i ever typed into my C64. It was called Pudding Mountain Miner and was created by Charles Brannon and printed in COMPUTE!'s Gazette 1985/04 (Issue #22).
You can see the game and source code (in BASIC) here:
czcams.com/video/FSngspwDJ8g/video.html
I’d like to learn to code. Don’t think my brain would agree though!
Great explanation! You should probably record these in two (or more) sessions. You seemed to be getting tired about half way through, and your explanations were slightly less thorough. (You went from enthusiastic to "let's get this over with!") I like the text corrections of your verbal explanations: It shows the value of comments.
Yeah, I've already recorded a walkthrough of my Frogs & Flies game for my patrons and I did that in two sessions; but each of those ended up being almost an hour! It's difficult to know ahead of time how long these things will take; I plan my main points but the rest is all ad-libbed.
Greate video - one day i'm going to port MARZ to some HTML5 game :-)
Maybe very soon! ;)
What's your opinion on developing C64 games on PCs using modern tools and emulators? I saw a video years ago about how demoscene coders had developed surprisingly sophisticated development environments for creating their demos that ran on modern PCs. Very interesting!
IMO, it’s absolutely the only way to code these days. especially if you are learning now. kickasm, C64debugger and charpad pro reduce your time to code by like a million percent. It’s also way easier to code for all versions of the c64 without having to buy it all on ebay. Most SID trackers are still native though I believe
@@MurderMostFowl Makes me wonder what types of games would have been made back in the day if those old "golden age" computers and consoles had had the tools that we have now. Creating a game of any sophistication for the Atari 2600 was EXTREMELY cumbersome, for example, back in the day. Now there are entire IDEs that make it a simple matter. (Well, far easier anyway).
Can you make the complex sprite assembly tutorial I need it pls
I guess you don´t have to cmp#$255 when decreasing the x-register by using bpl instead of bne.Or is there another reason, maybe saving time or bytes?
That's right, BPL can be used to detect wrapping around from 0 to $FF *but* it only works if the loop starts at x=127 ($7F) or lower.
@@8_Bit Damn it!Of course!Didn´t think this through...
I wonder if you could do "Bin Laden Liquors" in Commodore assembly.
Hey Robin, wonder if you might answer a question about TMP. I've been using it in VICE with 512k REU configured. Like in your videos, I configure the jumpback to respond to the RESTORE key. The problem I'm having is: If I hit RESTORE when at the compile status screen (before hitting 'S') it drops to basic, and I can't get back into TMP. sys 320, or sys 32768 do not work, and reloading TMP results in empty source. My compiled code is in memory, but as it is, I've lost any changes to the source since my last save. Appreciate if you can shed any light on this. I'm looking into how to manually swap banks in and out, but so far not having any success.
edit: it happens when I target $0801(*= $0801) with a basic loader configured correctly (10 sys )
edit2: I found an article by you! About REU programming. Tried some things, still couldn't recover the source :(
Sorry to hear about this trouble! Is it that you're accidentally hitting RESTORE while on the assembly screen? Normally you'd just hit space bar or probably any other key (besides RESTORE) to return to the source editor, or S to run the code (after which RESTORE should work fine).
One thing that should help in the future is that on the full TMP distribution disk (download from style64.org) there should be a short file called "JUMPBACK" or something along those lines. You should be able to load that file (with ,8,1) and then SYS 320 will work afterwards.
@@8_Bit Well, not really accidentally, just when I'm iterating on code, I get in the habit of hitting RESTORE to get back to the source, so I'll compile, think of something, and then instead of hitting space bar, or D or something, I'll reflexively hit RESTORE, then boom, back to basic, and with seeming no way to get back. I try to save often, but you know how that goes. :)
Your tip about the jumpback files was a good one, I've been overlooking those files, and they even include source SEQ files for them! But sadly, even loading that file doesn't resolve the problem. Like I said, I am using VICE and haven't tried to reproduce the issue on real hardware.... actually I can't as I don't have an REU. Perhaps looking at the jumback source file I'll figure out something.
But either way, thanks for the response! Learning assembly had always felt like unfinished business, and it has been a blast and your channel has been of immense help. I've now got a pretty polished game finished, a version of the classic snake game, and while seeming simple, it has been a real educational challenge and alot of fun.
Ok, I've dived into this and found out why it happens, and that it is in fact UNrecoverable. So, don't hit RESTORE at the compile screen if it's configured to "jumpback". :) UNLESS.. read below
What happens is that TMP zeroes out the REU 0 bank when you compile, and then assembles your code to that bank.
So, at the compile screen, your source and TMP are in C64 main memory and your assembled code is in R0.
If you hit restore at the compile screen, the code at $0140 writes REU memory into C64 memory. Effectively erasing TMP and your source in both places. Your *compiled* code however will have transferred and will still be in main memory. (hitting S does a correct swap)
UNLESS, you get your source out of Bank 0, by doing a R,b,2 (backup to reu bank 2) and R,s,2 (swap to bank 2). Now, in the lower right it'll say bank: 2/1. (any bank 2 and above will work here)
At this point, hitting restore at the compile screen will still drop you to basic, but your source and TMP are now living in bank 2, and you can load the "jb reu" program off the TMP disk, run it, select bank 2, and you'll be back.
Of course, a 128k reu wouldn't have a bank 2, so this solution is probably not possible with that size of REU.
(btw Robin, I rediscovered your C64 REU/SID random numbers vid that flicked the light bulb on the REU stuff)
How many pages (roughly) if you printed it?
Good source code costs more than people would imagine if they aren't (or haven't been) developers themselves. Having to push out garbage code that I could not have any measure of pride in, and then moving on to shovel even more code that just barely worked, is part of what pushed me out of the business. I *want* to see good source code, but in a commercial setting that's just not a priority, and that needs to be recognized. And on top of that, I wasn't even a game dev... so I don't think even I have a full appreciation for the pressure they're under. AAAAAAND the compiler will take care of a lot of shortcomings anyway (which I still don't think is much of an excuse, but it makes the end product a bit better for the user at least).
One day explain the source code of Minima
Basic C64 maybe, I think try
WAIT 6502, 1
What is the cartridge expander called ?
This expander is called a CMD EX3. CMD made them back in the '90s and early '00s. Jim Brain at Retro Innovations is currently making something similar called the X-Pander 3 which you should be able to find on go4retro dot com
Hi Robin, it's the future speaking in 2023 :-)... I am a newb, but have managed to set up Windows with VICE and using TMP (latest) .... and I've had some issues loading the mm29 code into TMP/VICE... but with some copy & paste of the text (thanks TMPViewer) into TMP it luckily parsed it (as it pasted in), and then some minor line length fixes of the Rem's (hanging over lines for-however it decided to input the incoming text)... [breathe]... TMP then after saving the code says - "21, read error, 18, 0" which seems to be pointing to the "screen = 1024" line ? (blink blink) I am lost 😐 Any tips?
* Added... "Oh yeah, a big thanks for your channel!!!!" :-)
The 21, read error, 18, 0 indicates the disk drive wasn't able to read or write to the disk, so probably the save didn't work. In VICE there's an option under the file menu to create and attach a new disk image. Give that a try, and then your save should work.
@@8_Bit - Thanks Robin. That helps :-}... well, you've got me at least into some coding and feeling like I understand everything you went through. Thanks again! I checked my version (the badly "pasted" in version) and some of the rem lines ;**** had wrapped onto new lines, and had become *=*, so it tricked the build process (I assume). Anyway, cleaned it up, line by line following your whole video and it shows - 0 Errors on the build screen... but when I Start it just clears to C64 blue screen "Ready". It's all good. I'll keep on keeping on and get it going. Cheers.
Should back them up to a cloud
I don't think source code needs to be pretty.. I think if you are working in a team, or on a long term project, you should document it and use logical variable & function names, but beyond any restrictions placed on it by the language it's in (some languages do require the source code be in a specific format), it doesn't need to be pretty.
That said, if working in a team, it probably should be clearly formatted as well as documented.
If you are working on code for your own use, I think the primary concern should be it works. Making it pretty is a secondary consideration. I remember at uni, our programming lecturer set a quick challenge for the Christmas break. We had to write a small program to display a Christmas tree. My friend won the challenge because his program was not only small, but the source code was in the shape of a Christmas tree. He also wrote another version of the program that (using a recursive function) drew a christmas tree. The source code for this program consisted of one, rather long and unreadable line.. Both versions worked well, but neither had maintainable source code.
...and these days a simple calc consumes 40MB :D
is MAC better than linux? dont know open source? Please Reply @8-Bit\ Show\ And\ Tell.
I'm not qualified to say if Mac is better than Linux. If you're asking why I use Mac, it's because I frequently get contract work doing iOS programming and a Mac is required for that. I also find Mac to be a good platform for doing video editing and audio work.
@@8_Bit do you know/use Linux or open source software
@@anshul493 I don't use Linux, but I do use some open-source software like Audacity, Firefox, and LibreOffice.
why doesn't your game start with "run" or "sys"?
If you LOAD"MARZ",8,1 then the game will automatically start. This is due to some auto-boot tricks the xip compressor does. I might make an episode about it sometime, if you're really interested, check out the xip.readme file in this .zip: www.ffd2.com/fridge/xip/xip.zip
Are they the original F keys on that micro? They look higher than normal.
As far as I know they're original; the F keys look the same as on the other 64Cs I have. I have noticed that the keyboard is shifted 1 or 2 mm right within the case, so there's a slightly bigger gap on the left where the keys come through the case. Maybe that makes them taller. One of these days I'll open the case up again and see why it's slightly misaligned.
@@8_Bit ah ok, must be an optical illusion. Thanks for explaining this minicoded game. Super interesting looking at how you save space.
1:18 SD cards will experience "bit-rot" after a while, too.
3:15 Is there some reason to start the assembly at $4000? If you start at $80D and include the sprites in .byte definitions inline in the code starting at $840, then it's all one chunk that can run from BASIC.
4:32 If a "VV" is a double-U (W), would VVVVVV be a sextuple-U? Maybe websites could shorten their "WWW." names to "sex-u".
6:21 Shouldn't a Rant Progress Bar end with an explosion?
8:30 If the Object is Unidentified, then how do you know it's a ship?
8:35 The shots sound more like lasers than bombs. Did you get in trouble with "Futurama" for copying from their pilot episode?
8:50 The blocks would normally be drawn as buildings. The sky on Mars would be red, orange, or black rather than blue.
10:38 Stalagmites?
11:13 Is the UFO motion jerky in the modern version or is this a video-capture artifact? The C64 version is perfectly smooth.
12:06 I always used to use location $FA as well, but according to the Anthology, $FA is technically allocated (to something almost certainly not being used at runtime).
12:12 You can also directly use any zero-page variable as a pointer.
15:53 Setting a block of variables to $00 can be done in fewer bytes in a loop.
17:10 I looked it up and found it a little surprising that your minus-N method doesn't take any extra time because STA absolute,X always takes 5 clock regardless of whether page boundaries are crossed or not.
18:05 You could also INX in this case, if you LDX #6 and STA $D800-6,X, etc. Or, you could just fill all 1024 bytes if you set the sprite frame pointers afterward.
18:32 If you were filling the color memory with Black, you could combine the two loops and save time and memory. In fact, if you were to combine the loops and do an LDA #15 for the first four STA's and LDA #32 for the next four, it would save five bytes and still be faster, since the redundant DEX : BNE - takes 5 clock cycles while LDA #15 : LDA #32 takes four.
Of course, since you're trying to save bytes instead of clock cycles, making a de-unrolled generic fill routine would probably be smaller. Is there a generic fill routine somewhere in ROM? You could also use $FFD2 if you could count on the screen-clear fill color. You could even copy the Kernal, swap it out for RAM, and tweak the fill color.
23:13 It might be better to have individual labels for the different VIC registers, since "v+$1c" doesn't say much more than "$d01c".
23:43 With a bunch of VIC register values close together, it would be more compact to do something like LDX #nRegValues-1 : - LDA initVicTable,X : STA v+$1c,X : DEX : BPL -. Each inline STA-absolute instruction consumes three bytes.
27:59 You could save a byte by doing «LSR : BCC building».
29:29 Instead of using "temp" to save the sprite-collision-register value, you could have used the .X register. Also, if you had have used Sprite #8 (however they're numbered), you could have done BMI/BPL without an AND or LSR.
32:29 The «LDA zp0+1 : ADC #0 : STA zp0+1» can be replaced by «BCC + : INC zp0+1: +». There's probably a ROM routine for the screen handling that multiplies a row index by 40. The PLOT routine will do something like this.
33:35 Why not put the bomb in the top-left corner of the sprite?
35:30 That code could be de-unrolled.
40:20 Could you have used some kind of shifting action on the sprite pixels to get a similar effect in fewer bytes?
43:35 Though it would take another byte, you could DEX twice to scan faster, since each "building" is two characters wide. Also, you could LDA #32 outside of the loop and CMP screen+960,X inside the loop.
It doesn't matter where the code is, the decompressor will launch it automatically anyway (and the decompressor itself loads to $326, overwriting internal pointers, so it decompresses and runs automatically).
Thanks for all the insights. Many things that could be improved in the code for sure - I wonder how much better the game could be made to look with enough code optimization to allow for some extra graphics for the buildings.
I have no idea why I ended up with the blue colour scheme for the background. When my friend Sam did the art for the iOS version he of course immediately shifted to Mars-like red. I think the iOS version is jerky due to the poor video capture solutions I had available for iOS at the time. It was much smoother on the actual device.
people complaining about code but dont make anything can go sit in the corner.
I wish that Rant Progress Bar was infinite as there is so much to say on that topic. The code I see my "colleagues" write is abysmal at best. The predominant approach to coding these days seems to be "make it work now and f**k all the rest"! No pride, no forward-thinking, no nothing, just mindless keyboard mashing.
Yeah, there’s nothing worse than taking over someone else’s project only to find that either:
1) there’s no source code organization; it’s all in one big file, or
2) they’ve taken the whole “code modules” to the ridiculous extreme, and every little sub/function resides in its own file, or
3) the person who wrote the code got only as far as the “If-Then” and “Goto” chapters in whatever book they were reading, and never got to the “looping constructs” chapter, much less the “subroutines and functions” chapter! Or,
4) they try to squeeze as much code as possible into each line, with only the bare minimum of white space so it’ll still compile. (I’m talking mostly about certain C programmers out there, but I’ve seen horrible BASIC code where they try to use as many statements as they can with the “:” token separating them, along with “If-elseif-else-end if” crap all stuffed in too.)
Unfortunately, the rant progress bar has a value limit of 32,767. 🤣 Darn Int16’s!
@@williamsquires3070 There are sometimes good reasons to do that with BASIC, mainly to save space. When dealing with situations like that, one solution (if you're working on platforms where you can manage to do it) is to write out the code more nicely formatted, with lots of comments, and "compile" it to the compacted, commentless form. For an example, see a file from my (partial! and now abandoned) reverse-engineering of Izumic Ballade: gitlab.com/retroabandon/izumic-ballade/-/blob/master/src/autoexec.ba (You can probably imagine what the original code looked like, but if not, load files/autoexec.bas from that repo into an MSX emulator and you'll see.)
"This is why we should comment our code"
If only more learned this lesson! (I've been accused of the exact opposite. My source is mostly comments! 😉)
The video was way too short (as always) :-)
I think this is the 3rd video I've ever made in the 50-something minute category. Haven't gone past 60 minutes yet :)
How about using www.udemy.com/ for the online course if you ever do one.
It's a solid idea, thanks.
All code is only useful for its side effects. If the code is beautiful but with ugly side effects then it's useless. The player doesn't care how nice the code is. i might have actually finished a game if i knew this sooner.