FORTINP@BNR.CA (Pierre Fortin, P.) (02/01/89)
Until recently, I was running my SH204 hard drive (Seagate 225) on
my Mega-2 with a second 10-meg drive (Miniscribe 3012). This is a
TWO drive to ONE controller configuration which Atari's AHDI.PRG
never supported, so I also booted with Supra's SUPBTHP.PRG in my
AUTO folder. This combination worked great with no problems.
After filling the original 20-Meg and the 10-Meg was creeping up,
I decided to spend some $ and bought a 40-Meg Miniscribe 3650.
At the same time, I got my hands on the "latest" Atari AHDI.PRG
(HDX20.ARC on some boards). I figured I had best get this S/W
upgrade done before the H/W one. Many floppies later, it was time
to re-format the original 20-Meg drive.... done.... put some files
back up... WOW!!!! writing to HD is MUCH faster!!! Now to tackle
the H/W upgrade.
This should be easy (I thought, naively)...
W-w-elllll!!! After much messing around, I finally got this 40-Megger
formatted, but only after removing SUPBTHP.PRG *AND* installing the
40-Meg as Unit 0 (no other drive connected).
Great! Now to put the H/W back the way it was and I should be back in
business... (Unit 0: 20-Meg partitioned 4-6-10; Unit 1: 40-Meg 15-15-10)
Put the SUPBTHP.PRG back in AUTO,... let 'er rip... YEAHHHHH!!!!
Upload... upload... 3-Megs (Unit 1) later, I decided to "use" the system
normally as before. Hmmm! strange! better reboot...
Some strange activities noted (random and intermittent):
(Averaged 3-5 minutes between re-boots)
- system reads HD (Unit 1) directory, displays it, FOREVER (in a loop)
- system locks up
- open several windows, hey! this Unit 1 directory belongs to another
logical drive, close window, open others, try again, it's OK this
time...(????)
- wrote something to Unit 1 again... strange!.. directory shows only
one folder which can't be opened but path looks like this:
"G:\MWC\MWC\MWC\..." Checked it with DLII: 3101 LOST CLUSTERS!!!
and entire directory on this partition is GONE!
Obviously something is severely brain damaged. OK, don't use Unit 1
and everything is fine... !?
So far I am 99.44% certain that the new AHDI.PRG and SUPBTHP.PRG are
definitely ***NOT*** compatible.
Questions:
1. Is any one else running this type of config?
2. If so, have you had to get a new SUPBTHP.PRG? Is there a new one?
3. If a new SUPBTHP.PRG exists, where can I find it?
Comments:
Atari ASSumes that since they only make one type of drive (ONE drive
per ONE controller) that they only need to code the AHDI.PRG with
the Unit number ALWAYS=0! I have nearly finished disassembling
AHDI.PRG (fully commented) and am not able find any code supporting
multi-unit "drives" yet. So **WHY**, Atari, did you document multi-unit
controllers in the technical data section of the manual????
Some of the AHDI.PRG ("apratt" is in the header) uses many "well it's
already on the stack" code sections. A puzzling one is where there
appears to be about twelve items stacked, but only six removed..!?
If I manage to modify this program to support multi-drive controllers,
can I post it? or should I send it to Mr. Pratt? I don't want to
do anything illegal, but I don't know the legalities of reverse
engineering and enhancing a product. I am fairly certain that the
patent laws allow someone to patent a "better" product which already
exists: is this a similar situation?
Phewww!!! I could write a lot more, but this is already plenty...
Thanks for reading this far...
Pierre Fortin
FORTINP@BNR.CA I think! We are connected to NETNORTH which is
Ottawa, Ontario connected to BITNET which is
Canada connected to ... (I never could sing!)rona@hpdml93.HP.COM (Ron Abramson) (02/04/89)
Pierre Fortin, P. writes: >Until recently, I was running my SH204 hard drive (Seagate 225) on >my Mega-2 with a second 10-meg drive (Miniscribe 3012). This is a >TWO drive to ONE controller configuration which Atari's AHDI.PRG >never supported, so I also booted with Supra's SUPBTHP.PRG in my >AUTO folder. This combination worked great with no problems. >After filling the original 20-Meg and the 10-Meg was creeping up, >I decided to spend some $ and bought a 40-Meg Miniscribe 3650. >At the same time, I got my hands on the "latest" Atari AHDI.PRG >(HDX20.ARC on some boards). I figured I had best get this S/W >upgrade done before the H/W one. Many floppies later, it was time >to re-format the original 20-Meg drive.... done.... put some files >back up... WOW!!!! writing to HD is MUCH faster!!! Now to tackle >the H/W upgrade. [Stuff Deleted...] >Some strange activities noted (random and intermittent): [More Stuff Deleted...] >Obviously something is severely brain damaged. OK, don't use Unit 1 >and everything is fine... !? >So far I am 99.44% certain that the new AHDI.PRG and SUPBTHP.PRG are >definitely ***NOT*** compatible. [ETC...] Based on the information posted, this conclusion seems premature to me. You made both a hardware AND a software changed and after finding problems, you make the assumption that Atari's software is 99.44% likely to be at fault. This doesn't seem very fair to Mr. Pratt & Co. I suggest that you remove the 40 meg drive and put the 10 meg in its place and test the set-up as best as you can. If this set-up works fine, your problem might not be software related at all. You might also want to try setting the 40 meg as unit 0 and the 20 meg as unit 1 and see if the problem stays on unit 1 or with the 40 meg. Finally, you could try going back to your old software and see if your new hardware works properly. Don't get me wrong, you may have identified the problem accurately. I'm just suggesting that you try some tests to confirm your theory. Maybe your intent was not to blame Atari, but that's how it sounded to me. Good Luck, Ron Abramson P.S. These opinions are my own!
FORTINP@BNR.CA (Pierre Fortin, P.) (02/22/89)
A while back I wrote about problems adding a second HD unit to my SH204... On Feb 3, (I never saw the original response; it arrived tonight in one of over a dozen digests) Ron Abramson responded: > > Pierre Fortin, P. writes: >>Until recently, I was running my SH204 hard drive (Seagate 225) on >>my Mega-2 with a second 10-meg drive (Miniscribe 3012). This is a >>TWO drive to ONE controller configuration which Atari's AHDI.PRG >>never supported, so I also booted with Supra's SUPBTHP.PRG in my >>AUTO folder. This combination worked great with no problems. > >>After filling the original 20-Meg and the 10-Meg was creeping up, >>I decided to spend some $ and bought a 40-Meg Miniscribe 3650. > >>At the same time, I got my hands on the "latest" Atari AHDI.PRG >>(HDX20.ARC on some boards). I figured I had best get this S/W >>upgrade done before the H/W one. Many floppies later, it was time >>to re-format the original 20-Meg drive.... done.... put some files >>back up... WOW!!!! writing to HD is MUCH faster!!! Now to tackle >>the H/W upgrade. >[Stuff Deleted...] > >>Some strange activities noted (random and intermittent): >[More Stuff Deleted...] > >>Obviously something is severely brain damaged. OK, don't use Unit 1 >>and everything is fine... !? > >>So far I am 99.44% certain that the new AHDI.PRG and SUPBTHP.PRG are >>definitely ***NOT*** compatible. >[ETC...] > >Based on the information posted, this conclusion seems premature to me. >You made both a hardware AND a software changed and after finding >problems, you make the assumption that Atari's software is 99.44% likely >to be at fault. This doesn't seem very fair to Mr. Pratt & Co. Ron, I said the TWO are "not compatible" versus "at fault". Anyway, since the original posting, I have had both e-mail and voice discussions with Vance Chin of Beckemeyer Microsystems (***** MANY thanks Vance!!! *****). I was correct in my statement, but for the WRONG reasons: one must use EITHER Atari's AHDI.PRG on drives formatted with THEIR formatter program, *OR* Supra's driver/formatter pair, *BUT NEVER BOTH*. I originally thought that Supra's SUPBTHP.PRG co-existed with AHDI.PRG: Boy! Was I wrong! Don't get me wrong, I *LOVE* my Mega2; my son has an IBM clone just 4 feet away from my Mega, but I have only touched its keyboard 2-3 times in over a year, and then just to help with problems. >I suggest that you remove the 40 meg drive and put the 10 meg in its >place and test the set-up as best as you can. If this set-up works >fine, your problem might not be software related at all. While your suggestion is valid, in this case it would have led to the wrong conclusions. You see, this turned out to be another multiple problem (seems like the only kind of problems I ever get, but that's another story). The 10Meg drive has NO hard errors on it, while the new Miniscribe 3650 has errors at (head/cyl/byte) 1/112/3351, 1/287/418, 4/736/2505, 5/789/1223 and 5/790/1223. Based on Vance's comments, the Atari host adapter card's PAL chip (the only socketed one) has a problem whereby drive errors are not reported back to the system. This is supposedly corrected by Beckemeyer Microsystems' ADE chip. I can't report on this yet, as I am still waiting for the chip to arrive from CA. On the software side, one must only use *one* driver/formatter pair. However, I still cannot reliably use the 2nd drive in either location. As far as Atari (including Mr Pratt) are concerned, I think the net has said more than I *ever* Would about their lack of support. Granted, Mr Pratt often replies to net queries, but as one who has spent money for the developper's kit, I wish that some of this good support was better channeled within Atari to get TOS 1.4 on the street ASAP. Personally, it sounds to me (based on many months of reading the net) that all bugs should be out of 1.4 by now, and any efforts trying to keep those ALL those OLD programs runnable are in the "ever-diminishing returns" category. Priority number 2 would be to support the developpers properly: currently, Atari seems to be suffering from the NIH syndrome (not invented here). Only those companies which are prepared to accept that they cannot be the sole supplier (Oh yes, I was one of those who bought one of the very first 4K Level-1 TRS-80 systems) will succeed. Mr Pratt & Atari: take a chance, byte ;~) the bullet, whatever; many of us don't care about older programs anymore, sell us the new 1.4 ROMs now. Those of us who would like to develop on the Atari ST line need something to sink our teeth into which is a little more tangible than the 8/8/88 disk version. If a great new program comes with a comment like "Requires TOS 1.4 or newer" and I don't/won't spend the money to get either, then my Mega2 might just as well be sitting next to the TRS-80 collecting dust. ***** Please, ALL of this is intended in the most POSITIVE of ways***** >You might also want to try setting the 40 meg as unit 0 and the >20 meg as unit 1 and see if the problem stays on unit 1 or with the 40 >meg. Finally, you could try going back to your old software and see if >your new hardware works properly. > >Don't get me wrong, you may have identified the problem accurately. I'm >just suggesting that you try some tests to confirm your theory. See the above... Also, I don't know if its the same for everyone else, but the digests only come to me in batches of about 10-15 every few weeks. Your input is valuable to me: I may already have tried most things people suggest, but unlike... I like to think I don't have the NIH disease ;~) >Maybe your intent was not to blame Atari, but that's how it sounded to >me. In respect to documenting (in a USER publication no less) the multi-unit multi-controller protocol, then only implementing a ONE-unit per controller AHDI.PRG... I would prefer to say "shame Atari". >Good Luck, >Ron Abramson I thank you very much. Again, I am a great fan of the Atari ST line, but except for the first few months of excitement, I no longer give any references (good or bad) regarding these systems. >P.S. These opinions are my own! Ditto. Pierre Fortin FORTINP@BNR.CA [my] P.S. Having read the net for quite some time, I know in my heart that many might want to jump in with comments. Please, comment if you wish, but provide some good information with your comments as Ron and I are doing; don't comment just for the sake of commenting (these are the least impressive/memorable types of mailings).
hcj@lzaz.ATT.COM (HC Johnson) (02/23/89)
In article <8902220706.AA01969@ucbvax.Berkeley.EDU>, FORTINP@BNR.CA (Pierre Fortin, P.) writes: > A while back I wrote about problems adding a second HD unit to my > SH204... > There is a great deal of chatter here dealing with misconceptions on hard disk interface. I will address here only the first four partitions on a hard drive. I know that the Supra software adds 8 more, but its not relevant to this discussion. 1. the Atari, Supra, and many ICD interfaces use the Adaptec 4000A scsi to st506 adaptor. (Atari builds their own under license.). 2. There is only ONE way to format the sectors on the disk. The 4000A is given ONE command (and an optional bad sector list) and it does the whole thing. There is no way for this to differ. 3. There is only ONE way to create GEM partitions on the disk. ATARI's way. If not, TOS wouldn't be able to read/write files. 4. GEM and non-GEM partitions are ONLY a way of allocating raw sectors on the disk. Each partition describes is starting sector and size in the partition table found in sector 0 of the hard disk. THIS IS NOT SECTOR 0 of C: . 5. Each venders version of ahdi.c does the same thing. It looks for connected disks, reads the partition table, and if the partitions name is GEM creates a logical disk. Otherwise it ignores the partition. OK, so why is there a problem? Sometimes its hard to tell if a drive is connected. 6. A. ATARI corp, designed the sh204 to have ONE DRIVE on ONE controller. THUS the ATARI ahdi.prg, does NOT TEST for a second drive, even tho you can format it. B. Unfortunately, there is a nasty bug in the PLA of the SH204 that prevents it from reporting errors from the 4000A. This is not a big deal for failed reads or writes, as the 4000A has tried and retried; the sector is bad and it will not likely be better. BUT, when BMS/ICD/SUPRA start polling for connected drives, they don't get the error when drive 1 is missing, and screw up when they think its there and doesn't work. ATARI ahdi doesn't have the problem as it never asks about drive 1 on a controller. 7. When a drive is added as drive 1 on a SH204, it is necessary to get someone elses driver, as ahdi will not ask if the drive is there. AND, most of the other drivers poll for drive 1 and sometimes 2-7 also, screwing up when the SH204 with 1 drive reports the other ones are present also. WHAT to do. 8. One way, is fix the SH204. That is what the Berkeley Micro Systems PLA does. Another, is to patch the supra/icd/bms driver to only ask about drives that you have connected. (BMS gave me a patch early on when we didn't know what the SH204 was doing to us). Another, is disassemble the driver, and change it. I've done this now for my system. Summary: a. Really, all the formatters are equivalent for base formatting and creating GEM partitions. b. all the hard disk drivers are interchangeable IF you realize what added features are in each one. This sounds strange, but it means that they should all run 1 drive per controller, and the sh204 with the pla change. c. ATARI isn't too excited about retro fitting the sh204, In fact they dont even believe its a problem. And for them, it isn't. Howard C. Johnson ATT Bell Labs att!lzaz!hcj hcj@lzaz.att.com
decouty@irisa.UUCP (Bertrand Decouty) (02/23/89)
In article <423@lzaz.ATT.COM> hcj@lzaz.ATT.COM (HC Johnson) writes: |In article <8902220706.AA01969@ucbvax.Berkeley.EDU>, FORTINP@BNR.CA (Pierre Fortin, P.) writes: |> A while back I wrote about problems adding a second HD unit to my |> SH204... |> | [....] | B. Unfortunately, there is a nasty bug in the PLA of the SH204 that | prevents it from reporting errors from the 4000A. This is Is this buggy PLA still here in Megafile30/60 hard disks? Is it possible to add a 2nd unit to a megafile disk? BTW, hdx2.0 (given with megafile disk), is really different from sh204 version because Magic Sac 5.5 does not see a hard disk formatted with hdx2.0 (but magichd sees it). ----- Bertrand DECOUTY @ INRIA-IRISA (Centre de Rennes) ----- +------------------------------+----------------------------------------------+ | IRISA - INRIA | EMAIL : decouty@irisa.fr | | Campus de Beaulieu | | | F-35042 Rennes Cedex | UUCP : {uunet,mcvax,inria}!irisa!decouty | | FRANCE | decouty@irisa.UUCP | +--------------------------+---+--------------------+-------------------------+ | PHONE : +33 99 36 20 00 | TELEX : 950473 UNIRISA | FAX : +33 99 38 38 32 | +--------------------------+------------------------+-------------------------+
meulenbr@cstw01.UUCP (Frans Meulenbroeks) (02/23/89)
A source within atari told me that 1.4 will not hit the market before summer. Major reason is that internally it has been decided to make 1.4 really robust, while initially it would not fix all known defects. This is what I am being told. flames to /dev/null [side note: forget about 1.4; move to minix] -- Frans Meulenbroeks (meulenbr@cst.prl.philips.nl) Centre for Software Technology ( or try: ...!mcvax!philmds!prle!cst!meulenbr)
meulenbr@cstw01.prl.philips.nl (Frans Meulenbroeks) (07/21/89)
Hi! I'm having trouble with my new hard disk. The disk is a Micropolis 1355 disk with an ESDI interface, which is connected to my ST by means of a BMS 200 board and an Adaptec 4520 SCSI <-> ESDI adaptor. The trouble is that sometimes formatting results in errors or in a lot of bad blocks. Also when used data is not always read properly. The drive often makes a grinding sound just like the floppy does when it is not formatted properly. It looks like it is retrying. Often it succeeds on the second try. All this is rather inconsistent. The blocks that are reported bad differ from one day to another. Does someone have an idea whether this is most likely due to the Adaptec controller, the drive, or the power supply? Any suggestion is welcome. I'm getting quite desperate on this. PS: Sometimes the supra formatter comes up with the error message "Invalid cartridge" when formatting the drive. On other occasions it will do the job. ICD sometimes gives error code 112. On other occasions it will hang making this grinding noise. hdx3.0 refuses to format the thing (check cabling). Thanks in advance, Frans Meulenbroeks (meulenbr@cst.prl.philips.nl) Centre for Software Technology ( or try: ...!mcvax!phigate!prle!cst!meulenbr)
domen@cartan.crin.fr (Eric Domenjoud) (03/07/90)
Some days ago, my hard disk got completely corrupted: I first noticed that some files were mixed on the disk and looking at the FATS and the root directory, I saw that a prt of file was written in the root directory and some clusters were allocated to more than one file. It's actually the third time it happens but I never exactly identified the problem before. I have then two questions: 1/ Does somebody else already had such a problem? 2/ could the Universal Item Selector be responsible for this? The Universal Item Selector is indeed the only program that were in use every time this problem occured, and the first time, it occured immediately after I tried to copy a file with the Item Selector. Eric
hcj@lzsc.ATT.COM (HC Johnson) (03/09/90)
In article <1777@loria.crin.fr>, domen@cartan.crin.fr (Eric Domenjoud) writes: > Some days ago, my hard disk got completely corrupted: I first noticed > that some files were mixed on the disk and looking at the FATS and the root > directory, I saw that a prt of file was written in the root directory and > some clusters were allocated to more than one file. It's actually the third > time it happens but I never exactly identified the problem before. I have > then two questions: Well, something is failing. First choice is that the disk read wrong, and did not report the error. If you have a standard SH204, this is true. There is a PLA fix from Berkeley Microsystems (USA) for this. Second choice on the hard disk is that it read wrong, but the checksum was OK. Not all that likely, but just as fatal. Third choice is an unfortunate memory failure. This may be detectable with a memory check program; but the ultimate test of memory is using it. Least likely is the file selector. It really cannot direct disk data to random locations. Howard C. Johnson ATT Bell Labs att!lzsc!hcj hcj@lzsc.att.com
domen@cartan.crin.fr (Eric Domenjoud) (03/12/90)
Some days ago, my hard disk got completely corrupted: I first noticed that some files were mixed on the disk and looking at the FATS and the root directory, I saw that a file was partly written in the root directory and some clusters were allocated to more than one file. It's actually the fourth time it happens but I never exactly identified the problem before. I noticed that the first data cluster on the disk corresponds to the third entry in the FATS, that's to say, is numbered 2 since the first one is numbered 0. This means that the data clusters 0 and 1 are actually never used and thus marked as free in the FATS (at least on my disk which is not an ATARI disk) and that they are actually located in the root directory, exactly where a part of my files were written. My questions are then: 1) Did anybody already experience this problem? 2) Are the data clusters 0 and 1 marked as free ($0000) on the ATARI disks? 2) Is it posible that a poorly behaved program allocates these two non existing data clusters, thinking that they are free? This problem occured first while copying a file with the Universal Item Selector and then almost systematicaly with Turbo C. My disk is a 30MB with OMTI controler bought at FSE in Kaiserslautern (W. Germany). Eric Domenjoud e-mail: domen@loria.crin.fr
ac365@cleveland.Freenet.Edu (Todd Donovan) (12/12/90)
I have an Atari Mega 4ST with a Syquest 44 megabyte removable hard drive
running with an ICD host adapter and system software. My original system
used an Atari Megafile 30 HD and everything worked fine. Then I added
the SyQuest44 as a second HD and problems started. I switched the Syquest
to DMA 0 and removed the Megafile 30 thinking that the computer was
having trouble managing two hard drives. This helped, but it didn't
really. I then removed the special features provided like read/write
caching and write verifies. Reliability improved tremendously. I was no
longer getting persistent write fails, missing files, and accidental
deletes.
My current problems include files getting mistakenly trashed. That is, a
file which I never saved onto is getting truncated and corrupted. It is
like the disk table isn't being done correctly and the computer uses the
same sector twice. Also, sometimes two quite dissimilar files become
merged. I have my biggest problems with large files. Maybe its just the
law of averages which allow larger files to be corrupted easier. For
example animations are prime candidates; however, there isn't always a
rhyme or reason to the corruption.
Also, sometimes when the hard drive should not be called for, the head
engages (I can hear it) and the red light comes on for a couple of
seconds. Then everything returns to normal. The computer's operation
isn't affected at all during this "blip".
What can be done to stop these problems?
Thanx in advance!
--
/| Todd Donovan: ac365@cleveland.freenet.edu
/ | President and General Manager
/__| Channel 4 WCFT-Television Chagrin Falls
| =======================================================================ekrimen@ecst.csuchico.edu (Ed Krimen) (12/12/90)
I left you a message on Freenet, in the same area you left yours, regarding
your hard drive problems. Did you see it? Len Stys saw it.
--
Ed Krimen ...............................................
||| Video Production Major, California State University, Chico
||| INTERNET: ekrimen@ecst.csuchico.edu FREENET: al661
/ | \ SysOp, Fuji BBS: 916-894-1261 FIDONET: 1:119/4.0