Bobo Cujo

@Mr Robot As for Joy2B ergonomics, I'm happy to report that it wasn't anywhere near as bad as I originally thought they'd be: My right pinky works surprisingly well for triggering Button 2. ...even in games where Button 2 is used extensively (Dreadnaught Factor, Hawkquest, Conan, Moon Patrol Redux, ...) Even reaching around for button 2 with my left index finger isn't that bad - the joystick shaft cover is helpful here. I have a leaf-switch-based original Competition Pro (which I hate), and despite resembling it, the ArcadeR is clearly superior in button accessibility/responsiveness/joystick feel/etc. The biggest issue with 2-buttoning an ArcadeR, oddly enough, is actually the quality of the Sanwa clone buttons - they don't like being pressed on the edges, and sometimes they don't quite press cleanly. I'd imagine that real Sanwa buttons (known for their high sensitivity) would do wonders to fix this, however - has anyone tried this, and if so, how hard is it to remove the existing buttons without breaking anything?

I ended up getting an ArcadeR after all (it took about 30 days + order processing time from China, for those wondering). Here's a picture of my Joy2B mod (with the newer 1.5c board revision). It turns out there's easier (larger) solder points that can be used instead of the really tiny wires on the ribbon cable plug: Essentially, it's taking advantage of the through-hole points for the Button 2/Button 3 selector switch (which directly connect to pins 5/9), as well as the C64/Atari jumper (which directly connects to Pin 7). I'd imagine this also works on the 1.5b board revision, for the same reason...

The 64-bit drivers on the Atarimax forum for Vista/Win7 should work on Windows 10 too: https://atarimax.com/flashcart/forum/viewtopic.php?f=5&t=889 I'm pretty sure that's what I use on my Win10 system...

The UAV has a trim pot specifically for modifying the artifact color value - I have one in my 800XL and I purposely set it to Orange/Blue. (There's a test program somewhere in the forums (uav.xex) for calibrating this...)

From looking a bit closer at the NES controller schematic and briefly skimming through the Adrian's Digital Basement video, it looks like the hack simply bypasses the shift register chip and effectively wires the joystick port pins directly to the switches. For Joy2B (schematic here, courtesy of @ascrnet and @mrrobot), you'd do a similar approach, but with a twist because you now need to tie the extra buttons into what would normally be the paddle lines: Wire Atari pin 7 to what would normally be +5V (we need this for the pull-up resistors. It's safe to still have it going to the shift register chip since it's no longer an integral part of our circuit anyway) A button (button 2): Wire Atari Pin 9 to the point where the switch connects to the shift register chip Start button (button 3): Wire Atari Pin 5 to the point where the switch connects to the shift register chip Swap the 1kohm resistors that are connected to the the A/Start button lines with 330 ohm resistors Remove or disconnect all the resistors on the other 6 buttons - unlike the Adrian hack, we're sending 5v to the pull-up resistors, and we don't want or need those on the up/down/left/right/fire inputs. (Big disclaimer: I haven't tried/doublechecked any of this myself; this is all off the top of my head...)

IMO, if you're going to hack an NES pad, you should go the Joy2B route, seeing as NES controller circuitry inherently requires a more involved hardware hack anyway. (Recommended mapping: B as button 1, C as button 2, Start as button 3) Many of the Joy2B hacks eliminate the need for Button 2 as Up - in some cases, they're better as Up still can climb ladders (or perform other functions) while Button 2 handles jumping. Button 2 as Up also doesn't help for games where up doesn't jump (think "bomb button")... As an extra bonus, the 2600 folks have a similar set of 2 button modified games/homebrews that use the same hardware standard ?

I use Sega Genesis 3-button controllers with no ill effects - as a bonus, Button C works as the second button for most Joy2B games* right out of the box. Reportedly, 6-button controllers may cause some issues - the adaptor that @manterola mentioned above (by @Eyvind Bernhardsen) is meant to address that, and also provide Button 3 support for 3-button Joy2B+ games. * the vast majority of these are 2 button games

I don't think it's a bad idea to have the ICSP header - imagine flashing different versions of the firmware if someone wants a different button layout... Also - if this is to be mounted in a (3d-printed?) case, would it be advisable to expand the PCB to include some screw holes for mounting? Or would such a case simply be a snap-fit held in place by the DB9 sockets? (I have no specific preference here; I'm mostly asking out of curiosity)

I think you meant to thank @manterola on this one ?

Ah, alas; I was hoping the other button was a bit more reachable. It may be worth trying the sideways approach for tabletop-only purposes, though... @Mr Robot By any strange chance, I don't suppose you'd happen to know where the ArcadeR joystick maker sourced those 9-wire joystick cords? They look quite sturdy and properly shaped, with thick cords, a properly shaped plug (no screw brackets), and a stress relief that can be fitted into a plastic joystick case - I'd be interested in getting a few to Joy2B-ize my Wico Command Control and Quickshot joysticks, since they look like good drop-in replacements that'll fit neatly into the existing cases... (and no, those "atari joystick extender cables" available on various parts on the internet don't seem like a good option, per this thread... even if they were, it'd be nice to have ones with stress reliefs built in)

This looks like a really elegant solution for using Sega controllers without having to permanently modify them. I may just have to try this with my 3-button Genesis controllers (which do work out of the box for 2 button mode, but not for 3 button mode). @Eyvind Bernhardsen Out of curiosity, where did you source the DB9 joystick connectors with built-in ribbon cable/header?

@Mr Robot As awesome as this joystick looks, I'm concerned about ergonomics of the two buttons. 1) For your own use, do you set up the buttons on the top, or the buttons on the right? (buttons on top corresponds more easily to Joy2B mappings, but buttons on the right presumably doesn't require an awkward claw grip around the stick?) 2) How did you end up mapping the buttons? 3) Is it feasible at all to swap out the autofire latches for a regular button (same size) that could then be hooked up to any of the button headers? 4) Is the joystick's manufacturer considering adding native Joy2B+ support for a future board revision? (All of the Joy2B mods I made assumed button 2 would be on the right, or at least triggered with the finger to the right - this is particularly important for jump + fire actions)

