Jump to content
IGNORED

Bruce Lee retweaked sprites


TIX

Recommended Posts

18 hours ago, fantômas said:

Hi,

 

I finally found time to do what I talked about. So here is a new RC, based on the HomeSoft version of Bruce Lee.

  1. I imported the new sprites into the HomeSoft xex (TIX, I hope I did this job well ?. I wrote a program to do that, but there can be errors),
  2. Changed the title screen:
  3. Changed the version (Ctrl+V):

 

Thank you fantomas for everything, looks perfect  :D?

 

Also thanks everybody for the encouragement !

As for the problem you described, I'm not qualified to answer.. I'm just the pixel artist.

 

Still pending the FINAL final version, with the new flying kick !

Edited by TIX
  • Like 3
Link to comment
Share on other sites

52 minutes ago, flashjazzcat said:

Was able to capture the effect in emulation by setting a breakpoint on writes to NMIEN:

 

bruce.thumb.png.6a16b9b727b0aa6efafc316a7a840c99.png

 

Subsequent to this, VDSLST ($200) is changed mid-frame while DLIs are enabled, so - while I lack Avery's pinpoint accuracy with this kind of opportune troubleshooting - I'm guessing this lucks out in emulation but at some point on real hardware, a DLI fires while VDSLST is invalid. Unsure why it wouldn't come a cropper when loaded via other means... I'll let the developer figure it out. :)

 

PS: There are some Scrotum Labyrinth calibre glitches in a few of early screen transitions as well.

LMFAO @ Scrotum Labyrinth.  Thanks, you brightened up my workday.

  • Like 1
Link to comment
Share on other sites

36 minutes ago, TIX said:

Still pending the FINAL final version, with the new flying kick !

Not to rain on your parade, but a new sprite definitely needs another RC and a few people playing the whole game. It might have new side effects.

Link to comment
Share on other sites

12 hours ago, Philsan said:

Thank you very much @fantômas and @MrFish?

 

Compared to Homesoft's version, you cannot use start key to skip titlescreen, only space bar.

For me it's not a problem, but perhaps people with XEGS without keyboard could not start the game.

You're right, you're right! So I changed, and the RC9 uses the console keys instead of the space bar.

 

3 hours ago, Faicuai said:

 

I do not have problems, however, when loading the current RC8 exec from SDrive or SIO2USB bootable (from PC), though. It works perfectly there. But that would not going to be the method-of-choice for loading it (on my end).

 

 

1 hour ago, flashjazzcat said:

Was able to capture the effect in emulation by setting a breakpoint on writes to NMIEN:

Subsequent to this, VDSLST ($200) is changed mid-frame while DLIs are enabled, so - while I lack Avery's pinpoint accuracy with this kind of opportune troubleshooting - I'm guessing this lucks out in emulation but at some point on real hardware, a DLI fires while VDSLST is invalid. Unsure why it wouldn't come a cropper when loaded via other means... I'll let the developer figure it out. :)

 

PS: There are some Scrotum Labyrinth calibre glitches in a few of early screen transitions as well.

Thank you very much for your feedback. I have to say, I'm not sure what to do.

The RC works on my 800XL (tested with Side2 and Ultimate Cartridge). I propose you an RC9 with some modifications, but I move in the dark.

I join it with and without the new intro screen.

 

RC9 With New Title Screen.xex

RC9.xex

 

The RC8 version is based on a different XEX of Bruce Lee than the RC7 version. I also attach this version for testing.

 

Bruce Lee (1984) (Datasoft).xex

 

15 hours ago, Faicuai said:

 

It seems that Bruce's skin-tone and hatch-pattern on the left appear to be referencing color on band (hue) 0F. That would render Bruce's face musk / greenish on many modern NTSC displays, including digital LCDs.

 

If fortunately the version with the new intro screen eventually works, I will take a look....

 

  • Thanks 1
Link to comment
Share on other sites

Just replayed the original cassette version, and I could not fall off the edge on the congrats screen. Just his little pinky toe kept him on the ledge while jumping and celebrating :)

 

To replicate, keep running to the right, long after the "end boss" is defeated and you go to the celebration screen.  Keep running.  In RC8 full sprite hack, you fall off the edge.

 

Edited by ivop
  • Haha 1
Link to comment
Share on other sites

29 minutes ago, fantômas said:

The RC works on my 800XL (tested with Side2 and Ultimate Cartridge). I propose you an RC9 with some modifications, but I move in the dark.

