SuperCart Construction

[+FarmerPotato]

My utility Supersave won’t help you make the final cartridge image (though that would have been a neat addition) but you can take the E/A utilities library out of it for your own use. Then you would have no more REFs. 
 

 

[GDMike]

Thanks Lee on that clarification for me. I never knew.

So im guessing I could I always push a copy of that 3k area where that table is prior to running my program, this way I don't need to push my program to upper ram like I intended?, as that was to avoid the ref problem. 

Edited December 13, 2019 by GDMike

[Tursi]

I'm going to back up a step and look that the 3 screenshots stacked up back there. Let's walk through what you have.

 

First, you have a standard cartridge header. I believe we have reached a point where that is working for you, and it starts executing at ENTRY. This leads me to my suggestion 1:

 

1) move your EVEN directive to after the TEXT directive, but before the BSS. This is because BYTE and TEXT can (potentially) misalign your address pointer, but the workspace at WS /must/ start at an even address. You are currently okay because the text plus text length byte make 10, which is even, but if you changed the text length it could break the app. You don't need an EVEN on the ENTRY line. In fact:

 

2) You don't need an ENTRY line in this app. Just put START in your header instead and delete that line.

 

You then execute a copy loop that uses R3, R9 and R10 to copy 1000 words (2000 bytes) from 'CART' to 'RAMU'. I don't see CART defined, but your comment says that it is at >6500. RAMU is EQU'd to >A000. After the copy, you branch to HR, which I don't see, but the comment says that it is at >A038. 

 

Assuming that your cartridge successfully has the target program fit in less than 2000 bytes, and is loading in the cart at >6500, and actually has code at >A038, this should work. The program shown in the second two screenshots does start at >A038, if it actually begins at >A000, of course.

 

3) Recommend that the second program have an AORG >A000 directive at the beginning. You have other software relying on it starting at >A000, so you should make sure that it does, and not rely on assumptions or side effects.

 

You say the second program works once, so I won't fuss with it too much, but lets talk about how to build this. The one thing I do recommend, is to make the first instruction executable. This gives you a lot of flexibility and increases the simplicity of running it. If you wanted an EA#5 PROGRAM image, it would be mandatory, and it's very easy. Just change the first instruction to "B @START".

 

Since your loader assumes that this other program lives at >A000, you should also use an AORG directive to insist upon it. So I'd change the beginning of that other program to look like this:

 

      REF VMBW,VSBW
      DEF START
      AORG >A000        * force absolute origin
      B @START          * jump over any data
MG1   TEXT 'IM RUNNING FROM HIGH RAM'
      EVEN              * always EVEN after TEXT or BYTES are done
WS    BSS 32
START LWPI WS
...

     
To build the working Supercart image on a real TI is harder, IMO, than using a PC to do it externally. The simplest way, IMO, might be to make it build itself. In my opinion, you do this in two steps -- a process to assemble the data in the right place, and a process to run the data.

 

Here's a rough stab at updating your original cartridge program, aimed at making that second program work:

 

* MAKE is a new program that will put all the data in the right place
  DEF MAKE

 

* cartridge header
  AORG >6000
  DATA >AA01
  DATA 0
  DATA 0
  DATA MNU
  DATA 0
  DATA 0
MNU
  DATA 0
  DATA START
  BYTE >09
  TEXT 'E/A NOTES'
  EVEN

 

* lets put our workspace in scratchpad, then this will even work from ROM  
WS EQU >8300

 

* lets define our pointer at the top where they are easier to find
* target of program
RAMU EQU >A000

* size of program in words
RAMS EQU 1000

 

* target of EA utils
EAU EQU >2000
* size of EA utils in words
EAS EQU 900

 

* the copy code starts here
START
  LWPI WS
  LIMI 0
  
* load the program to high memory
  LI R3,RAMS      * it's slightly more standard to decrement and jump than increment and compare
  LI R9,CARTPR
  LI R10,RAMU
LP1
  MOV *R9+,*R10+
  DEC R3
  JNE LP1         * DEC has an implied compare to 0!
  
* same deal, but load the EA utils to low memory
  LI R3,EAS
  LI R9,CARTEA
  LI R10,EAU
LP2
  MOV *R9+,*R10+
  DEC R3
  JNE LP2
  
* now it's safe to jump directly to the program!
* if we make the first instruction executable, we don't
* need to track the start address, just go to the first one
* otherwise we could put an absolute address here. Don't
* BLWP, we aren't calling a vector, rather, we are
* permanently transferring control.
  B @RAMU

 

* So that's the boot cartridge, and it's almost the same.
* the next little program will copy the data we use into
* place, ready to go. Note that MAKE will only exist the
* first time we load it, like the old crashes, the REFDEF
* table will go away after a power cycle. 
*
* all this does, is reverse the other copy loop, and
* copy data from RAM /into/ the Supercart, ready to go.
*
* Note no LWPI, by using the EA's workspace we can
* return when we're done.


