IRQ-Driven SID Music: Commodore 64 BASIC and Machine Language

[@madpuppet666]

I JUST BOUGHT AN ORIGINAL C64C SO I WILL BE WATCHING A LOT OF THESE VIDEOS!!! Sorry for yelling but I also bought a bottle of spiced rum that I'm halfway through.

[@vytah]

If anyone's wondering why $1000 is the most common address for loading SIDs: VIC cannot read RAM in ranges $1000-$1fff and $9000-$9fff (it sees the character ROM there instead), so if you have a part of memory where you can't put graphics, why not put music in there instead.

[@8_Bit]

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!

[@WarrenMarshallBiz]

I think you should focus on whatever interests YOU. It's your channel. Don't chase views. Everyone and their brother did a Mario videos and, sure, it's cool and all but I'd rather hear about weird BASIC optimizations and assembly tips/tricks and things like that. You've got a head full of history and great commodore content ... keep it coming! :)

[@8_Bit]

Thanks! Definitely good advice.

[@stefanjohansson3578]

More Machine Language videos please, I really like your calm style when explaining and showing things.

[@superx9619]

I have no idea what hes talking about but I watch these vids cuz I find them calming lol

[@azofeclipse]

I feel like that last SID tune is gonna take me back to the past.

[@tiger1x]

When I watched that video some (long) time ago, I didn't understand much what it is about but now I watched it again and I was even able to replace the music player with my own (little) assembler program which is just reading character from $0400, add one to it and write it again there as a background process while running the maze in basic! What a pleasant feeling when you finally understand stuff you didn't some time ago! Thanks Robin for those kind of videos! And since you asked: please more of that kind of videos! I admire those excursions into C64 assembler! 😃

[@JeremyNasmith]

Niche. No question. Loads of content all over YT of Mario etc. There's far too little on what you termed "niche". I know I speak for many of your viewers as well as myself: as a kid, I could see these amazing games, so I knew the C64 was capable of far more than what could be achieved using basic. (Heck, poking a sprite or two into memory and doing a simple "bounce off the walls" program already caused things to crawl)... Most of us didn't have an assembler or the memory map. Most tried listing or favorite game to find simply '10 SYS #####' and wondered how on earth one line of code made Paperboy work. Where was the hidden code? The "good stuff?" Parents had far less of a clue than we did. 33 years later, and I finally start to see how things were done, and what tools were needed!

[@RedSkyHorizon]

Same here

[@Koxi73]

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.

[@bierundkippen720]

I absolutely agree with all of you guys.

[@3vi1J]

I only recently found your channel, but I'm loving the vids in this series. In all my playing around with 65xx assembly, I never thought about using raster timing to benchmark routines - simple and effective... I wish 14 year old me could have seen this! Keep up the great work.

[@RandomInsano2]

I like the trick of changing the background colour on the boarder! It’s a great way to visualize how long the interrupt is running.

[@TimToolman]

Please keep up the knowledge transfer on c64 coding! Of course super mario is going to attract views, but i really appreciate your in depth videos most. Very keen to hear more about interrupts. What happens if one routine runs long, are other interrupts delayed or dropped? Or is the long runner dropped? A full overview on how to understand them would be ace!

[@8_Bit]

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.

[@Mr_ToR]

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

[@werre2]

www.c64-wiki.com/wiki/Raster_interrupt

[@G.B...]

I realize that videos about C64 games are probably going to be more popular, especially when the video is about the remake of a popular hit (like mario). Nevertheless, I think a big part of your audience is here mainly for the assembly videos, myself included. C64 was always a paradise for machine language crunchers. The 6502/10 has a simple yet effective instruction set, and the C64 hardware provides you the tools to make something cool easier than other machines based on the same processor. Not to mention the challenge to make something impressive on a machine with total RAM similar to what a png logo on a website takes. You explain everything in detail, and your assembly videos are great for both old coders and people wanting to learn assembly. We need more videos like this one, e.g. another episode about IRQ-driven applications, or a (pseudo) random number generator not based on SID oscillator 3, or implementing math functions in assembly - you name it.

[@8_Bit]

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.

[@miserychordia]

i really like how you go in depth on the commodore..back in the 80's i was kind of a "lamer" who only played games, i had a hard time figuring out programming..or "what to do with it"... watching you explain it makes me more and more curious about learning how to program .also you have a really nice voice so it's really relaxing to watch your videos!

[@johnrickard8512]

Man the C64 was a surprisingly well specced computer for its time. No wonder it was so popular!

[@artisticgoose2609]

Your coding tips are the dogs bolox, sir! Keep up the good work. love it

[@86Carrera911]

Another great video! I'm just getting going on programming in 6510 assembly. I've decided to use the setup you use, even though I currently don't have a Commodore computer (it's on the way!). The program that I think I want to make is one that exercises the SID to help me investigate the different sounds that it can make by varying the ADSR values. I'd like to use the keyboard to control the values and display the values along with some text to put the values into context, so I know what I'm looking at. I'd be interested in seeing some videos on creating strings in assembly, displaying them on the screen, getting input from the keyboard, and some of the basics of creating your own sounds and music with the SID. Cheers!

[@Breakfast_of_Champions]

Robin you are elite without the bullshit! I've always wished for a normal person to explain these more intricate things about the 64 👍

[@8_Bit]

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

[@00Skyfox]

I’d say please keep up these niche programming videos. Knowing all these little programming tricks and what the various memory registers are for is a fading knowledge that will be lost to time if experts like you aren’t around to teach the next generation of enthusiasts. Videos have much more of a human touch than simply reading a book or programmers reference guide and can go into much more detail.

[@BillAnt]

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. :)

[@chromosundrift]

I love the machine language coding videos best

[@darkstatehk]

This is quickly becoming one of my favourite must watch channels!

