#SCSI HELP!
11 messages in this thread
I'm having troube with the "scsi.device" which has replaced the "hddisk"
device on the 3000. I am trying to use the SCSICmd structure and cannot
send more than 256 bytes or else the system hangs with the HD light
remaining on. Setting up a data buffer with a byte pattern as follows:
01,02,03,04,05,06,07,08…..
the output consists of bytes 01,03,05,07… skipping every other byte.
It appears that the AMIGA thinks it read 512 bytes but the tagret device
only receives 256 and ties up the scsi bus requesting the remainder. This
problem is duplicateable in C and assembly. I know that the target device
functions properly as the asme testing on another type of computer results
in correct operation. Any ideas or help would be appreciated. Harry M.
Look at your data buffer, and it's declaration. When I was working
on my test program, I declared it to be a UBYTE array, and then had to cast
it to a UWORD array when assigned to scsi_Data. I'm not sure why CBM built
the structure showing the data for the data phase as being 16 bit quanities
for an 8 bit bus (the SCSI bus). I'm guessing they may require word
alignment of the data, but use it in "byte" sized hunks. If the data is
mis-aligned, it could cause some interesting effects…which I believe
you've seen.
Thanks. I'll try that. What I found did work properly was to create a
second uninitialized UBYTE buff2[512] array and memcpy the UBYTE buf1[512]
initialized array to it, then use buff2 to scsidata. Mike Roth said the
compiler will put initialized data in a data hunk and the uninitialized
data in a bss hunk, and this was the only difference in the code.
Does your cast look like this? :
SCSICmd.scsi_Data = ( (UWORD * ) &(UWORD)buffer[0] );
The Lattice / SAS C compiler 5.10 has an __aligned keyword to force
alignment. It may really be a linker issue as I could duplicate the problem
in assembly (A68k) and Blink using an initialized data array but I haven't
tried using a second buffer. I'll let you know what I find out.
Harry,
#define BLOCKSIZE 512
UBYTE databuff[BLOCKSIZE];
SCSIcmd.scsi_Data = (UWORD *) databuff;
Don
Yep, that works Don
UBYTE databuf[BLOCKSIZE] = {1,2,3,4,5….}; doesn't
work.
Harry,
I haven't tried this, but you might…just for "fun":
UBYTE databuf[BLOCKSIZE] = {
(UBYTE) 1,
(UBYTE) 2,
… etc.
};
or
UBYTE databuf[BLOCKSIZE];
register UBYTE i;
for (i=0; i < BLOCKSIZE; i++) {
databuf[i] = i;
}
Don
Now that's interesting, but one would think 0x01,0x02 would do the same
thing. Sure, I'll try it too:) Tnx again. Harry
Harry,
Let me know what happens…it could be a compiler side-effect or
bug.
Don
Harry,
BTW…here's what I'm thinking. As a byte array, filling it out
with integer values should yield an array as follows:
(each number represents one byte)
1234567…etc.
But if it were a word (16 bits) array, it'd get filled out like
this:
010203040506…etc.
(and I seem to recall that's what you're seeing)
My *guess* is that the scsi_Data is declared as a UWORD pointer
because the driver grabs the data 16 bits at a time, but pumps it to the
drive, 8 at a time (because it's only an 8 bit bus). If you originally
declared the buffer to be a UWORD array, then it'd fill out with every
other byte being a 0, and thus you'd get only 1/2 of what you intended
separated by 0's on the device.
Thus, by declaring it a UBYTE array, and filling it out with byte
values, it works even after you cast it to a UWORD array. Since the
scsi_Length is the byte length of data phase…the driver can handle the
conversion just fine.
That's my guess as to what's going on.
Don
I see what you're getting at but it was mor like this:
0102030405060708… What went to the device was 01030507.
The array was declared as a UBYTE array. So it looks like it was skipping
entire words. I did try a UWORD array 0x0102,0x0304 etc with the same
result. The only difference was whether or not the UBYTE array was
initialized:
for example UBYTE array[5] ={1,2,3,4,5} vs UBYTE
array[5] and stuffing the uninited array later. Mike Roth said that the
inited data goes into a data hunk vs a Bss hunk for uninited data. I'll
have to try it on a 2000 where there is no 32 bit wide fetch, that might be
part of it too. I'll get to play around with it more this weekend, we're
onto something I think.Thanks again, Harry Manolopoulos
Harry,
Ok…let me know what you find.
Don