MAKE
* copy the program from RAM into the Supercart
  LI R3,RAMS
  LI R9,CARTPR
  LI R10,RAMU
LP3
  MOV *R10+,*R9+  * opposite direction to above
  DEC R3
  JNE LP3         * DEC has an implied compare to 0!
  
* same deal, but load the EA utils FROM low memory
  LI R3,EAS
  LI R9,CARTEA
  LI R10,EAU
LP4
  MOV *R10+,*R9+
  DEC R3
  JNE LP4

* we're done, the cart is ready
  B *R11
  
* Now, we allocate some space for the data...
CARTPR   BSS 2000
CARTEA   BSS 1798

* all done! Mark the end of the memory space
  END

 

So what have I changed? Some minor tweaks which I commented, but mostly, I added a second copy loop for the EA utilities. Then, I added a separate 'make' program to prepare it. Here's how it works:

 

Assemble both this, and your test program with the modification that I suggested to put the B@ at the beginning. Let's say you saved them as CARTLOAD and TEST, but whatever names you want.

 

Go into E/A LOAD AND RUN, and first load up CARTLOAD. This will first load the Editor/Assembler utilities to load RAM (without telling you!), and set up all the DEFs for them in the REF/DEF table as available. Then it will load the loader program that we created /directly/ into the SuperCart RAM, and will add the DEF 'MAKE' in the REF/DEF table, indicating that MAKE is now available.

 

Next, without exitting, load up TEST. This will load your test program into high memory at >A000. It will search the REF/DEF table for VMBW and VSBW, and since they are present, it will patch the instructions that use them with the final actual addresses to those functions. It will also add START to the table as now available, but we aren't going to use it. It's not a problem - having a DEF like that is helpful for testing and has no longterm penalty.

 

So finally, without exitting, hit enter to get to PROGRAM NAME, and enter MAKE. This will (very quickly!) run the copy code which copies the test program from high RAM to the supercart, and also copies the EA utilities to the supercart. Note that both the utilities and the test program are fully "linked" and can only /run/ at their original addresses, we are just storing them for later use.

 

(Edit: It actually looks like you had the idea of the copy from RAM to SuperCart, so I guess you know that part well enough )

 

The supercart SHOULD now be ready. You should be able to quit, test, and have it work. You should also be able to power cycle the PEB (which blows away the REF/DEF table with the rest of RAM!), test again, and it should still work.

 

I've tested this, so it should work. Now, the bigger issue of fitting your larger program with the EA routines at the same time we can tackle once you have this going.

 

I did a silly stream, though I think I failed to show the end, here: https://www.twitch.tv/videos/520821176

 

 

[GDMike]

Wow, ok.

Yes, some of my code was a bunch of what-ifs and way back before starting I had it aorgd to A000 but with all the changes it got experimented with and the even statements were just part trying to resolve the B @start/entry sloppily as I didn't know I could change the entry name to the program name, start.

I'm going to try another test late today but can't wait. I really appreciate the explanation and that explanation from Lee was extremely helpful too.

What's funny is I thought initially moving the program to HRam and executing it successfully would be my hardest part of this project, and it turned out reversed. I kill me, always a surprise around the corner.

Thanks everyone for helping me out. Farmer potato, I appreciate that code lend, just in case I need it. 

I'll let ya know what I do with this and how my next attempt turns out.

 

 

[GDMike]

I'm happy right now..

CFG, a d/f 80 program pulls >2000 - >2705

(900 bytes) into >7C00, a one time run

E/A notes pushes that block back to>2000 at startup.

And my current E/A notes uses VMBW,KSCAN,VMBR etc...

So far things are testing great! 

Looks like I have around 6980 bytes free for program space, and 24K of user space. Thank you everyone!!!!

Edited December 13, 2019 by GDMike

[GDMike]

BTW, I will end up moving the main program up to>A000 and running it from there due to the bank swiitching that will be going on, but this was just a test, I think we've concluded that the running from>A000 was going to be ok. 

So to digest what I have:

1. A CFG program runs and moves that REF table to the higher end of Cart space. It's an independent file/run that needs to run prior to anything else.

2. The E/A Notes program runs and sets itself up as a cartridge with a menu.

The first part of the E/A notes run pushes that REF table back down to>2000 so that the rest of the program can use those utils.

Future changes: I will have the E/A notes program look and see if the REF table exists in the cart, if not then it will make the necessary moves. This way I can get rid of the CFG run altogether.

3. The E/A notes gets moved to high mem so the user can do bank switching and it won't affect the program, once the user decides to either quit OR make a SAVE, then the cart free space is updated with the written data from the user.

