Jump to content

RevEng

Members
  • Content Count

    6,840
  • Joined

  • Last visited

  • Days Won

    10

Posts posted by RevEng


  1. You can assign the same physical key press or physical controller input to multiple a7800 joystick inputs. Start the game up, hit tab, and go to the "console and controller inputs" menu, and assign how you like.

     

    I just tested with Xevious just now, and was able to map the LEFT arrow key to both the 7800 joystick 1 LEFT and fire buttons. Every time I moved left, the ship fired.

    • Thanks 1

  2. The specifics really affect the answer. If it's just dumb buttons, like a track+field or starplex, you can remap the directions in an emulation session. If there's active electronics and/or interpretation of those lines, then someone will need to put together a new slotted controller driver. Less development time if it's like something that already exists and you can copy the driver. (and change whatever needs changing.)


  3. It prepends a dot... not sure why dasm reports "0." in the output though.

     

    7800basic and bB do this to any goto/gosub destination so that "line numbers" will be valid labels. (dasm doesn't accept symbols that begin with digits)

     

    What I do is just give the assembly routine a dot-prepended label, so 7800basic will be happy to go there directly. Actually, usually I just give it two names, so I don't have to bother typing the dot if I go there from assembly too... 

     

      gosub myasmroutine
      rem [stuff]
      
     asm
    .myasmroutine
    myasmroutine
      ; [stuff]
      rts
    end

     

    • Thanks 1

  4. Per character coloring is a bit tricky in 320A, due to the palettes being assigned to a character object, rather than individual characters in the object. (except for 320 artifacting color, of course) 320A per tile coloring is easier, since the character objects for 3x3 tiles is doable DMAwise.

     

    We're experimenting with a few things, but rest assured the 7800 version will be more colorful than it's current PETish incarnation. Some way, some how.

    • Like 11
    • Thanks 1

  5. 6 minutes ago, Shannon said:

    I do have a question though when MAME loads an a.78 file is it possible for it to select options incompatible with the ones listedin a78_carts.h?  Is there a way I can tell which cart "slot" or setting MAME is using when it loads an .a78 file?

    In a78_slot.cpp, the a78_cart_slot_device::call_load member function validates the header bits and sets hardware, so no, there shouldn't be incompatible options being set. 

     

    I'm not really a MAME slot guru, but if you check out a7800.cpp, it uses "m_cart->get_cart_type()" to test which hardware is in the slot.


  6. 5 hours ago, Shannon said:

    Anywho... I've noticed that a7800 will let me select an .a78 file and it will load it just hunky dory.  Which leaves me the impression it reads the header information.  Does the main MAME fork which I know you guys split from support .a78 files?

    Yep. a78 header parsing has been in there well before the MESS->MAME update, let alone the a7800 fork. I've been using stand-alone a78 files exclusively for a very long time, since it suits my CLI dev style.

    • Like 1

  7. The YM capability in a7800 and js7800 are currently designed to emulate the XM, so you need to hit the XM $470 register with $84 to enable the YM. I confirmed that doing that manually in the a7800 debugger enabled your demo to play. Pretty sure js7800 will work once you do the same.

     

    Also, the [email protected] bit in the a78 header is a modifier for supergame format. It's not needed for 48k.

    • Like 1
    • Thanks 1

  8. Well, it still might be a problem. The number of scanlines is hardcoded into Maria, so an NTSC deck won't display all of the lines in a PAL game. When running PAL on NTSC, best case you'll get a cropped screen and a game that runs a bit too fast, worst case the game will crash due to an expected-but-missing interrupt in the cropped portion of the screen.


  9. Now you've done it... thanks to "Gyruss Lemmings" I'm sitting here contemplating a game where your ship shoots lemmings. :dunce: Pick up multiple lemmings, like humanoids in Defender, and splat them at your enemies to defeat them.

     

    Somebody, please make it so. Thx!

    • Haha 4

  10. 7 hours ago, John Stamos Mullet said:

    I mean - most of the graphics are just being displayed in random or cycling order. They aren't tied to any interactive game logic. Someone with enough time on their hands could look into how to write text and graphics to the display for a 7800 and put something similar together. There's a chasm of difference between repeated cycling of the same graphics
     and text, and actually tying that to working game logic that functions smoothly. I'm not trying to say what was produced here was "easy" by any means. But looking at what was done with games like f-18 hornet, and Super Huey, its' not like it was some "wow" technological achievement for the platform either. Just a bummer that it's another abandoned project on an underutilized console.

    By random graphics, I'm assuming you're talking about the cockpit display here. It's best practice to rough-in everything you need to display, to ensure you won't actually blow the dma budget. Actually making the displays do something, even random or cycling, prior to a fleshed out game is a good way to fire-up people's imaginations for show-and-tell. I see a whole lot of "what to do" in your critique choice here.

     

    On your broader point about it not being finished, it's a proto. We all know what that means. As Trebor already highlighted, the only lesson in "what not to do" is not have Jack Tramiel calling the shots on your project, if it requires anything more than base hardware.

    • Like 1

  11. On 9/14/2021 at 11:59 AM, John Stamos Mullet said:

    While it might be neat to investigate how certain functions were performed in the code (if the code exists, I don't know), I would think this might fall under examples of what not to do, since they never really got far enough to make a working beta.

    It's not playable beyond steering the ship, but it works very well to show off the tech proof-of-concept. Spectacularly well, in my estimation. 

     

    What lesson do you think it can teach developers, as far as "what not to do"?

     

    • Like 4

  12. One more wrinkle worth mentioning... RoF uses a half-vertical resolution bitmap (i.e. squarish 160 mode pixels) which cuts down on number of pixels it needs to thrown on the screen. The 7800 doesn't have such a mode, but the on-cart ram has an address line pulled down permanently, so that each odd graphics memory page maps to the prior even page. (aka "mirror ram") Thanks to the way 7800 graphics blocks are laid out, this turns the higher res mode into half-resolution.

    • Like 5

  13. 45 minutes ago, beoran said:

    The MARIA graphics processor is an interesting design, with it's draw lists, but both the NES and the even better Master System had graphics processors that were superior to what the 7800 could muster, in resolution, in colors (certainly the Master System), and in the ability to have a hardware acelerated scrollable tile map with true hardware sprites.

    What's the point of "true hardware sprites" in the NES if they're gimped compared to the 7800? (which isn't exactly soft-sprite either) The 7800 can push over a hundred sprites per frame with no flicker in sight, while the NES tops out at 64 per screen. Each 7800 sprite width can be up to 32 bytes wide, instead of the NES fixed width of 8 pixels wide. Any game object wider than 8 pixels on the NES has to use multiple sprites, which is problematic due to the max of 8 sprites per scanline.

     

    The truth of the matter is, the NES is fantastic with tiles, and weak with sprites. The 7800 is fantastic with sprites, and weak with tiles. A clever programmer can overcome the NES limits by abusing tiles, and a clever programmer can overcome the 7800 limits by abusing sprites.

    • Like 7

  14. Looking at this, it appears that a multi-line statement with end doesn't play nice when it's part of an if...then. It trips up the preprocessor, which prematurely ends the program.

     

    I think this one is just going to be a documented limitation for now. Multi-line statements in a single-line if...then is going to be clumsy anyway, from a syntax perspective. Maybe at some point I'll take a whack at adding a blockif statement.

    • Like 1

  15. The playsfx is one of those inflated statements that cause the if...then logic to trigger an out of range branch. Are there messages elsewhere saying the source wasn't resolvable? 

     

    This particular error you've flagged is actually issued by 7800sign, which gets run post-compilation. It's noting the rom is malformed.


  16. Just a quick update on everybody's favourite and completely uncontroversial topic, the Ethereum 2600 NFT... heading into the weekend I lowered the minimum bid to 0.01 ETH (about $39) because I was worried about being off the price curve entirely. It was a bit of a risk for a couple reasons. First reason being the lowered price reduces impetus to resell, which could end redistribution. Second reason being the fact that I was trying to walk the line between collectable and game with this project, and I didn't have any idea if I was looking at a regular demand curve or Veblen demand curve. For the latter, lowering the price reduces demand.

     

    The auction ended this afternoon without any offers, and then a few seconds later I was sent an offer of 0.18 ETH. I'll be accepting it later tonight. (just waiting for ETH gas fees to come down a bit.)

     

    This update isn't in lieu of that post-mortem I said I'd do; I'm still planning to get that out this coming week, and with some luck there might even be some resale info in it too.

    • Thanks 1
×
×
  • Create New...