Trying to learn TI programming

[apersson850]

Things are generally different when running Extended BASIC. Back when I did, I used a DSRLNK that was a bit different compared to the one TI recommends in the E/A documentation. The one I used works regardless of whether the DSR is written in assembly language or in GPL. That has the advantage that you can store a memory image in a file in exactly the same way regardless of whether it ends up on disk or cassette.

This may not be an issue today, but I wrote some software that was intended to be used as subprograms for Extended BASIC, and could work also with systems having only 32 K RAM expansion but no disk system.

 

If you want to do something that requires learning quite a bit of the internal working of the computer, and Extended BASIC, but still is a project of limited size, you could write a program that makes the cursor in Extended BASIC flash not between the character it's covering and a black block, but between the character it's covering and that character inverted in a black block. Flipping the cursor like this could be enabled by CALL LINK("FLIP") and disabled by CALL LINK("NOFLIP").

 

This is a good educational exercise, because it's not trivial but still rather small in size.

Edited May 19, 2017 by apersson850

[Pheonix]

With my limited TI knowledge, the only way I can see to do that right now would be to change the cursor itself depending on what is under it. Of course, that is based on my knowledge of BASIC and not assembly. There may be a way to pull it off in assembly. With my current level of knowledge, I would need to set up an interrupt driven routine that checked what was under the cursor and changed it appropriately.

 

My current big project is an autorun program (named LOAD on disk,) that will bring up a menu of what's on the disk with descriptions and let me chose one to load and run. Actually very new to disks on the TI. I never had a PAB back in the day, though I do now. Though I'm not even sure if it, or the floppy drive, even work. Don't currently have a spot to set my TI up (working on it.) I'm doing all of this in emulation. Saving up for a decent desk to set up my 8-bit (yeah, I know, the TI is actually a 16-bit system, but that's the era its from,) systems on. Currently have a c128 and the TI. Looking to eventually get an Atari 800 and an Apple II. That would complete the collection of computers I worked with back then. My mid-level systems (16-bit, though again some are technically 32,) include a DOS/Win3.1/Win98 Voodoo system (Voodoo 3dfx driven,) an Amiga 2000 and an Amiga 4000. Those share space with my modern 3.4Ghz Quad Core system.

 

**dragging self back onto topic** The menu program I'm writing is mainly in Extended BASIC as that is the cart I'm most likely to have installed most of the time. So, put in a disk, hit 2, browse through the menu, and the program is loaded and run. Issues I have with that are what, generally, lead me to an assembly project. The PSTR program was in answer to how slow it is to use HCHAR or VCHAR to put a string up (which are the only way to use the full 32x24 screen.) Not to mention how slow partial screen scrolling is in BASIC. Its also looking like I'm going to have to write my own E/A option 5 (maybe option 3 as well,) loader. I only have 2 games I like right now that require it, and none of the ones I've found load them.

 

Currently, with what I want to do, my program will eventually autorun when XB loads up. Read a data file from the disk, and display the information. If the data file isn't there it goes to the editor, bringing up a list of all files on the disk. Or I can enter the editor manually to change the menu if needed. In the editor, I would chose the files that actually need to load, give them a meaningful name and a description of the program (mostly games,) in question. Leaving out any secondary files for each program. If the data file is there, it throws up the list and I can scroll through (with the description appearing on each entry as I scroll to it. Each game would have a code to tell my program the proper way of loading it and getting it running.

 

Some of the things I would like to do are:

1) Use reverse text to show which file is currently selected. Currently can't do that in XB. Can't even, currently, see how to do it in Assembly without going into bit-map mode.

2) I would like to color code each entry by what type of load it's going to be (Assembly Option 5, XB Assembly, XB BASIC, etc...) With a color for programs that will require me to switch carts. In those cases, when I say to load it, it will throw up instructions that I can read prior to shutting down and switching carts. Again, this looks like it will require bit-map mode.

3) Scroll only a portion of the screen as I scroll through the list. This is definitely going to need an assembly routine. I don't remember which machine it was, but back in the day there was a built in routine I used in BASIC that loaded a scroll buffer. Then you called the routine marking a portion of the screen & a direction. It would then scroll the buffer onto the screen from the appropriate position (top/bottom IIRC.) Fairly sure it wasn't the TI, though.

