Assembly on the 99/4A

[+Vorticon]

3 hours ago, Lee Stewart said:

 

No. It is quite the other way around. This is self-modifying code that replaces the placeholder, >AAAA, with the contents of WORKSV at execution time.

 

...lee

Oh I see. I was thinking of it like interpreted code where the LWPI instruction would come after the MOV instruction and overwrite the WP address. Obviously that would not be the case when the code is compiled then executed. ?

[+Vorticon]

4 hours ago, jedimatt42 said:

The assembler produces the LWPI >AAAA instruction, which is 2 words in the binary. But at runtime, the MOV before it rewrites that instruction for the desired value of the immediate operand. 

 

That move instruction is using @$ which in xas99 is the address of the current instruction. So +8 gets the address of the parameter to LWPI. 

Got it. I don't suppose $ is supported by the TI assembler by any chance?

[+jedimatt42]

(I should have said: "I don't know, but if not you could..." - better answers from others in the next posts)  

 

You should be able to use a label and math.. 

 

      MOV @WORKSV,@THING+2
THING LWPI >AAAA

I think... 

 

Or something like

 

      LI R12,2
      MOV @WORKSV,@THING(R12)
THING LWPI >AAAA

 

[Tursi]

2 hours ago, Vorticon said:

Got it. I don't suppose $ is supported by the TI assembler by any chance?

$ is supported by the TI assembler. Usually only see it used like JMP $, so I don't know how well. Page 53 of the E/A manual.

 

 

[+Lee Stewart]

8 hours ago, Vorticon said:

Got it. I don't suppose $ is supported by the TI assembler by any chance?

 

5 hours ago, Tursi said:

$ is supported by the TI assembler. Usually only see it used like JMP $, so I don't know how well. Page 53 of the E/A manual.

 

TI Forth, fbForth, TurboForth (not sure about Camel99 Forth) all use ‘$’ extensively. It is used primarily in the code field of CODEd words to point to the parameter field (where the executable code for the word usually starts). Here is an fbForth example from the code field through the rest of the definition of MOVE :

*** MOVE ***       ( src dst cnt --- )
* Code Field
MOVE   DATA $+2    <---Code Field word points to Parameter Field (next instruction)
* Parameter Field
       MOV  *SP+,R1        pop cnt to R1
       MOV  *SP+,R2        pop dst to R2
       MOV  *SP+,R3        pop src to R3
       MOV  R1,R1          cnt = 0?
       JEQ  MOVE2          exit if so
MOVE1  MOV  *R3+,*R2+      copy next cell
       DEC  R1             dec counter
       JNE  MOVE1          copy another cell if not done
MOVE2  B    *NEXT          back to inner interpreter

...lee

[+TheBF]

59 minutes ago, Lee Stewart said:

 

 

TI Forth, fbForth, TurboForth (not sure about Camel99 Forth) all use ‘$’ extensively. It is used primarily in the code field of CODEd words to point to the parameter field (where the executable code for the word usually starts). Here is an fbForth example from the code field through the rest of the definition of MOVE :

*** MOVE ***       ( src dst cnt --- )
* Code Field
MOVE   DATA $+2    <---Code Field word points to Parameter Field (next instruction)
* Parameter Field
MOV  *SP+,R1        pop cnt to R1
       MOV  *SP+,R2        pop dst to R2
       MOV  *SP+,R3        pop src to R3
       MOV  R1,R1          cnt = 0?
       JEQ  MOVE2          exit if so
MOVE1  MOV  *R3+,*R2+      copy next cell
       DEC  R1             dec counter
       JNE  MOVE1          copy another cell if not done
MOVE2  B    *NEXT          back to inner interpreter

...lee

Since it was mentioned, Camel99 Forth has the same address structure for the pointer to code as the other indirect threaded systems, but since Camel99 is written in Forth $ is called HERE but it is the same thing.

In Camel Forth Direct threaded version (which I broke a while back  ) there is no pointer to code. The code begins right after the name of the word.

 

[atrax27407]

The source code written by the McGoverns made extensive use of "$".

[+9640News]

Got a question.  Is there a way with the Editor/Assembler module present, to use GPL code to load an EA #5 file (4 parts), into memory?

 

What I would like to do would be to have a keypress detected in a running assembly program, that would load a revised version of the program replacing itself.  It would load the program from >A000 to >FFFC and from >6000 to ~>7A00.

Beery

[HOME AUTOMATION]

This sounds to me like something that could be accomplished from assembly...

Is there a specific reason you want to do this from GPL...

Do you want the USER to be able to enter the file name, or will that be predetermined in the running program?

Perhaps you want to break back into the E/A's GPL code for OPTION 5?

[+9640News]

I want it to be able to load a predetermined filename.  I know I could write a separate loader which in turn after the program ran the new updated version, it would load the final segment (loader) before continuing.  I was hoping to be able to pass some minimal information such as path, and let the EA loader to do the rest without a separate loader segment.

 

