DZ-Jay

Ah ... I see a fellow member of the Voltron Intellivision Bling Club! 😎 I also see from that picture that you are now covered in golden glitter.

Hmm ... It could be the LipStick, although I think I would remember a silly name like that -- especially if it was emblazoned with that totally-80's logo, like in @evg2000's photo. I distinctly remember that it was supposed to recognize your voice and that you could say "UP!" or "DOWN!" or "FIRE!" to control the stupid balloon. It didn't really work all that well, like 2 out of 5 times, or so; and I felt silly just yelling at the screen to play a game. -dZ.

Every time a bootleg game is cancelled, the home-brew gods kill a kitten. Do you want the kittens to die? RELEASE THE GAMES. SAVE A KITTEN.

OK, doing some more research, I think I tracked them down. One of them seems to be "The Games Creator" by Mastertronics, which fits my recollection. The other ... as far as I can find information on it ... seems to be the Covox Voice Master. I may be confusing it as coming from Mastertronics, probably because I purchased all of them from at the same time from the same magazine catalog. I also may be confusing the voice one with two separate products: a text-to-speech cartridge and the Covox voice Master. I really don't recall much details, but I strictly remember a headset/mic sort of gear that came with it, and speaking to the computer, yelling "Up!" and "Down!" and "Fire!" at the screen on some crappy balloon game it came with. The text-to-speech seems to be a separate thing altogether, because I recall that I plugged in the cartridge and I could enter "text-to-speech mode" in which the machine would just say anything I typed, or I could include speech commands in my BASIC programs. For some reason I remember those being the same thing, but I can't find any evidence of the Covox software being on cartridge. Does anybody have any idea? The "Games Creator" game was crap, though. -dZ.

I had two cartridges I bought off a magazine, I think they were from "Mastertronics." One provided text-to-speech and "voice recognition" capabilities to the integrated BASIC, and the other was a "game maker" software. Both were kind of crappy, especially the second one, which was buggy and very slow. The "voice recognition" was supposed to allow you to play games without a joystick, you know, like saying "up!" or "shoot!" but in reality it didn't really work all that well. It also mostly ran with the built in games it came with, which were equally crappy: one was a balloon that you "controlled" by saying "up" or "down" to raise or lower it on the screen. I kind of remember that it came with a cheap headset and microphone. Meh. I was soooooo disappointed with both. I haven't seen any of them in any C=64 software libraries in the intervening years. Has anybody heard of them? -dZ.

Is Joe Z. ... the Mandalorian? 😱

No worries. It's just that an expanded Intellivision has 2x AY-3-8914 chips, so it should be able to do quite a lot; but it has been underutilized so far. I'm not a musician, so I can't make cool tracks for it, but I can "play" a sequencer and drum machine. So that's my little contribution to the scene. Well ... that, and the updated music tracker. :) -dZ.

Oh, and this is hat it was trying to emulate, the classic TR-808 drum machine. Not perfect, but close.

They're not really that bad. But there's only so much you can do with pure square waves and nothing more. In any case, the main point is that they sound better than this, which is the "standard" Intellivision music sound. -dZ.

By the way, @First Spear, if you give me one of your songs in "IBN" I can try to track it for you and see what we get.

