TiSHUG
News Digest Ti99/4A Articles

The Articles appearing on this page are from TND, the monthly magazine of the Texas Instruments Sydney Home Computer Users Group. They are usually created by our members, but often include articles reprinted (with permission) from other sources. If you have written an article that you believe may be of interest to the Ti 99/4A community, and you would like to see yourself in print, please submit your article to the TiSHUG Board for approval and inclusion in both the magazine - TND - and this site.
RGB Interface Revisited
Assembly File Formats
Cassette to Diskette File Transfer
Clocking the Groms
What is a Ti 99/4A?
The Shahzada EnduranceHorse Ride

TI-99/4A RGB Interface Revisited
Which is the best?
by Lou Amadio

I was talking to Eric Ockenden at the December meeting about the various TI console to RGB monitor interfaces that have been proposed over the years. Apparently Eric has built them all and said that he was in a position to advise on which was the best. Of all the designs that he tried, including one from TI, Eric liked a hybrid that he made using a Peter Schubert design, described in the May 1988 TND, but using the Geoff Trott sync separator from the RGB design in the Feb 1990 TND. Eric made me curious, so I convinced Geoff that we should look into it during the Christmas break. We used the console introductory screen for all of the comparisons. First we looked at the colours produced with an 80 column card which uses the TMS9958 video chip. This chip produces sharp characters with brilliant colours, particularly in the reds. White, however, we thought had just the slightest trace of red in it. On measuring the R,G and B levels, we found that the R drive out of the chip was 50% higher than the other colours. Next we tried Eric's hybrid design. Setting up proved to be particularly awkward as we had six pots to adjust. What was worse, there was some interaction between the pots and it was possible to cause some colours to saturate. Adjustment was difficult, even using a CRO. Geoff reminded me that it was the complexity of this circuit that prompted him to design his RGB interface in the first place! The final result was good, but not as good as that produced by the 80 column card. Finally we tried Geoff's own design (Feb 1990). When set up as per the original article (2.76 volts at the base of the G-Y amplifier) the image was sharp, but colour saturation was a little low, particularly in the reds. Geoff said that the colour levels in his design were based on the specification in the TMS9929 manual. We then changed the output resistors from 330 ohms to 220 ohms for blue and green and to 150 ohms for the red. This brought the B and G to R colour ratio in line with that from the 80 column card (1:1.5). The results were more pleasing with respect to colour saturation and the image sharpness was just as good as before. All in all then, the February 1990 RGB design by GWT was found to be the best for standard consoles and can be made even better with the small modifications described above. My thanks to Eric Ockenden for supplying the PCB and overlay used in this comparison.

DATE:7/9/98
Back

DISK ASSEMBLY FILE FORMATS.
DISPLAY FIXED 80 (UNCOMPRESSED)

Tagged object code may be loaded by option 3 using E/A, option 1 using Mini Memory or using CALL LOAD in TI BASIC with either the E/A or MM modules. It can be ABSOLUTE or RELOCATABLE. The Absolute code must always be loaded at the same place in memory while Relocatable code can be loaded anywhere. If the Tagged Object has references to other files or subroutines they will be resolved by the loader, except in the case of the XB loader. If source code does not contain an AORG directive then the code will be, by default, relocatable.

COMPRESSED TAGGED OBJECT code is like Tagged except that the program data is saved in bytes allowing it to load faster. It contains characters outside the printable ascii range and cannot be modified by the E/A editor. Compressed object files are created by using the C option with the assembler. They are NOT loadable by the X/B loader, however they are loadable by basic under E/A and E/A option 3 etc.

MEMORY IMAGE format is the most compact and the fastest loading of Assembly programs and can be stored on disk or cassette. It is identified as a PROGRAM file in a disk catalog and can be loaded with option 5 using E/A, or option 3 using TI-Writer. Please note that the screen will go blank and must be turned back on by the program itself after loading is complete. Memory Image files are produced using the SAVE utility on the E/A disk "B". Memory Image files like BASIC programs can be accessed from/to any I/O device with a single I/O call. That is why they load so fast.