[@velthoenify]

This channel is getting better with each new video. Keep up the good work!

[@LatherFace]

Some of this was over my head, but I still watched it twice because it was oddly relaxing.

[@Jobjoossen]

These videos might not get that many vieuw, but they are GOLD to the ppl watching them. As somebody trying to figure this out in 2024 it is an amazing source of information. Even having "mapping the C64" requires somebody to explain the mechanisms, at least for me it is. And you do it really wel Thank you

[@jameshyde6395]

keep up the video's they really are appreciated. you are a treasure to the C64 community, long live the commodore 64!

[@MichaelBLive]

I love ALL the videos! Especially the niche ones.

[@75slaine]

Excellent yet again Robin, always learn something new on this channel.

[@LivingInAVan]

This is a excellent video and you are great at producing tutorials. Keep up the excellent work!

[@elmariachi5133]

I like the unedited end better than the rest, because when trying to learn from you, one sometimes needs a few seconds for thinking about. So one can watch the end fluently, while the rest has to be paused, resumed and repeated all the time, for gathering more of that dense information.

[@pauldeane8369]

Watched this when you first posted, great video. I really learned a lot recently when I needed to use a SID file for my own project. Thanks for this!! so helpful!!

[@fluffyfoxbunny]

This is awesome, these are the best C64 assembly tutorials, and I'd love to see more, especially maybe a series on making a simple game in ASM with sprite movement, controls and stuff? Either way it's great to see this stuff presented in a way that doesn't make my head spin

[@shieladixon]

Thanks Robin. More niche! Don't chase the views. But whatever, I really enjoy what you do. Keep doing it.

[@inphanta]

Fascinating, I definitely enjoy your niche C64 videos. 6502 has always seemed like a black art to me, but in seeing you break it down like this, it's slowly making sense.

[@borismatesin]

This is by far the most succinct explanation on both how to set up a minimal player and how raster (and stable raster) interrupts work. I need to rewatch this with an open emulator (or actual machine) and start messing with players pronto.

[@ProjectGeek1]

So weird! I've been spending all week getting SID files to play on my C64. This helps!

[@75slaine]

And I love niche stuff, plenty of other channels cover the big ticket items and while I like to hear your take on it, it’s not why I come here.

[@econtrerasd]

Boy!, many years ago I did c64 programing and I had absolutely no idea on how to add music (I mean decent music) to my programs, this is one more mystery unraveled for me.. well now I need to solve another mystery which is how to create decent sid music!! ha ha!!

[@SteveGuidi]

Thank you for another great and informative video, Robin. Back in the day, I use to rip music from various intros and demos, releasing a disk of sid music every now and then. A fellow BBS'er wrote a machine language routine for me that would play the music, and I wrote a BASIC front-end to drive the player with play/stop/load operations. I had no understanding of ML at the time and I would often think his routine was some low-level complicated magic! But after watching your demonstration, its much clearer how his "magic" was done :)

[@Nelwyn]

I enjoy videos like this. I never learned to program in machine language, but I did fiddle around with basic quite a bit. Even though I don't really understand what you're doing it's still interesting to watch.

[@shieladixon]

I discovered by accident recently that VLC for Mac plays .sid files, you can just drag and drop them onto VLC. I assumed that a .sid just contained the music data in a standard format, so it's fascinating to see that there's a lot more to it than that.

[@laurent64]

One neat stuff to try is to copy ~200 bytes from the SID player memory (i think it's around $1600 or $1700 in your example) to the screen $0400 in the ISR when you call $1003. That way you see the internal SID player variables change as it is playing the tune (fetching pattern data/notes, modulating instruments, etc). Quite a lot of fun ! :) you can then use this info to synchronize some visual effects to the music like flashing the screen each time a snare is played...

[@BillAnt]

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

[@KennethSorling]

Thanks for this! I'd like to understand how these chiptunes are constructed. Is the bulk of it "sheet music" data which a tight loop reads and pokes into the appropritate SID chip registers? Or are they a sequence of machine code instructions which achieve the same result with explicit 6502 commands? I suspect it's the former, since that way they can be loaded into a sequencer/tracker and edited. But if so, what is the data format? Is it run-length compressible (which would be cool, since you can pack in more music that way)? I realize entire books can be written on the subject, but just a hint of a little bit of insight would go a long way.

[@8_Bit]

It varies, but typically there's a main music player routine that is data driven. In the early days, each C64 musician coded their own player and defined their own data structures to represent the music. New features and improvements were added to their players as the music demanded. Eventually some of these players and corresponding editors (each one custom for the player, there's no standard) were shared publicly so other musicians would use them. The data format varied by player, but typically you'd have note data that would get combined into blocks, and then those blocks would get combined into a song, to make it efficient to repeat parts. RLE would be possible but I don't know of any that do that on the fly; most games are more CPU-bound than RAM bound so keeping the music player as CPU-efficient as possible is the priority.

[@KennethSorling]

@@8_Bit Great answer! Thanks for taking the time to reply.

[@jamesrbrindle]

Learned some things I didn’t know about raster programming on the c64 from this. Used to write demos and cracktros back in the 80’s but never really understood the system.

[@8-bit-dust]

On vacation having a look at the code on c64c. You mention in the video when setting up raster line for the interrupt that one might get away with not setting the most significant bit for the raster in $d011. I found if this is not done the interrupt seems entered just once and then you get a hang. Maybe in earlier c64 models you can get away with it but better do it right.

[@josugambee3701]

When I play with my dad's old C128, I always love to turn the sound volume all the way up. There's a lot of digital noise that gets onto the audio output, and it's interesting to hear activity from the processor. A distinct component of that noise is a 60-cycle buzz that seems to change depending on what mode the computer is in, and I've always wondered why. It must have something to do with that interrupt, and the processor running code about 60 times a second.