[Tursi]

10 hours ago, GDMike said:

I kill me, always a surprise around the corner.

That's just called computers.

 

[+Lee Stewart]

Looks like a plan. However, I would not call the E/A utilities the “REF table” because you will not be copying any part of the loader or the REF table. You only need the E/A utilities from >2000 – >2397 (the first 920 bytes of low expansion RAM) for your linked programs to run properly.

 

...lee

[Tursi]

3 hours ago, GDMike said:

BTW, I will end up moving the main program up to>A000 and running it from there due to the bank swiitching that will be going on, but this was just a test, I think we've concluded that the running from>A000 was going to be ok. 

So to digest what I have:

1. A CFG program runs and moves that REF table to the higher end of Cart space. It's an independent file/run that needs to run prior to anything else.

2. The E/A Notes program runs and sets itself up as a cartridge with a menu.

The first part of the E/A notes run pushes that REF table back down to>2000 so that the rest of the program can use those utils.

Future changes: I will have the E/A notes program look and see if the REF table exists in the cart, if not then it will make the necessary moves. This way I can get rid of the CFG run altogether.

3. The E/A notes gets moved to high mem so the user can do bank switching and it won't affect the program, once the user decides to either quit OR make a SAVE, then the cart free space is updated with the written data from the user.

Just a quick clarification -- you are not moving or even touching the REF/DEF table. You are moving the utility code, but the table is not even in memory anymore -- it lives at roughly >3F00. You don't need it, because after you have finished the LOAD AND RUN all the references have been looked up and resolved -- your program is 'linked' at that point and doesn't need the REF/DEF table. I show this in my video when I show that the REF/DEF table at >3F00 has been erased, and is NOT reloaded.

 

Unlike modern systems that have such tables for DLLs, TI software never looks function addresses up at runtime. It's all changed to absolute calls at load.  

[Tursi]

2 minutes ago, Lee Stewart said:

Looks like a plan. However, I would not call the E/A utilities the “REF table” because you will not be copying any part of the loader or the REF table. You only need the E/A utilities from >2000 – >2397 (the first 920 bytes of low expansion RAM) for your linked programs to run properly.

 

Why do you get >2397 and I get >2705?

 

When I look at the debugger, LOAD AND RUN loads data up to >2704 (I capture >2705 to get the whole word)... I assume that's all necessary. Is the later code optional for some apps?

 

[GDMike]

And I was just talking with Owen, and that was brought up, and I got the message basically when he said the e/a Grom has those utils.

[GDMike]

l I know is that my utils are working, my program is working.. and I'm losing brain cells. I did watch that video, but on my phone, bad idea..I need to get involved with the debugging tool you made. I just don't know when .do you have a video somewhere explaining that tool. I really need to spend a moment with it and a good decent example file.

 

 

Edited December 14, 2019 by GDMike

[+Lee Stewart]

19 minutes ago, Tursi said:

Why do you get >2397 and I get >2705?

 

When I look at the debugger, LOAD AND RUN loads data up to >2704 (I capture >2705 to get the whole word)... I assume that's all necessary. Is the later code optional for some apps?

 

I was going from Thierry’s disassemly, which ends at >267B. That, though, is the end of the loader, which is not needed, is it? DSRLNK is the last utility before the loader and ends at >2397 in his listing.

 

...lee

[Opry99er]

The Classic99 Debugger is amazing.  You can set breakpoints, watch a heat map of RAM, see when errors occur and address them immediately.... 

 

Even for a novice like myself, it is very intuitive.

[Tursi]

I did notice that LOADER was the last function - agreed it's not needed, but I wasn't sure if there were subroutines after it.  That's handy though, since that saves GDMike a lot of memory to use your address instead of mine - maybe enough that it'll "just fit".

 

I used to have a couple of videos that went deep on using the Classic99 debugger, but I nuked my YouTube channel over the current legal crap. I moved a lot of my videos to my own Peertube instance at http://pt.harmlesslion.com, but unfortunately I discovered too late that I hadn't saved copies of the debugger vids.

 

Edited December 14, 2019 by Tursi

[GDMike]

Copy that. I'll dig into learning that tool even so, I mean I am familiar with the old visual foxpro debugger, so it's not like I'm not familiar with them, so it won't be too difficult for some basic issues. Ty

Yeah- so far, the utils I need are working fine AND opens the door for other similar projects. 

[GDMike]

I just had a dumb thought, why don't I just use the cart for my program and make an area in upper or lower ram for user area THEN as a save option from a menu, have the data moved from ram to a bank in the cart? Duhh...then I don't need to move my program from cart to high ram area to allow bank switching to occur. That seems like - obvious. I'm getting there..

[GDMike]

