DSRLNK in Extended BASIC

[+adamantyr]

While working on my game, I decided to offload my graphics to memory-image files on disk. That way they're loaded immediately into VDP on demand.

 

To use DSRLNK through a called TI Extended BASIC program, you have to roll your own it appears as it's not provided by the loader.

 

My main question is, do you have to have the PAB data in VDP? Or is there a way to place your PAB block in VDP so that it won't interfere with Extended BASIC? Anyone have a particular way of doing this?

[+InsaneMultitasker]

There are places you can use depending on what your XB program is doing. I've found the simplest method is to group your PAB and buffer somewhere, such as 0x2000 in VDP, then save/restore that memory in the lower 8K space before/after your DSR work.

 

If your PAB is 50 bytes (to account for longer paths) with a buffer of 256 bytes (assuming record IO) you would save VDP, execute your DSRLNK(s), restore VDP, and return to XB.

 

There are a few XB variants of DSRLNK out there. Watch for workspace and VDP utility usage. The GPL status byte and how you return from assembly to XB may impact what you do.

 

My BBS software goes one step further. I save 8K+ of VDP space to disk in swap-file fashion, use the space for my operations such as file transfers, then restore the VDP before returning to XB. This makes it possible to do some VDP/CPU gymnastics.....

[+adamantyr]

Ah, the GPL status byte... so should I save a copy of it when I'm coming from XB and restore it after the DSR call?

 

My thought for VDP was to take the current string stack address and just write the PAB into a lower block of it. Since it's only used once the stack will over-write it eventually.

[+adamantyr]

Nevermind, got it working!

 

My primary pain point now is conversion of parameters from Extended BASIC... I was trying to avoid using all the FP conversion crud, but I think I'll need it just to avoid a lot of hack solutions.

[+InsaneMultitasker]

Nevermind, got it working!

 

My primary pain point now is conversion of parameters from Extended BASIC... I was trying to avoid using all the FP conversion crud, but I think I'll need it just to avoid a lot of hack solutions.

Excellent!

 

For what it's worth, I often avoid NUMREF/NUMASG parameter passing by using memory starting at >A000 to pass values to assembly and between chained programs. So long as the program + running string space doesn't encroach upon the memory you use, you're pretty much golden.

 

>A000 is -24576. >A001 is -24575 etc. Therefore, CALL LOAD(-24576,0,1,2,3) would pass 8 bit value of 0 to >A000, 1 to >A001, etc.

 

If you need to pass a value larger than 255, you can calculate the high and low order bytes in XB to 'split' the 16-bit value into two 8 bit values. .

 

You can also use space starting at >A000 for assembly buffers and work areas (and often code) so long as you are aware of what your XB programs are using.

[+InsaneMultitasker]

Ah, the GPL status byte... so should I save a copy of it when I'm coming from XB and restore it after the DSR call?

 

 

Most often I immediately set the workspace pointer to my own WS, perform the needed assembly code, reset the WS pointer to the GPLWS, clear the status byte @837C, then return. There are other return methods that may be better or more common - perhaps others with hybrid experience will chime in as well.

[+adamantyr]

New issue... XMLLNK isn't working properly.

 

I tried calling >1200, the convert FP to integer function. I've referenced the XB address of >2018 for XMLLNK. But it just goes off into la-la land and crashes... anyone know why?

 

I've only messed around with FP numbers ONCE, when I wrote my conversion of TI-Trek to assembly years ago. There I used this routine but I used GPLLNK's rounding function first because I was dealing with real FP numbers with lots of significant digits. And I've no idea if there's something with XB that has to be done differently.

[+adamantyr]

Nevermind again... Fixed!

 

XB accesses the routines directly, instead of using a look-up table. So you have to put in the specific location, >12B8. The E/A manual actually HAS all this data on XB utilities and whatnot, it's just scattered around and not explained in a step by step way.

[+Lee Stewart]

You still should be able to use XMLLNK in a called ALC program, if you wish.

 

Regarding your attempt to call XMLLNK from XB, how did you set up FAC and call XMLLNK?

 

...lee

[+adamantyr]

You still should be able to use XMLLNK in a called ALC program, if you wish.

 

Regarding your attempt to call XMLLNK from XB, how did you set up FAC and call XMLLNK?

 

...lee

 

I copy the FP value from either VDP directly (in the case of a passed numeric constant) or copy it from high RAM into the FAC location and invoke XMLLNK via >2018.

 

Interestingly, the E/A manual has an error... it says the LINK argument type list is at >200A to >2019, but in fact it's stored at >8300 to >830F. The disassembly of the TI Basic Support utilities support this.

[+Lee Stewart]

I copy the FP value from either VDP directly (in the case of a passed numeric constant) or copy it from high RAM into the FAC location and invoke XMLLNK via >2018.

 

I have not done this through XB or TIB, which was the reason for my question. I presume you passed >1200 as the only argument to XMLLNK something like

 

