repetto74 Posted June 5, 2017 Share Posted June 5, 2017 Hi folks, I have started some ML coding with the ATARI XL (using for the moment the Altirra emulator). I can save source codes with a SAVE #D:name.m65 command and working ok but I do not know how to save the object code once assembled. Have read ATARI Roots which gives a command like BSAVE #D:name.obj<startaddress,endaddress but this is not working for me. I mean I do see a file saved on the disk but I do not know how to call it back (always getting a file error). Any idea? Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted June 5, 2017 Share Posted June 5, 2017 ASM,,#D:filename.xex creates an object file directly use ASM,#- first to test the assembly code The Mac/65 manual Is here somewhere too, I linked it on another post recently Quote Link to comment Share on other sites More sharing options...
luckybuck Posted June 5, 2017 Share Posted June 5, 2017 You will find everything(!) concerning MAC/65 here: https://atariwiki.org/wiki/Wiki.jsp?page=Articles under Assembler, when the Wiki is online again, including source code. 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 6, 2017 Share Posted June 6, 2017 Better off assembling to disk, relying on a memory copy could allow inadvertant corruption. You'd probably need to manually provide Init/Run address within the program itself, so in the source you'd need: *=$2E0 .WORD INITADR for each section where an init takes place during loading. *=$2E2 .WORD RUNADR to provide a run address for the program. Quote Link to comment Share on other sites More sharing options...
repetto74 Posted June 6, 2017 Author Share Posted June 6, 2017 Hi guys Thanks a lot then I will have a look to the manual :-) By the way which Mac65 version do you suggest ? I am actually using the rom image of version 1.01. Quote Link to comment Share on other sites More sharing options...
vitoco Posted June 6, 2017 Share Posted June 6, 2017 You'd probably need to manually provide Init/Run address within the program itself, so in the source you'd need: *=$2E0 .WORD INITADR for each section where an init takes place during loading. *=$2E2 .WORD RUNADR to provide a run address for the program. Oops! Addresses are swapped... RUNAD is $02E0 INITAD is $02E2 Also, Mac/65 saves chuncks of object code. I don't remember if the chunck has a max length of 252 or 256 bytes each. Each chunk has a 4 byte header with binary pointers (loading addresses). So, don't expect a continuous block of program if you analize the resulting binary using an Hex editor. That's OK! Quote Link to comment Share on other sites More sharing options...
Rybags Posted June 8, 2017 Share Posted June 8, 2017 I didn't realise that it also does it, Atari's AsmEd cart does it and I found it annoying enough to just manually do the BSave. The problem is that the segment length is probably not known until the second assembly pass hits it and to do proper segments the whole thing would have to be buffered in Ram which isn't possible in a lot of cases. Quote Link to comment Share on other sites More sharing options...
pirx Posted June 8, 2017 Share Posted June 8, 2017 before we had STs and did our own, MAC65 compatible crossassembler (OMC65) all our prods were done with MAC65 and this was really annoying, so I did a little utility "demacer" that was cleaning the object file (had also option to skip zeroes). too bad it got lost, but i'm sure someone else did something like this as well. 1 Quote Link to comment Share on other sites More sharing options...
+David_P Posted June 8, 2017 Share Posted June 8, 2017 ANALOG had a program called Streamliner that did the same thing. 3 Quote Link to comment Share on other sites More sharing options...
1050 Posted June 8, 2017 Share Posted June 8, 2017 I've renamed it to liner here for this offering. Main beef I have with it is that it only allows D1: to D1: work and no way to escape it or return to DOS short of a power down. Antagonistic doesn't even come close to a proper description as to ease of use for this one. But it does do the job. Liner.zip If memory serves the last program I was working on was my memory tester EXTEST upgraded for RAMBO type and all others such that the base ram was preloaded with mem test bytes so that those memory upgrades that use their memory for 0x0000 thru 0xFFFF don't have those banks counted as usable extended memory banks. At any rate it's on the disk too, free of charge. 1.01 works fine and not even sure of the benefits of 1.02 in comparison. 4 Quote Link to comment Share on other sites More sharing options...
repetto74 Posted June 10, 2017 Author Share Posted June 10, 2017 Hi guys, For some reasons the command BSAVE #D:name.obj<startaddress,endaddress I was typing was not correct and now after another try it looks good :-) Quote Link to comment Share on other sites More sharing options...
luckybuck Posted June 12, 2017 Share Posted June 12, 2017 https://atariwiki.org/wiki/Wiki.jsp?page=Mac65 Will answer all questions regarding MAC/65. 1.02 cart fixes a bug in the compiler. But it is hard to come to that bug... 3.6 is the best version, of course. Enjoy. Quote Link to comment Share on other sites More sharing options...
Alfred Posted February 4, 2019 Share Posted February 4, 2019 ANALOG had a program called Streamliner that did the same thing. Here's another one that I've used since the beginning. Don't know where I got it, but it works, and for all drive numbers. Just rename to to a .COM. UNI.obj 3 Quote Link to comment Share on other sites More sharing options...
+MrFish Posted February 13, 2019 Share Posted February 13, 2019 3.6 is the best version, of course. Has this been tested much? What are the the differences/improvements? Quote Link to comment Share on other sites More sharing options...
luckybuck Posted February 13, 2019 Share Posted February 13, 2019 (edited) To be honest, I have not tested it yet. It is just because of the number and it was developed years later. Therefore, I assume, because there was no higher version, that this must be the best version. This includes illegal opcodes. I suggest to just compare the source codes against each other. Regarding 1.01 and 1.02 there are just a few bytes... Edited February 13, 2019 by luckybuck Quote Link to comment Share on other sites More sharing options...
+MrFish Posted February 13, 2019 Share Posted February 13, 2019 I want believe it's the better version too; but I just wonder, since it was never released, if there are possibly some problems/bugs. I also wonder, since this version is numbered so much higher, that there should be more than a few major changes and what those might be. Obviously some time needs to be spent with it; but I think most serious machine language developers have long since abandoned Mac/65 and any other native assemblers, for anything more than short bits of code and nostalgia. Quote Link to comment Share on other sites More sharing options...
+therealbountybob Posted February 13, 2019 Share Posted February 13, 2019 https://atariwiki.org/wiki/Wiki.jsp?page=Mac65 Will answer all questions regarding MAC/65. 1.02 cart fixes a bug in the compiler. But it is hard to come to that bug... 3.6 is the best version, of course. Enjoy. That wiki page is fantastic, great work Don't suppose anyone can make v3.6 into an ATR so I can try it on the Atari? I want believe it's the better version too; but I just wonder, since it was never released, if there are possibly some problems/bugs. I also wonder, since this version is numbered so much higher, that there should be more than a few major changes and what those might be. Obviously some time needs to be spent with it; but I think most serious machine language developers have long since abandoned Mac/65 and any other native assemblers, for anything more than short bits of code and nostalgia. I'm glad you said "most" as I'm just about to start my 4th MAC/65 game on the Atari Thanks also for those file re-formatter utilities (1050 & Alfred), it's about time I tried them out too. p.s. How's it going repetto? Quote Link to comment Share on other sites More sharing options...
Alfred Posted February 13, 2019 Share Posted February 13, 2019 To be honest, I have not tested it yet. It is just because of the number and it was developed years later. Therefore, I assume, because there was no higher version, that this must be the best version. This includes illegal opcodes. I suggest to just compare the source codes against each other. Regarding 1.01 and 1.02 there are just a few bytes... Since it's a blizzard here today I think I'll have a look. I wasn't really aware of this 3.6, as far as I'm concerned 1.01 was the last real version, and the 1.02 just seems to have some minor changes. I can't imagine what he might have changed in 3.6, because Mac/65 at the 1.01 level was about as good as it gets for an Atari assembler. 1 Quote Link to comment Share on other sites More sharing options...
Alfred Posted February 13, 2019 Share Posted February 13, 2019 Has this been tested much? What are the the differences/improvements? Doesn't seem to be much difference between 3.4 and 3.6 based on the comments. According to the MASTER here is what 3.4/3,6 have as new features: 0450 ; Improvments: Wild cards in FIND/REP 0460 ; Second double qoute not needed 0470 ; SAVE [EOL] saves to previously LOADed filespec 0480 ; Uses extended memory for X-Ref file 0490 ; (can X-Ref only on an 130 XE) 0500 ; Faster Pass1 ASM for Branches, 0510 ; Immediates, & Jsr/Jmp instrs. None of which strikes me as useful; maybe the Save thing might be a bit handy. 1 Quote Link to comment Share on other sites More sharing options...
luckybuck Posted February 14, 2019 Share Posted February 14, 2019 (edited) @Alfred: Thanks for #13, greatly appreciated. Have to look after. @MrFish: #16: Well, it seems, but the 1st version did start in 1982 and final ones in the late 80's, so we have 5 years of development inside. Yes, but as Alfred wrote, Mac/65 was already on the top, there is not much air left at that level... '...I just wonder, since it was never released...', well there were released through AtariAge in the OSS D-Day posts, there are 3 of them. A major upate can be made with Alfred's extracted ACTION!-Editor integrated into the 3.6 version, of course. This should result into 'MAC/65 Ultimate'? With all bibs and fp in a bank switch super card from OSS with 64K? Just loud thinking as for BASIC XE, too. :-) Yes, sure, more and more Atariens are using WUDSN from JAC!, incredible IDE and Job he has done. But for the old ones, like me, coming back to Stephen's work, it just feels so goooood. :-) @therealbountybob: #17: Well, I am not the Wiki, just an author to, searching for more authors, too. The Wiki is at this status, because of Atariens like Alfred and MrFish, besides many thousands other users, who contribute to the Wiki through their work. It is the user's who make the Wiki great and keep it great. It is the old heros, who gave us their work to publish it there and so one. The Wiki is too big for one alone. 'Don't suppose anyone can make v3.6 into an ATR so I can try it on the Atari?' Well, we have BIN and CAR files of the 3.6 version, so why don't copy them to an atr image and start from there? Sure, go ahead with your 5th MAC/65 game, of course. :-) @Alfred: I have made here: https://atariwiki.org/wiki/Wiki.jsp?page=Assemblerin the chapter: 'Overview' an Excel spreadsheet, which compares the Assemblers and the commands. '...I wasn't really aware of this 3.6...' Alfred, you are kidding, aren't you? If not, I can offer you a Skype call, where we synchronize everything. 1.02 was from OSS! There is even a special cart made for this. AtariGeezer has one of them. Hard to get, mostly above 10 rarity... BTW. We (the community) do not just have the latest version of MAC/65, we have everything except this: https://atariwiki.org/wiki/Wiki.jsp?page=Rarity%2010 Very(!) soon, we will have the 'Holy Grail', still working on the hundreds of pages of the manual. That is the most expansive Atari program of all times, showing once and for all, that Atari was not just a 'game' machin, indeed, it was and still is much more! Thank you so much #19, that is of great help for Mac/65 Ultimate! :-))) Edited February 14, 2019 by luckybuck Quote Link to comment Share on other sites More sharing options...
+MrFish Posted February 14, 2019 Share Posted February 14, 2019 (edited) '...I just wonder, since it was never released...', well there were released through AtariAge in the OSS D-Day posts, there are 3 of them. I mean never officially released by OSS (or ICD, if they had rights to these) as commercial products, or product updates. Edited February 14, 2019 by MrFish Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted February 15, 2019 Share Posted February 15, 2019 ASM,,#D:TEST.COM That will produce a binary output file. Quote Link to comment Share on other sites More sharing options...
CJ Atari Posted November 17, 2019 Share Posted November 17, 2019 Hoping someone can help. Recently pulled out my A800, and am using one of thus Ardunio-based disc simulators. My problem is when I'm using MAC65 with a '.INCLUDE' statement - such as 0100 .INCLUDE #D:KERNEL.M65 - my program won't assemble. No object code is produced. The file - KERNEL.M65 - is available on the drive. Any ideas? Many thanks !! Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 17, 2019 Share Posted November 17, 2019 It should work. From the manual, a few things to remember: . it should be a SAVEd source file (tokenized), not a LISTed Ascii one. . you can't have nested .INCLUDEs . don't have a label on the line that has the .INCLUDE Quote Link to comment Share on other sites More sharing options...
Alfred Posted November 17, 2019 Share Posted November 17, 2019 If not assembling to a binary file, don’t forget .OPT OBJ or else you get no object code. 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.