TI*MES

Per the letter from TI*MES (TIUG) regarding Co-option there was a 100% vote resulting in a Negative Decision on accepting the co-option. It was felt that rather than TI*MES using Co-option that the idea of decentralization would be approached (regional groups). It was noted that the Secretary/Treasurer would notify Jim Ballinger of the results of the meeting noting:
1) We respectfully decline the offer of co-option with TI*MES (TIUG),
2) approach the idea of TI*MES decentralizing with regional group breakdowns,
3) Reiterate Peter Walkers listing of his regional breakdown of the mailing list as the approach to decentralization, and
4) as always, EAR 99’ers cooperation with all TI User Groups is offered in the true spirit of the TI family.

Disclaimer

EAR 99’ers is a self-sustaining, non-profit organization, and is not an instrumentality of the United States Government. It operates contingent on compliance with the requirements and conditions of all applicable Air Force Regulations, and Host Nation Laws. Articles written by members or contributors to this newsletter do not necessarily reflect the views or opinions of the representatives of EAR 99’ers. Responsibility is not accepted for hardware modifications.

EAR 99’ers purpose is to promote fellowship, morale, and we1fare among its members, and encourages all activities in connection with the TI-99/4A Home Computer and compatibles.

EAR 99’ers will not engage in an activity that duplicates or competes with any Base Morale, Welfare and Recreation Division activity, or NAFI, including the Army and Air Force Exchange Services (AAFES). Any item listed for sale does not represent duplication or competition with the aforementioned services.

Meet Scott and JoAnn

LET’S MEET SCOTT AND JO ANN COPELAND - MEMBER # 3

Aawww, do we have to?

I know the first couple of paragraphs should be reserved for Scott, but what the hay, I got to the computer first (seeing as I live on it that’s not surprising...).

And what could anyone possibly want to know about me? You know, the one who’s only playing with half a deck, the one who’s elevator doesn’t go all the way to the top;..

Well, here goes the saga of everything you always wanted to know but were afraid to ask... I was born in Glen Cove, Long Island, New York and raised in Nassau County before relocating to Suffolk County, Long Island. Long Island was a beautiful place to grow up, and we had many trips to the Bay, taking advantage of all the good weather by getting out on our boat and going Flounder Fishing. We’d often go to Fire Island to go clamming or swimming in the Ocean. I attended the usual Elementary thru High Schools and then a Business School in Bay Shore, Long Island, mastering the arts of Bookkeeping II and III, Accounting I and almost mastering Shorthand (I created .my own version).

Having learned and mastered all those skills I decided to do nothing with them and landed my first job with (groans and moans here) the Internal Revenue Service (British equivalent is Inland Revenue Service), working first in the Personnel Department, and I learned the art of FingerPrinting via working with the FBI in Security Investigations. Having had enough fun in this department I was transfered to the Audit Division and worked with Estate Taxes and Planning. Between working with the FBI and Audit people, I was a person you didn’t want on your bad side (only kidding!).

Well, after that it was time to move to Virginia, and I had several jobs supporting myself enjoying the good ol’ Single Life, including jobs as a Flexowriter, Gal Friday, Independent Insurance Agent, and Dictaphone-Transcriptionist (I type 94 wpm.)

Then it happened... Love at first transmission. I got involved in the world of CB Radios and met Scott thru the Radio Waves (been drowning ever since, he-he). Scott and I married, stayed in Virginia for awhile, my daughter Veronica came along, and then came the Army Reserves for Scott, and then a full-time enlistment with the Air Force. This brought us to Mississippi, then to Texas (along with having my son David), then England (oh well, there’s good and bad in everything...)!

We’ve been in England since 1984 and should hopefully PCS (permanent change of station) in 1991. It’s been an experience, both good and bad, living in England, but we’ve met an awful lot of wonderful people, especially those involved with the User’s Group. At least the common language is 'English' and not Turkish! We’ve had the opportunity of visiting Cornwall: and Wales, seeing a lot of real Castles, and beaches (although they’re not the same as Fire Island’s beach!). We’ve lived both ‘on the economy’ and on-base.

