Trying to learn TI programming

[Asmusr]

 

((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. ))

 

Well, I did actually did mean ROM . Thierry's web site says that "They [DSRs] can be found in GROMs or peripheral card ROMs, but not in cartridge ROM.", but is there any other reason for that than the DSRLNK used? Not that I think it would have any practical value.

 

http://www.unige.ch/medecine/nouspikel/ti99/headers.htm#header%20intro

[Tursi]

Well, I did actually did mean ROM . Thierry's web site says that "They [DSRs] can be found in GROMs or peripheral card ROMs, but not in cartridge ROM.[/size]", but is there any other reason for that than the DSRLNK used? Not that I think it would have any practical value.

Oh.. yeah. No reason I can see. There just won't be a CRU address involved.

[apersson850]

You have understood that Extended BASIC can't run at the same time as the screen is in Bitmap mode, right? XB uses a lot of VDP RAM resources for it's own stuff, even if you have the 32 K RAM expansion in place. The disk drive system also uses VDP RAM for buffering data being read or written.

 

It's possible to start XB, run an assembly program which uses bit map mode and die from there.

When you want to start XB, run assembly with bit map mode and then return to XB, you must make sure you save the XB environment in VDP RAM before start fiddling with creating the bit map mode. Otherwise you can't return.

Since bit map mode requires approx. 12 K bytes in VDP RAM, it's quite a lot of data to hide elsewhere. In a system like mine, which has 96 K RAM instead of 32 K, that's not a problem, but it is in a standard 99/4A.

You can dump it as memory images to files on disk, but you have to do that while you are still in the standard graphics mode, or you'll literally see the disk file system working on the screen.

[Pheonix]

So, XB uses VDP RAM for a lot of what it does? That's frustrating. I was sort of looking forward to multiple colors. Largest free chunk of VDP RAM is 2k, with a 1.25k chunk seperate. I thought this would only interfere with file loading/saving. Though I freely admit I could be wrong about that. The plan was to handle files while in normal mode, switch to bitmap mode for browsing/editing. Switching back to normal mode if it became necessary to handle files again. I guess I could go full uppercase, and use lowercase (and the empty spots for the non-alpha characters,) to create reverse text. Would have to count. Could also go back to using the < & > characters to indicate current file. With presence of load instructions and/or description to indicate enabled files when editing. Would put me back to using PSTR.

[matthew180]

That is the biggest problem with BASIC / XB (aside from them being slow due to double interpretation). The 99/4A only had 16K of RAM in the console*, and that RAM was really the VDP RAM, not direct CPU addressable memory. So BASIC / XB store everything in VRAM, i.e. the program, variables, stack, etc. as well as everything needed for the screen, i.e. name table, patterns, colors, etc. Even with the 32K memory expansion, a lot of VRAM is still used by BASIC / XB. Unfortunately, XB is not the language to use if you want to take full advantage of the video subsystem in the 99/4A. Some people have done a great job squeezing room in VRAM to work around XB, but it only gets you so much.

 

 

* note: aside from the 256 *bytes* of scratchpad RAM on the 16-bit CPU bus.

[apersson850]

When you do have the memory expansion together with XB, then 24 K RAM segment will be used for code lines and numeric variables.

The rest, like the symbol table, string variables, line number table, return stack and scratch pad for string manipulations etc. is still in VDP RAM. You also have disk I/O buffering there.

The scratch pad employs garbage collection, so it will eventually use all available VDP RAM, then collect the unused garbage and start over again. Hence there's not really any corner of VDP RAM it will not touch, when it has been running for a while.

The 8 K RAM part of the expansion is reserved for assembly language support for XB.

[RXB]

When you do have the memory expansion together with XB, then 24 K RAM segment will be used for code lines and numeric variables.

The rest, like the symbol table, string variables, line number table, return stack and scratch pad for string manipulations etc. is still in VDP RAM. You also have disk I/O buffering there.

