fantômas Posted March 13, 2019 Share Posted March 13, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
fantômas Posted March 13, 2019 Share Posted March 13, 2019 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 6 Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 14, 2019 Share Posted March 14, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 14, 2019 Share Posted March 14, 2019 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 1 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted March 14, 2019 Share Posted March 14, 2019 Wow, this is really taking momentum.....You guys are great... Quote Link to comment Share on other sites More sharing options...
Ute Posted March 14, 2019 Share Posted March 14, 2019 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. 4 Quote Link to comment Share on other sites More sharing options...
Ute Posted March 14, 2019 Share Posted March 14, 2019 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. Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 14, 2019 Share Posted March 14, 2019 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. Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 15, 2019 Share Posted March 15, 2019 Almost there.....almost there..... Quote Link to comment Share on other sites More sharing options...
Ute Posted March 15, 2019 Share Posted March 15, 2019 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? 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 15, 2019 Share Posted March 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 15, 2019 Share Posted March 15, 2019 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. 2 Quote Link to comment Share on other sites More sharing options...
+DjayBee Posted March 15, 2019 Share Posted March 15, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted March 15, 2019 Share Posted March 15, 2019 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 15, 2019 Share Posted March 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
+Philsan Posted March 15, 2019 Author Share Posted March 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted March 15, 2019 Share Posted March 15, 2019 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 ) Quote Link to comment Share on other sites More sharing options...
+DjayBee Posted March 15, 2019 Share Posted March 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 15, 2019 Share Posted March 15, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 15, 2019 Share Posted March 15, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 15, 2019 Share Posted March 15, 2019 (edited) 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 #$13L0CC4: lda L40B1,X sta ICBLLZ,X dex bpl L0CC4 rts CheckHarderMode: lda L0085 cmp #$1C bcs L0CD7 cmp #$15 clv rtsL0CD7: lda #$FF bit L0CDCL0CDC: rts;ResetLampsLeft: - Duplicate label from DMX L0CDD: lda CurrentPlayer THIS ONE IS $0CDD. clc adc #$26 tax lda #$01L0CE5: 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 2 Quote Link to comment Share on other sites More sharing options...
dmx Posted March 15, 2019 Share Posted March 15, 2019 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! Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 15, 2019 Share Posted March 15, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 15, 2019 Share Posted March 15, 2019 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 Quote Link to comment Share on other sites More sharing options...
Alfred Posted March 15, 2019 Share Posted March 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.