TI Mini-Memory programs

[Retrospect]

Does anyone have any routines / code they would like to share, as to give examples of what we can do with Mini Memory in TI Basic?

 

For example, there are probably some nice PRINT AT routines maybe?

 

Thanks in advance.

[+Ksarul]

There are several books of programs in German and in French that were written for the Mini-Memory. There were also a number of programs in the Mini-Memory dialect of TI BASIC from other sources (mostly German-language magazines from Germany, Austria, and Switzerland).

[Retrospect]

It would be fantastic if someone with knowledge of the dialect could perhaps put some quick examples in this thread? .... I could search for books if not I suppose

[am1933]

I always found the Compute! book "Beginners guide to assembly language on the ti99/4a" to be the best assembly guide that was designed for use with the mini memory module.

Clear, concise and to the point.

 

I am sure it is kicking about in one of the archives somewhere.

[RXB]

It was hard to do much with the Mini Memory.

I wrote tons of stuff for it and learned Assembly on it.

TI Basic is just really slow and added routines like VPOKE and VPEEK do not really help due to TI Basic slow speed.

[+Lee Stewart]

Does anyone have any routines / code they would like to share, as to give examples of what we can do with Mini Memory in TI Basic?

 

For example, there are probably some nice PRINT AT routines maybe?

 

Thanks in advance.

 

You might find some of what you could use in D & D Publishing's Beginning Assembly Language for the TI Home Computer. It explains the commands and utilities that both Mini-Memory and Editor/Assembler cartridges add to TI Basic. The Editor/Assembler Manual also details the added commands and utilities in “SECTION 17: TI BASIC SUPPORT”. There may be better examples of the kind of routines you can write to call from Basic than these two references; but these would give you a start in writing your own.

 

All that said, what sort of routines would you like to see, in addition to something like DISPLAY AT? Perhaps some of us here can help.

 

...lee

[Retrospect]

 

You might find some of what you could use in D & D Publishing's Beginning Assembly Language for the TI Home Computer. It explains the commands and utilities that both Mini-Memory and Editor/Assembler cartridges add to TI Basic. The Editor/Assembler Manual also details the added commands and utilities in “SECTION 17: TI BASIC SUPPORT”. There may be better examples of the kind of routines you can write to call from Basic than these two references; but these would give you a start in writing your own.

 

All that said, what sort of routines would you like to see, in addition to something like DISPLAY AT? Perhaps some of us here can help.

 

...lee

Thanks again Lee, yeah , I would like to see if there's any routines for faster random number generating (can we exceed a value of 32767 in that case?) .... and routines to store values and display them on screen ... are there any rapid colour-changing routines, that sort of thing. I've never really delved into the Mini Memory and it's been sitting there on Classic99 all this time. I wonder if anyone ever asked about the battery being emulated. As a side-note, that sort of deep emulation is evident in the EightyOne sinclair emulator, they gave it "Ram-Pack Wobble".

 

Anyhoo, if there are any handy little routines I can use for a game I might write one with a little spare time on my hands should i get more.

[+Lee Stewart]

Thanks again Lee, yeah , I would like to see if there's any routines for faster random number generating (can we exceed a value of 32767 in that case?)

 

In TI Basic, RND actually generates a positive, floating point (FP) number that is 13 – 14 significant digits long. TIB only displays ten of them; but, you can get the remaining 3 or 4 by something like the following:

 

10 A = 10000000000 * RND

20 B = INT(A)

30 PRINT A - B

 

The GPL RAND function generates a one-byte pseudo-random number between 0 and an unsigned, user-provided limit (0 - 255). Because TIB uses FP numbers (8 bytes, 4 words), TIB's RND it actually calls the GPL RAND function four seven times, once for each word radix-100 digit (0 - 99) of the FP number. I am not sure how you could call the GPL function only once or twice from within TIB, even with access to XMLLNK. The RAND function is coded in ALC in console ROM 0 and returns to the GPL interpreter when it finishes. H-m-m-m...I suppose we could duplicate it in a LINKable function.

 

Here are a few of threads that extensively discuss random number generation on the TI:

 

Random number in assembly

TurboForth Random Number Generator

Not Prime!

 

There's at least one more thread, maybe my fbForth thread, that beats it to death, but I can't find it at the moment.

 

...lee

 

[EDIT: I misspoke earlier about the calls to the GPL RAND function. I had worked it out a few years ago and forgot! What can I tell ya?—I'm gettin' old!]

