DZ-Jay

Yes. I believe @artrag came up with a way to play low-bitrate (very low!) samples through the normal Intellivision sound chip. The result is not as crispy clear as the Intellivoice, but still adequate and mostly intelligible. It may be worth reaching out to him, unless you have access to the special secret Intellivoice Samplers Club. dZ.

I was just about to say a similar thing. Plus, why would they want everyone to think that the Intellivision version was as crappy and limited as the Atari VCS version? dZ.

You shouldn’t need bank-switching unless the amount of voice data you want to include exceeds the available space in the default bank (~42K words). It all depends on the size of your game and the amount of voice data, but bank-switching is not a requirement for voice — having an IntelliVoice is the only requirement. Good luck with your project. dZ.

How long did it take to make the Colecovision DK? Because if it took a lot longer than 90 days, and could afford a ROM larger thank 4 or 5 KB, then it sounds to me a lot like “never mind the budget — make sure ours looks and plays better than the others, whatever it takes!” sort of situation. In that view, the programmers for the other consoles may not have been asked specifically to make crap games, but that sounds like a distinction without difference. dZ.

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?