The scratch pad employs garbage collection, so it will eventually use all available VDP RAM, then collect the unused garbage and start over again. Hence there's not really any corner of VDP RAM it will not touch, when it has been running for a while.

The 8 K RAM part of the expansion is reserved for assembly language support for XB.

Hmm actually this is incorrect.

What you said is true for Console with no 32K.

When XB loads a XB program it moves the Line Number Table, XB Program and Numeric Symbols to the upper 24K of RAM in 32K.

The Strings, VDP STACK and String symbol table stay in VDP RAM.

 

[senior_falcon]

The above demo was made using XB256 and uses HILITE, SCRLUP and SCRLDN.

You can do something along these lines if you can live without lower case characters. Here's the address you need (all in VDP ram):

V0400-05FF Addresses of patterns for characters 32 to 95

V0600-07FF Addresses of patterns for characters 96 to 159 (This includes the sprite motion table so don't expect to use moving sprites. Other than that XB should not complain.

V0800-081F Color table

Remember the >60 or decimal 96 character offset. In the color table V0810 is the address of the color for characters 32 to 39.

You need an assembly sub to load a copy of characters 32 to 95 into V0600-07FF. You can either copy them out of v0400-5FFF or else use a GPL routine to load them:

LI R0,>0600

MOV R0,@FAC

BLWP @GPLLNK

DATA >0018 small capital letters

My routine is set up like this: CALL LINK("HILITE",ROW,COL,#CHARACTERS). For mine it was pretty straightforward because there is a duplicate character set with the patterns inverted. So you read the characters to hilighted from the screen into a buffer, add >80 to each character and then write back to the screen. CALL LINK("HILITE") a second time sets them back to normal by adding >80 to the hilighted text.

You might omit the column if it will always be the same. You would need to read the line to a buffer. Check the first character by comparing with >C0. If low then the first character is less than 96 (remember the screen offset!) this shows that the line has not been hilighted. So you need to add >40 to each of the characters and write them back to the screen. Otherwise you need to subtract >40 from each of the characters. The colors for characters 96 to 159 need to be set so they will appear hilighted. The assembly subroutine that put the patterns to v0600 would be a good place to change the colors. Write 8 bytes with the desired color to v0818, or do it in XB with CALL COLOR.

One interesting possibility is to use a foreground and background color with HILITE. That way the hilight could be in different colors depending on whether the program is XB, or EA5 or something else.

If you don't need to use the cursor, you could custom define characters 30 and 31 for some very limited screen graphics. This has to be done in assembly. Another thing that might be useful is to set the colors for characters 160-255 and 0 to 31. If the foreground and background colors are the same then you can use solid color 8x8 tiles in all possible colors which might be useful for frames or simple graphics.

All these memory locations are safe to use and will not run afoul of the XB interpreter.

Don't worry about XB's VDP use. We'll find you a place for disk I/O buffering.

Forgot to mention that Sprites can be used. The only patterns available would be letters but that would let you put some characters on the screen using different colors than the main and hilighted text.

Edited May 24, 2017 by senior_falcon

[x24b]

Hope this is not off-topic. I am trying to learn TI assembly programming again.

I'm dusting off my old Mini Memory cart and I have always wanted a disassembled source code for the LINES program.

Does it exist in archives or on another site? This is 35 year old curiosity tickling my spine.

I have accessed and run my own BAD assembly code using Bit Map Mode way back then. However, I still want to see how LINES works.

 

Thanks in advance.

Continue propeller spinning...

[Pheonix]

I might keep that in mind if I end up purchasing a cartridge with XB256. I had already considered using the small letters & the empty character slots to set up reverse text. Alternately, I could set up a BASIC program to just load what I need then do everything in assembly instead. Would mean, from what I've read, putting the data into RAM instead of into variables, but that doesn't pose much of a problem. I've done such for other systems. It just makes the assembly program quite a bit larger than I originally planned,

 

Option 1: Everything except small utility programs in XB, single color. Either go back to using > & < to indicate the currently selected file, and marking the configured ones (in the editor,) with a marker of some sort. Or sacrifice lower case letters to build a reverse text list (as in the example above.)

 

Option 2: Use XB to load the assembly program, and the disk directory & list file into a section of RAM. switch to assembly that lets the user select what to load, saving their selection and how to load it to a section of RAM, and/or allow them to edit the menu to add/remove programs to the list & set their load instructions and description. Then switch back to XB (after switching screen mode back to normal.) XB then checks the saved information in RAM and saves an altered list file back to disk. Then it checks to see which program has been requested and follows the provided instructions.

 

Either way is doable. It would probably be easier to do Option 1, but more aesthetically pleasing to do Option 2. Would have to remember not to use variables from before the assembly routine after I return to XB.

[apersson850]

When XB loads a XB program it moves the Line Number Table...

Yes, you're right. I forgot that the line number table also moves to 24 K RAM. But apart from that, it was correct.

[Pheonix]

Thought someone might be interested in my corrected & full Option 5 loader. The other source I found here didn't work because it depended on 2 REF entries (DSRLNK & GPLLNK.) XB doesn't recognize the REF command, and doesn't have the 2 routines anyways. So, I've added DSLLNK & GPLLNK to the code (thanks everyone involved with creating it and pointing it out to me.) I've also located the code at >2600 which is generally available in XB and not usually used by Option 5 programs. Though, I guess they could be at some point in time. I can even see someone putting a data block there. Which, if it is something they want pre-set on program load, could end up over writing the loader before it finishes. Not sure if E/A allows it, but using AORG >2600 could mark the location of where the data block is stored. Could have the main program assemble to AORG >a000 then have a section marked AORG >2600 followed by a DATA >????,>????,... with the character patterns for a custom character set (for example.) Or the other way around. Or, for my current major project, I would attach my Option 5 loader to my main program, and have it load there. Branching to it if an Option 5 program is selected in the menu. If I wanted to get fancy, I could have 2 of them set up, and load the one that is needed for a particular program.

 

Option 5 loader, corrected code:

 
       DEF  OPT5
 
       COPY "XB-EQUATES" * File attached below, just the XB equates copied & corrected from the E/A manual
 
VDPADR EQU >1109      * program file load buffer
VDPPAB EQU VDPADR-265 * header for above
                      * maybe use data values that can be calculated to reduce
                      * actual RAM used
OPLOAD EQU >0500      * command to load
WS     EQU >20BA
 
       AORG >2600     * Load in a generally empty spot in low mem
 
OPT5   LIMI 0
       LWPI WS
       CLR  R7
       CLR  R0
       LI   R1,1
       LI   R2,PAB+9
       BLWP @STRREF   * first file name of program to load
 
DOLOAD LI   R0,VDPPAB * start of header for file load buffer
       LI   R1,PAB    * header buffer (could save some RAM by having part serve double duty)
       LI   R2,10     * The header without the file name.
       A    @PAB+9,R2 * This adds the length of the file name to how much to write
       BLWP @VMBW     * Write the header to VDP RAM
 
       LI   R0,VDPPAB+9 * Load the address of the location of file name length
       MOV  R0,@>8356   * Place length here for routines to use
 
       BLWP @DSRLNK * Call DSRLNK to load the first section
       DATA 8
 
       LI   R0,VDPADR
       LI   R1,WS+6
       LI   R2,6
       BLWP @VMBR  * Load the file header (6 bytes,) into R3-R5
 
       MOV  R3,R3
       JEQ  NOMORE * no more files to load
       SETO R6
       JMP  NEXT1
NOMORE CLR  R6
 
NEXT1  MOV  R7,R7
       JNE  SKIP        * Is this the first file?
       MOV  R5,R7       * Yes, store the program entry address
SKIP   LI   R0,VDPADR+6
       MOV  R4,R2       * Length of file
       MOV  R5,R1       * Where it is supposed to go in RAM
       BLWP @VMBR       * Read the file from VDP to RAM
 
       MOV  R6,R6      * Is last section?
       JEQ  LAUNCH     * Get ready to launch the file
 
       CLR  R1         * More to load
       LI   R0,PAB+10  * Start of file name
       MOVB @PAB+9,R1  * Lenght of file name
       SWPB R1         * Move it to LSB
       A    R1,R0      * Now at last character of file name +1
       DEC  R0         * Now at last character of file name
       MOVB *R0,R1     * Load the last character
       AI   R1,>0100   * Increment
       MOVB R1,*R0     * Save the last character
       JMP  DOLOAD     * Go back to load the next section
 
LAUNCH LI   R1,>2018  * Start of jump table to copy
       LI   R2,>2104  * Location E/A expects them to be at
       LI   R0,14     * How many to copy (7)
MLOOP  MOV  *R1+,*R2+ * Copy from source to destination
       DEC  R0        * Finished?
       JNE  MLOOP     * Loop back to do the next, or continue if finished
 
       LI   R1,EAREGS  * Now setting the VDP Registers
       LI   R2,8       * 8 registers
       CLR  R0         * Set for register 0
NXTREG MOVB *R1+,R0    * Read the first register contents
       SWPB R0         * Move register # to MSB & contents to LSB
       BLWP @VWTR      * Write the register
       SWPB R0         * Move them back (register # in LSB)
       INC  R0         * Increment to next register
       DEC  R2         * counting down
       JNE  NXTREG     * Finished?
       MOVB @EAREGS+1,@>83D4 * Register 2 contents mirrored here?
       LI   R0,CHRADR        * Lets set the character sets
       MOV  *R0+,@FAC
       BLWP @GPLLNK
       DATA >0018      * Using GPL to set character sets
       MOV  *R0+,@FAC
       BLWP @GPLLNK
       DATA >004A      * Using GPL to set character sets
       MOV  *R0+,@FAC
       BLWP @GPLLNK
       DATA >0016      * Using GPL to set character sets
       MOV  R7,@>83E0
       LWPI >83E0
       B    *R0        * Start the program
 
EAREGS DATA >00E0,>000E,>0106,>00F5
CHRADR DATA >0900,>0B00,>0C00
 
PAB    DATA OPLOAD
       DATA VDPADR
       DATA >0000
       DATA 8198
       DATA >00FF
       BSS  255
 
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
 
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
 
       END
 

Attached the XB-EQUATES file.

 

XB-EQUATES.zip

[apersson850]

​After the PAB declaration, there's a BSS 255. I don't remember now, but does the DATA directive restore the byte counter to an even value? If not, everything after that BSS is shifted one byte.

 

A really ugly example of coding of the DSRWS overlaying the code. I guess to save a few bytes, but... Not your fault, I understand you got it from elsewhere.

[apersson850]

 

I'm dusting off my old Mini Memory cart and I have always wanted a disassembled source code for the LINES program.

Does it exist in archives or on another site?

I thought I had it, but I'm probably mixing it up with having the LINES program as an object file on disk. The original is on tape. So it seems I can't help you.

[Pheonix]

Actually, the 255 is me. 255 is the largest a string variable can be in XB. It was originally 15 (with the preceding "size" byte set to 0F.) It also, originally went before the AORG directive. So, making it EVEN wasn't necessary. I tend to put my data blocks at the end of the program so that the EVEN directive isn't necessary. I also put all the EQU directives at the beginning. This was a case of cut & past, then correcting. I raised the data block to 255 so that you could have file/path names longer than 15 bytes. When you take into account the DSK?. that drops down to 10. This is fine, as long as you aren't going to be worrying about multiple drives (with target in an unknown drive,) and if you aren't going to be using sub directories. However, once one of those comes into play, you can forget using it as it originally was (not to mention the REF directive and dependence on the presence of DSRLNK & GPLLNK, despite supposedly being written for XB.) 255 is probably major overkill, but it's safe. It also compiles OK, so E/A evidently will automatically make it EVEN, though I don't usually like to depend on that.

 

That being said, in my code, I'm going to clean things up a bit. Put all the EQU directives together and put all the data blocks at the end. Not that it makes a difference, could just put EVEN at the beginning of code start. to be safe. But, if I move all the data blocks to the end, I can leave out all EVEN directives and will waste no more than a single byte. It's pretty set for now, though I will (in the future,) work on tightening up the code a bit. There was some code provided to alter a RUN "???" line that I am currently working on. It worked fine as is, but there were aspects of it that I didn't care for. Unless you padded your BASIC program, or made sure that it was at the very beginning of your BASIC program, you could very easily overwrite lines you may need before actually getting to the RUN command. Personally, I can see throwing in a couple of REM lines, a GOTO line (to skip the RUN line,) then the RUN line itself at the beginning of any program that may use it. That should give you a fairly large buffer to work with, As long as you don't reference any lines that are effected before the RUN command prior to executing the RUN command, overwriting those lines doesn't make a difference. If you use lines 1-9 for the initial GOTO 10 statement, with RUN being on line 9 and the meat of the program starting at 10, then you can build yourself sufficient buffer space (got it over 256 without any problems,) to run pretty much any path/filename you need to. Then you just GOTO 9 to actually run the program after running the CALL LINK to set the name.

 

I made the exact same program in pure BASIC, but it was exceedingly slow. It looks like I'll be putting pretty much the entire program into Assembly. So, if I return to basic, after restoring VDP RAM to what it was before, it will go straight to the RUN line, which may be changed to END, so the user can shut down, change cart, then start back up. The Assembly program itself can display instructions. Or I can create a BASIC program to display the instructions. Eventually, i may look up how to RUN "dsk?.program" from assembly. I'm sure there is a way

[+Lee Stewart]

​After the PAB declaration, there's a BSS 255. I don't remember now, but does the DATA directive restore the byte counter to an even value? If not, everything after that BSS is shifted one byte.

 

A really ugly example of coding of the DSRWS overlaying the code. I guess to save a few bytes, but... Not your fault, I understand you got it from elsewhere.

 

 

...

It also compiles OK, so E/A evidently will automatically make it EVEN, though I don't usually like to depend on that.

...

 

The DATA directive does, in fact, align the instruction on an even word boundary (see p. 226 of the E/A manual.

 

...lee

[apersson850]

Good, then I didn't have to look to avoid this question spoiling my entire day!

[x24b]

I thought I had it, but I'm probably mixing it up with having the LINES program as an object file on disk. The original is on tape. So it seems I can't help you.

Thanks for the interest in helping as you could. I might be able to pull it off tape and use Editor/Assembler and a disassembler later when I have my full system checked, cleaned, tested and back on-line (don't hold your breath).

Everything is buried in the garage, and summer is not here yet.

I know I can scavenge a console and some minor peripherals right away for learning.

I was hoping to get a jump on it, and had hoped to start with only the console, mini memory, cassette player and LINES cassette tape until then.

Have a great day!

[apersson850]

Well, I can load it from disk, so that's not an issue. But I don't have the source. Disassemble you can always do, but it's more informative with the real source.

[Pheonix]

You might have to have to Disassemble it, then have someone who really understands TI Assembly go through and add comments, labels, & equates.

[Pheonix]

OK, tightened up the OPT5 loader and cleaned it up a bit. Also moved things around with the goal of linking it in to my menu program I'm still working on (now going totally Assembly, to try out the bitmap mode.) Broken it down into 3 parts (GPLLNK, DSRLNK, & OPT5.) For the OPT5 portion, the entire first part will be removed, which is why I moved the CLR R6 line down to DOLOAD (which will change to OPT5 when the first part is chopped.) The VDPPAB is changed from an equate to an address so that it can be adjusted on the fly (and not tie up 255 bytes of VDP RAM for a 10 byte file name.) But the option is there for a path/file name of up to 255 bytes. Mapped out the locations that will need to be updated if it is loaded into another location. Very likely, as the menu program is probably going to be rather large, and thus will load into >A000. Planning to just tack the loaders onto the end. I could make it modular, and then just load OPT5, DSRLNK, & GPLLNK into locations I chose instead of what the files call for.

 

The adjusted code (Option 5 loader is at the end.)

 
       DEF  OPT5
 
       COPY "XB-EQUATES"
 
VDPADR EQU >1000
OPLOAD EQU >0500
GR4    EQU  GPLWS+8
GR6    EQU  GPLWS+12
LDGADD EQU  >60
XTAB27 EQU  >200E
GETSTK EQU  >166C
PUTSTK EQU  >50
TYPE   EQU  >836D
NAMLEN EQU  >8356
GR4LB  EQU  >83E9
GSTAT  EQU  >837C
 
 
       AORG >2F18
 
*** GPLLNK ***
 
GLNKWS BSS  14
GPLLNK DATA GLNKWS
       DATA GLINK1
RTNAD  DATA XMLRTN
GXMLAD DATA >176C
       DATA >0050
       BSS  8
 
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 ***
 
DSRLNK DATA DSRWS,DLINK1
 
DSRWS
 
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 @DSRWS+7,@VDPWA
       MOVB R3,@VDPWA
       SZCB R12,R15
       MOVB @VDPRD,R3
       SRL  R3,5
       MOVB R3,*R13
       JNE  SETEQ
       COC  @GSTAT,R12
       JNE  DSREND
SETEQ  SOCB R12,R15
DSREND RTWP
 
 
*** Option 5 Loader ***
 
OPT5WS BSS  32
 
OPT5   LIMI 0
       LWPI OPT5WS
       CLR  R0
       LI   R1,1
       LI   R2,PAB+9
       BLWP @STRREF     * load the file name
       MOVB @PAB+9,R2
       SRL  R2,8
       S    R2,@VDPPAB  * adjusting VDPPAB to correct size
 
DOLOAD CLR  R6          * Clear the start address holder
 
LLOOP  MOV  @VDPPAB,R0
       LI   R1,PAB
       MOV  @PAB+9,R2
       AI   R2,>10
       BLWP @VMBW       * Copy PAB to VDP RAM
 
       AI   R0,9
       MOV  R0,@>8356
       BLWP @DSRLNK
       DATA 8           * Load file
 
       LI   R0,VDPADR
       LI   R1,OPT5WS+6
       LI   R2,6
       BLWP @VMBR       * Copies file header to R3, R4, & R5
 
       MOV  R6,R6       * Check if it's the first file or not
       JNE  SKIP
       MOV  R5,R6       * If it is, save the start address
SKIP   LI   R0,VDPADR+6
       MOV  R4,R2
       MOV  R5,R1
       BLWP @VMBR       * Write the loaded data to RAM
 
       MOV  R3,R3       * Is it the last file?
       JEQ  LAUNCH
 
       LI   R0,PAB+9    * File name size location
       MOVB *R0,R1
       SRL  R1,8
       A    R1,R0       * Now pointing at last character of file name
       MOVB *R0,R1
       AI   R1,>0100
       MOVB R1,*R0      *Last character now incremented & saved
       JMP  LLOOP
 
LAUNCH LI   R1,>2018
       LI   R2,>2104
       LI   R0,14
MLOOP  MOV  *R1+,*R2+
       DEC  R0
       JNE  MLOOP      * My routine to copy XB jump table to E/A
 
       LI   R1,EAREGS
       LI   R2,8
       CLR  R0
NXTREG MOVB *R1+,R0    * This copies the VDP registers E/A expects
       SWPB R0
       BLWP @VWTR
       AI   R0,>0100
       SWPB R0
       DEC  R2
       JNE  NXTREG
       MOVB @EAREGS+1,@>83D4
 
       LI   R0,CHRADR  * Also the character sets are reset (really necessary?)
       MOV  *R0+,@FAC
       BLWP @GPLLNK
       DATA >0018
 
       MOV  *R0+,@FAC
       BLWP @GPLLNK
       DATA >004A
 
       MOV  *R0+,@FAC
       BLWP @GPLLNK
       DATA >0016
 
       MOV  R6,@GPLWS
       LWPI GPLWS
       B    *R0
 
EAREGS DATA >00E0,>000E,>0106,>00F5
CHRADR DATA >0900,>0B00,>0C00
VDPPAB DATA VDPADR-10     * Can just subtract file name length to make accurate
PAB    DATA OPLOAD
       DATA VDPADR
       DATA >0000
       DATA >2006
       DATA >00FF         * Loading in clear area, DSS for file name shouldn't
                          * be needed.
       END
 

GPLLNK length is 84 bytes

DSRLNK length is 116 bytes

OPT5 length is 250 bytes + length of the file name

 

Total lenght is 450 bytes + the length of the file name. Still takes forever to actually load.

[Pheonix]

Seriously considering having CALL LOAD load the smallest file I can make to then load my menu program & run it. The menu program is growing rather large (just in the planning & graphing phase, the individual modules are rather small IMHO.) Load times in assembly are extremely fast (comparatively.) A 450 byte CALL LOAD takes 10 seconds, while the 22 Kb game takes less than a second. So XB will display a screen saying "loading menu" as it loads the small loader into RAM. Then it switches to the assembly loader that loads the larger menu program in a fraction of the time that it took to load the much smaller assembly code loader. Also been reading up on disk access to see if I can bypass the need for DSRLNK & GPLLNK (not that they are very big,) but with XB's load times, that 200 bytes equates to 4-5 seconds

 

[apersson850]

Yes, you can take control of the disk access directly (I've done that, but for another reason). But then you run into the issue that different disk controllers work in different ways, so you either have to try to figure out which one you are dealing with, or you'll only be compatible with the model you write the code for. The purpose of the DSR is of course to hide such differences from the user's applications.

[RXB]

Seriously considering having CALL LOAD load the smallest file I can make to then load my menu program & run it. The menu program is growing rather large (just in the planning & graphing phase, the individual modules are rather small IMHO.) Load times in assembly are extremely fast (comparatively.) A 450 byte CALL LOAD takes 10 seconds, while the 22 Kb game takes less than a second. So XB will display a screen saying "loading menu" as it loads the small loader into RAM. Then it switches to the assembly loader that loads the larger menu program in a fraction of the time that it took to load the much smaller assembly code loader. Also been reading up on disk access to see if I can bypass the need for DSRLNK & GPLLNK (not that they are very big,) but with XB's load times, that 200 bytes equates to 4-5 seconds

 

In order to bypass the DSR you need to do Sector Access and that opens up a different larger can of worms unless you know exactly the sectors to load or save.

 

I have a CALL SECTOR in RXB that is all GPL, but it is insanely small in comparison to loading or saving files of any size.

 

Anyway Sector access could be a solution if you know everything about that disk

Edited May 28, 2017 by RXB

[Pheonix]

Yeah, just going to use the DSRLNK & GPLLNK programs I have now. At 200 bytes, it's not like they memory hogs or anything. At the most, I would just copy the "section" of each into my code instead of using a BLWP call for them. though, I don't think I'll even do that. I've also successfully altered the OPT5 program to be relocatable (manually,) in 1, 2, or 3 parts (DSRLNK, GPLLNK, & OPT5,) depending on the needs of whatever addresses the OPT5 program needs. I don't have access to any, but I've read of some that use scattered locations leaving only small chunks of RAM free (and spread out.) As long as I can find a 84 byte, a 116 byte, & a 242 + length of file path/name byte chunk free (even if they are in 3 separate locations, I can set up my loader to get the program into RAM and loading. I honestly cannot see any way to make them smaller, though.