Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by RevEng

  1. Pretty sure you're triggering the 7800basic soft-reset/pause code. 7800basic implements these via impossible joystick directions. This code is disabled compile-time if the game uses a 7800basic controller driver that can generate these directions.


    It looks like I need to update the manual with this. (I've posted about it a few times in the forums, including the 7800basic thread.)

  2. There's a bit of jitter inherent in paddle controllers, since they work in a polling loop that competes for 6502 time with Maria's DMA. I do some position smoothing, which works wonders, but if you have heavy/irregular DMA in a particular zone you may still get jitter at certain positions.


    I think in your case the heavy/irregular zone in question happened to line up with the paddle position near the extreme, and rearranging the timer setting location basically moved the jitter spot to somewhere less noticeable.

  3. 3 hours ago, PacManPlus said:

    I know, kind of a rookie mistake; you'd never know that I've been doing this for almost 20 years now. 😡

    Each game is a new problem landscape, and iteration of the approach is going to happen as you learn the terrain. This is doubly true for arcade conversions, where you're striving to match the arcade experience on dissimilar hardware, and usually starting with a naive barebones test to ensure the display will work as intended.


    If you didn't make bad turns in your designs, it would mean you're doing the same kind of game over and over again.


    • Like 5
    • Thanks 1

  4. 14 hours ago, -^CrossBow^- said:

    My only question is if the Atari can recognize more than one keypad press at a time. My guess it that it can't or it might do weird things when you do so. That being the case, it would make movement difficult since you wouldn't be able to press but one button at a time.

    You can press any two buttons held simultaneously, without a decoding problem at the console end. There's a ghosting issue that can occur with 3 buttons being held at once, depending on the buttons, but that shouldn't be a problem here.

    • Like 2

  5. For sure. The 7800basic github would be a good place to start...


    The hiscore.asm file has the upper level hi-score table load/save. The link will bring you directly to the bits you're probably most interested in. The code earlier in the file is involved in the hiscore display and controls.

    The 7800vox.asm has some convenience functions. (reading a series of bytes, writing a series of bytes to the vox, and detecting a vox)

    i2c7800.inc is the low-level avox serial eeprom driver written by Alex Herbert, and minimally tweaked by me.


    Instead of using regular atarivox eeproms per-game allocations, the driver uses a chunk of memory that Al put aside for the 7800, so we can use it like an HSC. i.e. the driver will search that chunk of memory for the game's ID+difficulty when loading/saving.

    • Like 5

  6. The driver is mostly in the slotted device, like the one you copied - e.g. the a7800_joy_r() routine controls what gets returned on a joystick port read, but the joystick one you picked as a basis is pretty mundane, so it's not very instructive. Have a look at a7800_joy_r() in the trackball driver, or something else that gets a bit more involved.

    • Thanks 1

  7. 18 hours ago, PacManPlus said:

    Does anyone have any ideas?

    You can do it 2600 kernel style. Create 2 or 4 vertical line sprites in the radar DL, and as you go through each scanline in the radar, change the object X to enable+relocate or disable the sprite. This will require some pre-calculation in non-kernel time, saving the X for each dot ahead of time, so you'll need 120 bytes for a 4 dots per row radar, or 60 bytes for 2 dots per row radar. If you need to skimp even more, you can put dots on every other line.


    • Thanks 1

  8. Ghosting is the term used when simultaneous key-presses aren't registered correctly. e.g. if button 1 is pressed and activates left+up, and button 2 is simultaneously pressed and activates right+up, it will be interpreted as an entirely different button that's represented by left+up+right.


    The atari keypads use a different scheme, with the keypad rows being detected by the joystick directions, and the columns being selected by paddle lines. This is closer to regular keyboard wiring, and less prone to ghosting.



    • Like 2

  9. 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?

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

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

  12. 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]
      ; [stuff]


    • Thanks 1

  13. 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 10
    • Thanks 1

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

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

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

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

  • Create New...