4) Load & run the selected program. This may involve loading an interim loader & clearing out RAM first. My system only has a 32k RAM expansion (assuming the PAB works,) so I can't use some of the memory banking tricks I've read about for the larger programs.

 

Now, with the name sizes of some of the programs I would like to set up with the menu, I could probably put load type information as text with the program names. As the program name itself precludes a multi-column menu. I also don't foresee having more than 14 programs on a single disk (my drive is probably a SSSD disk, so rather small.) 14 is the key number as I am planing to have 7 lines used up at the bottom (a box with 5 30 character lines of text for description,) and 3 lines at the top for system messages & such (2 lines with a separater.)

 

So, a pretty big project (for me & my current knowledge.) Right now, I'm looking into bit-map mode for the color coding & reverse text (which makes PSTR obsolete I'm afraid,) and disk access for reading the data file. Though, I might leave that up to the BASIC half. Unless I find an Option 5 (maybe 3 as well,) loader that works, I'll need it for the special loaders I will have to write for the E/A programs I have. One of them is 19k in size, which is probably what is making it difficult to find a loader for. Best I can think of is to write a loader that first moves itself to a portion of memory that the game in question won't be loading to, then load it from there. I found a loader that puts itself at the top of RAM, and was extremely small, so it should have worked. Only it used the DSRLNK & GPLLNK routines I mentioned, which E/A doesn't give XB equate values for. I used the ones from my Mini Memory manual instead, but that could be why it is failing instead of the game itself not liking it. Assuming the game loads at A000 (which is a pretty big assume, I know,) there should have still been quite a bit of space between the game and the loader. Though, I'm wondering now, if it removed itself from the DEF/REF table, would it work then?

[apersson850]

You can define an alternate character set that's inverted. But there's not space to do that for all possible characters within the X-BASIC environment. Nor can you use bit map mode with BASIC, as you get a video memory conflict.

 

A loader that loads relocatable code can be anywhere, since per definition the code it's loading can be anywhere. But most larger programs are converted to memory images, which must load at a certain memory location.

The machine's support for loading memory images requires them to go to a buffer in VDP RAM, which is so large that you can't have bit map mode enabled when doing that. Not unless you don't care you'll literally see the file being loaded.

But once the file is loaded, you can check in the file where it's supposed to go in memory. If the file is on disk, you can do a sector read of the beginning of the file, and find out where it should be loaded. If you write your own loader, you can then read and load one sector at a time, instead of one up to 8 K byte memory image at a time.

 

Regarding the flipping cursor, you are right in your assumptions.

[Asmusr]

Things are generally different when running Extended BASIC. Back when I did, I used a DSRLNK that was a bit different compared to the one TI recommends in the E/A documentation. The one I used works regardless of whether the DSR is written in assembly language or in GPL. That has the advantage that you can store a memory image in a file in exactly the same way regardless of whether it ends up on disk or cassette.

This may not be an issue today, but I wrote some software that was intended to be used as subprograms for Extended BASIC, and could work also with systems having only 32 K RAM expansion but no disk system.

 

It is an issue today! Now that we can easily make our own GROMs it would have been cool to be able to make GPL DSRs that worked in general, e.g. for a SAMS RAM disk, HDX on a cart, or loading disk software from ROM. It's incomprehensible to me why a routine as central as DSRLNK was not built into the console ROM?

 

BTW, is there any reason why a custom DSRLNK could not search for ROM headers as well?

[senior_falcon]

 

Some of the things I would like to do are:

1) Use reverse text to show which file is currently selected. Currently can't do that in XB. Can't even, currently, see how to do it in Assembly without going into bit-map mode. XB256 will do this directly from Extended BASIC.

2) I would like to color code each entry by what type of load it's going to be (Assembly Option 5, XB Assembly, XB BASIC, etc...) With a color for programs that will require me to switch carts. In those cases, when I say to load it, it will throw up instructions that I can read prior to shutting down and switching carts. Again, this looks like it will require bit-map mode.Can probably do this in XB256. You'd need several different places for character definitions with a different CALL COLOR for each.

