Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

370 Excellent

About FifthPlayer

  • Rank

Recent Profile Visitors

5,862 profile views
  1. I remember buying the Happy upgrade for my 1050 that gave it true double density. The Happy was just as significant an upgrade as the 1050 was.
  2. With 16-bit processors came enough linear memory space to offer an operating system with hardware abstractions for graphics and sound. Some of the 16-bit platforms isolated apps from the hardware (Mac) and some allowed the app to choose to use the abstractions or code straight to the metal (Amiga, Atari ST). But all of them provided some way to write an app that could work unchanged with an upgrade to graphics and sound. In contrast, none of the 8-bit platforms (Atari, Apple, C-64) offered the level of software abstraction as the 16-bit machines. You could add a hi-res graphics card to the Apple II for instance, but you had to rewrite the apps to support it. The situation would have been no different with a VBXE chip on a card plugged into a 1090 chassis. If that had existed BITD, only a relatively few apps and games would have supported it.
  3. Disagree. The systems you mention are 16-bit, and they have more sophisticated operating system support for sound and graphics that allows hardware upgrades, while allowing application software to use it without modification. Or else the hardware board came with an applications software suite that made the board a complete, stand-alone solution (e.g. Video Toaster). The Apple II had plenty of support for expansion cards, and there was absolutely no shortage of cards available. You could get sprite cards and synth cards and the vast majority of apps and games didn't use them because of the same dynamics VBXE now faces.
  4. One thing I am curious about: how many people currently have the latest SDX source code, and are active (or semi-active) contributors? drac030 obviously, but who else? I ask because even though SDX is no longer commercially viable, and even if the code cannot be made open to all, it is valuable enough that there should be some line of continuing its development. Witness valuable projects such as TurboBasic XL and RMT. They are now orphans becuase the owner/maintainer passed away without handing it on to a new maintainer or opening the source. I'm definitely not sitting here expecting drac030 to pass away, but I also don't want to see SDX go the same way those other projects did.
  5. Just about every one of the expansions you mentioned - CF cards, serial devices, parallel, memory expansions, even processor upgrades - all enhance existing software. VBXE (and Covox) both need software to be written to support it. Also, VBXE isn't a plug-and-play peripheral like a CF card that goes into the PBI port. It requires a soldering iron and skills to install, which for me (and probably a good number of other people) puts it outside the realm of consideration. I don't necessarily think VBXE is a bad thing, but I understand why it hasn't received the warm reception people hoped for. I do like the idea of a modern recreation of the A8 hardware with integrated VBXE. That could be very interesting and perhaps give the VBXE the respect it deserves.
  6. I think the issue is that the SIO2SD tries to load a patch to the OS at boot, to enable high-speed SIO operation. But the OS patch fails on the 400/800 ROM.
  7. I have a 130XE and it also has the vertical bar issue on modern TVs. I've tried a few scan converters but they don't help and it costs too much money to keep buying different models to try out. I only want one Atari in the house, and if I were to do it over again I would go with a 600XL or 800XL.
  8. There's a bigger issue here as to whether realism is a good thing for a game to strive for. I'm of the opinion that the game would be more fun if it reflected the knobs and dials that an epidemiologist would reasonably have on hand, but doing so runs the risk of turing the game into a dry, boring spreadsheet exercise. For me personally I'd like to see enough attention to reality for the simulation to be plausibly realistic, but still retain the elements that make it a game. Are nuclear weapons part of that? Regardless of what certain world leaders today might or might not do, one could argue in practical terms nuclear weapons aren't really a solution, but a cure that is literally worse than the disease. Still, I do admit that I find this game intriguing.
  9. Personally I'd like to see a more realistic simulation game that has you as an epidemiologist for a fictional WHO-like organization combatting the spread of a virus worldwide. Epidemic! doesn't look terribly realistic from the science point of view (nuclear weapons? shooting down meteors?). A realistic game could be a good teaching tool.
  10. Stuff like sprite flicker because of multiplexing hardware sprites, or soft-sprite character cell cutouts, I have no issue. But one game showed random electronic garbage on the screen when the player went from one screen to the next because the game didn't manage the display list properly. Another had stutters and hiccups in the background music because the author was lazy and disabled the vertical blank interrupt at certain times, which also disabled the music player. These issues were bugs plain and simple. Programming experts here gave the author simple ways to solve these fit-and-finish issues and he refused to do so. And programming glitches like those are still OK if it's a homebrew game you're giving away, but if you're putting it on a cartridge, claiming it's profressionally made, and asking $40 for it, for me that's a non-starter.
  11. My issue with this developer isn't so much their hard-core insistence on cartridge distribution, but that the titles themselves are generally glitchy and unpolished. Display garbage when transitioning between screens, sprites lingering outside screen borders, hiccups in the soundtrack, lackluster graphics on some of the titles. For the asking price you should be getting something that at least in presentation looks professional.
  12. I remember all the early IBM software releases for the then-shiny-new PC were in three-ring binders with punched-hole documentation. I don't think this was just an Atari thing.
  13. Generally the arcade ports were sub-par, but there were some that I enjoyed in their own right, partly because the hardware limitations put a new spin on the gameplay. Defender is one of those games, owing to how the smart-bomb works with the single-button joystick and the overall easier play because there's fewer enemies onscreen. And then there are the games that are pretty faithful to the arcade but have their own unique style on the 2600. Space Invaders, Asteroids, Missile Command, Ms. Pac-Man, and Frogger are a few examples.
  14. Hi, just a friendly reminder that these posts about hardware belong in the main Atari 8-bit forum, rather than the programming forum.
  15. I'm not a big fan of design by committee, and I think rensoup should make the presentation the way he wants. But I do think Jose's mockup looks much nicer than a stark white on black intro. @rensoup and @TIX have deviated from the original in some really brilliant ways that improve on the experience, but in this case the white-on-black design is neither true to the original nor an improvement. I think the argument about flicker is a red herring - it's the white-on-black design that's really lacking in feeling or inspiration. If @rensoup doesn't like the tiled border, I'm sure there's a compromise where the tiles are eliminated but the colorfulness is kept.
  • Create New...