[@8_Bit]

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.

[@josugambee3701]

@@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.

[@mikegarland4500]

These are just immensely informative. Enjoying every one of them so far. Thank you!!! (I have my VICE emulator running, and usually either the built-in monitor feature, as well as CBM prg Studio, open at the same time so I can follow along with the videos. Plus, I've got Notepad++ open in the background so I can take notes.) I can't tell you how many books and videos I've watched that tried to explain about this, and previous topics you've done in this series, but they never really made sense. Until now. You have a style that builds on current topics and keeps branching logically through variations that are not on interesting but helpful. You're not afraid to show and example, then explain why it might not be the best option, but it's there if you want to use it. I tend to work through code in a very similar way, and your approach is very easy to follow and build upon previous stuff.

[@rev.davemoorman3883]

I'm taking note - because I might get back into the fray! One thing - I made it a point to copy the original vector, tuck it away, and set a flag (switch). When the execute is called a second time (the switch is set), it is good to put the IRQ vector back where it is supposed to be. BTW, do these SID files work with Chamberlain's SIDPlayer?

[@8_Bit]

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.

[@rev.davemoorman3883]

@@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.

[@-Jakob-]

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.

[@axemanracing6222]

Most music files that are found on old disks need a SYS command to start the sound from BASIC. SYS49152 and SYS40912 are the most common jumps.

[@AureliusR]

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.

[@tiikoni8742]

Great video, but completely unrelated question: At 17:55 basic program drawing the maze makes screen scroll one row at the time when reaching bottom. Until after screen is full, it starts scrolling screen two rows each time it reaches the bottom of screen. Why is that, why it doesn't just keep going one row at the time?

[@8_Bit]

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.

[@TechLord79]

What an amazingly thorough video and also great book suggestion, many thanks! I wished someone like you would make a stable raster interrupt video some time. There is a lot of info on the net but it always eludes me, feels like stuff from electrical engineers that inhaled C64 timing diagrams and such :D

[@LaLa-6581]

Just discovered this. Fantastic explanation, clear and easy to understand with all the visual aids. Nicely done! (NB: I used to be in the HVSC Crew, so cheers for mentioning the HVSC, too. ;-)

[@8_Bit]

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

Just subbed, great video, very well explained. This brings back old but fun memories. I contributed Sprite Driver to CDU then which also included components helping you to create platform style games (the sprite driver component itself was interrupt driven). This was an exciting time when 'bedroom programming' had just started, no internet, learning through self-innovation due to minimal programming examples available. Huge contrast with today where the internet/Google has made such an immense change with places like stack exchange etc allowing you to pretty much program by cut-and-paste, in many cases without needing to know how the replies to your questions actually work.

[@8_Bit]

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.

[@hugovangalen]

I like all the videos you do and in fact I prefer the so-called niche stuff over Mario! (I used to program the C64 as a kid; in fact, that's why I am now a software engineer.) Your videos are entertaining and you often manage to show a thing or two that I never knew about. Thanks for your videos and keep them coming. :)

[@thamessinclair2010]

Worth mentioning might be that the vector at $0314 is already jumped to by the KERNAL. If you do a game or demo completely in machine language and don't care about BASIC running alongside, but want to completely own the interrupt handling, you need to utilize the vector at $FFFE, which is where the CPU's program counter directly is set to once an interrupt occurs. It returns to its previous state (the location where it was interrupted from) with the RTI command, which is the actual _ReTurn from Interrupt_. This is important to know to fully understand how interrupts are handled. Usually the memory setup in the register mapped into memory at $0001 switches the HIRAM area to ROM, so $FFFE contains the ROM content pointing to the KERNAL's own early interrupt handler which only later in the process does a JMP ($0314). If you change Bit 1 of $0001 to 0, the CPU sees the RAM bank at $FFFE, where you can setup your own vector. You have to take care then to put the current CPU register's content onto stack first, before you use them for anything else, so you can restore them before returning from interrupt (just as the KERNAL routine does).

[@8_Bit]

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

[@saganandroid4175]

8:32 after watching this many many times, I really think this explanation works for those who already know. You never state why SEI, and then it kind of goes astray from there. it's possible to be so into something that you forget how to explain it to a person new to it.

[@8_Bit]

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.

[@saganandroid4175]

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

[@tapmantwo]

Just watched this for the second time - thank you! I still don't 100% get interupts, but your explanation helped me fix up some code.

[@garymetheringham4990]

is this how tape loaders work that play music? do they load the sid file start it playing, then load the screen intro picture hence the scrolling load then the game part last. if so could a tape game load a lot faster if it wasn't for the loader? could you do a video on how they work?

[@Gameboygenius]

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.

[@eightsprites]

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

[@8_Bit]

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.

[@garymetheringham4990]

@@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.

[@furroy]

i love the niche videos! in fact if you could do one on reading the joystick and keyboard at the same time from assembly that would be awesome!

[@8_Bit]

That's a good idea!

[@JohnKerrashVirgo]

Absolutely love the obscure niche things! Keep them coming 😄

[@JesusisJesus]

Although I am borrowing SID’s username and icon, I have to admit I know very little about the SID chip and pretty much everything explained in this video, but I am slowly learning from these videos and one day I’ll understand it enough to get 2 or more SIDs cranking along.

[@evileyeball]

That was pretty neat. I haven't done any assembly since back in my university days when I had to take a course on it. I subscribed because I enjoy watching neat stuff like this or well mostly listening to help keep myself awake on long night shift nights.

[@8_Bit]

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

[@TaramiBedona]

I, too, like these "niche" videos. As a software developer with long hours already, I try to have hobbies other than sitting even more at the computer, but it's really refreshing being walked through older computer architectures like this. I'm always amazed with how much was done with so little. :) I'd love a video on hardware (is there really any other kind?) sprites on the C64!

[@8_Bit]

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

[@saganandroid4175]

Robin at 1:42 can you include a link to that web site ( screenshot on the left). At about 4:51 you say the first jump is ti "initialize the player". What's actually going on?

[@8_Bit]

re: link, sure, I think it's this one: hvsc.c64.org/players It's just a subpage from the HVSC link in this video description.

[@8_Bit]

re: initializing the player, pretty much every C64 tune has a subroutine that needs to be called once, which initializes RAM, the SID, and whatever else needs to be done one time, before the song starts. Then the 2nd subroutine is what actually produces the music when called repeatedly.

[@saganandroid4175]

@@8_Bit Ah! By initializing RAM, I'm guessing that means housekeeping for the player routine itself, starting player-related counters at 0, etc. BTW have you done any videos on how to use CIA interrupts for different things? Like a 50Hz Interrupts for NTSC C64s? Or the TOD alarm that is consistent regardless of PAL/NTSC?

[@jack002tuber]

Love the video. I like interrupts too. I remember the first time I saw a sprite cloud moving and basic was all working. The top of basic is held in the pointer start of basic, or SOB for short. Once you hear SOB, you never forget. LOL

[@timrichter1980]

The Super Snapshot cartridge seems to be good. I wish my Final Cartridge was a bit better, the menu system was cool in the 80s but it is more standing in the way than helping

[@8_Bit]

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.

[@timrichter1980]

@@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?

[@bloodmapedit]

"Video killed the Complex Interface Adapter star" when it comes to timing that is....

[@eugenetswong]

I appreciate the niche stuff more. Thanks from BC, Robin.

[@StevenWalter]

A video on the kernel ROM's interrupt handling would be very cool!

[@jeffryan7672]

Thanks for making this video Robin! Exactly what I need to do in my curling game. Gonna try this ASAP!

[@stunthumb]

Makes me miss coding on the ST - I did some stuff on the C64 but SID stuff was a bit beyond me. Nowadays when I think, I want to play tracker style music, and trying to get a native code tracker player working nicely is a pain in the butt. I miss the reliability of IRQ interrupts, the cool tricks we could pull with them made us feel bad ass :)

