Playground

[RXB]

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 August 21, 2017 by RXB

[RXB]

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.

[senior_falcon]

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 August 21, 2017 by senior_falcon

[kommissar]

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

linesBasic.zip.zip

[senior_falcon]

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

 

Alles klar, Herr Kommissar.

[senior_falcon]

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

[MueThor]

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 September 11, 2017 by MueThor

[+Lee Stewart]

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

[MueThor]

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 October 14, 2017 by MueThor

[senior_falcon]

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 October 15, 2017 by senior_falcon

[digdugnate]

Since I saw some threads mentioning this 'Playground' I wanted to bump this so other folks would see it if they hadn't (like me).

[xxx]

having problems with this. ive tried copy and pasting the code into the assembler but it wont assemble, it just crashes. ive tried 2 different assemblers. i know a bit about machine code and have used assemblers for other systems. the instructions arent very good either. ive also tried some of the wav files but they wont load. are there any disk images, etc of these progs? any suggs?

[Tursi]

You're 137 posts in to a three year old thread... to get some help, maybe be a little more specific about which code you are working with and which assembler you were trying to use.

 

[xxx]

2 hours ago, Tursi said:

You're 137 posts in to a three year old thread... to get some help, maybe be a little more specific about which code you are working with and which assembler you were trying to use.

 

im working with the ti writer/assembler. and im trying to get demo.s from playground to run

[atrax27407]

TI Writer will append tabs to the D/V80 file which will likely cause errors to be generated by the assembler. Try another text editor.

[xxx]

25 minutes ago, atrax27407 said:

TI Writer will append tabs to the D/V80 file which will likely cause errors to be generated by the assembler. Try another text editor.

ok, im using editor/assembler but still having problems. its saying 'multiple symbols' and just scrolling with loads of numbers and 'invalid mnemotic' 

Edited November 18, 2020 by xxx

[atrax27407]

The numbers are the line numbers that contain the invalid codes. Send me the source as a D/V80 and I'll look at it.

[+9640News]

1 hour ago, atrax27407 said:

TI Writer will append tabs to the D/V80 file which will likely cause errors to be generated by the assembler. Try another text editor.

Wolfgang, if you are doing anything with MESS and Geneve Emulation, you should be able from the MDOS to type MW which will launch MyWord from the MDOS prompt.  From there, you can type PE which will put you in Programming Edit mode on MyWord.  That's likely already my default environment.

 

Now, I just went through an ordeal in removing some CR/LF's from a text file I got from Github loaded from the TIPI into MyWord.  If you are using MyWord, look under the HELP feature.  From there, under the Control Keys command.  I was able to use a Replace String Function typing a "/" (no quotes) CTRL-U and then I forget the specific character after that then CTRL-U which I think is what disabled the control Mode), then "//" .  Effectively this replaces the character I was seeing on the screen which looked like a "dot" and a very small "9".

 

I don't know if TI-Writer has those capabilities or not.

 

In my case, I was saving files to the TIPI from the Windows PC, then using MyWord loading the file from the TIPI.  I know the TIPI can load .TXT files, and the formatting was not clean for source code, but I got things across.  There is still some cleanup, but I had over 1000 such characters to replace that the Replace String function made things easy.

 

Beery

 

[atrax27407]

That is exactly what the problem with his file appears to be from the copy that he set to me. I think I can straighten it out in F'WEB.

[+9640News]

I tried another route, essentially downloading the TXT files through XMODEM which saved the files as DIS/FIX 128 since there were no TIFILES headers.  I then used a program from Al Beard, TRANSFORM, for the Geneve that would read the DIS/FIX 128 and convert to a DIS/VAR 80 file.

 

It stripped out the CR/LF issue I had, however, the labels were all screwed up and the first few lines of each file was missing.  Not sure what was going on, so that is when I went back to MyWord to find a solution.

 

We really need to find a method with some very clear step by step directions to transfer DIS/VAR 80 source up to and back down from Github without all these hurdles.  I know some have mentioned some tiimagetool (???) features, but a clear set of tool(s) to automate a single file to a hundred or more source files at a time would be an asset.  The simplest tool I could think of would be an interface function that goes talks with some tool that sends commands to GitHub to get the files, then saves the files with TIFILES headers to the TIPI.  Then, if something needed to be uploaded, it would send the other way with some method to mark directories and/or individual files.

 

