DZ-Jay

Thanks, David. One word of caution: Please, as you update the game, make sure to have some restraint in maintaining its character. I imagine something like Super Pro Chef or Super Pro Tennis, in which the end result is exactly the original game with all the annoying bits fixed, and a few new features that enhance what was there already. I still liked the original KotM very much, only the balance and the controls needed some tweaking. :) -dZ.

Don't worry, I'll be gentle with my feedback. Gotcha! I will try making my own map. I think it's the kind of game that I need to figure out based on the terminal read-outs.

I just played the last version for a while ... wow! I am very impressed. I really like this game! I got a good play in, and got pretty far before my wife called me to dinner. I'll play again later and try to complete it. I do need to build a map! 😬 I do have some feedback (don't I always?), but I'll post it later when I have more time. Right now, I just wanted to say, congratulations guys! This game has come along nicely. dZ.

I figured that. However, in my experience, it's a crapshoot. Like I said, in IntyBASIC, the emulator tends to put the oscillators in phase, causing them to go louder ... for a while at least; but I do not think you can control nor expect that in the real hardware, as we've find out empirically. That's the thing, we had the same theory for the PSG in the Intellivision (there were some discussions with Arnauld, Joe Z., Artrag, and a few others in the past; here and in the IntvPROG mailing list), but we couldn't find a way empirically to do so. Then Joe Z. and a few others did a deep reverse-engineering analysis on the AY-3-8914, and discovered that there didn't seem to be a way to deterministically reset the counter. The most you can do is put the counter down to its lowest level which causes it to alternate between 1 and 0. But then, you can't really tell whether the oscillators will fall either in phase or out of phase, so still a crap shoot. There may still be some way to figure that out, but as far as the experts have determined, there isn't one. Here's the thread in the mailing list: https://groups.io/g/intvprog/message/9239 Here's the consequential conclusion from Joe Z.: The first sentence refers to the oscillators: they are free running, in that there is no mechanism for them to get synchronized or phased -- they are just there, counting on their own, and you just change the amount to which you divided them in order to produce output. -dZ.

I think the best way to "avoid it" is to just not play the same tune on two channels for such a long time without variation. You could just either not do that, or change the instrument of one of them, or silence one of the channels occasionally. I've noticed that doing the same thing in the Intellivision Music Tracker causes the waves to go out of phase a lot quicker. That's probably because we are re-enabling the channel bits on every cycle, but in IntyBASIC, that's only done probably once. Then again, I wonder if this is purely a jzIntv artefact. I mean, it was just very recently that Joe Z. did some reverse engineering on the PSG to discover how the internal counters of the chip worked, and we learned once and for all that there appeared to be no deterministic way to reset the counters. -dZ.

Nah, it's not really something bad like that at all. It's just a weird sound. When two soundwaves synchronize their phases, they just tend to add to each other, but if they go slightly out of phase, they tend to cancel each other out. It's just a weird sound effect, nothing more. What I would recommend is just not making the same tune on two channels identical. Not because it is bad or wrong, but because all it does is lead to that weird effect, which is probably not done on purpose. Here's an excerpt from your code: MUSIC F5,F5,A2# MUSIC -,-,- MUSIC C5#,C5#,- MUSIC -,-,- MUSIC -,-,A2# MUSIC A4#,A4#,- MUSIC -,-,- MUSIC -,-,- MUSIC F5,F5,A2# MUSIC -,-,- MUSIC C5#,C5#,- MUSIC -,-,- MUSIC -,-,A2# MUSIC A4#,A4#,- MUSIC -,-,- MUSIC -,-,- MUSIC F5,F5,A2# MUSIC -,-,- MUSIC C5#,C5#,- Any particular reason why you have "F5#" and "C5#" and "A4#," etc., both playing on the first and second channel? -dZ.

Well, I see that you are playing the same notes on two channels at a time, using the instrument (default), which suggests that the problem is that the oscillators go in opposite phase, cancelling each other out after a while. (When I said before they were "in phase," I meant the effect typically called "phasing" or "flanging," which actually involves the waves being slightly out of phase, cancelling some harmonics.)

