DZ-Jay

Wow! That's an impressive score. I agree, it is a very addictive game, in spite of its simplicity. It reminds me of "Up Monster" -- another super-simple but addictive game by @atari2600land. -dZ.

I kind of think it was that way. As I remember (and it has been several decades, since I last played, so I could be wrong), at the end of the game, you would get an account number if you paid back your initial loan and earned a profit. If you didn't, you would get a message about going bankrupt or something. I sort of recall that the point of the game was that you were starting a franchise and received a $10,000.00 loan from the bank to start, and you need to pay it back and succeed as a business. dZ.

Very nice review. Thanks for sharing it. I too have fond memories of the C=64 version, which I played for days on end, and it remains one of my favourite games of all time. The Intellivision Ultimate Edition improves on the original in significant ways. dZ.

Yeah, sorry about that. I saw it in my sprite animation data, but I thought it was weird because I don't recall ever getting that far (the ROM I posted before, with the Pac-Man sprite running around and eating dots was all I did back then). I'll work on it. Cool! 👍

Ah, it's ROM only. Boo! 😕 Are you planning on releasing it in cartridge format? -dZ.

I finally got around to playing your latest version. Here is my feedback: The difficulty ramp seems strange: It is very easy for quite a number of boards, but then it just seems to speed up considerably all at once. Maybe the speed increase should be leveled more gradually. Also, when the ghost speeds up, Pac-Man should also speed up -- at least up to a point (like in the original game). Remember: a faster Pac-Man does not necessarily mean an easier escape from the ghost -- it also means a harder to control Pac-Man, especially in such a limited horizontal space. The death jingle seems off. I think the sound may be too high pitch. The death animation does not seem smooth enough. This is probably my fault, the sequence I sent you included just the key frames, but I had not yet implemented death back then, so it was not fully realized. I can work on that if you'd like. In the original game, there is a pause for about 2 seconds from when Pac-Man touches the ghost and the death animation starts. It seems to go like this: 0 sec: Sprites freeze 1 sec: Ghost disappears 2 sec: Death sequence starts I am not very fond of having to press a keypad key to select disc or button at the title screen to start the game (it forces me to move my eyes to focus on the hand-controller, while pressing the disc or button feels intuitive and can be done without even looking). If you want to support both schemes, I propose the following alternatives, in order of preference: Accept both types of input automatically during game-play. There is not much going on in the game (only a couple of sprites and no complex mechanics), so you should be able to decode both disc and button at the same time. Select the disc as the default input scheme, but offer the option for the player to switch it in the title screen. Use disc if the player pressed the disc to start, or button if they pressed the button. When Pac-Man eats a ghost, he disappears (yay!), but his eyes are still visible (boo!). I suggest disappearing him completely during the pause, and only show the eyes once they start moving. And here is my latest score: -dZ.

For the record, I misspoke about the "bas-interface.bas" file -- it needs to be included at the bottom of the program (i.e., outside of the program execution flow) because it includes the code library modules and data tables. Here is an excerpt from my test driver to play the "TRON Anthology" track from IntyBASIC: Notice that the tracker interface module for IntyBASIC is included at the bottom, followed by the instrument and song data (which could have been put in a single file, but I broke it up into separate modules). As for code segment segregation, make sure that the "bas-interface.bas" file occurs within a single ROM segment. The music data does not need to be all in the same segment, unless it is a single data block. For reference, below are the most common ROM segments. I intend to include a feature in the next version of the IntyBASIC SDK that will allow you to easily allocate code and data in ROM segments. ; -------------------------------------- ; Memory map for 42K ROM cartridge ; -------------------------------------- ; SEGMENT RANGE ; 0 $5000 - $6FFF : 8K ; 1 $A000 - $BFFF : 8K ; 2 $C040 - $FFFF : 16K ; 3 $2000 - $2FFF : 4K ; 4 $7000 - $7FFF : 4K ; 5 $4800 - $4FFF : 2K ; ; CARTRAM $8040 - $9EFF : 8K ; -------------------------------------- * K = Kilo-Decle (16-bit words), not Kilo-Byte (8-bit bytes) Segment #0 is the default memory range that IntyBASIC uses. You can see that the largest range is in segment #2. -dZ.

I may have misspoken. Let me check what is in the “bas-interface.bas” file. It may not work at the top, if it includes code modules (I can’t remember right now). If you do not mind sharing your code, I could try to troubleshoot it. I’m rather handy with the assembler and debugger … Maybe just the generated listing file from the assembler, or the song data itself. I would understand if you rather not, but in that case it would be harder for me to know what is going on. dZ.

There is one more thing to try: See if your program is blowing out of the available address space in its current segment. It may be the case that your song data is being allocated outside the address space that is visible to the CPU, and thus fails to read data correctly. If that were the case, you can add something like the following right before all your program data, which typically lies at the end of the program (i.e., outside the program execution flow). ASM ORG $C040 Let me know if this helps or not. -dZ.

