Jump to content

Photo

Assembly on the 99/4A


585 replies to this topic

#576 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 508 posts
  • Location:Phoenix, AZ

Posted Thu Sep 7, 2017 10:15 PM

Answering rather late, sorry.
 
I always put my workspace at >8300.  No particular reason other than I have always done it that way and it is out of the way of using the rest of the scratch pad RAM for variable storage.  IMO you should *always* use a workspace in the 16-bit scratch pad RAM, otherwise you pay a hefty performance penalty.  As others have mentioned, if you are going to use console routines (ROM or GROM) or allow the console ISR to run, then you will need to know and respect the use of scratch pad based on those services. 

That's pretty much what I gathered regarding >8300 being a choice because "I have always done it." I'm relieved there wasn't something I was missing. Of course, scratchpad RAM is the way to go for speed.

Assumption: Most guys leave LIMI 0 and poll the CRU bit for timing so...

May I assume the rest of the scratchpad is safe for variables? How about the ISR's Workspace at the end of the Scratchpad (>83E0 - >83FF)? Assuming it is usable as long as LIMI 0 *interrupt disabled ?

Edited by Airshack, Thu Sep 7, 2017 10:39 PM.


#577 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 3,907 posts
  • Location:Denmark

Posted Thu Sep 7, 2017 11:08 PM

Assumption: Most guys leave LIMI 0 and poll the CRU bit for timing so...


Yes.
 

May I assume the rest of the scratchpad is safe for variables? How about the ISR's Workspace at the end of the Scratchpad (>83E0 - >83FF)? Assuming it is usable as long as LIMI 0 *interrupt disabled ?


Yes.

#578 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,311 posts
  • Location:Silver Run, Maryland

Posted Fri Sep 8, 2017 5:01 AM

... How about the ISR's Workspace at the end of the Scratchpad (>83E0 - >83FF)? ...

 

Not to put too fine a point on it, but >83E0 – >83FF is GPL workspace. ISR workspace is >83C0 – >83DF.

 

...lee



#579 Airshack OFFLINE  

Airshack

    Dragonstomper

  • 508 posts
  • Location:Phoenix, AZ

Posted Fri Sep 8, 2017 10:38 AM

 
Not to put too fine a point on it, but >83E0 – >83FF is GPL workspace. ISR workspace is >83C0 – >83DF.
 
...lee


Hey Lee,

Anything you have to add is ALWAYS appreciated. The details matter. Thank you for today's ounce of enlightenment.

I had no idea about ISR/GPL Workspace differences. So... I'm thinking with interrupts disabled, they're both areas I may use for variable space without concern? -j

#580 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,311 posts
  • Location:Silver Run, Maryland

Posted Fri Sep 8, 2017 12:20 PM

Hey Lee,

Anything you have to add is ALWAYS appreciated. The details matter. Thank you for today's ounce of enlightenment.

I had no idea about ISR/GPL Workspace differences. So... I'm thinking with interrupts disabled, they're both areas I may use for variable space without concern? -j

 

Yes.

 

You will only have a problem if you decide to enable interrupts at any time in your program. Then, there are a few(?) registers in ISR WS that probably need particular values—notably, R1 (various flags) and R2 (ISR hook). Since the ISR also uses (or causes use of) the GPL WS, you will also need to be sure R13 and R15 are restored to >9800 (or whatever different GROM base your program might need) and >8C02 (VDP RAM Write Address Register), respectively. This last comment applies also if you call any GPL routines, even without enabling interrupts. The graphic in post #364 shows details for the registers in both workspaces.

 

...lee



#581 Asmusr OFFLINE  

Asmusr

    River Patroller

  • 2,422 posts
  • Location:Denmark

Posted Fri Sep 8, 2017 1:18 PM

limi 0

lwpi >8300

do whatever you want



#582 apersson850 OFFLINE  

apersson850

    Moonsweeper

  • 417 posts

Posted Sat Sep 9, 2017 10:11 AM

There is sort of a conflict of interest here.

