It seems no matter how much I try to cram into a video, I always forget to say something obvious. I guess that's what the comments are for, eh? :) Thanks!

Thanks! Definitely good advice.

Same here

Yes, I totally agree. After 35 years I start understanding assembler a bit on the C64 and this is mostly because of this niche videos. And damn you Super Mario .. Great Giana Sisters rules the 8bit world.

I absolutely agree with all of you guys.

A more in-depth video about interrupts is a good idea. In the meantime, a quick (and rough) explanation: after a SEI (set interrupt disable opcode) no other IRQs interrupts will occur until a CLI (clear interrupt disable) occurs, so the long running interrupt will just keep going as long as it likes. However, other interrupt sources will wait and cause an IRQ as soon as possible. But they can't queue up more than one request from each source, additional IRQs are dropped.

@@8_Bit Definitely hoping for an in-depth episode about the interrupts. Thnx a lot.

www.c64-wiki.com/wiki/Raster_interrupt

I was thinking the same, these nice niche tutorials are what's gonna be left once the old timer c64 coders depart this Earth (sadly we all do at some point). While online Wikis and such will remain, there's nothing better than Robin explaining and demonstrating it in his cool calm voice. :)

I definitely want to make an episode about LFSRs, a type of pseudo-random number generator. I've used them quite a bit in my games, after hearing that the Atari 2600 classics Pitfall! and River Raid used them.

Thanks for being a part of HVSC, it's awesome! :)

Thanks for watching - or listening! I used to work night shifts too, I'm glad to hear these episodes help a bit.

Thanks, I'll keep making them. Is there a particular subject you think would be helpful to you and other beginners?

@@8_Bit BASIC is a little easier to comprehend for beginners vs machine language. But i understand that it has a lot of limitations, so that limits you on what you can demonstrate. And i do still enjoy the machine language even if I'm not proficient in it

@@thicclink BASIC 2.0 on the C64 is quite limited. All the cool stuff needs at least poking, which often ends up being almost like machine language anyway. If you actually have a C128, you could just stay in C128 mode and use the much richer BASIC 7.0 there.

@Kurt Pedersen It's been 4 months, please allow my reply... When you add or edit a line in a large BASIC program, the computer must move an (increasingly larger) chunk of memory to make room for your new line, then update the hidden links that connect the lines of your program. You must be patient. If you hit STOP / RESTORE before the cursor returns (aborting this memory management process midway) it will corrupt your program. I've done it.

Haha, maybe I need to put "1337 without the bull$#17" on my nametag at the next Vintage Computer Festival I go to :)

Thanks. I didn't even know about "Commodore Disk User" until today, but I found a scan of your contribution here: archive.org/details/commodore-diskuser-19/page/n11 Looks very interesting, nice work!

@@8_Bit Thanks! until recently I thought I'd lost this - things like archive.org are great! The submission was rushed and needs some clarification on getting the demo running(mainly resetting basic at the right time): Run spdriver.bas Make the emulator run faster by selecting Options/5x speed (or max) - the next stages are a bit slow otherwise. Enter “Y” 6 times (down to and including “load chars”). Enter “N” three times to exit the program (i.e. don’t enter data into memory - it will overwrite the basic program itself & error out). Now, reset Basic by selecting Reset/C64-Soft from the File menu Enter: Load “spdriver.bas”,8 to load in the same program Enter “Run” and enter “N” to load programs/data Enter “Y” to enter pattern data into memory, then exit by entering “N” for the next three questions. Reset Basic again by selecting Reset/C64-Soft from the File menu. Enter: Load “plat.bas”,8 to load in the platform encoder program then enter “run” to run the program and enter the 4 demo screens into memory. Take note of the sys call (sys 32771) - the game start location. (almost there...) The sprite data will have been overwritten by now, so we need to load it in again… Reset Basic again by selecting Reset/C64-Soft from the File menu. Enter: Load “spdriver.bas”,8 and enter Run Enter Y,N,N,Y(load sprites), then enter N till you exit the program. Configure the emulator input keys - left/right/up/down and fire. Return the emulation to normal speed Run the demo by entering sys 32771. It was all programmed without an external development system, which makes things a bit cumbersome/difficult. I've only very recently looked into this again and see that we have great utilities like CBM prg Studio and D64Editor, so with these, I'm going to have a look at this again. I don't know if there's any better utilities out there.

Thanks Josh, I will probably do an episode about smooth scrolling. A simple example, such as a horizontal text scroller, shouldn't be overly long. And yes, I'm looking forward to working on some videos about 80-column mode. I've got 2 out of 3 of the things I need - the final piece (RGB to VGA converter) is on a boat from China I believe :)

Or you could scroll the notes of the three channels as being played, like a tracker player.

Thanks, I really appreciate it :)

That's a good idea!

Hearing a foreigner (YOU) trying to pronounce English names is always fun. :)