Intellivision: B-17 Bomber BurgerTime Bomb Squad Dracula and of course, Christmas Carol Although, to be honest, it's mostly Christmas Carol. Atari: Stay Frosty Stay Frosty 2 Yar's Revenge That's all I break out the System Changer for. ColecoVision: None I dabble here and there with some games, but honestly, I seldom bring out the unit -- not when I can play Intellivision. dZ.

By the way, I have an update on the IBN-to-IMT translator program: It's now complete, fully documented, and works rather well. I will be publishing it in the coming weeks, after I complete a couple of tracks I am preparing to go along with it. If anybody wants to test it with their own projects, or needs help using the tracker, just let me know. -dZ.

Hello everyone, I've updated the distro files on the first post to "revision #2." This revision includes the following bug fixes and enhancements: FIXED: Procedure TRKPATINIT now skips PSG updates completely when the end-of-song marker is detected. This ensures that the tracker stays silent after the song ends, even if notes were still active. FIXED: Macro NPK.Note() ignored all NUL events that start at the beginning of a new NPK sub-pattern definition. FIXED: Macro NPK.Note() did not compact properly consecutive note events that use the same instrument. Consequently the instrument definition is repeated for each one, wasting a 16-bit word of ROM space for each note. NEW: Macro NPK.Note() now validates DRM event instruments to make sure they are non-zero. (Drum instruments go from 1 to 127; a value of zero is invalid). NEW: Updated the "Global Music" module with new instruments and drum samples. I encourage anybody who's playing with the tracker to update to this latest version. If anybody has any questions or encounters any problems, please let me know. -dZ.

Hmm ... I'd hate to admit it, but there is the possibility, however slight, that I may be miss-remembering, and that Eurasia is our ally, and we've always been at war with Eastasia.

Principle. Having a right to something is not the same as being granted access to it by fiat. History has already proven that those notional guarantees of "it'll always be there," sometimes have a way of falling through. There are many reasons why an item is removed from an ostensibly "perennial" catalogue, whether its due to legal, government, business, marketing, or any other kind of pressure (including bowing to tweeter storms and misplaced public outcry). It has happened. And when it does, no matter the justification, the end result is that people lose access to something that they otherwise would not have, had they had an enforceable right to it, such as private property rights to a physical object or the first sale doctrine. Not trying to take a stand myself, just answering your honest question with an honest answer.

Hmm ... I do not see the difference. All VARPTR does in that context is treat the label heading the dataset as an array, which you can then use to compute an index into it to load an individual cell. There's no magic, and it is definitely not different -- or more efficient -- than just putting individual labels in each of those data objects and calling them by name with a count of "1." Computing an index into an array of animation cells is one way of doing it. It could also be a state machine, in which case, labels could suffice as well. I do not see how using VARPTR "frees up more grams for levels" ...

Yay! Thanks for that. Just to be sure, I like the game the way it is, minus the wonky controllers. So if your updated version is just an input-handling and bug-fixing revision, I'm all for it! (I mean, I don't really care to have any new features or changes in game-play). 👍 Just let me know to where I send the cart and how much postage you need. -dZ.

The 64 GRAM cards limitations actually means that there is enough space in graphics memory to hold 64 8x8 cards. Think of those spaces as variables: If your program had 64 variables defined, your program could have any number of values in DATA statements, but you can only load 64 of them at a time into your variables. The DATA statements reside in your read-only memory (ROM), and they are inert until your read them and assign them to a variable. The same thing happens with graphics memory (GRAM). Essentially, GRAM is an array of 64 cards. you can have as many graphic card definitions stored in DATA statements in your program, but you can only load 64 at a time. At any point in time, your program is free to load any card into any of those 64 slots, so you are not limited to loading a complete set of 64 in one go. So, if you have levels with different screens, you can store in your ROM the data for all those cards, and at the right point in your program load them as necessary. If one level only needs to change a few of the cards, then you can do that too. Just remember: GRAM slots are just like variable slots in memory: they are there for you to update as necessary, in any order or number. You just have only 64 slots at one time. -dZ.