Edited January 16, 2016 by Lee Stewart

[+Lee Stewart]

Here is the GPL RAND function, a 16-bit (or greater) version of which I will later attempt to convert to a LINKable function for TI Basic:

 

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* GPL RAND *

* Uses GPL workspace. *

* First, generates an unsigned, 16-bit "random" number and *

* stores it at 83C0h. *

* Calculation for new seed is *

* ((seed * 6FE5h) & FFFFh + 7AB9h) & FFFFh *

* Then, generates an unsigned, 8-bit random number (RN) such that *

* 0 <= RN <= lim, where 0 <= lim <= 255 and supplied by caller. *

* Stores random number byte at 8378h to be retrieved by caller. *

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

*

RAND LI R4,>6FE5 Generate random number

MPY @>83C0,R4 RN = seed * 6FE5h

AI R5,>7AB9 RN = (RN & FFFFh) + 7AB9h

MOV R5,@>83C0 Load random number seed = RN

*

* At this point, 83C0h contains an unsigned, 16-bit pseudo-random number

*

MOVB *R13,R6 Fetch limit (0-255) from next GROM byte

SRL R6,8 ...in Lbyte

INC R6 ...+1

CLR R4

SWPB R5 swap bytes of RN

DIV R6,R4 adjust to limit

MOVB @>83EB,@>8378 LSB of remainder in R5 to 8378h

*

* Return to GPL interpreter...

...lee

[am1933]

Thanks again Lee, yeah , I would like to see if there's any routines for faster random number generating (can we exceed a value of 32767 in that case?) .... and routines to store values and display them on screen ... are there any rapid colour-changing routines, that sort of thing. I've never really delved into the Mini Memory and it's been sitting there on Classic99 all this time. I wonder if anyone ever asked about the battery being emulated. As a side-note, that sort of deep emulation is evident in the EightyOne sinclair emulator, they gave it "Ram-Pack Wobble".

 

Anyhoo, if there are any handy little routines I can use for a game I might write one with a little spare time on my hands should i get more.

So EightyOne saw fit to include what is probably the most pain in the arse design flaw in emulator form, it is even worse than the old "getting the function/shift and + key mixed up on the 4a".

[senior_falcon]

It sounds like you want to create a library of assembly subroutines to support TI BASIC with the minimemory cartridge. There is 4K of RAM available, and you should be able to put quite a few goodies in that space. You'd have to do it with the Editor/Assembler and not the line by line assembler which uses up most of the 4k RAM. I believe that you could add many of the extras provided by XB - Display At, Accept At, with some creativity I think you could support sprites, and quite a bit more. Besides the single statement BASIC lines, the other problem is that you will be accessing the assembly subroutines via CALL LINK and that entails a big speed penalty compared to XB. In general, CALL's in BASIC are about 2.5 times slower than in XB. (About 1/20 second vs 1/50 second) Even though the assembly subroutines are fast, getting there and back through BASIC will be slow. I am quite sure that generating a single random number using an assembly subroutine and CALL LINK will be much slower than RND would be. If you were to generate 16 of them in a single CALL LINK and pass them back to BASIC you just might be a little faster, but I doubt it.

Anyway, it would be an interesting project. Back in the day I wrote accept at and display at routines for the minimemory which worked fine but once I started using assembly routines with XB I stopped using the minimemory. I have no idea where they might be now.

[+Lee Stewart]

... CALL LINK and that entails a big speed penalty compared to XB. In general, CALL's in BASIC are about 2.5 times slower than in XB. (About 1/20 second vs 1/50 second) Even though the assembly subroutines are fast, getting there and back through BASIC will be slow. ...

 

Could this be wholly due to the fact that both MiniMem LINK and E/A LINK store call parameters in memory on the 8-bit bus, whereas XB stores them in memory (scratchpad) on the 16-bit bus?

 

...lee

[senior_falcon]

Pretty sure XB puts them in low memory. Try a speed test yourself by setting up a loop that does CALL HCHAR, or any other CALL. See how many times it loops in one minute in XB and then in BASIC. Now, I have a confession to make - I did not test how long CALL LINK takes in minimemory basic. I do know that a CALL LINK in XB that goes to a subroutine that does nothing but return takes about 1/50 second, pretty much the same as any other CALL in XB. Since there is some new code in the cartridge, I suppose CALL LINK in BASIC may run faster than the normal BASIC CALL's, but that would surprise me.

[+Lee Stewart]

