Bobo Cujo

"Oil's Well" is a great game for testing horizontal overscan. With no overscan filtering, you can see the monsters for each row (implemented as Player sprites) come in a lot sooner than you normally would...

I have two 2600-Daptor IIs for Atari joystick/paddle usage. That model also supports Joy2B+ (extra buttons) as of the latest firmware update, in case you end up with any sticks that have been modded for it.

N.Y.C The Big Apple (Synapse) - upon getting the key to the city, you're seemingly treated to the same ending screen with King Kong on top of the Empire State building... who then gets promptly knocked down by an airplane with a "WINNER" banner. One of the simplest, yet most satisfying endings I've seen in a video game (let alone an Atari Computer game), and great revenge on all the game overs it takes to get there...

Does removing the RF modulator completely remove the need for the shield (even for the HAM Radio operator across the street case)?

...and also Ali Baba's spiritual sequel, Return of Heracles. (just be mindful that once a character dies, they stay dead, unlike Ali Baba. Also make sure you bring enough warriors to the Trojan Horse quest, because dying there makes the game unwinnable...)

With that said, Dandy (Gauntlet-esque, but made before Gauntlet) is also a co-op game option that'll definitely work on a 48K machine - with 4 player support too.

Gauntlet absolutely requires 64K, unfortunately. (I have an original disk/package for it, and it explicitly states that it requires an XL/XE 64K)

Zombies and its semi-sequel, Realm of Impossibility. (I'd go for the latter as it's more beginner-friendly) Seconding Asteroids, which even has a mode where the game ends when one player (not all of them) loses all their lives.

And even PAL games that technically work on NTSC might run at a more manageable speed on PAL as intended. Famous examples: Dropzone and Trailblazer...

@retrosix 1. Is https://retrosix.co.uk/Atari-2600-CleanComp-Composite-Video-Out-p537997297 the correct page to order V2? The page only mentions V1's release notes. 2. Does V2 still have the issue with switch-mode power supplies as V1 did?

I believe @Eyvind Bernhardsen already decrypted Spelunker's disk obfuscation back when we were working on adding Joy2B+ support for it...

I personally would leave the stick as is and wire up the top button to the main Fire Button. I love my Seimitsu LS-56 and Sanwa Clone sticks, but being able to use the joystick/button 1-handed is really great for games that use the keyboard too - the Atari 8-bit still has a lot of those that even Joy2b+ can't patch away (Star Raiders! F-15 Strike Eagle! etc.)

@pirx @Pecus I downloaded the source code and played around with it a bit. The following fix works for the gameplay section (verified on both my real Atari 800XL and in Altirra, with all three combinations of controllers I mentioned in my previous posts): game.asm: (added code is in purple) ManualShooting .IF TARGET = 800 lda #0 sta PaddleState .ENDIF lda JoyNumber,x sta JoystickNumber ; set joystick port for player ... However, when I tried adding this to textproc.asm (in .proc CallPurchaseForEveryTank) to fix the issue in the purchasing menus, the build failed due to a lack of free bytes. 😞 I tried putting the above code snippet in a .proc and having both targets jsr into this routine, but that led to the game getting glitchy after entering all player names and between player turns (I put it right after .proc MainRoundLoop in game.asm). Either I dislocated some important variable placement, or the 12 extra cycles per call is enough to throw off some (presumably tight) code timing...

@ascrnet When you have a chance, can you add this information to https://github.com/ascrnet/Joy2Bplus ? It's definitely a best practice we should highlight for anyone else who wishes to implement Joy2B+ support. (I would have also benefitted from this guidance when I did my Joy2B hacks :-))

The same effect can also be seen in the initial Purchase Weapon screen before we even get to the main gameplay, likely for the exact same technical reason. Using the same 2-player scenario from above: "A" buys some weapons, and moves on beyond the purchase/activation screen. "B" is immediately put in the Defensive page (since Button 2 toggles between the offense and defense item pages).

Actually, this happens with just 2 players too: Joy2B in Port 1, ordinary stick in Port 2. 2 players (named "A" and "B"), each with baby missile/missile/baby nuke/nuke. Turn order: "A" (joy2B), "B" (ordinary stick). Every time "B"'s turn comes up, they end up switching to the next weapon immediately on starting their turn. EDIT: This also happens if we have an ordinary stick in Port 1 and the Joy2B stick in Port 2. In this case, "A" is the player that gets the involuntary weapon switch at the start of their turn.

