catsfolly

I'm sorry if this sounds dense, but would you mind explaining the algorithm a bit? You are obviously making some optimizations but I'm not sure I understand them. In particular, why the alternation between SUBR/ADDR for R3? Also, why use "ADDI #-100000 AND $FFFF" instead of "NEGR" once outside the loop and then just using ADDR with the 1000 in another register? Does NEGR not set the carry bit when an overflow occurs in the negation? I'm trying to implement my own bin2dec routine to display score, more as a learning exercise, but I can't seem to understand exactly the mechanisms that make yours work. -dZ. I haven't looked into the carry bit operation much, but think I can explain the alternating subtracts and adds. Basically, we are doing a divide by doing subtracts and counting the number of subtracts we do. Imagine we are working on the hundred's digit. So we have a number "num" that is less than 1000. The code in C would look like this: digit = 0; while (num >= 100) { num = num - 100; digit = digit +1; } // use digit to set a display char digit = 0; while (num >= 10) { num = num - 10; digit = digit +1; } // use digit to set a display char In assembly, this would look like clrr r3 mvii #100, r1 ; Power of 10. BCDLoop3: cmp r1, r0 ; is num lt 100 blt done3 ; yep, done subr r1, r0 incr r3 b BCDLoop3 done3: ; output r3 clrr r3 mvii #10, r1 ; Power of 10. BCDLoop4: cmp r1, r0 ; is num lt 10 blt done4 subr r1, r0 incr r3 b BCDLoop3 done4: If we study this code, it seems inefficient. The cmp r1, r0 instruction subtracts r1 from r0, sets the flags, and then discards the result of the subtraction. Then the subtract instruction does the same subtract again. To fix this, we could do the subtract every time to set the flags. But this means we would be subtracting 100 one too many times from num, so we have to add back 100 to fix up num. digit = 0; while (1) { num = num - 100; if (num <0) break; digit = digit +1; } num = num + 100; // we did one too many subtracts, so fix num // use digit to set a display char digit = 0; while (1) { num = num - 10; if(num<0) break; digit = digit +1; } num = num + 10; // we did one too many subtracts, so fix num // use digit to set a display char In assembly, this would look like: clrr r3 mvii #100, r1 ; Power of 10. BCDLoop3: subr r1, r0 blt done3 incr r3 bc BCDLoop3 done3: add r1, r0 ; fix up r0 ; output r3 clrr r3 mvii #10, r1 ; Power of 10. BCDLoop4: subr r1, r0 blt done4 incr r3 bc BCDLoop3 done4: add r1, r0 ; fix up r0 ; output r3 As you can see, the loops are smaller. We could optimize this a bit more by initializing r3 to "-1" and then always doing the increment: mvii #-1, r3 mvii #100, r1 ; Power of 10. BCDLoop3: incr r3 subr r1, r0 bge BCDLoop3 done3: add r1, r0 ; fix up r0 ; output r3 mvii #-1, r3 mvii #10, r1 ; Power of 10. BCDLoop4: incr r3 subr r1, r0 bge BCDLoop44 done4: add r1, r0 ; fix up r0 ; output r3 But, is there some way to avoid doing the fixups? This is where the alternating subtracts and adds comes in. In C digit = -1; while (1) { digit = digit +1; num = num - 100; if (num <0) break; } // num is now negative number (or zero) // use digit to set a display char digit = 10; while (1) { digit = digit -1; num = num + 10; if (num>= 0 ) break; } // num is positive // use digit to output the character In assembly: mvii #-1, r3 mvii #100, r1 ; Power of 10. BCDLoop3: incr r3 subr r1, r0 bge BCDLoop3 done3: ; output r3 mvii #10, r3 mvii #10, r1 ; Power of 10. BCDLoop4: decr r3 addr r1, r0 blt BCDLoop44 done4: ; output r3 Does this make sense?