Thanks for the various RC versions. All crashed immediately after the title screen on real hardware (U1MB/SIDE2) until I disabled the FAT FMS in the SIDE loader. Then every single version worked.

 

The SIDE Loader's FAT FMS (DOS) resides between $0A00 and $1600 or so (immediately above the XEX loader module). Obviously, it's not needed by the game but XEX files are free to overwrite anything beyond $09FF as long as they don't require the FMS. Turning off the FMS causes all memory between $0A00 and MEMTOP to be cleared prior to loading the XEX. When the FMS is enabled, only memory between the end of the FMS module and MEMTOP is cleared. Since disabling the FMS appears to fix the issue, I can only assume that the crash is caused by uninitialised RAM (i.e. assuming memory somewhere between $0A00 and $16xx is zero when it is not).

 

This would explain why problems were observed when launching the XEX under SDX and DOS 2.5 as well, but does not explain why I cannot replicate the issue in Altirra in the exact same environment.

 

Anyway: that's what it looks like to me. :)

Edited by flashjazzcat
Addresses
  • Like 1
Link to comment
Share on other sites

1 hour ago, flashjazzcat said:

Thanks for the various RC versions. All crashed immediately after the title screen on real hardware (U1MB/SIDE2) until I disabled the FAT FMS in the SIDE loader. Then every single version worked.

 

The SIDE Loader's FAT FMS (DOS) resides between $0A00 and $1600 or so (immediately above the XEX loader module). Obviously, it's not needed by the game but XEX files are free to overwrite anything beyond $09FF as long as they don't require the FMS. Turning off the FMS causes all memory between $0A00 and MEMTOP to be cleared prior to loading the XEX. When the FMS is enabled, only memory between the end of the FMS module and MEMTOP is cleared. Since disabling the FMS appears to fix the issue, I can only assume that the crash is caused by uninitialised RAM (i.e. assuming memory somewhere between $0A00 and $16xx is zero when it is not).

 

This would explain why problems were observed when launching the XEX under SDX and DOS 2.5 as well, but does not explain why I cannot replicate the issue in Altirra in the exact same environment.

 

Anyway: that's what it looks like to me. :)

NICE!!!

 

There you go! Confirmed on Incognito, as well: disabling FAT-FMS on Side Loader settings menu, proceeds with succesful loading of Bruce's .xex with modified Intro-screen.

 

HOWEVER, the original .XEX (up to RC7) does not fail with FAT-FMS enabled. Therefore, and taking into account your details:

 

1. Original Intro-Screen may be already clearing $0A00 to $1600 (or beyond) before proceeding with the whole game itself (but newer intro screen stripped that code?). I suspect this is the case, because as soon as the original .XEX file is loaded, when you hit any key, splash-screen gets "loaded" again with the classical "reset" sound (gentle, very short buzz) coming off the 800's speaker, BEFORE proceeding to actual game screen. I speculate that is the precise moment in which RAM is cleared (?)

 

2. If the above is not true, the modified Intro screen then maybe touching that $0A00-$1600 area (?) and leaving something in there that corrupts the execution, down the road, on screenplay #1.

 

I will try to confirm (or not) that $0A00-$1600 is being actually cleared by original version, and (if that is true), then current RC-version (modified screen) will need to be patched appropriately.

 

 

Edited by Faicuai
Link to comment
Share on other sites

24 minutes ago, flashjazzcat said:

Thanks for the various RC versions. All crashed immediately after the title screen on real hardware (U1MB/SIDE2) until I disabled the FAT FMS in the SIDE loader. Then every single version worked.

 

The SIDE Loader's FAT FMS (DOS) resides between $0A00 and $1600 or so (immediately above the XEX loader module). Obviously, it's not needed by the game but XEX files are free to overwrite anything beyond $09FF as long as they don't require the FMS. Turning off the FMS causes all memory between $0A00 and MEMTOP to be cleared prior to loading the XEX. When the FMS is enabled, only memory between the end of the FMS module and MEMTOP is cleared. Since disabling the FMS appears to fix the issue, I can only assume that the crash is caused by uninitialised RAM (i.e. assuming memory somewhere between $0A00 and $16xx is zero when it is not).

 

This would explain why problems were observed when launching the XEX under SDX and DOS 2.5 as well, but does not explain why I cannot replicate the issue in Altirra in the exact same environment.

 

Anyway: that's what it looks like to me. :)

 

Thank you!

 