I haven't had a chance to dive as deeply into this as I originally wanted (and I too got distracted with a new project), but a few thoughts: It may be a bit harder to tweak the underlying game logic than I originally thought... Some months ago (after my last post) I did try to double the speed of the bombs to increase the player's ability to quickly take out multiple ground targets. While I was able to do that, it turns out that the animation for blowing up buildings is dependent on being able to finish before the next bomb lands - otherwise, the second (quickly fired) bomb interrupts the previous animation and apparently corrupts the state of the logic for actually destroying the buildings, resulting in half-blown up buildings and subsequent bombs not actually destroying buildings ? It may be possible to more safely double the speed of the player shots, but that also entails doubling the height of the shots themselves to ensure that collisions aren't missed - I haven't tried this yet. It's getting a bit difficult to keep track of further hacks, even with @playsoft's project files above, since it still requires doing manual patches in the original disk images. I was hoping to try to assemble @kiwilove's aforementioned source code disk images into something that could build in MADS (with @playsoft's changes integrated, of course) so that it'd be easier to modify and more maintainable. To that end, does anyone know of a utility that can batch-extract files from an ATR and auto-convert them from ATASCII to ASCII? (ATR Tools can convert and extract files, but it has to be done manually on a file by file basis ? ) @TIX I could try to put in those sprites, but I kind of want to see how far the balance tweaks can go first - one particular thing I noticed is that as nice as the chopper looks, its wide sprite causes it to be a wide target for getting hit, since that's dependent on P/M collisions. Ideally, we'd add some additional software collision checks to see if the object in question collided with just the frame of the chopper, but that might be a little more difficult to integrate - another reason it'd be nice to have a full source-level project to work with ?

