Jump to content
matthew180

Assembly on the 99/4A

Recommended Posts

3 minutes ago, senior_falcon said:

VSBW, VSBR, VMBW, VMBR, VWTR are all there and can be used as usual. NUMASG, NUMREF, STRASG, STREF cannot work. They were written to pass values to and from an XB program. They would have no idea where the strings and numbers are kept in a compiled program. Since everything is integer, CFI and CIF have no purpose and are simply bypassed.

 

Got it. Thanks for the info.

  • Like 1

Share this post


Link to post
Share on other sites

TI-Net BBS took advantage of this.

 

The LOAD program is made with SYSTEX (Barry Boone) and it fills up the low memory with object code. Then it chains to BBS. 

It can chain to “Doors” programs (that is, games). When the game exits, it hangs up and runs BBS again. Assembly routines are only loaded one time. 
 


 


 

 

  • Like 2

Share this post


Link to post
Share on other sites
29 minutes ago, Vorticon said:

Got it. Thanks for the info.

I should add that this is totally transparent to the user. When you test the program in XB you can use any of the assembly support utilities as desired. When it's time to compile there is a utility called FIXAL that modifies the assembly support routines so they will work with the compiler.

If you use XB 2.8 G.E.M. you will find that loading the assembly routines for testing happens 20X faster

  • Like 2

Share this post


Link to post
Share on other sites

It has been years since I looked at it, but I seem to recall that you can force XB to use high memory (A000-FFFF) for assembly and low memory (2000-3FFF) plus VRAM for XBASIC code.  It takes some effort and probably breaks a few things.

Share this post


Link to post
Share on other sites
4 minutes ago, Jeff White said:

It has been years since I looked at it, but I seem to recall that you can force XB to use high memory (A000-FFFF) for assembly and low memory (2000-3FFF) plus VRAM for XBASIC code.  It takes some effort and probably breaks a few things.

You can AORG an ALC program into high memory, but it will have to coexist with the XB program. I am not aware you could force XB into low memory but I might be wrong there. Besides, since the idea to mix XB and assembly is to avoid the tediousness of pure assembly for complex tasks while delegating features not available in XB or too slow to assembly, restricting XB to the lower 8K would likely be too restrictive for most projects...

Share this post


Link to post
Share on other sites
2 hours ago, Vorticon said:

You can AORG an ALC program into high memory, but it will have to coexist with the XB program. I am not aware you could force XB into low memory but I might be wrong there. Besides, since the idea to mix XB and assembly is to avoid the tediousness of pure assembly for complex tasks while delegating features not available in XB or too slow to assembly, restricting XB to the lower 8K would likely be too restrictive for most projects...

Actually, with some cleverness there is a great deal of flexibility in where XB can put programs. For example:

CALL INIT::CALL LOAD(-31868,0,0,0,0) Type SIZE and you'll see that the memory expansion is turned off and XB will run completely from VDP ram. But CALL LOAD didn't get the message, so you can still poke values wherever you want. Or you can CALL LOAD an object file anywhere in the memory expansion. You'll need to AORG the code to high memory, but you can use all 32K for assembly, plus about 12K for the XB program in VDP.

 

Since you can put the XB program into 12K of VDP ram, it wouldn't make much sense to put it in the 8K low memory.

 

If 24K is not large enough for your XB program, you can split the program between high and low memory and use all 32K for an XB program. In the Game Developer's Package there is a file called XB32K.OBJ which lets you do just that.

 

HMLOADER lets you embed assembly routines in an XB program and run them from high memory. This makes a neat, self contained package that contains everything in one program.

 

  • Like 1

Share this post


Link to post
Share on other sites
15 minutes ago, senior_falcon said:

Actually, with some cleverness there is a great deal of flexibility in where XB can put programs. For example:

CALL INIT::CALL LOAD(-31868,0,0,0,0) Type SIZE and you'll see that the memory expansion is turned off and XB will run completely from VDP ram. But CALL LOAD didn't get the message, so you can still poke values wherever you want. Or you can CALL LOAD an object file anywhere in the memory expansion. You'll need to AORG the code to high memory, but you can use all 32K for assembly, plus about 12K for the XB program in VDP.

 

Since you can put the XB program into 12K of VDP ram, it wouldn't make much sense to put it in the 8K low memory.

 

If 24K is not large enough for your XB program, you can split the program between high and low memory and use all 32K for an XB program. In the Game Developer's Package there is a file called XB32K.OBJ which lets you do just that.

 