I'm afraid all this is a little beyond me. Is there anything I can do to avoid having to disable this option?

 

 

Otherwise, here's what I understood from the way the XEX is built: segment A actually corresponds to the memory range $2000-$7BFF, but segment B ($7C18-$97FF) will be copied later at $0418-$1FFF. We therefore have at the end the memory range $0418-$7BFF entirely from the bytes of the XEX (segment A+ segment B). The other segments correspond to the title screen and the text animation.

 

image.png.d883c82c2e9bb1fdbbd64a5a582ca378.png

Link to comment
Share on other sites

Weird. Original (1984), RC8, RC9 and RC9 with new title screen all crash for me 100 per cent of the time on real hardware (U1MB/SIDE2) with the FMS enabled. All work with the FMS turned off. No crash observable in emulation.

 

Regarding segments: solid blocks of code and data will not be a problem, but addresses outside of the segments may be used for data. If that data isn't explicitly initialised before use, problems ensue.

 

Hypothetical example: there's a gap between $7BFF and $7C18. The two separate segments could have been caused by one or more '.DS' pseudo-ops in the source code. The contents of that memory are entirely unknown at load time, strictly speaking. Of course that particular area will be cleared regardless, but the only reason the loader clears any RAM at all prior to loading an XEX is to account for programs which neglect to initialise memory to known values.

 

Link to comment
Share on other sites

22 minutes ago, Faicuai said:

NICE!!!

 

There you go! Confirmed on Incognito, as well: disabling FAT-FMS on Side Loader settings menu, proceeds with succesful loading of Bruce's .xex with modified Intro-screen.

 

HOWEVER, the original .XEX (up to RC7) does not fail with FAT-FMS enabled. Therefore, and taking into account your details:

 

1. Original Intro-Screen may be already clearing $0A00 to $1600 (or beyond) before proceeding with the whole game itself (but newer intro screen stripped that code?). I suspect this is the case, because as soon as the original .XEX file is loaded, when you hit any key, splash-screen gets "loaded" again with the classical "reset" sound (gentle, very short buzz) coming off the 800's speaker, BEFORE proceeding to actual game screen. I speculate that is the precise moment in which RAM is cleared (?)

 

2. If the above is not true, the modified Intro screen then maybe touching that $0A00-$1600 area (?) and leaving something in there that corrupts the execution, down the road, on screenplay #1.

 

I will try to confirm (or not) that $0A00-$1600 is being actually cleared by original version, and (if that is true), then current RC-version (modified screen) will need to be patched appropriately.

 

 

Ok, so RC's with modified intro load DIFFERENTLY on >=$0A00 than original title.

 

1. When original title (blue/purple) shows up for the FIRST time, >=$0A00 is CLEAR while screen is on and music begins. Then music jingle runs loops for a total of TWO times, and then a "warm" reset follows, with intro-screen showing AGAIN, and then a whole bunch of code appears on >=$0A00. From this point on, RESET key is trapped! You press it, and you return to intro screen.

 

2. With modified title screen, as soon as title screen shows up for FIRST time, >=$0A00 goes from clear to filled with code, immediately. From this point on, the main-game screen follows, but RESET is NOT trapped. 

 

It is possible that the problem is rooted at that particular difference. Something is wrong with the initialization sequence of the revised title screen. It needs to mimic or follow the original one.

 

 

Edited by Faicuai
Link to comment
Share on other sites

For what it's worth, RC9 with titlescreen works loaded from SIO2PC-USB and AVGCart.

First game's screen is black with AVGCart using Side2 loader.

 

I noticed that if you keep pressed start key on title screen, the game is freezed.

When you release start key, selection screen appears. 

Link to comment
Share on other sites

 

1 hour ago, flashjazzcat said:

Weird. Original (1984), RC8, RC9 and RC9 with new title screen all crash for me 100 per cent of the time on real hardware (U1MB/SIDE2) with the FMS enabled. All work with the FMS turned off. No crash observable in emulation.

 

Regarding segments: solid blocks of code and data will not be a problem, but addresses outside of the segments may be used for data. If that data isn't explicitly initialised before use, problems ensue.

 

Hypothetical example: there's a gap between $7BFF and $7C18. The two separate segments could have been caused by one or more '.DS' pseudo-ops in the source code. The contents of that memory are entirely unknown at load time, strictly speaking. Of course that particular area will be cleared regardless, but the only reason the loader clears any RAM at all prior to loading an XEX is to account for programs which neglect to initialise memory to known values.

 