3) Scroll only a portion of the screen as I scroll through the list. This is definitely going to need an assembly routine. I don't remember which machine it was, but back in the day there was a built in routine I used in BASIC that loaded a scroll buffer. Then you called the routine marking a portion of the screen & a direction. It would then scroll the buffer onto the screen from the appropriate position (top/bottom IIRC.) Fairly sure it wasn't the TI, though. XB256 will do this directly from Extended BASIC.

4) Load & run the selected program. This may involve loading an interim loader & clearing out RAM first. My system only has a 32k RAM expansion (assuming the PAB works,) so I can't use some of the memory banking tricks I've read about for the larger programs.

 

[senior_falcon]

 

Some of the things I would like to do are:

1) Use reverse text to show which file is currently selected. Currently can't do that in XB. Can't even, currently, see how to do it in Assembly without going into bit-map mode. XB256 will do this directly from Extended BASIC.

2) I would like to color code each entry by what type of load it's going to be (Assembly Option 5, XB Assembly, XB BASIC, etc...) With a color for programs that will require me to switch carts. In those cases, when I say to load it, it will throw up instructions that I can read prior to shutting down and switching carts. Again, this looks like it will require bit-map mode.Can probably do this in XB256. You'd need several different places for character definitions with a different CALL COLOR for each.

3) Scroll only a portion of the screen as I scroll through the list. This is definitely going to need an assembly routine. I don't remember which machine it was, but back in the day there was a built in routine I used in BASIC that loaded a scroll buffer. Then you called the routine marking a portion of the screen & a direction. It would then scroll the buffer onto the screen from the appropriate position (top/bottom IIRC.) Fairly sure it wasn't the TI, though. XB256 will do this directly from Extended BASIC.

4) Load & run the selected program. This may involve loading an interim loader & clearing out RAM first. My system only has a 32k RAM expansion (assuming the PAB works,) so I can't use some of the memory banking tricks I've read about for the larger programs.

 

[Pheonix]

You can define an alternate character set that's inverted. But there's not space to do that for all possible characters within the X-BASIC environment. Nor can you use bit map mode with BASIC, as you get a video memory conflict.

 

OK... Is this Extended BASIC trying to also do something with the video, or can I still use XB as the driver, and just have an Assembly routine running the video? I'd sort of like to know before I get too far into this. I could still do it, but I would have to put it all into Assembly. Or I could just give up on the bells and whistles, and just go back to the original plan. 6 defined characters for the box, and PSTR to utilize the entire screen for text. With special characters instead of color, and brackets to mark selection instead of reverse text.

 

Dragonstomper: Not sure what XB256 is. Since I don't have anything extravagant for my TI, I may not be able to use it. I'll look it up. My first goal is to just get everything up and running. Then I'm going to start tricking them out. Waiting on getting a desk right now. Once I get it my projects will probably come to an end for a bit as I start setting everything up. Assuming everything is running, then I'll start looking for HW & replacement software & such. If a system I don't have yet becomes available at a decent price, that would slow things down too. These projects are what I do between, right now. The projects will become a little more stable once everything is running smoothly.

[apersson850]

No, it's more a question about that since an unexpanded TI 99/4A has almost nothing else but video memory. Hence almost everything that takes place goes through video memory. This includes the memory image transfer function, which is used for the Run program file option (#5) in E/A, to load and save BASIC programs and several other stuff.

[senior_falcon]

Dragonstomper: Not sure what XB256 is. Since I don't have anything extravagant for my TI, I may not be able to use it. I'll look it up. My first goal is to just get everything up and running. Then I'm going to start tricking them out. Waiting on getting a desk right now. Once I get it my projects will probably come to an end for a bit as I start setting everything up. Assuming everything is running, then I'll start looking for HW & replacement software & such. If a system I don't have yet becomes available at a decent price, that would slow things down too. These projects are what I do between, right now. The projects will become a little more stable once everything is running smoothly.

To run on a real TI you need 32k, the XB cartridge and a disk drive. Since you were talking about using Editor/Assembler on a real TI, you also need 32K and a disk drive for that,

[Omega-TI]

 

Since I don't have anything extravagant for my TI, I may not be able to use it. I'll look it up. My first goal is to just get everything up and running. Then I'm going to start tricking them out.

 

Uh huh... THAT'S HOW IT ALL STARTS!

By this time next year you'll probably have a full blown system!

[Sinphaltimus]

