ftp.whtech.com/ftp.whtech.com.tar/ftp.whtech.com/articles/limanews/LFA7.TXT

Text File | 2006-10-19 | 18KB | 265 lines

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 -- [e-mail]
       Delphi -- GLOBAL01