Beery

[HOME AUTOMATION]

I tried to cop some entry addresses from Classic99's DEBUGGER.

 

This is as far as I came...

       DEF  RUN
RUN    LI   R1,>6440
       MOVB R1,@>9C02
       SWPB R1
       MOVB R1,@>9C02
       LWPI >83E0
       B    @>70
       END

But, it doesn't seem like this can work...

 

 

Maybe a smarter(...or more awake) programmer can get it to work!

 

...I like the "load your own loader" idea myself.

 

    P.S. I loaded/ran this from >A000, using E/A OPTION 3.

 

  ...Good luck!

[RXB]

8 hours ago, HOME AUTOMATION said:

This sounds to me like something that could be accomplished from assembly...

Is there a specific reason you want to do this from GPL...

Do you want the USER to be able to enter the file name, or will that be predetermined in the running program?

Perhaps you want to break back into the E/A's GPL code for OPTION 5?

Actually Assembly sucks for that as you have to sacrifice some of the 32K to for the loader.

GPL would be a better answer as it can load into VDP/RAM/GRAM and as the VDP PAB and Buffer is in VDP so once started could load all the code.

RAM has to have someplace to run Assembly, GPL runs from the ROM OS and GPL is also built into the Console, so there is you full memory loader.

[+9640News]

4 hours ago, RXB said:

Actually Assembly sucks for that as you have to sacrifice some of the 32K to for the loader.

GPL would be a better answer as it can load into VDP/RAM/GRAM and as the VDP PAB and Buffer is in VDP so once started could load all the code.

RAM has to have someplace to run Assembly, GPL runs from the ROM OS and GPL is also built into the Console, so there is you full memory loader.

That's nice, but I need to know how to do it as I can not say I have ever seen an example.  In my example, I want to be able to load UTIL1, UTIL2, UTIL3, and UTIL4 with UTIL1, UTIL2, and UTIL3 loading into the >A000 to >FFFB memory space, and UTIL4 as the 4th file in the chain loading into the 8K ram of an EA cartridge at >6000.  The routine would pass the filename to be loaded without having to retype the program name.

 

Basically, I would have a keycheck detection test for a specific character in my program, and if it found the key, it would B/BL/BLWP, etc. to the GPL code routine and reload the program.  It's not restarting the same program, as the program would have been modified from its current running state.  This would save exiting the program, dropping back through the main menu and editor screens, typing the filename, etc.  Yeah, a bit lazy, but when I thought of the idea, I thought others may like the idea as well.

 

Beery

[senior_falcon]

It would load the program from >A000 to >FFFC and from >6000 to ~>7A00.

 

It looks like RAM past >7A00 is usable, so you could roll your own and put it there.

Of course, your program will probably bloat up (they always do), so that memory area may wind up not being available.

 

Edited August 31, 2021 by senior_falcon

[+9640News]

34 minutes ago, senior_falcon said:

It would load the program from >A000 to >FFFC and from >6000 to ~>7A00.

 

It looks like RAM past >7A00 is usable, so you could roll your own and put it there.

Of course, your program will probably bloat up (they always do), so that memory area may wind up not being available.

 

The program has indeed been growing, thus the reason of hoping to find a way to do it without writing a new loader.  I was hoping I could use something inside the EA module to accomplish the task at hand with minimal code.

[+TheBF]

4 hours ago, 9640News said:

That's nice, but I need to know how to do it as I can not say I have ever seen an example.  In my example, I want to be able to load UTIL1, UTIL2, UTIL3, and UTIL4 with UTIL1, UTIL2, and UTIL3 loading into the >A000 to >FFFB memory space, and UTIL4 as the 4th file in the chain loading into the 8K ram of an EA cartridge at >6000.  The routine would pass the filename to be loaded without having to retype the program name.

 

Basically, I would have a keycheck detection test for a specific character in my program, and if it found the key, it would B/BL/BLWP, etc. to the GPL code routine and reload the program.  It's not restarting the same program, as the program would have been modified from its current running state.  This would save exiting the program, dropping back through the main menu and editor screens, typing the filename, etc.  Yeah, a bit lazy, but when I thought of the idea, I thought others may like the idea as well.

 

Beery

From what I see it would work for you if the loader was at >2000   ?

I might be able to squeak a custom kernel with a loader program into the 8K  at >2000.

Would that work?

[RXB]

Well the EA module could do >A000 to >FFFF but only way I load at >6000 to >7FFF is EA3, then again I could use Program Image too I suppose, but more work.

To solve your problem I would load your program as Program Image of >A000 to >FFFF and another Program Image for >6000 to >7FFF and then put the loader at above 

Assembly support in Lower 8K >2000 to >3FFF

[+9640News]

Unfortunately, the >2000 to >3FFF space is full of all kinds of buffers.  If the EA #5 loader turns out to not be an option with GPL access, I will resort to a custom loader myself and squeeze it up as high as I can in the >7000 range to give as much room for program growth.

 