The repeat feature of the sequencer (i.e., adding a negative offset at the end), only serves to backtrack the player a number of patterns. If you backtrack all the way to the first pattern, it repeats the song from the start, if you backtrack only a few patterns, it will repeat from that point on. In that sense it is not really like "MUSIC GOSUB," because you cannot call it with multiple offsets -- its more like "MUSIC JUMP" that jumps once to the middle of the sequence. Since there is only one sequence per song, this causes the song to loop a particular segment. However, you can do precisely what you want by altering the sequence. Think of the song as a series of patterns strung together in a sequence. So, my song sequence may look like this: @@sequence: DECLE 1, 2, 3, 4, 5, 6, 7, 8, -8 That means "play pattern #1, followed by pattern #2, followed by pattern #3, and so on, until pattern #8; after which we backtrack to the first pattern and start again." So, let's say that before repeating the entire song, you want to repeat the middle parts first, say, patterns #5 and #6. Just do precisely that in your sequence: @@sequence: DECLE 1, 2, 3, 4, 5, 6, 7, 8, 4, 5, -10 Notice that I just added patterns #4 and #5 after pattern #8, and then backtracked 10 patterns to fall back at the beginning again. You can get funkier than that and place patterns in whatever order you want, repeating them as you wish. The following repeats the middle section, then advances a little bit, then the middle section again, and finally goes back to the beginning: @@sequence: DECLE 1, 2, 3, 4, 5, 6, 7, 8, 5, 6, 5, 6, 7, 8, -14 Think of "patterns" as musical sections: the intro, the verse, the drum solo, etc. Then string them together as you wish to compose your song. This is one key difference between traditional "trackers" or sequencers such as this one, and the IntyBASIC music player. It's not better or worse, just a different paradigm. You must think of your song in terms of a sequence of patterns, and then statically define that sequence; rather than a program where you have to use control flow and other techniques to "execute" the song. That's how I "remixed" the songs: I re-arranged the patterns in the sequence, repeating some, extending others, putting a drum solo at the beginning, etc. In this sense, the order of the pattern definitions is completely arbitrary -- It's just an "array" of patterns. What actually matters is how you place their "indices" in the sequence list. Sure, the length of the sequence consumes ROM space, one data word for each entry, but hey! songs are resource-expensive, and the more effects or arrangements you want to add, the more resources it'll consume. The cool part is that you "set it and forget it": just like the IntyBASIC music player, once you define your song, the tracker does everything for you, playing notes and synthesizing the sounds in the background while your game plays. Does this make sense? -dZ.

Thanks, I'm glad you liked it. Unfortunately, the emulator only exports in MP3 format. I guess it could be recorded with another software from the emulator. I'll try to give it a go and post back. In the meantime, I posted in the original thread a short tutorial of how I made the drums track, for anybody interested. Spoiler Alert: I used Garage Band to compose them, then transcribed the patterns into tracker row events by hand. The post walks you step by step of how I did that. -dZ.

Also, I "remixed" the demo tracks to illustrate some cool things you can do with the Intellivision Music Tracker v1.5. Because it is pattern-based and uses a sequencer to play the patterns, rather than, say, executing procedurally, it affords some really neat effects. Some cool examples demonstrated in the sample tracks are: (You can download the songs from the first post in the thread.) butterfly-remix.mp3 - Layered fade out, starting at around 3:15. It uses the same patterns as in the rest of the song, but I duplicated them and lowered the volume across the events in the pattern. Different instruments attenuate at different rates. This is all static pattern definition, not dynamically faded. Dynamic fading can be performed under program control by accessing the master fader variable (see the documentation for more information). We did this in the "Voyage" demo at the end of each part: the demo sequencer would periodically increase the master fader attenuation, and when the volume reached zero, the song ended and we start the next part. space-music.mp3 - Dance break, starting at around 1:30. The normal drums, melody, and bass sub-patterns are rearranged in different patterns to break down the track to a drum solo, then re-introducing the bass and melody slowly afterwards. voyage-remix.mp3 - Pattern "inter-cut edit" introducing the dance break, starting at around 2:30. It's a typical DJ remix effect of splicing together patterns in interesting ways, similar to what they do in Dub-Step and very common in megamixing. Because the patterns are defined by a set of note and drum events, you can just take events from different patterns and put them all together in the same one. In this instance, I chose the last pattern of the melody verse with the first pattern of the dance break, repeating the events for drums, bass, and melody of each, and intercalating them into the same pattern in a cool rhythmic effect. It's a bit involved, but the point is that it is very possible. This is my favorite effect and it was a lot of fun to create. You don't hear this sort of thing very often in 8-bit tracks. voyage-remix.mp3 - Pattern transposition, starting at around 3:15. The bass line of the melody is actually composed of two separate patterns, one that plays lower notes and the other one that plays higher notes. I just re-ordered them in the sequence. Instead of low-to-high, the bass line now goes from high-to-low, which makes it sound like the song has been transposed. Notice how it changes back to "normal" when the melody is re-introduced again at around 3:36. I want to clarify that most (and perhaps all) of these effects were possible with the original tracker as created by @Arnauld. However, because it is now properly documented, it is easier to pick at the fringes of its capabilities and discover new ways of using it. Plus the new "NPK" packing macros make things like the inter-cutting effect simpler and more straightforward by allowing you to unroll the patterns without consuming more ROM. Oh and lastly, here's another cool twist that is enabled by the tracker: Just change the "drum kit" or "instruments" list used by your song, and it automatically changes its character using the new sounds. Here's the same "demo-drums" song with the "standard" drum kit. drums-demo.mp3 - "Funk My Drum Machine" track with different drum sounds - By @DZ-Jay Note that the hi-hats sound more like real ones and the TR-808 rimshot "click" is changed to something that evokes a cowbell. All done by just changing the list of drum instruments that the song uses. Both the "standard" and "TR-808(ish)" drum sounds are included with the tracker. -dZ.

