Kchula-Rrit Posted October 10, 2020 Share Posted October 10, 2020 How important is the GROM address? Will the computer crash or "go nuts" if it's corrupted? A while ago, I had asked the forum about a DSR call that was giving me problems. I was just duplicating the code that Tom Bentley used in his TCIO routines, to see how to do a DSR call. Before the BLWP @DSRLNK I saved the GROM address, then restored it afterward. Not knowing any better, I did it "because Tom Bentley" did it," assuming everyone knows more about DSR calls than me. One of the responses advised that it was unnecessary to save and restore the GROM address, so I removed that part. A few days ago I was poking through a PDF file of Molesworth's "Intro To TI Assembly", which said that DSR calls will trash the GROM address, so it should be saved. I assume that things like GPLLNK (obviously) or XMLLNK use it but my programs do not directly use it. I also assume that I "know enough to be dangerous" at this point. K-R. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted October 10, 2020 Share Posted October 10, 2020 Was the Molesworth statement made with respect to the cassette IO routines? I have never saved nor restored a GROM address when calling DSRLNK using the "standard" routine for non-cassette IO. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted October 10, 2020 Share Posted October 10, 2020 Here is the addendum to the E/A Manual (look at the note for page 262): Yes, you do need to protect the current GROM address for GPL calls via GPLLNK. If you never use GPLLNK, you are probably safe. ...lee 2 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 10, 2020 Share Posted October 10, 2020 And if you don't let your machine program return to Editor/Assembler; if you do a BLWP @0 to exit, there is no need to save the GROM address. 1 Quote Link to comment Share on other sites More sharing options...
Kchula-Rrit Posted October 11, 2020 Author Share Posted October 11, 2020 (edited) 7 hours ago, InsaneMultitasker said: Was the Molesworth statement made with respect to the cassette IO routines? I have never saved nor restored a GROM address when calling DSRLNK using the "standard" routine for non-cassette IO. Molesworth did not mention GROM address with cassette I/O. Could that be because cassette I/O is done with GPLLNK? I've only done cassette I/O with ExBASIC, not assembly. Took upwards of fifteen minutes to load a 20K data file, so I quit using it. Molesworth does repeat what Mr. Stewart's addendum above says, that the RS232 and Thermal Printer will trash the GROM address. On Page 83 he says you must save the GROM Read and GROM Write addresses before each BLWP @DSRLNK and restore them afterwards. The statement sounds like there are two addresses in the GROM that need to be saved, one each for reading and writing. I thought GROMs were read-only? I realize that this is a side-question, but Molesworth's example only saves and restores one address. It looks like the safe thing to do for my L23dump package is to save and restore the GROM address, since I don't know if the calling program will log to disk or RS232. K-R. Edited October 11, 2020 by Kchula-Rrit Quote Link to comment Share on other sites More sharing options...
Kchula-Rrit Posted October 11, 2020 Author Share Posted October 11, 2020 6 hours ago, mizapf said: And if you don't let your machine program return to Editor/Assembler; if you do a BLWP @0 to exit, there is no need to save the GROM address. All programs I've written up to now return to Editor/Assembler, so it is probably safest for me to save the GROM address. I use C99 which, I believe, does a save at start-up and a restore at exit. Hopefully, that's good enough. If I change to exit with BLWP @0, I can remove the save/restore to gain a little speed and size. By the way, is BLWP @0 the same as a "hard reset?" (What you get with a real reset button tied into the clock chip?) K-R. 1 Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 11, 2020 Share Posted October 11, 2020 (edited) GROMs only have one address - even GRAM uses the same address counter, so there's only one thing to save/restore. However, Editor/Assembler doesn't require you to save the GROM address to return to it. The GPL interpreter /generally/ assumes that it needs to set the GROM address for every new instruction. The problems mentioned above are specific to those DSRs. (Edit: and frankly - I wonder how true it is. They corrupt the GROM address, okay - but who cares? It's possible those guidelines were written before the GPL interpreter was finished? And doing what, anyway? Just a KSCAN, right?) As for BLWP @0 - this does all the same initialization and startup that turning on the console or resetting does -- but no reset pulse is sent out to the hardware. Again, generally this is not a big deal on the 4A, since most of the hardware doesn't do very much on hardware reset, but it's worth noting that it's not exactly the same. Edited October 11, 2020 by Tursi 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted October 11, 2020 Share Posted October 11, 2020 Yes, the hardware reset also goes to the VDP and to the I/O port. Quote Link to comment Share on other sites More sharing options...
GDMike Posted October 12, 2020 Share Posted October 12, 2020 2 hours ago, Tursi said: GROMs only have one address - even GRAM uses the same address counter, so there's only one thing to save/restore. However, Editor/Assembler doesn't require you to save the GROM address to return to it. The GPL interpreter /generally/ assumes that it needs to set the GROM address for every new instruction. The problems mentioned above are specific to those DSRs. (Edit: and frankly - I wonder how true it is. They corrupt the GROM address, okay - but who cares? It's possible those guidelines were written before the GPL interpreter was finished? And doing what, anyway? Just a KSCAN, right?) As for BLWP @0 - this does all the same initialization and startup that turning on the console or resetting does -- but no reset pulse is sent out to the hardware. Again, generally this is not a big deal on the 4A, since most of the hardware doesn't do very much on hardware reset, but it's worth noting that it's not exactly the same. Shoot, I need to do a hex view on final Grom, and other .bin files to see what they look like so I can write a program that distinguishes them out for me on a PC in a nice orderly fashion. Quote Link to comment Share on other sites More sharing options...
Kchula-Rrit Posted October 12, 2020 Author Share Posted October 12, 2020 So, something to try if a program acts weird; otherwise, nothing to worry about. Also, I was just curious if a hardware reset gets you anything a BLWP @0 doesn't. Looks like another thing to not really worry about. Thanks. K-R. Quote Link to comment Share on other sites More sharing options...
Tursi Posted October 12, 2020 Share Posted October 12, 2020 (edited) 10 hours ago, GDMike said: Shoot, I need to do a hex view on final Grom, and other .bin files to see what they look like so I can write a program that distinguishes them out for me on a PC in a nice orderly fashion. ROM or GROM Cartridge header is documented nicely at Nouspikel.com: http://www.unige.ch/medecine/nouspikel/ti99/headers.htm#header summary (edit: huh, guess it's not Nouspikel.com anymore ) Edited October 12, 2020 by Tursi 1 1 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.