Jump to content

Recommended Posts

Tonight I finished merging DMX's commented file and my own, and uploaded it to Sourceforge.

 

Fantomas, I hope you don't mind I uploaded your files as well.

 

I would like to upload these pictures too if the authors don't mind(Philsan, emkay, and others.)

 

Jose, you have some nice screens in the other Bruce Lee thread, would you mind if I uploaded those?

Edited by Ute

 

I would like to upload these pictures too if the authors don't mind(Philsan, emkay, and others.)

 

No problems, thanks.

But please wait my final Bruce Lee conversion, with left eye fixed.

If my image will be used for the game, I would need to make a NTSC version.

Loving the screen Philsan......Oh, just noticed Emkays one, yeah, very nice too.I do hope one of these gets used , as said memory allowing just an an intermission load screen, it can be removed after a while and memory recovered..

Edited by Mclaneinc
  • Like 1

baseline is still wrong, you forgot to change the lamps thing:

 

After label L3948

7295 394F 20 C2 0C jsr ResetLampsLeft
7296 3952 20 17 2B jsr ResetLampsAll
7297 3955 20 C2 0C jsr ResetLampsLeft >>>> change to jsr L0CDD

 

and then it matches the xex.

  • Like 1

The Load screen/ intermisssion and outtro/success screen is something that is forgotten on games it would be interesting....as a reward when you complete the game whatever screen not used could be displayed or loaded from disk after the congratulations or final score when you are done playing/leaving the game... more Bruce Lee sketches and pics you can't go wrong :)

Edited by _The Doctor__
  • Like 3

Tonight I finished merging DMX's commented file and my own, and uploaded it to Sourceforge.

 

 

 

Great job!!

 

I merged the SourceForce version and mine . Produces the same Xex than the SourceForge file. Big big file included. Time to split src?

And how can we share the work?

 

 

Edit: wrong file. fixed.

incbin.zip

BruceLeeData.asm

Edited by fantômas
  • Like 1

 

Great job!!

 

I merged the SourceForce version and mine . Produces the same Xex than the SourceForge file. Big big file included. Time to split src?

And how can we share the work?

 

 

Edit: wrong file. fixed.

 

Same problem, L0CDD is missing.

 

This construct looks odd:

 

Map18Exec: lda MapVar1

bne L3406

jmp UpdateEmperor

L3406: lda Map18Lamps+0*4

 

 

plus zero times four ? that's zero, so why even put that there ? Another automated tool I guess

 

Anyway I might be busted out at this point, with all these new names I can't build a binary yet, and I don't feel like doing the work needed to fix it..

After label L3948

7295 394F 20 C2 0C jsr ResetLampsLeft

7296 3952 20 17 2B jsr ResetLampsAll

7297 3955 20 C2 0C jsr ResetLampsLeft >>>> change to jsr L0CDD

 

Sorry Alfred I didn't have time to respond yesterday.

 

I changed L0CDD to something more meaningful: ResetRoomsVisited, then called called from above code.

 

 

I merged the SourceForce version and mine . Produces the same Xex than the SourceForge file. Big big file included. Time to split src?

And how can we share the work?

 

 

Fantomas that's great.

 

I agree we should start splitting the source code in to meaningful files or logical partitions.

 

I'm going to upload the new baseline with Alfred's fixed part.

 

Then I think we should start using forks or branches on Sourceforge. We can then work independently from each other and merge whenever we need also independently from each other.

 

I would like to start working on the screen editor again now that Fantomas has made the map screen data relocatable. I welcome any help.

 

More importantly, I hope everyone who is interested in working on this project feels like they have a voice and feels included. :) I haven't seen anyone take a fork yet from Sourceforge.

Edited by Ute
  • Like 1

Well I just pull the .asm from sourceforge, without forking or whatever.

 

Anyway, I finished importing fantomas' excellent work, but I've made a mistake somewhere because now I'm about 50 bytes short, sigh. Anyway, while I was fixing things, I decoded this at $3E3E:

 

L3E3E LDX #$05
L3E40 LDA $CFFA,X
CMP $FFFA,X
BNE L3E62
DEX
L3E49 BPL L3E40
LDX #$14
L3E4D LDA L3F2A+1,X
STA CURPLYR+1
LDA L3F40,X ; RLE TABLE
L3E55 STA CURPLYR+2
DEC CURPLYR+2
LDY #$FF
LDA #$7F
STA (CURPLYR+1),Y
DEX
BNE L3E4D
L3E62 RTS

 

Not too sure what's going on there. I see it gets called from a couple of places in the mainline.

  • Like 1

Ok, all caught up, my binary now matches the xex again. I missed that fantomas made a change in the MapColors table from his original post.

 

As for splitting up the files, just as a point of reference, here's what my directory looks like. You can infer the code locations from the file names. I've had to break some of them, like the MAPEXECS due to size, and I might split them up more into each individual exec and/or init routine once we're done parsing the data tables and such.

 

