SeaGtGruff

Ah, the color adjustment question! Yes, the manual for Atari's test cartridge does state that you should set the color pot so the top and bottom colors are the same. However, if you do that then you're setting hue 15 to be the same as hue 1 (or 360 degrees apart), which means the 2600 will display only 120 different colors, not 128! I've never messed with the color pot myself, but it's my understanding that a tiny fraction of a turn results in a big change, and thus it's very difficult to set hues 1 and 15 to be exactly the same color. In that case it seems like the instruction to set them to be the same was probably intended to serve as a general guideline to help make sure you end up in the right ballpark, rather than a strict rule. In other words, if you try to make them the same then chances are that the best you'll be able to do is get hue 15 close to hue 1 but not exactly the same. In that case hue 15 will end up being either (a) somewhere between hue 1 and hue 2, or (b) somewhere between hue 14 and hue 1. If you end up with situation (a) then hue 15 will have more of a brownish tinge; but if you end up with situation (b) then hue 15 will have more of a greenish tinge.

Thank you, calfranklin. I hadn't heard that it was available on Netflix, so I'll be sure to watch it.

You don't need eight writes, just seven: (1) Write GRP0-- with VDELP0 enabled, this updates the "new" copy of P0 but the "old" copy is still displayed onscreen. (2) Write GRP1-- with VDELP1 enabled, this updates the "new" copy of P1 but the "old" copy is still displayed; and with VDELP0 enabled, this also updates the "old" copy of P0 from its "new" copy. (3) Write GRP0-- this updates the "new" copy of P0, and also updates the "old" copy of P1 from its "new" copy. These first three writes let you set up the first three sprites ahead of time (i.e., early on in the scan line, or possibly even during the latter part of the previous scan line depending on the horizontal positions of the sprites), but the data for the third sprite is "held in reserve" for the time being. Then you load A, X, and Y with the data for the last three sprites-- which takes a little juggling, since you're also using Y as an index into the graphics tables-- and time the last four writes so they occur neither too early nor too late: (4) Write GRP1-- this updates the "new" copy of P1, and also updates the "old" copy of P0 from its "new" copy; so this write must finish executing sometime after the first sprite has finished being drawn but before the third sprite needs to start being drawn. (5) Write GRP0-- this updates the "new" copy of P0, and also updates the "old" copy of P1 from its "new" copy; so this write must finish executing sometime after the second sprite has finished being drawn but before the fourth sprite needs to start being drawn. (6) Write GRP1-- this updates the "new" copy of P1, and also updates the "old" copy of P0 from its "new" copy; so this write must finish executing sometime after the third sprite has finished being drawn but before the fifth sprite needs to start being drawn. (7) Write GRP0-- this updates the "new" copy of P0, and also updates the "old" copy of P1 from its "new" copy; so this write must finish executing sometime after the fourth sprite has finished being drawn but before the sixth sprite needs to start being drawn. It doesn't matter whether you write A, X, or Y to GRP0 in the last step, because the "new" copy of P0 won't be displayed anyway-- this extra write is strictly to ensure that the sixth sprite displays the correct graphics. It also doesn't matter whether you arrange the sprites as P0-P1-P0-P1-P0- P1 or as P1-P0-P1-P0-P1-P0, although if you decide to position P1 first then you'll need to change the order of the writes to P1-P0-P1-P0-P1-P0-P1.

You need to enable VDELP0 and VDELP1. This lets you write the graphics values for the first three sprites early in the loop, leaving just three more that will need to be written with rapid timing. Then read the graphics values for the last three sprites into A, X, and Y. Finally, write A, X, and Y one after the other into GRP0 and GRP1; you'll need to include an extra write so the last sprite will be changed.

I imagine it can be explained by the same explanation that's given for so many other unexplainable muck ups: "It seemed like a really good idea at the time!"

I seem to recall that you're right about that, but I can't remember where/what the mistake was. I may have posted about it in another thread a few years ago. Also, note that the non-USA versions of the games are different than the USA versions.

FireWorld is actually winnable once you know the pattern for finding the number clues-- although it still takes a while to work through the possible combinations. WaterWorld is the most playable of the three as far as finding the number clues, since you get hints throughout the game as you drop items in rooms. EarthWorld is (IMHO) the least winnable SwordQuest game, since there seems to be no rhyme or reason to how you trigger the number clues as far as how many items need to be left in how many rooms.

Or some other fixed-spacing font of your choice; let it be selectable.

Yeah, you know-- hedgehogs, elves of all types (dark, forest, high), dwarves, ogres, halflings, lizard people, panda people, etc., etc.

When do we get Skyrim 2600? I don't know if it's been mentioned yet, but there's a slight "bug" in the two-color version-- namely, as you're moving or panning there's a lag between the two colors from one frame to the next. I'm not sure if there's any way to fix it, which is why I say "bug" in quotes. Now all you need to do is completely rewrite the engine to use ChronoColor or whatever Andrew calls it, so you can draw eight-color worlds!

