10:59:42 AM EST Sunday, November 2, 1986 (Sysop .^Dave^.) Okay folks, as most of you know Acroatix has brought forth a major improvement in its operating system for the Tandy portable disk drive known as Powr-DOS; present this morning as guest is Ed Giese from Acroatix and last I looked we had some of the main users of the program that have used it to enhance the TDD. Joel, Don, and Phil are here too. (Ed G.) Good morning everyone; I just wanted to start things out with a general question to the conferees: I recently got some mail from one of the SIGGERs here who described "POWR-DOS" as a "hacker's delight" but not as the best general purpose OS. If this is true, what improvements would be necessary to make it the best? (Phil W) A couple of comments, Ed.. First --- it is a fantastic product. So I am talking improvements. In the context you mention, the biggie would be M/L utilities; the D-Menu and Dtext functions SUFFER from being implemented in Basic, as compared to the *file handling* speed of TS-DOS or even DSKMGR here on the SIG. Of course, P-DOS wins hands down in other areas. But why not put some of the demonstrated M/L programming capability there into better/faster/smaller utilities? (Ed G.) I agree with you. I would have loved to get DMENU working in assembly. However, I guess in the excitement to get the product out, We went with the BASIC version. Part of the problem was no doubt that we tend to compare things with POWR-DISK, and MENU.BA was greatly improved upon by DMENU. However, things could be faster still. Now, I may be wrong about D-TEXT, but our tests (though limited) showed it to be disk-bound. That drive is SLOW in random access. I really doubt that D-TEXT would be much faster in m/l, although it would probably be smaller. You made comments, and didn't ask questions, so this sounds like a rationalization, which I guess it is. Anyway, we may come out with a m/l DMENU now that we have the loading technique perfected. That, BTW, was the last part of POWR-DOS to be completed, and is the part I personally like the best about the product. (joel) having looked at D-Text a bit, I agree that most of the speed problem is the drive. there are file management things I'd like it to do a bit differently, but so far I'm not good enough with P-DOS to write 'em. back to the first question: I don't think the "hacker's tool" accusation is entirely fair. If all a person wants is to transfer files, then they should pick up DSKMGR and not worry about the commercial products; what P-DOS and the others offer are greatly enhanced capabilities. What they LACK (so far) are software that uses those capabilities to good advantage. (Ed G.) We had to draw the line as far as POWR-DOS utilities were concerned or we'd still be working on the thing now. I guess that with any product, there will be that tantalizing/frustrating time before there is much support for a product, when it is "just promising." Even the IBM PC went through that time, although with all the developers, it didn't take long. Here in the (relative) backwaters of the 100 & 200, it might take a bit longer for the support to come. I can only say that if P-DOS takes off, we would be the FIRST to offer commercial support/application products for it. (joel) agree. blaming us, not you (Sysop Tony) When is the 200 version going to be released, so I can have fun, too? (whimp-er) and..... Based on Sales of Powr-D, can you estimate how many 200 versions sold, vs. 100 versions???? 10%, 20%???? (Ed G.) As for the 1st question, I am still working on the conversion, although it is now pretty far along. I feel terrible that some orders have been placed for the 200 version and we are still holding them. We have to get moving, but the question leads me into a relevant point. So far, our only sales (practically) have been upgrades of our own customers. Portable 100, which hasn't appeared since JULY, has the advertising in it for new customers. What are we supposed to do? I've had to take on contracting work to survive the slump, and that of course means less effort on the conversion. It's a cold, cruel world. As for the second question, the ratio of 100 to 200 sales is about 8 to 1. (Phil W) Hasten to say that I do not think of it as a hackers tool. RECOVR by itself is enough to put this product on the applications side of the fence (and to justify the price). But, as Ed says, one always makes comparisons where they CAN be made! (RICH L) I bought the original p-d; just what are the improvements for those of us that doesn't get 100/200 mag anymore and are in the dark. (Ed G.) I might be as subjective as anyone else about what the best improvements are. You should have gotten a newsletter detailing just about everything, but it is fairly lengthy. To be super brief here, the best improvements are probably: 1. The improved loader, eliminating many conflicts. 2. The improved menu program, for those who use it. 3. The other applications, especially RECOVR. 4. The flexibility of the IPL routine, including the TINY capability. Incidentally, I wonder if I'm alone in operating my 100 much "emptier" with a DOS in place, so that the size of some applications is less of an issue. It seemed to us that the TINY solution gave us the best of both worlds, allowing access using (relatively) big files and lots of convenience for normal use. (Don Z) Question on marketing. Since there are almost no places to advertise 3rd party material in a world where you can buy 3rd party Commodore programs at K Mart. What are the restrictions that the SHack has put on their "express order" that seems to make it so difficult for items such as yours to appear there? (Ed G.) Problem #1 with express order is that you have to pay the Shack 55% off the top. Problem #2 is that most people still won't hear about the product unless the mgr tells them, and problem #3 is that they are pretty picky for all that. We tried to get POWR-DISK in the door with no luck. Hopefully the better packaging of POWR-DOS (and the higher price) will give us a better chance. We are trying already. (jim b) when using tmpc with powr-disk, super rom crlf function is owverridden by tmpc print applications e.g., fdp, ptodo, etc. does powr dos solve this conflict? what is upgrade cost from powr-disk to powr-dos? (Ed G.) As far as your first question, I may be ignorant, but does SUPER ROM solve CRLF problems in BASIC applications outside of the ROM itself? I didn't think so. If I am wrong, some one correct me, but if I am right, the real problem is that the TMPC utility programs simply use the built-in BASIC driver, which will add LF's if you put in the appropriate patch. (Don Z) That data is saved in a file called WSPEC.CW (Phil W) It is not a DOS isue, but is a property of TMPC that it seems to avoid the code which will be intercepted in high RAM by a Linefeed patch. So things like LFUTL will not add lf's to output from TMPC.CO. Utilities SHOULD be OK, tho. (Ed G.) Phil is right. TMPC, written by yours truly, was written in ignorance and bypassed the character drivers that allow line feed patches to work. However, this should not affect the BASIC utilities Jim, although WSPEC.CW contains LF information does that mean that other BASIC programs OUTSIDE of Super ROM will respect the setting it leaves? I didn't think so, but some one correct me if I'm wrong. (joel) a couple comments & a question: regarding leaving RAM emptier with easy disk access-- yes, true in the bank I use to access the disk. The other two banks seem to stay about the same, over time; but they're essentially "dedicated", anyway. I was thinking about just that issue this week; I've been working on a program and decided about half-way through that saving RAM was NOT a major concern. Second comment: Am still planning to update the review, and another of SECTR0. and the question: RECOVR doesn't recognize MultiPlan spreadsheets. Is there any easy way to fix that? (Ed G.) (!!!!? RAM not a problem on the 100 ???) (joel) well less a problem.... (Ed G.) (Boy, things HAVE changed!) As for your question, ... Could you elaborate ? "Does not recognize?" (joel) ok: What it does is tell me it CAN'T be a .CO file, since the addresses aren't "right". If I can't recover it as a .CO, I can't recover it. (Ed G.) There are two possibilities: The sector containing the first six bytes of the CO file is incorrect. (Least likely.) Or, more likely, there is a bad sector somewhere in the middle of the file. RECOVR knows from the first sector EXACTLY what the length of a CO file should be, and if the "sector series" in question does not correspond in length, it complains that the file "can't" be a CO file. Of course, the file might be damaged. There is also a (groan) small possibility that a bug in RECOVR is making it misinterpret the correct length of the CO file. I know ('cuz I tested it) that RECOVR works with CA files, which begin at 65535. Maybe multiplan files are different; I assume they were at least similar. (joel) Don't think any of those are the problem; think it's in Plan's addresses. (RICH L) ED, WHY NOT ADVERTISE ON some of the mod-100 bbs' around? get right to the people that need it, like my bbs here in Atlanta? (Ed G.) We will be pursuing that. As you may know, Acroatix is a very small company, and we have to do contracting work to survive. I guess we are the typical technology-driven types who make whiz-bang products and expect people to buy them without really knowing about them. This will change soon, as we have hired some one to help out exclusively with the marketing. Contact me independently, and I'd be more than happy to provide you with more info, and even review copies. (joel) On my BBS (in Lansing) this and virtually all new products get discussed. (Phil W) This is an answer to Ed's RAM question and a Question. To me the big advantage of P-DOS is it's invisible disk access. As Joel said, there is DSKMGR (2100 bytes) for file management in m/l. But P-DOS is neat because of where it lives and a complete lack of conflict with high RAM programs. I keep it in 5 banks (I think) and it is so invisible that I have to test to see if its there before using it!! Now the question: With P-DISK there was a MAP.DO file. Are you going to provide simillar info for P-DOS? (Ed G.) One of the problems with providing that kind of technical info about P-DOS is that There is a VERY ANNOYING restriction on any software written to work that way : It must contain NO NULLS. If a null sneaks into that area, The 100 (or 200) will start diddling with it, thinking that it is at the end of a line of BASIC code. Now, to avoid problems, we not only had to eliminate all nulls from instructions in the code, but we had to ensure that the disk I/O buffer, which (necessarily) sits down in the same area, never had nulls in it, and consequently there are some places where we had to be very careful. It didn't seem fair to give people a map without fully documenting this behavior, and there was a lack of time (and frankly, desire) to go into such detail about how our software works. However, we DID expand the MAXRAMC call list to cover just about anything that anyone would want to do as far as m/l calls to P-DOS was concerned. Does this explain things adequately? (Phil W) Yes, I think that does answer it. If I come up with any functions not covered in the call list, I'll ask about it. FAir enough? (Leonard E.) On the Multiplan problem: If Multiplan saves a file to disk it saves a BINARY *DATA* file, *not* an executable m/l file. (in spite of the .CO extension). I suspect that this was due to there only being 3 'official' extensions & .CO being closest to what is wanted. For what it's worth, here's the first six bytes of a multiplan file from a disk (DVI but since Multiplan wrote it it should do the same on TDD): 81 1 1 0 15 0 (Ed G.) First of all, you are 100% correct about why multiplan files are CO files. No other type gave the designers the (needed) ability to include nulls and ^Z's in the file. You will find IN GENERAL that the first six bytes of a CO file are: 1 & 2. The TOP address. 3 & 4. The file length (less 6, I think) 5 & 6. The EXE address. For multiplan files the EXE is always 63012 which is the access address for the option ROM. (Leonard E.) [not on disk! (Ed G.) It is a clever trick. In some other cases, perhaps a different EXE would be used. BUT ... The bytes 3 & 4 MUST MUST MUST be the length, or the M100 will very soon Coldstart. Perhaps this is one reason why coldstarts are so common. Anyway, it is these two bytes that RECOVR uses to determine the length. If they don't work, then the file cannot be safely loaded into RAM. (Leonard E.) Ed, you missed my point! What *multiplan* writes to a disk is *NOT* a .CO file! It is data in some internal format. If you try to do a LOADM or RUNM on it you *will* cold-start the machine or get an error. it is nothing but *data*. The .CO files in *rAM* are 'real' .co files. (Ed G.) I guess I did miss your point. I figured you were talking about Multiplan files from the aspect of recovering them with RECOVR.BA. Now, you cannot save Multiplan files directly to the TDD from within Multiplan using POWR-DOS. So I guess you were making some other point. But as regards RECOVR.BA, it assumes that ANY file with extension CO must contain the length (less 6) in the third and fourth bytes. It doesn't matter whether the file contains data or program, because that length is used by the M100 simply to figure out where different files start in RAM. Am I still off the mark? (Leonard E.) I was under the impression that you could write directly to the disk w.. Multiplan. (joel) a couple technical questions.... 1) Anything in SECTR0 that's WRONG? Anything I missed? Why do P-DOS and Tandy's Utilities have something at 1280 in sector 0? (Ed G.) I didn't see any errors in SECTR0, but I'll admit I didn't proof-read it. I'll take a closer look and let you know. As for byte 1280, it is not actually part of the "sector proper," but part of the 12 "marker bytes" used by the TDD OS to point to the next sector in a series. Since Sector 0 is never read as a file, it really doesn't matter what goes in the "marker" bytes for it. In general, these 12 bytes per sector are a fairly fascinating way to slip in some extra data. As you have noted, the TDD is not all that efficient in how it stores information. (joel) I'm well aware that IO and HT errors keep DSKO$ from reading a sector, and that about half of the sectors on the P-DOS disk can't be read, either. I'm not real interested in how you did that, but I want to be real sure I can't do it by accident. Comments? (Ed G.) I really don't mind telling you about how the HT errors are caused. More on why at the end. But when you format a TDD diskette, you actually have a choice of six or seven different "packet" sizes that are used whenever you do sector i/o. Tandy only used two: 64 bytes and 1280 bytes per packet. It is the 64-byte packet that is so annoyingly slow to write, and why "rename" can take up to 20 seconds, as well as DSKO$. I would use the 1280 byte packet size exclusively, except for one thing: The TDD CHANGES THE PACKET SIZE TO 64 bytes whenever you write a file to the sector using the "file" utilities in the drive! This means that you cannot maintain a different "packet" size on a disk and still use it for "normal" file I/O. This may seem confusing, but It's difficult for me to explain on the fly this way. restrictions related to disk use. The "packet" size is what they must be using to allow their random I/O, and as far as we can tell, you must select this at formatting time. If you read the obscure section in our manual about FORMAT.BA, you will see that that is one way you can set up a packet size of 1280 bytes. This makes DSKO$ much faster, but you lose the advantage as soon as you write a file to a given sector. Boy, that is a mouthful! (joel) lose it permanently? (Ed G.) (to answer your question, until you re-format.) Anyway, DSKO$ only recognizes the two packet sizes used by tandy. So, DSKO$ will not read the other packet sizes, even though the TDD can. That is how we "copy protect" the file. Using TS-RANDOM, or some appropriately home-brewed program, no doubt anyone could defeat our scheme. No matter. We GIVE the non-copy protected version away as soon as we feel confident that the customer won't return it for a refund. That was our only purpose from the beginning. It's the rare user who will be able to pick apart our scheme, and THEN try to fraudulently return the product. Feel free to ask for any clarification. This is a pretty complex subject. (joel) then nothing I'm likely to write to a sector will make it invisible? (jim b) novice user here again== !st thnxs for ur help resolving powr-disk/super/rom & TMPC conflicts ovr the phne a few weeks ago. regarding powr-doss does it provide the user with any file aging mngmnt info such as date & time last written in some file directory that can later be printed showing such file info in printed form? (Ed G.) Sorry, it doesn't. That would be a very expensive option in terms of program storage, and I don't think it could be make fool-proof. (Phil W) I have had some disks "trashed" (directory sector unreadable, but other sectors accessible with DSKO$). What causes this (NOT a P-DOS problem, I must quickly add!) (Ed G.) I'm not sure. It might be a hardware hiccup, and I think that most likely. The directory is written to disk more often than any other sector. (Phil W) You mean a ROM issue? are there any software ways to make it more or less likely? (Don Z) Ed, with your comments about 64 vs 1280 and, from the descriptions we have seen, the theory that TS Random will be using a format non-standard to Floppy and Powr-Dos in your judegement, is it possible that the future might hold the ability to store more data with the TDD, or do faster file handling, etc with non-standard formats? (Sysop .^Dave^.) [Note: Travelling will be here in CO on 23-Nov TS-Random out in 2-3 weeks.] (Ed G.) Don, my watch seems to say that the official end of the session is close. So I will try to make this into a "concluding" remark of sorts. TS-RANDOM will be constrained to the same sort of thing that P-DOS does for sector access. They may come out with a more imaginative way of using the same resources and there will always be different preferences. However, it IS possible to actually reprogram the TDD chip to use (TDD) RAM based software; in fact, that is what happens whenever you use the Tandy IPL program. A very enterprising person could figure enough out about the drive to actually bypass the TDD ROM entirely, or only use some utilities in it. Then, the sky is the limit. I'm not certain, but it may even be possible to reconfigure the drive for double density! We haven't done any more at Acroatix than discuss these possibilities, and whether we ever pursue them ourselves depends on how well our current products do. However, it is safe to say that any such ambitious program would HAVE TO BE ROM BASED, as it would take quite a bit of software to do what I'm talking about now. On that "Star Wars" note, I'll say. (Phil W) [SUPER session, Ed! Thanks!!] (Don Z) Very informative Ed, and A FUN PRODUCT!!!!!!! (Ed G.) Thanks, all of you. I really ... enjoy doing this. (Sysop .^Dave^.) Very nice timing there Ed!! Super wonderful and many thanks to all for the inputs. CO is ended but stay and chat all you want ... 1:00:42 PM EST Sunday, November 2, 1986 User ID Nod Handle ----------- --- ------------ 70465,203 POR Leonard E. 71266,125 TOR Phil W 72157,1264 NRK RICHARD WENER 72206,2776 NYJ David K. 72216,512 RPA GENE NESTRO 72227,2507 NAS Terry G. 72276,2454 WPL WAYNE S. 72407,3224 SYR Marty T 72457,3343 BOO Ed G. (Acroatix Inc.) 73007,2774 DCI STEPHEN MCGAUGHEY 73337,1204 QKE LOUIS HAMMOND 73615,1711 COL Mark H. 73765,605 NYJ larry l 74425,231 NYJ Gerald G 75715,100 ATJ RICH L 75725,1130 CVK Curtis G 75725,1134 LSM joel 75765,1124 DCQ Mike A. 75775,1430 QKE Don Z 76067,314 WPL WALTER LINDE 76267,142 QCE DICK B 76537,640 FTW lyle f 76576,3166 LBC jim b 76606,25 SCS Jay Miller 76703,4062 REN Sysop Tony 76703,446 BMD Sysop .^Dave^.