med@druhi.ATT.COM (Myron Drapal) (08/30/88)
First off, this is a followup to a posting I made yesterday regarding
the incompatible PC format from the new BETA ROMs. Allan Pratt claims
that this is fixed in the new BETA ROMs, and indeed it is -- that is if
you never want to store a file on it!!!
After a little bit of investigating, and some real insightful help from
Dan Moore (thanks, Dan), it seems that the double sided format is almost
compatible, except that a standard PC formatted disk has 3 sectors per
FAT, and the ST formats them with a standard(?) 5 sectors per FAT. Since
most (all) MS-DOS systems simply check the format ID (in this case, 0xF9)
to get its information, and ignores most if not all of the rest of the
boot sector information, the PC thinks that the root directory starts
somewhere in the middle of the second FAT on this disk!!! So, CHKDSK
is very happy with this disk, until you put a file on it on the ST, at
which time it complains that there are lost clusters on the disk (since
the first FAT shows them in their proper place, but they aren't in the
root directory).
Well, after all of this, I am really wondering how much BETA testing(??)
that these ROMs have gone through. You see, I really don't even have a
set of these ROMS, and have managed to find what I consider a major bug.
Are these ROMs even being tested, or are we all in line for another
MEGA ROM snafu??? (you all remember that one, don't you - everything
broke including the kitchen sink ;-{ ). I sure hope that we aren't in for
the same thing again - Atari will never be able to live through such
a mess again, at least not in the computer market.
Myron Drapal
AT&T Denver
att!druhi!medgood@atari.UUCP (Roy Good) (09/01/88)
in article <3461@druhi.ATT.COM>, med@druhi.ATT.COM (Myron Drapal) says: > > First off, this is a followup to a posting I made yesterday regarding > the incompatible PC format from the new BETA ROMs. Allan Pratt claims > that this is fixed in the new BETA ROMs, and indeed it is -- that is if > you never want to store a file on it!!! > > > Well, after all of this, I am really wondering how much BETA testing(??) > that these ROMs have gone through. You see, I really don't even have a > set of these ROMS, and have managed to find what I consider a major bug. > > Myron Drapal > AT&T Denver > att!druhi!med Dear Mr. Drapal (and fellow net readers), Since you are so insistent with your desire to post comments on the performance of a set of ROMs which you do not have, which is somewhat akin to publishing a road test report on a Testarossa you have never driven, might I ask you to make one final posting? Please post the name and contact address of the person or company from you which you obtained either: the unauthorized copy of the ROMs the unauthorized copy of the RAM version ('tho you say "ROMs") the source of the report which you are publishing, if it is not you Also, please post the identification code of the TOS version. I'm taking a risk - you may have got it through Atari even! But I think you owe it to Atari and to the more responsible subscribers to this news category to be less secretive. For all I know, you may have a bootleg copy of a development-in-progress version. Incidentally, all Atari subsidiaries received copies of the Beta kit, and have since received copies of the Developer Kit. There will be further improvements and, yes, some bug fixes, prior to comitting to ROMs. If each subsidiary has just 5 external sites (and I believe that is the minimum anywhere), there are at least 70 testers. And we have received some quite obscure bug reports from them, and we thank them for their support. This last word should be in 28 point bold underlined type, as it encapsules the spirit of Beta test - the desire of the test site to support the supplier in the aim of producing a quality final product. ----------------------------------------------------------------------------- Roy J. Good Product Development, Atari Corporation Views expressed are my own. Atari may agree or disagree; they have the right. -----------------------------------------------------------------------------
apratt@atari.UUCP (Allan Pratt) (09/02/88)
In article <3461@druhi.ATT.COM> med@druhi.ATT.COM (Myron Drapal) writes: > [...] Allan Pratt claims > that this is fixed in the new BETA ROMs, [...] Since you reveal that you have read either my mail or my posting, you can't claim that you didn't see the (rather restrained I thought) request that you stop posting comments about unreleased Atari products to the net. I withdraw my recommendation that you not be sued. This is really unforgivable behavior, and you have demonstrated (over and over) why we have to be very careful in selecting Beta test sites. Apparently we were not careful enough, because either someone talks with you about the ROMs, or someone allowed you to copy them. Be that as it may, I can find no explanation for your continued bad manners, but bad manners should never be allowed to go unpunished. PLEASE STOP POSTING TO THE NET. PLEASE STOP POSTING TO THE NET. This is not an attempt to "hush up" deficiencies in the new TOS which you obviously consider important. THIS IS AN ATTEMPT TO SHUT YOU UP BECAUSE YOU DON'T KNOW WHAT YOU ARE TALKING ABOUT, to wit: [MEDIA DESCRIPTOR BYTE] "DOS internal routines use information in the BIOS parameter block (BPB) to determine the media type of IBM formatted disks rather than using these values. THESE MEDIA DESCRIPTOR BYTES CAN NO LONGER BE GUARANTEED TO INDICATE A UNIQUE MEDIA TYPE." [Emphasis mine.] [GETBPB] "The device driver checks the boot sector. If the boot sector is for DOS 2.00 to 3.30, the BPB from the boot sector is returned." -- pages 2-27 and 2-30, IBM PC-DOS 3.30 Technical Reference We never promised DOS 1.x compatibility. The information in the boot sector includes, among other information, the number of sectors of FAT on the disk. The media descriptor never defined that, except in some nebulous way which IBM/Microsoft never documented. I am tired of discrediting you publicly. If you must report these things, please MAIL to atari!pts and request feedback. We will endeavor to reply, in loving detail, why what you're reporting is not a bug, or, God forbid, that it is. And we will thank you for the time you spent investigating on your own, to be sure it wasn't just a misunderstanding on your part. I hope that the rest of the net is as tired of this as I am, and will never take you seriously. That will save me (and Mr. Good) the trouble of discrediting you still another time. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
Thomas_E_Zerucha@cup.portal.com (09/02/88)
"... But the PC only checks the media descriptor byte and if it is F9 then it assumes that it is a standard PC disk with 3 sectored FATs..." I wrote a utility and put F8 for the media descriptor byte (normally only for Hard Disks), and mine work fine. There are all kinds of bytes in the boot sector which will theoretically tell the PC *exactly* how many bytes and sectors and tracks are on the disk and used for each part (number and size of FAT's, etc.). I think the BIOS on my PC may be a little smarter as well. I even had 800K (10 sector) disks work fine on my PC. If your disk driver isn't reading these bytes to determine how many sectors per FAT, don't blame Atari, blame the writer of your BIOS for not following their own rules and reading the number of sectors per FAT directly from the boot sector. But while I am at it, does the BIOS now support any sector size other than 512 bytes? Any other cluster size besides 2 sectors/cluster? All the other stuff in the Bios Parameter Block and Boot sector that are supposed to set up all these values?
apratt@atari.UUCP (Allan Pratt) (09/03/88)
In article <8662@cup.portal.com> Thomas_E_Zerucha@cup.portal.com writes: > [Media byte, etc.] > > But while I am at it, does the BIOS now support any sector size other than > 512 bytes? Any other cluster size besides 2 sectors/cluster? All the other > stuff in the Bios Parameter Block and Boot sector that are supposed to set > up all these values? Thank you for backing me up on the Media Descriptor versus the longhand information in the boot sector. We could have used the media descriptor byte F8, forcing the PC driver to look at the boot-sector information, but those same dumb BIOSes would make the faulty assumption that the media was nonremovable. IBM realized the limitations of the media descriptor byte as shorthand for the rest of the boot-sector information, and, at least in DOS 3.3, they rescinded it. Perhaps they did sooner than that; I can't lay my hands on a DOS 2.x tech ref manual. A driver can be written to support >512 byte sectors, and I have been told that GEMDOS will work, but you have to create GEMDOS buffers that are appropriately sized. The built-in buffers are 512 bytes, and while everything else is parameterized to the BPB, that size is fixed. If you patch in your own buffers (using the system variable _bufl) it will work, I have been told. I have not verified this. The person who told me so had old ROMs, so that's even more encouraging. He said he wrote a RAMdisk with an Rwabs that returned 1K sectors, and it worked fine. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt