Kurt_Woloch

Well, as far as I can remember (since nobody else replied to this), you have to feed the whole screen content of the LCD every time it is updated... which involves using 4 of the LCD lines for the pixel data and 2 of them for synchronisation. The data gets "strobed in" 4 pixels at a time, thus in a total of 64 strobes, by the CPU. And... I think I've found two more consoles which didn't have homebrew... the Epoch Cassette Vision and Epoch Super Cassette Vision, which are two little known consoles from Japan. You can find out more about them in this thread: http://www.atariage.com/forums/index.php?showtopic=130365

Well... this seems to be slightly undoable to me, but it would be doable with some modifications: The thing you call "score" obviously would be a 6-char. Above that you display the hand and call it "playfield". This doesn't work... the playfield doesn't have such a high resolution as displayed... but another 6-char would do nicely, with one exception: the 2-digit number on the right to it can't be displayed, but if you move it one line up, on the right to the player arrow, it would fit there nicely.

Ok, this is my best so far... 7160.

OK, I managed to improve my score... a bit. 35121

My games this week: Park Patrol (C-64, emulated in VICE): 584 minutes Reactor (2600, emulated in Stella): 204 minutes Gremlins (C-64, emulated in VICE): 23 minutes Gopher (2600, emulated in Stella): 4 minutes Donkey Kong Demo (2600, emulated in Stella): 1 minute

Well, that's true. The CV still looked much better... even if you could have managed to make at least the rivet screen (and others) look better on the 2600 too, it wouldn't have been able to look as good as the CV version. And I think Atarisoft doesn't get criticized for their ports for other systems because they were GOOD... for instance, the TI-99 version of DK by Atarisoft is also 16K long, but has all four screens (like all DK ports by Atarisoft I know have) and still overall better graphics than the CV and also Ocean's MSX version (although it's working with the same video chip). And they were absolutely not ashamed of making their ports look better on other systems than they do on Atari's own systems if it was technically possible. For instance, on the C-64, Mario Bros. has better graphics and a better framerate than on the Atari 8-bit, Ms. Pac-Man has more colorful, non-flickering ghosts (because the C-64 is able to display 8 multicolor sprites), Dig Dug has multicolored enemies, and the list goes on... in my opinion, their unreleased CV ports even put Coleco's own games to shame (though you can't quite compare them, because of course they are different games). So I dare say Atarisoft generally put much more effort in their games than Coleco did... on any system they released them for.

Here's my best so far... 29793 (So close to the next extra life!)

Well, I have my own theory on that. Note that Colecovision DK is 16K long, but 2600 DK is only 4K!!! OK, you could say they had to make some sacrifices... but I think they would have had to make much less sacrifices if they would have made the 2600 version 8K or even 16K long. But they gave Garry Kitchen only 4K to work with. Of course, having more memory, it also would have taken him longer to do the game. I think he initially was heading for more. You can see that by the fact that the screen structure of the barrel level got copied pretty well. Then he probably did the kernel, which actually is also pretty well thought out, and the barrel movement, which also was captured pretty well, as is Mario's appearance. At that point it probably struck him that he would need more than 4K to do the game well, and that was turned down, so things went downhill from there... therefore we have the funny jumping movement of Mario and the level structure of the 2nd level which doesn't resemble the arcade one very well, as do the movements of the fireballs in the 2nd level. I think many things could have been improved with a bigger ROM size: - Mario's movement patterns could have been made more realistic - The rivet screen could have been reproduced as faithfully as the barrel screen (even if maybe the fireball's movements couldn't have been) - There could have been included a third or even (in 16K) all four screens (hey, the pie level is totally symmetric!) I do think that it was Coleco's intention to make the other system's versions one step down from the Colecovision version, even if more could have been done. That's why 2600 DK was only allowed to have the two main screens, not more... and why 2600 Carnival is lacking the music and the bear intermissions, which could have been reproduced pretty easily on the 2600.

Classic systems? OK, I'll try again, I hope these all qualify... Juno First (2600 Release Candidate emulated in Stella): 406 minutes Park Patrol (C-64 version, emulated in VICE): 160 minutes Solar Plexus (emulated in Stella): 20 minutes

OK, that's my best so far... 2410.

