Jump to content

Photo

SAMS usage in Assembly


90 replies to this topic

#76 RXB OFFLINE  

RXB

    River Patroller

  • 2,634 posts
  • Location:Vancouver, Washington, USA

Posted Thu Sep 4, 2014 10:19 PM

Rich have you got any docs on those programs? I know of their existence but no nothing of the programs themselves.

Sure here you go but this is not everything he has done. Just most of it.

Attached Files

  • Attached File  RAG.zip   504.73KB   10 downloads


#77 RXB OFFLINE  

RXB

    River Patroller

  • 2,634 posts
  • Location:Vancouver, Washington, USA

Posted Thu Sep 4, 2014 10:42 PM

Found some more files not included with those sent already.

 

Attached Files

  • Attached File  RAG.zip   504.73KB   11 downloads


#78 Willsy OFFLINE  

Willsy

    River Patroller

  • 2,993 posts
  • Location:Uzbekistan (no, really!)

Posted Fri Sep 5, 2014 4:46 AM

That has to be one hell of a lot faster then having to fetch values after the XOP. 8 Registers are loaded and ready to execute before I even do the call.

 

Yeah, but you had to load those registers before-hand right? So it seems you're doing the work pre-call rather than post-call. No problem with that at all. Just making the point that the work still has to be done somewhere! ;)



#79 Stuart ONLINE  

Stuart

    Dragonstomper

  • 666 posts
  • Location:Southampton, UK

Posted Fri Sep 5, 2014 5:05 AM

I would have to disagree with that Stuart.

In RXB I use a command called CALL EXECUTE(cpu-address)

And it is a just a BLWP @cpu-address

 

So what I do is the CPU Workspace is where all the values are loaded before I call that routine. Thus all registers are pre-loaded and ready to go.

 

That has to be one hell of a lot faster then having to fetch values after the XOP. 8 Registers are loaded and ready to execute before I even do the call.

I was talking about the specific case of passing "a parameter" - just *one* parameter. XOP @>1234,R1 where the parameter >1234 is passed in the instruction itself uses one less instruction than having to MOV that parameter somewhere then calling BLWP which then retrieves it. It you want to pass *lots* of parameters, then there is of course no benefit at all.



#80 RXB OFFLINE  

RXB

    River Patroller

  • 2,634 posts
  • Location:Vancouver, Washington, USA

Posted Fri Sep 5, 2014 5:14 AM

 

Yeah, but you had to load those registers before-hand right? So it seems you're doing the work pre-call rather than post-call. No problem with that at all. Just making the point that the work still has to be done somewhere! ;)

 

I do after all load all 8 Registers with one move of data, now I suppose you could do the same thing with a CALL LINK but then that would take one hell of a lot more code to do then preloading them.

 

If was just more effective to move 16 bytes with a single RXB CALL MOVES then to keep doing CALL LINKS for them or a single one at a time CALL LINK version.

 

P.S. Never mind just read the second message....


Edited by RXB, Fri Sep 5, 2014 5:14 AM.


#81 adamantyr ONLINE  

adamantyr

    Stargunner

  • 1,101 posts

Posted Tue Jun 27, 2017 1:05 PM

As I recently acquired a SAMS card, I'm now thinking I'll change my CRPG to make use of it. I actually don't need a great deal of memory to complete it, most of the game content is still disk-based, but I can utilize some memory-intensive approaches to make the performance better in places.

 

The problem is, I need to actually break my program up into some code segments; just data in extra memory isn't going to be enough. But what platform to do this? I've used A99 to do my compiling into a tagged object format before, but should I be trying to use CSEG and CEND? And I suppose E/A #5 is right out, you'll have to use a custom loader.. I don't mind doing that, I just want to make sure I can compile the segments so they all have the same absolute addressing.

 

I suppose, worst case scenario, I can group together all the shared code and then create different source sets for the different "states" the program is in, compile those, then read in the 8K segments in a custom loader...

 

Has anyone actually used Art Green's assembler and linker for SAMS programming?



#82 Asmusr ONLINE  

Asmusr

    River Patroller

  • 2,335 posts
  • Location:Denmark