@shanti77 It turns out you already support them. ? Unmodified Genesis/MegaDrive/Master System controllers effectively pull Pin 9 low, causing POT0 (not POT1) to return $E4 if the button is pressed. Your game already does that, from what I can tell: 95D5: 8D 0B D2 STA POTGO ;-------------------------------------------------- 0EF9: AE 00 D2 L0EF9 LDX POT0 <--- button B read here 0EFC: AD 82 0B LDA $0B82 0EFF: D0 01 BNE $0F02 0F01: 60 RTS ;-------------------------------------------------- 0F02: AD 30 18 L0F02 LDA $1830 0F05: D0 FA BNE $0F01 0F07: 20 BD 0E JSR $0EBD ;[expand] 0F0A: AD 30 18 LDA $1830 0F0D: D0 F2 BNE $0F01 0F0F: AE 00 D2 LDX POT0 <--- button B read here 0F12: E0 14 CPX #$14 0F14: B0 01 BCS $0F17 0F16: 60 RTS ;-------------------------------------------------- I admit I didn't think it was working the first time I played it, as I was expecting it to do some other type of attack. Just a moment ago, I realized that what it's actually doing is enabling a more powerful (wide) shot for a limited time - the counter at the lower-left of the screen shows how many times the player can do this. Awesome game BTW ?

The cart image (via Ultimate Cart) definitely works without issues on my real NTSC Atari 800XL ?

There are apparently two versions of Seafox floating around. The cartridge image allows you to shoot up and forward, but only one projectile at a time per direction (matching the original Apple II version). It also uses more of the built in atari fonts. The .xex file (found on homesoft and elsewhere) instead only allows shooting upward, but allows up to three projectiles at once. Having recently hacked the former version for 2 button joystick support, I can definitively say that those differences have nothing to do with 400/800/xl/xe differences...