Well, I did some more research after I read that there also was a predecessor of the "Super Cassette Vision", the "Cassette Vision". Of course that one has even inferior graphics and sound, but nonetheless seems to be an interesting platform (just as the Atari 2600 is). I've found the most complete game description and the highest quality screenshots of that system here: http://www.ne.jp/asahi/cvs/odyssey/hyperli...cv_yosaku1.html (from there on click on "Nextsoft" to advance to the next game) Interestingly, this system seems to have a pretty low resolution, but still seems to be bitmapped. And I haven't seen any restrictions in which colors are allowed to appear where (though there probably are only 8 colors in total). What's also interesting about that system is that each pixel seems to be able to contain a diagonal. But there seems to be something strange going on about those diagonals... on those objects that are made out of diagonals, like the pigs, snakes and birds in "Kikori no Yosaku", you can see black triangles on the left side, but not on the right side. I really would like to know how that system works and what kind of games could have been made on it if it would have become more popular.

OK, here's mine... KO : 88 with 0:02 left.

I see... there seems to be some kind of trickery involved here. What actually surprises me here is that it also seems to be possible to have a text window on the left, and coloured background on the right. Actually, how the text looks like reminds me a bit of the VIC-20 home computer. Never mind... I found a screenshot meanwhile, it's printed on the cover of the game, here: http://www.old-computers.com/MUSEUM/softwa...p;c=&id=288 But I'd really like to read the technical description you wrote in that PDF. Unfortunately, I can't read any Japanese. Is there an English version of it, maybe (other than the main points you gave here)?

Hmmm... now that's a very unique architecture. With that text / BG mode, are you saying that ALL the high resolution graphics in games are created with sprites, since the background can only do relatively big color blocks? Well, it doesn't seem to matter since if really 30 sprites are supported per line, it's possible to fill the whole screen with sprites for a background. In that respect the system is similar to the Atari 7800, which doesn't really divide background and sprites... there the whole screen (or, rather, each scanline) is composed of different size layers which get displayed over each other. It also reminds a bit of the G7000 / Odyssey^2 in that for certain things, only the built-in characters are supported (in this case, the text mode), and in that almost all of the more complex graphics is done with sprites. However, the SCV clearly surpasses the G7000. I'd put it roughly on par with the Colecovision, though it's probably more tricky to program with all the trickery you have to do in order to put a meaningful background on screen. And of course, the sound is probably even worse than on the Atari 2600 and 7800, having only 1 sound generator. But it seems that that one generator at least is able to put out better sounding melodies than the Atari 2600 (not so far off-key). Do you happen to have screenshots or even a video of Pole Position (or was it Pole Position II)? I'd really like to see how that one turned out...

OK, here's mine: 28 - 36 (twice).

OK, I see they write 36 KB of ROM. I guess that's the maximum a ROM cartridge is able to have. I know for sure that there were many much smaller cartridges than that, though... but some actually at least came close to that limit, like the Extended Basic cartridge. And in fact, that figure is incorrect too, but I can guess where it comes from... The TI-99 has an oddity called "GROM", which is a ROM that sequentially gets accessed (similar to how the video chip presents its memory to the CPU). One bank of GROM typically has got 6K of memory. 8 such banks are supported, but 3 of those are already occupied by the console ROM. This would leave 5 banks of 6K each, which is 30K in total (not 36K). In addition to that, each cartridge is allowed to have 8K of CPU ROM, which actually puts the total to 38 K. But as I mentioned earlier, Atarisoft cartridges actually were 16K long, and that was all CPU ROM. They did that by bank-switching the ROM, as it was also done with other systems. And in fact, the GROM system actually supports 16 GROM bases (theoretically even 256 of them), which means that you can put additional GROM's in a cartridge which then are read/written on different CPU addresses. That way, theoretically up to 256 * 30K might be used in a cartridge, which gives an address space of 7,5 MB ROM on a cartridge, if you're really in for it (in addition to the bank-switched CPU ROM's). However, software has to be written on the cartridge to account for that since the console routines only support 16 GROM bases (which gives us 480 KB of ROM).