Was it how I said Mikael? I've got a friend from the USA named the same and that's how he says it! :)

@@8_Bit no worries. Michael, Mikael, Michel and more, lots of different pronunciation in different languages. I'm sure we in Sweden not always pronounce names "correctly" either ("correct" depends on country and accent)

I'm working on a video about controlling sprites by joystick right now!

49152 is $C000 and 40912 is... $9FD0 ? that seems like a weird place to jump to start playing SID music, isn't that in IO space? Or am I still in VIC-20 mode.

It's funny, I've just been curious since even before I got my C64 (that was in 1984) and there just always seems to be something new and interesting to learn about it. I'm still learning something almost every time I make a video, especially during those C128 videos I made last month. I just keep reading old books and magazines, and reading modern articles on the web and forum posts.

It's a cover of Video Killed The Radio Star :)

They do seem to have some similarities in the memory map! I was surprised when I was adapting the 2-Player Karateka patches from the Apple 2 version to C64 how the code was in almost exactly the same place. Offset by 16 bytes, iirc.

Yes, thanks, I expect I'll eventually do an episode with a deeper look at interrupts.

It's difficult to know how in-depth to go with these things, while still covering several examples, and keeping the flow going. This video is more of a "how to" and less of an explainer, I guess. In this case, the reason to use SEI (which stops all IRQ-level interrupts) is to guarantee an interrupt doesn't occur while we're polling $D012. Otherwise an interrupt could happen shortly before scanline $64, and finish afterwards, and we would miss one or more frames of playback, potentially causing the music to stutter or otherwise not sound right.

@@8_Bit True. FWIW, Carl Sagan advocated more details rather than fewer.

I've seen the Final Cartridge a few times. It seems pretty good but yeah, the menu seems to be more of a gimmick that didn't age so well. Even the Super Snapshot menus are a bit annoying now, as they have a little animation you have to wait (a second) for and somewhat strange numbering, but not too bad. I plan to do a video exploring more of the Super Snapshot features.

@@8_Bit My Final Cartridge also seems to dislike my C128, therefore I am looking for alternatives. Yes, a video about the Super Snapshot features would be nice! Generally I like niche videos as well as videos for a broader audience. Perhaps even a video with your friend who likes forth and can show or tell some interesting bits about forth?

Yes, many of the great SID musicians also wrote and tweaked their own music players. In a way it was their secret weapon, as not only were they bringing their composing skills, but also the tricks and features they had included in their players. I think there have been articles and interviews that go fairly in-depth on this subject, but a good video about it would be fascinating.

I still write SID related code for music production :)

It's definitely a good idea to clean up after one's self. Most of the C64 world ignored that, but Loadstar did an excellent job of maintaining that higher standard. These SID files don't work with Craig Chamberlain's SIDPlayer - SIDPlayer files just contain the music data, while these other .sid files contain both the player code and the music data. Kind of inefficient, but it also allowed a wide variety of special features (such as mixed waveforms, squeezing drums and bass into a single track, digital sound effects, and more) that SIDPlayer couldn't do. SIDPlayer has its own unique place in C64 history though, especially in the USA.

@@8_Bit Loadstar did that because it was an environment - docs, program, everything had to return to the main menu. Sometimes it didn't (demos required a hard reset), but for the most part, the user was warned.

Yeah, and I would go one step further, I would also call the stored IRQ vector at the end of my IRQ routine instead of calling that hardcoded $ea31.

Here's a very informative chart comparing many different C64 music editors. Most of them are native: chordian.net/c64editors.htm I used JCH way back when but haven't touched it in 20 years so I don't know if I should recommend it :) I've heard good things about SID Wizard and NinjaTracker.

You're welcome! I'm happy to find an audience for my nerdery :)

@@8_Bit There is a related topic that I would find very interesting, too: How would you go about composing/coding a song for the SID in the first place? Do you use a specialized tool for that or an assembler? Or a combination of both? But I don't know if that could fit into a 30 minutes video.

That's a good video idea, though I was barely competent at it 20 years ago and haven't tried since. If I tackle this subject I'll have to see if one of my friends with some skills would help. To quickly answer your question though, back in the '80s the leading game music composers had their own custom players they had written and tweaked themselves in assembly language, and would punch the instrument and note data in by hand to the assembler or even just a machine language monitor. Eventually more elaborate tools were made called "trackers" that simplified the process. I used one by "JCH".

@@8_Bit That's what I thought, thanks for the quick reply. I would love to see that video if you get the chance to make it!

Good question! This is my current understanding, I'd have to dig into the KERNAL/BASIC disassemblies further to be 100% sure. The C64 has "physical" screen lines that are 40 characters long, but it also tracks logical lines that can be either 40 or 80 characters long - two physical lines linked together using a "link table" that's stored starting at $D9 in memory. When we type RUN, the screen is full of 40 character logical lines. As the 10 PRINT program prints each line, the logical lines are extended to 80 characters each. I'm not entirely sure why this happens, it seems kind of arbitrary, but maybe there's a good reason. Anyway, each time the bottom of the screen is reached, the screen is scrolled up according to the length of the logical line at the TOP of the screen - either one or two rows. Once those 80 character logical lines reach the top of the screen, then it scrolls two rows at a time.

