+FALCOR4 Posted January 8, 2021 Share Posted January 8, 2021 I was cleaning up my desk at work today and came across this cartoon a friend of mine gave me years ago after discovering I enjoyed programming assembly language on the TI. It was in fun and I certainly didn't take any offense but it got me thinking about structure in assembly language programming. So, do we have examples of what "good" assembly language programming looks like? And, why is it "good?" If you do, I'd love to see it and hear your philosophies about it. 2 1 2 Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted January 8, 2021 Share Posted January 8, 2021 It has to be the F'WEB package, The code is compact, efficient, and all of the parts fit flawlessly together. Quote Link to comment Share on other sites More sharing options...
GDMike Posted January 8, 2021 Share Posted January 8, 2021 Explorer or probably any of the FORTH packages I'd assume are probably pretty tight. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted January 8, 2021 Share Posted January 8, 2021 XKCD says it all. . .but I really have no idea what the best TI code would look like. I am personally much more focused on what the code actually does and how well it performs that function. Seen from that angle, there is an awful lot of "best" code out there. Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 8, 2021 Share Posted January 8, 2021 Just comment it. Uncommented assembly code might as well be Martian. Even if you can tell what he's saying, you've no idea what he's talking about. Avoiding fancy tricks, break the code up into functions... nothing so different from what makes any other code good. It ultimately depends on what your goal is - if you want other people to read it, code like you mean it. 5 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted January 8, 2021 Share Posted January 8, 2021 On 1/7/2021 at 8:43 PM, Tursi said: Just comment it. Uncommented assembly code might as well be Martian. An especially frustrating example of non-commented Martian-Assembly is the Boone MBX code. Help @Tursi if you get bored and need a new TI project Quote Link to comment Share on other sites More sharing options...
+acadiel Posted January 8, 2021 Share Posted January 8, 2021 @Tursi's Multicart code. Bar none, some of the most impressive assembly work to this day that I've seen. Simple, concise, and works extremely well. The code scans all 8K banks on a bank switched ROM within the console's 256 bytes of scratchpad RAM, generates a menu on the fly, and then launches the ROM. No 32K Expansion required. Also, had a super cool font. Completely blew me away on how he accomplished it, and still impresses me to this day. 3 Quote Link to comment Share on other sites More sharing options...
+9640News Posted January 8, 2021 Share Posted January 8, 2021 Well, very few people have looked at the code for MDOS, however in my opinion, it is probably one of the finest examples out there. Until you really start digging into it, and boy do you have to dig into it, but it is truly amazing everything that is in the code. The code requires approximately 22 x 8K pages of memory with 6 memory overlays of extended libraries that can talk to the other libraries, a "Shell" called the Command Line Interpreter or MDOS prompt that can do just about any disk management feature one can imagine, and supports TI/Myarc/CC FDC's, RS232's, a SCSI card, and soon to be released IDE and TIPI cards as well. Some of the code can be difficult to follow as there is so much memory paging involved and several examples of various object files using the same label code in their sources that can be confusing, however, IT WORKS, and it works well. It has a single DSR while in "TI-99/4A mode" that pretty much if you can plug it into the PEBox, it will talk to it with very few exceptions of incompatible hardware. That same DSR is smart enough to know whether you are calling it from TI-99/4A mode, or MDOS mode. And in MDOS mode it can really unleash its power. Imagine in about 5 lines of code, being able to change to any of the text or graphic modes, load or save a file, or call any of a hundred or more routines without adding all the extra VMBW, VSBR, DSRLNK, etc. code to your source. If you want to write text to a graphics screen, you don't need to figure out the character pattern and where to write each pixel. You just give it the string and call the library function and MDOS does it for you. If anyone ever wanted to learn assembly language, I would tell them to start off with programming in MDOS mode on the Geneve as those XOP (library) calls gets you well on your way with minimal effort as you learn more about assembly. Anyways, my 2 cents. Am I a bit biased, perhaps <grin>. Beery 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 8, 2021 Share Posted January 8, 2021 One of the most impressive pieces of code that I saw was Thierry's bootstrap code for his IDE card, using the NVRAM of the real-time clock RTC-65271. The RAM of the clock is organized as 128 pages of 32 bytes, so you really cannot write longer sequences of code, and you always have to map into the next page. Nevertheless, he managed to install a bootloader from several of these 32-byte pages into main memory which downloaded a second-stage bootloader, which in turn pulled the DSR from the IDE drive into the IDE DSR space, and then comes the Master title screen. By that concept, the IDE card does not need any EPROM or FlashROM. See also this posting: 2 Quote Link to comment Share on other sites More sharing options...
+dhe Posted January 9, 2021 Share Posted January 9, 2021 On 1/8/2021 at 12:34 AM, Airshack said: An especially frustrating example of non-commented Martian-Assembly is the Boone MBX code. Help @Tursi if you get bored and need a new TI project You obviously have not tried his archiver code! ? Quote Link to comment Share on other sites More sharing options...
+dhe Posted January 9, 2021 Share Posted January 9, 2021 Two examples of very read-able code our Edgar Dohmann (data biotics) and Ken Culp - Simplified Assembler. Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 9, 2021 Share Posted January 9, 2021 jmp $ 1 1 Quote Link to comment Share on other sites More sharing options...
Airshack Posted January 9, 2021 Share Posted January 9, 2021 1 hour ago, dhe said: You obviously have not tried his archiver code! ? Nah! I’m just trying to get others to help with deciding the MBX code. Not at all being critical of Boone as a programmer. Just, the MBX code is frustratingly challenging due to no comments. 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted January 9, 2021 Share Posted January 9, 2021 4 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted January 9, 2021 Share Posted January 9, 2021 ... but I've heard real programmers use machine code... ... not confusing things like... ...but me, what the heck do I know, I'm just a lowly... ... and I can't wrap my head around ... 4 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted January 9, 2021 Share Posted January 9, 2021 On 1/7/2021 at 9:43 PM, Tursi said: Just comment it. Uncommented assembly code might as well be Martian. Even if you can tell what he's saying, you've no idea what he's talking about. Avoiding fancy tricks, break the code up into functions... nothing so different from what makes any other code good. It ultimately depends on what your goal is - if you want other people to read it, code like you mean it. Well said! For me, comments explaining how the code works are more important than explaining the instructions. Long ago when I was first dabbling in assembly, someone in our Milwaukee user group shared his commented code with me. I didn't get much value from comments like "LI R0,1 * load register 0 with 1" or "C R0,R1 *compare R0 to R1" but I did glean a lot from how he documented the routines and the expected operation. I'm not sure I agree with avoiding fancy tricks, especially when commented well 2 Quote Link to comment Share on other sites More sharing options...
apersson850 Posted January 9, 2021 Share Posted January 9, 2021 Comments should describe what you intend to do, and why. They shall not describe what you are doing, since anybody who knows coding can see that by reading the instructions. Those who don't know coding aren't likely to read your program anyway. This is true for any language, by the way. 2 Quote Link to comment Share on other sites More sharing options...
tater1337 Posted January 9, 2021 Share Posted January 9, 2021 1 hour ago, apersson850 said: Comments should describe what you intend to do, and why. They shall not describe what you are doing, since anybody who knows coding can see that by reading the instructions. Those who don't know coding aren't likely to read your program anyway. This is true for any language, by the way. Ideally it should do both, in case you are using some esoteric method that is such spaghetti code that t cannot be unwound easily assume the next person that maintains your code will be looking at it 20 years later, and is not comfortable in the dialect of the code you are running (been there, currently doing that, should order the t-shirt) 3 Quote Link to comment Share on other sites More sharing options...
+TheBF Posted January 9, 2021 Share Posted January 9, 2021 3 hours ago, InsaneMultitasker said: Well said! For me, comments explaining how the code works are more important than explaining the instructions. Long ago when I was first dabbling in assembly, someone in our Milwaukee user group shared his commented code with me. I didn't get much value from comments like "LI R0,1 * load register 0 with 1" or "C R0,R1 *compare R0 to R1" but I did glean a lot from how he documented the routines and the expected operation. I'm not sure I agree with avoiding fancy tricks, especially when commented well The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. Dijkstra (1972) The Humble Programmer (EWD340). 5 Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted January 10, 2021 Share Posted January 10, 2021 3 hours ago, TheBF said: The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. Dijkstra (1972) The Humble Programmer (EWD340). That was a very interesting lecture to read, thank you for linking that. Somewhat to the point, I wasn't thinking about tricks as code written to intentionally obfuscate its own purpose nor to proclaim its greatness. The 9900 allows for some neat things like self-modifying code and speed-enhancing qualities e.g. running routines from scratchpad, which some including myself might never have even considered without seeing working, commented code from others that went beyond what the self-learning books offered. For quite some time I even thought the E/A Utility subprograms (VSBW, VMWB, KSCAN) were the only proper methods to access video and keyboard; seeing home-spun, faster routines was to me quite a feat/trick that I would probably not have considered - were it not for commented code. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 10, 2021 Share Posted January 10, 2021 On 1/7/2021 at 10:34 PM, Airshack said: An especially frustrating example of non-commented Martian-Assembly is the Boone MBX code. Help @Tursi if you get bored and need a new TI project I've got a pretty loaded queue already https://harmlesslion.com/cgi-bin/walrusshow.cgi 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 10, 2021 Share Posted January 10, 2021 8 hours ago, InsaneMultitasker said: I'm not sure I agree with avoiding fancy tricks, especially when commented well If you are writing your code to be /readable/, then yes, avoid fancy tricks. Fancy tricks are not readable code. That's why they are called "fancy tricks". However, when you DO use fancy tricks, comment the hell out of them. "Avoid" doesn't mean "Never". GOTO all you like. Just explain why. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 10, 2021 Share Posted January 10, 2021 Another way to put it is my favorite old one on debugging: "Debugging is twice as hard as coding. Therefore, if you code as cleverly as possible, you are not, by definition, clever enough to debug your own code." 3 1 Quote Link to comment Share on other sites More sharing options...
Fredrik Öhrström Posted January 10, 2021 Share Posted January 10, 2021 12 hours ago, apersson850 said: Comments should describe what you intend to do, and why. They shall not describe what you are doing, since anybody who knows coding can see that by reading the instructions. Those who don't know coding aren't likely to read your program anyway. This is true for any language, by the way. Indeed! Hear Hear! Totally agree! 1 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.