I'm not entirely sure I understand what you're doing here but that's fine. I don't know much of anything anyway. But I did download the work.dsk to try and see what you're up to. How do I load this up? in classic99 and what should I expect to see happen? I will start learning assembly someday.

[Pheonix]

I'm not entirely sure I understand what you're doing here but that's fine. I don't know much of anything anyway. But I did download the work.dsk to try and see what you're up to. How do I load this up? in classic99 and what should I expect to see happen? I will start learning assembly someday.

Basically, it's just an extended text display. To use (in BASIC:) After the "CALL INIT" command you would "CALL LOAD("DSK1.PSTR") - changing DSK1 to whatever drive you have the disk in (DSK1, DSK2, etc...) Then, you can "CALL LINK("PSTR",Y,X,<STRING>[,S])" Where Y & X are the Row & Column you want your text to start at, <STRING> is the text you want displayed, and the optional S is the spacing, which is a value from -384 to +384 denoting how many spaces to place between each character in <STRING>. 0, would place them all on top of each other (not much use there, you would only see the last character.) 1 (the default) would have them all print out normally (one after the other.) -1 would put them up backwards. Not the characters themselves, just how they print out on screen. "HELLO" would come out "OLLEH" with the H being on the column/row you designated.

 

With that, you could have them print out vertically by using +/- 32. Or diagonally with +/- 31 or 33. Unlike DISPLAY AT, you have access to all 32 columns (and not the 28 PRINT & DISPLAY are limited to.)

[senior_falcon]

 

Currently, with what I want to do, my program will eventually autorun when XB loads up. Read a data file from the disk, and display the information. If the data file isn't there it goes to the editor, bringing up a list of all files on the disk. Or I can enter the editor manually to change the menu if needed. In the editor, I would chose the files that actually need to load, give them a meaningful name and a description of the program (mostly games,) in question. Leaving out any secondary files for each program. If the data file is there, it throws up the list and I can scroll through (with the description appearing on each entry as I scroll to it. Each game would have a code to tell my program the proper way of loading it and getting it running.

 

Some of the things I would like to do are:

1) Use reverse text to show which file is currently selected. Currently can't do that in XB. Can't even, currently, see how to do it in Assembly without going into bit-map mode.

2) I would like to color code each entry by what type of load it's going to be (Assembly Option 5, XB Assembly, XB BASIC, etc...) With a color for programs that will require me to switch carts. In those cases, when I say to load it, it will throw up instructions that I can read prior to shutting down and switching carts. Again, this looks like it will require bit-map mode.

3) Scroll only a portion of the screen as I scroll through the list. This is definitely going to need an assembly routine. I don't remember which machine it was, but back in the day there was a built in routine I used in BASIC that loaded a scroll buffer. Then you called the routine marking a portion of the screen & a direction. It would then scroll the buffer onto the screen from the appropriate position (top/bottom IIRC.) Fairly sure it wasn't the TI, though.

4) Load & run the selected program. This may involve loading an interim loader & clearing out RAM first. My system only has a 32k RAM expansion (assuming the PAB works,) so I can't use some of the memory banking tricks I've read about for the larger programs.

 

All that you want to do can be accomplished with an XB program running with XB256. XB256 only needs XB, 32K and a disk system. Which happens to be the minimum requirements for what you want to do - if you want to autoload from XB then you need XB and a disk drive. If you are loading EA5 programs then you must have 32K.

[Sinphaltimus]

.... Unlike DISPLAY AT, you have access to all 32 columns (and not the 28 PRINT & DISPLAY are limited to.)

Nice!

[+arcadeshopper]

 

OK... Is this Extended BASIC trying to also do something with the video, or can I still use XB as the driver, and just have an Assembly routine running the video? I'd sort of like to know before I get too far into this. I could still do it, but I would have to put it all into Assembly. Or I could just give up on the bells and whistles, and just go back to the original plan. 6 defined characters for the box, and PSTR to utilize the entire screen for text. With special characters instead of color, and brackets to mark selection instead of reverse text.

 