Pretty sure XB puts them in low memory. ...

 

H-m-m-m...Thierry says otherwise (sort of):

 

“In addition, LINK places the total number of variables in byte >8212 and indicates the type of variable (number, string constant, numeric variable, etc) into bytes >7002-7011, one byte per parameter. Note that this is different from CALL LINK in Extended Basic, that places the parameter types at >8300 and from the Editor/Assembler cartridge that uses the low memory expansion for this purpose.”

 

...lee

Edited January 17, 2016 by Lee Stewart

[Tursi]

I've never really delved into the Mini Memory and it's been sitting there on Classic99 all this time. I wonder if anyone ever asked about the battery being emulated.

Several times.

[senior_falcon]

Here are some TI BASIC speeds that I determined this morning:

CALL LINK to an assembly subroutine takes .041 seconds. This is the best case scenario - a one character subprogram name and only one subprogram in the ref/def table. The subprogram is simply B *R11.

CALL HCHAR(1,1,42) takes .044 seconds

These are at least twice as slow as they would be in XB. As noted in earlier threads, it is the CALLs that makes TI Basic so slow, the actual programs will run slightly faster than XB if there are no CALLs.

[RXB]

The biggest bug in TI BASIC is two problems that go hand in hand within TI BASIC.

 

1. Everything runs from VDP, Variables, Strings, and Program.

 

2. Garbage collection is called much more often and is badly designed compared to the Extended Basic version of the Garbage Collection routine.

[senior_falcon]

The biggest bug in TI BASIC is two problems that go hand in hand within TI BASIC.

 

1. Everything runs from VDP, Variables, Strings, and Program.

 

2. Garbage collection is called much more often and is badly designed compared to the Extended Basic version of the Garbage Collection routine.

1 - It is true that everything runs from VDP in TI BASIC. This is also true of TI Extended BASIC if you don't have the memory expansion. This limits the size of the programs, but despite the slower VDP access compared to CPU RAM, you will find that XB programs run at virtually the same speed with or without the memory expansion. They might run 1% slower without the memory expansion. It would have been nice if TI BASIC recognized the memory expansion the way XB does, just because it would allow longer programs.

2 - Garbage collection will indeed happen more frequently without the memory expansion. The presence of the program in VDP means less room for strings. This is true of both TI BASIC and XB without the memory expansion. Garbage collection does seem to be a bit slower in BASIC. But in the real world I don't think you'd really notice because you don't spend that much time doing garbage collections anyway. The test program I wrote to force as many garbage collections as possible ran just a tiny bit slower in BASIC compared to XB without the memory expansion. A fraction of a percent and almost within the margin of error in pushing the stopwatch button. Don't get me wrong - I'm not arguing that slower is better, just saying that you have to look elsewhere to find the reason BASIC is so slow.

 

The real reason is that it takes much longer to do a CALL in BASIC than it does in XB. Is that a bug? I dunno, but if you wanted to improve BASIC that would be the best place to start.

[RXB]

Guys XB has a ROM's to speed up XB. GPL XML commands that use ROM routines like:

*    Equates for XMLs
SYNCHK EQU  >00               SYNCHK XML selector
FILSPC EQU  >01               Fill-space utility
CSTRIN EQU  >02               Copy-string utility
SEETWO EQU  >03               SEETWO XML selector
COMPCT EQU  >70               PREFORM A GARBAGE COLLECTION
GETSTR EQU  >71               SYSTEM GET STRING
MEMCHK EQU  >72               MEMORY check routine: VDP
XCNS   EQU  >73               Convert number to string
* Warning Default changed in >0073
PARSE  EQU  >74               Parse a value
CONT   EQU  >75               Continue parsing
VPUSH  EQU  >77               Push on value stack
VPOP   EQU  >78               Pop off value stack
PGMCHR EQU  >79               GET PROGRAM CHARACTER
SYM    EQU  >7A               Find SYMBOL entry
SMB    EQU  >7B               Also for ARRAYS
ASSGNV EQU  >7C               Assign VARIABLE
SCHSYM EQU  >7D               Search symbol table
SPEED  EQU  >7E               SPEED UP XML
CRUNCH EQU  >7F               Crunch an input line
CIF    EQU  >80               Convert INTEGER to FLOATING P
CONTIN EQU  >81               Continue after a break
SCROLL EQU  >83               SCROLL THE SCREEN
IO     EQU  >84               IO utility (KW table search)
GREAD  EQU  >85               READ DATA FROM ERAM
GWRITE EQU  >86               WRITE DATA TO ERAM
DELREP EQU  >87               REMOVE CONTENT FROM VDP/ERAM
MVDN   EQU  >88               MOVE DATA IN VDP/ERAM
MVUP   EQU  >89               MOVE DATA IN VDP/ERAM
VGWITE EQU  >8A               MOVE DATA FROM VDP TO ERAM
GVWITE EQU  >8B               WRITE DATA FROM GRAM TO VRAM
GREAD1 EQU  >8C               READ DATA FROM ERAM
GDTECT EQU  >8E               ERAM DETECT&ROM PAGE 1 ENABLE
SCNSMT EQU  >8F               SCAN STATEMENT FOR PRESCAN