I just remembered that BL had several protection routines that could crash the Atari if certain conditions were not met.

 

For example there is a test that if activated turns the first level into this:

 

image.thumb.png.6c218acdc7d95256935767ba4d9cbed2.png

 

 

(It reminds me of something ?)

 

Here is the code of this routine:

 

L30A9:     lda #$00
           tay
L30AC:      eor L06F3,Y                ; watch out, this is a code loc
            iny
            bne L30AC
            cmp #$62
            bne L30B7            ;If computed values is not #$62 then branch and program will crash
            rts

;Intentionally crash computer    - Should be removed at some point      
L30B7:      ldx #$FF    
            asl L30C4            ;Is changing address L30C4 below
            lsr L0101,X
            lsr L0117,X
            ldx HOLDCH
L30C4:      .byte $4D,$40        ;TXS - ASL L30C4 from above changes this at run time

                

 

So if something changes the memory range 0x6F3..., the Atari crashes...

 

Couldn't the FMS do that?

 

 

Link to comment
Share on other sites

36 minutes ago, fantômas said:

 

 

I just remembered that BL had several protection routines that could crash the Atari if certain conditions were not met.

 

For example there is a test that if activated turns the first level into this:

 

image.thumb.png.6c218acdc7d95256935767ba4d9cbed2.png

 

 

(It reminds me of something ?)

 

Here is the code of this routine:

 

L30A9:     lda #$00
           tay
L30AC:      eor L06F3,Y                ; watch out, this is a code loc
            iny
            bne L30AC
            cmp #$62
            bne L30B7            ;If computed values is not #$62 then branch and program will crash
            rts

;Intentionally crash computer    - Should be removed at some point      
L30B7:      ldx #$FF    
            asl L30C4            ;Is changing address L30C4 below
            lsr L0101,X
            lsr L0117,X
            ldx HOLDCH
L30C4:      .byte $4D,$40        ;TXS - ASL L30C4 from above changes this at run time

                

 

So if something changes the memory range 0x6F3..., the Atari crashes...

 

Couldn't the FMS do that?

 

 

FYI:

 

NO problems with SIDE-Loader's FMS enabled, for ORIGINAL intro screen (e.g. RC7 works perfectly).

 

As soon as the new intro appears on the RC-build, the load with FMS fails. The problem is rooted at the new intro-screen, as the FMS presence just reveals it.

Link to comment
Share on other sites

43 minutes ago, fantômas said:

Couldn't the FMS do that?

The loop EORs a whole page starting at that address, so will be affected by the loader module itself. It's surprising the game loads at all from the loader or DOS if it screws around with RAM in this region (unless bytes aren't written to this area until the load has completed).

 

For info, before loading anything, the loader zeros page 6 entirely.

Edited by flashjazzcat
Link to comment
Share on other sites

2 hours ago, Faicuai said:

Ok, so RC's with modified intro load DIFFERENTLY on >=$0A00 than original title.

 

1. When original title (blue/purple) shows up for the FIRST time, >=$0A00 is CLEAR while screen is on and music begins. Then music jingle runs loops for a total of TWO times, and then a "warm" reset follows, with intro-screen showing AGAIN, and then a whole bunch of code appears on >=$0A00. From this point on, RESET key is trapped! You press it, and you return to intro screen.

 

2. With modified title screen, as soon as title screen shows up for FIRST time, >=$0A00 goes from clear to filled with code, immediately. From this point on, the main-game screen follows, but RESET is NOT trapped. 

 

It is possible that the problem is rooted at that particular difference. Something is wrong with the initialization sequence of the revised title screen. It needs to mimic or follow the original one.

 

 

Thank you for the investigation! I think that it is the warm reset that makes the difference..... But I hate to have to do this to make it work....

Link to comment
Share on other sites

27 minutes ago, flashjazzcat said:

The loop EORs a whole page starting at that address, so will be affected by the loader module itself. It's surprising the game loads at all from the loader or DOS if it screws around with RAM in this region (unless bytes aren't written to this area until the load has completed).

 

For info, before loading anything, the loader zeros page 6 entirely.

But after the program has been loaded and started, I suppose you can have all the memory (the memory area 0x0418-0x1FFF is overwritten after the game starts)? 

My hypothesis is that something changes the memory after the program starts, which activates the protection routines.... This something, however, would not survive a warm reset, which makes the RC7 works.

Well, that sounds a little twisted... maybe I'm completely wrong ?.

 