[@raulrrojas]

How did you do to learn all this? Its amazing how in deep you understand this computer, yet amazing as well seing this series of videos to realize that a computer we tend to percieve as simple and basic is in fact very complex to understand! Thank you!

[@8_Bit]

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.

[@madcommodore]

I think the original SIDplay is born from the work of the Amiga demo called "100 most remembered C64 games" which came before the standalone SID player for Amiga...which I think predates all others.

[@tonym2464]

Hi Robin. I've been following along and using Turbo pro direct on a C64 which has been fun. If I wanted to cross-assemble (for modern convience) for the C64 on Linux, Mac, or Windows what are my best options in 2019?

[@8_Bit]

cc65 is tried and true and is multi-platform. On Windows there's CBM PRG Studio. There's a bunch of other assemblers that have their fanbase that I've only used briefly to get a small task done (someone asking me for help with their source code). There are also some fascinating new languages that I've been meaning to try out but haven't yet, like Turbo Rascal Syntax Error and Pas6502 that I haven't tried yet.

[@arthurjordison5392]

@@8_Bit HI Robin. Thanks for mentioning CBM Prg Studio! Really enjoy your output, if only this information was available to me back in the day. It took me a long time to get an interrupt working!

[@tonym2464]

@@desertfish74 thanks for the info

[@tonym2464]

@@8_Bit Thanks for the info.

[@csbruce]

@@8_Bit wrote «Turbo Rascal Syntax Error». Is that a machine translation from a different language?!

[@piggypiggypig1746]

I like your approach to assembly. Some creators use cross assemblers on PC and use variable names for all their hex locations. It might be nice for the programmer but its not so easy to follow.

[@8_Bit]

Yeah, since this routine was short I thought I'd show how it's done in a machine language monitor. In the following episode (about moving a sprite with joystick) I used the native Turbo Macro Pro assembler, but try to keep the label use to a minimum as I find it makes it more complicated to explain.

[@piggypiggypig1746]

@@8_Bit Thanks for the reply. No I think your approach is great, don't change it. I've been following your for a good while now and see that you using the Turbo Pro. Its easy enough to follow with the labels, no complaints there. Just some guys like to use conditional assembly on the PC and use labels for everything. It ends up looking very high level and thus its hard to understand whats going on at the machine level if you see what I mean. BTW I typed in your program from a previous video of yours. Six digit score counting. Worked like a charm on the PET 4032. I've been wanting to know how for the longest time. Cheers. :)

[@MMSZoli]

Very nice video! My main platform is Plus/4, so as we have SID card too(with the same or different base address as the original SID) I try to utilize it in my programs too. The two system has a lot of similarities, except instead of the lot of special chips the TED IC does them all (gfx, sound, raster interrupts, keyboard and joy handling, RAM refresh, etc), it was JAck's idea, but I think he got the idea from the ZX Spectrum ULA. I am not a super programmer, but can do few things in BASIC. It will be great to play SID music in the background of my Plus/4 BASIC program. One further issue is that $1000 is the usual BASIC start address on 264 platform, so I think it could be better to relocate the SID music and rewrite the code with the new addresses to eg. $A000 from $1000. (though when we switch on GRAPHIC command, it automatically redefineds the BASIC start address to $4000, so a memory area between $1000-1800 is free on this machine for the music. I have to choose a short one :-) ) Only one question: why not play the music at the border area? there is no VIC activity, so the CPU has a little more time to run the code, means will influence less the speed of BASIC (if I well understand how it works). On the 264 platform the CPU is 2x faster on the border, I am not fully confident what is the case in C64.