WooHoo! I finally got something on the Intellivision to a playable state! As far as I can tell, this game started out as a set of programs called DSTAR for the TI graphical calculators by Joe Wingbermuehle and Andrew Von Dollen (there is also a version for the HP calculators - I'm not sure which came first...) Since then, there have been several other versions. Last month, Stefano Bodrato made a version for the Jupiter Ace computer, and I saw a video of that version on youtube. This was the first time I had seen the game. Since the game is based on 16 by 9 grid and has few moving objects, it seemed like a good fit for a quick Intellivision conversion. So, I made a copy of "Tag Along Todd" and started hacking away at it to turn it into DSTAR. Unfortunately, I kept adding features to the program, so it took much longer than I had hoped. But now I've about run out of GRAM, so I guess it must be done. I would appreciate any feedback anyone has. I would especially like to know if it runs on a real Intellivision, since I have no way of testing that at this time. If you press 9 on the keypad while playing the game, you can switch to an editor. You can edit your own level and test it out. Unfortunately there is no way to save your level. But, if you make a cool level and send me a screenshot (or a dump of scratchram), and (if I like the level and have the space,) I can add it into the game... Currently, there are 25 "classic" levels (from the ti-83 calculator version) and 11 new levels that I have made. I recently discovered that Atariage has a 2600 version of this game called "Astar", so I am calling my version "Istar". (Hopefully Apple hasn't reserved that name for something...) Thanks for checking it out... David istar.rom.bin

Kaboom could be done on the Intellivision. The bombs couldn't be as colorful as the Atari 2600 version though. And it would be harder to play the game with the Intellivision controllers (the 2600 version worked best with the paddle controllers.) (Hmmm... (WARNING - rambling technical "thinking out loud" interlude follows) Maybe if we used scrolling to move the bombs,and then on each frame, offset the paddle and bomber motion object positions so they didn't scroll, and dynamically counter-scrolled some gram stamps to display a non-scrolling score, and dynamically swapped out the stamps for the border between the top of the screen and the bomb area to counteract the scrolling effect, we might be able to put the bombs and fuses on separate backtab characters and have burning fuses...)

Actually some changes were made to the exec ROM for the Intellivision II, and these changes (accidentally or on purpose?) caused some Coleco games not to run. So it was actually a continuation of the "protection by keeping the programming details secret" technique. At the time, company lawyers weren't sure about the legal implications of having copyright protection for cartridges (for example - having the exec look for the string "Copyright Mattel" inside the cartridge and not run the game if it didn't find it). So they just tried to keep everything secret. (A few years later, one of the early versions of the IBM PC had a bios program that looked for the string "copyright IBM" in the graphics card bios and would only run the bios if it found that string. So graphics card clone makers put a message like "we're not associated with IBM, but we need to put the letters "copyright IBM" here so the code will work" ...) In hindsight, what they should have done was what Nintendo did - make it easier and more profitable for third parties to work with the console maker that to go it alone (by reverse engineering the system and hoping it wouldn't change underneath them...)

Well, hindsight is a wonderful thing I guess. Imagine that for two years, every product your company made sold out, and your biggest problem was figuring out how to increase production fast enough to meet demand. This was the situation at Mattel Electronics (and probably Atari and other companies as well) from mid 1980 to mid 1982. (I went to toy stores in early 1982 to see what games were selling, and even "Poker and Blackjack" was sold out. And that was the pack-in game! Why would anyone buy it?) In such a situation, the company leaders will tend to come to one of two conclusions: A. We are the luckiest people in the world to be at the right place at the right time with the products people want. Or B. We are product development geniuses who instinctively know exactly what the public wants. Unfortunately, many industry leaders went with "B" and buoyed by their fantastic past successes, believed that they knew what they were doing even as the business was crumbling around them. As far as the Colecovision goes, it looked like vaporware until it actually shipped. At the 1982 Winter CES, Coleco showed nothing - only arcade game logos and empty cartridge shells. At the summer show, they had a closed booth. On the outside of the booth they had monitors supposedly showing "coming soon" "Colecovision" games, but in some cases these were just video tapes of someone playing the arcade game (this was obvious in the case of Zaxxon, where the Zaxxon joystick blocked part of the screen...) Most importantly, they didn't show any finished game. Everyone in the industry knew that it took 2-3 months for a game to go from completed code to mass-producible masked roms, so if the games weren't finished by summer, they couldn't ship in time for Christmas. So it looked like Coleco couldn't deliver on their promises. But, to everyone's surprise, Coleco did ship. The early games shipped on EPROM cartridges, which were usually only used for engineering prototypes. Donkey Kong versions changed weekly. Meanwhile, Mattel's next generation system was stuck in the labs, a victim of creeping feature-itus... Because of the runaway success of video games in 1981, in 1982 everyone and his brother started up a video game company. Since everything made in 1981 sold out, regardless of quality, these companies did worry so much about game quality (in general...) So, the market was flooded with mediocre games, and every time someone bought a mediocre game, they thought about other, better uses for their entertainment dollars ... Mattel and Atari and Coleco had operated on the principle that the console makers would be the only ones to make games for their systems - protected by keeping the internal details of the systems secret. When demand exceeded supply, the third party game companies sprang up - but with no controls on quality. Meanwhile, in Japan, Nintendo had invented "licensing" - they protected their system from unauthorized 3rd party games with lockout chips involving patents and copyrights, and then sold licenses to companies that wanted to make games for it. This meant a great supply of games for the players, and quality control (and profits from each game) for Nintendo. In hindsight, the biggest mistake the old game companies made was not inventing licensing or something similar.

> The Inty isn't very good at drawing arbitrary lines as required by Missile Command... Well, that's true, but the Atari 2600 isn't good at drawing arbitrary lines either, and Atari still managed do to a simplified version of Missile Command for the 2600 that captured the essence of the game (with a lot less arbitrary lines.) Probably something similar could be done on the Intellivision...

The problem with Qix is that it requires a bitmapped display, where every bit can be turned on or off. The Intellivision has a character based display. There are 64 characters that can be defined by the program, for the background and the sprites. So, out of the 20 by 12 character display, the Qix play area could only be about 8 by 7 characters. And, only 2 colors can be used on a character, so the "filling in" of squares would have to be done with fill patterns. (non-artists conception...)

That's a great trick. Finally, a use for the RSWD instruction!

I got 0 points! Has anyone beaten that yet? So far so good! The screens look good and the transitions are smooth and quick. The player character moves kind of fast - it's great for zipping down long highways, but in some of the smaller rooms it's hard to get through the narrow doors. Maybe the character could start out moving slow and quickly accelerate to a higher speed. That would enable the player to do the fine maneuvering needed to line up with the doors. Just a thought. The seems to be a tall stack of green plates on the right edge of the display - what's the deal with that? Looks promising!! Thanks for letting us try it out!