Bobo Cujo
-
Posts
99 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Posts posted by Bobo Cujo
-
-
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.
-
2
-
-
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.
-
2
-
-
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...
-
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...
-
1
-
-
On 5/30/2023 at 10:31 AM, Eyvind Bernhardsen said:
The decision to make pot-pin buttons work like this wasn't invented for Joy2B+, so changing it would break old games, but it's not quite as bad as you make it out to be. This code is universal:
PADDL0 = $270 pot_max = $e4 test_button_c lda PADDL0 cmp prev_button_c beq not_pressed sta prev_button_c eor #pot_max bne not_pressed ; code to handle button press goes here! ... not_pressed ; button wasn't pressed, go do something else prev_button_c .byte pot_max(My code calls it "Button C" because that's what it's called on a Megadrive/Genesis controller). You can detect a Joy2B+ or compatible button by checking if prev_button_c ever gets set to anything other than #$e4, and you can read the third button from PADDL1 in the same way.
Edit: the code works with a normal joystick because the button is "held down" on startup, and won't be detected until it's "released".
@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 :-))
-
3
-
-
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.
-
1
-
-
@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).
-
1
-
-
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
-
1
-
1
-
-
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.
-
1
-
1
-
-
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)
-
3
-
-
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:
@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!
-
3
-
-
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)
-
3
-
-
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)
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Co-op simultaneous 2 player games?
in Atari 8-Bit Computers
Posted
...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...)