Dragonstomper: Not sure what XB256 is. Since I don't have anything extravagant for my TI, I may not be able to use it. I'll look it up. My first goal is to just get everything up and running. Then I'm going to start tricking them out. Waiting on getting a desk right now. Once I get it my projects will probably come to an end for a bit as I start setting everything up. Assuming everything is running, then I'll start looking for HW & replacement software & such. If a system I don't have yet becomes available at a decent price, that would slow things down too. These projects are what I do between, right now. The projects will become a little more stable once everything is running smoothly.

 

dragonstomper is his rank the user name is at the top of the post on the left

 

xb256 on cartridge: https://www.arcadeshopper.com/wp/?page_id=11#!/Extended-Basic-Fun-Contains-XB2-7-XB256-and-XB-w-The-missing-link/p/58077087/category=15846004

[Pheonix]

Oops.... I meant senior_falcon then My bad, I didn't look close enough, just at what was directly over the avatar. Sorry about that.

 

In the middle of writing code to use bitmap mode right now. May not be very memory friendly, but right now I have a DATA block with the character patterns. Mainly because it is the easiest method. Later, will replace that with just a DATA block of the changes I want to make, and will use the ones in ROM instead. The current block is 96 characters (768 bytes,) long. Just the different ones will be 32 characters (256 bytes,) long. Characters changed... a-z & 6 special characters for the box (drawn lines for horizontal, vertical, and the 4 corners.) Apologies to any purists out there, but I could never stand the small upper case letters instead of lower case letters. The top is going to just have 2 lines for text (full 32 characters wide,) and a line all the way across. The bottom will have a full box (with the drawn corners,) containing 5 lines of 30 characters each. Limits the description to 150 characters, but that should be sufficient. Not going to color code, but leaving the option in place so the routines can be used for other things.

 

There are going to be 5 routines. 1 to turn bitmap mode on, 1 to turn it off, 1 to place text directly to an area of the screen (defined by 4 numbers, upper left X/Y and lower right X/Y,) 1 to scroll a section of the screen UP/DOWN (with provided text being scrolled on & scroll length being determined by the amount of text to be scrolled on,) and 1 to clear a section of the screen.

 

This will allow XB to do all the accounting work (opening & reading the list file, deciding what is going to be displayed, reading the keyboard, etc...) The only issue I might be facing is the drop in available VDP RAM. I'm just remembering that someone said that file transfers are handled in VDP RAM as well. Was planning to create a listing file that is VARIABLE 150 (150 for the largest entry which is the description.) The entries will be: program file name (10 characters max,) program real name (20 characters max, for now - may change,) loader method (1 character) and program description (150 characters, though also considering 5 entries of 30 characters each.) Going to have to research that, may mean using VARIABLE 181 instead.

 

thinking on it, I may add in a routine to pop a cursor up on the screen, for entering a new description & the program's real name. May use XB to do that, though. Just thought of another necessary entry in the list file. But it would only exist in "Command Module Change" loaders. That is, instructions after changing the command module. These instructions could get quite lengthy, so I would probably just create a text file, or even a basic program, to give these instructions. Using a BASIC program to give the instructions might work best, as the instructions could be encoded as the program file name, and it would use the same loader routine as a program that is just a BASIC program file.

 

There will also be routines for each of the loaders that can be handled directly. Such as just running a BASIC program & such. A special loader would also follow the same routine, I'm sure. This program is getting hefty enough, that there may not be very many Assembly programs that it will be able to load itself. Will probably be fairly close to 1K in size when finished, but putting at the end of the 24K RAM block (>FC00 if it is 1K in size,) may make many Assembly programs loadable (after returning to regular screen mode instead of bitmap mode.)

[Pheonix]

xb256 on cartridge: https://www.arcadeshopper.com/wp/?page_id=11#!/Extended-Basic-Fun-Contains-XB2-7-XB256-and-XB-w-The-missing-link/p/58077087/category=15846004

 

I'm writing this to work on my physical TI (when I get a desk and can set it up.) I write everything to work on my physical systems (C128, Apple, Amiga, etc...) I don't, currently, have the resources to use custom cartridges (though planning for that to change eventually.) Thanks for the link though Will come in handy when I can use custom cartridges, be it through an EPROM burner or the SSD (?) multi-cart system. Though I would like that one better if it had on-board RAM and was designed to be configured for all cartridge types (Mini Memory, comes to mind.) Would really save on swapping cartridges in/out. Take a note from MAME on that, and use a nvram file for the RAM of cartridges such as the Mini Memory. With on board VRAM, designers could also design around using that. Don't know if cartridge RAM is compatible, but could such be used to replace a PAB RAM expansion? Ack, off topic, I'll drop my dreaming for now