Do only Atari 2600 games count or any type of game? In the case that any type of game counts, here's mine... Gate-Empire (game revolving around Stargate) 13 1/2 hours Dino Run (Online Flash Game) 3 hours Dino eggs (Apple II version, emulated in MESS) 125 minutes Pitfall! (for HSC competition, emuated on Stella) 80 minutes Buck Rogers - Planet of zoom (2600 version, emulated in Stella) 68 minutes Stargate Role playing game (in a forum, in German) 53 minutes Elevator action (Arcade version, emulated in MAME) 42 minutes Popeye (emulated in Stella) 40 minutes Berzerk (Open GL version) 10 minutes Prince of Persia demo (emulated in Stella) 4 minutes Ballblazer demo (emulated in Stella) 1 minute

Ok, my score here is not very good, but I don't want to play any longer... 32716.

No, that's seriously wrong. In fact I don't know of any game that was 36k... but maybe I'm wrong here. Anyway, I know of many games for the TI that were only 8K (for instance the Romox games), and many that were 16K (most of the Atarisoft ones). As for homebrews... well, that depends on what exactly you would consider a "homebrew". If you mean homebrew CARTRIDGES (Command Modules in TI slang), then you may be right. But TI offered some possibilities to program their machine. If you had the console only, you could only program in BASIC (and save your creations on tape, if you had the optional tape adapter). If you bought the minimemory module or the rather pricey expansion box with the 32K expansion, you could also write games in Assembler. And there were several small companies who sold disk-based games for the TI-99. For instance, I have @APESOFT's "Cerberus". Now the question is if you could consider this a homebrew since, of course, you could consider @APESOFT a company... but I'm not sure if it was. If you count games programmed in BASIC or EXTENDED BASIC as homebrews, then I'm sure there are literally thousands or millions of them... I have personally written about 100 programs for the TI-99 in EXTENDED BASIC. And by the way, even professional companies did some "hacks". If you listen to the sounds of Atarisoft's TI-99 version of "Protector" closely, they will strangely remind you of those of TI's own "Tombstone City", whose source code was released on the pack-in disks for their "Editor/Assembler" module, which you needed to write machine language programs for the expanded TI-99.