Wait. I get that there's pea in the pool, but ... wouldn't the hamburger get soggy?

Well, if you really want to get pedantic, the game is not stored in the RFID dongle, so the license comes in physical media, but the game does not. Your turn. -dZ.

Thanks, that's probably what it was. The games when I was younger were always US releases, and perhaps the first few lots I purchase as an adult were only US releases, so that explains why I never came across those before. Now that I have traded games with others, I have a bunch of crap from all over the world. 😆 Oh, I've never seen those ...

I've seen that on some of mine too. As I recall, the plastic tray was always just molded and included as is. However, I saw amongst my collection that some have a piece of card stock glued to the plastic to keep stiff and make it more sturdy. Honestly, I don't ever remember coming across that when I was younger, so it took me by surprise. Can someone provide some insight as to what the differences are? Is it a US vs. European market distinction?

I was just going to recommend that. You could easily create a macro for it, like this: DEF FN GetGromCard(c) = (c * 8) Then you can just say: SPRITE 0, avatar_x_pos + VISIBLE, avatar_y_pos + ZOOMY2, GetGromCard("x")

I've heard that before in some tracks. I think it's two channels oscillating in phase. I do not know why it happens only sometimes, except that we have already established some time ago that there is no direct way to reset the oscillator counters. What I think is that in jzIntv, the initial state of the PSG counters is deterministic, so if they eventually go in phase, they will always do so at the same point. Do you have more than one channel playing the same sequence of notes on the same instrument? -dZ.

Just do what you can, but don't give up. There are plenty of people here willing to assist if you need help. The more entries we get, the better! It also serves to motivate others in the future. Some of the projects this year are of superb quality, amd there is always room for more! No, it's definitely not you. It seems "working from home" during lockdown actually means "working all the time." Lots of people are burning out. I myself took almost an entire month off from work during December to recover from almost an entire year of working 12 to 18 hour days without break since mid-March. I was dreaming of all the things I was going to do in my free time, but then, like you and @carlsson, I just couldn't get motivated for a few weeks. By the time I started doing something, I had about a week left. Needless to say, none of my projects got completed. Now I'm back to work and the whole thing is starting again. Hey, at least I got my job, my health, and my family (said he, as he knocked heartily on the wooden table) -- even if no motivation to do absolutely anything -- so I count my blessings. dZ.

Oh, that's easy! My Bottom-10 worse like games: Space Battle TRON Maze-A-Tron Vectron Las Vegas Roulette Space Spartans Space Hawk Mind Strike Horse Racing Ice Trek Coleco Donkey Kong Royal Dealer Mousetrap Turbo Star Wars: The Empire Strikes Back Pole Position

It's really not that hard, all you have to do is pick only those which are the ultimate, most favoritest of your collection. Here, let me show you: I start with my last Top-10 list: Dracula Microsurgeon Star Strike Astrosmash B-17 Bomber Bomb Squad AD&D BurgerTime Utopia Loco-Motion He-Man Atlantis Work Whomper Christmas Carol Night Stalker Hover Force And then I whittle it down to only the most critically important to me: Dracula Microsurgeon Star Strike Astrosmash B-17 Bomber Bomb Squad AD&D BurgerTime Utopia Loco-Motion He-Man Atlantis Work Whomper Christmas Carol Night Stalker Hover Force Triple Action: Biplanes Shark! Shark! See?

Just a quick update on this issue: I thought of a quick and dirty work-around. The key is that there are no actual bounds-checking for envelopes, so there is nothing that requires them to be just 64 points. The only limitation is that the note length counter is stored in 8-bit memory, so you cannot exceed 256 points. Therefore, when utilizing the new fastest envelope speed (4) (which updates on every tick), you can just make your envelope twice as long and avoid it running out early. Simple. :) I'll leave the envelope backtracking/jump-back feature for some other day. -dZ.