I say this as there is code like FunnelWeb, MDM5, MDOS, MyWord, ABASIC, PSystem, HRD4000B+, and a host of TI-99/4A programs where this would be extremely beneficial.  Not to discourage anyone from using GitHub, but it would be very helpful if comments did not exceed past column 80 as those comments get scrolled to the next line and an assembler will want to treat it as an instruction or honk for an error.  Also, not sure whether the asterisks character is an allowable character for adding comments within the source on the xdt side of things.  I have not played with xdt to know if comments after the instruction have to be commented with the semicolon or not.  Commented source code looks great, but if comments without a semicolon is a problem for GitHub, then it really limits the ability to upload older source code. 

 

Like I said earlier, I pulled some code down from GitHub written to assemble, etc. with xdt that is not directly portable to the Geneve that I will spend several evenings porting it over into a format suitable for GenASM to process.  It's great the code was posted so don't get me wrong, however it would not be easily portable back into the Editor/Assembler assembler nor GenASM for the Geneve.

 

 

 

 

[+DuaneAL]

I must be missing something.  Playground programs run from console basic.  Is this an attempt to convert to regular assembly?

[Tursi]

.. I think you guys are chasing the wrong problem.. I don't think the Playground asm was written to be assembled by the TI Editor/Assember... @senior_falcon?

 

@DuaneAL - the final resulting program runs from TI BASIC, but in order to /create/ the program, you need to write assembly.

 

[senior_falcon]

53 minutes ago, Tursi said:

.. I think you guys are chasing the wrong problem.. I don't think the Playground asm was written to be assembled by the TI Editor/Assember... @senior_falcon?

 

@DuaneAL - the final resulting program runs from TI BASIC, but in order to /create/ the program, you need to write assembly.

 

To create a program for the playground loader you need a disk drive, 32K, Editor/Assembler or MiniMemory carts. All these are part of the Classic99 emulator. The program should be written in assembly language. Easiest is to use a text editor to create the assembly source code, but you can use the Editor/Assembler package if you are a purist/masochist.

Once created the source code must be assembled into assembly object code. You can use the TI assembler, Asm994a, or another assembler. Once assembled it must be loaded as described below. Once the loader has been created with the embedded code it can be saved like any BASIC program. If you save it to cassette then  you can load the program from cassette to an unexpanded TI99.

 

N.B. If you want to learn assembly programming for the TI99/4a, this is not the place to start. The programs must be divided up into small segments, paying careful attention to the length of each. BLWP cannot be used. BL has some serious limitations as described in the manual. Debugging is harder than with a normal assembly program. And on and on... It is much more demanding than a normal assembly program.

The manual was not meant as an assembly language tutorial, but rather as a description of how programming for playground is different from normal assembly programs.

 

CREATING A BASIC LOADER CONTAINING YOUR ASSEMBLY CODE
After writing the assembly language program you will need to create a BASIC program that contains
the embedded assembly program. First save the assembly source code, then assemble it to create object
code. Once the object code is created, with the E/A or minimemory cartridge in the slot and 32K of
memory expansion, type these lines: (Here the object code is DEMO-O)
CALL INIT
CALL LOAD("DSKn.DEMO-O") this will load the DEMO program starting at >A000
CALL LOAD("DSKn.MAKEBX-O") this loads the code that will embed DEMO in a BASIC
program (this code is AORG'd at >F000)
CALL LOAD(-31804,240) this runs MAKEBX and creates the BASIC program.
Then SAVE or RUN as you desire. If your program is long you may need to CALL FILES(1), then
NEW before loading to free up additional room. You can paste the above into BASIC using Classic99
if you want to avoid having to key it in. Use Paste, not Paste XB.
The BASIC program consists of two lines. Line 10 is a REM statement. This can be modified as you
desire. Other REM statements and even program statements can be added before line 20, but do not try
to edit line 20

[+DuaneAL]

7 hours ago, Tursi said:

.. I think you guys are chasing the wrong problem.. I don't think the Playground asm was written to be assembled by the TI Editor/Assember... @senior_falcon?

 

@DuaneAL - the final resulting program runs from TI BASIC, but in order to /create/ the program, you need to write assembly.

 

I think you nailed my point?! The OP was trying to run demo which should have been runnable without the cartridge.    You and Senior falcon then explain that to develop the programs, one needs to write assembly.  Thanks for saying it much better than I!  And senior falcon’s clarification should help the OP when/if he wants to develop in playground.

[apersson850]

I see no point whatsoever in creating Playground programs for yourself. To create them, you already have every piece of hardware needed to not need the Playground programs. You create them for other people, to run them on unexpanded consoles. But that auditorium is pretty small today.

 

I've used my complete TI 99/4A to create programs that could run on computers with just Extended BASIC, 32 K RAM and casssette player. But that was back then, when there were no eumulators and not all people had everything.