I also changed the block in $7800 to just .BYTE since all the labels were pushing me over the limit and none of them are used, since it's all junk and not real code, at least that we know of so far. So here's my copy, in case you want to replace the crap in your baseline copy.

 

 

post-7980-0-37507800-1552784126.jpg

PAGE782.txt

  • Like 5

Just working through the startup, some odd things. Like what is it with this LFFFB address ? Why compare it to $CFFFA ? At first I thought it was some kind of protection, now I'm starting to think this is code that the game modifies on the fly.

 

Something I'm missing about InitLamps too, at L2ADA. It checks the first byte and if it's NZ then it skips setting the lamps. Huh ? Every lamp table for each room has $01 as the first byte, so it never stores lamp chars. Must be modified on the fly again, it makes no sense why the routine is there if it doesn't work. Character $86 seems to have some special significance, every line starts with four of them, and ends with them as well. Overscan ? Dunno. The DecodeMap seems unnecessarily complicated.

The game at playing area scanlines is for sure in 48Bytes wide mode because PF3 is black and used as 5th Player 4Missiles on the Ninja.

 

Edited: 4 at left and 4 on right sides with char $86 is an all black PF3 one, isn't it?

Edited by José Pereira

Just working through the startup, some odd things. Like what is it with this LFFFB address ? Why compare it to $CFFFA ? At first I thought it was some kind of protection, now I'm starting to think this is code that the game modifies on the fly.

 

Something I'm missing about InitLamps too, at L2ADA. It checks the first byte and if it's NZ then it skips setting the lamps. Huh ? Every lamp table for each room has $01 as the first byte, so it never stores lamp chars. Must be modified on the fly again, it makes no sense why the routine is there if it doesn't work. Character $86 seems to have some special significance, every line starts with four of them, and ends with them as well. Overscan ? Dunno. The DecodeMap seems unnecessarily complicated.

 

You're right, I missed that hidden code when I decoded data.

 

L3E3E ldx #$05
L3E40 lda $CFFA,X
cmp $FFFA,X
bne L3E62
dex
L3E49 bpl L3E40
ldx #$14
L3E4D lda MapDataLo,X
sta $13
lda MapDataHi,X
L3E55 sta $14
dec $14
ldy #$FF
lda #$7F
sta ($13),Y
dex
bne L3E4D
L3E62 rts
Like you, I thing that this is some king of protection that corrupts the maps in certain circumstances , eg a special cartridge connected?
DecodeMap : The lines of the maps are 40 bytes long, but the display is in antic mode 'Wide playfield' (48 bytes per lines), so eight $86 (4 left, 4 right) are inserted for each line during the decoding. Why $86? I don't know...
Lamp table: Look at L2AC2:
L2AC2: dey
dey
dey
lda #$00
sta (DSKFMS+1),Y ;And store 0, for a removed lamp
rts
  • Like 2

$86 is for sure a full black (PF3) char. That's the reason why 4 at each side so that playing area is 40Bytes wide.

It 'fools' people with black on the sides and the only way he got that aren't BAK but indeed PF3 colour register.

Well I just checked and both the XL/XE OS Rom and the 800 OS B rom are different at the $CFFA, so they pass the test. I suppose he's looking for a custom OS, one where for some reason the few bytes at $CFFA are the same as $FFFA. Looks like it corrupts the maps around room 7 or so, so he fiendishly let's you play for a while and then, blam!.

 

Ok, the 48 byte wide playfield make it make sense then, I was just looking at the Antic $05 and thinking 40 bytes per line. I still don't get the lamps test though. It's the exact opposite of what you'd expect, it should be BEQ to skip the removed lamps, not BNE. I guess I need to take a look at the master VBI, I think it did some odd things.

 

 

$86 is for sure a full black (PF3) char. That's the reason why 4 at each side so that playing area is 40Bytes wide.
It 'fools' people with black on the sides and the only way he got that aren't BAK but indeed PF3 colour register.

 

Ok, that's good to know thanks. I don't really have a good understand of the intricacies of the graphics hardware. Like I don't quite get how that title screen works, it's some trick with VSCROL while it tinkers with the character set. So you guys will have to explain things to me slowly, with words of one syllable ;) .

What title screen, the one with Bruce?

It's what I said. It hasn't tricks, DLIs,... nothing, a simple GR.15 Bitmap mode in 4colours so that it can be seen while the main game loads.

But black isn't BAK (712) but PF0 or PF1 or PF2 (708 or 709 or 710).

The BAK on the code is the dark blue so if you on your code have it black you have 2x black + 2colours and all dark blue pixe now black that is why you lack some detaits.

Get it?

:thumbsup:

Edited by José Pereira

No, not Bruce, the character screen at $9000, TM Linda Lee, etc. It goes by so fast I can't see it, but I think it looks like the characters are rising up from the ground or something.

 

Edit: The very first screen the game displays.

Edited by Alfred

It scrolls a single line and copies one byte for each character into the character set at a time. So the Atari can only draw part of each character. When its time to scroll again, another byte has been copied to the character set and so a little more appears. Repeats this until all of the character set has been copied.

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