Jump to content

RevEng

Members
  • Content Count

    6,772
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by RevEng

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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)
  7. 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.
  8. 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.
  9. 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.
  10. 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]
  11. 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.)
  12. 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.
  13. RevEng

    Atarivox 7800

    It's worth mentioning @Nathan Strum's AtariVox audio mixer, for those that are DIY inclined. (as discussed in his About the AtariVox page)
  14. Make sure your .a7800/a7800.ini file has a "hashpath" entry that's pointing at the provided hash directory from the a7800 package.
  15. Yes, that's the question, and there isn't a simple answer here. The 7800 has some signal quirks. e.g. A14+A15 being pulled up, A12+A14+A15 being run through AND gates before hitting the cart port. (introducing differences in timing between these lines and the others) Bus access happens at 1.19Mhz, 1.79Mhz, and 7.16Mhz, depending on what device is involved. Probably more that I'm not considering. Timing with these quirks, even with eprom based carts, has always been a bit hit and miss. I only wanted to add some clarity to the fact this likely isn't a software issue, since Versa is immune. I don't own a DF cart, and nor do I have the tools to do a signal timing analysis.
  16. Just to underline a point here... While getting rid of "BEQ $00" may have provided relief for Popeye from the 7800basic break protection, it's just masking the real problem. The argument byte of an opcode shouldn't be executed as it's own instruction ever, unless the program flow has gone completely off the rails. The fact that 7800basic calls a dead-stop when BRK is executed is meant to alert the programmer to the fact that something very dangerous has happened, and changing the code to remove the "0" opcode argument isn't really a fix, any more than disabling break protection would be. This sort of problem with flow control could either be a bad jump, bankswitch, or whatnot, or it could be a hardware issue. The fact that the problem with Popeye didn't manifest when Versa was used, demonstrates it's a hardware issue in that case. Perhaps it's the same here too, since many people can't reproduce it.
  17. Alternate history. 1977: An enhanced version of the VCS is released. 1979: a jealous George Plimpton convinces the Kremlin it should send a bomb to take out the Sunnyvale HQ. Ferris Bueller tries to stop the Kremlin computer from sending the bomb by playing 3D Tic-Tac-Toe with it, but he loses, and the bomb launches anyway. Luckily Nolan and the employees are all out back in the hot tub when the bomb hits, and are unscathed, except for some soot-covered faces and smouldering hair. With the building destroyed, George Plimpton convinces the bank manager to foreclose on Atari's mortgage, but at the last minute Nolan manages to sell the rights to the name "Atari" to some french company. Cut to Nolan, the employees, and Ferris Bueller all triumphantly dancing outside the rubble, and George Plimpton sulking away. If anybody reading is wanting to option the rights, I currently have several bidders, so come in with your best and final.
  18. + YM2151 + High Score Cart + Covox + xegs keyboard Plus the ability to play the Rescue on Fractalus demo without every other line messed up.
  19. Sure. But using the same display (hdmi TV) and the same controller that I was using on retroarch for RPi and Android, to me the latency difference is night and day. On those systems I wasn't able to play Caverns of Mars (A8) with any level of skill approaching what I used to have. I had written it off as just getting old, until I fired it up in MiSTer and played like my old self. Then the same experience repeated itself over and over with a number of games. But honestly, if you're happy with software emulation, for sure stick with it - to each his own, and I'm the last person to be slagging software based emulation.
  20. From the perspective of latency, it's night and day.
  21. As far as "ok", the de10 nano is warrantied up to 100 degrees celsius, and shouldn't exceed that during normal operation, so you're unlikely to break things any time soon running this way. However silicon longevity is always inversely related to the temp you're running at over the lifetime of the device, and I don't think we have the data for a specific answer here. i.e. I don't think we know the mean time before failure rate with any mode of cooling, let alone MTBF rates for different cooling scenarios. There are certain cores that are known to be less stable on some systems, and active cooling seems to improve the situation. This mainly seems to be the SNES and ao486 cores, from what I read. Being much simpler, the 7800 core shouldn't have the same problems. I could be entirely wrong here, but I also get a feeling these cores with thermal instability issues may be due to race conditions being won differently, after a temperature differential shows up between different parts of the fpga. I wouldn't expect problems with the 7800 core on this count either.
  22. I think the question can be equally framed as "why didn't the CC2 respond to $800-$FFF after warm-up?" on your first unit. Best guess is it's along the lines of @tep392's versa problem, with timing of some signal on the device being near some edge case. The warm-up seems to push the unit into not-working side of the edge case.
  23. You're welcome. I found an old doc (attached) that clears up the mystery a bit too. We likely gave it some impossible settings, which messed up the menu. Odd the messed-up menu didn't persist, as this is battery backed ram, but maybe it detects bad settings and re-inits for the next run. Or maybe Bob's battery isn't doing the job. CC2-techdocs.txt
  24. It's only tested in emulation so far, but give this a shot and let me know. Robotron 2084 (PAL HACK).a78 It's a (fairly involved) hex-edit hack that fixes the display to run on PAL, so no speed tweaks. (I don't know if speed tweaks are even possible.) Technical details ahead... The display and NMI for this game is a bit unconventional. There are mulitple NMI, and the NMI that's supposed to run at the bottom of the screen looks to see if a vblank transition happens soon, to ensure it actually is running at the bottom of the screen. If that transition doesn't come, it assumes the NMI order is off, and shifts the order. But if the vblank transition is never seen in any of the NMI positions, the shifting never ends. Due to this NMI scheme, this PAL hack hangs on NTSC consoles, for the same reason the NTSC retail release hangs on PAL. (no vblank transition near the NMIs)
  25. Pretty sure that from the cart's perspective, A12 being forced low (via U4) made access to $1800-$1FFF look like access to $800-$FFF. The CC2 likely has an undocumented mapping or hotspot in that range. Avoiding $1800-$1FFF seems to have done the trick.
×
×
  • Create New...