Jump to content
IGNORED

Believe it or not(sing along)!


Out_of_Gas

Recommended Posts

Nope...the only thing that I'm working on is doing the labelling - enough to the point that the program can be divided up between 2 banks...then add in animation tables for each of the objects. The game kernal is very similar to Adventure's, so once it's done it will be very easy to add in GFX frames, screens, etc. much like you would do with 8k Adventure's "tutorials".

Here's a copy of the disassembly so far:

superman.zip

Link to comment
Share on other sites

Got the disassemble, Great job(as always)!

Nukey is the MAN!!!

 

That file is a very rough assembly...there's tons of vectors that weren't labelled yet.

I've found that the screens are numbered as multiples of 8...and 8 bytes are used for each one. This value is used as an offset for page $F000 to gather that screen's info (i.e. addresses $F000 to $F007 belong to the "zero" screen and so on). This is the data that each group of 8 bytes holds:

Offset 0 and offset 1 holds the address pointer to the GFX bitmap for that screen (more on this in a second). Offset 2 holds the playfield color (i.e. the "sky" and windows in the subway), while offset 3 holds the background color. Offset 4 through 7 holds the linked screen numbers when you move out of bounds...offset 4=up, 5=right, 6=down, and 7=left.

 

The GFX bitmaps of the screens are held at page $F200. Each screen uses 9 bytes of info (3 sets of PF0, PF1, and PF2 values)...and are arranged upside-down...i.e.:

Offset 0: PF2 for the bottom group

Offset 1: PF1 for the bottom group

Offset 2: PF0 for the bottom group

Offset 3: PF2 for the middle group

Offset 4: PF1 for the middle group

Offset 5: PF0 for the middle group

Offset 6: PF2 for the top group

Offset 7: PF1 for the top group

Offset 8: PF0 for the top group

...and the bitpattern for PF0 and PF2 are in reverse of PF1's.

 

A more complete disassembly will follow some time this weekend...I should be able to track down the remaining vectors by then :)

Link to comment
Share on other sites

All set to go :) In this assembly, I unshared everything (it's possible to have different types of enemies or satellites, for example). Or the Daily Planet doorway with a globe that moves! :D All you need to do is edit the corresponding bitmaps and/or add in new ones (if adding some causes Dasm to report errors, just paste all the frames for that object on a different "page" of memory). When adding frames, you'll need to change that object's "Anim" table...listing each one by name and adjusting the AND value (see the example table SflyAnim for a better description of this).

NOTE: the color table is still a static number of bytes for each object...that would need correcting if you want the colors of objects to be able to move/change between frames).

 

Since you are currently interested in adding in W.Katt's spastic flying, I increased the number of frames for flying to 8 in this sample...notice the nice smooth animation of Supe's cape? :)

 

Final assembly + binary...hack away!

suprmn8k.zip

  • Like 1
Link to comment
Share on other sites

  • 14 years later...

All set to go icon_smile.gif In this assembly, I unshared everything (it's possible to have different types of enemies or satellites, for example). Or the Daily Planet doorway with a globe that moves! icon_mrgreen.gif All you need to do is edit the corresponding bitmaps and/or add in new ones (if adding some causes Dasm to report errors, just paste all the frames for that object on a different "page" of memory). When adding frames, you'll need to change that object's "Anim" table...listing each one by name and adjusting the AND value (see the example table SflyAnim for a better description of this).

NOTE: the color table is still a static number of bytes for each object...that would need correcting if you want the colors of objects to be able to move/change between frames).

 

Since you are currently interested in adding in W.Katt's spastic flying, I increased the number of frames for flying to 8 in this sample...notice the nice smooth animation of Supe's cape? icon_smile.gif

 

Final assembly + binary...hack away!

 

 

 

This is really cool. Love the aspect that you can have different bad guys. Is the color assigned randomly for the thugs or can that set for each thug?

  • Like 1
Link to comment
Share on other sites

The game uses color tables (the original Superman game does, too). Each gfx and color table is specific to each character here...since I unshared all data.

 

In the original Superman game, color tables are *mostly* specific to the characters...the upper and lower color values are often shared between characters, satellite colors are taken from other characters. You can see the addresses used by the original game in the disassembly I used to create the Supercharger hack of the game. I just cut a few bytes of superfluous coding so that the data tables at the end of the Rom are shifted downward by a few bytes.

 

Superman.asm

Link to comment
Share on other sites

Fascinating. I played with this a bit tonight and found out one thing.

 

On the bridge screen...

post-4709-0-50656400-1555416393_thumb.png

 

Looks like the screen background code that you detailed has two sections.

 

post-4709-0-62454400-1555412148.png

 

Looks like the above code covers the top portion of the screen:

 

post-4709-0-09994000-1555416507_thumb.png

 

