Amiga 500 bluescsi

[marcelv-3]

Tested the BlueScsi with an Amiga 500 and Kommos scsi controller (jkscsi.device)

questions:

1. After powering on the A500 I have to press the reset button on the bluescsi to get the scsi devices recognized.
2. The bluescsi only works if the termination power jumper 5V is removed and the termination jumper GND is in place. Both jumpers on or removed does not work. Do you have an explanation ?
3. When formatting the drive with the provided tool FormatSCSI , I get an illegal request on write buffer. This is because the write buffer (0x3B) command is not implemented in bluescsi. Could you add the following code:

case 0x3B:
    LOGN("[WriteBuffer]");
		onWriteBuffer(cmd[1] & 7, ((uint32_t)cmd[6] << 16) | ((uint32_t)cmd[7] << 8) | cmd[8]);
    break;


/*
 * onWriteBuffer.
 */
byte onWriteBuffer(byte mode, uint32_t allocLength)
{
	// WRITE BUFFER 0x3B
	// Used for testing buffer, no change to medium

  LOGN("-WriteBuffer");
  LOGHEXN(allocLength);

  //mode 00h Combined header and data mode
  //mode 02h Data mode
	if ((mode == 0 || mode == 2) && allocLength <= sizeof(m_buf))
	{
    readDataPhase(allocLength, m_buf);
    for (unsigned i = 0; i < allocLength; i++) {
      LOGHEX(m_buf[i]);LOG(" ");
    }
    LOGN("");
    return 0x00;
	}
	else
	{
    m_senseKey = 5;  // Illegal request
    m_addition_sense = 0x2400; // Invalid field in CDB
    return 0x02;  // Check Condition
	}
}

Ungultige anforderung = invalid request

After formatting the drive and installing workbench the bluescsi is working great in the Amiga

[erichelgeson]

@marcelv-3 - great debugging

For 1/2 - I'm not sure why - that is strange. Maybe due to how termination is handled on that particular machine? I have seen others do the same "half" termination, even on other scsi drives/drive emulators, to get it to work.

3 - Have you tested this patch? At first glace looks like it should respond correctly to that test. Would you be willing to open a Pull Request to integrate it in? Also there is a SCSI_READ_BUFFER(0x3C) command - and does seem to have what looks like a no-op mode - maybe we should look into that one as well (just glanced at the docs)

[marcelv-3]

1- The reset on the bluescsi I cannot explain, when the bluescsi has started it waits in the main loop so has to start responding when the controller autoboot rom has started. Have to do some more logging.

2 - Strange termination, controller seems to have full termination, but if it works...

3 - The patch has been tested , this is the (abbreviated) log output

Command:3B:0:0:0:0:0:0:2:0:0:ID 0:LUN 0
[WriteBuffer]
-WriteBuffer
200
DATAOUT PHASE
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C
....
6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C 6C
Sts
MsgIn
BusFree
Selection

Great idea to also add the ReadBuffer, can write the code, but testing would be difficult because the controller I am now testing does not issue the command, but as you say, will be a no-op

[erichelgeson]

1 - Maybe modify the code to not truncate log.txt - see what bluescsi is doing right before you hit reset and then right after and compare. Maybe something is asserted too early and it goes too far in the code, just taking some guesses.

2- If you have the ability to measure the resistance of some of the lines, maybe termination is just pulling things too much and bluescsi isnt able to shout/talk over the higher resistance.

3 - looks good, and yes I'm not sure how to test readbuffer, but a seemingly safe add.

I appreciate all the debugging you've done, thanks!

[erichelgeson]

Took a quick stab at read, just echo back whatever write put in the buffer. Looks like your app sent 200 bytes?
https://gist.github.com/erichelgeson/ea3d471fd6c3b1172140db7e5850c099 - let me know what you think

[marcelv-3]

checked the hardware, the controller does not have termination on the parity bit (think it does not use parity)
the bluescsi has termination on the parity bit, maybe this is a cause for the half termination ?

Question is, does the bluescsi expect / need the parity ?
can it be disabled, software ?

[erichelgeson]

The READ_PARITY_CHECK is default off - but any line on the bus should have termination if used or it'd be pulled too high/low.

[marcelv-3]