TI Basic GPL code has no where near as many Assembly routines to do mundane things like XML IO that does a Key Word Search in XB for commands.

Or XML SEETWO that does the amazing thing of selecting a seperate list of internal XML routines in the XB ROM's not listed in GPL Code.

Example it searches Line Number table or Program crunched code or sting memory or numeric values depending on the BYTE values of 0 to 3

 

If you look at RXB source code (Same as XB Source code except were I show changes made) all the code shows XML routines all over.

Edited January 19, 2016 by RXB

[senior_falcon]

I've been musing on how to create TI BASIC extensions that run with the Minimemory cartridge. Here's what I've come up with:,

1-Move the color table to >0380. Of course, then you will need a CALL LINK("COLOR") to change the colors because CALL COLOR will write to the wrong memory locations.

2-The sprite attribute table should be at >0300 which is the normal location. There is room for 32 sprites if you overwrite the crunch buffer at >0320. I looked at the crunch buffer with Classic99 and it seems to only be used in the immediate mode and when inputting strings and numbers, so unless it is used for something else in a BASIC program it should be OK. Otherwise, there is room for 8 sprites without overwriting the crunch buffer.

3-You'd need a small interrupt routine to look at whether the program is running or not. If running then change VDP register 3 to >0E; if not running make it >0C and write >D0 to >0300 to turn off sprites.

4-Then there must be CALL LINKS to duplicate all the sprite routines in XB. Also you need CALL LINKs for DISPLAY AT and ACCEPT AT. These would probably take up 2, maybe 2.5K. That leaves quite a bit of room for other extensions - scrolling, windowing, etc.

 

One way to mitigate the slowness of CALL in BASIC would be to pack as much into each call as possible-multiple colors in one CALL LINK("COLOR"); multiple sprites in a single CALL LINK("SPRITE") and so on. I doubt that you could quite equal the speed of similar extensions in XB but you might come close. You still have the many limitations of TI BASIC (slow startup, slow loading of programs, single statement lines, etc.) but it would be a very cool project. With the utilities in battery backed memory it would be like having your own custom cartridge. If something like this had been available in 1983 TI would have sold a lot of Mini Memorys!

[sometimes99er]

Mark Wills did The Game Writers Toolkit (89/91) for the Mini Memory. See this review from Micropendium for functionality. I don't know why I still haven't got a copy, and I can't find it on Whtech.

[senior_falcon]

Sounds like exactly what I had in mind. This should be found and added to the development resources!

[Willsy]

Here you go, 'yall...

 

TGWTK.zip

 

The attached is Win994A disk image, of course you'll need to insert the mini-mem cart into Win994A.

 

If you rename the file extension from TIDISK to DSK you can open the disk image in TIDIR or Michael's TIImageTool and export into FIAD or any other format.

 

Here's the manual, just for kicks:

 

 

.CO PRINT THROUGH THE FORMATTER!!
.CO CONTINUOUS PAPER RECOMMENDED
.PA 1
.FO ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^PAGE %
.PL 60
.LS 1
.LM 5
.RM 75
.CE 5
THE GAME WRITERS TOOLKIT V2.8
WRITTEN BY MARK WILLS
© 1991 ABBOTS SOFTWARE

USERS MANUAL/GUIDE V2.0 (This is NOT a comprehensive manual)

Congratulations on choosing THE extension to TI BASIC for the
TI-99/4a.

If you have any enquiries/problems with The Game Writers Toolkit then
please write to the Author at the below address:

Mark Wills (Abbots Software)
12 "Rosehill",
Betton Street,
Belle Vue,
Shrewsbury,
Shropshire,
SY3 7NY.

A stamped addressed envelope would be appreciated!!


CONTENTS OF THIS TUTORIAL:
--------------------------