CALL LINK ("XMLLNK",4608)

 

where 4608 is the decimal equivalent of >1200?

 

Interestingly, the E/A manual has an error... it says the LINK argument type list is at >200A to >2019, but in fact it's stored at >8300 to >830F. The disassembly of the TI Basic Support utilities support this.

 

The E/A manual is actually correct. I don't know about XB (which is not mentioned in this regard), but the E/A support for TIB, indeed, does use >200A to >2019 to store up to 16 argument types. See G6CF4 ff. in the E/A GROM subprograms listing on Thierry's site.

 

...lee

[+adamantyr]

I'm not calling XMLLNK from XB...? Who would ever do that or why? This is to convert parameters passed via LINK to integers in the assembly program.

 

And in this case, because the assembly routine is called from XB, there's no look-up table for the XMLLNK routine. The E/A manual specifies that you should use >12B8 instead for the CFI routine, and it works.

 

When I wrote my code to check >200A for my argument type, there was nothing but garbage in that block. So I checked the disassembly of the TI BASIC support utilities and to my surprise, it wasn't looking there at all for the argument types. It was looking at >8300, offset by the argument #. So I checked there and voila, working.

 

The problem is you essentially have three environments to consider: pure assembly, assembly to TI BASIC, and assembly to TI Extended BASIC. Also whether or not you have a memory expansion is a factor; keep in mind that numerical variables, in contrast to what the E/A manual says (that the pointer in the stack is to VDP RAM), are actually stored in high memory in Extended BASIC.

[+Lee Stewart]

I really do not mean to be obtuse. And, I agree with you about calling XMLLNK from XB, but that was not clear to me from your post. Your narrative confuses what happens in XB with what happens in TI Basic (TIB). You may not be confused, but I surely am. What I said in my last post stands. TI Basic does, in fact, use >200A to >2019 for the passed variables' argument types, so it is not in error. The E/A manual is talking about what the E/A cartridge is doing when it mentions this fact. Obviously, the E/A cartridge is not running when you are using XB. The same routines (LINK etc.) in the XB cartridge and its support file(s) are coded differently and, I have no doubt, work the way you say they do, using >8300 to >830F to pass the argument types. But, once again, the E/A manual (where you claim it to be in error) is talking about the TI Basic support routines, not those for XB. The listing I referenced in my last post is a disassembly of the GPL in the E/A GROM (where LINK for TIB dwells), not the corresponding code used by the XB cartridge.

 

...lee

[+adamantyr]

I really do not mean to be obtuse. And, I agree with you about calling XMLLNK from XB, but that was not clear to me from your post. Your narrative confuses what happens in XB with what happens in TI Basic (TIB). You may not be confused, but I surely am. What I said in my last post stands. TI Basic does, in fact, use >200A to >2019 for the passed variables' argument types, so it is not in error. The E/A manual is talking about what the E/A cartridge is doing when it mentions this fact. Obviously, the E/A cartridge is not running when you are using XB. The same routines (LINK etc.) in the XB cartridge and its support file(s) are coded differently and, I have no doubt, work the way you say they do, using >8300 to >830F to pass the argument types. But, once again, the E/A manual (where you claim it to be in error) is talking about the TI Basic support routines, not those for XB. The listing I referenced in my last post is a disassembly of the GPL in the E/A GROM (where LINK for TIB dwells), not the corresponding code used by the XB cartridge.

 

...lee

 

My apologies for the confusion, the thread has always been focused on Extended BASIC.

 

And on page 418 of the E/A manual, here it is!

 

"CALL LINK--The Editor/Assembler Loader uses its own workspace to store information from the parameter list. Only the addresses >8310 through >8312 are reserved for parameter passing purposes. TI Extended BASIC uses addresses >8300 through >8315 for this information. Your assembly language program must not modify this area if parameters are to be accessed in the program."

 

So you are right it's not an error... just poor organization. The E/A manual is about as difficult to find concrete information in as the 1st Edition Advanced Dungeons & Dragons Dungeon Master's Guide!

[+Lee Stewart]

You are dead on regarding the E/A manual's “poor organization”! Trying to tease out information over the years has often been extremely frustrating.

 

...lee

[Stuart]

adamantyr, on 30 Jun 2016 - 7:48 PM, said:

 

... the 1st Edition Advanced Dungeons & Dragons Dungeon Master's Guide!

 

Happy memories!

[+Ksarul]

My copy of the DMG was from the messed-up second printing of the 1st Edition--it had a whole bunch of pages from the Monster Manual in the mid-section of the book instead of the DMG pages with the same numbers. I had photocopies of the correct pages so that the book would be useful. Most of those never made it into player's hands though, so that printing is actually pretty valuable now (mine probably isn't because it was heavily used). Only a few of these survive though. . .and oddly enough, I was the one who both confirmed that at least one copy survived and provided that data to the Acaeum about ten years ago. Then someone showed up with a pristine copy and now the discovery is credited to them. Go figure.