And after 30 (!) of these, it's now time for me to take a break from these and let others have a go... ? Here's a list of other games to consider, along with some caveats: Ace of Aces Press Button 2 instead of double-tapping the fire button (!) to invoke view switching (see the game's manual for more on this) Asteroids Press Buttons 2/3 for thrust and shield/hyperspace/flip over - but it'd be good to let players select Joy2B vs. original controls on this one. Axis Assassin Press Button 2 to activate the zapper. Use the .atr from Fandal for this; other versions don't actually have a properly working zapper. Also note that pressing the zapper when the spider web appears takes you to a special bonus round... Raster Blaster Press Button 2 to activate the right flipper. This one will require hacking in a custom VBI for STA POTGO since the main loop runs repeatedly between VBLANKS... Castle Hassle Press Buttons 2/3 to switch between different ghost forms. Cloudburst Hold Button 2 to hold up the umbrella? (currently this involves holding UP) Computer War Press Button 2 to rotate pieces during the piece-matching puzzle. Dandy Dungeon Press Buttons 2/3 to activate food/bombs per player. Dark Chambers.rom Press Button 2 to activate magic (instead of double-tapping the button - the logic for this is really finicky, too) Decathlon Use Buttons 2/3 (or 1/2) for running instead of wrecking the joystick ? Desert Falcon Press Button 2 to activate acquired abilities (instead of double-tapping the button) Final Legacy Press Button 2 to instantly go back to the main view selector screen (currently mapped to the space bar). This needs to work in each of the different subscreens... Gateway to Apshai Use Button 2/3 + stick directions to substitute the START/SELECT/OPTION functions (see the manual for details) Ghost Chaser Press Button 2 to jump (instead of UP). Ghostbusters Press Button 2 to drop ghost bait and Button 3 to see status. This one's tricky since there's a rather complicated key handler here... Gumball Press Button 2 to activate the bomb defuser (instead of the space bar). Hard Hat Mack Press Button 2 to drop the jackhammer (first screen only) instead of the space bar. King Tuts Tomb Buttons 1/2 to fire left/right, and Button 3 for the flash (just like Tutankham, above). Livewire and Livewire 2 Press Button 2 to fire the zapper (Joystick mode) or Paddle 2's Button (Paddle mode). Nightstrike.rom Use the extra buttons to either independently rotate the turret or to load the other ammo types (see the manual for details). Pinball Construction Set Press Button 2 to use the right flipper (and possibly other construction set functions?) Qix (the older Mode E version) Press Button 1 for fast draw, Button 2 for slow draw. Thunderfox Press Button 1 for regular shots, and Button 2 for bombs. This also requires some UI treatment to get rid of the weapon selector icon. Wizard of Wor Button 2 + direction to change aiming direction without moving, to simulate the original arcade game's special joystick. I attempted this, but the direction changing code auto-assumes that the player will move forward and makes this harder to implement... And I'm sure there's more - can someone also fill in some PAL titles (my recommendations above come from NTSC-land)?

Here's Beer Belly Burt in Brew Biz Joy2B (based on the Homesoft .xex version). This hack essentially separates out jumping from other actions activated by pressing UP. Old controls: UP: Jump (combine with Left/Right to jump left/right), Climb stairs, Climb up conveyor belts, Climb up ladders Fire button: Shoot New controls: Button 1: Shoot Button 2: Jump (combine with Left/Right to jump left/right) UP: Climb stairs, Climb up conveyor belts, Climb up ladders Note that if you are on the ground and want to start climbing on a ladder, you'll have to jump (Button 2) to start climbing it. The original game code doesn't explicitly check if you're in front of a ladder; it makes you jump up - and holding up starts the actual climbing. ? No attempt has been made to smooth over some of the other clumsy aspects of movement in this game (can't crouch until the character's momentum has run out, momentum comes to a dead stop after landing from a jump, etc.) If anyone wants to take a try at smoothing that up, you're welcome to use this Joy2B hack as a starting point... Beer Belly Burt in Brew Biz - Joy2B.xex

I just looked at this, and unfortunately the disk does obfuscated loading a la Spelunker ? @Wrathchild Did you mean "the second button of the Amiga mouse" rather than "the second button of a Joy2B controller?" I think the game plays better with a mouse compared to a joystick, but I'm not sure offhand what the correct handling of the second button would be... Does anyone else want to attempt this?

I just tried it and it works pretty well - this is a pretty elegant way to handle selecting the control preferences. Thank you @Eyvind Bernhardsen for making this! @ascrnet Please replace the existing Spelunker binaries on the git/wiki with Eyvind's binaries ?

@ascrnet...and this is what happens when I try to code these with the sound off. ? I also tried using dis6502 to get a disassembly of the file for use with WUDSN IDE (many of the previous hacks were done by manual hex editing/note taking in a text editor). For whatever reason, it apparently misplaced a few bytes along the way ? At any rate, here's a fixed version - I just copied/pasted the relevant joy2b patch code into the actual binary in a hex editor. Thanks for pointing this out! Picnic Paranoia - Joy2B - Rev 1.xex

Here's Choplifter XEGS Joy2B (the full-color Mode E version, since IMO it's better suited to the Atari's strengths and it's PAL-friendly). Old controls: Press and release the fire button to shoot Hold the fire button to change which way the helicopter is facing New controls: Button 1: Shoot Button 2: Change which way the helicopter is facing (firing now happens on button press rather than button release) Essentially, the button controls are now in line with the original Apple II version. Firing should now be more responsive, and it should now be easier to aim at things overall ? Cartridge and .xex files are provided. (Cartridge is based on the original cart; .xex version is based on the Homesoft version) Choplifter! _ Atari (US) - Joy2B.car Choplifter XE - Joy2B.xex

I actually did hand assembly (well, text file assembly) along with a hex editor for many of the recent Joy2B hacks. It's still a useful technique if you want to replace small amounts of code in an existing binary, since you'll be counting opcode sizes to make sure everything fits. Having to recount branches by hand is painful, as @Rybags said. With that said, it can still easier than dealing with disassemblies that involve branches, JSRs and JMPs to locations that are dynamically remapped on load, and are thus near-impossible to follow without the assistance of a debugger...

That...is one very comprehensive memory map. ? Now that we know where all the variables are, it should be easier to play around with things. Thank you for providing this @kiwilove!