Do you hear the 60-cycle buzz in C64 mode? If so, try: POKE 56325,29 which will roughly double the frequency of the interrupt, and you'll see the cursor flashing faster. I'm curious if it makes an audible difference.

@@8_Bit I would try that but it's in the attic. :-( I can't remember if it does that in C64 mode, but I do know that when you do a FAST in C128 mode it changes from a high pitched sort of "ringing" to a more normal buzz that sounds more like power supply noise. It probably has something to to with the VIC being turned off in FAST mode.

That was one of my questions from my original post leading to this episode. There is a way to detect PAL/NTSC and compensate for the speed in the ISR. However, you can play a PAL SID on an NTSC C64 by adding some bogus cycles to slow down SID play routine triggering but not the other way around meaning you can not play a SID made for NTSC play properly on a PAL C64 with the VIC Interrupt because of the slower ISR on a PAL C64 compared to an NTSC C64.

Yep just gave it a try @desertfish74 and @Tonguç - The CIA interrupt that was shown in the video worked for this piece on PAL hardware. The CIA should have the same ~60Hz when calling the interrupt routine regardless of PAL or NTSC-serving machines, so if music was designed for that then this seems to be the trick. However, as Tonguç already mentioned, the other way around is not so simple.

@@desertfish74 then the solution would be to detect NTSC/PAL and set CIA timer accordingly. 👍

@@desertfish74 Do you have a small example on how to do that?

Lots of good answers here already, but you basically have two options. By the way, you can check $2A6 (678): 0 if you're NTSC, and 1 if PAL. You can adjust the number of cycles between CIA interrupts with $DC04/$DC05 (low/high byte). Take your clock speed of approx. 1,000,000 Hz, divide by 50 or 60 Hz depending on what speed you want, and that's the number of cycles to STA in there. So 1000000/50 = 20000 which is $4E20, so that's #$20 in $DC04 and #$4E in $DC05. If you need to use the raster interrupt to call the music player (some games/demos require it due to timing) then an okay hack is to skip the music player call every 6th frame (so JSR $1003 for 5 frames in a row, then nothing the 6th) to play 50 Hz music on NTSC, or to play 60 Hz music on PAL, JSR $1003 twice every 5th frame. A lot of games and demos simply didn't care and would play the music at the "wrong" speed across the ocean, but as game players we didn't know any better in the '80s and just got used to it.

Yes, a more advanced interrupt system could be created; I'm pretty sure Contiki (a surprisingly advanced C64 OS that was in development 10 or 15 years ago) had a good system although it's been years since I looked into it. GEOS surely had a more elaborate system too.

I found the issue since I'm using an emulator. I have to use LOAD"*",8,1 to read the PRG file containing the SID. Anything typed into a basic listing would automatically overwrite the memory locations where the sid data was stored. If you type the command NEW before entering any BASIC listing you don't have the issue

Does sidplay64 have an export feature like PSID64? That was the main reason I used it, as I wanted to be able to play the songs from my own programs, not just listen to the songs.

They could be made a little faster, yes. But the assumption is of course that loading the game will take long enough that the little time lost loading the music/intro screen is worth it to keep the user entertained during the rest of the load process.

The loader often replaced the default load rutine with a faster one. Many hacks was used to get the game to load faster.

I'll have to study more tape loader code to fully understand it, but my understanding is that it's basically the opposite of what I've shown here: interrupts handle the loading from tape, as they need the higher priority to make sure they don't miss any bits, while the main program plays the music and whatever else. Pretty neat, I'll make sure it's on my list of episode ideas and hopefully I'll get to it.

@@eightsprites i wasn't refering to fast loaders as in how they work but more how the music and intro picture were incorporated into the loading process and if it wasted much time loading the music/picture, some game you can see the time taken to load the picture as it draws the picture as it's loading the data, ocean, activision springs to mind.

750 videos, amazing! Thanks for your insights. I definitely agree with your philosophy. Even that Super Mario Bros. video I mentioned was about the brand-new C64 port of the game, and I was able to bring my own perspective on what made this port so amazing, and show it running on some rare hardware that most people don't have access to. And I was genuinely interested in it all. It's just weird how that video was viewed so many more times than videos that I put 10x the work into. But that's the nature of KZfaq.

@@8_Bit KZfaq is funny. I posted a 4 minute random video of fixing a stuck lens on an old cheap camera and it got 40K views, and it still gets thank you comments years later, hah. I gave up guessing what will have legs after that :)

Darren = Shroom and Robin = Macbeth :)