There is a size restriction for MEMORY IMAGE FILES OF 8192 BYTES, ( hex 2000), although the E/A the TI/WRITER Modules will load multiple Memory Image files to make a larger program. The loader does this by looking for files after the initial file is loaded whose filename is similar except for the last character which is incremented by one. EXAMPLE: The file GAME is loaded. The loader then looks for GAMF, GAMG etc., if such files are required due to program size. MEMORY IMAGE assembly files have a 3 word header followed by the data to be placed in memory as follows:
1) The first word is a 'FLAG'. If it is not 0 (zero) i.e. >FFFF then this file is not the last in a multi-file program. For example, if the flag for GAME is >FFFF then there HAS to be at least a file named GAMF, etc..
2) This word is the length of the Memory Image file in bytes, including the six byte header. The largest value here is >2000.
3) This word is the CPU RAM address where the file is to be loaded. Execution always begins at the first byte of the first segment loaded.

Retyped for TEXPAC BBS by John Ryan,
edited by Ross Mudie. DATE:10/9/98
Back

HOW TO TRANSFER PROGRAMS BETWEEN CASSETTE AND DISKETTE?

Normaly OLD DSK1.PROGRAM; SAVE CS1 will work. But what when the file is too large and even CALL FILES(1) won't help?
After loading an INT/VAR 254 from disk you can type in: CALL LOAD(-31888,63,255). This will act like CALL FILES(0) and sometimes the program can be saved. If not, it's realy too big too fit on cassette. But how can you get a file from cassette on your disk thatwon't load because it's too big.
Simply by using the DSKBUF program. How? Type in: RUN "DSKx.DSKBUF/EXB" (only ones)
CALL LINK("SAVE") (this will save the disk buffer)
OLD CS1 (the program has to load now)
CALL LINK("LOAD") (this will restore the disk buffer)
SAVE DSKx.PROGRAM (or any name you like)
Eric-Paul Rebel
Merelstraat 27
1223 NR HILVERSUM
The Netherlands
DEF SAVE
DEF LOAD
VMBW EQU >2024
VMBR EQU >202C
SAVE MOV VDPTOP,R0
VDPTOP,R0
VDPTOP,R0
VDPTOP,R0
MOV R0,SAVTOP
SAVTOP
SAVTOP
SAVTOP
LI R1,DSKBUF
LI R2,>4000
S R0,R2
BLWP VMBR
VMBR
VMBR
VMBR
LI R0,>3FFF
MOV R0,VDPTOP
VDPTOP
VDPTOP
VDPTOP
RT
LOAD MOV SAVTOP,R0
SAVTOP,R0
SAVTOP,R0
SAVTOP,R0
MOV R0,VDPTOP
VDPTOP
VDPTOP
VDPTOP
LI R1,DSKBUF
LI R2,>4000
S R0,R2
BLWP VMBW
VMBW
VMBW
VMBW
RT
SAVTOP BSS 2
DSKBUF END

DATE:10/9/98
Back

Clocking The Groms
by Lou Amadio Illawarra Regional Group

During the Christmas break Geoff Trott and I carried out an interesting experiment at the Wollongong University. We wanted to see how far we could push the GROM clock in frequency before the console refused to work. Amongst other things, we were hoping to show some improvement in speed with TI BASIC / XBASIC and GROM modules.

TI conveniently provided a link on the motherboard for isolating the clock line to the system GROMS. We lifted this link and injected a clock signal from an external signal generator. The specification for the GROM clock frequency is approximately 440 kHz to 480 kHz. The console that we were experimenting with had a clock rate of 448 kHz - ie at the lower end of the range. The experiment was carried out by switching the console off, adjusting the frequency on the generator and then switching the console back on again. We were amazed to find that we could reliably run the GROMS at up to three times their normal speed (1.3 Mhz). There was no abnormal overheating of any chips on the motherboard and the console ran quite happily at the maximum GROM clock speed. The only peculiarity that we noticed was a change in pitch in the reset tone. Did it make any difference to the speed of the console? In a word, no. We ran a BASIC program which changed the screen colours and carried out some mathematical calculations but the results with and without the clock modification were very similar. The bottleneck in speed must therefore be in a different area. We welcome any ideas on this subject.

