ORIGINALLY PUBLISHED IN LIMA NEWSLETTER JUNE 1994 LETTER from AUSTRALIA - No. 7 Apr / 94 --------------------------------------- Well, it does seem a long time since I last put fingers (2 of them anyway) to keyboard to bash out a Letter. Actually I did start one in January, about on schedule but events conspired against it. Just after New Year I tried to install a 80-track drive on the Hawks Nest machine, so I could spend evenings of a lazy summer vacation doing some TI programming. Disaster struck however and in process of hooking up the drive to a PC power supply, I managed to reverse the power leads to the Mechatronics 80-Z unit. It was downhill with Murphy all the way from there. Although the PE-Box turned out to be undamaged, the first spare normal console did not work - a dud power supply and of course it was one with a mid-lead connector. Any other I could rustle u p had on-board snap-on connector. So out with the CC-40 and Memo-Writer. Time to do a Charlie Good and compose a Letter on that and download it later to the Kotara machine. No luck there -- after several attempts, new batteries, every time the Memo-Writer would lose its conte nts when it was put aside for later work. Either something is faulty in the CC-40 or the M-W cartridge does not really handle 18 Kb expanded machines properly. Eventually I gave up in frustration. After that came a vacation trip to New Zealand. The air tickets were William's Xmas present to ancient parents - that was the least of the expenses, but I could not convince him to pick up the damage to the Master Blaster. According to our Kiwi friends February is the best time to visit NZ, unless you are specifically after a skiing holiday. With only 2 weeks or so we chose to restrict our visit to the South Island, and scarcely had enough time for that. As it turned out the weather was well-nigh perfect, sunny and clear all the way down the west coast of the South Island, a very rare event indeed in summer. This followed on a period of extreme rainfall and flooding in the South Island. Some of the mountain roads such as Haast Pass had only just reopened so tourist numbers were down temporarily. Many things about NZ were more or less as expected, but some that I should have been prepared for came as a surprize. Mostly this was to do with driving around the country. Our experiences have been of Australia and the USA, both rather large countries. You can drive from east to west coasts in NZ in just a few hours if you don't stop to look at the scenery along the way! That is obvious enough from a map but still a surprize. Mountain driving is not what we expected at all. We were used to the western US of A where mountain driving starts at 5 or 6000 feet and goes up from there, and were thinking of high altitudes and cold at night - there are glaciers after all. That's not how it is - most of the driving is at or near sea level, and even the passes are only 3000 feet or so, even though the mountains rise to 12,000 ft. That is not to say it is trivial. The mountain s of NZ are very young in geological terms and always eroding do wn in great landslides, and it is only about 6 million years since tectonic plate collisions caused the uplift. The recent ice ages ground out deep glacial valleys all over the place. The narrow west coast plain has formed from all the eroded material being washed back up. I could have spent days and days just picking up the beach pebbles and driftwood at Hokitika and Gillespies. The relationships between NZ and Australia show quite a few parallels to those between Canada and the USA. Small country reacts to much bigger neighbour. NZ does share with Australia the characteristic attitude expressed in the phrase "She'll be right mate!" common to both countries. In NZ however they have a corollary to that which runs "Geez, how did thet heppen" with a slight attempt there to convey the NZ pronunciation. Mainly this differs from Australian pronunciation in the vowel sounds, and to Australian ears the accent is quite distinctive. Unlike the U S where there are distinctive regional accents, the Australian and NZ internal variations are more between "educated" and "broad". Regional variations tend to be more in items of vocabulary than accent. I still use terms that date from my Queensland childhood which are foreign to NSW where I now live. I sometimes think all those Kiwis come to Australia looking for their lost vowel sounds. One thing that is good in NZ is "fush and chups" - the only place we have had it as good in Australia was at Apollo Bay on the Great Western Road in Victoria. I guess that shares an exposure to the Antartic. Much of the South Island of NZ is south of Tasmania, but it amazing how easily you can get sunburnt in the Otago region. In NZ they are very conscious of ozone depletion problems. Driving a car in the South Island is an interesting experience. NZ used to be a rolling museum of old British cars, but now these have been largely displaced by imports of second hand Japanese cars. Like Australia, Japan, and the UK the cars are right hand drive, so we had no adjustment problems there, apart from dodging the occasional US or German tourists who had forgotten what side of the road they were supposed to be on. We have scared some American drivers in our time in the US too while adjusting - once you have changed over a couple of times the switch becomes just another driving skill. NZ is the last refuge of the one-lane bridge even on main highways, and in one place on the west coast a long one-lane bridge is shared by the railroad track. Very unnerving when you are out in the middle. Kiwis treat speed limits very casually. You can usually tell you are in a town area with 50 km/hr speed limit by noticing the traffic is all moving at 70 km/hr, and 20 km/hr over the limit is the basic norm. I gather speed cameras were introduced last December and made such a haul that the protests are still reverberating and there was no sign of them while we were there. I had better stop talking about NZ before this becomes the the equivalent of forcing you to look at the slides from our holiday. Magic moments included walking to the terminus of the Fox Glacier just near sea-level rain-forest, a helicopter trip to the top of the glacier, and the glow-worm cave on Lake Te Anau, known from Maori legend but lost for centuries and only rediscovered relatively recently. All in all I can thoroughly recommend NZ as a place to visit. Nature is said to abhor a vacuum. In this case it fills it with possums. The word must have gone out and some new ones moved in. Also the Animal Welfare lady brought back the baby possum whose mother had been savaged, a tough little survivor that one. So now we have a full complement that come down outside the kitchen door for food. You do get a different slant on them in NZ however. Australia has its own set of disasters with introduced animals - rabbits, foxes, cane toads, starlings, mynahs, and domestic ones gone feral such as cats, pigs, and goats, just to list a few of them. In NZ also they have a hugE list of introduced disasters, not the least of which is the common Australian brush-tail possum. These have gone crazy in NZ and are destroying much of the native forest. In Australia the level of toxins in the tree leaves that they eat keeps a reasonable balance, but in NZ they munch up almost everything and are in plague proportions. On the west coast of NZ approaching Hokitika we went along one section of road where there were squashed possums every meter or so. Most programming work around here has been on Editors in various versions. Ever since the coming of the AVPC, developments in this area have been driven by the 80-column versions, with the 40-col following along as best it can. Most recent releases have been the Vn 5.01 80-column version with large 64 Kb buffer in 9938 VDP extension VRAM. To put this in user terms, I have combined all the 80-col documentation into a single file 310 sectors long on disk which still leaves more than 10% of the text buffer free. I am currently working on a symmetrical "editring" version which replaces the large DiskReview type of View buffer with a second text buffer with exactly the same properties as the first one. It can still be used as a View buffer if desired, but with exactly the same capacity and edit and search functions as the first buffer. I think I finally slew all the RS bugs in the 40-col ED/AEH version last night and e-mailed off the corrected version in TIED form to Charlie this afternoon. By the time you read this you will have seen it at the Lima MUG or have received it in the Lima UG distribution. Now if you have 80-col capability you will have found that it works as well as the earlier regular size buffer versions despite the greatly increased capacity. A preliminary test is sue of this was set up for programmers' editor function only because buffer handling speed was such that word-wrap mode would not have been realistic. So what has changed? The test version used VDP RAM as just a larger buffer for text data, but separated this from the line table which was kept in CPU RAM. The large size combined with the inherent inefficiencies of reading and writing to VDP memory slowed down buffer manipulation functions to a degree unacceptable in a general purpose editor. The next step was clear as I was also looking to the future of using CPU RAM expansions, which of necessity page in numerous smaller blocks of RAM, and only one of these can be addressed at a time at a given address. VDP memory is different in that though there is a 16 Kb bank size built in, reads or writes can auto-increment over the whole range which is what was done in the test P/E-only issue. So what we are facing is the design of a buffer manager that can handle a banked or segmented buffer structure. There are gains to be made here, because if only a one or two segmen ts have to be attended to at a time, even if there is overhead in deciding just which segments, we may well come out way ahead on the amount of buffer shuffling that has to be done. I have talked about how TI-Writer type editors handle buffer management in previous writings, but I will give a brief summary here. The design concept is to keep the buffer manager as a separate layer with a small set of defined interface routines called by the edit code. This has been extended in the segmented model by another layer which is called by the previously defined buffer functions, and the edit code remains blissfully unaware of the details of the text buffer. The exception to this statement was the buffer initialization called by Purge which acted directly on the buffer pointers. The original TI-Writer defined a set of line oriented services, and was not particularly tightly written and even very inefficient for block functions. The general structure of the one piece text buffer is a downwards growing table of line pointers to an upwardly growing pile of compacted ("squished") lines. No gaps are left in this pile. It is shuffled down when a line is deleted, and new lines are added to the top. Text buffer full occurs when the two collide. These services are B LWP calls to INSTLN -- adds a new line to the buffer and inserts a new entr y in the line table. DELTLN -- deletes a line by removing it from the text pile, an d adjusts all line pointer references as necessary. UPDTLN -- replaces the modified line with the new one, deletin g the old and inserting a new line if necessary. GETLN -- fetches and unsquishes an existing line from the text bufer. These have a small cast of supporting BL routines, to generate line numbers, locate lines in the buffer, check for possible overflow, adjust the line table, and to do mass moves of the text buffer. Later versions of the Funnelweb editors added some block oriented BLWP services to improve handling blocks o f lines for Copy and Delete which was handled with appalling slowness by the original TI written code. Another BL service, MVLINS was added to optimize line table block shuffles as need ed for the Move lines function, which now occur rapidly with no risk of overflow (TI's terrible original code first copied the bloc k line by line and then deleted the original also line by line). DLBLOC -- deletes blocks of lines by contiguous blocks in the text buffer, and is very much faster for a well ordered buffer, and usually much faster than doing it line by line. In the worst case it is no better than the original, but in practice the text buffer is rarely so disordered. CPBLOC -- copies a block of lines by making tentative additions of the copied lines and their pointers beyond the existing contents. If buffer overflow would occur the attempt is abandoned with no changes, and if successful only a single reshuffle of the pointer table is necessary. Now in the new segmented buffer model, the edit code sees exactly this same interface. The new buffer manager introduces a layer of services below this, the segment manager. A variation that had already been made in the P/E-only large buffer test issue was that the line table occupied its own area of CPU RAM in high-mem, and line table overflow became a separate issue from text overflow. The capacity was made large enough to cover most normal usage of a 64 Kb text buffer. It was found desirable to introduce seven new BLWP services for the segment manager. INISEG -- sets up the data tables and pointers for the segment ed buffer structure. This is called by the Purge routine in the main code, and isolates all details of the buffer from the caller. FNDSEG -- locates and returns segment data for the segment containing the particular line requested by line number. GETSEG -- returns the data for the first segment it can find w ith enough room for the line to be stored. TMPSEG -- sets up a temporary segment data table for use by the block copy function. MAXSEG -- locates the temporary segment with the most room left to see what size of contiguous block can be stored in one hit. UPDSEG -- updates the permanent segment table for a successful block copy that does not cause overflow. FRESEG -- returns data for the SD display showing text buffer and line table free. As you can see it is the Copy Block function alone that is responsible for 3 out of 7 of these. Deeper below these still are the routines for setting up bank switching and VDP addressing. These are of no concern at all to the edit code, and would change drastically if a different form of banked memory were used. The manager currently assumes a 64 Kb fully byte addressed buffer as its model, segmented into from 2 to 32 segments of uniform size in binary sequence. This allows for a 2 Kb minimum size which would be appropriate for the banked memory in Horizon family RAMdisks. The Vn 5.01 editor as issued uses 4 Kb segments, a size chosen deliberately not to match the 16 Kb banks of VDP. The segment size can be altered by a single dat a word in the program, but I have not yet had the time to experiment to find the optimal segment size. The next stage of development beyond the 2 file edit-ring using VDP is to extend the edit ring approach to banked RAM devices of one sort or another. With this it would also be possible to extend the large buffer model to the 40-col version. Whether that effort is worth it or not, I am still not sure. Immediate plans are to use a 192 Kb HRD for this purpose, as I have one of these spare for use as a memory expansion. The Quest RD would make a good candidate as it has a simpler CRU banking structure, but I am short of RAMdisk space and cannot spare it . The AMS looks too small at 128 Kb to be of more than limited interest now that the edit-ring idea is up and running, as it would support only a single full 64 Kb buffer in this size. Talking of that device, I know it only from description, but the opinions expressed in the last Letter were carefully considered. The article from Jim K in the Feb/94 BB&P missed the point in its highly polemical defense of the design decision (flawed in my view) not to have a DSR ROM. The comments I made on this in no way implied that a DSR was necessary for memory access via DSRlink search and DSR routine execution though Jim K seems to be stuck on this model as a straw man to tear apart. What a DSR could and should provide at the very least is test functions, and as a report I have seen from Germany on the AMS card indicates, initialization function for warm restarts as well. It does not really matter, as the path of memory expansion for general purpose use around here will of necessity be the surplus small HRD. If you are curious when and where this is being written, I am at home on my TI-99/AVPC, with the radio playing Lester Flatt tunes on the ABC's Sunday night country music program - which much to my liking tends to play a lot of bluegrass, the C&W stuff itself not being of much interest. I did start to write it on the PC as it will be e-mailed via my office PC to Ohio when do ne, but I find I like using the FW Editor much better than any PC editor I have, so I will put up with the extra step of transferring it to PC disk. Tony McGovern Funnelweb Farm May / 01 / 94 e-mail -- phpam@cc.newcastle.edu.au Delphi -- GLOBAL01