[@Chriva]

Hearing a foreigner trying to pronounce Swedish names is always fun. :)

[@HuntersMoon78]

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

[@8_Bit]

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

[@bennylloyd-willner9667]

@@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)

[@steiniapproved]

Thank you so much for this kind of videos! This video helped me a lot to understand the internals of the C64, usage of assembler, and SID playback. Before, I wondered if the SID plays back music by itself or if there is an active loop to do so; question answered. :-) But does it mean, every SID musician back then had to provide his own (or code from another musician) player for the use in a certain game? Were SID musicians masters of coding and fine tuning the player code too, in addition to create awesome music?

[@8_Bit]

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.

[@whisk0r]

I still write SID related code for music production :)

[@williamsquires3070]

Hey, waiddaminnit! 0x0800 was the beginning of memory for AppleSoft BASIC on the Apple ][+, too... 🤣

[@8_Bit]

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.

[@joshhiner729]

I love your niche videos. Very interesting/riveting. Great episode. Watched many pieces twice so it sank in. The raster interrupt portion was my favorite part. Believe thats part of how smooth scrolling works. Would be a great episode (smooth scrolling) but maybe too long. Also cant wait for an 80 column mode video. I remember you mentioning the hardware was on the way. Sure hope you get to that too. Anyways keep up the excellent videos.

[@8_Bit]

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 :)

[@fitfogey]

This is my favorite youtube channel.

[@8_Bit]

Thanks, I really appreciate it :)

[@csbruce]

1:04 Super Snapshot V5 - "Made in Canada!" 3:29 "Author: Shroom & Macbeth". Are you Shroom or Macbeth? 4:04 The floating hand is able to type on the Mac computer using telepathy! 4:40 They should have designed three calls: +0 Startup, +3 Shutdown, +6 play next jiffy. 5:02 The HELP key on you keyboard looks like it could use a little help. 7:39 A better way to implement playback synchronized to real-time jiffies in BASIC would be to use the TI pseudo-variable: 10 POKE 780,0:SYS 4096 15 TI$="000000":TW=1 20 SYS 4099 30 IF TI < TW THEN 30 40 TW=TW+1:GOTO 20 The caveats are that this will fail after 24 hours of playback and the first sound will play for 0 ≤ t ≤ 1 jiffies. 8:25 Your program won't conflict with other data in the program space since it only has a couple of scalar variables and doesn't use strings. 9:41 The 6502 documentation says that the INC/DEC instructions stand for Increment/Decrement. You use the proper term at 16:55. 10:13 In principle, your routine could play two or more jiffies worth of sound if a call were to take less than 65 clock cycles. Also, some "bad" scanlines would be hard to catch by polling with an equality comparison. 11:40 Trivia question: on a stock C64, how can you read the content of RAM location 0? (Note: the RAM content, not the processor-I/O-register content.) 12:17 You could unintentionally catch the player while it's actually doing something, before it has restored zero page. 13:54 You could note that ($0314) is a secondary vector. When an IRQ is accepted by the 6510, it jumps through the hardware vector ($FFFE), to code that finishes with a JMP ($0314). 15:36 Um, LDA $C0 is not the same as LDA #$C0… C64 crash coming in 3… 2… 1… Oh, you caught it! Although your comment refers to #$80 instead of #$C0 - off by magic number 64! 16:18 "Clear Interrupt Disable" always sounded strange to me. They probably could have just as easily reversed the logic in the chip to make it an Interrupt *Enable* flag. 18:11 They probably should have used a scanline IRQ, though this would have created a discrepancy between NTSC and PAL for system services. I imagine they used the CIA simply because the C64 ROM is almost a carbon copy of the VIC-20 ROM and the VIC-I chip didn't have a scanline interrupt. They should still have been able to synchronize the CIA/VIA timer to a scanline perfectly, however, even on a VIC-20. Maybe they were targeting a nearly perfect 60 Hz instead of the NTSC VIC-II's 59.82 Hz. I would guess that most NTSC SIDs are actually written for 59.82 Hz instead of 60.00 Hz since most games sophisticated to use SIDs would also use scanline interrupts. 19:44 You could also move down the top of BASIC and put your SID in higher memory. I've always used the terms "bottom" and "top" to mean "start" and "end" of BASIC, probably because there are associated Kernal jump-table functions named MEMBOT and MEMTOP. 22:38 Once the CIA interrupts are stopped at the source, I don't think the sequence or timing of the LDA $DC0D:SEI matters. In fact, the SEI is redundant if we assume there is no other possible source of IRQs at that time, though it's best to be cautious. Even the LDA $DC0D is redundant if IRQs are enabled in the processor since any pending IRQ would assert itself immediately, before we alter the interrupt vector. 22:58 You should probably set the raster scanline before enabling the interrupts to avoid a spurious IRQ from the wrong scanline. You could also acknowledge any pre-existing scanline interrupts. 23:05 You would normally use something like scanline 250 to make the execution of the IRQ service routine overlap the bottom border of the screen to avoid "video tearing" in your screen-content updates during a video game, or even in business software. 23:35 You can get away with setting only the low-byte as long as the 9th bit is already set to 0, which I assume would always be the case under normal circumstances. But if it were a '1', then the VIC would only interrupt on scanline $164 = 356, which would never be reached on either NTSC or PAL, so… never. 24:40 Doing an INC $D019 doesn't seem like a good way to acknowledge an IRQ. Logically, it shouldn't work because you'd read a $81 and write back a $82, which acknowledges the wrong IRQ source. It only works because of a quirk/bug in the 6510 where the Read-Modify-Write INC instruction will write back the original value verbatim on its penultimate clock cycle. This method might not play well with upgrade processors. 28:14 "If you want me to make the more niche videos…" just watch these videos and all ads all the way through 100 times each. Maybe it's the length of my comments that flags them as being "spam". No non-robot would make such a detailed comment on KZbin!

