Jump to content

Kurt_Woloch

Members
  • Content Count

    1,781
  • Joined

  • Last visited

Posts posted by Kurt_Woloch


  1. OK, since you do list coin-ops... I noticed that my "Dino eggs" on an emulated Apple II in the first week wasn't listed, although it was over 2 hours, and 2 hours was the cut-off for that week. And later on, you did list C-64 games. I think the Apple II is about as old as the C-64, if not older, so that game should be listed too. And according to Wikipedia, that game was already released in 1983, so it also qualifies for "7800 or earlier"... and the 7800 actually was released much later.


  2. My games for this week are...

     

    Food fight (Arcade, emulated in MAME)... 235 minutes

    Space Invaders Deluxe (Hack) (2600)... 13 minutes

    Fast food (2600)... 7 minutes

    Sky diver (2600)... 6 minutes

    Carnival 8k (Hack) (2600)... 5 minutes

    Ballblazer demo (2600)... 2 minutes

     

    Total classic gaming time... 268 minutes (38 minutes per day)


  3. OK, here are my games for this week...

     

    Wing war (2600)... 249 minutes

    Burger time (Aquarius)... 144 minutes

    Pac Man 4K (2600)... 15 minutes

    Pac Man Arcade (2600)... 7 minutes

    Fatal run (2600)... 5 minutes

    Ballblazer demo (2600)... 2 minutes

     

    (all 2600 games emulated in Stella, Aquarius emulated in Virtual Aquarius)

     

    Total classic gaming time: 422 minutes (60 minutes per day)


  4. OK. I tested it again, and the energizer positions are fine now. I just noticed something else... the interruption, along with the sound when you eat a ghost seems to be shorter than in the arcade. The sound playing while this delay is taking place also doesn't go up far enough. So I'd suggest lengthening the delay and stopping the sound at a higher note while not changing the rate it's going up by each frame. I don't know if that's possible or if it maybe interferes with the sound of the fruit being eaten, since right now both sounds seem to be the same. So this suggestion maybe only works in the 8K version... but maybe it would be possible to lengthen only the delay, without lengthening the sound? However, if you have the delay set up to simply wait for the end of the sound, if probably won't work this way...


  5. I just tried this version, and it occured to me that at least 2 of the energizers are in the wrong places. In my opinion the energizers need to be 1 pill lower than they are currently in order to approximate their arrangement in the arcade. I know that for the upper energizers it's a tough call since in the arcade they actually are in the middle of the three pills between the upper row and the row below it, but I'd go with the 5200 version here, which has the energizer in the lower of the 2 positions between those rows, not in the upper one.


  6. OK, here's my best so far... 3955.

     

    Actually, there a quite a few things about this game which the manual doesn't say... so I'll give some tips although they are far from complete since I didn't get very far in this game either... post-8393-1227890723_thumb.png

     

    First, you start out in an empty screen, which is your den. The only exit at that time is to the right, which gets you to the first fire screen. Shoot the enemy and pick up the crystal before it disappears. Then fly back to the den and sit down on the ground near the middle of the screen. This will lay down the crystal you collected. You can only carry one crystal at a time, and the color you have indicates which crystal you're carrying (brown for fire, blue for water, white for air and green for nothing).

     

    Now it gets a bit more tricky: The way from the den to the first fire screen is the only one that can be passed at any time. For all other passages to other screens, you need certain prerequisites. For instance, below the first fire screen is the first water screen, but at first you only can get there if you are brown (however, this changes later). Also, touching an enemy robs you of the crystal you're currently carrying, turning you green.

     

    So, the next crystal you should bring home is an air crystal (since fire and water cancel out each other unless they're separated by air). You'll find the first air screen to the left of the first water screen, but be careful not to collide with an enemy on the water screen since the passage from the water screen to the air screen is also closed if you are green, and you'll have to collect a water crystal in order to re-open it. So get that white crystal and return to the den. Then return to the water screen and get the water crystal. Be careful, if it falls on the ground and you stay there for too long, you'll lose some hitpoints!

     

    Once you've brought back the water crystal to the den, after a few moments a super crystal will be forming.

     

    From that point on, you have double the range for shooting. Also, you gain quite a few hit points at that point. But the game also gets trickier, since from that point on, you'll lose whatever you're carrying as soon as you touch the background! So you have to fly carefully.

     

    As you get out of the den again, you'll notice that there are no enemies left in the screens you were before. However, some more passages are now open. First, the passages to the screens you previously were on are now also open if you are green. Then from the first air screen, you can reach a second air screen to the left and a second fire screen to the top of it, which do contain enemies. Going right from the second fire screen takes you to a second water screen, but you cannot escape that one if you are green. You can escape it, however, if you are blue.

     

    Bringing things back to the den also gets much more tricky since touching the background, including the growing and shrinking crystals in the den, robs you of the things you're carrying (and in the den collisions also eat away your hitpoints), so you have to outmaneouver those crystals in order to bring your belongings home safely. And, nastily, as soon as you carry a crystal, the screens on your way back to the den are filled with enemies again.

     

    And now for the display at the bottom (which also doesn't get described in the manual):

    The upper part alternates between showing your score (in 6 digits) and 4 numbers in different colors. These numbers are the number of crystals of the different type (water, air, fire and super) you've already brought home to the den. Below that are a brown and a blue bar. The brown bar shows roughly how many shots you have left, and the blue bar shows how many hitpoints you still have. The number of hitpoints increases when you create a super crystal at the den. The number of shots also increases every time you bring home a crystal.

     

    I have partly figured out how the scoring works. Each enemy shot is worth 1 point multiplied by a score multiplier. If you pick up a crystal, it's worth 2 points multiplied by the same multiplier.

    That multiplier seems to work as follows: score * A * B, where A is the sum of the 4 numbers shown below (thus, the total of the crystals brought home including the super crystal that forms when you've brought home the other three), and B is (1 + number of super crystals created). At least this seems to hold through for the first two "rounds" (considering a round to end with each super crystal created).

    In the first round, I got 100 points for each crystal brought home and another 200 when the super crystal formed. In the 2nd round, however, I got 400 points for each crystal brought home.


  7. So, any news on this? Sorry to bring this up after nearly 3 years, but I just found this thread and didn't know previously about the menu system of the FB2.

    What I'd really be curious about is if it would be possible to write games in Gizmode. I know, that's sort of defeating the point that the FB2 should be essentially a repackaged Atari 2600, but I'm always interested what various systems really could do if tweaked in the right way.

     

    From the looks of the title screen, I suppose Gizmode simply lays out the Atari 2600's capabilities over a full bitmap which gets fetched from somewhere (probably RAM, but maybe not) line-by-line automatically like in other graphics chips. In the worst case we probably have a 160 wide x 192 high resolution bitmap in 4 colors per scanline, but no sprites / players overlayed over that. This would give us graphics capabilities that are roughly comparable to the 5200 (at least one graphics mode of it) without the players in it. Still I suppose some games would be possible, like those that primarily used software sprites for displaying their characters and didn't use more than 4 colors (at least per scanline). Examples for these would be Karateka, Donkey Kong (Atari 8-bit version) or Drol.

     

    We are still utilizing this within FB2 and derivitives for 06' So right now, I'm not preparing to release that info until Atari officially says they are no longer interested in marketing the FB2 platform. Gizmo and its design is mine and Atari doesn't have control over it, but I have a contractual obligation to support the FB2 platform as whole until they do not wish to market it any further, I will then at that time consider releasing its technical details.

     

    Not really...

     

    Well, not without totally understanding how the ROM is setup and how to code "Gizmo"

     

    Gizmo is actually a chip within a chip, well really a mode within the "Michele" 2600 chip.

     

    When the 2600 chip is powered up, its actually in "GIZMODE" which means the 2600 is not active, but Gizmo is, and Gizmo handles and menu'ing and bankswitching of the games into the 2600 mode of the chip.    So you'd need to understand and know how to code in GizCode to alter the menu, add more games and have them bank into memory, then switch to 2600 mode, release the latch and the code loads up into the 2600 as if a cart were plugged in.

     

     

    Curt

     

     

    Curt, it sounds like you are surprised that it took someone that long to ask that question! Interesting answer, as I was curious as to how you interfaced the menuing system to the 2600 code. Did the FB2 team develop GizCode themselves? Is GizCode open source?


  8. OK, here are my games for this week...

     

    Gremlins (C-64)... 191 minutes (95 emulated in VICE, 96 on the original C-64)

    Vanguard (2600, emulated in Stella)... 55 minutes

    Park Patrol (ZX-Spectrum, emulated in MESS)... 49 minutes

    Lock'n'Chase (2600, emulated in Stella).... 42 minutes

    Tortue (VG-5000, emulated in DCVG5K)... 33 minutes

    BigBaps (ZX-Spectrum, emulated in MESS)... 28 minutes

    Glouton (VG-5000, emulated in DCVG5K)... 8 minutes

    Star roc (VG-5000, emulated in DCVG5K)... 5 minutes

     

    Total gaming time: 411 minutes (59 minutes per day)


  9. Dan Boris has at least cartridge pinouts for the microvision.

     

    No idea what you're supposed to do with the LCD lines exactly, tho.

     

    http://www.atarihq.com/danb/Microvision.shtml

     

    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


  10. 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.


  11. Doesn't make sense. Even *if* 2600 DK had all four levels, or even 3 levels like the CV version, the CV still *LOOKED* much better.

     

    Like someone else mentioned, the 2600 had the largest fan base and market share at the time, you'd be insane to sabotage your own product to make it look worse when it *already did.

     

    Does AtariSoft get criticized for their ports for other systems?

     

    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.


  12. 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.


  13. 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.


  14. Please refer this picture about text and sprite screen:

    http://www1.interq.or.jp/~t-takeda/scv/scv_screen.png

     

    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.

     

    Sorry I have not dumped Pole Position ][ yet.

     

    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)?


  15. 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...


  16. 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).

     

    hey man. ok i found somestuff here, I also just picked one uo at the flea market for 5 bucks on e game all the wires and the original controllers.

     

    http://www.old-computers.com/museum/comput...?st=1&c=236

×
×
  • Create New...