DATE:7/9/98
Back

Computers and more and the Shahzada Endurance Horse Ride
by Ross Mudie

I thought I would share a little of what I am doing these days in my 'spare' time with computers. As longer term members would know (or may by now have forgotten), I became involved with the little old TI99/4A Home Computer back in 1984 when TISHUG was meeting in a church hall in Kings Cross. The TI99/4A was my first taste of computers and I had not encountered anything like the enthusiasm of Shane Andersen and other members of the TISHUG committee. I was also involved in Amateur Radio and participating in some various fairly serious sporting events as part of WICEN (Wireless Institute Civil Emergency Network). This involved providing part of the radio communications from check points to base for motor bike rallies, car rallies and endurance horse rides. Soon I found myself providing Public Address systems and computer at the WICEN exercises because I had an interest in this direction and in some cases other people weren't prepared to take their computers, printers etc into events where the roads were rough and the conditions were dusty due to equipment becoming damaged etc.

In 1989, the Shahzada Endurance Horse Ride committee approached me to provide computer and PA for their 5 day, 400 km endurance ride in St Albans, NSW, just 21 km up the Macdonald River from Wisemans Ferry. The popularity of the event was growing and the job of doing PA, communications and computer was getting out of hand for the committee. After a number of meetings and phone discussions, I developed a 'data base' type of program to run on the 32K TI99/4A home computer to handle up to 240 entrants in the 5 day Shahzada. The event is centred in the village of St Albans and the riders take their horses out on a different marked course each day, for about 50 km on the first leg and 30 km on the second leg. Each leg of the event each day starts and finishes in St Albans. The first leg starts at 4 am or later, there is a minimum 1 hour rest period between the first and second legs and the second leg finishes back in St Albans before 5 pm daily. The daily courses are through extremely steep, rugged and breathtakingly beautiful terrain of the farms and National Parks in the Macdonald Valley which is part of the Colo Wilderness. This article is written as I am preparing for my involvement in the 18th and my 10th Shahzada.

On the first year and for a few years after, all the data was entered at the event and this was a mammoth task. In my first year, which was the 9th year of the Shahzada being held, there were a massive 102 entries. (In later years, pre-nomination was introduced to put some sanity back into the operation by entering all possible data before going to St Albans). The 'pre-ride' data consists of names, addresses, division of entry and horse information including breeding and veterinary data. During the event there is start and finish time data for each leg plus the horse pulse rate twice daily and the daily horse weight. The computer program calculates things like time taken for a leg of the event, the average speed per leg, average speed for the day, total time for the day and a running total is kept of the time taken over the five days. A certificate of achievement is printed out of the event data for each successful horse at the end of the event. The event is under very strict veterinary supervision and the data base program has to be able to eliminate entrants whose horses are considered unfit to continue in the event.

As the event grew even bigger, it became impractical to try to do the whole thing through just one little computer and so I needed to look at how to hook extra computers together to form a Local Area Network (LAN). Other factors which made the setting up of a LAN 'interesting' was the 'virtual zero budget' and the risk of damage to computers due to dust and moisture. I had my communications caravan for the LAN server and main terminal location which was reasonably clean and dry, but the other computers are housed in horse floats and tents, complete with the elements of overnight mist, dust, rain and sometimes driving wind which accompanies the rain. The terminals are located at the Ride Secretary (on a temporary verandah under a tarp or in a tent with a dusty earth floor), Time Keeper, Weighing Scales (both in horse floats which seem impossible to keep dry with tarps) and WICEN (in a caravan).

Because of the fact that I knew the TI operating system quite well, I developed the little LAN on the TI99/4A Home Computer using Extended Basic and Assembly languages. I also had a fair amount of hardware which had not cost too much, thus would not involve too much loss in case equipment was ruined by the elements at the event, (a wise move). I also wasn't prepared to have a system there that I couldn't fix if something went wrong, because I knew that I would have absolutely no one to call for help if things went wrong.

