Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by RevEng

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




    It's also worth mentioning that the x68000 collection on the same wiki page also has the R-Type OPMs used with that platform.


    • Like 5
    • Thanks 1

  2. 22 hours ago, Synthpopalooza said:

    Tagging in @RevEng here:


    I have had zero luck in nailing down a .vgm --> .mid --> .dfm process.  :( how feasible would it be to import .vgm directly and have it play on the 7800?

    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.




    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.


  3. I'm late to the party, but this is fantastic news, Fred!


    6 hours ago, Synthpopalooza said:

    No special SKCTL settings.


    From memory, here's what's being used:



    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.

    • Like 2

  4. 31 minutes ago, Harry Potter said:

    The problem I'm having is not with the emulator but with the console being emulated.  I don't like the graphics and sound.

    A genuine thanks to everybody who responded in this thread, trying to help me out. I have it working now.

    [leaves without casting aspersions on people's choice of hobby platform]


    • Like 3
    • Haha 2

  5. 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".)

    • Like 1

  6. Here's the relevant excerpt from the yellow screen of death section of the manual...


    You've somehow managed to begin executing data, rather than program code. This can happen if you return from a routine you didn't gosub to, or if you trigger bankswitching accidentally by writing to the bankswitch hotspot. It's possible to turn off this protection with the set breakprotect off statement, but you should figure out the reason the protection was tripped in the first place.


    • Like 1
    • Thanks 1

  7. 9 hours ago, fultonbot said:

    for i = 0 to num_shots

         for j= 0 to num_enemies

              if j collides with I then goto break_inner_loop




    With nested loops, will the next after the jump label affect the inner loop or the outer loop if I jump out of the inner loop?

    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.

    • Like 3

  8. 3 hours ago, Trebor said:

    Serpentine, on the other hand, I do not believe has ever been released on cartridge with a POKEY chip, but does support POKEY sound if such a chip is present... @RevEng would know best though.

    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.


    • Like 4

  9. 1 hour ago, Jstick said:

    This is not necessarily true; if you check the link in the first post of the thread you referenced, you'll find it was in fact Sorgelig himself who made the initial suggestion to combine ARM emulation with the FPGA:


    "I want to bring attention to one interesting thing which can be achieved on MiSTer. It's hybrid emulation. It's where both emulation worlds can meet each other."

    Fair point. :thumbsup: 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.


  10. 3 hours ago, orange808 said:

    Sorry, RevEng, but:  All those questions were pretty much answered.  I feel like your post was composed entirely as a vessel for damage control on your friend's behalf.  The answered questions feel like filler to me; designed to sandwich a carefully worded statement to contain the discussion.  It's wooden and it's calculated.

    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.



    • Like 4

  11. 3 hours ago, hizzy said:

    Someone attached a card reader to a Mister. That would work with ARM games, no?

    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.


    17 hours ago, MrMaddog said:

    Forgive me if this sounds naive to experts but doesn't the DC-10 Nano that MISTer runs on have an ARM processor to run the game's ARM based code?

    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.


    • Like 1
    • Confused 1

  12. 3 hours ago, fultonbot said:

    Can you see any way to "draw" on the screen effectively with Maria by manipulating the bitmap drawing?  
    Like how would one approach drawing the missiles in Missile Command? 

    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)

  13. 1 hour ago, Bradsco said:

    I think it might be. The case I've found is when the dividend is less than the divisor, the result is always zero. 

    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.

  14. 1 hour ago, kisrael said:

    Roughly that's what the 5200 was, landing in 1982 right? Pity about the joysticks. 

    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.


    1 hour ago, kisrael said:

    (Atari 8-bits are so impressive. (and the whole culture, like with the Atari Program Exchange). But I think they were pricey when they came out? Like Atari and Apple had these amazing systems, and C=64 came out a bit later, cheaper but more tuned for playing games, and then they were all competitors.. Sometimes I feel bad hopping to the C64 for the games when Atari had been a much better development machine)

    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.


  15. 21 minutes ago, kisrael said:

    Heh, yeah, I've been thinking about Random Terrain's saving of the "hula hoop" ad.


    I don't think it means quite as much as RT takes from it ... I mean, if that were true in that way, why release the 5200?

    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]

    • Like 3

  16. 2 hours ago, Cafeman said:

    1. Thank you for sharing the interesting Zelda dev-team statistics chart!  

    2. A lone 7800 programmer could not do a Zelda-style game/clone, true.   Even with Adventure II, a 32K game on 5200 hardware, we had 3 people contributing. I was the main programmer, but also I needed Raccoon Lad as the artist or else the game would not have been done. He used Calamari's Antic4 utility to make the character sets and then most of the actual screens.  He also designed the sprites and moving BG images and their animation.    It would have taken me forever to attempt that, I'm not an artist.   Then I had to do the coding work of compressing the BG Antic 4 screens, converting all the sprites and animation into ASM/hex bytes and tables, in addition to coding the actual game engine and routines. And it took years of part-time work.   



    EDIT - actually, John Swiderski had a Zelda-ish 5200 game demo he shared (Irata Quest?) years back. It functioned and looked all right. I wonder if he did that all himself, how long it took him, and why he bailed on it eventually. 

    With AdvII being on the Adventure->Zelda spectrum, that's a nice data point for complexity. :thumbsup:


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

    • Like 2

  17. 21 hours ago, Cafeman said:

    I imagine a 7800 Adventure 3 (not including PMP's idea) as basically a clone of NES Legend of Zelda. Inventory, health, enemies to battle, multiple weapons to use.  

    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.

    • Like 8

  18. 12 hours ago, -^CrossBow^- said:

    But a hardware issue where? The 7800? The DF cart? That is what we are trying to figure out. The fact that @john_q_atari has this happening to some degree on 3 different 7800s that he has in his possession would indicate it isn't the 7800 as it is unlikely that he would own three of them with the same hardware error right?

    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.


    • Thanks 1

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


    • Like 1
    • Thanks 1
  • Create New...