DZ-Jay

January 26

4 hours ago, intvdave said:

I just can not stop updating this game

Thanks for all the IMs. I will work through them once I finish the game. It is best to complete the game correctly this time than rush it again. Everyday I feel closer to finishing...soon...

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.

January 26

31 minutes ago, cmadruga said:

Thanks! A lot of work, and time, (and love!) went into it.

Don't worry, I'll be gentle with my feedback.

31 minutes ago, cmadruga said:

FYI, the "Player Guide" has a simplified map on its last page... but I think it's more fun to play and make your own map or annotations as needed.

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.

January 25

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.

January 25

1 hour ago, carlsson said:

I would imagine one reason PuzZLeR uses two voices for the same tone is to accentuate those, making them sound louder but then again I haven't experimented if that really is the case, that volume on each channel are accumulated in the final output.

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.

Quote

Again, this discussion reminds me about the VIC-I chip on the VIC-20 which generates similar artifacts. On that chip, the actual pulse width may change for each note played, and Viznut a number of years ago came up with a way to wait out the counters to deterministically be able to play notes at different pulse widths. Possibly the AY chip could be controlled in similar ways. Then again that chip is used on so many other systems that it should be common knowledge about counters and phases, unless the other systems use slightly fixed versions of the same chip.

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

Quote

They are free running.

Also, the reset condition for the count goes into a simple toggle flip-flop for the tone output. There's no way to reset that toggle to a known phase.

So, if you play the same tone on multiple channels, there's no way to fully control their relative phase on either version of the PSG. You do have more control over where toggles happen on the later design (greater-or-equal). You have zero control over whether it's outputting 0 or 1 on an active tone channel

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.

January 25

2 hours ago, carlsson said:

I doubt the AY chip would be harmed if two of the oscillators are in reverse phases, effectively cancelling the output. The question is how to avoid it, if changing the tone enable bit in register R7 will reset counters. While we can use SOUND 4,[NOISE 5 bits],[MIX] to set that register, I'm not sure what happens if one does that in the middle of the music player is operating, or if it does any difference.

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.

January 25

7 hours ago, PuzZLeR said:

Hi DZ-Jay.

Do you think it would be unsafe on real hardware? I remember one of your posts somewhere that a stack overflow, although very dangerous to the program, will not affect hardware in any way. I'm thinking the same thing here, but still not sure. Just don't want anyone's Inty damaged by this. (Ha ha, but also serious.)

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.

January 25

2 minutes ago, PuzZLeR said:

People questioned my musical tastes over the years. (Yeah, into that "hard stuff" still.) But never knew it would violate an Inty sound chip, at least in emulation. (I liked this jingle because it sounds like a guitar solo. A bit.)

I know it's a hard problem, but I am still curious if this effect happens on real hardware. I don't think it unsafe, but if the experts say it's unsafe, then I'd rather it not tested if it's capable of busting a real AY.

Thanks again!

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

January 23

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.

January 22

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.

January 22

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.

January 22

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.

January 22

4 hours ago, Tommy Tallarico said:

If you can play the game "years" from now no matter what... I'm interesting in understanding what you feel the difference would be.

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.

January 22

8 hours ago, skywaffle said:

Doing this not only frees up more grams for levels, but allows for much more complex animation. It's also nice to use DEFINE VARPTR for pulling in graphics for stage bitmaps as you need them.

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

January 22

8 hours ago, intvdave said:

I agree with DZ's statement that controlling the man was clunky.... NO MORE!!! I have spent some time on this game as I have always loved it. The disc controller input has been rewritten and I think works much better. I have cleaned up other aspects of the game also. If you have an Intelligentvision game board of KotM, it can be upgraded for cost of shipping. This is an old thread and an "old" game so I am curious if there is any interest.

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.

January 22

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.

January 22

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

January 21

13 minutes ago, mr_me said:

The rfid stores the license information. Since that is digital storage, it is technically physical media.

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.

January 21

1 hour ago, Intymike said:

I would say that on the international versions the cardboard was alway on the back.

My first game without it was a US only release. Probably Fathom.

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

1 hour ago, Intymike said:

another thing is that some of the plastic trays are white instead of the normal black.

Oh, I've never seen those ...

January 21

1 hour ago, Intelligentleman said:

This one seems glued to the tray. My other imagic games with boxes haven't had this inclusion. Perhaps they fell off and we're lost over the decades.

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?

January 21

6 hours ago, mmarrero said:
The way I've done it with a constant, multiplying the character code by 8.
SPRITE 0, avatar_x_pos + VISIBLE, avatar_y_pos + ZOOMY2, ("x" * 8) + SPR_WHITE
SPRITE 1, avatar2_x_pos + VISIBLE, avatar2_y_pos + ZOOMY2, ("\95" * 8) + SPR_RED '--solid block

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

January 20

1 hour ago, nanochess said:

I only can say: interesting! After leaving it to play for around one minute in my Macbook Pro, it starts chirping, like an artifact in the jzintv audio generator.

Anyway in real hardware this glitch shouldn't happen (I'll test it out of curiosity as soon as possible). Maybe @intvnut can chime in for an explanation?

I've made a video, the effect happens at 58 secs. approximately.

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.

January 19

14 minutes ago, PuzZLeR said:

I do have something, but it's something that I've been working on for months, again, bit by bit, and not worthy of any victory as of yet. It sucks that I too may have to opt out of this contest.

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!

Quote

And, is it me? I feel this pandemic has had an effect on my concentration levels. Maybe it's just my imagination, but something is off.

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.

January 18

7 minutes ago, JasonlikesINTV said:

Hey, I got mine down to 21.

Someone should start a " What's your BOTTOM 10?" thread.

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

January 18

1 minute ago, cmart604 said:

Right? I whittled down to around 30 after my first pass through as well. Then it got difficult...

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? :grin:

January 17

On 1/15/2021 at 10:52 AM, DZ-Jay said:

I found another issue ... well, more of a potential side-effect. The tracker does not have any bounds-checking for envelopes, so when it reaches the end of the array, it just continues reading whatever follows (which could be another envelop, or anything else in the data stream).

At a glance, it appears that the tracker expects all envelopes to end at zero volume; because when the volume of a channel goes to zero, envelope processing automatically stops.

However, if you forget to end an envelope in zero (say, you were trying to make a long, sustaining envelope), then if the note lasts longer than the envelope, it will not work as intended.

Note that this only manifests in special circumstances, mostly when the note is exceedingly long and the envelope is on its highest speed.

I am not sure if I should change this behaviour. I could easily mask the upper bits of the counter to force the envelope to cycle, but I do not know if this is desirable at all. It could be used for repeating envelopes, though, which are not supported right now and sounds like a useful feature to have.

What do you think?

-dZ.

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.

Sign In

Profiles

Member Map

Forums

Blogs

Gallery

Calendar

Store

Posts posted by DZ-Jay