Jump to content

RevEng

Members
  • Content Count

    6,841
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by RevEng

  1. Ah, now I get what you're saying... no, 32 unique inputs isn't possible with that method, since you need to stick to the original actions for the mapping. So you'd need a custom controller driver for that. In your proposed controller, you'd get ghosting from simultaneous button presses. I take it that's not a problem for your planned use-case?
  2. 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.
  3. 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.)
  4. 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
  5. Asked and answered at the 7800basic github. @peteym5 needs to actually use the trackball anywhere his code, and the issue will go away. The trackball generates illegal joystick directions, which interferes with the soft-pause/reset functionality. Using the trackball will disable the soft-pause/reset.
  6. 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.
  7. For sure Matt and I will support a few schemes here, since I'm positive picking any specific solution will make some group of people unhappy. It sounds like joystick+keypad will need to be one, and twin sticks will likely be another.
  8. JS7800 is working for me, here. Must be a browser issue. Nice music!
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Now you've done it... thanks to "Gyruss Lemmings" I'm sitting here contemplating a game where your ship shoots lemmings. Pick up multiple lemmings, like humanoids in Defender, and splat them at your enemies to defeat them. Somebody, please make it so. Thx!
  14. Most of the time it's ready the first time you check, so probably not a lot.
  15. Literally stunned right now, reading this news. Kurt was skilful to the point of being a legend, and more importantly he was a genuinely nice, helpful, ego-free guy. He will be missed.
  16. 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.
  17. 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"?
  18. Thanks for the contribution - It's been merged into master. There's a few other issues I'm working on, after which I'll put out a binary release.
  19. 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.
  20. 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.
  21. Oops. I misunderstood the initial report, and took it as sfx data in the if...then. Since the list output was interrupted, I didn't get clued in. Thanks for clarifying. Back to the drawing board.
  22. 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.
  23. Ok, can you send me the list file from a broken compile in PM? That might help me track down why dasm didn't report choking on the assembly, despite the fact it only created a malformed 8k rom.
  24. 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.
×
×
  • Create New...