By the way, you don't need Garage Band to do drums. There are plenty of similar open source software out there. And on a pinch, you could "draw" the patterns in a grid on paper -- just like we used to do back in the 80s when megamixing records with tape splices. :) -dZ.

For an example of how I made the drums, consider this Garage Band view: Notice that you have 16 blocks across for each instrument. Let us consider the kick drum (at the very top). The 16 blocks are packed into four groups of four blocks each. When you play that track, you will hear the kick drum hit on every beat, which means that every four blocks (one group) represents one beat. (To imagine the beat, notice that the snare hits on every other beat, so you get a nice "boom, kah, boom, kah, ..." rhythm. The hi-hats fill in the empty spaces in between drum hits.) So, we fashion our tracker pattern in the same way: Each row will represent one block, so we need 16 rows in total to fill the pattern. It'll look something like this: NOTE("--- ---") ; 00 Beat #1 NOTE("--- ---") ; 01 NOTE("--- ---") ; 02 NOTE("--- ---") ; 03 NOTE("--- ---") ; 04 Beat #2 NOTE("--- ---") ; 05 NOTE("--- ---") ; 06 NOTE("--- ---") ; 07 NOTE("--- ---") ; 08 Beat #3 NOTE("--- ---") ; 09 NOTE("--- ---") ; 10 NOTE("--- ---") ; 11 NOTE("--- ---") ; 12 Beat #4 NOTE("--- ---") ; 13 NOTE("--- ---") ; 14 NOTE("--- ---") ; 15 Now, we saw in the Garage Band pattern that the kick hits every beat, that is, every fourth block starting with the very first one. Assuming we already set up our song header and instruments, we'll consider that the kick is drum instrument #1 and that the snare is drum instrument #2. We then put our kick drums on the beats using "DRM" events, with the NOTE() macro: NOTE("DRM 1F0") ; 00 Beat #1 NOTE("--- ---") ; 01 NOTE("--- ---") ; 02 NOTE("--- ---") ; 03 NOTE("DRM 1F0") ; 04 Beat #2 NOTE("--- ---") ; 05 NOTE("--- ---") ; 06 NOTE("--- ---") ; 07 NOTE("DRM 1F0") ; 08 Beat #3 NOTE("--- ---") ; 09 NOTE("--- ---") ; 10 NOTE("--- ---") ; 11 NOTE("DRM 1F0") ; 12 Beat #4 NOTE("--- ---") ; 13 NOTE("--- ---") ; 14 NOTE("--- ---") ; 15 As per the manual definition of the NOTE() macro, the row string means the following: DRM - this is a drum instrument, not a tone. 1 - this is instrument #1 (from the drums list as stated above). F - Play the instrument at maximum volume (15) 0 - The event lasts one single row, so there is no delay to the next row. (Actually, that last one is not strictly accurate, but we'll address that one step at a time. It'll make sense in a second, trust me.) The rest of the blocks are empty in the Garage Band pattern, which essentially means that the drum hit will continue playing until it naturally decays and then drop off until the next beat. We do the same in our tracker notation by adding "NUL" events. Because we want the drum instrument to decay naturally, following its original definition, we do not want to alter its volume ourselves. Therefore, our "null" events essentially say "do not change anything in this row. Oh, and by the way, keep the volume at maximum." NOTE("DRM 1F0") ; 00 Beat #1 NOTE("NUL 0F0") ; 01 NOTE("NUL 0F0") ; 02 NOTE("NUL 0F0") ; 03 NOTE("DRM 1F0") ; 04 Beat #2 NOTE("NUL 0F0") ; 05 NOTE("NUL 0F0") ; 06 NOTE("NUL 0F0") ; 07 NOTE("DRM 1F0") ; 08 Beat #3 NOTE("NUL 0F0") ; 09 NOTE("NUL 0F0") ; 10 NOTE("NUL 0F0") ; 11 NOTE("DRM 1F0") ; 12 Beat #4 NOTE("NUL 0F0") ; 13 NOTE("NUL 0F0") ; 14 NOTE("NUL 0F0") ; 15 The string in those rows means the following: NUL - This is a "null" event, continue the previous event as normal. 0 - No change in instrument, let the previous one continue. F - Maintain the volume at maximum. 0 - This event lasts a single row, so no delay is needed. (Again, the same caveat as before applies here ...) And that's our kick drum pattern. Notice that we "unrolled" it to match the Garage Band pattern, where each row represents one block in the 16-block pattern. This is why we said that the "0 delay" for each row is inaccurate: in reality, for our tracker, the kick drum event lasts four rows, right until the next one. We just "unrolled" the four events into individual rows: one for the actual event of the drum hit, and three "null" events that just extend it. We did that purely out of convenience. In reality, our pattern should look like this: NOTE("DRM 1F3") ; 00 Beat #1 NOTE("DRM 1F3") ; 04 Beat #2 NOTE("DRM 1F3") ; 08 Beat #3 NOTE("DRM 1F3") ; 12 Beat #4 Notice that it is the same one, but compacted. We are now saying that each drum event lasts four rows (the current event row, plus a delay of 3 rows). And normally, that's how we would write our patterns: our last step is always to "compact" the events. In fact, that's how all the demo songs are tracked right now, except the drums. It uses less ROM because we pack each event row into a single data word (four), while the previous "unrolled" way required one data word per row (16). The power and convenience of unrolling the rows becomes apparent when you want to modify or play with the pattern. Let's make our drums a bit more funky ... Notice that we added two syncopated kick drum hits. Those do not fit nicely in our 4-event pattern. It forces us to figure out between which rows we need to add them, and adjust the length of the events around it. That's too cumbersome, at least for me, and especially when we're just experimenting to see how it sounds. We may want to move those kicks around as we continue. But if we were using the unrolled pattern, it's a cinch! Because every block is represented as a row, we just find the row we need to change, and add a drum event: NOTE("DRM 1F0") ; 00 Beat #1 NOTE("NUL 0F0") ; 01 NOTE("NUL 0F0") ; 02 NOTE("DRM 1F0") ; 03 <-- New beat NOTE("DRM 1F0") ; 04 Beat #2 NOTE("NUL 0F0") ; 05 NOTE("DRM 1F0") ; 06 <-- New beat NOTE("NUL 0F0") ; 07 NOTE("DRM 1F0") ; 08 Beat #3 NOTE("NUL 0F0") ; 09 NOTE("NUL 0F0") ; 10 NOTE("NUL 0F0") ; 11 NOTE("DRM 1F0") ; 12 Beat #4 NOTE("NUL 0F0") ; 13 NOTE("NUL 0F0") ; 14 NOTE("NUL 0F0") ; 15 And we're done! No need to fiddle with the length of events or their positions; we treat the pattern table in the same way we treat it in Garage Band, and maintain them in sync. The only problem, as I mentioned before, is that the pattern still takes considerably more ROM space than the "normal" compacted one. I came up with another solution for this: a new macro family described in the manual as "Automatic Note Packing" or NPK. With NPK, you define your patterns unrolled like we've done here, and let the macros handle the complexity of detecting event boundaries and compacting your event rows. Translating our unrolled pattern to use NPK is simple, we just add some wrapper macros to enclose the pattern block, and use the NPK.Note() macro instead for our rows: NPK.Begin(16) NPK.Note("DRM 1F0") ; 00 Beat #1 NPK.Note("NUL 0F0") ; 01 NPK.Note("NUL 0F0") ; 02 NPK.Note("DRM 1F0") ; 03 <-- New beat NPK.Note("DRM 1F0") ; 04 Beat #2 NPK.Note("NUL 0F0") ; 05 NPK.Note("DRM 1F0") ; 06 <-- New beat NPK.Note("NUL 0F0") ; 07 NPK.Note("DRM 1F0") ; 08 Beat #3 NPK.Note("NUL 0F0") ; 09 NPK.Note("NUL 0F0") ; 10 NPK.Note("NUL 0F0") ; 11 NPK.Note("DRM 1F0") ; 12 Beat #4 NPK.Note("NUL 0F0") ; 13 NPK.Note("NUL 0F0") ; 14 NPK.Note("NUL 0F0") ; 15 NPK.End At the top, we tell the NPK sub-system that our pattern is 16 rows in total. It will tell us if we under- or overrun it, which is convenient. And what about the triplets? Well, easy: just change the grain of your rows. In the above example, each row is equivalent to a block in Garage Band. To add triplets we just make each row 1/3 of that. That is, for each block in Garage Band we add three rows. Here's an excerpt from the drums demo track to illustrate (instrument #3 is the closed hi-hat, #4 is the open hi-hat): @@ph04: NPK.Begin(48) NPK.Note("DRM 3E0") ; #00 - 1 Beat #1 NPK.Note("NUL 0E0") ; #01 NPK.Note("NUL 0E0") ; #02 NPK.Note("DRM 3C0") ; #03 - 2 <-- Triple here! NPK.Note("DRM 3B0") ; #04 NPK.Note("DRM 3B0") ; #05 NPK.Note("DRM 3E0") ; #06 - 3 NPK.Note("NUL 0E0") ; #07 NPK.Note("NUL 0E0") ; #08 NPK.Note("DRM 3B0") ; #09 - 4 NPK.Note("NUL 0B0") ; #10 NPK.Note("NUL 0B0") ; #11 NPK.Note("DRM 3E0") ; #12 - 1 Beat #2 NPK.Note("NUL 0E0") ; #13 NPK.Note("NUL 0E0") ; #14 NPK.Note("DRM 3B0") ; #15 - 2 NPK.Note("NUL 0B0") ; #16 NPK.Note("NUL 0B0") ; #17 NPK.Note("DRM 3E0") ; #18 - 3 NPK.Note("NUL 0E0") ; #19 NPK.Note("NUL 0E0") ; #20 NPK.Note("DRM 3B0") ; #21 - 4 NPK.Note("NUL 0B0") ; #22 NPK.Note("NUL 0B0") ; #23 NPK.Note("DRM 3E0") ; #24 - 1 Beat #3 <-- Triplet here! NPK.Note("DRM 3C0") ; #25 NPK.Note("DRM 3C0") ; #26 NPK.Note("DRM 3B0") ; #27 - 2 NPK.Note("NUL 0B0") ; #28 NPK.Note("NUL 0B0") ; #29 NPK.Note("DRM 3E0") ; #30 - 3 NPK.Note("DRM 3C0") ; #31 NPK.Note("DRM 3C0") ; #32 NPK.Note("DRM 3B0") ; #33 - 4 NPK.Note("NUL 0B0") ; #34 NPK.Note("NUL 0B0") ; #35 NPK.Note("DRM 3E0") ; #36 - 1 Beat #4 NPK.Note("NUL 0E0") ; #37 NPK.Note("NUL 0E0") ; #38 NPK.Note("DRM 3B0") ; #39 - 2 NPK.Note("NUL 0B0") ; #40 NPK.Note("NUL 0B0") ; #41 NPK.Note("DRM 3E0") ; #42 - 3 NPK.Note("NUL 0E0") ; #43 NPK.Note("NUL 0E0") ; #44 NPK.Note("DRM 3B0") ; #45 - 4 NPK.Note("NUL 0B0") ; #46 NPK.Note("NUL 0B0") ; #47 NPK.End I add the comments to keep my place in the pattern. It's similar to what the "ruler" does in Garage Band. And that, in a (rather large brazilian) nut shell is how I made the drum tracks. The rest is doing similar patterns for the other instruments or intercalating them in the same patterns. I hope this helps. Ask any questions. -dZ.

