[comp.sys.atari.st] ST/020 DMA, and Disk driver bug.

martin@minster.UUCP (03/09/87)

Part 1:
=======

In article <1138@chinet.UUCP> cabbie@chinet.UUCP (Richard Andrews) writes:
>In article <579@atari.UUCP> neil@atari.UUCP (Neil Harris) writes:
>>As a matter of fact, the system you describe is almost exactly what we're
>>working on.  In the works is a 68020-based system which has none of its own
>>I/O except for a pair of DMA ports.  It will plug into the back of a current
>>ST computer and act as a high-powered number cruncher.  The 68881 and
>>Motorola MMU will also be part of the hardware, with UNIX system V or some
>>close relation being the software part.  The ST acts as a "genius terminal".

Regarding the two DMA ports... Wouldn't this be an excellent oportunity to
replace (at least one) of the DMA ports with a proper interface, such as SCSI.

At the moment many people just go out and buy an Atari DMA -> SCSI adapter,
but this only gives them a broken version of SCSI. Elsewhere Atari have
supported standards, but in this area they have been ignored. Is it because
Atari are afraid people will go and buy cheap SCSI disks from other vendors,
since Atari disks are relatively expensive, and slow?

Part 2
======

While I'm talking about Hard disks, has anyone else noticed that the disk
Rwabs operation (read/write sectors), takes a sector number which
is a 16-bit number!!!! This is the most UTTERLY STUPID thing I have seen
on the Atari yet, and may render it impossible to use for a system I
have in development! This places a hard limit on 32Mbytes/partition,
and 128Mbytes/disk, now I was planning on using one of the new MAXTOR
760MByte drives, or possibly the Northern Telecom 820MByte drive
(No flames please, I NEED this sort of storage!!).

And please don't say `But you can't use this, since GEMDOS can't work
with a partition bigger than 16Mbytes', This is irrelevant, I am using
my own filing system. But I did expect to be able to use the ATARI hard
disk driver!

Yours, extremely annoyed,

	Martin

PS
	Landon Dyer, you wrote the driver (although I realise the specification
had probably already been decided), are you listening?

--
usenet: mcvax!ukc!minster!martin

Martin C. Atkins
Composer's Desktop Project |	and	|
c/o Department of Music	   |		|	Department of Computer Science
University of York
Heslington
York Y01 5DD
U.K.

gordon@sage.UUCP (03/10/87)

In article <542288243.24960@minster.UUCP> martin@minster.UUCP (martin) writes:
>
>Regarding the two DMA ports... Wouldn't this be an excellent oportunity to
>replace (at least one) of the DMA ports with a proper interface, such as SCSI.

Surely, by two DMA ports, they mean that one is ported through to the other
(pardon the pun). So that you connect the 68020 box to the ST, the hard disk
to the 68020, etc, in one long chain.

dyer@atari.UUCP (03/12/87)

> While I'm talking about Hard disks, has anyone else noticed that the disk
> Rwabs operation (read/write sectors), takes a sector number which
> is a 16-bit number!!!! This is the most UTTERLY STUPID thing I have seen
> on the Atari yet, and may render it impossible to use for a system I
> have in development! This places a hard limit on 32Mbytes/partition,
> and 128Mbytes/disk, now I was planning on using one of the new MAXTOR
> 760MByte drives, or possibly the Northern Telecom 820MByte drive
> (No flames please, I NEED this sort of storage!!).
> 
> And please don't say `But you can't use this, since GEMDOS can't work
> with a partition bigger than 16Mbytes', This is irrelevant, I am using
> my own filing system. But I did expect to be able to use the ATARI hard
> disk driver!


Deja vu, eh?  Let's try this again, a little more constructively:



-------------------
PHYSICAL UNIT TABLE
-------------------

When the Atari Hard Disk driver is loaded, the system  vari-
able  `pun_ptr'  [$516 long] points to a Physical Unit (PUN)
table that describes the controllers and partitions  managed
by the driver.  The PUN table has the following structure:


    struct PUN
    {
        WORD nunits;        /* # physical drives */
        char physunit[16];  /* logical mapping table */
        LONG partstart[16]; /* partition starting sector */
        BPB partbpb[16];    /* BPB for logical drive */
    };


`nunits' contains the number of hard disk drives (ACSI  con-
trollers) that are handled by the driver.

Each byte in the array `physunit' maps a logical drive to  a
physical drive; the index into the table is the drive number
supplied to Rwabs(), the byte in the table contains the con-
troller  and  drive  number  to  use.  Bit 7 will be `1' for
unused entries, and `0' if the entry  is  valid.   Bits  0-3
contain the controller number and bits 4-6 contain the drive
number on the controller.


       7    6    5    4    3    2    1    0
    +----+----+----+----+----+----+----+----+
    |    |              |                   |
    | V  | drive number |  ACSI unit number |
    |    |              |                   |
    +----+----+----+----+----+----+----+----+
      |
       \--> 0=valid, 1=invalid (unmapped)


NOTE
The drive number in bits 4-6 must  currently  be  zero;  the
AHDI  driver  does  not yet support more than one drive on a
controller.

Each longword in the array `partstart' contains  the  32-bit
starting physical sector number of the partition.

The BPBs for each logical drive are computed when  the  hard
disk   driver  is  loaded.   They  are  kept  in  the  array
`partbpb'.  Unused BPBs will contain garbage.


----------------------------------------------------------------


So here is an awful kludge if you need to get to more than
16-bits worth of sectors on a hard disk.  The following is g'teed
to work ONLY IF YOU MANAGE THE STORAGE YOURSELF --- GEMDOS is
currently not capable of accessing more than 16 bits worth of
sectors.

Pick an unused logical device.  Fill in the `physunit' entry with
its ACSI unit and drive number.  The BPB doesn't matter, since
GEMDOS can't use the device anyway.

Now, before every call to Rwabs() on your device, fill in the
appropriate `partstart' entry with the 32-bit physical sector
number you really want.  Supply a logical sector number of 0 to
Rwabs().


[The next version of the hard disk driver will contain a 32-bit
sector number interface that will not break current applications,
and it will include several other enhancements.]
-- 
-Landon Dyer, Atari Corp.	    {sun,lll-lcc,imagen}!atari!dyer

The views expressed here do not not		
necessarily reflect those of Atari Corp.	Segments are for worms.

martin@minster.UUCP (03/16/87)

In article <645@atari.UUCP> dyer@atari.UUCP (Landon Dyer) writes:
>> While I'm talking about Hard disks, has anyone else noticed that the disk
>> Rwabs operation (read/write sectors), takes a sector number which
>> is a 16-bit number!!!! This is the most UTTERLY STUPID thing I have seen
>...
>Deja vu, eh?  Let's try this again, a little more constructively:
>

I would like to thank Landon for his swift, and enlightening response to
my panic-stricken article. I havn't tried this yet, but it all makes
sense, and gives every prospect of solving the problem for me.

I only wish the documentation I have (dev system, abacus, etc), was as helpful,
and easy to understand as his response!

Now I can also rest, sure in the knowledge, that someone at atari has seen
my request (clarified nicely by <sorry I can't remember the name>@rochester)
for a REAL SCSI interface.

	Martin

usenet: mcvax!ukc!minster!martin
surface:
	Martin C. Atkins
	Department of Computer Science
	University of York
	Heslington
	York Y01 5DD
	ENGLAND