Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


RevEng last won the day on September 5 2020

RevEng had the most liked content!

Community Reputation

6,301 Excellent

About RevEng

  • Rank
    ​​ 👾 Space Cowboy 👾 ​

Profile Information

  • Gender
  • Location
    ​ 🇨🇦 

Recent Profile Visitors

46,087 profile views
  1. Here's the relevant excerpt from the yellow screen of death section of the manual...
  2. Sure, it's a valid format. The ROM in 32k+ram is the same as plain old 32k format. (i.e. no banking required)
  3. Karl is correct. You can just break out of the inner loop with a goto, as you have here. The outer loop "next" won't get confused with the inner loop one.
  4. Serpentine does indeed support external POKEY. The original A8 game didn't exactly push POKEY's limits, so there's not a huge difference between what you hear when using TIA vs POKEY. With TIA playback, the original music is pitched upwards a bit to avoid sounding sour, and the slithering sound has been modified to be less annoying than it otherwise would be with TIA's coarser volume resolution. If you spent your early years playing Serpentine on A8 you might notice those differences.
  5. Fair point. I guess I let the infamous laughing shoes post, and historic resistance to opening things up to front-ends, incorrectly colour my perception on the general ARM-for-emulation point here.
  6. Nope. I just see someone else's perspective on the matter, and how they might have been led astray, or have a different opinion without the facts. I don't assume bad faith or intent, like you have. For sure "lazy" was insulting, and I didn't defend it. My preference is always debate, discussion, and education, unless someone has historically proven themselves to argue in bad faith. It seems that you don't feel the same, or you've already put me in that latter category. Either way, not much point to further discussion, then. As for questions being "pretty much answered", sorry, but I don't recall OP asking people to stop answering the open questions posed. I do think my replies added to the conversation. Apologies they were too wooden for your taste.
  7. Without seeing the project in question, my guess is it's a non-realtime dumper. i.e. it doesn't keep reading the device, but just dumps it once. The de10 nano doesn't have enough free gpios to connect to the cart pins directly. While this sort of hybrid approach has been explored recently, I get the feeling there's some resistance in putting any emulation onto the ARM, or leveraging it any more than it currently is utilised. (see the public arguments against graphical front-ends, or even the ability to launch a core with rom enabled from command-line) There's also a hurdle in the melody/harmony cart firmware being closed. Even if source was provided openly, the firmware would be twiddling GPIOs for the data and address bus, which isn't how the Mister cores work. Someone would need to implement and maintain a hybrid firmware that did equivalent stuff. Then there's the matter of different ARM memory maps, instructions, and such, which is what threw a big wrench into Unocart support for Melody-arm games. (not sure where that's at right now) IMO Mister FPGA running the melody firmware on the ARM is technically possible, but just very unlikely to happen. It would require someone with access to that firmware source, and an insider knowledge of Melody and MiSTer FPGA development, to also be interested in doing this work. (with the added hurdle that the work may never be part of the main MiSTer distribution) Answers to OP... - Is there a danger for enhanced games, by their nature, to not be preserved or playable? There's no danger in terms of playability, with Stella containing a GPL licensed implementation. One could certainly argue about cycle-accurate preservation here, or hardware-reference preservation, both of which are a big focus of MiSTer. if the principals behind melody have moved on in XX years, will anyone be able to make a melody compatible cart based on publicly documented info? My best guess here is "no". - Is the lack of support in MiSTER and possibly other hardware based approaches for these enhanced games a concern? I doubt those making the enhanced games are concerned with any modern console implementation not running them, so long as the games run on the original hardware. - Is the use of enhanced games lazy and a lazy approach (compared to a Mapper)? I think Kitrinx's choice of calling it "lazy" is unfortunate... the word choice seems to stem from the mistaken idea that an alternate, more period-silicon-correct abstraction could have been made, that could give similar benefits as the ARM enhanced games. That approach was actually tried with DPC+, but the ARM-enhanced game devs found that having the less-abstracted power of a modern cpu (with the 6507 acting as an IO co-processor) to be more alluring than staying period-accurate. It's unsurprising that someone involved in archiving hardware doesn't value, or even intuit, this motivation immediately. - What are the primary reasons for using ARM based enhancements? To create games that aren't possible on the 2600 otherwise.
  8. The quick answer to arbitrary bitmap drawing is to use RAM-backed sprites. Basically you have a series of sprites that cover the screen and point at different segments of RAM, and you have line drawing routines that update that RAM. There isn't an easy way to do this in 7800basic right now. @SmittyB's Plink game uses pretty much this technique for dynamic backgrounds, though it's not doing full-screen bitmaps. (they repeat vertically) That said, I don't think Missile Command actually needs bitmap display, if you just limit the number of angles the missiles can come in at. (The 2600 version doesn't pull off arbitrary angles either, and the missile aspect of the game compares very well to the arcade). Given that approach, you can just draw the missile segments with sprites. (pulling this off quick enough would likely require the Under The Hood technique)
  9. Ah, looking at how the routine runs, I think that's an overlooked case. I'll add a comparison check to the beginning of the routine to cover it. Until the next release, I'd recommend you just add an if...then test for this case to your code.
  10. The new routine should definitely be in there, though it's entirely possible you've run into some other issue. When I get a chance, I'll write up an exhaustive test.
  11. And then the XEGS again, in 1987. Candy in 1979 would have been much better timing for such a console release, market strategywise. I won't comment on the sticks, because people living in Proline houses shouldn't throw rocks. They 8-bits were pricey, but a good chunk of that was ram. A console doesn't need as much ram as a computer does, since the program resides mostly in cart rom, and the Candy console would have no doubt been more streamlined in other ways.
  12. More that that. Atari internally expected the VCS to age out of the market around 1980. The "Candy" project, which later became the Atari 400, was originally planned to be a keyboardless console that was the remedy to that problem. [source]
  13. With AdvII being on the Adventure->Zelda spectrum, that's a nice data point for complexity. It's deceptively easy to put together a quick Zelda-ish demo, but the full game is another beast. I imagine this is where Irata Quest went off the rails. AtariusMaximus quickly put together a 7800 Zelda map traversal demo in pretty short order. (he never planned to take it past a demo). But full-game stuff requires dialog trees, npc behaviours, etc., and all of these needing to be malleable with progress through the game. It's only tenable if you take a well-thought-out data driven approach, with tools being written to support the data generation and encoding. Aside from dev time, I think there are other reasons to consider a design on the Adventure->Zelda spectrum. The shorter play-time commitment and better replayability of Adventure would be worthy design goals. (while trying to maintain some of that richness of the Zelda world.)
  14. While I don't disagree that the 7800 invites all of this complexity, in the past I've advocated for something between Adventure and Zelda. (for both complexity and story). Reason being that Zelda had a dev team of 6. When people say they want a Zelda clone, IMO they really mean something more like the sequels, which had even bigger dev teams. A lone 7800 dev taking on a true-to-form Zelda clone will be metaphorically eating an elephant one bite at a time.
  • Create New...