So where is the bottom portion defined?

 

post-4709-0-98952100-1555416540_thumb.png

 

I figure the bottom portion of the screen is the same with the exception of one screen, the bridge screen.

 

-------------------------

 

(Hours later). I think I will be alright NOT hacking the lower portion of the bridge screen, but still kinda curious how this works. My guess is though the bridge screen is the playfield where the world ends and begins

Link to comment
Share on other sites

Hard coded exception at $F555 for that specific screen. The original game uses playfield temps to store bitmap data. On the bottom portion of the screen, zeros are saved to the PF0 and PF1 temps, and then a check is done for the bridge screen when updating the PF2 temp.

 

 

 
;* = $F555
       LDY    #$00                   ;2
       STY    TempPF0                ;3 ram $E4
       STY    TempPF1                ;3 ram $E5
      LDA    $80                    ;3
       CMP    #$0A                   ;2
       BNE    LF563                  ;2
       LDY    #$C0                   ;2
LF563: ;BNE destination
       STY    TempPF2                ;3 ram $E6
       JMP    LF579                  ;3

 

The 8k hack uses a simplified version without needing temps:

 

.noPlayfieldChange ;@64
   ldy roomGraphicPtrs        ; 3 = @67   get the graphic pointer LSB
   cpy #<BridgeRoom           ; 2 = @69
   bne .setPF2Graphics        ; 2³= @71
   ldy #%11000000             ; 2 = @73   draw gap for bridge chasm
   bne .drawRiver             ; 3 = @76   always branch
.setPF2Graphics ;@72
   ldy #00                    ; 2 = @74
   nop                        ; 2 = @76
.drawRiver ;@76
;--------------------------------------
   sta GRP0                   ; 3 = @3   draw object
   stx COLUP0                 ; 3 = @6
   sty PF2                    ; 3 = @9
   ldy #00                    ; 2 = @11
   sty PF0                    ; 3 = @14
   sty PF1                    ; 3 = @17
  • Like 1
Link to comment
Share on other sites

  • 6 months later...

Hey all, I have a hack in mind, but wanted to see if I could get some help with two adjustments...

 

1.. want to make it where the "bridge" explodes as soon as Superman enters the screen.  (no pause)

 

This it here?

 

;blow up the bridge
LF6F3:
       LDY    $9E                    ;3
       CPY    #$0C                   ;2
       BNE    LF70A                  ;2
       LDA    #<Screen00             ;2
       STA    BridgeRam              ;3 reset the bridge to be offscreen
       LDA    #<Screen18             ;2 reset all 3 pieces to be on the bridge screen
       STA    Piece1Ram              ;3
       STA    Piece2Ram              ;3
       STA    Piece3Ram              ;3
       LDA    #$10                   ;2
       STA    $F0                    ;3
       TYA                           ;2

 

2.. The parade of characters after that, I want to have it start with the helicopter.

 

The copter appears after the yellow thug, but that is not the arrangement here...

 

LF74E:
       CPY    #$38                   ;2
       BNE    LF757                  ;2
       LDX    #GreenThugRam          ;2
       JSR    LF78B                  ;6
LF757:
       CPY    #$BC                   ;2
       BNE    LF764                  ;2
       LDX    #CopterRam             ;2
       JSR    LF78B                  ;6
       LDA    #$58                   ;2
       STA    CopterRam+2            ;3
LF764:
       CPY    #$FE                   ;2
       BNE    LF76D                  ;2
       LDX    #PurpleThugRam         ;2
       JSR    LF78B                  ;6
LF76D:
       CPY    #$58                   ;2
       BNE    LF776                  ;2
       LDX    #BlueThugRam           ;2
       JSR    LF78B                  ;6
LF776:
       CPY    #$78                   ;2
       BNE    LF77F                  ;2
       LDX    #OrangeThugRam         ;2
       JSR    LF78B                  ;6
LF77F:
       CPY    #$98                   ;2
       BNE    LF788                  ;2

       LDX    #YellowThugRam         ;2
       JSR    LF78B                  ;6
LF788:
       JMP    LF6F0                  ;3

 

Any help naturally appreciated.

Link to comment
Share on other sites

The timer $9E is used in both cases.

 

In 1, the next two lines are the delay

  CPY #$0C

   BNE LF70A

You could replace those 4 bytes with NOP instructions to skip the wait.

 

In 2, look at the CPY lines for each character...that is what determines what order they are released in.  When re-arranging those, try not to precede or follow characters with ones that have an influence on their direction (look at their object matrices to see what affects what).

The yellow thug is released when the timer is #$98, the copter is next at #$BC.  So yes, that is the arrangement (even tho the program lines are not sequential).

 

I strongly advise you to experiment (or at least cross-reference) with the disassembly made by Dennis Debro...it's detailed much better than mine.

  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...