Success, except it should be referring to bank 2 not bank 1. But it doesn't matter rt now because I haven't programed that portion yet, but the program pushes itself AND the util library into the cart at different addresses as a one time shot. The MENU when selected pushes out both the utils to where they need to be and the program goes back to >A000 then menu does a B to >A000

I have room for 6700 bytes of Program space and 24K of user space while the main program,EAN runs in high Ram and each user screen also resides in upper ram but gets moved to the cart available space as the user selects save. I'm wanting to provide an algorithm that reduces characters that repeat to save space in the cart. I have one idea already, well see how it goes.

 

[GDMike]

I suppose GPLLNK isn't an option anymore within this copy of utils strategy I'm using. It appears most other utils are working.

[+Lee Stewart]

35 minutes ago, GDMike said:

I suppose GPLLNK isn't an option anymore within this copy of utils strategy I'm using. It appears most other utils are working.

 

Code?

 

You really need to be more specific. GPLLNK should work just fine. Just be sure you have not changed GPL workspace R13 (>83FA) and R15 (>83FE) or, if you have, that you restore them to >9800 (current GROM port) and >8C02 (VDPWA—VDP Write Address), respectively, before calling GPLLNK. The GPL interpreter expects them to always have those values. There may be others, but those two are sacrosanct.

 

...lee

[HOME AUTOMATION]

GPLLNK's REF/DEF table entry would normally reside at >3FFA "GPLLNK2100".

 

...or you can just equate a label such as: GPLNK EQU >2100.

 

or just...

 

BLWP @>2100
DATA >????

[+Lee Stewart]

3 hours ago, HOME AUTOMATION said:

GPLLNK's REF/DEF table entry would normally reside at >3FFA "GPLLNK2100".

           ...or you can just equate a label such as: GPLNK EQU >2100.

or just...

                  BLWP @>2100
                  DATA >????

 

I do not think that is the problem. He is using previously linked programs. He just needs to have a copy of the utilities in the right place.

 

You do imply what could be a problem for him, however: @GDMike may already know this, but he needs to be setting up the data properly for the call to GPLLNK. As you imply, he must supply the GPLLNK subprogram code in a DATA statement following the BLWP instruction, as well as set up data in FAC (>834A) and, often, ARG (>835C) and/or other locations, depending on the function called. But—we cannot discern any of this without the relevant code. H-m-m-m, methinks I am beginning to sound like a broken record. 

 

...lee

[GDMike]

Sorry I just saw this..my code is just a simple,

Clr r1

Movb R1,@>837C

Blwp @gpllnk 

Data >0034

But whatever I do with gpllnk my computer crashes.. but all other utils work.

This code works in my regular program not in the cart though so I thought maybe it's because I'm copying the utils..

Edited December 27, 2019 by GDMike

[Stuart]

31 minutes ago, GDMike said:

Sorry I just saw this..my code is just a simple,

Clr r1

Movb R1,@>837C

Blwp @gpllnk 

Data >0034

But whatever I do with gpllnk my computer crashes.. but all other utils work.

This code works in my regular program not in the cart though so I thought maybe it's because I'm copying the utils..

Subprogram >0034 plays the accept tone sound? I have a pencilled note in my E/A manual that interrupts need to be enabled for the sound list to be processed. If interrupts are not enabled, not sure if the routine hangs (like you're finding) or you just don't hear the sound.

 

GPLLNK also won't work with a program that autoruns after loading with the E/A module option 3. I know you're not doing this, but there was some investigation into this in a thread some time ago and a solution found. If you're able to find that thread, it may help in determining what GPLLNK needs in addition to the info that Lee and others have provided above.

 

If all else, fails, I use the code below in one of my programs to play the bad response tone. If you change the frequency in the first line to that of the accept tone, it gets round your problem (assuming you don't need GPLLNK for anything else).

*       Play middle "A" note on generator 1.          
                                                      
        LI R0,>8E0F       Frequency on generator 1.   
        MOVB R0,@>8400    Sound port address.         
        SWPB R0                                       
        MOVB R0,@>8400                                
        LI R0,>9000       Volume: maximum.            
        MOVB R0,@>8400                                
                                                      
*       Delay for approx. 1/2 second.                 
                                                      
        LI R0,>4000                                   
BDR1    DEC R0                                        
        JNE BDR1                                      
                                                      
*       Turn sound off.                               
                                                      
        LI R0,>9F00                                   
        MOVB R0,@>8400                                

 

[GDMike]

I'll try to directly equ the reference as stated above by the home automation. It might just work.

I should have stated that the gpllnk routine I provided the illustration from DOES perform until I do a reboot and copy the utils back into lower ram. At least I can still "beep" with the suggestion of using the sound list.

Thank you. I'll let you know what I find.