Two Bruce Lee sequels

[fantômas]

 

Holy crap, you have way more patience than I do. That's a lot of typing.

 

In fact is an automatic refactoring . So far, from tables in the xex, I extract src code for

• rooms (levels)
• PMs
• sounds
• fonts
• lanterns

 

I do prefer read code like:

 

room_0

ins 'room-0.rle'

or

sound_0

;AUDFx,AUDCx

dta $4C,$64

dta $4C,$86

or

spr_117

dta 32 ;.....#..

dta 56 ;...###..

than

L3C44: .byte $C5,$C6,$A0,$B0,$C5,$C1,$A0,$F5,$F6,$F7,$A0,$BE,$BF,$18,$A0,$F2

.byte $02,$A0,$B1,$B6,$A0,$20,$62,$CF,$D0,$D4,$C9

 

Most of the sprites align with the one following, but the first few, and a few in the middle, there's a gap of 1-3 bytes between sprites. Is that gap supposed to be there ?

 

For example, SPRX0 ($3D50) ends with a 195 ($C3) in your code, but in the xex there's a second 195.

 

Just wondering.

 

You're right. I will try to understand and fix this.

[fantômas]

 

Yes a repository or some kind of version control would be a good idea. Github or something like that?

 

I think so. You and Dmx did a great job. I now have some knowledge that I can share.

We need to start with a "good binary" as dmx call it, its source code.

I wrote some code to extract data from the Xex that I can share....

Maybe other people will be interested in this work and will want to participate.

Because the A8 now have two versions of Bruce Lee less than the C64, we can not fail!

I now have some knowledge that I can share

[Alfred]

I think the SCREEN1 data block at $9000, the character title screen is wrong. Now that I have the worst bugs out of my assembler, the display is wrong. There's only 37 bytes in each .SBYTE line, and I expect there should be 40. Sitting here counting bytes in the .xex to see what's what.

 

Edit: yes, the offset looks to be wrong. "Datasoft" should be 129 bytes in and it's only 6 instead of 9 on its line.

Edited March 14, 2019 by Alfred

[Alfred]

Ok, here's a corrected screen data block. I think I discovered the problem. For some reason, when you cut & paste this text, Windows truncates the blank lines to 37 characters. I have no idea why it does that.

 

The problem is that this data chunk is too short. It ends just after the "Linda Lee" but it needs 5 more lines to fill the screen. I would hazard a guess that they relied on the machine ram being zero on booting up, so they didn't supply the necessary screen data. So some care needs to be used here. To build a working binary, the screen needs to be padded with the five lines. To compare to the XEX however, you need to leave the five lines out, else you'll get a mismatch.

SCREEN1.TXT

[Mclaneinc]

Wow, this is really taking momentum.....You guys are great...

[Ute]

Created a Sourceforge project here: https://sourceforge.net/projects/bruce-lee-aa/

 

I uploaded BruceLeeXEX.asm. This should be almost identical to what Alfred has so we will all be on the same page.

 

Not sure how everyone would like to create their account. I can give the admin name/password so that anyone who is interested in the project can add a developer account for themselves.

 

I've never used Sourceforge before, but it looks like we can use either Git or SVN, or both?

 

First thing I would like to do is Merge DMX's changes in to the 'trunk' or base or whatever the terminology is for Sourceforge.

[Ute]

Anyway. The first thing to do is to make the code relocatable - all the tables (map data, map properties, text lookup table, colours, map init, exec routines) and self-modifying code + irqs

must be "labeled" properly so that you can move stuff around at will without side-effects. That's a given.

 

This became very apparent last night as I was working on a room editor. I realized that because each room uses RLE , the encoded rooms will all be a different size. This becomes a problem if an edited room is bigger than the original room. Pointing to the new locations would solve this until room 20. Where this would overwrite whatever data is stored after room 20. So I will put the room editor on hold for now.

 

Once everything is relocatable I have a couple of ideas how to overcome the RLE. Most obvious would be store the data for rooms without the RLE, since the program is only 41K for now, we could use extra room. Another possibility would be to turn it back in to an ATR after all changes are done, and it could load a smaller executable once the title screen and music have finished, just like the ATX and ATR do now.

 

Anyway, this is all moot for now. So I'll keep on chugging away at disassembly.

[Alfred]

Well, I'm trying to build my first test binary to compare to the xex but I'm running out of memory, just too many labels (>800 external references). Still some things I can do, so I'm not out yet.

[Alfred]

Almost there.....almost there.....

[Ute]

Almost there.....almost there.....

Could you be talked into coming over to the dark side and using Wudsn, Mads, Dis6502, Altirra, and other various cross compilation tools?

[_The Doctor__]

I think it's a two fold return on this one as he's working on both pieces of software... it's a double success when he nails it down.

[Alfred]

Well I got this far, but my binary doesn't match:

 

ME Ute

 

0400-7C02 0400-7BFF

8000-8896 8000-8899

9000-931F same

A010-BE2F same

02E0-02E1 same

 

So I'm almost caught up to you guys at the starting line, heh.

 

 

[+DjayBee]

Well I got this far, but my binary doesn't match:

 

If you quickly want to see the differences then get Beyond Compare for your PC or Mac and compare the binary(!) memory dumps. Perhaps they are only cases where one assembler used 16-bit values instead of 8-bit. Edited March 15, 2019 by DjayBee

[Mclaneinc]

I'd love one of these as a load screen.....Or a better choice?

 

Thinking o

 

 

 

Given the Atari treatment..

Edited March 15, 2019 by Mclaneinc

