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