@pirx Unfortunately, your suspicion was correct. My setup: Joy2B in Port 1, ordinary stick in Port 2. 4 players (named "A", "B", "C", and "D" respectively), each with baby missile/missile/baby nuke/nuke. Turn order: "A" (joy2B), "C" (joy2B), "B" (ordinary stick), "D" (ordinary stick). Every time "B"'s turn comes up, they end up switching to the next weapon immediately on starting their turn. However, this does not occur with any of the other players (including D).

Thanks for implementing this (especially with the memory constraints!) I'm going to test this later tonight on my NTSC Atari 800xl and report here. Let me know if you want me to get my Atari 800 to test 3-4 player scenarios too.

I was thinking about this issue more generally, but for my own purposes, 128 bytes-ish would probably be fine. Given the limited amount of nvram cart options (even virtual ones for flash carts), using passwords/QR codes/etc. may not be a bad idea either (and wouldn't require a disk drive).

After looking at scorch.xex in the Altirra debugger: It looks Scorch is using the OS ROM's VBlank handler, which already calls STA POTGO at 60 (or 50) hz in order to scan the paddle lines. Assuming that Scorch is scanning inputs at the same speed, it's mostly a matter of calling: LDA PADDL0 (Button 2) or LDA PADDL1 (Button 3) (and so on for the other controller ports) and CMP #$E4 to see if the button was pressed. (All of the hacks I wrote assumed Joy2B support - you may want to see what value comes out of these with a standard Atari Joystick to make sure that it works properly when the paddle lines are left floating.) The absolute simplest code sample that I have comes from my earlier Joy2B hack of English Software's Air Strike, where I replaced the "press Space to bomb" code with "press Button 2 to bomb" - it involved a replacement of all of five bytes since the OS ROM was already calling STA POTGO: ; ORIGINAL ;-------------------------------------------------- 15D4: AD FC 02 LDA CH 15D7: C9 21 CMP #$21 ; Was Space Bar pressed? 15D9: D0 34 BNE $160F ; MODIFIED ;-------------------------------------------------- 15D4: AD 70 02 lda PADDL0 ; Get Button 2 state 15D7: C9 E4 cmp #$e4 ; Was Button 2 pressed? 15D9: D0 34 BNE $160F

As of 3/11/2023, the 2600-daptor II has support for Joy2B+ controllers (Thanks Hafner Enterprises!) http://www.2600-daptor.com/2600-daptor.htm The Joy2B+ extra buttons are mapped as Buttons 3 and 4 (where the main Atari fire button is Button 1). I have actual 2600-daptor II hardware and Joy2B controllers - please let me know if you need me to test anything in Stella.

I didn't know the TeleLink II cart had static NVRAM in it! That's exactly the kind of cart format I was looking for - does anyone know if there are any others (that are supported as part of the .car format) with NVRAM? As for using disk drives: I do know about/have worked with SIO - the main reason I wanted to avoid it was that I wanted to be able to have the program and saved data be on the same multicart/SD card. On numerous A8 multicarts (or at least, my Ultimate/UNO carts), it's possible to mount a cartridge/binary executable or a disk drive - but *not* both at the same time, meaning a second device (real disk drive, SIO2SD, SIO2USB, etc.) would be required. 😞 I do realize that supporting this case is a good idea anyway, but it'd be nice to have a solution that required less connected hardware.

I finally got to trying this, and I'm rightly impressed. Nice work! I've played the original DOS Scorched Earth too - it's nice to have a version that just works (the 386 I played the DOS Scorched Earth had issues with its keyboard routine). One small feature request - would it be possible to add a Joy2B+ option so that Button 2 can switch weapons (instead of having to reach for the TAB key)? For context: https://github.com/ascrnet/Joy2Bplus

Hi everyone, Do any of the known Atari8 cartridge formats support any sort of persistent storage (battery backed or otherwise) for storing small (<4KB or so) amounts of data, e.g. high scores, config, basic save games, ...? The closest thing I could think of was the AtariMax cartridges, but 1) having to reflash a specific part of the cartridge seems a little complicated 2) I don't know how many flashes the carts can take before the flash memory loses writability. Failing that, are there any special formats usable for Ultimate/Uno/etc. carts that have special modes that can leverage the fact that we have SD cards? (yes, I know that Atari floppy disks exist too - I was trying to see if I could accomplish this without requiring the use of a disk drive, which then means needing disk loading routines, loading in dos.sys, etc...) Thanks,

The Joy2B version of Hawkquest was never made in 1MB .xex form; it was only made available in .car (Atarimax cartridge) form. If that was made into an .xex, it would definitely explain why the game didn't boot ? To my knowledge, I don't think non-Joy2B Hawkquest ever made it to an .xex version either... (for those wondering: I didn't make a Joy2B version of the original 4-disk version, since it lacks NTSC compatibility)