Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by RevEng

  1. The answer is "it depends on how much you're making Maria do". But here's some figures of non-DMA cycles per game frame, for some common games. This is in the midst of action, with a moderate number of game objects moving around. Alien Brigade 13163 Bentley Bear 12024 Choplifter 19660 Commando 16996 DigDug 20401 Food Fight 23198 Froggie 9052 Ms Pac 14871 Popeye 11506 Robotron 26260 Sirius 14971 T:ME Salvo 16970 Bear in mind that a good chunk of that will be updating display lists ("plotting" in 7800basic) so you don't have all of that time available, unless your game isn't plotting objects. But at least it should give you a ballpark idea.
  2. It can go anywhere - inline with your main loop, or within a sub that gets called from the main loop. The main consideration is that it needs to be part of your control handling code, since it allows/denies player movement in a given direction. As such you'd usually run it once per frame.
  3. Nerds often refer to the period symbol as "dot", when it's not being used at the end of a sentence. That would have helped with the search. A label that begins with a dot is limited in scope. i.e. if you use a particular dot label somewhere in a dasm subroutine, you can use the same dot label elsewhere for some other purpose, without a name clash. The reason for the dot label in this particular case is to make it possible to "gosub unrand" directly from bB source code. bB prepends a dot to all of it's labels, which means the basic code "gosub unrand" becomes the assembly code "jsr .unrand". A natural follow-up question might be "why does bB internally add a dot to each label?" The reason bB does that is to support line numbers as labels. Dasm doesn't support symbols that are just numbers, or even those that begin with numbers. So adding the dot to each label was batari's way to turn the line numbers into a label that dasm would accept. (bB doesn't actually use dasm subroutines at all, as far as I recall) The colon is just an optional dasm syntax for labels. Some people use it to make labels more obvious in their assembly source, or because they previously used an assembler that required the colon for labels. I typically don't use it, but I did for some reason here. (and inconsistently too, since .unrand doesn't have one)
  4. It's a 16-bit LFSR. "rand16" holds the upper part of the seed. Try something like... rand=15 rand16=42
  5. Deflemask can import OPM files for it's ym2151 instruments. There's a vgm2opm converter somewhere out there, but you can also just grab the ripped opms instead. A good chunk of all of the games that ever played through a ym2151 is available. The 7800.8bitdev.org wiki OPM Instrument Collection page has a link to the "Mega Arcade Collection" OPM pack, which includes the files for the R-Type games. (and a lot more) To save you the hunting, I've also attached a zip here with just the R-Type OPMs. R-Type_OPM.zip It's also worth mentioning that the x68000 collection on the same wiki page also has the R-Type OPMs used with that platform.
  6. vgm appears to just be a realtime dump of each register hit... it makes sense that you couldn't convert through those formats. I looked at one of the r-type vgm rips. Each song is ~200k. So I don't think it's feasible from a rom perspective to just take vgm on it's own and import. It's the same problem we find with midi files being very rom-expensive, since none of the repetitive bits of the song structure is encoded. [edit...] Hmmm, I think some PCM data was encoded in that one. Other ym2151 rips are about 20k per song, which is still a bit expensive, but at least doable.
  7. RevEng

    HOKEY demo

    I'm late to the party, but this is fantastic news, Fred! It would be best to send the player @mksmith put together for these tunes to Fred in PM, along with your notes on what Pokey settings were used. The M+M demo Fred is using didn't have all the areas, and the player will make it more convenient to check any one song.
  8. It looks like a Windows-specific 7800basic bug, the root of which is Windows both ignoring and gleefully adding capitalisation to file names. The problem is those file names turn into case-sensitive symbols in 7800basic. I've worked around this for the most part, taking the capitalisation desired from the "incgraphic" statement instead of the OS. Unfortunately this doesn't work if the capitalisation inside the tiled file differs from the rest of the usage in the basic file. I'll have to figure out a fix, though it's not quite clear to me what that will look like yet. For now the work-around is to either ensure your incgraphic statement (and other references) matches the OS file name capitalisation, or to open the tmx in a text editor and fix any references inside to match the capitalisation used in your incgraphic statement. (e.g. "Untitled" can be manually changed to "untitled".)
  9. Here's the relevant excerpt from the yellow screen of death section of the manual...
  10. Sure, it's a valid format. The ROM in 32k+ram is the same as plain old 32k format. (i.e. no banking required)
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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)
  17. 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.
  18. 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.
  19. 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.
  20. 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]
  21. 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.)
  22. 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.
  23. 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)
  • Create New...