Yes, it's looking good so far. But some more comments to those screenshots: 1. The blue region below the mountains doesn't have to turn grey when the foot comes down because it can actually be drawn with the background color which then changes to black. So blue = background (stays blue), grey = dino mom's foot (turns grey). 2. Dino mom's foot could actually come in multiple colors. At least the toes could have a different color than the main foot. Since toes and leg are divided by a row of black pixels, this would look pretty realistic... there still is no scanline where the toe and leg regions overlap. 3. The solid wood graphics don't look too much like wood. Look at the C-64 screenshots... the wood is not drawn solidly in the original game, and I think it wouldn't make much of a difference doing it like that as well in the 2600 version. 4. I would do a blank line between the floors and the eggs / rocks. Why? You would need some cycles to reposition the players between those areas in order to display the eggs and wood (or, alternatively, above the floor, but in this case the players wouldn't be able to touch the floor). Then I thought about how much flicker would be involved in the screenshot as you're showing it now. On the upper level, at least two of the objects shown (two stacks of eggs and one wood) would have to flicker 30 Hz because there are only two players to display them. You have the same problem on the second and on the fourth level. The third level could be displayed without a flicker. One little detail would be the spiders and their threads. I'd display the spider threads with missiles and the ball, which unfortunately means that they're changing color depending on where they are. But such is life (and that can be seen on other 2600 games as well, such as Jungle Hunt or Realsports Tennis). Another idea would be to limit the "grid". In the Apple II and C-64 versions, there are 4 horizontal levels, divided into 12 spaces where either eggs, rocks, flowers, wood or ladders could be. If you limit those to 10 for the Atari 2600 version, you could space them apart by 4 playfield pixels which could make things much more convenient. Among other things, you could try to reduce flicker if you have the multiple copies in the same row (such as eggs and wood) to displaying them using multiple copies of a player object. Even multiple, different sized, stacks of eggs could be displayed that way by changing the number of copies of the player on the fly. Might not always work, but sometimes it just might. Oh, and I've created some screenshots of the Apple II version for comparison (since shots of that version can't be found anywhere on the net). Note that in that version, there are actually two regions of mountains... one upper, richly colored, and one lower, only sparsly colored (that's where the spiders are). Food for thought maybe?

OK, some feedback here... 1. OK, some things are missing, most obviously the sound, the scoring and life counter. I won't comment further on that... 2. The game seems to run rather slowly, at least on my PC. If all robots are still there and shooting, it does only 4-5 frames per second, though it does speed up when most of them have been killed. And I don't have a slow PC... I've got an Intel Quadcore 4x2.4 GHz one. 3. You didn't tell us that we need a recent version of CYGWIN1.DLL and GLUT32.DLL for it to run. This also isn't mentioned in the documentation. Speaking of documentation, there's no README file either. But such things (dependencies that are needed which don't come with the download) should be mentioned, in my opinion, so that the user doesn't get confused. 4. There's a probability that you start the game or a new room and immediately get shot by a robot. Maybe the robots should be prevented from shooting for the first 1-2 seconds you're in a room so that the player has a chance to get out of danger.

One console that hasn't been mentioned yet is the Creativison, a console made in Hong Kong which coupled a 6502 CPU with a TMS9928 video chip and a TI sound chip. That console was sold in Austria and Italy, though I don't know if it made it to the USA. Anyway... as far as I know there has no homebrew game been written for it yet. There is some homebrew hardware (a multicart), and I managed to write a graphics and sound demo which also has been put on the multicart, but it isn't a game since it doesn't accept any user input.

Well, for Ms. Pac-Man, I have my own memories how this turned out... The first home version of Mrs. Pac-Man I saw reviewed in a magazine (I think it was back in 1983 here in Austria) actually was the 7800 version. They talked about it as one of the first games for the 7800, and how close it came to the arcade because they used the original programmer from the arcade version (Bally). Of course, as we know today, the 7800 actually wasn't released until much later. Anyway, only after I read that mag article, I saw the 2600 version of Ms. Pac-Man, which wasn't that arcade perfect, but nonetheless was a huge step up to the 2600 version of Pac-Man. And in fact, this holds true for most home versions of Ms. Pac-Man vs. Pac-Man. On the C-64, Pac-Man by Atarisoft (which is only 8K in size) only has mono-colored ghosts (and is generally very close to the Atari 8-bit version of Pac-Man), while Ms. Pac-Man has got multicolored ghosts, an attract mode, all the original mazes and all the intermissions. The same holds true for the Atari 8-bit version of Ms. Pac-Man. On the ZX-Spectrum, the original Pac-Man moves all characters in 8-pixel steps (!), while in Ms. Pac-Man they move smoothly. The only exception seems to be the TI-99, where Pac-Man itself wasn't that bad already, and Ms. Pac-Man seems to be based on it, having the same ghost sprites etc. (just like the Ms. Pac-Man arcade version is based on the original Pac-Man machine), thus not being such a big step up.

OK, here's my best so far... 901.

Well, it all depends on how much flicker you can stand. Obviously, there often are too many objects on each scanline to do without flicker. Another problem is that you can lay down your eggs anywhere, so if there are multiple stacks of eggs on one scanline, you probably need multiple players to display them. Same problem with the wood that can be laid down anywhere. As for Dino mom's foot... on the mockup screenshot the playfield is already asymmetric, so I would just overlay that asymmetric playfield with the foot, if possible. The foot should be 48 pixels wide on the 2600, which corresponds to 12 background pixels. I'd draw the foot with the background graphics and have all other background graphics on those scanlines change color to the color of the foot. Alternatively, you could use two players with quadruple width, but then flickering would be almost unavoidable (not that it would be avoidable if you don't do it like this...). This could be accomodated by a special version of the kernal which doesn't change the foreground colors as it normally would, but instead takes the foot into account when writing to the PF registers. For this application, the foot could be confined to a few positions which don't make too much trouble (i.e. covering a full PF register and half of another one). The foot animation could also be simplified so that the foot raises and lowers a half or a full playfield level at a time. I think it would make sense to divide the playfield in regions, as usual for Atari 2600 games: - sky region with typical Atari 2600 mountainscape and incoming spiders - 4 main regions which are subdivided as follows: - region for high flying objects - region for low flying objects - platform, eggs, wood and rocks - status and scoring region Between each region, as usual, there would be an opportunity to reposition players.