I modified the xex to disable this protection routine.

RC9 One Protection Disabled.xex

Link to comment
Share on other sites

1 hour ago, fantômas said:

But after the program has been loaded and started, I suppose you can have all the memory (the memory area 0x0418-0x1FFF is overwritten after the game starts)? 

My hypothesis is that something changes the memory after the program starts, which activates the protection routines.... This something, however, would not survive a warm reset, which makes the RC7 works.

Well, that sounds a little twisted... maybe I'm completely wrong ?.

 

I modified the xex to disable this protection routine.

RC9 One Protection Disabled.xex 40.7 kB · 2 downloads

 

Copied this file (RC9) into a Atari-DOS 2.5 formatted disk (bootable), where I successfully tested RC7, initially.

 

Now, RC9 above fails, does not work (fails on the exact same spot as others, exact same corrupted screen...).

 

(EDIT 9:31pm EST): ALL of the latest RC9 versions fail with FMS=ON on Side Loader, INCLUDING the old-title version). RC7 continues to work perfectly with our without FMS (but its load sequence / process is different, and there is a warm-reset at the intro-screen, with trapped-reset).

 

I would suggest for now (if possible) rolling back to prior RC9 version, and settle on two versions (while more time can be devoted to track this issue):

 

1. RC9.a: modified intro screen that will run with SIDE-Loader (FMS=off. Please, fix NTSC's HULK-like 0F-hue on Bruce's face and left-side hatch)

2. RC9.b: same as above but with original title screen with trapped-reset (which does not fail on SIDE-Loader, no matter what you enable or disable). 

 

It is possible we may not be able to overcome the issue without a much deeper (and time-consuming) code/runtime inspection.

 

Either way, FANTASTIC work, guys!

Edited by Faicuai
Link to comment
Share on other sites

I realized that I just had to update my SIDE2 cartridge to be able to test myself!

 

What I did

 

... and in fact the crash was caused by the protection routines

 

... so I desactived them. 

 

@flashjazzcat Thank you very much!

@Faicuai Thank you very much! I'll try to fix the NTSC color problem.

@Others Thank you very much for testing. We need you!

 

Bruce Lee RC 10.xex

  • Like 9
Link to comment
Share on other sites

1 hour ago, fantômas said:

I realized that I just had to update my SIDE2 cartridge to be able to test myself!

 

What I did

 

... and in fact the crash was caused by the protection routines

 

... so I desactived them. 

 

@flashjazzcat Thank you very much!

@Faicuai Thank you very much! I'll try to fix the NTSC color problem.

@Others Thank you very much for testing. We need you!

 

Bruce Lee RC 10.xex 40.7 kB · 6 downloads

Sweet!!! 

 

It works! (WITH or WITHOUT FMS enabled on SIDE-Loader, either way!) Looking good!

 

As for NTSC color-fix, try the same color used on Bruce Lee's sprite (flesh), for Bruce's face on Intro skin. For your reference, I am attaching a direct screen capture from live system, rendering ACP calibration (notice that F-hue band is not suitable for skin-tones, on modern NTSC rendering...)

 

0A69B9D5-0DED-4C99-BF60-42B1E1B2DAC6.thumb.jpeg.4aceb54d616435c0ca8d38f76ad1f1a6.jpeg

 

To render Atari color palette (and a FULL 256 colors of it), on modern NTSC color-decode, it is absolutely essential to naiil Hue-01 band, and then Hue-0A band. That involves a concerted effort between your video-processing path (whatever it is) and the GTIA's color-pot.

 

Once you reach good 01 & 0A rendition, MOST colors will fall into place, and error will be shifted (and minimized) to 0F region. Out of the box, 0F would be mostly green and 01 like yellow-green (NOT gold), on today's NTSC, though...

 

Cheers!

Edited by Faicuai
  • Like 2
Link to comment
Share on other sites

Regarding screen's version, I have a doubt. Perhaps release year should remain.

 

Copyright2.png.724dde5d7c9da3bbda8717554b9d6c44.png Copyright.png.81963ef7071ac1bc3542f6cc0ed7642c.png

 

For example

BRUCE LEE (C) 1984 DATASOFT SPRITES BY TIX

or

BRUCE LEE (C) DATASOFT 2019 SPRITES BY TIX

or 

(C) 1984 DATASOFT - 2019 SPRITES BY TIX

or

BL (C) 1984 DATASOFT - 2019 SPRITES BY TIX

  • Like 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...