HMLOADER lets you embed assembly routines in an XB program and run them from high memory. This makes a neat, self contained package that contains everything in one program.

 

This is the realm of black magic! I am only but a poor accolyte...

 

Share this post


Link to post
Share on other sites
19 hours ago, senior_falcon said:

Actually, with some cleverness there is a great deal of flexibility in where XB can put programs. For example:

CALL INIT::CALL LOAD(-31868,0,0,0,0) Type SIZE and you'll see that the memory expansion is turned off and XB will run completely from VDP ram. But CALL LOAD didn't get the message, so you can still poke values wherever you want. Or you can CALL LOAD an object file anywhere in the memory expansion. You'll need to AORG the code to high memory, but you can use all 32K for assembly, plus about 12K for the XB program in VDP.

 

Since you can put the XB program into 12K of VDP ram, it wouldn't make much sense to put it in the 8K low memory.

 

If 24K is not large enough for your XB program, you can split the program between high and low memory and use all 32K for an XB program. In the Game Developer's Package there is a file called XB32K.OBJ which lets you do just that.

 

HMLOADER lets you embed assembly routines in an XB program and run them from high memory. This makes a neat, self contained package that contains everything in one program.

 

I think that CALL LOAD is just clearing the values for first free address (FFA) and last free address (LFA) of 24K to make it “disappear”.  I am pretty sure that I was able to point the FFA and LFA using values in the range 2000-3FFF and manipulated some other values to CALL LOAD object code into 24K without using AORG.  I had limited success.

 

It made sense to do it at the time.

 

I could be misremembering.  

Share this post


Link to post
Share on other sites
23 hours ago, Vorticon said:

You can AORG an ALC program into high memory, but it will have to coexist with the XB program. I am not aware you could force XB into low memory but I might be wrong there. Besides, since the idea to mix XB and assembly is to avoid the tediousness of pure assembly for complex tasks while delegating features not available in XB or too slow to assembly, restricting XB to the lower 8K would likely be too restrictive for most projects...

Check out RXB 2020 it has

CALL PRAM(start low memory address, end high memory address) ! for XB programs in upper 24K where XB programs reside

CALL VDPSTACK(VDP stack memory location) ! for XB  to change location of VDP Stack in VDP so changes VDP RAM use and control

CALL PLOAD(memory address boundary ,"DSK#.filename") ! will load at any 32K location 4K file into memory (i.e. example >B000 )

CALL SAMS(memory address boundary , page number) ! changes SAMS page number at boundary address (i.e. example >A000)

 

  • Like 1

Share this post


Link to post
Share on other sites

Hi. Does anyone know if the CFI function (XMLLNK) trashes R5? It seems to be the case but I want to make sure. There is no mention of that in the EA manual...

Share this post


Link to post
Share on other sites
1 hour ago, Vorticon said:

Hi. Does anyone know if the CFI function (XMLLNK) trashes R5? It seems to be the case but I want to make sure. There is no mention of that in the EA manual...

 

Not unless you are using FAC as your workspace. When you

       BLWP @XMLLNK
       DATA >1200

the workspace is changed to >2094. The return is then changed to the instruction following the DATA directive and the workspace is again changed to the GPLWS (>83E0) before BLing to the CFI routine. After CFI returns, the workspace is reverted to >2094 and the RTWP, of course, reverts to your workspace, continuing execution with the instruction following the DATA directive. No register in your workspace is touched unless it overlaps FAC, >2094, or GPLWS.

 

...lee

Share this post


Link to post
Share on other sites
1 hour ago, Lee Stewart said:

 

Not unless you are using FAC as your workspace. When you

       BLWP @XMLLNK
       DATA >1200

the workspace is changed to >2094. The return is then changed to the instruction following the DATA directive and the workspace is again changed to the GPLWS (>83E0) before BLing to the CFI routine. After CFI returns, the workspace is reverted to >2094 and the RTWP, of course, reverts to your workspace, continuing execution with the instruction following the DATA directive. No register in your workspace is touched unless it overlaps FAC, >2094, or GPLWS.

 

...lee

Well, I have this nasty habit of not creating my own workspace and just using the default registers, so I don't think that's it...

I really should stop doing that regardless 😄

In the mean time, I just replaced R5 with a different register until I figure this out. I would never have guessef was it not for the Classic99 debugger...

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...