@First Spear, Also, if there is any particular thing you want to know about any of the examples, I could break down one of the patterns and illustrate what it does and how it works. -dZ.

Wow! This is fascinating, @decle. Thanks for sharing. HAPPY NEW YEAR! -dZ.

I understand that. I pointed out that the problem is of clipping. I mentioned the scale because the size of the sprites are "just exactly the same size" as the openings of the doors which exacerbates the clipping problems at anything but the exact position or angle of collision. It's also not precisely realistic. However, you are right, that reducing the size would not have fixed all the clipping problems of the doors. That's due to the isometric perspective. These are not new problems, to be sure. The problem is brought on by a couple of things, first of which is the isometric view, which opens up an interim space that needs to be accounted for while the player transitions out of the scene. In other words, the problem is self-imposed: you want cool-looking wide 3-D doors, then you now have a clipping issue to address in exit transitions. We've all been there. One way to solve it, as you suggest, is to re-purpose one or two MOBs to cover the transition and clip the edges of the sprite as it goes through. Indeed this is what I do in Christmas Carol for the tunnels in the maze, and the exits in the cut-scenes. Take a look at the red box below. It automatically adjusts its position when it "senses" that there is a sprite within a few pixels of it. (In the real game, the red box is painted black to blend with the background.) I created this problem for myself by adding those cubes at the edges. But because I already knew about this problem before hand, I could face it head on from the beginning: I built a sub-system to handle the automatic movement of the cover, and I also made sure I didn't put myself in a situation where I had no MOBs available for it. And in those cases where I had no MOBs left, well ... I had to find a way to gain one back. That last part is the trick: Once you are aware of the problem, you can find creative solutions for it. In my case was to make sure to leave at least one MOB available whenever a sprites were going through a door. At points when no sprites were going through a door, I could use all 8 MOBs. When sprites start moving, I had to find ways to reuse at least one MOB: for example, force one sprite to stay put for a few seconds (drawn in BACKTAB, yet still animated) until a sprite leaves the stage. I could also design my cut-scenes so that no two sprites ever left the stage simultaneously on opposite ends, say, by staggering their movements so that one reaches the edge at exactly the point when the other already left. In the Boss Level I added an enemy which consumed an extra MOB -- precisely the one I used for the tunnel cover! So, I removed the arms of the Snowman to gain it back. But then the Snowman looked stupid. I could have left it like that and nobody would have complained, but it was half-assed; it looked precisely like what it was, a cheap solution: I needed a MOB so I stole it from another sprite. So I came up with a compromise: the Snowman is melted in a cut-scene into a snowball. He now has no arms. Done. The solution is not only practical, but diagetic: part of the narrative of the story. In the end, all those little tricks are invisible to the player because they are built into the entire game naturally. Perhaps something similar could be done in this game. One simple idea would be to force the player to not be able to leave until all enemies are dead, and therefore guarantee the availability of MOBs. I don't know, the doors could shut when an enemy enters, or they could block the exits, or whatever suits this particular game. Another idea would be to animate the sprite "crouching" to go through the door. Perhaps a simpler idea is to just dispense with the wide 3-D door look altogether and just make the cavity narrower, decreasing the necessity of having the sprite walk into the "in-between" space. There are ways around these sort of issues. Some of them easy, some hard, but all of them compromises, of course; but that's what makes making a really polished game hard. Game design is full of trade-offs, and the programmer should choose the best trade-offs for his game. If a wide 3-D door doesn't add anything to the game play, and it is only cosmetic; then what does it really add if it brings with it extraneous aesthetic issues? Also, you do not need to solve this problem right now -- there are bigger fish to fry while you continue making the game. However, you should at least start thinking of ways around it. The one thing that I really wouldn't recommend you do is to just throw your arms in the air and say "that's the Intellivision, I can't do anything about it." The canon of every platform is full of half-assed games like that, even when other games themselves prove that different trade-offs would have provided a better experience. That defeatist mentality is what stops a good game from becoming an awesome one. -dZ.