[@thamessinclair2010]

Hehe, almost exactly my thoughts through the video. However I'd like to know the answer to your trivia question. How can you read the RAM content at $0000? Maybe with LDX #$01 and then LDA $FFFF,X ...?

[@csbruce]

@@thamessinclair2010: Any method using the CPU, including indexed or indirect addressing, is going to be directed to the I/O register mapped to address 0. The REU could do the job, since it accesses the RAM directly and doesn't see an internal register in the CPU, but an REU is not part of a "stock" C64. The VIC chip also sees raw RAM instead of the I/O register, but how do you read out a byte value from RAM using it?

[@csbruce]

@@thamessinclair2010: To read the memory using the VIC chip, you can set the bitmap display to use location $0000 so that the first eight pixels of the screen show the binary content of location $0000 and then set one pixel in a sprite on and move the sprite so that the lit pixel collides with each bit of RAM location $0000 in turn and check for sprite-to-display collisions to read out the content of location 0. You could also set up all eight sprites to collide with the appropriate bit of location 0 and read out all eight bits in the sprite-collision register as a coherent byte value.

[@thamessinclair2010]

@@csbruce This is a very beautiful hack. :)

[@MorreskiBear]

@@csbruce OMG that's exactly what I thought of back in the 90's, but not for location zero. You seem quite "in the know" about the C64, so I'm sure you've heard of the SuperCPU, and that by default, all writes to SuperCPU memory are mirrored to C64 RAM as well. This is solely for the benefit of the VIC, as it cannot see the SuperCPU's onboard memory. Now, one can set one of many "optimization modes" in the SCPU registers, to dictate *which* areas of memory to mirror, and the less the better, as it must slow down to 1Mhz to do the write, and the write buffer is only 1 byte large, so multiple writes in a row is a big slowdown. But you probably already know this. Here's the cool part, kinda useless, but cool. Okay. Mirror all memory. Load in your font to $2000 and sprites to $2800 to $3FFF. Switch to the tightest memory mirroring scheme ($0400 basic screen only?) and go ahead, and load in data, tables, routines, whatever right over top of the stuff at $2000-3FFF. The font and sprites should not be corrupted by this. Dual function memory! And, if for some reason, you needed or wanted to READ that "hidden" graphics data, the eight single-dot sprites & collision trick should work, albeit terribly slow - 60 bytes per second? Never tried it, but logic tells me this is how it would work.

[@saganandroid4175]

At 14:15 you ask if this might be good stuff for it's own episode. Yes please!

[@pegu06]

sidplay64 has an integrated file browser and sid player. No need to convert your sids to prgs

[@8_Bit]

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.

[@RonnyOlufsen]

wow! this is inspiring stuff!

[@paulkocyla1343]

The niche videos are the coolest. This is where the magic happens ;)

[@awilliams1701]

If the CIA is doing the interrupt based on a timer and the VIC is doing it based on video refresh rates wouldn't the CIA be the better option since it wouldn't be PAL NTSC dependent and then you get the same music on both computer types?

[@8_Bit]

The CIA would be a good choice, but most games and demos are already running code that's synced to the video refresh, and the display will glitch if it's not run at the correct scanline. If you introduce an asynchronous interrupt, such as the CIA, then sometimes the music routine will be executing when the raster (VIC) interrupt needs to be serviced, and the screen will glitch.

[@DAVIDGREGORYKERR]

If you have a Linux powered computer then it might be possible to add the 6502 compiler tool-chain which will allow you to write programs for the COMMODORE C64.

[@Mr_ToR]

Hey Robin Thnx a lot :-) That was really awesome. I have one question. At 21:47 you indicate that to kill the CIA interrupts you have to write $7F to $DC00, which is 01111111 in binary. Which means only Bit 0 is set to 0 and Bit1~Bit7 are set to 1. Also setting Bit 7 to 1 means 'bits written with 1 will be set' but what will they be set to? I mean that can't be 1 bec. they are already set to 1 so does that mean they will be set to 0? then why not write $00 to $DC00 to begin with? This was very confusing to me. What is the significance of setting only Bit 0 to 0, which the book shows as only disabling Timer A of CIA and it seems like it's not disabling or killing the CIA interrupts like you've said but only the Timer A of CIA, I mean why not Timer B for example, you know? What's really going on there?

[@Mr_ToR]

oh wait, it's the other way around right :-) you're only setting Bit 7 to 0 which sets all other bits which are 1 to 0 i guess right? That's actually how I did in my code too if I can remember correctly :-) I still have to relocate a SID to a different location in memory to avoid incompatibility with loading a KOALA picture from BASIC too :-)

[@8_Bit]

Yes, we're setting bit 7 to 0 which sets all the other bits to 0. You're right that it's kind of weird/confusing. So many things I could make in-depth videos about, but so little time! :) I'll put that subject on my very long list of videos to make...

[@thamessinclair2010]

@@Mr_ToR The way this works is, on a write operation, Bits 0 to 6 mask which bits of the register should take the value of Bit 7. This way, you don't need to first read out its content and perform some boolean logic to set or clear the respective bit, but can switch them in one simple write operation. Reading would also clear the content of the register, which is meant for acknowledging an interrupt and should only happen once after it occured (or on initializing the interrupt setup). This is also explained in "Mapping the Commodore 64", just not in the snippet shown in the video. :)

[@Mr_ToR]

@@thamessinclair2010 Awesome Thnx

[@quantass]

@8-Bit Show and Tell, you should do an episode on C64 Disk Copy Protection types. I recall various techniques being implemented to thwart copying requiring clever assembly workarounds or even hardware copying. It would be greatly appreciated to get your explanation on all this. And for the record, NICHE.