[Alfred]

If you quickly want to see the differences then get Beyond Compare for your PC or Mac and compare the binary(!) memory dumps. Perhaps they are only cases where one assembler used 16-bit values instead of 8-bit.

Yeah, that’s my guess too, that I’m missing a single zero page equate and that’s what’s messing it up. Going to be a bitch to find it.

[+Philsan]

Thanks to Rastaconverter we can surely make a nice colorful or grey scale title screen.

 

I don't know, perhaps if we'll convert RoF, perhaps we should be faithful to the original.

[Mclaneinc]

Oh indeed re the main screen, clearly that HAS to be a version of Dmx's work but I was thinking of a load screen...(memory allowing )

[+DjayBee]

Yeah, thats my guess too, that Im missing a single zero page equate and thats whats messing it up. Going to be a bitch to find it.

Do what I proposed. You will see it immediately.

The tool highlights any difference, even SINGLE bytes.

[Alfred]

Do what I proposed. You will see it immediately.

The tool highlights any difference, even SINGLE bytes.

Thats the problem, there will be a bazillion differences. Like LDA $7993 in mine vs $7990 in the xex. The instruction is at the correct address but the target is wrong. So its a false positive. Anyway, Ill see what I can find.

 

Edit: what I need is a mads listing of the assembly; I could find the error fast with that (hint)

Edited March 15, 2019 by Alfred

[Alfred]

Ok problem solved, my binary is now the same as the mads .obx. However, the binary from mads is different than the .xex, in that for some reason there are 3 extra bytes of $00 at $8896. So however the .xex was produced, it just saved a little more of the memory. So to match the .xex one just needs to add a: .BYTE $00,$00,$00 to the end of the music data, and then it should match.

 

Edit: Spoke too soon. While the segments match, there's a few byte diffs. Fixed one, a typo on my part, still some more to go looks like.

Edited March 15, 2019 by Alfred

[Alfred]

Ok, we have a problem. Thanks to BeyondCompare (hot dam Dj, that is a sweet tool, needs porting to the 8 bit though), the dmxbucelee.asm file run through mads does -not- produce a binary that matches the xex. For example,

 

ResetLampsLeft is at $0CDD in the xex but both mads and I put it at $0CC2. So, what to do ? I'm going to poke around some more, try to figure out why they are different.

 

Edit: Wait, I see Ute has moved it, claiming it was duplicate. Let me try swapping it back, cuz the old spot is indeed $0CDD.

 

Edit2: No, that made it worse. I found what's wrong. There's two different ResetLamps and the mads source is wrong. I guess what's happened is somebody did a search and replace xxxxxx with ResetLampsLeft and it's messed up the JSR to the other ResetLampLeft which is about twenty bytes up:

 

ResetLampsLeft : >>> THIS ONE IS $0CC2
ldx #$13
L0CC4: lda L40B1,X
sta ICBLLZ,X
dex
bpl L0CC4
rts

CheckHarderMode:
lda L0085
cmp #$1C
bcs L0CD7
cmp #$15
clv
rts
L0CD7: lda #$FF
bit L0CDC
L0CDC: rts

;ResetLampsLeft: - Duplicate label from DMX
L0CDD: lda CurrentPlayer THIS ONE IS $0CDD.
clc
adc #$26
tax
lda #$01
L0CE5: sta IsMapVisited,X
dex
dex
bpl L0CE5
ldx CurrentPlayer
lda #$00
sta IsMapVisited,X
rts

So I'll have a go at finding the wrong ResetLampsLeft calls and replace them with JSR L0CDD and that should fix that mismatch. Edit3: Yeah, there's no JSR L0CDD in the dmx code, which is the problem.

 

Edit4: We know the xex is the gold master, right ? It works and plays correctly ? I've never actually tried it myself.

Edited March 15, 2019 by Alfred

[dmx]

Oops, sorry, didn't intend my quick'n'dirty search replace job to be actually assembled, only to be used as a reference, but seems you got it right anyway. Nice work!

[Alfred]

Oops, sorry, didn't intend my quick'n'dirty search replace job to be actually assembled, only to be used as a reference, but seems you got it right anyway. Nice work!

 

eh, things happen. BruceComments has the same problem cuz I think he said it's just based on yours, so it doesn't matter, but since I based my build on the dmx version, I'll just fix that up, and deal with the comments later.

 

edit: although really, just looking at the code, L0CDD probably doesn't have anything to do with the lamps, just setting some flags around having visited the room.

 

Edit: Here's the fix:

 

L3948: sta L013C,X

7291 394B E8 inx

7292 394C 88 dey

7293 394D 10 F9 bpl L3948

7294

7295 394F 20 C2 0C jsr ResetLampsLeft

7296 3952 20 17 2B jsr ResetLampsAll

7297 3955 20 C2 0C jsr L0CDD >>> CHANGE THIS

 

 

Edit: looks like the display list for the Lee picture is wrong, there's a three byte offset in the JMP to the top of the display list, mads says $F5, xex says $F8

Edited March 15, 2019 by Alfred

[Alfred]

I guess I'll save up all the changes and post a list, but for now here's the error in the picture part:

 

;Sets Display list to the Bruce Lee picture
SetPic
lda #<Picture
sta SDLSTL
lda #>Picture
>> INSERT MISSING LINE

STA SDLSTH

 

On to the next one

[Alfred]

Ok, so the last couple of errors was me, putting in padding bytes to try and fix previous errors. I now get a perfect match to the xex, so if you make the above changes to the dmx source, mads ought to work out too.