Thanks again for this great video and sharing the code with us ! I must say that I understand the principle of most of demo effects even if i'm certainly not capable of coding them from scratch. However, I still do not get the the entire principle of the a sprite multiplexor (well i know about the sorting algorithm, the fact that we re-use sprites, but i fail to understand how the interrupt re-schedulling is handled - even from a pure principle perspective. I guess some pseudo code would help me). So if by chance you could some day perform some kind of step by step multiplexor tutorial that would be awesome. Anyway thanks again for sharing this super cool stuff.
Thank you again for the kind support. :) I've been planning a "how multiplexors work" video for a while now. I will keep your question in mind when I'm working on it.
@@MartinPiper6502 I don't know much about the c64 past running sys command on it. But can my game be made on that machine. Its sci-fi rpg dialog-driven.
@@MartinPiper6502 My game has currently over 500 different groups of enemies in it involving travelling through many systems and planets in a ten party member companion sci-fi rpg. Party members are: Commander Marston Axle (party leader), T6 Unit (droid), Loana Shields, Nella Parkas, Herc Commander, Storm (tank), Skynar Harrison (ship pilot), Cronis and Rex Titan Suns and William Smith.. Its not a small game. But for the C64 I have seen a few rpg games taking up to 10 or more virtual disks because they were so huge. If I was to put it on the c64 it would would have to be loaded from disks, need a dialog widget system for handling all the dialog. An inventory system for all the items you pick up in the game. Disks to load all the sprites banks from. The game also has got store vendors for buying or selling items. And some kind of global manager to track all the progressive dialog storyline events, and the loot drops from the enemies on the planets that you explore.... An interface to show also all the systems and planets in a list as the game has got jumpgates and jumpholes in it to travel from system to system. I did create some music also for my game but its in midi format. For the text version of my game. The game so far has nearly 13,000 variables in it for all the items, and the dialog because its dialog driven. But I want the player to also beable to run around and explore planets I suppose I can make a small text version of one of the planets on the Commodore c64 because I dont know how to do the graphics and sprites. Although there are converters. On the pc the game in just the text form is abt 30 megs.
@@MartinPiper6502 Tesseract Prime Offworlds, is the name of my game is not small. It Has currently over 500 different enemy groups in it its a game where you travel around jumpgates and jumpholes exploring different systems and planets in the universe, interacting with npc's dialog and also party member dialog. Its a 10 party member switching companion type game. The Text version of game on the pc which I run in the dos console is 30 megs in size containing over 13,000 variables for tracking all the dialog storyline progressive events and all the loot drops from enemies. has also store vendors in it to buy and sell items you pick up or find so its that type of game.. But I have seen a couple of RPG games taking up 3-10 or so disks up on the C64. So it probably is possible to put a game like this on it now that you have virtual disks with the emulator. I guess the best thing i can do since I don't know how to code in all the graphics and set up the dialog widget system, inventory system, and all the other stuff in this assembly language that you guys do is to write a simple text version of it in basic since I don't think there are any editors to create the 3d game worlds on the commodore c64 for players to be able to run around in to explore (at least I don't think we do) so it may have to be done like the 2D graphic adventure games with Switching into different screens to show the different locations. My game does have some dialog audio but I am not sure if there's a converter for the c64 to play audio wav files. As for game music I made some music tunes for it but its in the midi format. Not sid format. Plus I don't know how to set up the instruments properly with the sid converter once i had converted my midi. So they don't sound so good when playing them back on sid with the default instruments.. Tried the online graphics converter to convert the pics of my characters into c64 pics not so great the results.. All the sprite banks would have to be loaded in from disks as I think you can only have up to 3 sprite banks in memory on the c64....
VSCode can be adapted for pretty much and language or environment. There are several toolchain builds for C64 development. I think most folks use the Kick Assembler or ACME via VS64. There are similar builds for Mac OS X using Sublime ( and actually VSCode ). You’d be surprised how smoothly architected and integrated it all is with VICE and C64 debug etc.
@@MurderMostFowl I think it's awesome that A) old retro computers like the C64 are still being actively developed for (software AND hardware!) and B) that there's such a plethora of excellent tools available for coding those old systems. There are even complete programming environments for the Atari 2600! Programmers from back in the day would be drooling if they had the tools that are available now (most are free). Heck, I've heard that the original Atari 2600 programmers were essentially using calculators (for display timing since the display is highly program driven and cycle counts are crucial) and graph paper! A quick aside about that: David Crane, the programmer of the legendary "Pitfall!" for the Atari 2600, had completed his game and showed it to his coworkers. He had made the game so that you only get ONE Pitfall Harry and that was that. They talked him into giving the player 3 chances, but the problem was that he had already used every available byte of ROM code (only 4K!)* so it took him an additional two or three weeks to optimize his code even more so that he could squeeze in the necessary dozen bytes or so to accommodate the extra overhead. * Despite only having 4K of ROM space, the game has 256 unique screens. The way he was able to do this in only 4K is one of the things that made David a legend. If you're interested, here he is talking about how he did it: ruclips.net/video/MBT1OK6VAIU/видео.htmlsi=ZFyLpQwnY0dM2K3L&t=1329
I use visual studio for the text editor and project file management. In the project settings you can define build, run, and debug command lines. So when I press F7 to build it just executes the batch file or assembler, and when I press Ctrl+F5 to run it runs the emulator with command line options to boot and run a cartridge or disk.
@@MartinPiper6502 Very cool. Thanks for the explanation. I imagine Visual Studio can then call Vice to run the built .exe for testing? I used to use a C64 emulator back in the day called CCS64 and it was quite good, but it seems everyone uses Vice for C64 emulation now. (I think CCS64 has not been updated in years).
If your multiplexer would only accept sprites one pixel heigh (and perhaps one pixel width to make it a dot), how many would you be able to animate onscreen then..?
This is tricky, the C64 is somewhat limited to 21 pixels height for a sprite. There are way to shrink a sprite by a few pixels, but they need quite a lot of extra CPU. Sprites cannot be shrunk horizontally to a pixel either.
@@MartinPiper6502 Ok, but what happens if you place a sprite (containing a dot top left) at y 100 and when the raster is at 101, you move the sprite to 102? Would the dot show up again when raster hits 102, or what happens?
In C64 land. At raster 100, it would draw the top with the dot. At raster 102, it would continue to display the transparent part of the sprite, under the top row with the dot, it would not redraw the dot until at least 21 rows have been drawn of that sprite. Unless the sprite was shrunk by a few rows, but that's not really feasible due to the extra CPU.
That's a very smooth multiplexer. Nice.
Nice - I am surprised multiplexing runs that well using basic. I expected it to be much slower.
There's quite a lot of machine code support :)
Thanks again for this great video and sharing the code with us ! I must say that I understand the principle of most of demo effects even if i'm certainly not capable of coding them from scratch. However, I still do not get the the entire principle of the a sprite multiplexor (well i know about the sorting algorithm, the fact that we re-use sprites, but i fail to understand how the interrupt re-schedulling is handled - even from a pure principle perspective. I guess some pseudo code would help me). So if by chance you could some day perform some kind of step by step multiplexor tutorial that would be awesome. Anyway thanks again for sharing this super cool stuff.
Thank you again for the kind support. :) I've been planning a "how multiplexors work" video for a while now. I will keep your question in mind when I'm working on it.
@@MartinPiper6502 I don't know much about the c64 past running sys command on it. But can my game be made on that machine. Its sci-fi rpg dialog-driven.
Anything is possible. :)
@@MartinPiper6502 My game has currently over 500 different groups of enemies in it involving travelling through many systems and planets in a ten party member companion sci-fi rpg.
Party members are: Commander Marston Axle (party leader), T6 Unit (droid), Loana Shields, Nella Parkas, Herc Commander, Storm (tank), Skynar Harrison (ship pilot), Cronis and Rex Titan Suns and William Smith..
Its not a small game. But for the C64 I have seen a few rpg games taking up to 10 or more virtual disks because they were so huge.
If I was to put it on the c64 it would would have to be loaded from disks, need a dialog widget system for handling all the dialog. An inventory system for all the items you pick up in the game. Disks to load all the sprites banks from. The game also has got store vendors for buying or selling items.
And some kind of global manager to track all the progressive dialog storyline events, and the loot drops from the enemies on the planets that you explore....
An interface to show also all the systems and planets in a list as the game has got jumpgates and jumpholes in it to travel from system to system.
I did create some music also for my game but its in midi format.
For the text version of my game. The game so far has nearly 13,000 variables in it for all the items, and the dialog because its dialog driven. But I want the player to also beable to run around and explore planets
I suppose I can make a small text version of one of the planets on the Commodore c64 because I dont know how to do the graphics and sprites. Although there are converters.
On the pc the game in just the text form is abt 30 megs.
@@MartinPiper6502 Tesseract Prime Offworlds, is the name of my game is not small. It Has currently over 500 different enemy groups in it its a game where you travel around jumpgates and jumpholes exploring different systems and planets in the universe, interacting with npc's dialog and also party member dialog. Its a 10 party member switching companion type game. The Text version of game on the pc which I run in the dos console is 30 megs in size containing over 13,000 variables for tracking all the dialog storyline progressive events and all the loot drops from enemies. has also store vendors in it to buy and sell items you pick up or find so its that type of game.. But I have seen a couple of RPG games taking up 3-10 or so disks up on the C64. So it probably is possible to put a game like this on it now that you have virtual disks with the emulator.
I guess the best thing i can do since I don't know how to code in all the graphics and set up the dialog widget system, inventory system, and all the other stuff in this assembly language that you guys do is to write a simple text version of it in basic since I don't think there are any editors to create the 3d game worlds on the commodore c64 for players to be able to run around in to explore (at least I don't think we do) so it may have to be done like the 2D graphic adventure games with Switching into different screens to show the different locations.
My game does have some dialog audio but I am not sure if there's a converter for the c64 to play audio wav files.
As for game music I made some music tunes for it but its in the midi format. Not sid format. Plus I don't know how to set up the instruments properly with the sid converter once i had converted my midi. So they don't sound so good when playing them back on sid with the default instruments.. Tried the online graphics converter to convert the pics of my characters into c64 pics not so great the results.. All the sprite banks would have to be loaded in from disks as I think you can only have up to 3 sprite banks in memory on the c64....
Great video. Thanks! Have you thought about possibly doing a video on how to write a multiplexer in assembler?
@@dbarros yes it's on my list of things to do
@@MartinPiper6502 Thank you. Looking forward to it!
I 2nd that, please make a video on how to write a multiplexer in Assembler.( Pure Assembly and none of scripting language used elsewhere).. thanks
Multiplexor video: ruclips.net/video/BtTCzjmwsMA/видео.html
very interesting video
Thank you
How are you using Microsoft Visual Studio to edit and compile programs for the C64?
VSCode can be adapted for pretty much and language or environment. There are several toolchain builds for C64 development. I think most folks use the Kick Assembler or ACME via VS64. There are similar builds for Mac OS X using Sublime ( and actually VSCode ). You’d be surprised how smoothly architected and integrated it all is with VICE and C64 debug etc.
@@MurderMostFowl I think it's awesome that A) old retro computers like the C64 are still being actively developed for (software AND hardware!) and B) that there's such a plethora of excellent tools available for coding those old systems. There are even complete programming environments for the Atari 2600! Programmers from back in the day would be drooling if they had the tools that are available now (most are free). Heck, I've heard that the original Atari 2600 programmers were essentially using calculators (for display timing since the display is highly program driven and cycle counts are crucial) and graph paper!
A quick aside about that: David Crane, the programmer of the legendary "Pitfall!" for the Atari 2600, had completed his game and showed it to his coworkers. He had made the game so that you only get ONE Pitfall Harry and that was that. They talked him into giving the player 3 chances, but the problem was that he had already used every available byte of ROM code (only 4K!)* so it took him an additional two or three weeks to optimize his code even more so that he could squeeze in the necessary dozen bytes or so to accommodate the extra overhead.
* Despite only having 4K of ROM space, the game has 256 unique screens. The way he was able to do this in only 4K is one of the things that made David a legend. If you're interested, here he is talking about how he did it: ruclips.net/video/MBT1OK6VAIU/видео.htmlsi=ZFyLpQwnY0dM2K3L&t=1329
I use visual studio for the text editor and project file management. In the project settings you can define build, run, and debug command lines. So when I press F7 to build it just executes the batch file or assembler, and when I press Ctrl+F5 to run it runs the emulator with command line options to boot and run a cartridge or disk.
@@MartinPiper6502 Very cool. Thanks for the explanation. I imagine Visual Studio can then call Vice to run the built .exe for testing? I used to use a C64 emulator back in the day called CCS64 and it was quite good, but it seems everyone uses Vice for C64 emulation now. (I think CCS64 has not been updated in years).
@@JustWasted3HoursHere yes correct
If your multiplexer would only accept sprites one pixel heigh (and perhaps one pixel width to make it a dot), how many would you be able to animate onscreen then..?
This is tricky, the C64 is somewhat limited to 21 pixels height for a sprite. There are way to shrink a sprite by a few pixels, but they need quite a lot of extra CPU. Sprites cannot be shrunk horizontally to a pixel either.
@@MartinPiper6502 Ok, but what happens if you place a sprite (containing a dot top left) at y 100 and when the raster is at 101, you move the sprite to 102? Would the dot show up again when raster hits 102, or what happens?
In C64 land. At raster 100, it would draw the top with the dot.
At raster 102, it would continue to display the transparent part of the sprite, under the top row with the dot, it would not redraw the dot until at least 21 rows have been drawn of that sprite.
Unless the sprite was shrunk by a few rows, but that's not really feasible due to the extra CPU.
@@MartinPiper6502 Today I learned! Thanks 🙂
@@MartinPiper6502 To be honest, that's how I thought some animated dot effects (spinning 3d globe of dots, for instance) was made in demos.
😡😡