[@8_Bit]

A very interesting topic, but I don't know that subject deeply, so I'll have to study up or enlist the help of a friend. There would be so much to say, I'd probably have to just focus on one or two techniques in a video. I'll put it on my list, but it might be a fair while before I get to it.

[@saganandroid4175]

Can you show us how to set a 50Hz interrupt (CIA?) on NTSC machines so we can use it to play European SIDs at a less ridiculous speed?

[@8_Bit]

Yeah, if you use the CIA method I show around 13:30, you can just POKE 56325,77 (or ML equivalent) to slow down the system CIA to about 50 Hz. POKE 56325,65 to set it back to normal 60 Hz. Note that the BASIC cursor will flash slower with this hack too.

[@saganandroid4175]

@@8_Bit WOW! I look forward to trying this once I have a C64 and all the software I need to start assembly language. Can you do a short video showing that this really is a way for getting NTSC machines to play PAL SIDs at a more normal speed?

[@Sultaneous]

I have some confusion about start addresses. "*=" is a compiler directive for the code location; but where does it put this in the compiled code? If I compile a 6502 asm file with a cross compiler like 64tass, and look at the bin output, there is no memory location specified. Also, I can't find an opcode that sets the code location. If I disassemble a program on the C64 using a monitor, there is no directive that tells the code where it is to be loaded. In short, if I specify "*=$C000" in my program, how is that being communicated to the C64 for when it loads it? Or does the C64 just start everything at $1000 when one uses LOAD"MYCODE",8,1 ?

[@Sultaneous]

Wait, I think I figured it out. The fist two bytes of the bin output is the LSB, MSB of the start location, right? Not quite sure... how would the C64 know if I change code locations in my program later on -> how does it know it is a new code location, and not opcodes to execute.. for example, if I start with a "*=$8000" and later in the source use a "*=$C000" how would it know to change to that location when loading, or is that even legal. Sorry; it's just hard to find resources on this.

[@8_Bit]

Yes, the first two bytes of a PRG file are the load address in low, high byte order. If you LOAD "FILE",8,1 then the file will be loaded to that address specified. If you LOAD "FILE",8 then the load address is ignored, and the file is loaded to the start address of BASIC which defaults to $0801 on the C64. Multiple load addresses within one file are not directly supported, in the case of your *=$8000 and then *=$C000 example. The simplest solution is to save those to two separate PRG files and have one of the two load the other - or have a simple BASIC boot program which loads both from disk and then SYS to start them.

[@8_Bit]

A second *= in a program would cause the assembler to start assembling to that new location, but C64 KERNAL LOADs don't support loading beyond the end of BASIC ($9FFF) so that wouldn't work if you want it all in a single file, plus you'd have all that wasted space filled with zeros between e.g. $8xxxx and $C000. A common solution to this problem is to use a packer/cruncher with linker which will compress this all down into a single file, and then unpack the various parts to the correct parts of memory. Check out Exomizer as one of the best solutions to this problem - it runs on Windows, Mac, Linux, or if you're keeping everything C64 native, search csdb.dk for "cruncher", for example one of Cruel Cruncher's many variations.

[@BillAnt]

In Turbo Macro Pro, is it possible to copy and paste or load a code snippet from a file in the assembler, or edit the assembler file on a PC like in a text edit or something similar?

[@8_Bit]

You can copy and paste within your file with the commands in the "block" menu (back arrow B). You can save PETSCII files with the back arrow W (write) command. These are SEQ (sequential) files that are basically like .txt files on a PC. They can be loaded/inserted into your source program with the back arrow E (enter) command. The SEQ files can be converted back and forth into true ASCII .txt files with the "petcat" command line program that's included with VICE.

[@BillAnt]

​​ @8_Bit - That's really cool, good to know that it's possible to convert a source SEQ file to ASCII, edit it in Notepad++ on a PC, then back into a SEQ source file. When pasting a block with the Back arrow W, can you specify the location of the pasted file within your current source code in memory or just appends it at the end?

[@8_Bit]

@@BillAnt It should insert the text at the current cursor position.

[@MrThomashorst]

You could do the supreme discipline ... Paralax Softscroller with 4 switching Charsets :-) ... that was the aha moment for me in the old days

[@JustWasted3HoursHere]

Hi, 8-Bit S&T! I was wondering if you'd be interested in doing some really in-depth assembler tutorials on the C64, especially using one of the more modern "user friendly" assemblers for the system that make coding not too much more difficult than BASIC (but with a LOT more control). Years ago I had an assembler for the 64 called MAE (Macro Assembler Editor) and I seem to remember it was quite flexible and almost BASIC-like (using macros, etc to emulate label jumps and so on). I know using asm is extremely niche, but on these older systems it's almost a necessity if you want any sort of performance out of your program.

[@esshahn]

Great video Robin, cheers.

[@tommik1283]

Interesting there is no slowdown in playback whatsoever.. On ZX Spectrum I experienced slowdowns when AY music was playing especially in games with music added to 48k only titles years later like Commando or Action Force 2. I am quite sure it has to do with this IRQ based system.

[@8_Bit]

Yeah, this IRQ-driven music will play at a very steady rate with no slow downs, though it is stealing some CPU time so the main BASIC program will be running a bit slower than usual.

[@csbruce]

A quick lookup of the stock ZX Spectrum says that it uses a 1-bit I/O-register value to control its speaker, which means that the CPU has to change this value twice for every sound wave, or thousands of times per second. This makes it difficult to do other things at the same time, like run a video game. The C64, OTOH, will keep playing up to three simultaneous frequencies you program into its SID chip, plus effects, while the CPU does other things. This makes it possible to play sophisticated music by making only minor tweaks to the SID registers every 1/50th of a second, or maybe even slower. This aligns well with interrupt processing.