The server was initially a TI99/4A with two RS232 cards, giving 4 serial ports running at 9600 bauds for communications and a RamDisk. Later an additional RS232 board was built, expanding the server system to 6 serial ports. The terminals were TI99/4As with one or two serial ports. The longest distance from server to terminal is about 100 metres of cable.

There were problems with the TI's at the terminals. A major problem was some of the people who were co-opted into entering the data at the Time Keeper, Secretary and the Scales were used to the IBM type keyboard and had real problems coming to grips with the tiny and to them quite awkward TI99/4A keyboard. Reliability with the TIs at the terminals also became a problem because of the plug socket of the expansion out of the keyboard / console and the plug connections to extended basic. Due to these reasons, I developed the Shahzada terminal program to run on PCs. I used GW Basic (because I had it) and set up around using old XTs or ATs or 286s. Basically computers with very low or zero cost because of the real danger of computers being ruined by the elements. (I had already written off some TI bits because of water ingress). The migration to the PCs made me think about going to some sort of commercial LAN, but the benefits available from just connecting the serial ports together with 6 wire cables made from telephone type wire and the ability to hook any sort of PC on the end of the system via the available COM port also meant that in the event of a terminal computer failure it was not a big drama to use another PC. Load the software from disk and away the new computer went. All the development had to occur on week ends or week day evenings, basically in the 'spare time' which seems to becoming a shrinking commodity these days.

A basic principle of the data base entry routines was to keep the operation as simple as possible for the users at each terminal. Giving the time keeper just the fields of start and finish time to enter on the correct day, the scales just the fields for weight, the ride secretary's office just the daily pulse and the scratchings to enter, whilst allowing all of them to view entries in the whole data base to answer questions about how individual entrants are going. The terminal programs needed to be simple enough for people who were not at all computer literate to use after a short period of instruction.

Each terminal is configured from the LAN server for its operational function which is read when the terminal boots up. The terminal knows what day it is working in from the time of day clock in the LAN server. When the terminal operator keys in the entrant number, that entrant data is retrieved from the server and displayed. If data already exists for the field being entered, the operator is prompted to initiate change else the new data is added to the existing data and automatically saved back in the server. Safeguards are provided to prevent data for a particular entrant being changed by two terminals at once which could result in the data from the first terminal re-saving the same-entrant number data being lost.

There is a need to deliver information from some terminals direct to another organizational area in hard form. The time entered by the time keeper is also needed by the ride secretary's office to manually fill in the horse log book and WICEN needs to know when a horse is scratched so that operators are not held in the field for horses that are already eliminated. This is achieved by providing a serial cable out of the second COM port on specific terminals direct to small dedicated printers at the required area. There is nothing extra for the person entering the data to do; the terminal sends the data to the LAN server then reformats the same data for delivery to the appropriate dedicated printer. This feature works well and sure beats using runners to hand deliver the information.

Routines are provided in the main terminal software (some of which still runs on a TI) to sort and print into various report formats. The printer used for the event is still a Canon Bubble Jet. Somehow I wouldn't feel very comfortable taking an expensive laser printer into the event. Tasks such as paper logging of entered data and printing of address labels are handled on an old (and very noisy) Burroughs 142 column dot matrix printer. The end results from the Shahzada are put together in a book which usually exceeds 50 pages and is photocopied and distributed to all the entrants.

I have come to the point where I have thought about upgrading the LAN server to a 386, but the Shahzada currently is only likely to run until the year 2000 or 2001. It would be nice to have a faster server with more reliable hardware, the connectors on the TI are a problem, but with the sunset on the event it seems hardly worth the effort in developing software and changing over to different hardware.

There are two other computer systems used at the Shahzada. I use a 486 running Word 6 for Word Processing tasks, such as writing text type reports to be included in the results book and there is a synchronized time clock system. The 486 uses the bubble jet printer and computer selection is achieved with a manual printer switch.