The drums I coded by hand. However, I did "design" them in Garage Band. I made the drum track patterns in Garage Band, placing the instruments until it sounded good, then I just imitated it in code. Garage Band has a neat "key pad" interface were you light up the points were you want a drum to sound, in a horizontal "scale" marked by the beat. I take the buttons in that horizontal scale and mentally pivot them into rows in the tracker. The songs themselves were tracked originally by @carlsson. He uses a tracker tool to make the music, then exports it into some sort of notation that then he converts into the code. He then has to alter it manually. I then "remixed" them by re-arranging the patterns or altering the instruments. And of course, adding cooler drums. I can help you track some of your songs if you'd like. I do it by hand (Christmas Carol's tracks were also composed in Logic then transcribed by hand). Personally, I've worked with the tracker for so long, that I don't find its format too intimidating. However, if you have your songs in some particular format, we could figure out how to transcribe them in the appropriate one. Part of my goal was to document the data format in detail to enable this sort of work. For the drum track, it's pretty straight forward: they are 16-beat patterns, grouped in blocks of 4-beats each for easy reading. Then each beat is sub-divided into four rows, that's to allow for "triplets" quantization in the hi-hats. It helps that I was a DJ for many years, so I used to program drums and synths using beat boxes and sequencers, so I'm used to thinking of songs and rhythms as patterns. I just can't play worth crap. -dZ.

Sure thing! Let me know if you need help. I know that you have quite a few songs in IntyBASIC already. I'd love to see what you can do with this tracker. 👍🏻 dZ.

It is my pleasure to be able to contribute to it. I think the hardest part was your work on creating the module, I just added a bit of flair on top. By far, my biggest contribution is documenting the functionality and the data format in great detail. I hope that it opens it up to more programmers and musicians. -dZ.

Hey, that looks really good!

Exactly. More specifically, you overlay one or more MOBs, each one with their own single color, then move them all in unison by updating their positions simultaneously. Obviously, every MOB you use in this way is one less MOB you have available to act on its own, so make sure to design your game with that in mind. Also to keep in mind is the fact that the order of MOBs is significant: lower number objects have higher priority. That is, MOB #0 will appear on top of MOB #1, and so on. This can helps in "shaping" your multicolor MOBs by using higher priority MOBs to mask parts of the ones behind them. -dZ.

Happy New Year to you and all Intellivision fans!

My toast this evening: