ftp.whtech.com/ftp.whtech.com.tar/ftp.whtech.com/articles/archives/limanews.exe/LFT4.TXT

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