Found a factory mistake on the PCB, 2 resistors not in the right place.
The ATN signal had a different (termination) resistance reading compared to the other signals
Compared the PCB with the schematic and found 2 resistors not correctly placed.
Swapped them, the resistance is now ok.
Does not solve the reset or half termination problem, have to look further for this.

Strange thing that all pictures of the board I can find also have the resistors wrong, so must be factory fault.

original configuration

after the change, the correct way

[marcelv-3]

Fixed the reset problem !!!!! the Amiga now boots directly without having to press reset on the bluescsi,

did a lot of debugging, testing, trying...

code changes:
readHandshake(): add REQ inactive before REQ active

  SCSI_OUT(vREQ,inactive)
  SCSI_OUT(vREQ,active)

loop()
add delay in wait loop, (don't know if this is needed, will test later)

  do {
    delayMicroseconds(35);
  } while( SCSI_IN(vBSY) || !SCSI_IN(vSEL) || SCSI_IN(vRST));

after the line: if(isHigh(gpio_read(ATN))) {
==> this is the message handling code section, not command mode

replaced the MsgOut2 with direct readIO()
also added delay (maybe not needed, will test later)

    while(isHigh(gpio_read(ATN)) && loopWait < 255) {
      delayMicroseconds(35);
      //MsgOut2();
      m_msb[m_msc] = readIO();
      m_msc++;

      loopWait++;
    }

add message handling for 0x47 (parity error?) this might also solve the problem i read about in another discussion (sun sparcstation)

    for(int i = 0; i < m_msc; i++) {
      //Stop processing after parity errror
      if (m_msb[i] == 0x47) {
        LOGN("// PARITY ERROR");
        goto BusFree;
      }

My currrent source contains a lot of debug and log statements, have to create a version based on the latest published and check if this works. Also have to test this version on a Mac as not to break that code,

Also set gpio_mode to GPIO_INPUT_PD for ATN,BSY,ACK,SEL
was GPIO_INPUT_PU
Have to check if change is needed.

UPDATE:
delayMicroseconds(35); and GPIO_INPUT_PD changes are not needed.

@erichelgeson Could you review the changes and possibly merge ?

[marcelv-3]

or replace MsgOut2 in this while loop with MsgOut3

this is more time critical, in debug mode (write to file) this is not always fast enough

/*
 * MsgOut3.
 */
void MsgOut3()
{
  LOGN("MsgOut3");
  SCSI_OUT(vMSG,  active) //  gpio_write(MSG, high);
  SCSI_OUT(vCD ,  active) //  gpio_write(CD, high);
  SCSI_OUT(vIO ,inactive) //  gpio_write(IO, low);
  m_msb[m_msc] = readIO();
  m_msc++;
  m_msc %= 256;
}

have also noticed that sometimes an IDENTIFY message is generated,

The SCSI controller sets ATN and SEL in the selection phase and sends the IDENTIFY message.

so the IDENTIFY code also has to be completed, or at least a default busFree

      // IDENTIFY
      if (m_msb[i] >= 0x80) {
        LOGN("// IDENTIFY");
        //TODO`...

        goto BusFree;
      }

[erichelgeson]

It looks like you're not on the latest - some things have changed around the code you're referencing

I'll take a look at the spec for Identify/0x80 - good call.

[marcelv-3]

Downloaded the latest snapshot, have to change the following to get it working (without reset)

• replace readHandshake() with readIO()
• add 0x47 handling
• add busfree to Identify (as temp fix)

Question, why the loop to read 255 bytes, you only need 1 after the ATN signal , unless you get an Extended message, but you can read the rest of the bytes there

    while(isHigh(gpio_read(ATN)) && msc < 255) {
      m_msb[msc++] = readIO(); // readHandshake();
    }
    for(int i = 0; i < msc; i++) {
      // Parity?
      if (m_msb[i] == 0x47) {
        goto BusFree;
      }
      // ABORT
      if (m_msb[i] == 0x06) {
        goto BusFree;
      }
      // BUS DEVICE RESET
      if (m_msb[i] == 0x0C) {
        syncoffset = 0;
        goto BusFree;
      }
      // IDENTIFY
      if (m_msb[i] >= 0x80) {
        goto BusFree;
      }

[erichelgeson]

By changing readhandshake to readIO -you're not doing the handshake... I think it's fairly safe to add the busfree's for some of the other handshake messages, but I dont think we want to remove the handshake. I havent dove too deep in the spec on this yet, but will soon. Glad you made some progress!