Modifying Capture the Flag for #FujiNet

[tschak909]

it occurs to me that it should be possible to modify this game for fujinet:

 

http://www.atarimania.com/game-atari-400-800-xl-xe-capture-the-flag_888.html

 

There is a file version in the homesoft collection that could be used as a starting point.

 

Basically it would need four things:

 

(0) a screen to connect to host or listen on port 6502.

(1) send the maze data from player 1 to player 2 (no translation or anything needed, just SIO WRITE the buffer, the other side just SIO READs it into the same place.)

(2) only send joystick changes

(3) automatically select 2 player, and have player 1 select invader or defender.

 

If I'm right, the result should be highly playable.

 

 

Thoughts?
-Thom

[tschak909]

Have started the attempt, and it is in github:

https://github.com/FujiNetWIFI/fujinet-apps/tree/master/Capture_the_Flag

 

So far, I can jump out to my own code before the game starts, and establish a network connection, but things go south very quickly when I try to insert _ANYTHING_ into the game code, particularly in spots like this:

 

L5677       cpy #$1F
            beq L5683
            jsr L599C
            sta L0083
            jmp L56C3
L5683       lda STICK0
            and STICK1
            and #$0F
            sta L0083
            lda STRIG0
            and STRIG1
            jmp L56A0
L5696       lda STICK0,X
            and #$0F
        sta L0083
            lda STRIG0,X
L56A0       bne L56C3
            ldx L0083
            lda L56B3,X
            cmp #$FF
            beq L56B0
            sta L00E8
            jmp L5732
L56B0       jmp L5745
L56B3       .byte $FF,$FF,$FF,$FF,$FF

If I try to insert ANYTHING anywhere in here, the whole game refuses to run, and goes into a loop where it's color cycling PCOLR4. grrrr.

 

I am NOT experienced in disassembling games and marking data sections, so am pretty sure I'm still being bitten here...

 

-Thom

[Wrathchild]

I converted this to the 5200 so have a disassembly you can use, but midnight here so will get in touch tomorrow.

[tsom]

A quick look at the code on GitHub, it’s including a file “ctf.inc” but it’s not in the repo...

[tschak909]

14 minutes ago, tsom said:

A quick look at the code on GitHub, it’s including a file “ctf.inc” but it’s not in the repo...

fixed. it is just an equates file.

-Thom

 

[+DjayBee]

Wild guess #1:

Your code runs inside the VBI where you should not do SIO calls. 

 

Wild guess #2:

You are fighting against the nasty checksum code which checks integrity of the code. 

[tschak909]

18 minutes ago, DjayBee said:

Wild guess #1:

Your code runs inside the VBI where you should not do SIO calls. 

 

Wild guess #2:

You are fighting against the nasty checksum code which checks integrity of the code. 

I found the VBI (I see the call to VBV), definitely not doing anything in there

 

There's checksum code?!

aigh.

 

-Thom

[flashjazzcat]

Data sections aren't marked as I mentioned before, so lookup tables, jump tables, etc, which disassembled as random code are assembling with all the wrong values when other equates change (when new code is added, etc). The disassembly needs careful scrutiny and editing before one can start adding new bits. You should start with something that can at least run when assembled to a different start address.

[+DjayBee]

I wrote my last message OTOH. The checksum code is only part of the loader and gone by the time the XEX is started.

 

Until you make the source relocatable this should work:

 

	org $400	; or some other unused area

L4x01	
    ; do more stuff
    ; take care A contains STRIG0
	and STRIG1
    rts
    
L5683       lda STICK0
            and STICK1
            and #$0F
            sta L0083
            lda STRIG0
            jsr L4x01
            jmp L56A0

 

Edited January 4, 2021 by DjayBee

[thorfdbg]

9 hours ago, tschak909 said:

I found the VBI (I see the call to VBV), definitely not doing anything in there

 

There's checksum code?!

aigh.

There is a checksum code, indeed, just a pretty well hidden one. I forgot unfortunately the details. If I recall, it was part of the VBI which checked for a flag, upon which it decoded a function which performed the checksum.

 

[+DjayBee]

Are you sure?

I only found the not well hidden, but very nasty one in the loader. It creates a 16-bit checksum and does eight rounds on every byte of the whole program. Thus this one is also much too heavy for a VBI.

 

Please test if this XEX runs as expected:

Capture the Flag-NOP.xex

 

I replaced two accesses to zero page originally using 3-byte commands (16-bit addresses) with real 2-byte zero page commands, each followed by a NOP. The code length stays the same but the checksum for sure is now different. At first glance it works fine.

[tschak909]

1 hour ago, DjayBee said:

Are you sure?

I only found the not well hidden, but very nasty one in the loader. It creates a 16-bit checksum and does eight rounds on every byte of the whole program. Thus this one is also much too heavy for a VBI.

 

Please test if this XEX runs as expected:

Capture the Flag-NOP.xex 8.71 kB · 0 downloads

 

I replaced two accesses to zero page originally using 3-byte commands (16-bit addresses) with real 2-byte zero page commands, each followed by a NOP. The code length stays the same but the checksum for sure is now different. At first glance it works fine.

Yup, seems to be fine. heh, count on me to step on a land mine.

-Thom

 

[+DjayBee]

Then my JSR-approach from post #9 should be feasible for the time being.