E/A Manual Addendum

[RobertLM78]

Well, I'm going to re-post this question along with the quote from the addendum, so that hopefully it makes more sense:

 

In the Addendum for the Editor Assembler manual, there is an entry for page 262 saying to add a note about saving the current GROM address before an I/O operation. It also says "RS232 and TP are known culprits." Do I need worry about this "bug" with a Corcomp RS232 card? (I don't have a Thermal Printer, so that isn't a worry ).

ADDENDUM: Editor Assembler Owner's Manual

 

Page 262, section 16.2.4

 

(Add the following). NOTE: Some devices modify the GROM read address. RS232 and TP are known offenders. If your program accesses these devices, save the current GROM address before the I/O operation, and restore it after your program has accessed the device. Otherwise the program will not be able to return to the Editor/Assembler or BASIC or to perform a BLWP @GPLLNK properly.

Edited July 18, 2013 by RobertLM78

[RobertLM78]

Bumping this now that I have (hopefully) made the question more clear.

[+mizapf]

What is the issue you expect?

 

I would never really assume that the GROM address is unchanged after a DSR call. Apart from the fact that I only rarely needed access to the GROMs. The problem they are bringing up is that you could decide to set a GROM address, do some reads, do a DSR call, and then continue reading.

[RobertLM78]

What is the issue you expect?

 

I would never really assume that the GROM address is unchanged after a DSR call. Apart from the fact that I only rarely needed access to the GROMs. The problem they are bringing up is that you could decide to set a GROM address, do some reads, do a DSR call, and then continue reading.

Good points - so it's never a good idea to assume the GROM address in unchanged? (Sorry if I'm asking some really basic questions, I'm a total noob, but eager to learn ). I was thinking about the fact that accessing GROMs might be a rare thing to do, but still, I guess I worry about unwittingly coding bugs into my programs - especially being so green .

Edited July 18, 2013 by RobertLM78

[+mizapf]

Suppose you had a tool to print the contents of your GROMs as a dump file. You would probably set the GROM address, e.g. G>6000, then read 16 bytes sequentially, and then you may consider to directly print them to the printer. The manual just warns you that after printing, the GROM pointer will be elsewhere, so you should not continue to read but you should set the new address and then continue reading. As I said, if you just don't assume that the pointer is untouched, you won't get into trouble.

[RXB]

Suppose you had a tool to print the contents of your GROMs as a dump file. You would probably set the GROM address, e.g. G>6000, then read 16 bytes sequentially, and then you may consider to directly print them to the printer. The manual just warns you that after printing, the GROM pointer will be elsewhere, so you should not continue to read but you should set the new address and then continue reading. As I said, if you just don't assume that the pointer is untouched, you won't get into trouble.

 

GROM/GRAM is self advancing. I mean when you read GROM/GRAM it automatically advances to the next address.

 

Thus if a card also reads the GROM/GRAM it will ALSO advance the GROM/GRAM address by doing the read of GROM/GRAM.

 

So if you read backwards from the POINTER of GROM/GRAM address you should find the correct value.

 

Just thinking on a logical progression here.....

Edited July 19, 2013 by RXB

[RobertLM78]

Very nice Rich! I think I'm beginning to see a glimmer of light here in my understanding . Thanks!

[Tursi]

Although it doesn't say, it's a good idea not to assume that the VDP address is unchanged, either. It probably doesn't say anything there because a DSR is almost guaranteed to change the VDP address, but if you give control to any code you didn't write yourself, you should just assume it changed the system state. For instance, calling KSCAN will change the GROM address too, and the vertical interrupt will usually change the VDP address!

[Willsy]

Indeed. I used to have code in TF to save the GROM address before a DSRLNK before I realised that what TI were actually saying was "If you call a DSR then the GROM address may not be where you left it". I'm cool with that, since TF doesn't really "do" GROM. So I took the code out to save/restore the GROM address. It can be set to whatever as far as I'm concerned

[+Lee Stewart]

I understand the note vis-à-vis returning to E/A, Basic or XB; but, I'm not sure it matters with BLWP @GPLLNK.

 

...lee

[+Lee Stewart]

Indeed. I used to have code in TF to save the GROM address before a DSRLNK before I realised that what TI were actually saying was "If you call a DSR then the GROM address may not be where you left it". I'm cool with that, since TF doesn't really "do" GROM. So I took the code out to save/restore the GROM address. It can be set to whatever as far as I'm concerned

 

I do believe that any code you had that saved the GROM address was truly superfluous. TF is using a modification of the Millers Graphics universal GPLLNK/DSRLNK from Smart Programmer, both of which save the GROM address—GPLLNK because it calls console routines that start out with a GROM save and DSRLNK because it calls GPLLNK, which then invokes the console's DSRLNK.

 

...lee

[RXB]

I do believe that any code you had that saved the GROM address was truly superfluous. TF is using a modification of the Millers Graphics universal GPLLNK/DSRLNK from Smart Programmer, both of which save the GROM address—GPLLNK because it calls console routines that start out with a GROM save and DSRLNK because it calls GPLLNK, which then invokes the console's DSRLNK.

 

...lee

 

This was one of my main reason for promoting the use of the Miller Graphics universal GPLLNK/DSRLNK in the first place.

[+Lee Stewart]

This was one of my main reason for promoting the use of the Miller Graphics universal GPLLNK/DSRLNK in the first place.

 

I hear ya, Rich. I will probably wind up using it for fbForth when I hoist it into cartridge space because I think it will be easier than adapting the current TI-Forth/fbForth GPLLNK and DSRLNK.

 

...lee