Yeah, I figured the human stars would sign it. As far as never meeting actors, I've met a few in years past at science fiction conventions, although I haven't been to a con in decades. I even rode on the elevator with Freddy Krueger (Robert Englund) and two of Doctor Who's (Peter Davison's) companions-- Tegan (Janet Fielding) and Turlough (Mark Strickson). I didn't speak to them, because I was too "star-struck." I got a laugh out of Mark Strickson's story-- told during one of the sessions-- about how he had to run around in shorts for one Doctor Who episode (I think it was "Planet of Fire"), so everybody on the set started calling him "Legs." When I was getting him to autograph a photo for me, I asked if he'd sign it "Legs," which he did-- although he probably thought I was a bit wacko for asking!

But who would it be signed by-- the sharks? Maybe have a special custom cartridge made that's shaped like it's got a bite taken out of it.

Only if he calls it Link, Legend of Zelda, etc. I vote for "Zinc: Legend of Imelda."

We're looking forward to seeing what you make!

Well, it's okay to define the playfield just once like that, but you need to put the drawscreen in a loop so the 2600 keeps drawing it 60-ish times a second. So just change the last part of your program to something like loop drawscreen goto loop end

I just noticed you got pixelated. Is it an actual screen capture? If yes, is it from a 2600 or 7800?

Yep, the manual indicates that you should use the in-game number clues to find the words hidden in the comic book, but the number clues are just sequential numbers-- 1, 2, 3, 4, etc. If you try to find any correspondence between those and the comic book, you'll just go crazy (or crazier, if you were already crazy). I read much later that the sequential number clues were (most likely) just "place holders" that the programmer had evidently meant to replace with the actual page and panel numbers from the comic book. Maybe the unfinished ROM got put into production by mistake instead of the finished ROM, or maybe the comic book wasn't ready soon enough for the programmer to go back and put in the page/panel numbers before the game had to be put into production to meet a deadline. So everybody just combed through the comic book to find the hidden words, then used the extra clue inside the front cover to figure out which of the words were the correct ones. That was probably also how a lot of people found the words hidden in the EarthWorld comic book-- except the last of the correct words was hidden differently than the others, so a lot of people (including moi) found only four of the correct words. Said we-uns didn't get to play in the EarthWorld contest, we just got a certificate to show off to the world.

Yes, if you know there are words hidden in the panels of the comics then you can search each panel for words. However, it's possible that a word is hidden differently than the others, or that what looks like a word actually isn't, as was the case with EarthWorld-- one word (which was one of the five "correct" words) was simply in boldface in a speech bubble rather than being hidden in the picture, and what looked like a word hidden in a picture turned out to be a red herring. So unless you knew the number clues from EarthWorld you might not get all the words correctly. FireWorld was a different story, since the "number clues" were apparently dummy placeholders that never got replaced with the actual number clues, hence the only way you could find the words in the comic book was to search through the comic book.

Video games in general have no value beyond the pleasure they elicit from playing them. (Well, they sometimes also have value as inducers of twitchy movements, sleepless nights, meal-less days, mental breakdowns, and stuff like that.) So whether the SwordQuest games have any value beyond their contests depends mainly on whether you gain any pleasure from trying to crack a combination or password-- since that's sort of what trying to figure out the correct combinations to trigger the in-game number clues amounts to-- and to a lesser extent on whether you like playing the "skill and action" sequences. The games don't actually depend on their accompanying comic books at all. The *contest* did, or trying to figure out what the correct words were to qualify for entering the contest, but the video games themselves don't really use any information from the comics. You can successfully play and win each of the three SwordQuest games without ever laying eyes on their comic books-- well, in theory you can win EarthWorld, although I personally found it to be the most "unwinnable" of the three, since there's no discernable pattern to triggering the in-game number clues. WaterWorld is the easiest to play and win because of the in-game "clues" that help you figure out what combinations to use to trigger the number clues, whereas FireWorld is somewhere between EarthWorld and WaterWorld. It's like Atari realized how difficult EarthWorld was to win, so they made each subsequent game progressively easier to win.

Someone in that thread mentioned "Wizardry 8"-- I would have suggested that one, as well. I've never played any of the other "Wizardry" games.

Okay. In that case, I vote for "3E Whee." Edit: Or "Whee 3E."

I believe the Krokodile Cartridge can: http://www.arminvogl.de/KrokodileCartridge/ If you click on the link for the Krokodile Cartridge Manual and scroll down a bit to the list of cartridge bank-switching formats that are supported, you'll see "3E (up to 512K ROM and 32K RAM)."

But if the limitations were related to using 3E bankswitching on a Cuttle Cart, does that mean an actual 3E cartridge could have 512K ROM and 256K RAM? If so, it would be nice for Stella to support that, in case anyone ever wants to develop a 3E game with 512K ROM and 256K RAM.

The new one looks good in my browser/desktop resolution-- you could even make it a little bit wider.

Ah, I think I know what happened. Remember that if you're using VDELP0, writing to GRP0 won't cause any change to player0's graphics-- the new value won't show up until you write to GRP1. That means if you don't ever write to GRP1, player0 will be drawn with its "old" value, which will probably be all zeros. So if you're using the "skip draw" method or something similar, such that you aren't writing to GRP1 on the lines where player1 doesn't appear, then on those lines you'll likely have an issue with player0's graphics. The solution is to always write to GRP1-- on lines where player1 doesn't appear, write zeros to GRP1.