Yes, that is a good point. Wow! That is amazing. I would be very interested in playing around with GoatTracker and your tool whenever we get all this sorted out. Hmm ... That is strange. Would you mind sharing your song file with me? You can send it in a PM if you'd like and I can troubleshoot it. The integration with IntyBASIC should be fairly straightforward, as described in the User's Guide (Appendix B): Include "bas-interface.bas" at the top of your program. Include your song file at the end of your program, with a handy IntyBASIC label preceding the song data so that you can reference it later from IntyBASIC. Call TRKINIT() during your program's initialization phase. Call TRKLOADSONG() with a pointer to your song data, to start song playback. Call TRKPLAY() on every tick to update the playback state of the tracker. The "bas-interface.bas" library should take care of everything, including RAM allocation and appropriate library module inclusions. A few things to check, just in case: Make sure you call TRKINIT() only once per program. Calling it again will stop playback and reset the tracker. Make sure you only call TRKLOADSONG() only once -- this loads the song and initializes the tracker for playback, so calling it again would just restart playback. Make sure you are not writing to any of the variables used internally by the tracker. These would be allocated as two arrays: TRK_BYTEVAR and #TRK_WORDVAR. Check that your song data has the correct number of pattern tracks that match the number of tracks configured (3 or 6). Check that all sub-pattern definitions used in a particular pattern match the length defined for that pattern. Make sure the data format generated matches the IMT format, as described in the documentation. (It may be easier to troubleshoot if your program generates IMT NOTES() macros rather than the raw data itself). I hope the above helps. If not, let me know. IMT has been used successfully in IntyBASIC programs in the past (and integration was as simple as described above), so it should certainly work. -dZ.

Not to rain on your parade, but I wonder if this thread would be better in the “General Chat” area of AtariAge, since it is not remotely Intellivision-related. Maybe the mods can move the thread?

You are most welcomed. Yup. I tend to do things the hard way. One of my goals with IMT 2.0 is to be able to use something like MilkyTracker and translate the generated XM files to IMT 2.0 format. That, and create an actual tracker program for the Intellivision. It wouldn’t work to use that technique from GoatTracker, true. It also would be tricky to do it by hand, since you would have to account for the fact that tone and noise are mixed by ANDing their outputs rather than ADDing or ORing them, which means that their combined sound tends to modulate the timbre of the noise rather than it’s pitch. Ready! The DRUM macro generates data that is pretty much passed through to the PSG device’s registers. Therefore the tone and noise values are not frequencies but oscillator periods. Zero essentially turns off the oscillator, and shouldn’t be used unless that is exactly what you are looking to do. (Changing it back to a higher value later on may result in an audible click due to the way the oscillators are cycled.). Typically, if you want to stop output of a PSG oscillator, whether tone or noise, you set its volume to zero and leave its period as is. If you feel compelled to reduce the period, then try to avoid going below 1. The noise period is controlled by a 5-bit register, so it can go from $01 to $1F. Since the noise generator generates white noise (or something close to it), the period serves to bias the frequencies included. Essentially, higher values act as a high-band filter, while lower values act as a low-band filter. (Wait, I may have gotten those reverse, but you should still know what I mean: one extreme has more higher frequencies than the other.) dZ.

Hi, @Eiswuxe, Attached are the drums definition for the TRON song. The "drmCombo" definitions are a combination of the "Synthpop Kick" drum sample and the "Bass" instrument, interpolated by hand. I took the first few ticks of the kick drum definition (to establish its presence), then followed it with the tone and envelope definition of the bass instrument, tuned to a specific note. I then repeated the process tuning the bass tone to different notes depending on where the kick drum hit in the pattern. (Note that these drums require 32 samples, so to use them, you need to set the TRK_DRUM_STEPS constant to 32 in the "global-config.asm" file.) This way, I could have the bass line playing on a channel, with the points where the kick drum is supposed to hit replaced by the appropriate tuned drum instrument. The end result was drum and bass on one channel. (I should have done a similar thing for the snare drums, but didn't think of it at the time. In retrospect, you can tell when the song goes from a pattern in which drums and bass are played in separate channels, to a pattern in which both are played in the same channel; precisely because the bass cuts out when the snares hit. It still gives it a nice and distinct rhythm to the choruses, but it was mostly inadvertent.) I also include the instrument definitions for the track, just in case they can be of any use. -dZ. tron-drm.asm tron-inst.asm

I understand. Can't you use 2 channels in GoatTracker to synthesize one drum, one for tone and one for noise? I haven't used GoatTracker, so I do not know its limitations. I am somewhat familiar with the SID, though, having programmed it directly myself in the past. Also, I wanted to offer a small patch: Right now, IMT 1.5 requires drum samples to be all of the same length, as defined in a configuration constant. This can lead to a lot of waste for shorter samples (like hi-hats). I could patch the 1.5 code to support drum samples of arbitrary length, so that the constant is no longer necessary. You could then create drum samples as long or as short as you need them to be. Let me know if you are interested. It is a small change. dZ.

It is my pleasure. Sounds good. Great! By the way, I have other drum instruments I used in the TRON remixes, if you want them. (It turns out I am pretty darn good at synthesizing drum sounds. ) dZ.