[@tommik1283]

@@csbruce I meant ZX Spectrum with the AY sound chip not the stock beeper onboard. Even with the AY sound chip there are sometimes slowdowns in music playback as I stated.

[@tommik1283]

Right, after some discussion on Spectrum forum it seems the 48k games sometime disable interrupts so that the beeper sound does not get distorted or/and they use any cycles left just to render the screen, and even use Z80 CPU stack to fast-write to screen meaning no IRQ enabled to avoid data corruption... With 128k games programmers should really take into account there is an AY sound chip and do the routines "Commodore way"...(?)

[@Mr_ToR]

Hi Robin, I'm having an interesting problem. I'm trying to programmatically stop the SID playback then load a game. If Interrupt vectors are not set back to $EA31, it crashes when I load a game. But when I set vectors back, it exits the basic program. I tried POKEing and SYSing but none worked. How can I set the interrupt handler back to $EA31 and still keep basic running? Whatever I do, it always stops the basic program and clears the screen. This is my ISR: INC $D019 LDA #$0 CMP mem BEQ handler JSR PlaySID handler JMP $EA31 mem is normally 1 so if I do a poke mem,0 from basic then the playback stops, However, when I load a game, mem becomes something, which causes ISR jump to PlaySID address and it crashes from there. So I tried to set the interrupt vectors back to $EA31. I made a subroutine which I call from my basic program with SYS to its address. It sets the vectors back to $EA31 and also disables the raster interrupt but always exits the basic program. I tried JMP $EA31, RTS, SEI~CLI nothing worked. Is it possible to keep basic running while setting the interrupt vectors back to $EA31?

[@8_Bit]

Hi! :) I wrote this little routine and it seems to disable the music and interrupts fine, and allows BASIC to keep running: LDA #$00 JSR $1000 SEI LDA #$31 STA $0314 LDA #$EA STA $0315 LDA #$00 STA $D01A LDA #$81 STA $DC0D CLI RTS I assembled this after my example demo, so I could SYS 49152 to start the music, and then call this new routine with SYS 49211, and I found I could turn the music on and off at will, and BASIC continued to work normally throughout. Let me know if it works or not.

[@Mr_ToR]

@@8_Bit Hi, I just came to post that I found a way and I found your reply :-) Here is how I did it: I didn't use SEI ~ CLI. First, I read $D01A back to accumulator after setting it #$00 thinking might be good practice like you've said :-) then did the interrupt vectors same as yours, finally, I set $DC0D to #$FF instead of #$81. Now, I've added SEI ~ CLI and used #$81 for $DC0D. Works, probably more stable :-) Thank you so much :-)

[@napomania]

is GEOS a multitasking OS? maybe it can't transform a c64 into a Amiga, but I thought it allows a c64 to make more jobs at the same time..

[@8_Bit]

GEOS and Wheels don't support multi-tasking, unfortunately. There were some other multi-tasking C64 OS released that require or benefit from the SuperCPU, like Wings, LUNIX, ACE, Contiki, and others.

[@CarlosdaCunhaeSilva]

Hi Robin, thanks for these excellent series of videos. I'm replaying them one by one and redoing these exercises on a Vice emulator together with a cross compiler. I hit a snag, I downloaded the SID file "Hey Sister" from hvsc but the start address has changed. I tried to get it to work under basic and changed the SYS addresses accordingly but it doesn't work. The memory area it's in gets overwritten. As a second step I disassembled the prg file, took out the SID data and put it back at address $1000 but it yields the same result. Any hint to what can be the cause ?

[@CarlosdaCunhaeSilva]

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

[@PhilWaller]

Thanks again Robin, very informative. Can you recommend a native C64 app to create music for use in a game?

[@8_Bit]

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.

[@davewilliams1363]

Ok, so having a hard time trying to get this to work on VICE...sorry, but that is all I have. First step is to load Turbo Marco Pro. I then try to load a SID file (which I know starts at $1000) but it always fails with an Out Of Memory error message, and I have no idea why. The SID file is the music from Ghost and Goblins which I extracted to a PRG file. If someone could help and provide some info as to what I am doing wrong I'd appreciate it.

[@davewilliams1363]

Actually, how can I confirm what address the SID PRG file loaded to? I converted it using SIDPLAY to PRG. The file info said the SID load address is 1000 and the init address is 1003.

[@8_Bit]

If you're in Turbo Macro Pro, then using the back arrow L command, that's just for loading source code files, not for loading arbitrary binaries. You should load the music PRG file in BASIC like LOAD"MUSIC",8,1 then NEW, then load TMP. If you're not sure the music file is really at $1000, then use a machine language monitor to load the file, and it'll report the load address. VICE has ML monitor, there's docs about it included with VICE. Good luck!

[@davewilliams1363]

@@8_Bit Thanks for the reply Robin. I was trying to load the SID in BASIC and not from TMP :D In the end I went with a monitor and was able to get this working. Thanks for a great video.

[@TheUtuber999]

@@davewilliams1363 You might have figured this out already, but if you just want to test the interrupt handler, here is a quick-and-dirty routine to increment the border color every 4.25 seconds (255/60 jiffies)... c000 78 SEI c001 A9 0D LDA #$0D c003 8D 14 03 STA $0314 c006 A9 C0 LDA #$C0 c008 8D 15 03 STA $0315 c00b 58 CLI c00c 60 RTS c00d A9 00 LDA #$00 c00f CD 12 D0 CMP $D012 c012 D0 FB BNE $C00F c014 C5 A2 CMP $A2 c016 D0 03 BNE $C01B c018 EE 20 D0 INC $D020 c01b 4C 31 EA JMP $EA31