Bobo Cujo

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

Regarding Hawkquest Joy2B: There's two preceding "original" versions: 1) The original 4-disk version 2) The Atarimax 1MB(8mbit) cart version by @playsoft per this thread: @mytek @Peruchi@Mr Robot Did you try version #2 above, or just #1? Assuming that the non-Joy2B Atarimax cart version works and the Joy2B one doesn't, there's a few things that may come to mind: 1) @playsoft mentioned in the post below that there was a bug that sometimes caused the game to not boot on real hardware; I patched in the proposed fix into the Joy2B release (I don't think it's in the original Atarimax cart release). It may be possible that something about it is causing issues with 576NUC (or I implemented it incorrectly)? 2) One of the big differences between the original disk version and the Atarimax version is the usage of the >48K memory map (E000-FFFF, AKA the OS ROM space). The extra code for Joy2B support (which was a more involved hack than the other Joy2B hacks I made) involves even more extra code in the OS ROM space. I can't imagine that it would cause problems since that part of ram should be fully banked in (and the OS ROM banked out), but just in case, could that be causing issues with 576NUC memory management? From my original notes (pardon the lack of comments; the key thing is where I located things in memory...): ;-------------------------------------------------- ; New Button 2 handler (in OS RAM space) ;-------------------------------------------------- ; E965: Button 2 debouncing value E966: AD 70 02 lda PADDL0 E969: C9 E4 cmp #$e4 E96B: D0 0D BNE $E97A E96D: AD 65 E9 lda $E965 E970: D0 0D BNE $E97F E972: A9 01 lda #$01 E974: 8D 65 E9 sta $E965 E977: 4C 9E 85 JMP $859E E97A: A9 00 lda #$00 E97C: 8D 65 E9 sta $E965 E97F: 60 RTS ;-------------------------------------------------- ; New, relocated Custom Immediate VBLANK handler (the call to setting SETVBV needs to be set to the new address too) ;-------------------------------------------------- F2E0: AD 00 D3 LDA PORTA ; $FE380 in the rom, $E965 in system memory F2E3: 29 0F AND #$0F ; ($FED40 in rom/$F2DF in system) is where free space begins) F2E5: 8D 78 02 STA STICK0 F2E8: AD 10 D0 LDA TRIG0 F2EB: 8D 84 02 STA STRIG0 F2EE: AD 00 D2 lda POT0 F2F1: 8D 0B D2 STA POTGO F2F4: 8D 70 02 STA PADDL0 F2F7: A9 01 LDA #$01 F2F9: 8D 16 E8 STA $E816 F2FC: AD 18 02 LDA CDTMV1 F2FF: F0 08 BEQ $E985 F301: CE 18 02 DEC CDTMV1 F304: D0 03 BNE $E985 F306: 20 C2 E9 JSR $E9C2 ;[expand] F309: AD 1A 02 LDA CDTMV2 F30C: F0 08 BEQ $E992 F30E: CE 1A 02 DEC CDTMV2 F311: D0 03 BNE $E992 F313: 20 C5 E9 JSR $E9C5 ;[expand] F316: AD 1C 02 LDA CDTMV3 F319: F0 0A BEQ $E9A1 F31B: CE 1C 02 DEC CDTMV3 F31E: D0 05 BNE $E9A1 F320: A9 00 LDA #$00 F322: 8D 2A 02 STA CDTMF3 F325: AD 1E 02 LDA CDTMV4 F328: F0 0A BEQ $E9B0 F32A: CE 1E 02 DEC CDTMV4 F32D: D0 05 BNE $E9B0 F32F: A9 00 LDA #$00 F331: 8D 2C 02 STA CDTMF4 F334: AD 20 02 LDA CDTMV5 F337: F0 0A BEQ $E9BF F339: CE 20 02 DEC CDTMV5 F33C: D0 05 BNE $E9BF F33E: A9 00 LDA #$00 F340: 8D 2E 02 STA CDTMF5 F343: 6C 24 02 JMP (VVBLKD) ;-------------------------------------------------- ;As pointed out by Paul Lay, replace the following mutexes to fix a bug from the original cart release: AD 0E D4 LDA NMIEN 48 PHA ;with: A9 40 LDA #$40 48 PHA EA NOP ;-------------------------------------------------- And finally, for those wondering: I tested Hawkquest Joy2B on an actual NTSC 800XL and in Altirra; I didn't test this on other systems (I don't even have NTSC 128K Ataris anymore ? )

@rensoup I went ahead and played the entire game (Atarimax Cart version in Altirra, NTSC 130XE mode with 128KB ram, default game settings) start to finish. First of all, like everyone else on this thread, I'm incredibly, unbelievably impressed by this port. My hat is very much off to you ? That said, I did run into a couple of issues (and my apologies if any of this has been asked before; it's a looooooong thread), so here's my bug reports: - ESC/Option doesn't seem to skip between-level cutscenes, or skip the death music. Was this intentional? (I may be used to this from playing the DOS version of this game) - Two of the fake life-up jugs on Level 9 are supposed to vertically flip the screen as a joke (the first one flips the screen, the second one reverses the effect). In this version, it does nothing. Was this intentional for technical reasons (PMG handling)? - I don't think the "princess watching the hourglass" cutscene is supposed to play between: Level 12/Before Jafar, and After Jafar/Before the ending level. I saw it both times... (I had 12 or so minutes on the clock) - I didn't get to see the ending animation because Altirra/the game crashed ? Altirra threw up an internal error dialog message (no specifics on the actual error) when the ending was about to play. I enabled the debugger when this happened; attached is a screenshot of the history/registers windows and the history window text itself - let me know if there's a better/more comprehensive way to get a dump for this. Again, despite the above, amazing work! PoP Atarimax History Dump.txt

I've personally played A8 Scramble with both a Sega Genesis controller and a Joy2B stick - both work great for shoot+bomb. You actually wouldn't want down+fire to bomb in this game - a key strategy in this game is to stay low to the ground so that you can bomb at a fast rate, and you wouldn't want to risk crashing into the ground... (Especially in areas 3 and 4)

I've also noticed that the Ultimate cart isn't consistent about loading .xex files on the Atari 800. It works fine on XL/XEs pretty consistently. I'm guessing this has to do with 400/800s somehow not being able to use $8000-BFFF because the hardware isn't there to allow cartridge disabling (CCNTL/$D500-D5FF)? ("Mapping the Atari memory map" is unclear on whether this works differently on 400/800s)