Posted Tue Jun 27, 2017 1:39 PM

How much program code do you have, since it's not possible to use SAMS for data only?



#83 adamantyr ONLINE  

adamantyr

    Stargunner

  • 1,101 posts

Posted Tue Jun 27, 2017 1:49 PM

At present, around 29k. Some of that is static data.

 

I'm reading up on the linker that Art Green did, with root and overlay segments, I may be able to use that... I was just hoping someone had already made a cross-assembler version of it.



#84 RXB OFFLINE  

RXB

    River Patroller

  • 2,634 posts
  • Location:Vancouver, Washington, USA

Posted Tue Jun 27, 2017 8:44 PM

As I recently acquired a SAMS card, I'm now thinking I'll change my CRPG to make use of it. I actually don't need a great deal of memory to complete it, most of the game content is still disk-based, but I can utilize some memory-intensive approaches to make the performance better in places.

 

The problem is, I need to actually break my program up into some code segments; just data in extra memory isn't going to be enough. But what platform to do this? I've used A99 to do my compiling into a tagged object format before, but should I be trying to use CSEG and CEND? And I suppose E/A #5 is right out, you'll have to use a custom loader.. I don't mind doing that, I just want to make sure I can compile the segments so they all have the same absolute addressing.

 

I suppose, worst case scenario, I can group together all the shared code and then create different source sets for the different "states" the program is in, compile those, then read in the 8K segments in a custom loader...

 

Has anyone actually used Art Green's assembler and linker for SAMS programming?

Yea I played around with the RAG GPL Assembler and Linker for about a year. I had a hard time with the oddball syntax he used.

 

I think if you are used to C then it would be a natural fit.



#85 RXB OFFLINE  

RXB

    River Patroller

  • 2,634 posts
  • Location:Vancouver, Washington, USA

Posted Tue Jun 27, 2017 8:45 PM

How much program code do you have, since it's not possible to use SAMS for data only?

Why do you say this?



#86 Asmusr ONLINE  

Asmusr

    River Patroller

  • 2,335 posts
  • Location:Denmark

Posted Wed Jun 28, 2017 12:02 AM

Why do you say this?

 

My point is that if he could limit his program to 24K, for instance, then he could use the lower memory area to swap in 2 pages (8K) of data that are stored in SAMS. This is much easier to work with than paged programs, especially if he wants to use a cross compiler. A loader is still require to get the data from disk into SAMS, but that should be relatively easy.



#87 RXB OFFLINE  

RXB

    River Patroller

  • 2,634 posts
  • Location:Vancouver, Washington, USA

Posted Wed Jun 28, 2017 12:33 AM

 

My point is that if he could limit his program to 24K, for instance, then he could use the lower memory area to swap in 2 pages (8K) of data that are stored in SAMS. This is much easier to work with than paged programs, especially if he wants to use a cross compiler. A loader is still require to get the data from disk into SAMS, but that should be relatively easy.

LOL you do know this is built into RXB since version 2001?

 

My game IN THE DARK used 336K of SAMS memory.

 

http://atariage.com/...me-in-the-dark/

 

And this game uses XB and Assembly combined. Matter of fact the Assembly is loaded in the UPPER 24K at >B000 to >B200


Edited by RXB, Wed Jun 28, 2017 12:48 AM.


#88 Willsy OFFLINE  

Willsy

    River Patroller

  • 2,993 posts
  • Location:Uzbekistan (no, really!)

Posted Wed Jun 28, 2017 4:04 AM

 
My point is that if he could limit his program to 24K, for instance, then he could use the lower memory area to swap in 2 pages (8K) of data that are stored in SAMS. This is much easier to work with than paged programs, especially if he wants to use a cross compiler. A loader is still require to get the data from disk into SAMS, but that should be relatively easy.


If possible it may be possible to architect the game software such that the 29k or so of data is always accessed at the same 4k address window. Then you're only mapping in 4k of game data at any time, so the rest is free for code. The last 4k of the 8k cpu space would be an ideal place to map it in.

#89 adamantyr ONLINE  

adamantyr

    Stargunner

  • 1,101 posts