The simplest context to write assembly language programs for are those that are completely self-supporting. They start, they run and do their own thing and they end by a system reset. Hence as long as you take control (don't allow interrupts), you can use all resources in the machine and do whatever you like.

Things get a bit more complex if you want to use routines in the machine as subroutines for your own code. If you want to use the floating point math, for example, then you must adapt to how they are written. If they use GPL WS, FAC and ARG areas in scratch pad RAM, then you can't store your things there and suspect them to survive.

It gets even more complex if you want to add assembly support routines to another environment, like Extended BASIC or Pascal. In such a case, you must respect the fact that these environments have mapped all of scratch pad RAM, and some other RAM too, for their own purpose, and only selected parts can be modified without ruining the capability to return to the calling environment.

 

For a game or major other application (like TI-Writer), the self-supporting route is no problem. But I've almost always found the best use of assembly to augment Extended BASIC or Pascal, and then you need to be careful. That's when consoles with all 16-bit RAM are good, as there's no speed penalty for me, regardless of where the workspace is or the code runs.



#583 TheBF OFFLINE  

TheBF

    Moonsweeper

  • 307 posts
  • Location:The Great White North

Posted Sat Sep 9, 2017 10:18 AM

There is sort of a conflict of interest here.

The simplest context to write assembly language programs for are those that are completely self-supporting. They start, they run and do their own thing and they end by a system reset. Hence as long as you take control (don't allow interrupts), you can use all resources in the machine and do whatever you like.

Things get a bit more complex if you want to use routines in the machine as subroutines for your own code. If you want to use the floating point math, for example, then you must adapt to how they are written. If they use GPL WS, FAC and ARG areas in scratch pad RAM, then you can't store your things there and suspect them to survive.

It gets even more complex if you want to add assembly support routines to another environment, like Extended BASIC or Pascal. In such a case, you must respect the fact that these environments have mapped all of scratch pad RAM, and some other RAM too, for their own purpose, and only selected parts can be modified without ruining the capability to return to the calling environment.

 

For a game or major other application (like TI-Writer), the self-supporting route is no problem. But I've almost always found the best use of assembly to augment Extended BASIC or Pascal, and then you need to be careful. That's when consoles with all 16-bit RAM are good, as there's no speed penalty for me, regardless of where the workspace is or the code runs.

 

That is excellent advice Apersson850.

 

It's also important to balance the expected speed of your assembly code versus your  XB or Pascal application speed. 

My point is, even if you use 8 bit RAM for your workspace, the upgrade in speed is still many many times faster than your hi level language speed.

 

So I like the Steve Jobs approach:

 

"Make it work, then make it better"

 

B



#584 apersson850 OFFLINE  

apersson850

    Moonsweeper

  • 417 posts

Posted Sat Sep 9, 2017 1:20 PM

Yes, and that pretty much describes my "TI life". When I bought the 99/4A, I was still in school. At that time, Pascal was THE language. C had just emerged and wasn't used for anything important. Algol had just stepped down from the top for technical/scientific applications.

 

So I pretty quickly acquired the expansion box, including the p-code card. After a couple of years, I had upgraded to four DS/DD disks, built my own clock and I/O card and installed 64 K 16-bit wide RAM inside the console. That of course required quite a lot of assembly programming to make it work, but on the other hand, I've hardly written any stand-alone assembly program. Some smaller ones, but mainly for technical applicaitons.

 

But I have made a large number of assembly support routines, both for the p-system and also for Extended BASIC, but then mainly with other people in mind, since many more had Extended BASIC than the p-system. Still, I had half a dozen or so of friends who all used Pascal on the 99. I've understood that it was a bit rare at that time that so many Pascal users actually knew each other, and three of use lived within a few hundred meters from each other.

 

Most of what I've used the TI for has been text based, and then the p-system is 40 column wide window to an 80 column wide screen from the beginning. But by using assembly I've for example implemented the ability to display pop-up messages on the screen, without disturbing what's there from the beginning. That's not too difficult in theory, since the 80 column screen is in low RAM, but the visible window in VDP RAM. So just write to VDP RAM to display the window, then restore the screen and the original text is back. This also means that the pop-up will be visible regardless of which of the three windows the user is displaying.

But the logic in the assembly routine to wrap words in strings so they are not cut at the end of the window is quite complex. But done in assembly to give an instant display of the message.

 

All my own hardware has RAM in DSR space. If they aren't battery backed, I need to reload the programs on startup. To make that easy, I wrote a loader (in Pascal), which loads object files into memory at any location, even if a CRU bit must be set to enable that memory. The loader benefits from the p-system's assembler's capability to generate code files with multiple procedures in one segment. Thus I can simply assemble a code file containing all the different code files I want loaded in one file. I included extra header information about memory and CRU address to load to, so the different procedures can end up on different cards, and also in my own internal RAM expansion (which is paged with CRU bits) in one single run.

But to write to a word in memory that's paged in by a CRU bit requires assembly. Thus there's  the function crupoke(value,addr,crubase: integer): boolean; external; linked to that Pascal program. But all other stuff is done by Pascal, since it's fast enough in that case. Pascal is also able to read directly from any sector in a file, or any sector on a unit, so no assembly is needed to access the code file in my special way. Crupoke is a function instead of a procedure, since it not only writes to memory, but also reads back and verifies that there is actually RAM at the accessed location. If there isn't, the program simply skips to the next procedure to load in the code file. By specifying a CRU address of 4000H (they can't be larger than 3FFFH), it loads to normal RAM instead. If I set the CRU address to 8000H, it loads the code, or rather data, to VDP RAM.

 

This is what I consider a good example of where almost all of the logic of a program is in high level language, which is easier to write and debug, but that critical part that can't be done in Pascal is written in assembly.



#585 MueThor OFFLINE  

MueThor

    Space Invader

  • 43 posts
  • Location:OMG, yet another good former TI customer from Germany ;-)

Posted Mon Sep 11, 2017 2:42 PM

Hello all,

 

Unfortunately, nobody of you wanted to answer my questions posed in my message under the link http://atariage.com/...ayground/page-6. I would be delighted, if anyone of you will be so nice to answer my questions, give an outline and/or links regarding the topic short machine language programs to be executed in scratchpad RAM. Hence I repeat the aforementioned message in the following:

Here (in the program Playground) a way was found to access scratchpad RAM directly from TI BASIC. It is surely possible to access this scratchpad RAM from XB and EA too, or? If so, can you return from scratchpad RAM to XB and EA? BTW, does there exist an overview of machine language addresses, which can be accessed from scratchpad RAM in dependance of the programming language used for accessing scratchpad RAM, i.e. TI BASIC, XB or EA?

 

 

Regards


Edited by MueThor, Mon Sep 11, 2017 2:48 PM.


#586 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,311 posts
  • Location:Silver Run, Maryland

Posted Mon Sep 11, 2017 8:30 PM

Hello all, ...

 

Unfortunately, nobody of you wanted to answer my questions posed in my message under the link http://atariage.com/...ayground/page-6. ...

 

See my response in the above link.

 

...lee






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users