Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by RevEng

  1. Yeah. And there likely won't be a 7800 specific SNAC. The 7800 does some odd things to the controller lines in 7800 mode, when two-button mode is enabled. But single-button games and AtariVox should work just fine in 7800 mode too, with the 2600 SNAC adapter.
  2. It's been a while since I looked at connecting to AtariVox though a serial adapter, but there's a couple things that I believe would need to line up here fo stelladaptor atarivox to work... the serial port device presented to the Linux OS would need to be chosen in the UI (or somehow auto-detected), and it would need to be setup with a particular baud rate and flow control. the 7800 core would then need to pass though the bit-banged joystick port bits to that Linux serial port. I have no idea if either of these are already implemented or not. Doubtlessly SNAC is easier, since the bit-banged joystick port lines are right there on the SNAC adapter, as if it were a real 7800.
  3. A few thoughts... I'd make sure that crashing in your dynamic code is a result of timing, rather than something else. Unless you're completely starved by DMA, you should be able to pump out a fair bit more than a dozen sprite updates (2x DL updates per sprite) within any given frame. Without double-buffering, the dynamic DL generation in 7800basic manages around 24 moving sprite updates. (on a 160A tiled background. Maybe a little more with no background. Definitely much more with double-buffering, but that's another kettle of fish) The thing is, 7800basic has it's DL update running outside of the NMI. (when objects need to updated, I check for a flag that indicates the end of the visible zones has been reached, and wait if it's not yet good.) That architecture is pretty forgiving for missing a frame here and there, since it will never clobber itself due to too many objects being pumped to the screen. Worst case result of taking too long for a frame is you get a mostly duplicated frame with a few sprites missing and one corrupted. Typical case result is you get the duplicated frame, and as long as it doesn't happen too frequently, nobody notices. Hopefully there's something useful in there for you.
  4. You've completely nailed it, Bob. Just like we all expected you would.
  5. Actually, I think this may be more mundane. I didn't notice earlier, but your code appears to be off. You need to test YM2151BASE+1 for chip readiness, but your first check is for YM2151BASE.
  6. Ok, so it doesn't sound like my guess is right. Is it purely a sound quality thing, or are notes actually dropped from the transfer? If you send a note-off very shortly after a note-on on the same channel, you get distortion. I think that's just a quirk of the YM.
  7. It's nothing I've run into before... if this is the only code accessing the YM at the same time (i.e. there isn't access happening on both interrupts and the main code loop) then it would seem to be a timing quirk. Try throwing a single NOP before each BIT test loop. Maybe it takes a few more cycles to chew on the last input before the YM realizes it needs to raise it's busy flag. Something to try anyway. (Adding @tep392 in case he's seen it before)
  8. Yeah, that 7800basic option was just to disable the soft-reset acting as a pause, when pause isn't disabled. It sounds complicated, but basically it means the soft-reset button can start a game (reset when pausing is disabled, as it should be during a title screen), and then act as a pause during a game when pause isn't disabled. I don't actually have a full disable for the soft-switches yet (aside from compiling in a mouse or trackball) but I'll add one in before the next release.
  9. An excerpt from atarimuseum.com (courtesy of the wayback machine)... And another one from Curt, from the forums here...
  10. You're welcome. Not sure why it wasn't disabled... I see the conditions in there. If you're looking to disable this functionality, check std_routines.asm and just search for "soft".
  11. 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.)
  12. Well, the fix has the issue that under some circumstances (dma heavy near the top of the screen) the 0 value will be unattainable. I'm also not sure it's a general problem, instead of some unexpected interaction.
  13. Ah, I see. 220 is a lot, and certainly beyond what I tested. I'm thinking that your paddle scan is getting interrupted by the NMI at the bottom of the screen. Maybe.
  14. 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.
  15. 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.
  16. 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.
  17. Yep, it only uses the CPU time when a paddle is the active control.
  18. 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.
  19. Try changing this... static INPUT_PORTS_START( a7800_joystick ) ...to this... static INPUT_PORTS_START( a7800_minikeyboard )
  20. 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.
  21. 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.
  22. 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.
  23. 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?
  • Create New...