Posted Wed Jun 28, 2017 10:09 AM

Even though my present codebase is not that large, I still needed a Superspace cartridge to get the RAM I needed. (29k of code/data, and 8k of empty RAM required) So the AMS does benefit, and it also gives me the option to expand and add features.

 

The problem with SAMS development is it's something most 99'ers are not accustomed to, which is module/segment/overlay programming.

 

For example, you have a root module, which ALWAYS exists in memory. So common functions and global variables go there, along with main program control. Then you have to identify your self-contained modules and how much space they need. If need be, you duplicate code functions and data, another practice that we aren't used to, given that memory is usually precious.

 

What Art Green was trying to accomplish was to make it so that you did not have to bake any memory management into your code; instead the linker will add the necessary header data to your program segments and the loader will load them into the respective pages and add control code to them as well so that your program just invisibly switches to the different modules. That would mean you would always need his loaders to load the programs, but a small price to pay. Unfortunately, his AMS assembler and linker appear to be a bit of a mess to figure out. :P So much so that I'd almost rather roll my own. I also don't like compiling on the actual TI (even in emulation) because a cross-assembler works WAY faster.

 

So what I'm going to work on now is to re-architect my source code so that it has four modules including a root module. The other modules are distinct states in the game that cannot overlap each other, so I effectively have three "state" versions of the program. I can compile and create memory image files of all three, and then use a hex editor to copy out the compiled contents to create module files that can be loaded via a custom loader into the AMS memory pages.



#90 apersson850 OFFLINE  

apersson850

    Moonsweeper

  • 355 posts

Posted Thu Jun 29, 2017 9:41 AM

I recognize that issue.

My TI 99/4A has 64 K internal RAM, which is segmented in 8 K banks. Bank switching is via CRU bits. As 64 K is the entire address range of the TMS 9900, this implies that this memory can overlay everything.

When I implemented a RAM disk, with a DSR on my I/O card, I wanted to use all available memory for the RAM disk. That includes console RAM at >4000->5FFF. But since enabling that memory disables the console's capability to access the DSR in the PEB, it took some extra code to fix that. Switching away the memory the current code is running in is the electronic version of suicide.

 

Due to that there are (were) only three consoles I know about with my memory structure, I did of course also have to write my own loader software. I decided not to make my own assembler (which would have been necessary to add directives for bank switching), but instead split it up. If I wanted to assemble code that should be loaded at a "forbidden" place, i.e. where other computers didn't have RAM, I assembled with the .ABSOLUTE and .ORG directives. Then, when running the loader, I had to separately specify which CRU bit to turn on and which file to load with that bit on. To make it easy to use in daily life, when maybe several code segments should be loaded in various memory locations, I made the loader so that I can specify any number of CRU addresses and code files. The loader will then load them all in a sequence. My loader can also save the sequence data in a file, and retrieve and run that file on another occasion. I even automated it in such a way, that when I start the DSRLOADER (I gave it that name, since the first application was to load DSR files in RAM on my own PEB cards), it looks for the file *SYSTEM.LOADER. If it exists, it will run the load sequence stored in that file.

 

Doing it like this made it possible to just turn the 99/4A on, and provided the right diskette was in the first drive, it booted not only the operating system, but also installed the clock and RAM-disk DSR files, set the system date, installed the fourth and fifth drives and copied the system files I mostly benefited from having on the RAM disk without any manual intervention.

 

This has absolutely nothing to do with the SAMS card, but since it's about ways to use more memory than initially thought for this computer, I wrote it anyway. Just disregard if you didn't find anything useful to build on.


Edited by apersson850, Thu Jun 29, 2017 9:47 AM.


#91 Willsy OFFLINE  

Willsy

    River Patroller

  • 2,993 posts
  • Location:Uzbekistan (no, really!)

Posted Fri Jun 30, 2017 9:09 AM

With a "bank stack" you can call code in any bank from any bank. You can either put the bank push and pop routines in pad, or place identical routines at identical addresses in each bank.

http://turboforth.ne...urces/sams.html

Edited by Willsy, Fri Jun 30, 2017 9:10 AM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users