HUMANTRON - new game

[Blue Azure]

Introducing HUMANTRON - A *NEW* 7800 GAME. Well not exactly.

But it's still April Fool's month, and some can still be fooled.

 

Here's what I think happened…For 30 years now, the Mutant Clone (You) have been saving humans from these horrible Robotron monsters. And the inevitable happened. You have run out of bullets!!! What to do? What will you do? Being resourceful and having a supply of over 7,000,000,000 humans saved, what will you do? YOU THROW HUMANS AT THE ROBOTRON MONSTERS, and save more humans!!!

 

 

DO NOT TRY THIS AT HOME - THROWING HUMANS IS NEVER A GOOD IDEA.

 

 

THE MODIFIX MENU:

Obtain your original ROBOTRON 2084 (checksum $BFDC) file and modify as follows

(all addresses shown are system-level addresses, for EPROM/binary subtract 8000):

1) Change $9044 from $A5$75 to $A5$74 to start with one Player#1 life.

2) Change $9061 from $A5$75 to $A5$74 to start with one Player#2 life.

3) Change $D358 from $C0$07 to $C0$0E to display up to 14 lives.

4) Change $D8B1 from $C9$0D$D0 to $4C$40$D9 to be invincible.

5) Change $FCA0 from $3A to $11 (for Mommies and Daddies) or $13 (Daddies only). One could experiment loading different values from $00 thru $FF at location $FCA0, although many crash with a value over $4F. You can throw Mikeys, and Brains ($2C) as well. Tell us what you find!!!

 

Unfortunately this game is glitchy - in fact it outright crashes without an attempt to correct for the size of these new "bullets." The problem occurs at the bottom of the screen. If you stay away from the bottom and shooting left and right - it works fine. I attempted to compensate by changing the height of the Mutant Clone by changing $D7E6 from $69$0B to $69$0C which prevents the Mutant Clone to reach the bottom by one count. Now the game generally doesn't completely crash, but now it tends to crash when shooting at the top of the screen instead of the bottom. This was obviously a tight design that wasn't meant to be tweaked.

 

The code of possible interest:

 

The problem is probably caused by the shot failing the border/boundary test. The "human" bullet is much larger than an ordinary bullet. And I'm assuming we're failing the y-axis since there's only trouble when shooting at the bottom (or top) of the screen.

 

MCSYMI:

DB10--BD-79-1B--LDA SYTBL,X---------------;LOAD SHOT Y POSITION

DB13--38----------SEC

DB14--E9-08-------SBC #SHOTSTY-----------;DECREMENT Y POS BY Y SHOTSTEP

DB16--9D-79-1B--STA SYTBL,X---------------;SAVE NEW POS IN TABLES

DB19--18----------CLC

DB1A--69-10-------ADC #$10-----------------;ADD FOR BORDER CHECKING

DB1C--C9-22-------CMP #MINY+$10

DB1E--90-0B-------BCC SHOTEND_$DB2B

DB20--BD-8D-1F--LDA SYEXTBL,X------------;GET THE EXTENT

DB23--E9-08-------SBC #SHOTSTY-----------;MOVE THE OTHER EDGE

DB25--9D-8D-1F--STA SYEXTBL,X

DB28--4C-33-DB--JMP MOVESD--------------;DONE WITH MOVING SHOT

 

* NOTE: IN THE BORDER CHECKING ABOVE IT IS OK TO USE SHOTWID AND SHOTHT

* INSTEAD OF ACTUAL EXTENTS - SHOTS ARE NEVER PARALLEL TO BORDERS THEY HIT

* COMPUTE CHANGES IN MC'S POSITION

 

 

D7CE--AA----------TAX------------------------;PUT IT IN X TO INDEX

D7CF--BD-3D-EC--LDA XDIRTBL4,X----------;RETURNS 0, +STEP OR -STEP FROM 4-BITS

D7D2--6D-CF-1A--ADC MCXPOS--------------;MOVE 1 STEP

D7D5--85-BE-------STA MCXPOS-------------;STORE NEW POSITION

D7D7--18----------CLC

D7D8--69-05-------ADC #MCWID

D7DA--85-C0-------STA MCXEX---------------;STORE NEW X EXTENT

D7DC--BD-4D-EC--LDA YDIRTBL4,X----------;RETURN CHANGE IN Y POSITION

D7DF--18----------CLC

D7E0--6D-26-1B--ADC MCYPOS--------------;MOVE 1 STEP IN Y DIRECTION

D7E3--85-BF-------STA MCYPOS--------------;STORE NEW Y POSITION

D7E5--18----------CLC

D7E6--69-0B-------ADC #MCHEIGHT

D7E8--85-C1-------STA MCYEX----------------;STORE NEW Y EXTENT

D7EA--A2-00-------LDX #$00-----------------;LOOK AT MC ENTRIES IN OBJECT TABLES

D7EC--20-B4-D1--JSR CHKOBJBD------------;CHECK IF OFF SCREEN

 

Obviously this game is some kind of freak, but freaks can be fun. I'd like to get this working. Maybe the specialist Robotrondev can fix this by limiting the Y-coordinate that the Mutant Clone can travel. It looks like it only needs to be limited by one or two counts and then the game will function properly 100% with the data at $D7E6/7 changed back to $69$0B.

 

ROBOTRON DISASSY (reference)

RobotronDisassy2013.rtf

NTSC HUMANTRON, binary

HUMANTRON_NTSC_C0A3.bin

NTSC HUMANTRON, emulator

Humantron_NTSC_32K.a78