Introduction and how to access the extra commands.

A description of each command, with examples.

COMMAND PAGE NUMBER
------- -----------
BOX 4
BYE 4
CHIMES 5
CROLL 5
DOWN 8
GPHOTO 7
LCHARS 5
LEFT 5
LOWCAS 6
PPHOTO 8
PRINT@ 6
QUITOF 7
QUITON 7
RIGHT 8
SETUP 8
SMLIST 10
SPRCOL 9
SPRITE 9
SPRMOV 10
SSIZE 9
UP 5
WINDOW 8
WIPE 7
WHERE 10
GETKEY

PAGE 12 - DISCLAIMERS & COPYRIGHT INFORMATION.
DISTRIBUTION CREDITS AND INFORMATION.

.CE 2
INTRODUCTION
------------

The Game Writers Toolkit (hereafter reffered to as TGWTK) represents
nearly a year of continous development and refinement. All the
routines included in this utility have been designed to run as
efficiently and quickly as possible.

The utility and all is buffers/memory banks etc reside in the RAM of
the Mini Memory and sits in the background when TI BASIC is in
operation. It is dormant until a specific Toolkit command is called.
Only then does control pass over to the Toolkit. When the particular
Toolkit command has finished, control passes back to the TI BASIC
program, AFTER the line that called the particular Toolkit command.

You can run any TI BASIC program with the TGWTK setup and in
operation, but all CALL COLOR commands will have to be changed to the
Toolkit version : CALL LINK("COLOR",X,Y,Z) in order to run the program
with the correct colours assinged to the correct character sets. This
is because the colour table in VDP RAM has been physically moved to
the top end of VDP. This of course means that the TI BASIC CALL COLOR
command is writing to redundant memory locations, so I have provided a
COLOR command in the Toolkit. The Toolkit version has exactly the
same syntax as the TI BASIC version, it is thus very easy to edit old
TI BASIC programs and change all CALL COLORS to the Toolkit version.

Some of the facilities afforded by TGWTK are outlined here: It allows
the TI BASIC programmer to access all 32 sprites, in all 4 selectable
sizes. Full directional screen scrolling is supported. You can scroll
any part of the screen (or all of it) in any of the four directions.
Fast manipulation of the colour table is allowed via the Colour Roll
command which will roll all sixteen colours through the character sets
with a selectable delay and repeat. The machine can now reset itself
from INSIDE a TI BASIC program, the FCTN and + key can be disabled
(and re-enabled) to prevent accidental resetting of the machine. A
true lower case character set is included and much more...

.CE 2
ACCESSING THE NEW COMMANDS
--------------------------

Because all the Toolkit commands are written in 100% machine code,
they are accessed through the CALL LINK("") command. The name of the
command you wish to use is inserted between the quotes - eg. CALL
LINK("BYE"). Some commands need specific information before they can
work, when this is so the information is supplied after the command
name with a comma seperating them. eg. CALL LINK("CROLL",100,50) note
the comma between the second quote and the first number.

Where some commands need numeric or string information, you can
specify either numeric constants, variables, or expressions, string
constants or string variables respectively. Arrays or array elements
either numeric or string cannot be passed. They must be passed to a
numeric or string variable first.

CALL LINK("BOX",Y,X,YE,XL,ASCII)
--------------------------------

This command allows you to instantly draw a rectangle of any vertical
and horizontal size, consisting of any ASCII character.

The operand "Y" is the number of lines down the screen where drawing
will then start (range 0 - 23).

The operand "X" is the number of characters across the screen where
drawing will then start (range 0 - 31).

The operand "YE" is the number of lines down the screen where drawing
will end. (range 0 - 23). Note that it MUST be greater than "Y" or a
crash may occur.

The operand "XL" is the length of each horizontal line that is drawn.
(range 1 - 32).

The operand ASCII is the character code of the character of which you
want your box to be drawn. (range 32 - 159).

EXAMPLE:
--------

CALL LINK("BOX",4,9,22,7,42)

The above example would draw a box starting 4 lines down and 9
characters across, ending on the 22nd line, each horizontal line
having a length of 7 characters, consisting of asterisks. (character
code 42).

CALL LINK("BOX",10,10,10,10,65)

Would draw a box consisting of A's (character code 65) starting ten
lines down, ten characters across, each line having a length of ten
characters.

CALL LINK("BYE")
----------------

