ivan@cvax.psi.ch (Ivan D. Reid) (02/05/90)
There have been several messages lately about weird results when using
diskettes formatted on IBM-type machines (especially HPs). Basically, the ST
seems to trash the directories/FATs. This *MAY* be the same problem I ran into
last year transferring disks to & from an HP-150. There are two problems with
this, neither of which HP is likely to have changed in later machines:
a) the HP-150 insists that the first three bytes in the bootsector be an Intel
JMP SHORT <displacement>/NOP, where the value of displacement is critical
(can't remember the value off-hand :-(, this despite the MS-DOS developer's
guide suggesting that any value of displacement is OK, as well as the 3-byte
JMP LONG <disp>, to validate an MS-DOS diskette.
b) the HP-150 also uses *TWO* reserved sectors, and has DOS loading data in the
second sector, after the boot sector. The Atari TOS (up until the Megas; I
can't check 1.4 as I don't believe Atari Schweiz has released it yet -- I'm
still waiting for a Blitter!) *ASSUMES* only one reserved sector, so when it
reads a HP-150 diskette it gets the FAT, directory, and data sectors all off by
one. I guess you can see the problems that can occur if the two machines don't
agree on the location of all these items...
The first problem is readily fixed with a format programme or sector
editor; just use DEBUG to read in the boot sector of a disk formatted on the
DOS machine (L0 n 0 1 where n=0 for A:, etc) and dump out the first bit (D0) --
note the first three bytes (probably EB xx 90) and, following a hint on the net
last week, also the Media Descriptor Byte at location 015h. Make sure that
your Atari disk has the same values here and you may be able to read it on the
DOS machine. While you have the dump in front of you, also check bytes at 01eh
and 01fh; these give the number of reserved sectors. If it's anything other
than 01 00 (e.g. 02 00 on the HP) then TOS is guaranteed to trash or misread
disks formatted on the DOS machine. I wrote a patch that enabled me to
intercept BPB calls and correct the information returned to the caller in these
cases. It's short, so the docs and UUE file follow. Because of its ancestry I
won't post the sources -- they're available on request.
ivan
------------------------ Coupez ici! 8< -------------------------------
NEWBPB.PRG
==========
A programme to allow the Atari ST to read properly diskettes
with more than one reserved sector.
PROBLEM
======= The Atari ST, at least up until the Mega ST versions (I haven't been
able to check TOS1.4 or the STe TOS), had a bug where it assumed that all
floppies had only one reserved sector -- the boot sector. This bug occurs in
the routine to return the BPB (Bios Parameter Block) for the diskettes. This
causes problems when trying to read, for example, disks from a HP-150 MS-DOS
machine, which has two reserved sectors, since the calculated locations for the
rest of the disk (FAT sectors, root directory, and so on) are wrong.
SOLUTION
======== I have written a little programme, based on ideas from a couple of
programmes from Landon Dyer of Atari Corp., a RAM-disk written by Volker
Brandt, and a virus I dissected in September 1989, which intercepts the BPB
routine and recalculates the FAT, directory, and data locations from
boot-sector information which is left in memory after the BPB routine is
called. This apparently works because of the way the rest of TOS interprets
the BPB data; in particular, it obviously requires that the two FAT copies are
contiguous, and calculates the start of the first by subtracting the FAT length
from the position of the second.
TO USE
====== The programme NEWBPB.PRG should be run before you try to access
diskettes with more than one reserved sector. This can be accomplished by
double-clicking on it from the desktop. If your need to read these disks is
more than casual, you may want to put the programme in the AUTO folder of your
boot-disk so that it is automatically executed as you boot. It only needs to be
run once as it stays resident until the machine is powered down, but it
shouldn't do any harm if it is executed again (just waste time and
memory-space).
DISCLAIMER
========== This appears to work on the one HP-150-formatted diskette I have.
Tha's a 100% success rate, but your mileage may vary! As with any programme of
this nature, you should test it carefully (write-protect disks, etc.) before
trusting it. If there's any problem, please let me know and I'll try to fix
it, but I make no warranty as to the fitness of this programme for any purposes
and disclaim any responsibility for any harm resulting from the use of the
programme.
Ivan Reid. Untersiggenthal 29/11/89
ivan@CAGEIR5A.BITNET ivan@rzsin.sin.ch 20550::IVAN
----------------8< Schneiden Sie hier, bitte! >8 ------------------------------
table
!"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 NEWBPB.PRG
M8!H "\ @ "!O 0@* ,T*@ %-"H !S0z
MO 0 CP +PO/ *8_/ F3DY<CS\\ O.0 +P_/ Q3D%@_DY6y
M _+@ (('D # 3I ,7P ";%!(YP ,*GD 3&*$ 0+0 /X4 0+0 .T&P x
M"#E K0; (T&P !CE P0+0 4X4 0+0 3D&P #,"\ #__X'L (Y0 .w
M0FP $" ,3-\P $Y>3G4C^0 !'( # (_P \ $<DYU & 82%F8&v
! &P u
t
end
------------------------- Hack here, mate! -----------------------------------dsmall@well.sf.ca.us (David Small) (02/08/90)
[The basenote discusses using ST disks in MSDOS machines, and the troubles thereof]. I've had trouble under TOS 1.4 with Toshiba disks as well -- double sided, MS-DOS, DOS 3.3, off a Toshiba 1200HB. One time I read a file into the ST, and got the 1st sector repeated for the length of the file. Many times directory changes (cd) fail or act weirdly. I always have to ARC (to get a quick & dirty CRC) to make sure the file transferred ... it's that flaky. I've been told that Toshibas do something especially strange that makes things worse, but do not recall the details. -- thanks, Dave / Gadgets
dave@dms3b1.UUCP (Dave Hanna) (02/19/90)
In article <16035@well.sf.ca.us> dsmall@well.UUCP (David Small) writes: <[The basenote discusses using ST disks in MSDOS machines, and the troubles <thereof]. < < I've had trouble under TOS 1.4 with Toshiba disks as well -- double <sided, MS-DOS, DOS 3.3, off a Toshiba 1200HB. One time I read a file into <the ST, and got the 1st sector repeated for the length of the file. Many <times directory changes (cd) fail or act weirdly. ... < I've been told that Toshibas do something especially strange that <makes things worse, but do not recall the details. I've encountered similar problems with disks written in (supposedly) IBM compatible format with Mtools on a UNIX-PC. One problem that I have determined with Mtools is that it only writes the first copy of the FAT. I've got plans to correct that short-coming and see if it fixes the problem. At any rate, could that be the problem with the Toshipa? > -- thanks, Dave / Gadgets Dave Hanna -- Dave Hanna, Infotouch Systems, Inc. | "Do or do not -- There is no try" P.O. Box 584, Bedford, TX 76095 | - Yoda (214) 358-4534 (817) 540-1524 | UUCP: ...!texbell!letni!dms3b1!dave |