[+arcadeshopper]

The cart works in any ti994a if you have 32k ram that's helpful.

 

Sent from my LG-H830 using Tapatalk

[Pheonix]

The cart works in any ti994a if you have 32k ram that's helpful.

 

Sent from my LG-H830 using Tapatalk

 

I keep apologizing Didn't even check the link, just assumed it was a cart ROM image like some other original release improvements. Sorry about that.

[Pheonix]

OK, I give up..... I've searched & searched, and I just cannot find XB equates for DSRLNK & GPLLNK. The equates in the Mini Memory manual don't even come close the ones I can verify from the E/A manual (for XB.) So, I can't use those. The loader program I got HERE, cannot be used with XB becase XB doesn't support the REF line. The closest I've found to finding DSRLNK, is in the TI-99/4A intern book, and that seems to be TI BASIC (not XB.) May be the same, but it also may not. Might give it a try & see.

 

I also find it hard to understand the one HERE, unless an Option 5 loader is built into XB somewhere. CALL LINK("OPT5","??") seems to work. But the 2 Option 5 programs I currently have both fail with it.

 

Pulling the REF/DEF table from E/A (simple BASIC program to read it and convert to readable text,) has all the one in the >2xxx range not match (with 4 that aren't even in the XB list - UTLTAB, DSRLNK, GPLLNK, & LOADER,) and all the ones outside the >2xxx range matching up. The values are "not" interchangeable. You have to use the XB values when running under XB & E/A values when running under E/A (which I could see leading to Option 5 programs not working.) Though, since these appear to actually be references, that could be fixed. Just move the values from where XB put them to where E/A expects them.

[senior_falcon]

GPLLNK and DSRLNK do not exist in XB. You have to provide your own. Miller's Graphics came up with the code below many years ago and this is what I have always used.

*******************************************************************************
*GPLLNK AND DSRLINK FROM THE SMART PROGRAMMER
********************************************************************************
 
GPLWS  EQU >83E0
GR4    EQU GPLWS+8
GR6    EQU GPLWS+12
LDGADD EQU >60
XTAB27 EQU >200E
GETSTK EQU >166C
 
GPLLNK DATA GLNKWS
       DATA GLINK1
 
RTNAD  DATA XMLRTN
GXMLAD DATA >176C
       DATA >50
 
GLNKWS EQU $->18
       BSS >08
 

GLINK1	MOV *R11,@GR4
       MOV *R14+,@GR6
       MOV @XTAB27,R12
       MOV R9,@XTAB27
       LWPI GPLWS
       BL *R4
       MOV @GXMLAD,@>8302(R4)
       INCT @>8373
       B @LDGADD
 
XMLRTN MOV @GETSTK,R4
       BL *R4
       LWPI GLNKWS
       MOV R12,@XTAB27

       RTWP
	
*DSRLNK
 
PUTSTK EQU >50
TYPE   EQU >836D
NAMLEN EQU >8356
VWA    EQU >8C02
VRD    EQU >8800
GR4LB  EQU >83E9
GSTAT  EQU >837C
 
DSRLNK DATA DSRWS,DLINK1
 
DSRWS  EQU $
DR3LB  EQU $+7
DLINK1 MOV R12,R12
       JNE DLINK3
       LWPI GPLWS
       MOV @PUTSTK,R4
       BL *R4
       LI R4,>11
       MOVB R4,@>402(R13)
       JMP DLINK2
       DATA 0
       DATA 0,0,0
DLINK2 MOVB @GR4LB,@>402(R13)
       MOV @GETSTK,R5
       MOVB *R13,@DSRAD1
       INCT @DSRADD
       BL *R5
       LWPI DSRWS
       LI R12,>2000
DLINK3 INC R14
       MOVB *R14+,@TYPE
       MOV @NAMLEN,R3
       AI R3,-8
 
       BLWP @GPLLNK
DSRADD BYTE >03
DSRAD1 BYTE >00

       MOVB @DR3LB,@VWA
       MOVB R3,@VWA
       SZCB R12,R15
       MOVB @VRD,R3
       SRL R3,5
       MOVB R3,*R13
       JNE SETEQ
       COC @GSTAT,R12
       JNE DSREND
SETEQ  SOCB R12,R15
DSREND RTWP

*************************  

[+mizapf]

(removed my answer; has been resolved already)

Edited May 21, 2017 by mizapf

[Pheonix]

Well, that explains why I couldn't find it. I had found that code elsewhere, but couldn't help being distracted by the XB loaders I came across that claimed to work without it. As pointed out, one used the REF assembler directive, while the other changed 8196, which seemed to enable a shadow "OPT5" routine. The first works fine, once I tack on the DSRLNK/GPLLNK code. Makes the loader program a bit larger, meaning I have to create a lot more junk entries at the beginning of the BASIC loading file (it gets overwritten by the opt5 loader,) so it doesn't overwrite lines that I actually want to execute. But got that taken care of.

 

All that's left is the program that still won't load, even with that. It's smaller, and I checked it's load address (it's >A000,) so that's fine. Wondering if it uses routines that are at different locations in XB (such as XMLLNK.) If that's the case, then I'm wondering if I move the jump table entries around if it would work? Would make the loader even larger, which makes me want to break it into 2 parts. Part one loads without a large list of junk files in the BASIC part. Then it will load the actual loader that does everything else. >2000->3FFF is writable RAM, so maybe I can move the jump table around. Some may be the same. Maybe I'm trying to get too fancy

[Tursi]

BTW, is there any reason why a custom DSRLNK could not search for ROM headers as well?

 

((Old reply:: (Assuming you meant GROM). There's not really any reason... the main gotcha is you need to get into the GPL interpreter and back. GPLLNK shows this can be done, and if you are willing to save off your scratchpad somewhere (like VDP RAM) to preserve the OS state, you don't even need to protect the relevant scratchpad areas to make it run. Of course if you support GPL DSRs then you need to deal with the side effects of CS1, being the screen offset and scrolling and such, unless of course you skip scanning the console GROMs. ))

[Pheonix]

Well, added in a short routine to copy >2018 - >2033 to >2104, this copies the BLWP tables from the XB locations to the E/A locations. Now the difficult game that wouldn't work before works fine, the already working game still worked as well. Could interfere with running BASIC commands, but a reset would be called before that would happen anyways.

 

Will also borrow the code that resets the character pattern table for when I turn of bitmap mode in my menu program. I can put my main menu utilities at >A000 (I'll be finished with them if I need to load an OPT5 program, so their location doesn't matter,) then I can either restore the screen & "RUN" a BASIC program, or just load the OPT5 loader to load the OPT5 program. Haven't done anything with OPT3 programs yet (trying not to alter original program's code.)

 

I did run an experiment. The current OPT5 program loads itself at >FE04, which requires a chunk of BASIC program lines that cannot be referred to again after the CALL LOAD. As an experiment, I changed that to >2E04 (the upper end of the first 4K of the 8K low RAM.) Can't use the upper end of the full 8K block, as that is the DEF table that CALL LINK uses. 8 Bytes per entry, and not 100% sure how large the table is allowed to become. The experiment worked, which would eliminate the loss of the first chunk of the BASIC program. It also proves that the program can be moved around, just have to find out what areas an Option 5 program leaves alone (that is 508 bytes in size.) If another CALL INIT is used prior to loading it, can be placed anywhere from >2600 to >3DFD (will take it up to just before its entry in the DEF table.) After a CALL INIT, that entire area is empty. Though, I guess it "could" be used by something as storage or work space. Don't see any references to it on a quick search though. The key here is, if I can find a 508 byte area of RAM that an Option 5 program isn't using, I can re-compile the OPT5 program into a customized loader. A better understanding of Assembly, and I can design it to actually move itself to a location specified by the CALL LINK arguments. Can't see how to do that, though, without self-altering code. Would make it larger, initially, But the actual re-located program would be a little smaller. Replace the places where labels are actually used (in code,) but aren't relative (such as jumps,) with the new calculated values. Would make the relocation code a little hefty, but could move it to >A000 giving me room to work. Maybe even put it as >2600 originally, so that most of the time it won't need to be relocated.