Jump to content
Kchula-Rrit

DSRs and GROM address question

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

Here is the addendum to the E/A Manual (look at the note for page 262):

image.thumb.png.a82e7f60794332ee1af82ca4034557e1.png

 

 

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

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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 by Kchula-Rrit

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites

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 by Tursi
  • Like 1

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by Tursi
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...