This command when encountered in your program or in direct mode will
cause the computer to reset itself immediately. You must of course be
careful when using this command and make sure that all data is saved
etc before your program resets the machine, or else all data will be
lost!



CALL LINK("CHIMES")
-------------------

This command plays a chime whenever it is encountered, rather like a
doorbell. Aknowledgement is made to Texas Instruments Inc. Dallas,
Texas, who hold the copyright to this routine. The routine is based
on the routine on page 322 of the Editor Assembler Manual.



CALL LINK("UP",R)
-----------------

CALL LINK("DOWN",R)
CALL LINK("LEFT",R)
CALL LINK("RIGHT",R)

These commands scroll the screen in the directions as stated above.
The numeric operand "R" tells the toolkit how many times you want the
screen to be scrolled in that particular direction.

EXAMPLE:
--------

CALL LINK("LEFT",10)

This would cause the section of the screen covered by the WINDOW
command to scroll left 10 times. control then returns to the next
line of your program.

See the description of the WINDOW command on page ???

CALL LINK("CROLL",R,D)
----------------------

This command moves all the colours of the sixteen character sets into
the character set to the left of it numerically speaking. In other
words, it moves the colours in character set 2 to character set 1, the
colours in character set 3 to character set 2 and so on.

The numeric operands R and D tell the command how many times you want
to repeat the rolling before control passes to the next line, and how
long a delay you want between each roll. The range for R and D is 1 to
65535 for both.



CALL LINK("LCHARS")
-------------------

This command is intended to be used when you want to make the normal
upper case characters slightly larger. It expands upwards all the
characters from ASCII(32) TO ASCII(95) inclusive. If you want to use
this command AND have user defined graphics residing in the character
set between the above two values, then execute LCHARS first, then
define your graphics, otherwise your graphics characters will be
expanded also!!



CALL LINK("LOWCAS")
-------------------

This command replaces the "small capitals" in the lower case character
set with proper lower case characters. Any graphics characters that
you have stored in ASCII(97) to ASCII(122) prior to this command will
be overwritten with the new definition data that this command creates.



CALL LINK("PRINT@",Y,X,D,S$)
----------------------------

This command allows you to print a string of up to 255 characters in
lenth in any postion on the screen. Like DISPLAY AT in Extended
Basic.

The numeric operands Y and X tell the command how many lines to count
down and how many characters to count across BEFORE it starts to print
your text. If your text goes over the end of the line that it starts
on, then it simply reappears on the other side, one line down.

The numeric operand "D" tells the computer which direction to print
the string in. You can experiment with this value to get different
effects but here are four values for you to try: D=1 print to the
right(like a normal print statement), D=-1 prints the string
backwards!, D=32 prints the string downwards, D=-32 prints the string
upwards.

EXAMPLE:
--------

CALL LINK("PRINT@",11,5,1,"HELLO THERE WORLD!")

This would cause the computer to count 11 lines down, 5 characters
across and then print the string HELLO THERE WORLD! on the screen.

CALL LINK("PRINT@",10,10,-32,"HELLO")

This would cause the computer to print the string HELLO starting at
10,10 and going upwards!



CALL LINK("QUITOF")
-------------------

This command disables the FCTN and + keys so that you cannot reset the
computer while typing in a program, or while a program is running,
unless you type BYE when in edit mode or the machine encounters a CALL
LINK("BYE") in your program.



CALL LINK("QUITON")
-------------------

This turns the quit keys back on so that it is possible to reset the
machine from the keyboard.



CALL LINK("WIPE",D,ASCII)
-------------------------

This is a fancy screen clear command!! It fills the screen with the
character you specify from the top left and bottom right at the same
time, working in to the middlle of the screen. The operand "D" tells
the command how long a delay you want between each character being
printed. (range 1 - 65535). The operand "ASCII" (both operands are
numeric) tells the command which character you want to fill the screen
with. (range 32 - 159)



CALL LINK("GPHOTO",Y,X,YE,XL)
-----------------------------

This command called "get photo" actually "takes a photo" of a section
of screen, the size of which you tell the command, and stores it in
the RAM of the MiniMemory. All operands are numeric, and the operands
work in exactly the same way as the operands do in the BOX command.

EXAMPLE:
--------



CALL LINK("GPHOTO",6,4,12,9)

This causes the computer to count down 6 lines, across 4 characters,
then store the next 9 characters in each line, up until line 12.
In other words it copys a 6*9 square box of the screen into the
MiniMemory.