Rich, I thought there may have been a way to give it the starting image name so that the EA 5 loader for program image files would take over completely for all 4 image files.  That's how I load the program now, all 4 segments.

 

2 minutes ago, RXB said:

Well the EA module could do >A000 to >FFFF but only way I load at >6000 to >7FFF is EA3, then again I could use Program Image too I suppose, but more work.

To solve your problem I would load your program as Program Image of >A000 to >FFFF and another Program Image for >6000 to >7FFF and then put the loader at above 

Assembly support in Lower 8K >2000 to >3FFF

 

 

1 minute ago, TheBF said:

From what I see it would work for you if the loader was at >2000   ?

I might be able to squeak a custom kernel with a loader program into the 8K  at >2000.

Would that work?

 

[RXB]

LOL thinking same!

I would use RXB to solve your issue using RXB 2020 command CALL PLOAD to load >A000 to >FFFF and >2000 to >3FFF, but then no access to >6000 to >7FFF

Which is why I recommend a SAMS instead, there is NO LIMIT to your program size unless you can exceed 1 Meg?

[+TheBF]

12 minutes ago, 9640News said:

Unfortunately, the >2000 to >3FFF space is full of all kinds of buffers.  If the EA #5 loader turns out to not be an option with GPL access, I will resort to a custom loader myself and squeeze it up as high as I can in the >7000 range to give as much room for program growth.

 

Rich, I thought there may have been a way to give it the starting image name so that the EA 5 loader for program image files would take over completely for all 4 image files.  That's how I load the program now, all 4 segments.

So you just want to re-enter the E/A loader from within your program and pass it a file name string.

That seems like a reasonable request. All that code is just sitting there in ROM and GROM.

However it is a TI-99.  

 

[+Lee Stewart]

30 minutes ago, 9640News said:

The program has indeed been growing, thus the reason of hoping to find a way to do it without writing a new loader.  I was hoping I could use something inside the EA module to accomplish the task at hand with minimal code.

 

As long as you leave the E/A utilities alone in low expansion RAM,

1. It should take a minimal amount of ALC to write a simple memory image loader.
2. You should also be able to write an ALC routine that would use GPLLNK to execute the E/A cartridge’s “5 RUN PROGRAM FILE” program loader at a place after the file entry (supplied by your code). 

You can do (1) with your own DSRLNK. However, though you could use your own GPLLNK to jump into the E/A GROM, you have no choice but to leave E/A’s DSRLNK at >22B2, with its WP at >209A, because the E/A program image loader code calls it.

 

...lee

[Tursi]

I'm confused about the loader request... is there a reason the scratchpad loader we wrote as a group won't work? It can load to the entire 32k of RAM (and cartridge space, if it's RAM, is not an issue either), and doesn't require any additional code (including the EA utilities, it includes its own DSRLNK).

 

This thread has the XB version, but includes the source code so you can pull it out and use it at will.

 

[+9640News]

3 hours ago, Tursi said:

I'm confused about the loader request... is there a reason the scratchpad loader we wrote as a group won't work? It can load to the entire 32k of RAM (and cartridge space, if it's RAM, is not an issue either), and doesn't require any additional code (including the EA utilities, it includes its own DSRLNK).

 

This thread has the XB version, but includes the source code so you can pull it out and use it at will.

 

I was not aware of this loader.  I will look over the source code.  Thanks.

 

Beery

 

[senior_falcon]

If Tursi's loader does not work out for you, I have identified the part of the E/A code that sets up the PAB. I believe that you could set up the PAB the same way and then GPLLNK to the code that follows that to load and run the file. Setting it up that way might be a little more compact, but of course then you are dependent on the E/A cartridge.

(I should add that Tursi's loader is probably a better solution because you can know exactly what is going on.)

Edited September 1, 2021 by senior_falcon

[+9640News]

47 minutes ago, senior_falcon said:

If Tursi's loader does not work out for you, I have identified the part of the E/A code that sets up the PAB. I believe that you could set up the PAB the same way and then GPLLNK to the code that follows that to load and run the file. Setting it up that way might be a little more compact, but of course then you are dependent on the E/A cartridge.

(I should add that Tursi's loader is probably a better solution because you can know exactly what is going on.)

One has to have ram across the full 8K page at >6000 to >7FFF, so outside of a Gram emulator (Gram Kracker comes to mind) that leaves that memory space as RAM and not ROM, is there anything besides the EA cartridge with the 8K bank that would allow loading EA #5 files?  Minimemory is only 4K, so that would not work.  Myarc XBII 2.xx has ram, but no EA5 loader ability.  I did not think SAMS had the full 8K at that mapped area, but I may be wrong.  

 

At the time when I first started modifying the AFTERHOURS BBS program, there was not a SAMS sidecar with the TIPI available which has now changed so other options are available for the future.

 

Beery