@kiwilove and I (and others) were discussing Hawkquest's game balance in the Joy2B thread, and we generally agree that even with separate fire/bomb buttons, the game might be in need of some game balance tweaks to make the game a little easier. Quote from the aforementioned thread: "Overall the game is probably too tough and needs some hacking to make it more playable/fun for the general player. I do have some ideas but may not be so easy to implement?" I personally feel that the right gameplay foundations are in place (it's still the most ambitious Xevious-inspired shooter I've ever seen on the Atari 8-bit, including the actual Atari Xevious prototype); it just needs some tweaks to prevent cheap player deaths. (I say this as someone who actually prefers harder games, but we ideally want the "you-were-fairly-warned" kind of Hard...) @kiwilove What ideas did you have for tweaking the game? Here are some ideas I have (not an exhaustive list) based on (repeatedly getting blown up in) my Joy2B-testing playthroughs: Flying sections: Make it easier to actually hit targets: Widen the shot sprite to make it easier to hit air targets. Allow at least 2 simultaneous bombs onscreen, or if that's not possible, increase the speed of the bombs, a la "Flak". There's a ton of onscreen bomb targets, and it'd be mighty satisfying to be able to destroy more of them... Have the simultaneous shot maximum be independent from the simultaneous bomb maximum (right now it's 2 shots, 1 of which can be a bomb) Increase the width of the bomb's hitbox to allow easier destruction of ground targets. Prevent cases where the player can get trapped/insta-killed a bit too easily: Decrease the width of the player's hitbox - the chopper's rotors make it a bit of a wide target. This alone might prevent a fair amount of the deaths. (I assume it's using standard P/M collisions for this; we may have to switch to software collisions that kick in if a P/M collision is detected). Reduce the speed of the really fast flying enemies - they're overly hard to dodge without trial and error, and the Atari's landscape screen orientation inherently means less lead time for the player to react to them. Similarly, ensure that the flying enemies don't ever move at the same speed as the player (in the x or y direction) to enable easier dodging. Change the splitting formation patterns to prevent funneling the player into hard-to-dodge traps. Don't allow flying enemy explosions to also be fatal to the player - that just makes the flying enemies even more unnecessarily hard to dodge. (I assume the collision logic is parsing the explosion as still technically being an enemy, and counting it as a fatal collision) If a player respawns near where a swarm of fast-flying enemies would normally appear, don't respawn those enemies too (this one in particular caused a bunch of instant deaths for me on new lives). Give some visual cue (in the status bar?) before a flying enemy suddenly comes up from below. Or perhaps prevent them from spawning from the bottom if the player is at the bottom of the screen. The "shotgun blast" flying enemies should be destructable, and perhaps only come in one at a time - their bullets shouldn't be that fast either. For the Bacura-alikes, change the randomization a bit/de-densify them to prevent cases where moving between them is nearly impossible. (I've been funneled into what are effectively dead ends before.) Make more of the ground targets unable to fire at you if the player has flown past them or is flying very close to them (since the player can't fire backwards); either that, or suppress such firing if there's a bunch of air targets onscreen. Maybe make the earlier planets easier so that there's a noticeable step up in difficulty in each new planet. Side question: is there an actual tactical advantage to making a second attack run upon destroying the forcefield? On-foot sections: Give the player more of a visual clue on the traps so that the player isn't just instantly frozen in some places (thus turning the player into an instant punching bag) - either that, or just equip players with the trap finder from the start. Make enemy spawners stay dead even if they're scrolled off-screen. Allow the user to retry the on-foot section by pressing the fire button on game over (just like the flying sections) Given the emphasis on exploration, perhaps start the player with the maximum amount of marines, especially given how easily players can get killed off in the flying section. To compensate for the increased player fairness but decreased difficulty, perhaps it'd be good to put in a score/performance-based ranking/bonus system so that players can get rewarded for playing the game optimally and destroying a bunch of enemies (a la Star Raiders's end game ranking) - max scores/ranking per level could potentially be stored in the save file. Regarding implementation difficulty: We have a fair amount of memory to play with (basically what's under what would be the OS rom that hasn't been taken up by existing new routines); it's more a matter of trying to figure out how the rest of the code works and what variables do what. Neither @playsoft or I have dug too deeply into this; it's probably a fairly large undertaking. With that said, if someone does do that, the actual changes might not be too hard. Some of them will be harder than others to implement, of course...