home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.whtech.com
/
ftp.whtech.com.tar
/
ftp.whtech.com
/
articles
/
limanews
/
LFT4.TXT
< prev
next >
Wrap
Text File
|
2006-10-19
|
22KB
|
343 lines
ORIGINALLY PUBLISHED IN LIMA NEWSLETTER JUNE 1993
LETTER from AUSTRALIA - No. 4 Mar / 93
---------------------------------------
Last letter it was coming up to Xmas, and now the New Year
is well and truly under way, and already it is starting to feel
like summer had never really happened. We just had a Federal
election yesterday, Saturday. US readers of course had theirs on
regular schedule last November, but Canadian readers, if any,
will understand the system here where elections occur more or
less at the convenience of the pollies. Also to confuse US
readers, the conservative party is called Liberal for historical
reasons, but was pushing policies to make Baroness Margaret
Thatcher proud, and proposing to make the medical system as like
the American model as possible. The result caught two particular
people in Australia as an immense surprize. The less surprized
of these was the previous Prime Minister who was partially
expecting to lose, and the other the Opposition Leader who
absolutely expected to win. The PM had no trouble switching to
to a winner's acceptance speech, but the other fellow just
couldn't believe the result, and was pretty reluctant to admit
defeat and positively ungracious. I had a look at the newspaper
headlines in the Sydney Sunday rags when I went down to the Minit
Mart for some milk the next morning (the more serious papers have
the same owners but come out in weekend editions on Saturday) and
here was the headline "Photo Finish" with a picture of the
Liberal leader underneath. Not quite Chicago Tribune 1948 (it
did have a two way bet quality), but it was quite obvious which
way the editors had expected the result to go. The TV networks
and all the computers had made it clear late the night before
that the current ALP government would be returned with an
increased majority. No doubt all the promises from the pollies
are inoperative now the elections are over. That seems to be a
political universal.
The Libs had imported some hired guns from George Bush's
campaigns, who came up with some very nasty TV ads, one showing a
voter in the cross-hairs of an assassin's rifle. I guess these
guys are now two time losers. How about the pollsters? Well
maybe some of them got it right within sampling error at the very
end, but at 6 pm on the TV news just as the voting closed in the
east of Australia, Gary Morgan - big cheese of the Morgan Gallup
poll - declared for a narrow Lib win. The funny thing was his
own organization's exit polls showed clearly the opposite was
going to happen. Such is the power of the running pack. It's
like thinking that just because everyone is buying 80x86 PCs,
they are computers to be enthusiastic about.
Just reading the latest BB&P article on the CYC list. Good
to see the Vincent and Gill book, 'Software Development Handbook'
mentioned. This has been over the years my main source of
background information on 9995 and 99000 details, as well as a
good reference on 9900 family assembly programming. Only part of
it is really relevant to 99/4a users, but it is a good general
text on program design. I had always wondered if it had ever
made it to the US of A, as it was a product of the UK operation
of TI. I saw it in the RadioSpares catalog years ago and ordered
a copy for the library. I gather that 9900 series processors
were widely used in England in commercial applications, more so
than in USA.
I think I may have been too kind about Myarc in recent
Letters. The 80-track ROM in my Myarc Floppy Disk Controller
(FDC hereafter) is not a genuine Myarc original but a modified
version from Richard Sierakowski in England, and works
consistently on DSQD (80-track) disks with 2 sectors per
allocation unit. Recently I had occasion to install an original
Myarc DSR 80-track ROM in the Hawks Nest machine and found that
this this did not handle sector counts correctly in DSQD,
sometimes losing track of the last sector on record by record
saves of text files.
The gremlin that inhabited one of my 192Kb HRDs finally
stuck its head up far enough to get it lopped off. This card,
though extremely neatly put together has always been strangely
unreliable on power cycling, even with the extra wire prescribed.
The other two live in the second machine which resides at Hawks
Nest, 50 miles away, while the Kotara home machine is supposed to
rely on the HRD3000b, and these have always been reliable, with
this third one as emergency backup. With all the HRD3000
problems it has had to take the leading role again, even though
DSSD is inadequate for a serious collection of utilities. It had
been behaving itself but then decided to die every time. Maybe
it was surprize at seeing William back on the TI. Nothing is
more likely to get a TI-99 consigned in anger to the back of the
deepest closet than a dodgy system boot HRD, and now both were
bad. Out with the voltmeter, and all the NiCads looked good when
checked individually --- but in circuit the one at the earthy end
appeared to have reversed voltage reading. Aha -- here was the
clue to all the troubles! The total voltage across the string of
good NiCads was fairly small. The obvious conclusion was a open
circuit between the + end of the first cell and the solder tab,
and indeed the connection in the battery holder was only a press
fit which could be rotated. So there it was, a dodgy battery
holder. Now I know what the problem is, it just does not seem so
frustrating any more. Geoff Trott down in Wollongong very kindly
checked out the HRD3000 and found that the 8K RAM chip was
causing it to hang. The design seems fairly critical in these as
several samples had been substituted before. So it worked but
now died on power cycling. The green LED turned out to be one of
the low voltage jobs so I added a series diode as per Bud's
recent change order. No joy on power cycling. With the extra
diode raising the ante, the 3v lithium battery with its reverse
protection diode now seemed too low a supply. After finding any
Li battery with solder leads, let alone a 4.5 V, impossible to
buy in Newcastle, I settled for a Varta 4 V NiCad battery as
replacement and installed it with suitable charging resistor.
Joy of joys, it worked like a charm, and I was even thinking the
time had come to install the RAMBO. Then a week or so later it
started locking up again, and the old gloom descended. At least
the small HRD is functional now. Actually my own preference for
experiments in expanded memory in the past was to use my third
small HRD, but I have never felt able to spare it for that.
The !I Gotcha!s struck here too, renaming and apparently
reformatting a drive. I was not at all amused, and singularly
unimpressed. I must say I find the comment by Gary Bowser that
"it takes the system a very long time to realize an invalid drive
number or letter was picked" difficult to understand in any
reasonable ROS code. Somehow it seems that doing some checksums
at power-up might be a better idea for user protection. The
comment is almost as strange as that published in the Nov/92
Micropendium about the RAMBO developer's package.
One thing I can attest to is that the new SCSI card should
work quite well at the lowest level when the DSR is done. It
will be at TI rather than Amiga speeds, but it works. A real
attraction of SCSI for TI owners is that SCSI devices are
transferable to or from other machines. How can I be so
confident? Well, there has been one in this very PE box,
communicating with a SCSI device over the bus (a 52 MB Quantum
drive, the preferred test device here - if any SCSI fixed hard
drive will upset a controller, a Quantum will). William has now
gone to Sydney to a job in computer graphics and special effects,
but his last task in January before moving was to get back on the
TI to write the low level SCSI driver for the card. So that was
done, with the benefit of years of experience of writing SCSI
drivers for Amiga cards, by a former master of 9900 code, and
should be a pretty solid foundation for the higher level DSR
functions being done elsewhere. As he said a week or two ago,
when overcoming difficulties getting a new SCSI device, a
magneto-optical drive, running on his big Amiga - "SCSI is easy
-- if you know how to roll your own drivers".
The review topic for this Letter will be VDP memory and
disk DSRs, triggered by a letter I received and by the public
discussion of the I Gotchas. The TI-99 was designed originally
in the days when memory cost a fortune and 8K was normal on most
smaller computers. The disk peripheral was to be usable without
the 32K expansion, and to accomodate this need the disk DSR was
designed to operate with all RAM used (except for a small block
in the scratchpad) being in VDP memory as were Basic or XB
programs in the unexpanded machine. The overall regular device
independent DSR structure of the machine has been an essential
reason for its continuing even now 10 years after its creators
set it adrift, but the downside of the original design is that we
are still living with that decision of TI's to use VDP memory for
functions that had nothing to do with video display. TI allowed
for other devices to steal VDP memory, which permitted major new
developments such as 80-column cards to function. In summary
then, as TI left it, disk DSR memory usage was as follows
(1) The DSR ROM itself in the range >4000 up to >6000 with
some addresses used for memory mapped byte wide
communication with the disk controller chip.
(2) CPU RAM in the scratchpad, >22 bytes from FAC at >834A
for communication with the DSR and scratch usage, as
specified and reserved by TI for use by any DSR. Strictly
speaking DSR writers were at this stage not even allowed to
assume PAD was at >8300, and it had to derived from the GPL
workspace location.
(3) Areas in VDP RAM used transiently by the program for
setting up Peripheral Access Blocks (PABs) and for data
buffer areas, as generally specified by TI for all DSRs.
(4) A permanent block of VDP RAM used by the DSR to hold
disk information and for stack usage. This had a
prescribed header at a VDP address stored in PAD at MAXMEM
>8370, a location to remember. Normally space was allowed
at power-up for 3 files to be open, and more space had to
be assigned for extra files, or could be removed for fewer.
The disk DSR block extended up from there towards the top
of memory, and the internal details were not officially
available for applications programmers, though they
gradually became known. TI did specify clearly in internal
documents that the TI disk DSR did not assume that the
block extended to the top of VDP at >3FFF, and that its
position always be located from the MAXMEM pointer. This
block is only a detail that went with TI's FDC, and not an
essential feature of disk DSRs.
So that was the situation on Black Friday, 1983. The first
new development was the CorComp disk controller, which apart from
that silly capture of the screen on power-up and non-standard
method of loading its disk manager, otherwise obeyed all of TI's
rules and matched TI's usage of VDP exactly. Come to think of
it, I forgot to mention this in the last Letter as an example of
a DSR that captured the machine, but we have never had one so it
did not come to mind. A later update eliminated the annoying
initial screen, and should be the one used in 80-column systems.
Most if not all programs of this era which attempted low level
access to disk details assumed absolute addresses in the VDP
block (TI internal documents emphasizing use of MAXMEM had not
leaked outside a tight and secretive circle at this time).
Next came the Myarc FDC, first and only ever seen here as a
PE box card. This card was very different from the TI/CorComp in
its memory use. The DSR ROM was bankswitched in two 4 Kb blocks
at >4000 and had an internal 2 Kb RAM at >5000. It used more of
PAD on a temporary basis, otherwise its software intensive design
with minimal hardware assists would never have been able to
handle DD tracks (DD raw track reads are still dodgy at best but
are not routinely used, and it also has various file level bugs
and disk sector allocation incompatibilities). The real change
was the use of the internal RAM for all disk buffering instead of
upper VDP, and also a convention for programs to signal use of
CPU RAM for data buffer areas. The DSR initialized VDP RAM in
mimicry of TI cards but then ignored it. The designers chose to
emulate the TI DSR in restricting the number of open files
according to CALL FILES(x) setting of the VDP pointer, instead of
always using the number available in the DSR RAM. The later HFDC
seems to have followed the same general outline. This approach
of faking handling of VDP was unnecessary and in retrospect a
very unwise decision that gave users less performance than they
could have had. Myarc users could have had cassette length Basic
programs from disk all along.
It is clear then that the Myarc FDC had no business in VDP
supporting CALL FILES(x) in the first place, as the function was
specific to TI/CorComp disk DSR usage of VDP, and it was only
ever a command line function in Basic or XB. Various TI programs
such as the Formatter and Assembler did manipulate VDP memory
allocation, but only to let an assumed TI FDC have adequate open
files. The correct behavior for an FDC or emulation is to
support the >16 VDP file allocation subprogram as defined for TI
FDCs only if the DSR uses VDP in TI-style, and for programs which
call it to clear the error byte at >8350 first, and only flag an
error if the error byte is set, whether or not the subprogram is
found. What is also crystal clear in retrospect, though obscured
at the time, was that as soon as the Myarc FDC card appeared, any
programming technique that assumed use of upper VDP by disk DSRs,
let alone intimate details of that area, was no longer generally
valid. Funnelweb's boot tracking code after that time still
looked in VDP for TI/CorComp data but also checked for the Myarc
FDC, and if found assumed specific details in the Myarc internal
RAM. The Funnelweb system always gave the user the option to
turn off this search altogether. Long after this commercial
programs were still being issued that would not run on Myarc FDCs
because they rigidly assumed TI/CorComp VDP usage details.
The next big step was the first of the continuing family of
Horizon RAMdisks. The Johnson/Ballman Miami ROSs for these cards
remained externally similar to the TI original (except that they
improperly ignored MAXMEM) and shared use of the VDP area with
the FDC, and observed the CALL FILES(x) limit. Again in
hindsight this was an unnecessary and performance limiting design
decision. When 80-column cards came along the last (Vn 7.3) of
these ROSs had to be patched to respect MAXMEM, but the public
availability of source code made this running correction
possible. The HRDs by their nature contained RAM, and all
sectors on the simulated disks already were accessible at CPU RAM
speed and so did not need to be buffered from slow physical disks
to RAM for reasons of speed. The later OPA Vn 8.1x ROSs have
embodied this understanding. The HV99 Quest RD, though
internally very different, uses a ROS like 7.3 to this day, and
provides the test in my Myarc FDC based system of correct
function for TI/CorComp. Funnelweb's internal Files(x)
equivalent routine became more complex to allow for possible
pushdown of MAXMEM by unknown small amount with arbitrary number
of files set. It has to reserve VDP just in case it is needed by
a TI tyoe disk DSR so that all FDCs are handled transparently.
Life would be very much simpler all around if all disk DSRs were
like the Myarc model without the unnecessary CALL FILES.
Why are programmers interested in the leavings of disk DSRs
anyway? The reason is that most substantial program packages need
to load subsidiary files automatically from their original disk,
and the TI operating system made no direct provision for
returning information on which drive this disk was in. Within
the package it is under control, but it is that first load by the
OS or another program that is the difficulty. An elegant but
partial solution to this problem was given by Bruce Harrison
recently. It relies on the prior use of standard form DSRLNK
routines to load the main program initially, that store
intermediate pointers in known PAD locations, and backtracks into
the DSR devicename list to find the last one used. Given the
pointers, this is a properly device independent method. I always
knew there had to be a reason why nonstandard DSRLNKs never
appealed. Funnelweb now uses Bruce's method in FW and LOAD, with
the usual override provision. You can't always work in the
simple-minded way of looking for "n" in the name "DSKn." so
expected. Files loaded through a disk volume name or hard drive
path do not fit this model in the final detail, which is why
Funnelweb still needs alternative support for configuring in
pathname access. Also direct DSR program level access (MENU, FW,
LOAD or whatever) as supported by Horizon style DSRs fails to
satisfy the necessary conditions. The solution here is for the
DSR writer to arrange that the DSR ROM pointer in PAD is left at
the drive name entry "DSKn." on which the program called directly
by name was stored, just as if it had been loaded normally. The
CRU pointer should already be correct.
This brings us to the latest letter from OPA as attached to
the March BB&P. In the light of the above discussion, a well
written DSR for HRDs has no business with VDP at all, except to
look at PABs and read or write data if so instructed. Since the
function of the HRD is to be indistinguishable from physical
drives, application programs must treat all alike. This means
that if the Files(x) function is needed to cover TI type FDCs,
the program should provide its own universal routine to cover all
possibilities, or else handle the >16 subprogram correctly as
covered above. Calling the physical FDC's VDP allocation routine
(subprogram >16) may not be adequate for the worst case of a 7.3
style ROS using VDP, combined with an FDC that ignores VDP and
this subprogram. The OPA letter seems to be an implicit
admission that ROS 8.14 still has misconceived and bad code in
this area. Pity, because it does so many other things so well.
There is this legacy of programs which make obsolete and now
clearly illegitimate VDP references, at absolute addresses in
worst case. I believe the best way to handle such problems is to
do the DSR correctly in the first place, and provide special
options to handle ill-behaved programs, callable when needed
(like the AVPC's TI-Mode). It is sometimes possible to cover up
for bad applications by cunning code called transparently. If
Gary Bowser is unwilling or unable to update ROS 8.14 to fix its
sins of comission (VDP reference or interference, I Gotchas) or
omission (no 800K DSQD equivalent drives in big HRDs) then Bud
should hand it over to someone who will, as a solid DSR is an
essential part of the HRD, and leave OPA to supply alternative
third party products, all of them no doubt wonderful.
That had better be all for now folks, or it will soon be
Text Buffer Full.
Tony McGovern
Funnelweb Farm
Mar / 14 / 93
.PL 1