CALL LINK("PPHOTO",Y,X,YE,XL
----------------------------

This command, called "put photo" puts the photo back onto the screen,
that you "got" with the get photo command. Note that you DON'T have
to put the photo back on to the screen, in the same place that you
"took" it. This allows you take a photo of a large section of screen
(or even the whole screen) and move it around very quickly.

You can also "distort" the image that you "put" back onto the screen
by changing the operand "XL". If for example the XL in your GPHOTO
command was 9 and the "XL" in you PPHOTO command was 8, then it would
cause the photo that it put back on the screen to slant to the left as
it goes down each screen line. The demo program "PHOTOS" shows this
feature. It also shows CROLL.



CALL LINK("SETUP")
------------------

This command must be issued at least once at the begginning of your
program, or else none of the toolkit commands will function.
It displays the credits on the screen, establishes the REF/DEF table,
and relocates the colour table in VDP ram so that all 32 sprites can
be used. This is why a new version of CALL COLOR is included.


CALL LINK("WINDOW",Y,X,YE,XL)
-----------------------------

This command tells the scroll commands which part of the screen to
scroll. You only need to issue it once and the scroll commands will
know the section of screen to be scrolled every time they are called.
You must of course issue a new WINDOW command if you want to change
the section of screen to be scrolled.

The numeric operands Y,X,YE AND XL work in the same way as the BOX
command.



SPRITES:
--------

A lot of work has been put into this utility to offer an easy to use
sprite system comparable to that of extended basic, indeed most of the
sprite commands offered by Extended Basic are implemented in TGWTK and
those that are not can be gotten around. Much research was put into
using the interrupt driven sprite routines in ROM but it was found to
be impossible. TI BASIC was never intended to use it anyway so we
mustn't grumble too much! An alternative approach is used in TGWTK so
all is not lost.


CALL LINK("SPRITE",SN,Y,X,ASCII+96,C)
-------------------------------------

All initial sprite information is supplied with this command. In
order to enable the sprite system, sprite 0 must be somewhere on the
screen. (0,0 is fine). To disable the sprite system make sprite 0's Y
location on the screen 208 like this:CALL LINK("SPRITE",0,208,0,0,0)
This turns off ALL sprites.
To disable for example sprites 8 to 31 then make sprite 8's Y value
208 (CALL LINK("SPRITE",8,208,0,0,0) Then you can only use sprites 0
to 7 unless you change the Y value of sprite 8 to some value other
than 208.

The numeric operand "SN" is the sprite you wish to use (range 0 - 31).

Numeric operand "Y" tells the machine the Y value of the sprite you
are using.

Numeric operand "X" tells the machine the X value of the sprite you
are using.

All sprites are "tied" to a character in the character set. If you
place 65+96 for example in the ASCII operand then the sprite will look
like a capital A, unless the shape of the capital A has been changed
with CALL CHAR.

The numeric operand "C" tells the sprite what colour it should be.
Subtract 1 from the numbers given for colours in the TI manual to get
the number to use. Eg. The manual says black is 2, so for the sprite
colour the value to use is 1.



CALL LINK("SSIZE",S)
--------------------

The SSIZE command allows you to change the size of the sprites in
exactly the same way as the MAGNIFY statement in extended basic. For
standard single character sprites use a 0 for the value of "S". For
single character double sized sprites use a value of 1. For 4
character normal sized sprites use a value of 2. For double sized 4
character sprites use a value of 3. For a description of sprite sizes
see the extended basic manual.



CALL LINK("SPRCOL",SN,C)
------------------------

This command changes the colour of the sprite "SN" to the colour "C".
No other characteristics of the sprite are changed.
Subtract one from the colour values given in the TI manuals, to get
the correct colour value to use.



CALL LINK("WHERE",SN,Y,X)
-------------------------

This command asks the computer for the "Y" and "X" screen locations of
sprite "SN". At times you will need to know where a particular sprite
is on the screen, this is what this command does. It puts the Y and X
values of the sprite whose details you ask for into the variables you
place in the second and third operands. EG. CALL LINK("WHERE",5,A,B)
will place the Y location of sprite 5 into numeric variable A and the
X location into numeric variable B.



CALL LINK("SMLIST",SN,YM,XM)
----------------------------

This command tells the toolkit Sprite Movement List in the MiniMemory
the movement details of the sprite "SN". Then whenever a SPRMOV
command is encountered, the sprite "SN" will move according to the
details given to the SML. EG. CALL LINK("SMLIST",4,10,-3) means that
whenever a SPRMOV command is encountered sprite 4 will move down 10
pixels and left 3 pixels from where it was. CALL
LINK("SMLIST",2,-4,5) will cause sprite 2 to move up four pixels and
right 5 pixels everytime a SPRMOV command is encountered.



CALL LINK("SPRMOV",N,R)
-----------------------

This moves all sprites from sprite 0 up to and including sprite "N"
according to thier details entered into the SML with SMLIST. The
numeric variable "R" will repeat this R times, then continue execution
from the next line of your program.


SEE THE DEMO PROGRAMS FOR MORE INFORMATION ON SPRITES.

CALL LINK("GETKEY",S$,KU,A)
---------------------------

This command was added at the last minute which is why it is not
included with the others!

It works like the POS statement in TI BASIC, whereby it will return
the position of the key(s) being searched in the string "S$", in the
variable "A". The numeric operand "KU" tells the computer what key
unit to use and works in the same way as the keyunits work in CALL KEY
in TI BASIC.

EXAMPLE:
--------

10 CALL LINK("GETKEY","ESDX",3,A)
20 PRINT A;
30 GOTO 10

The above program would print a 1 on the screen when you pressed "E",
a 2 when you pressed "S" and so on. If you do not press any keys, or
the key you press is nnot in the string, then the value returned is 0.

COPYRIGHT INFORMATION AND DISCLAIMERS:
--------------------------------------

The program THE GAME WRITERS TOOLKIT (all versions) is the sole
copyright of Mark Wills of Abbots Software. No unauthorised
duplication of this product is allowed in any way without express
written permission from the author.

Abbots Software accept no liability for any damages to persons or
equipment deriving from the use of this software.

The only authorised duplicator for this software package at the time
of writing is Mike Goddard, M.G.C.S, "Sarnia", Cemetary Road, Rhos,
Wrexham, Clwd. LL14 2BY.



DISTRIBUTION CREDITS AND INFORMATION:
-------------------------------------
This program and its associated files and documentation are
distributed and duplicated by:

Mike Goddard Computer Support, (MGCS)
"Sarnia",
Cemetary Road,
Rhos,
Wrexham,
Clwyd,
LL14 2BY.

Thanks are given to MGCS for taking some of the burden off the
author!!

Any information you may require about this program can be obtained
from the above address, or by writing to Abbots Software at this
address:

M. Wills,
Abbots Software,
12 "Rosehill",
Betton Street,
Belle Vue,
Shrewsbury,
Shropshire,
SY3 7NY.

We hope that The Game Writers Toolkit gives you hours of pleasure and
helps you to get just that little bit more from your TI!

Have Fun!

LOADING THE DEMO PROGRAMS
-------------------------

The programs that come with this package demosntrate some of the
features of TGWTK.

To load them simply type OLD CS1 if you are using a tape system, and
follow the onscreen instructions, or type OLD DSKX.ZZZZZZ if you are
using a disk system where "X" is the disk number and "ZZZZZZ" is the
filename of the demo program you wish to load.
RUN them in the normal way for both tape and disk systems.


LOADING THE GAME WRITERS TOOLKIT OPERATING SYSTEM INTO YOUR OWN
PROGRAMS:

If you are using a disk system then make the first line of your
program:

CALL LOAD("DSK1.TGWTK/O") and the machine code will be loaded into the
coreect place.

Tape owners will have to load the operating system using the LOAD
option in EASY BUG, then reset the machine and load you BASIC program
with OLD CS1 in the usual way.

Write to me if you have any problems, or programs you would like me to
see, You never know we might release them for sale!!

€‹€Ñ—˜Ÿ©³½ÇÕÕÕÕÕÕÕÕÕ€‹€†€Õ†’¤ÕÕÕÕÕÕÕÕÕÕÕÕ€†

 

[Willsy]

Some notes: TGWTK NOTES.TXT

 

A disassembly: TK2.txt

 

I wrote that in 1991 - 25 years ago!! The original source code is long gone, as it was written in a small notebook in pen, and typed into the Line-By-Line assembler by hand!

[senior_falcon]

Hi Mark.

I can't see why auto sprite motion wouldn't work unless the sprite table is someplace other than >0300. Of course you'd lose character sets 14 and 15 (Or is it 15 and 16?) just like in XB. Don't you miss programming with the line-by-line assembler? That was a real challenge - about the only good thing about it is that the inability to make changes forces you to think harder about the program before keying it in.