Anyway, Scott and I have two lovely (well, angels and devils at the same time) children. Veronica is 10 and David is 7. We’ve been married 11 years and will probably extend the contract for a few-more years. We have two lovely Yorkshire Terrier Puppies named Lance Algernon and Kumiko Algernon (monsters actually). I enjoy (most of the time) working with the group and the newsletter, knitting and reading in any spare time I have, Adventuring, and playing games with the children (I'm just a big kid!). I look forward to the next couple of years here with our friends in England, although eventually I do want to head home.

Well, I guess I better give Scott some time also, so will sign off and let you all breath A sigh of relief now that the worst part is over (or is it ?!)... .
-------
HI! I was born in 1958 in a little town in SUFFOLK, VIRGINIA. Notice Suffolk is also a County in England, where my grandparents originated from, thereby contributing to my English descent. I grew up in a large family and took an interest in Electronics by the age of 7. My first job was working at a Gas Station, but I also had a Short Wave Shop where I assisted in maintenance and repair of Short Wave Radios. I then moved to an easier apparatus, the CB Radio, where I met my first love (and I’ve been paying for it ever since). Over the airwaves I invited her over for coffee, but she insisted on having Sweet-N-Low with her coffee. I immediately despatched persons under my persuasion to the nearest 7-11 to obtain said item. She was then indebted to come for coffee. Our true romance started...

Further on in time, having a small family to support, I sought a job that would enable me to increase my knowledge of electronics, thus the Air Force. After 10 years of service, I am a qualified Senior Ground Radio Electronics Communications Technician (sounds impressive 'eh?). In short, I fix ground to air radios. Within the coming year, I should have my degree in Applied Radio Technology, and within 16 months following I hope to have my Bachelor Degree of Science in Industrial Technology. Wish me luck!

In 1981 Jo started my TI Career by purchasing this small piece of machinery. I was enthused with its ability in the start, but found its limitations quickly. After coercing the Financial Manager (Jo) I was able to acquire the PEB and associated disk drives. No more OLD CS1 for me... For a long time it was just myself, my computer, and my ability to learn programming. It wasn’t until 1984, upon arriving in England, hhat I found a large, vast world of the TI Community. I originally came to the UK with 10 disks of purchased software, and maybe 5 of programs I wrote over the years. My library now consists of over 550 disks and more still coming! Just goes to show, you gag teach an old dog new tricks.

If you haven’t doubled over in pain by now, you can relax ‘cause k I'm through! l’ve enjoyed my tour here in England so far, and look forward to my arrival back in the States, especially now that we’re aware of all the User Groups there. May our next 3 years be as prosperous as the last 5. .

Multicoloured Text

IN EXTENDED BASIC
By: JOHN S. DUNNING

One of the problems with TI Basic is the inability to be able to display text on screen in more than one color at a time, due to the characters being grouped together in 'sets' of eight.

The only way around this problem is to redefine the patterns of characters in unused sets. This is fine if you only need a few letters or a word of up to eight letters, but if you need more, then it gets very tedious working out all the patterns and typing them in, and of course it is also expensive in terms of memory.

In TI Basic I know of no way around this, but in Extended Basic we have a couple of very useful statements we can use to help us:

CALL CHARPAT(A,A$) will take the pattern identifier code for the upper case letter 'A' and store it in the string variable ‘A$’.

CALL CHAR(97,A$) will transpose this code to the lower case letter 'a' so now we have two upper case letters A in different character sets, therefore we can use CALL COLOR(9,5,8) to color the second 'A' differently and then print it to the screen, and our trusty TI has done all the hard work for us.

Once we have finished using this multicolored text (say we only needed it for our program title for instance) we don’t have to store a load of redundant character definitions, colors, etc. because we can then use CALL CHARSET to restore the characters to their original patterns and colors thus freeing then for later use by the program.

The two sample programs below demonstrate how these statements might be used. I have used single lines for each statement to make it easier to read, but remember in Extended Basic you can use multiple statements on a line.

100 CALL CLEAR
110 CALL CHARPAT (69, E$, 65, A$,
82,R$,57,N$,83,S$)
120 CALL CHAR(101,E$,97,A$,
114,R$, 110,N$, 115 S$)
130 FOR C==5 TO 8
140 CALL COLOR(C,2,8,C+4,5,8)
150 NEXT C
160 PRINT “EAR 99 ERS"
170 PRINT
180 PRINT “ear nn ers"
190 GOTO 190



Go to top of page

100 CALL CLEAR
110 FOR X=65 TO 95
120 CALL CHARPAT(X,X$)
130 CALL CHAR (X+32,X$)
140 NEXT X
150 FOR C=5 T0 8
160 CALL COLOR(C, 2,8,C+
4,5,8)
170 NEXT C
180 PRINT "ABCDEFGHIJKL
MNOPQRSTUVWXYZ"
190 PRINT
200 PRINT “abcdefghijkl
mnopqrstuvwxyz"

CALL CHARSET will restore the original character definitions and colors.

Disk Peripheral DSR

There is no credit to TI but this article draws VERY heavily upon a 1980 internal TI document called "GPL Interface Specification for the 99/4 Disk Peripheral". Colin was a TI employee.

DISK PERIPHERAL D.S.R. SUB-PROGRAMS
by Colin Hinson

LEVEL 1 SUBROUTINES

The lowest routines in the disk DSR are called level 1 subroutines. These routines make the higher levels independent of the physical disk medium, e.g. changing the disk software for a double density disk would only involve changing the routines on this level provided the physical sector size remains at 256 bytes.

There are two Sub-programs available on this level

1. Sector Read/Write
2. Format disk

The following paragraphs contain a description of the subprograms and their call requirements. All parameters are transferred through the FAC block in CPU ram. This block is located at a relative position of >4A (which for the 99/4a is >834A).

All the subprograms are called by a ’BLWP @DSRLNK’ followed by a data statement: ‘DATA >A’. (Note that the Editor Assembler manual is WRONG - it gives >10 for the data on the third line of the First paragraph on page 262). Before calling any of the subprograms, location >8356 (name length pointer) must be set up to point at the location in VRAM where the name length and the subprogram number have been written: e.g. lf subprogram >14 is called then a location in VRAM (say >1000) must contain 2 bytes, the first of which is >01 (the name length), and the second of which is the subprogram number >14. Location >8356 in CPU RAM points to the first of these bytes - i.e. contains >1000.

Error codes are returned in >8350

SECTOR READ/WRITE SUBPROGRAM >10

The transfer block for this subprogram is:

>834A : (Sector Number)
>834C: Unit # | Read/Write
>834E: VDP Buffer Start Address
>8350: Sector Number

The meaning of each entry is:

Unit Number:- Indicates the disk drive on which the operation is to be performed. For a T.l. controller, this has to be either 1, 2, or 3.

READ/WRITE - Indicates the direction of data flow:
0 = WRITE
NOT 0 = READ

VDP buffer start address. - Indicates the start of VDP buffer for data transfer. The number of bytes transferred will always be 256

Sector number:- Number of the sector to be written or read. Sectors are addressed as logical sectors (0-359 for a single sided single density disk), rather than as a track and sector number, which would require a knowledge of the physical layout of the floppy disk. The sector number has to be given in CPU Ram locations >8350 and >8351, and will be returned in CPU ram locations >834A and >834B.

DISK FORMATTING : SUBPROGRAM >11

The transfer block for this subprogram is:

>834A: (# of sectors/disk)
>834C: DSR Ver | Unit # | # of tracks
>834E: VDP buffer start address
>8350: Density | # of sides

The meaning of each entry is:

# of sectors/disk - Is returned by the routine to provide compatibility between the normal controller and double density or SA200 systems.

DSR Version (This is the MostSignificant nibble)

0 indicates the format requires nothing special and can be done on any version of the DSR.
1 indicates the format requires the 2nd version of the DSR for one of two reasons. It may be because a double sided format is requested, or it may be because a # of sectors other than 35 or 40 is requested (but see below!).

Unit Number:- Indicates the disk drive on which the operation is to be performed. For a T.I. controller, this has to be either 1, 2, or 3. This is the Least Significant nibble.

# of tracks - Indicates the number of tracks to be formatted. In the only versions released, this entry has to be either 35 or 40!!! Upon return, this entry contains the number of sectors per track.

VDP buffer start address - Indicates the start address of the VDP buffer that can be used by the disk controller to write tracks. The amount of memory used depend on the disk format. For a single density format, the buffer memory used is a nominal 3125 bytes. This can vary with disk motor speed to a maximum of 3300 bytes. To be compatible with double density versions of the controller (such as MYARC), the minimum buffer size must be 8K bytes.

Density - 0 = single

# of sides - Indicates the number of sides to format

The above subprogram will format the entire disk on the given unit unless the disk in the unit has been hardware write protected. It can use any VDP memory starting at the location given in the transfer block.

LEVEL 2 SUBROUTINES

The Level 2 subroutines use the "file" concept, rather than the "logical sector number”. Note that the file concept on this level is limited to an abstract type of file which has NO properties such as "program file" or "data file”. A file on this level is merely a collection of data, stored in logical blocks oi 256 bytes each.

The logical blocks on this level are accessed by filename and logical block offset. This offset starts with block 0 and ends with block N-1 for a file with a length of N blocks.

Go to top of page

MODIFY FILE PROTECTION - SUBPROGRAM > 12

The transfer block for this subprogram is

>834C: Unit # | Protect Code
>834E: Pointer to file name

The protect bit for the indicated file will be set or reset according to the information given in CPU ram location >4D:

0 - Reset the file protect bit. The file is no longer protected against modification or deletion.
1 - Set the file protect bit. Disallow SAVE and OPEN for OUTPUT, APPEND, or UPDATE mode.

The pointer to the file name must point to the VDP ram location of the first character of the file name. The name must be left adjusted in a 10 character field, right filled with spaces. No checks are made to ensure the legality of the file name.

FILE RENAME ROUTINE - SUBPROGRAM > 13

The transfer block for this subprogram is:
>834C: UNIT # | unused
>834E: Pointer to new name

>8350: Pointer to old name Both pointers to the file names must point to the VDP ram location of the first character of a file name. Each name must be left adjusted in a 10 character field, right fi1led with spaces. No checks are made to ensure the legality of the file names.

Since the rename has to be done on the same disk, only one unit number entry is required.

Error codes are returned, as usual, at location >8350. The error codes returned are identical to the standard file management error codes, i.e. only the upper three bits of the error byte are significant.

---------------------
[Subprograms >14 and >15 did not appear in these issues of the magazine. These dealt with Direct File Access routines. I have extracted the equivalent text directly from the original 1980 TI document, which in this case has not been rephrased / corrected by Colin.]

The direct file access routines can be used for accessing disk files without paying attention to the type of disk file (PROGRAM or DATA). The level of access is equivalent to the Level 2 disk software, which means that access is performed on the basis of straight AUs. However, Level 3 information can be passed at file open time.

Since the input and output direct access subprograms can be used together to copy files, the user has to be very careful with the information returned by the input file subprogram, since some of this information may be used by the output file subprogram.

Access Direct Input File — Subprogram >14

The transfer block for this subprogram is:
>004C: Unit # | Access code
>004E: Pointer to file name
>0050: Additional Information.

The meaning of each entry is:
Unit #: Indicates the disk drive on which the operation is to be performed. This entry has to be either a 1, 2, or 3.
Access code:
An access code is used to indicate which function is to be performed, since this subprogram combines multiple functions. The following codes are used:
0 : Transfer file parameters. This will transfer Level 2 parameters to the additional information area (six bytes). It also passes the number of AUs allocated for the file.
N : When N is not equal to 0, this indicates the number of AUs to be read from the given file starting at the AU indicated in the additional block. After the read is complete this entry contains the actual number of AUs read. If all AUs have been read, this entry will be 0.
Pointer to file name: Contains a pointer to the first character of a 10-character filename, possibly padded to the right with spaces. This filename is NOT checked by the disk software.

Additional info: Points to a 10-byte location in CPU RAM containing additional information for direct disk access:
X+0 VDP Buffer start address
X+2 # of first Allocation Unit
X+4 Status Flags | # recorder per Allocation Unit
X+6 EOF offset | Logical record size
X+8 # of Level 3 records allocated.

where:
VDP Buffer Start Address: Indicates where the information read from the disk can be stored. The buffer has to be able to store at least N * 256 bytes, in which N is the access code.
# of first AU entry: Indicates the AU number at which the read should begin. If the access code = 0 (parameter passing), the total number of AUs allocated for the file will be returned.

The remaining 6 bytes are explained in the Software Specification for the 99/4 Disk Peripheral. The user should be very careful when changing these bytes, since they directly affect Level 3 operation. If the information in these 6 bytes is not modified consistently, unpredictable results may occur.

Error codes are returned at location >50 in CPU RAM.

Access Direct Output File — Subprogram >15

The transfer block for this subprogram is:
>004C: Unit # | Access code
>004E: Pointer to file name
>0050: Addt'l Info

The meaning of each entry is:
Unit # : Indicates the disk drive on which the operation is to be performed. This entry has to be either a 1, 2, or 3.
Access code: An access code is used to indicate which function is to be performed, since this subprogram combines multiple functions. The following codes are used:
0 Create file and copy Level 3 parameters from additional information area
N When N is not equal to 0, indicates the number of AUs to be written to the given file, starting at the AU indicated in the additional information block

Additional info : Points to a 10-byte location in CPU RAM containing additional information for direct disk access:
X+0 : VDP Buffer start address
X+2 : # of first Allocation Unit
X+4 : Status flags | # records/AU
X+6 : EOF offset | Logical Record size
X+8 : # of level 3 records allocated

VDP Buffer Start Address: Indicates where the information read from the disk can be stored. The buffer has to be able to store at least N * 256 bytes, in which N is the access code.
# of first AU : Indicates the AU number at which the read should begin. If the access code = 0 (parameter passing), the total number of AUs allocated for the file will be returned.

The remaining 6 bytes are explained in the Software Specification for the 99/4 Disk Peripheral. The user should be very careful when changing these bytes, since they directly affect Level 3 operation. If the information in these 6 bytes is not modified consistently, unpredictable results may occur.

Error codes are returned at location >50 in CPU RAM.

----------------------
BUFFER ALLOCATION ROUTINE - SUBPROGRAM >16

The transfer block for this subprogram is:
>834C: ZERO
>834E: # of files | ZERO
>8350: ZERO

The "argument" for this subprogram is the number of file buffers to be allocated. Whilst it is not actually necessary to clear >834C, & >8350, experience has shown that strange results sometimes occur if you don’t.

The effect of this routine is that an attempt is made to allocate enough VDP ram space for disk usage to facilitate the simultaneous opening of the given nuumber of files. This number has to be between 1 and 16.

The disk software automatically relocates all buffer areas that have been linked in the following manner:
Byte 1: Validation code
Bytes 2 & 3: Top of memory before allocation of this buffer.
Byte 4: High byte of CRU address for given buffer area. For programs this byte is 0.

The linkage to the first buffer area is made through the current top of memory, given in CPU ram location >8370.

The top of memory is also automatically updated after successful completion of this subprogram.

A check is made that the current request leaves at least >800 bytes of VDP ram space for screen and data storage. If this is not the case, or if the total number of buffers is zero or greater than 16, the request is ignored and an error code will be indicated in CPU ram location >8350.

Successful completion is indicated by a 0 byte in CPU ram location >8350. A non-zero byte indicates unsuccessful completion.

Assembly

Assembly and Joysticks. Unfortunately I have to put the code here as an image, apologies.

MINI MEMORY

by Robert Wordsworth

How to read the keyboard in Assembler, using the KSCAN routine. What may not be obvious about KSCAN from its name is that it is also used for accessing the two joysticks. It may be useful to recall how we access the joysticks in BASIC, using CALL JOYST:

CALL JOYST (key-unit , x -return , y-return)

We set the "key-unit" to one or two depending on which joystick we want to read. (Note that we can also set the key-unit in a CALL KEY to one or two if we want only to read part of the keyboard in, for example, a two-player qame. "x-return" comes back to us as -4 (left), 0 (centre) or +4 (right); ‘y-return” as -4 (down), 0 (centre) or +4 (up).

In Assembler things are very similar. The “key-unit" becomes our old friend byte >8374. When reading the keyboard we set this byte to zero. If we had wanted to do a "split keyboard" read, we would have set it to one or two, depending on whether we wished to read the left or right hand side of the keyboard. We also set this byte to one if we wish to access joystick one and to two for joystick two.

After calling KSCAN, byte >8376 will contain the "y-return” of whichever joystick we are checking and byte >8377 the "x-return". The values of these bytes are as with BASIC: -4 for up or right, +4 for down or left, and 0 for centre. The value -4 will of course be held as a one-byte binary number, hexadecimal representation >FC.

A word of warning at this point. As you know, the screen is represented in VDP RAM by a 768-byte area in which each byte holds the ASCII code of the character displayed at the corresponding; position on the screen and where byte 0 represents the top left hand corner of the screen, byte 32 the first position in the next line down and so on.

The screen position is determined by the value in register 0 when we call the VDP write routines. To move down the screen one line we would add 32 to the value in register 0.

The " y-return " however, is -4 for going down and +4 for going up. We therefore need to negate this value before converting it to a screen displacement to be added to register 0. We also need to convert a value of 4 to a value of 32, in other words, multiply by 8.

The “x-return” is correct since +4 represents "right", but needs to be divided by 4, since we only need to add one to register 0 to move one character position to the right.

Values such as 4 and 32 crop up quite a lot. in programming since they are powers of two. To multiply or divide by a power of two is easy to do using shift instructions.

Just as in decimal arithmetic we multiply a number by ten when we "shift" it to the left by adding another nought at the right-hand end, so the binary numbers in our registers we multiply by two whenever we shift them to the left by one bit position.

TI have thoughtfully supplied some instructions just for this purpose. The two we are going to use are SRA, shift right arithmetic, and SLA, shift left arithmetic. They have two operands in the format:

workspace-register , shift-count

The number to be operated on must be in a workspace register. So, for example, if we wished to multiply the number in register 8 by two, we would code

SLA R8,1

since shifting a number one bit leftwards multiplies it by two. If we wanted to multiply by four we would code

SLA R8, 2

since shifting leftwards two bits multiplies by four. To divide by eight we would similarly code

SRA R8,3

With the SRA instruction, the sign bit held in the leftmost bit fills up empty bit positions that have become free as a result of the shift. This preserves the sign of the number. Note that in this article I have coded registers with their "R" prefix in response to popular request (Colin Hinson’s actually). The second operand of a shift instruction is not however a register and so cannot be prefixed with an "R“.

The following little program moves a ”+” sign around the screen in response to joystick number one. The shift instructions are used to convert the -4/0/+4 return values to the appropriate screen displacements, with NEGate being used with the y-return as mentioned above.

>
There is nothing to stop you going off the top or bottom of the screen. Doing so may cause unusual effects as we’ll be overwriting parts of VDP RAM outside the screen display area which are used for other purposes.

As regards the comment about Editor/Assembler, the program will work with it, although unless you are loading the assembled object code into MiniMemory the AORG should be removed.

To use Editor/Assembler you must have 32K + disk drive of course.

Now that I have joined the happy band of disk owners I realise how much I have been missing all these years, but I feel that MiniMemory-only users can’t be forsaken.

Happy coding, Robert

[Sorry about the image up there, but to keep the page compatible with the mobile devices everyone is using these days I have had to put the code as an image which can be rescaled. Also my OCR software could not cope with this and I am very unsure about my ability to copy it without error.]

Adventuring

Go to top of page