The synchronized time clock system runs quite happily on a little old TI99/4A in assembly linked from Extended Basic. This computer contains a small RamDisk, 32K RAM and time of day clock chip and it uses a stand alone disk controller. There are two time formats presented on the screen in large size characters, i.e., the current time and the time with 30 minutes added. The purpose of the time clock is to allow the time keepers to correctly record the 'time out' or the 'time in' and the 'half hour vet time' for each entrant. When an entrant comes in, the strappers have 30 minutes to work on the horse to ensure that it passes the veterinary inspection. Each rider is issued with a paper, hand written time slip showing the 'time in' and the 'half hour vet time' when the horse must be presented to the vets. (There is also a variation of the time clock program for events where they have a mandatory one hour from 'time in' to 'time out' which gives 'IN TIME', 'Half Hour Vet Time' and 'DUE OUT TIME' in 3 rows of large characters). The analog video from the time clock computer is fed via a splitter driver box into telephone type cable to additional monitors so that the same synchronized time is available to the time keeper, the ride secretary's office and the Vet area. The special interfaces used to drive and receive the monochrome video over telephone type cable have operated at distances up to 150 metres. The TI version of the time clock also doubles as a 'watch dog' on the LAN server and it issues an audible alarm if the server stops for any reason. A similar time clock has also been written in GW Basic to run on a PC but it is very slow to change its display on a XT or slower PCs.

I also set up and maintain the Public Address for Shahzada, which at the 1997 Shahzada consisted of 102 loud speakers driven by 4 PA amplifiers with microphones at 4 locations in the control part of the base camp. The speakers are set up to cover a base camp area which is about 700 metres end to end, about half the area of the village of St Albans. By using a larger number of loud speakers, the PA system doesn't need to be excessively loud to provide good coverage.

If any reader is interested in visiting the event, the Shahzada is held in the last full week of August each year, this year the pre-ride vetting is from 2 pm to 6 pm on Sunday 23/8/98 and the event starts at 4 am on Monday 24/8/98, finishing at 5 pm on Friday 28/8/98. St Albans is 21 km from Wisemans Ferry and visitors from Sydney direction may use either of the two vehicular ferries. There is 10 km of usually reasonable unsealed road surface on either access road from Wisemans Ferry to St Albans, or over 30 km if you approach from the Kulnura - Buckitty direction to the north of St Albans. Drivers should watch out for horses on the roads. Day visitors can obtain lunch at the historic Settlers Arms hotel or the Fickle Wombat tea house. There is no overnight accommodation available at this time of the year so if you are planning to stay in the area overnight, you will need to bring your own. Overnight temperatures as low as -4 degrees Celsius have been recorded in the base camp with day time temperatures up to 30 degrees.

The Shahzada Endurance Horse Ride is a very special and unique marathon horse event which requires high degree of physical and mental stamina of both the experienced horse person and the suitably trained and prepared horse in addition to good horse management skills.

The Shahzada is a commemoration of a particularly tough and very successful Grey Arab stallion which was foaled in England in 1913 and won a 250 mile endurance test in 1920 and a 500 mile endurance test in 1922 in addition to numerous prizes in English Agricultural Shows. Shahzada, the horse, was imported into Australia in 1925 and he stood at stud for many years.

Anyone wanting more information about the Shahzada Endurance Ride or the computer programs / hardware developed for the event should contact the author.

DATE:8/9/98
Back

The Ti 99/4A Home Computer
Texas Instruments constructed a 9900 series chip for military use in 1977 or there abouts. This chip soon became the heart of two small - by today's standards - computers. The version for home use was called was called the Ti 99/4.

This computer came with an impressive 16 colour capability and 256 bytes of RAM. It had access to most of the 16 Kb of memory that was used for the display as well, so it was generally considered to have an impressive 16 Kb of RAM. It was soon followed by the Ti 99/4A version which had a cheaper version of the CPU which was set in plastic rather than the military standard gold and ceramic.

The Ti99/4A was a 16 bit system that could do some impressive work back then. In fact it was only the due to a couple of poor management decisions that prevented the 99000 series chip (the next generation) from becomming the chip on every desktop. Intel chips did not catch up with the technology of the 99000 until the late 80s with the 386DX series. (I will post an article about this in the near future)

Back