pcrow Posted January 19 Share Posted January 19 I know there are tons of disassemblers out there, but I wanted one that would meet several criteria: Runs on Linux Handles formats of boot sectors and binary load (XEX) files Traces the flow of the code to avoid disassembling data Uses standard labels for known Atari memory locations So I wrote my own. https://github.com/pcrow/atari_8bit_utils/tree/main/disasm It's not too polished. It will behave badly if a binary load file uses an init routine and then overwrites it with new data. It could use some command-line options and help to decode arbitrary blocks of data. But overall, I'm pretty happy with it. I see no reason it wouldn't also work under MacOS, Windows, or pretty much anything else that runs a reasonably standard C environment. 21 2 Quote Link to comment Share on other sites More sharing options...
R0ger Posted January 19 Share Posted January 19 Not that I use linux, but that's the spirit ! 1 Quote Link to comment Share on other sites More sharing options...
baktra Posted January 19 Share Posted January 19 Good luck with the project, of course. When the project matures, bless us, lowly mainstream users, with a documentation and windows binaries. Quote Link to comment Share on other sites More sharing options...
pcrow Posted January 19 Author Share Posted January 19 5 minutes ago, baktra said: Good luck with the project, of course. When the project matures, bless us, lowly mainstream users, with a documentation and windows binaries. I actually don't run Windows, so someone else would have to provide binaries. Right now, you just put a file name on the command line, and if it starts with $FFFF, it parses it as a binary load file, otherwise it parses it as a sequence of boot sectors. Quote Link to comment Share on other sites More sharing options...
woj Posted January 19 Share Posted January 19 2 hours ago, pcrow said: I actually don't run Windows, so someone else would have to provide binaries. We should build a critical mass of non-Windows users and start convincing Avery to make moves towards Altirra running natively on Unix-like systems. I know the discussions about this have been up from time to time, and I know he essentially said no very many times, main reason being Altirra's non-modular architecture when it comes to GUI integration and huge dependency on Windows API, but perhaps that would be a good point to start - making it modular w.r.t. the GUI. 2 2 Quote Link to comment Share on other sites More sharing options...
baktra Posted January 19 Share Posted January 19 25 minutes ago, woj said: We should build a critical mass of non-Windows users and start convincing Avery to make moves towards Altirra running natively on Unix-like systems. I know the discussions about this have been up from time to time, and I know he essentially said no very many times, main reason being Altirra's non-modular architecture when it comes to GUI integration and huge dependency on Windows API, but perhaps that would be a good point to start - making it modular w.r.t. the GUI. Given the market share of the Linux desktop, the critical mass is difficult to achieve. Given what I know how much "joy" phaeron has experienced with Windows multimedia APIs, I wouldn't have high hopes for GNU/Linux version of Altirra. From what I know from game developers in general, multimedia APIs available for Linux are even worse. In any case, in early stages of the development, functions and capabilities are the greatest concerns. Let us deal with portability and collateral items later. 1 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted January 19 Share Posted January 19 Compiles fine under Cygwin 1 Quote Link to comment Share on other sites More sharing options...
invisible kid Posted January 19 Share Posted January 19 Awesome! Built fine, As a quick test I tried it on the xegs rom, but I guess this falls into the "It will behave badly if a binary load file uses an init routine and then overwrites it with new data." $ disasm XeGS.rom BOOT_INI = $0000 BOOT_SECS = $0001 BOOT_ADDR = $0002 Thanks again! Very cool. Quote Link to comment Share on other sites More sharing options...
Mark2008 Posted January 19 Share Posted January 19 5 hours ago, woj said: We should build a critical mass of non-Windows users and start convincing Avery to make moves towards Altirra running natively on Unix-like systems. I know the discussions about this have been up from time to time, and I know he essentially said no very many times, main reason being Altirra's non-modular architecture when it comes to GUI integration and huge dependency on Windows API, but perhaps that would be a good point to start - making it modular w.r.t. the GUI. Doesn't Alitrra run under wine? I do have Altirra on my MacBook, however I am just using windows emulation and the ARM version, but anyway, I was wondering if the Altirra via Wine solution still works, or has some limitations? What would be the advantage to a native port? Quote Link to comment Share on other sites More sharing options...
darwinmac Posted January 19 Share Posted January 19 Yes, Altirra works well under Wine. I run it on my M1 MacBook Air. A native port would have a more native feel. However, Avery uses Windows-specific technologies (e.g. DirectX) extensively. He makes the source code available for anyone who would want to port the code to another OS but, with how often he updates Altirra, it’s not really feasible for someone to take on a port. Since he gives away Altirra for free and he has said on many occasions that he has no interest in posting Altirra to another OS, I would not bother him about it IMHO. Bob C 2 Quote Link to comment Share on other sites More sharing options...
pirx Posted January 19 Share Posted January 19 i concur, using altirra for many years on ubuntu exclusively and white it has got it quirks, the features are all there. at this point the only slight discomfort I have are strange menu colors in my dark system, I am sure it could be configured in wine better, but this is not a blocker at all. Quote Link to comment Share on other sites More sharing options...
pcrow Posted January 19 Author Share Posted January 19 2 hours ago, invisible kid said: Awesome! Built fine, As a quick test I tried it on the xegs rom, but I guess this falls into the "It will behave badly if a binary load file uses an init routine and then overwrites it with new data." $ disasm XeGS.rom BOOT_INI = $0000 BOOT_SECS = $0001 BOOT_ADDR = $0002 Thanks again! Very cool. It's not set up for cartridge ROM files. It's parsing that as boot sectors for a disk image. 1 Quote Link to comment Share on other sites More sharing options...
pcrow Posted January 19 Author Share Posted January 19 1 hour ago, darwinmac said: Yes, Altirra works well under Wine. I run it on my M1 MacBook Air. A native port would have a more native feel. However, Avery uses Windows-specific technologies (e.g. DirectX) extensively. He makes the source code available for anyone who would want to port the code to another OS but, with how often he updates Altirra, it’s not really feasible for someone to take on a port. Since he gives away Altirra for free and he has said on many occasions that he has no interest in posting Altirra to another OS, I would not bother him about it IMHO. While it's frustrating not having the best emulator available, I totally understand the reasons. And if it were ported to Linux, one big benefactor would be Atari in having it for The400 and the like. The right thing would be for them to hire a developer or team to port it, but I just don't see that happening. Quote Link to comment Share on other sites More sharing options...
TGB1718 Posted January 19 Share Posted January 19 It seemed to build Ok using Ubuntu running on Windows (Linux Subsystem for Windows), but the output on the 2 files I tried didn't to work. The first program was a 6K demo which only disassembled about 25 lines of code, the second produces a file about 32K but it was 2820 lines all .byte statements even though I recognised those bytes as hex op codes, see screenshot; Also it produced an error in some code, this is what was disassembled:- INIT1 LDA PORTB ORA #$02 STA PORTB LDA #$01 STA BASICF LDA #$00 TAX L0410 STA LA000,X INX BNE L0410 INC (L0410-2) <<<<<<<<<<<<<<<< this looks wrong LDY (L0410-2) <<<<<<<<<<<<<<<< this too CPY #$C0 BNE L0410 I ran the code through my own disassembler and got this which looks correct 0400 LDA D301 AD 01D3 0403 ORA #02 0902 0405 STA D301 8D 01D3 0408 LDA #01 A901 040A STA 03F8 8D F803 040D LDA #00 A900 040F TAX AA 0410 STA A000,X 9D 00A0 0413 INX E8 0414 BNE FA D0FA 0416 INC 0412 EE 1204 <<<<<<<<<<<<<<<< increments the hi byte which is correct 0419 LDY 0412 AC 1204 041C CPY #C0 C0C0 041E BNE F0 D0F0 Quote Link to comment Share on other sites More sharing options...
pcrow Posted January 19 Author Share Posted January 19 (edited) 16 minutes ago, TGB1718 said: INC (L0410-2) <<<<<<<<<<<<<<<< this looks wrong LDY (L0410-2) <<<<<<<<<<<<<<<< this too That's from my code to handle self-modifying code, where the access needs to be an offset from the label on the instruction. That should be a plus. I just pushed the fix. Thanks for catching that. I also dropped the parentheses. Edited January 19 by pcrow 1 Quote Link to comment Share on other sites More sharing options...
TGB1718 Posted January 19 Share Posted January 19 (edited) 6 minutes ago, pcrow said: Thanks for catching that. No problem, what about the strange disassembly where it's all .byte statements ? This is the same segment from my disassembler:- 3000 LDA #9B A99B 3002 STA CB 85CB 3004 LDA #80 A980 3006 STA CC 85CC 3008 LDX #A5 A2A5 300A LDY #00 A000 300C LDA #07 A907 300E JSR E45C 20 5CE4 3011 LDX #DC A2DC 3013 STX 02C6 8E C602 3016 LDX #02 A202 3018 STX 02C5 8E C502 301B LDX #2A A22A 301D STX 02C4 8E C402 3020 JSR 334C 20 4C33 3023 LDA #00 A900 3025 STA 0230 8D 3002 3028 LDA #33 A933 302A STA 0231 8D 3102 302D JSR 30E0 20 E030 Not sure if it's something to do with having many segments in the file Edited January 19 by TGB1718 Quote Link to comment Share on other sites More sharing options...
pcrow Posted January 19 Author Share Posted January 19 18 minutes ago, TGB1718 said: The first program was a 6K demo which only disassembled about 25 lines of code, the second produces a file about 32K but it was 2820 lines all .byte statements even though I recognised those bytes as hex op codes, see screenshot; It only does boot sectors or XEX files for now. Both specify init and run addresses, so it flags those as being instructions. It disassembles from there, also adding any target of a BRx, JSR, or JMP as an instruction to trace from (but only if that address is also loaded, of course). I don't have any checks for XEX files that have an init routine and then overwrite that; in theory it should stop at an init routine, disassemble, and then continue, producing multiple files of output. Quote Link to comment Share on other sites More sharing options...
pcrow Posted January 19 Author Share Posted January 19 So your non-disassembling program probably doesn't have something to tell my code to start disassembling at 3000, or at least I'm not catching it for some reason. Oh, and it will also stop disassembly if it hits a JAM instruction (undocumented opcodes that lock up the CPU), as that almost certainly indicates that it's tracing through data, which should only happen if a code block ends with a BRx that is always taken. Quote Link to comment Share on other sites More sharing options...
TGB1718 Posted January 19 Share Posted January 19 The file is a .xex, but has loads of segments, probably was assembled with MAC/65 which seems to do this sort of thing. This is the file segment data. Segment 1: Load:3000 End:325D Size:025E Segment 2: Load:3300 End:3351 Size:0052 Segment 3: Load:7400 End:77FF Size:0400 Segment 4: Load:8074 End:8093 Size:0020 Segment 5: Load:80D9 End:80F8 Size:0020 Segment 6: Load:8174 End:8195 Size:0022 Segment 7: Load:81D9 End:81FA Size:0022 Segment 8: Load:8274 End:8292 Size:001F Segment 9: Load:82D9 End:82F7 Size:001F Segment 10: Load:8374 End:8397 Size:0024 Segment 11: Load:83D9 End:83FC Size:0024 Segment 12: Load:8474 End:8494 Size:0021 Segment 13: Load:84D9 End:84F9 Size:0021 Segment 14: Load:8573 End:8597 Size:0025 Segment 15: Load:85D0 End:85F4 Size:0025 Segment 16: Load:8774 End:8796 Size:0023 Segment 17: Load:87D9 End:87FB Size:0023 Segment 18: Load:8874 End:8898 Size:0025 Segment 19: Load:88D9 End:88FD Size:0025 Segment 20: Load:8A74 End:8A90 Size:001D Segment 21: Load:8AD9 End:8AF5 Size:001D Segment 22: Load:8B74 End:8B8B Size:0018 Segment 23: Load:8BD9 End:8BF0 Size:0018 Segment 24: Load:8C74 End:8C7A Size:0007 Segment 25: Load:8CD9 End:8CFE Size:0026 Segment 26: Load:8D74 End:8D97 Size:0024 Segment 27: Load:8DD9 End:8DFC Size:0024 Segment 28: Load:8E74 End:8E98 Size:0025 Segment 29: Load:8ED9 End:8EFD Size:0025 Segment 30: Load:8F74 End:8F94 Size:0021 Segment 31: Load:8FD9 End:8FF9 Size:0021 Segment 32: Load:9074 End:9098 Size:0025 Segment 33: Load:9174 End:9189 Size:0016 Segment 34: Load:91D9 End:91EE Size:0016 Segment 35: Load:9374 End:9398 Size:0025 Segment 36: Load:93D9 End:93FD Size:0025 Segment 37: Load:A500 End:A502 Size:0003 Quote Link to comment Share on other sites More sharing options...
pcrow Posted January 19 Author Share Posted January 19 1 minute ago, TGB1718 said: The file is a .xex, but has loads of segments, probably was assembled with MAC/65 which seems to do this sort of thing. This is the file segment data. That should be fine, but I don't see a run or init address. The code loads all blocks into a 64K character array, and also has an array of flags where it flags which bytes are loaded, branch targets, and instructions. It starts by setting the init addresses and run address as branch targets. It disassembles from anywhere that is flagged as a branch target but not an instruction. That may be too much on the internal details, but the essence is that it assumes everything is data unless it can find a way for the code to get there. The only big hole that I can see is if you store the address of a routine in an interrupt vector, my code won't recognize that as an entry point. Quote Link to comment Share on other sites More sharing options...
TGB1718 Posted January 19 Share Posted January 19 43 minutes ago, pcrow said: That should be fine, but I don't see a run or init address. Yes, I hadn't looked that closely, so it's running from the load address, couldn't you factor that in if there's no init/run address by setting the run address to the load address in this sort of instance ? I've just tried with a program I've written in MADS, I don't have an init/run address, and again it just produces all .byte instructions Quote Link to comment Share on other sites More sharing options...
TGB1718 Posted January 19 Share Posted January 19 1 hour ago, pcrow said: I also dropped the parentheses. Still has parenthesis on some instructions:- L042B STA (IOCB0+2) LDA #$3D STA (IOCB0+4) LDA #$04 STA (IOCB0+5) LDX #$00 JMP CIOV Quote Link to comment Share on other sites More sharing options...
pcrow Posted January 19 Author Share Posted January 19 I just fixed the parentheses. I also added a "--start=xxxx" option that can add a start address if your EXE file doesn't have one. You can repeat the option as many times as you like for multiple start points. Quote Link to comment Share on other sites More sharing options...
+DjayBee Posted January 19 Share Posted January 19 34 minutes ago, TGB1718 said: Still has parenthesis on some instructions:- L042B STA (IOCB0+2) If your target is MADS (dunno other assemblers' syntax), you can use square brackets for calculations. This way it stays very visible that you did calculate something. L042B STA [IOCB0+2] Quote Link to comment Share on other sites More sharing options...
pcrow Posted January 19 Author Share Posted January 19 3 minutes ago, DjayBee said: If your target is MADS (dunno other assemblers' syntax), you can use square brackets for calculations. This way it stays very visible that you did calculate something. I think I'll just leave them off entirely, as that should work with any assembler. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.