Jump to content

Photo

Playground


134 replies to this topic

#126 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sun Aug 20, 2017 10:35 PM

Amazing idea, crashed instantly in RXB though and I suspect due to VDP memory being different in XB and RXB compared to TI Basic VDP memory.

 

Possibly FAST RAM set up is not the same also.


Edited by RXB, Sun Aug 20, 2017 10:36 PM.


#127 RXB OFFLINE  

RXB

    River Patroller

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

Posted Sun Aug 20, 2017 10:35 PM

Amazing idea, crashed instantly in RXB though and I suspect due to VDP memory being different in XB and RXB compared to TI Basic VDP memory.

 

Possibly also FAST RAM set up is not the same also.



#128 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 929 posts
  • Location:Lansing, NY, USA

Posted Mon Aug 21, 2017 5:01 AM

Amazing idea, crashed instantly in RXB though and I suspect due to VDP memory being different in XB and RXB compared to TI Basic VDP memory.

 

Possibly also FAST RAM set up is not the same also.

Make sure you are running it in TI BASIC, not RXB.

 

(edit) Works fine in RXB, but first you have to turn off the 32K with CALL LOAD(-31868,0,0)

 

(further edit) If you have saved this as IV254 then it may not load with the expansion memory turned off. 


Edited by senior_falcon, Mon Aug 21, 2017 3:20 PM.


#129 kommissar OFFLINE  

kommissar

    Combat Commando

  • 2 posts

Posted Mon Aug 21, 2017 5:52 PM

I forgot to test it with extended basic, not sure how robust it is with different configurations.  After enthusing endlessly to my coworkers (most of whom weren't born when I got my TI) about an "escape from the sandbox" it turned out that one of them had a website with tons of TI-99/4A cartridge ROMs plus two TI computers at home.  He brought one in (foolishly got rid of mine in the 90s) and I laboriously typed in the whole program (this is before I found the oldcs1 utility).

 

Anyway, here's some source code used to re-make the lines program.  You can do a lot ~110 bytes at a time :)

Attached Files



#130 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 929 posts
  • Location:Lansing, NY, USA

Posted Tue Aug 22, 2017 12:11 PM

That's about how I figured it worked, using 6 bits and then adding the missing 2 bits.

 

Alles klar, Herr Kommissar.



#131 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 929 posts
  • Location:Lansing, NY, USA

Posted Thu Aug 24, 2017 8:55 PM

I think the slow startup and somewhat bulkier programs that result tend to limit the usefulness of this technique. The ability to key in the program would have been VERY useful back in the heyday of COMPUTE! magazine, but these days not so much because it is so easy to download programs. 
 
But if you want to refine this technique, there is a way that could help with the startup time.  There are 256 bytes of vdp ram used for character patterns from 128 to 160.  Instead of concatenating 102 times to get Z$, it would only take 13 CALL CHARs to plug the equivalent of 
Z$ into this area of memory. 
 
I believe you could create A$ the same way if PEEKV and POKEV were available so you could find and reset the pointer to A$. But I sure can't see any way to do it with normal TI BASIC.  
 
I have been meaning to convert LINES to be a playground program and you saved me the trouble!
 
 
100 FOR I=1 TO 128
110 READ J
120 A$=A$&CHR$(J)
130 NEXT I
 
140 FOR I=1 TO 102
150 READ J
160 Z$=Z$&CHR$(J)
170 NEXT I
 
180-250 DATA (230 numbers)
 
260 OPEN #1:A$
 
23296-23896 REM containg the program


#132 MueThor OFFLINE  

MueThor

    Space Invader

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

Posted Sat Aug 26, 2017 1:27 AM

Hi folks,

 

Here 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:41 PM.


#133 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

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

Posted Mon Sep 11, 2017 8:24 PM

Hi folks,

 

Here 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

 

Your first two questions imply that you have not read the manual for Playground. “Playground docs.pdf” is contained in Playground.zip in post #1. It not only answers your first two questions, it tells you how to write Assembly Language code (ALC) that, after assembly, can be loaded and run from TI Basic, Extended Basic, Editor/Assembler and more.

 
The point of Playground  is to load and run ALC programs in scratchpad RAM because that is the only RAM in an unexpanded TI-99/4A console and it is unavailable for this purpose except by the trick(s) employed by Playground. There really is no provision for returning to the originating language (TI Basic, Extended Basic, ...). I am not sure why you would want to return to the Editor/Assembler.
 
Regarding your question about use of scratchpad RAM, there are extensive resources that explain how scratchpad RAM is used by various languages. Here are a few:
  • The Editor/Assembler Manual, pp. 404 – 406;
  • Thierry Nouspikel’s TI-99/4A Tech Pages under “Memory”;
  • Chapter 4 in my fbForth 2.0: A File-Based Cartridge Implementation of TI Forth under “Manual” on the fbForth website indicated in the signature area below this message.
I hope this helps a little.
 
...lee


#134 MueThor OFFLINE  

MueThor

    Space Invader

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

Posted Sat Oct 14, 2017 4:18 AM

Dear Lee Stewart,

 

Thank you for your short overview and your simple explanations on this topic :).

 

There really is no provision for returning to the originating language (TI Basic, Extended Basic, ...). I am not sure why you would want to return to the Editor/Assembler.

Well, I asked myself following: Is it possible to run small parts of a long ALC program in scratchpad RAM for extreme fast calculation of intermediate results used by the much bigger, but also more slowly executed parts of this ALC program running in the 32k RAM, which can be accessed by Editor/Assembler? Does your answer in the quotation above imply that the answer for my question below the quotation is negative?

 

 

Regards


Edited by MueThor, Sat Oct 14, 2017 4:38 AM.


#135 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 929 posts
  • Location:Lansing, NY, USA

Posted Sat Oct 14, 2017 11:01 AM

I'm not quite sure what you are asking, so I will answer the question for two different possibilities:

1 - You are using assembly language subroutines running from an XB program or a TI BASIC program with the Editor Assembler or MiniMemory cartridge. In this case you want to be careful not to mess up the many pointers and other values used by BASIC.  It is no problem for your subroutine to copy assembly language instructions to the scratchpad memory, but you have to be careful.  Once you know how many bytes will be moved to scratchpad and where they will be moved to you should first copy the scratchpad ram in that area into a buffer, then move the assembly instructions to scratchpad, then run them, and finally restore the scratchpad.  You can see there is quite a bit of overhead here which might negate any speed advantages.  You might be able to use the FAC area from >834A to >836D from an assembly subroutine without backing it up.

2 - You are running a pure assembly program using the Editor Assembler cartridge.  Here there are fewer constraints and less need to back up the scratchpad.  But in this case you'd always have the workspace in scratchpad. It is true that there is more available scratchpad ram where you can copy your assembly instructions, but remember that with the workspace already in scratchpad ram you would see less of a speed increase from moving program segments to scratchpad and running them there.

(Edit) If you have some small loops or other short segments of code then it would be perfectly reasonable to copy them to the scratchpad when the assembly program starts up.  Once there they can be treated as just part of the program.  You can B or BL to them as desired and then return to the main program in the 32K expansion when they are finished.

 

To give you an idea of the speed differences, an assembly program running completely on the 16 bit bus will take around 60% of the time it takes to run with everything on the 8 bit bus.  
 


Edited by senior_falcon, Sat Oct 14, 2017 7:49 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users