New SCSI Host Adaptor

[KenLowe]

Some time ago I mentioned that I was wanting to build a SCSI host adaptor to use with a couple of old SCSI HDDs that I have in storage. I already have one of the drives working with an old Viglen host adaptor, so I know the drives are good and capable (can do 256 byte sectors, specifically).

Anyway, inspired by BeebSCSI, and borrowing the host adaptor design from that project, I have designed a board that will sit just above the 3.5" drive, and the drive / adaptor combo should sit in a 5.25" half height frame without any problem. I've also designed a small board to connect between the SCSI adaptor and the SCSI drive, which should keep everything securely in place.

I'm going to place an order for a few boards with SMT assembly shortly, and wondered if this would be of interest to anyone else? I know it's probably of limited interest, given the various SCSI drive solutions that are now available, but if you like the real retro feel and sound of a spinning drive, then this may just be for you! Costs are probably coming in at about £20 per fully assembled board (including the connector board).

SCSI Adaptor

Connector board

Template board sitting on top of SCSI drive mounted in 5.25" half height carrier. There is a 3mm thick double sided sticky foam pad on the underside of the board to keep it off the bottom of the drive.

Should I use a 5.25" Molex style power connector, or a 3.5" floppy drive style power connector??? Note that the Molex connector is upsides down relative to the SCSI drive connector. The connector board will connect between the SCSI drive and the SCSI host adaptor board, holding it all neatly in place.

There should be enough headroom to bring in a 1MHz cable to the back of the adaptor board. Not sure there's enough headroom for a straight vertical 1MHz connector, so although this template shows a vertical connector, I've actually gone with a 90 Deg horizontal connector instead.

[eelco108]

That's a neat solution, and would revive one of my old SCSI disks as well ... I'd be interested in a board (+the connector board)!

[egel]

I would be interested too.

[Boydie]

Plus one for me

[SteveBagley]

I'd be interested in one too.

Steve

[jimmoores]

I'd be interested.

[dominicbeesley]

I'm interested too

[KenLowe]

Okay. That's a bit more interest than I was initially anticipating. I've placed an initial order for a small batch of boards. Once I'm happy they're working correctly, and assuming I get permission from simoni to use and adapt his BeebSCSI implementation, I'll be back in touch with all those who have noted interest.

[simoni]

BeebSCSI software is GPL3 and the board design is CC share-alike - you are allowed to build upon and adapt at will even without my say-so as long as you follow the licensing (which basically says you can do anything you like with both the hardware and software design as long as the result is as open-source as the original).

So you don't need my permission, but you totally have my encouragement Looks like it would be a useful board.

[egel]

the board design is CC share-alike

Hardware License (Creative Commons BY-SA 4.0)
You have to give appropriate credit to Simoninns somewhere on the board, for example next to your name en provide a link to the license

[KenLowe]

You have to give appropriate credit to Simoninns somewhere on the board, for example next to your name en provide a link to the license.

I've included the following on the board, which is hopefully in the spirit of the licence:

[cmorley]

I think Ken's work is well within the licenses. Except ironically the method for crediting Simon - including Simon's logo kinda implies endorsement which is banned by the CC license Simon linked.

Keep up the good work Ken.

[simoni]

I seriously doubt anyone would interpret it as endorsement - I would say the thing to consider is the "spirit of the agreement". From my perspective, the important bit is that derivative projects remain open so other people can build upon any work done. Attribution is important; but that can be a simple mention on github, or something printed on the PCB, etc. It's more to let people know where they can find out more than any need for fame

For both GPL and CC there is no need to actually ask for permission as long as you are aware of the license terms; although (personally) I think it's polite and, like Ken, I would do the same thing. Being nice, kind and ethical doesn't require the letter of the law unless you prefix them with "un-" or "not".

In essence we are hobbyists with an interest and it's great when others share that interest - for me that ranges from people who simply want to use something all the way to those that want to dig in and bend things to their own purpose. I also have no problem with people selling the result - stuff costs money and time to make - as long as there is the option to do it yourself if you are so inclined and/or want to learn.

[KenLowe]

Prototype board arrived today. There's already one issue I know about, even before trying to test it. I managed to accidentally remove one of the tracks between the CPLD and one of the bias resistor blocks . I'll try to patch it with some kynar wire, but the solder points are very small, so not sure if I'll actually manage it.

Anyway, I thought I'd post up a couple of pictures with a mock up of how it will look. Ignore the fact that I don't have the correct header spot soldered onto the connector board. I'm waiting for delivery of the correct 2 x 25 headers:

[eelco108]

Still very nice! It all seems to fit well (given the space constraints) ...

[KenLowe]

I've been doing a bit of testing, but it's not quite working, so I'm looking for a bit of advice. I'm running a fairly simple setup, and I know the SCSI HDD is working correctly. If I connect the HDD to my old Viglen host adaptor, I can format / read / write to the drive without any problem. Currently I only have a single directory named 'FORMAT' on the drive, and 2 files saved within that directory.

When I hook up my new host adaptor, it appears to boot up fine, and if I do a *DIR, I can see the the 'FORMAT' directory. However, as soon as I try to move into that directory, I consistently get a 'Broken Directory' error:

I suspect it's possibly a termination / loading issue between the CPLD and the SCSI drive. On the SCSI side of the CPLD I've implemented SCSI termination as shown on the SCSI host adaptor circuit diagram. This has 220R pull up to +5v and 330R pull down to 0v on the data and control lines. It's worth me highlighting that the drive will only respond if I remove power from the 220R pull up resistors. If I have power on these resistors, then the beeb will hang at Acorn ADFS on power up.

Do I perhaps need to put some buffering or level shifting between the output of the CPLD, and the SCSI drive to get reliable operation? I'd assumed the 3.3v output from the CPLD would be suitable for driving the HDD signals, but with the SCSI termination, perhaps not. I'm inclined to remove the termination on the SCSI board completely to see what happens. It will be very close coupled to the HDD.

Circuit diagram attached.

Any words of wisdom?

[hoglet]

Circuit diagram attached.

Any words of wisdom?

How have you designed the CPLD?

Are happy you have correctly implemented the open collector outputs in the CPLD?

Dave

[KenLowe]

I just lifted the code from the BeebSCSI implementation and remapped I/O onto the 100pin CPLD. I had assumed that since the CPLD (host adaptor) was driving the AVR (SCSI drive) in BeebSCSI, that the CPLD outputs would be suitable for driving the SCSI HDD I/O similarly. Sounds like I perhaps need to do a bit more!

This is what is coded for the IRQ signal:

Code: Select all

	// The (not) IRQ line should be tristated.  The line should either be low
	// (when interrupting) or high-Z
	(* NOREDUCE = "TRUE" *)
	wire IRQ;
	assign bbc_nIRQ = (IRQ) ? 1'b0 : 1'bZ;

CPLD coding and programming is all a bit new to me!

If it helps, I've attached the build report from ISE...

[KenLowe]

I had a look through the CPLD code again last night, but couldn't see anything obvious that needed changing. However, I'm a complete amateur at this CPLD verilog coding, so I may be well off the mark.

This morning I decided to remove one bank of SCSI terminating resistors from the board. The ones I removed were the 330R resistors that were tied to GND (as I had no way of isolating these). I left the 220R resistors that are tied to Vcc, as these could be isolated with a jumper. With the 330Rs removed, and 220Rs isolated, the beeb just wouldn't boot. Linking the 220Rs back to Vcc gets the beeb to boot, but it hangs after printing Acorn ADFS. It never gets to the Basic '>' prompt.

If I then link the 220Rs to Gnd, I get more success. The beeb will boot to the Basic '>' prompt, and a *CAT will correctly show the root of the drive as before. This is very consistent. Ctrl-Break does the same. However, as soon as I try to step into the FORMAT directory I get the 'Broken Directory' error. Again, very consistently.

After initial boot

and then moving into FORMAT directory

As before, if I switch back to my original Viglen host adaptor, it all works as expected.

Using Viglen SCSI host adaptor

I'm going to do a bit of low level reading and writing to see if I can establish what's happening, but in the interim any help gratefully received!

I've also added a file to the root of the drive using the Viglen host adaptor. I'll switch over to my new host adaptor to see what happens when I try to read this file...

Edit: And as you can probably tell, I'm loving the screen capture facility of hoglets RGBtoHDMI adaptor!

[hoglet]

Hi Ken,

In the original schematic, SEL, ACK and RST are driven by open-collector buffers. As is the data bus. This is, I think, how SCSI-1 was designed. When the driver is deactivated, the termination resistors return the signal to the high level in a controlled way.

In your CPLD, they are driven by normal push-pull drivers, which is incorrect. In Simon's original source, there are comments to that effect as well:
https://github.com/simoninns/BeebSCSI/b ... pter.v#L39

I'm not convinved this is why you are having problems, but it's something I would try to fix (just to eliminate it as a possibility).

See the bbc_nIRQ signal for an example of how to correctly specify an open-collector output in Verilog.

You might find this document useful: Interface Circuits for SCSI (Texas Instruments)

Dave

[cmorley]

What is the current capability of the CPLD pins? You need 23mA sink (per pin) to drive SCSI-1 with a single terminator I think.

[hoglet]

I had another thought...

The load on the SCSI data lines is quite significant, especially with the termination resistors at each end. When the CPLD is driving all the SCSI datalines and trying to pull them low, it's quite possible you are getting a significant spike of ground bounce that's upsetting other things.

You probably should set the slew rate on all the outputs to SLOW, which will help reduce this ground bounce.

How good is your decoupling?

Dave

[hoglet]

What is the current capability of the CPLD pins? You need 23mA sink (per pin) to drive SCSI-1 with a single terminator I think.

Xilinx Application Note XAPP150 gives the I/V characterics for many of the Xilinx product families (derived I think from the IBIS simulation models):

In my experience, they can sink a fair bit of current per output.

The gradient on the above graph indicates the driver output impledence, and is about ~22 ohms when pulling low (1V / 45mA).

To work out Vol (the output low voltage) on the SCSI bus you have to consider:
- 220R in parallel with 220R to +5V (== 110R)
- 330R in parallel with 330R in parallel with 22R (== 19.4R)

Then a bit of ohms low gives:
Vol = 5V * 19.4R / (110R + 19.4R) = 0.75V

This a little close to the threshold for my liking:

Ken, it might be worth seeing what these signals look like on a scope during a data transfer.

Dave

[KenLowe]

Hi Ken,

In the original schematic, SEL, ACK and RST are driven by open-collector buffers. As is the data bus. This is, I think, how SCSI-1 was designed. When the driver is deactivated, the termination resistors return the signal to the high level in a controlled way.

In your CPLD, they are driven by normal push-pull drivers, which is incorrect. In Simon's original source, there are comments to that effect as well:
https://github.com/simoninns/BeebSCSI/b ... pter.v#L39

I'm not convinved this is why you are having problems, but it's something I would try to fix (just to eliminate it as a possibility).

See the bbc_nIRQ signal for an example of how to correctly specify an open-collector output in Verilog.

Baby steps:

Code: Select all

	// assign scsi_nACK = ~scsi_ACK;
	assign scsi_nACK = (~scsi_ACK) ? 1'b0 : 1'bZ;

Code: Select all

	// assign scsi_nSEL = ~scsi_SEL;
	assign scsi_nSEL = (~scsi_SEL) ? 1'b0 : 1'bZ;

Code: Select all

	//	assign scsi_nRST = bbc_nRST;
	assign scsi_nIRQ = (bbc_nRST) ? 1'b0 : 1'bZ;

Does that look right? Not so sure about the databus. I'll come back to that. It seems to build ok with the changes so far. Not implemented it yet, though.

I had another thought...

The load on the SCSI data lines is quite significant, especially with the termination resistors at each end. When the CPLD is driving all the SCSI datalines and trying to pull them low, it's quite possible you are getting a significant spike of ground bounce that's upsetting other things.

You probably should set the slew rate on all the outputs to SLOW, which will help reduce this ground bounce.

How good is your decoupling?

Dave

Slew rate now switched to SLOW, I think. I did this in the 'Process Properties - Fitting' window. I've got decoupling. How effective it is I'm not entirely sure!

What is the current capability of the CPLD pins? You need 23mA sink (per pin) to drive SCSI-1 with a single terminator I think.

I did wonder if this might be the problem. I had a look at the datasheet, but struggled to find the answer!
Edit. Ah, thank you Dave for the comprehensive answer!

Thanks for the help and pointers so far.

[KenLowe]

I've also added a file to the root of the drive using the Viglen host adaptor. I'll switch over to my new host adaptor to see what happens when I try to read this file...

So, I've now also saved a small basic file to the root of the drive, and this also shows up when I do a *CAT.

If I load the file, I get 'Bad Program' about 70% of the time, but the remaining times it loads correctly. I'm obviously getting some corruption. I've not tried to work out what's being corrupted. I'll implement the open collector and slew rate changes first, and try again.

[hoglet]

Baby steps:

Code: Select all

	// assign scsi_nACK = ~scsi_ACK;
	assign scsi_nACK = (~scsi_ACK) ? 1'b0 : 1'bZ;

Code: Select all

	// assign scsi_nSEL = ~scsi_SEL;
	assign scsi_nSEL = (~scsi_SEL) ? 1'b0 : 1'bZ;

Code: Select all

	//	assign scsi_nRST = bbc_nRST;
	assign scsi_nIRQ = (bbc_nRST) ? 1'b0 : 1'bZ;

Does that look right? Not so sure about the databus. I'll come back to that. It seems to build ok with the changes so far. Not implemented it yet, though.

I think you have them inverted, you need:

Code: Select all

	assign scsi_nACK = (scsi_ACK) ? 1'b0 : 1'bZ;
	assign scsi_nSEL = (scsi_SEL) ? 1'b0 : 1'bZ;
	assign scsi_nIRQ = (~bbc_nRST) ? 1'b0 : 1'bZ;

Slew rate now switched to SLOW, I think. I did this in the 'Process Properties - Fitting' window. I've got decoupling. How effective it is I'm not entirely sure!

Do check the CPLD report to make sure they are now marked as SLOW rather than FAST.

I normally set them explicitely in the .ucf file.

Dave

[cmorley]

Code: Select all

	// assign scsi_nACK = ~scsi_ACK;
	assign scsi_nACK = (~scsi_ACK) ? 1'b0 : 1'bZ;

Code: Select all

	// assign scsi_nSEL = ~scsi_SEL;
	assign scsi_nSEL = (~scsi_SEL) ? 1'b0 : 1'bZ;

Code: Select all

	//	assign scsi_nRST = bbc_nRST;
	assign scsi_nIRQ = (bbc_nRST) ? 1'b0 : 1'bZ;

Does that look right? Not so sure about the databus. I'll come back to that. It seems to build ok with the changes so far. Not implemented it yet, though.

I tend to use logical ! rather than bitwise ~ when I am dealing with logical tests. Both will work.

The databus is similar... e.g.

Code: Select all

wire [7:0] data_out;
wire [7:0] data_in;
wire dowrite;

assign data_pins[7:0] = (dowrite) ? ~data_out[7:0] : 8'bz;
assign data_in[7:0] = ~data_pins[7:0];

[KenLowe]

I tend to use logical ! rather than bitwise ~ when I am dealing with logical tests. Both will work.

Yeah. That's just the convention that was being used in the original code.

The databus is similar... e.g.

Code: Select all

wire [7:0] data_out;
wire [7:0] data_in;
wire dowrite;

assign data_pins[7:0] = (dowrite) ? ~data_out[7:0] : 8'bz;
assign data_in[7:0] = ~data_pins[7:0];

I think this is already implemented in the code?

Code: Select all

	// SCSI device databus bidirectional control
	wire [7:0] scsi_nDATA_in;
	wire [7:0] scsi_nDATA_out;
	
	// Here the input and output of the databus needs to be tied together
	// since the Acorn SCSI host adapter will drive the BBC databus output
	// latch from the data in latch if the SCSI bus isn't driven (this is 
	// used by ADFS to detect the presence of the host adapter, so we have
	// to emulate it even if the logic isn't needed for the SCSI).
	assign scsi_nDATA = (scsi_InO) ? scsi_nDATA_out : 8'hZZ;
	assign scsi_nDATA_in = (~scsi_InO) ? scsi_nDATA : scsi_nDATA_out;

Does that look right?

[KenLowe]

I think you have them inverted, you need:

Code: Select all

	assign scsi_nACK = (scsi_ACK) ? 1'b0 : 1'bZ;
	assign scsi_nSEL = (scsi_SEL) ? 1'b0 : 1'bZ;
	assign scsi_nIRQ = (~bbc_nRST) ? 1'b0 : 1'bZ;

Ok. Just to clarify, is the reason I need to invert because I'm switching to open collector?

Do check the CPLD report to make sure they are now marked as SLOW rather than FAST.

I normally set them explicitly in the .ucf file.

Dave

I'm not sure how to set them explicitly in the .ucf file, but they do all seem to be marked as SLOW now:

Code: Select all

** 22 Outputs **

Signal                                      Total Total Loc     Pin  Pin     Pin     Pwr  Slew Reg Init
Name                                        Pts   Inps          No.  Type    Use     Mode Rate State
bbc_DATA<7>                                 7     17    FB2_5   1    GTS/I/O I/O     STD  SLOW 
bbc_DATA<6>                                 7     17    FB2_6   2    GTS/I/O I/O     STD  SLOW 
bbc_DATA<5>                                 7     17    FB2_8   3    GTS/I/O I/O     STD  SLOW 
bbc_DATA<4>                                 7     17    FB2_9   4    GTS/I/O I/O     STD  SLOW 
bbc_DATA<3>                                 5     16    FB2_12  7    I/O     I/O     STD  SLOW 
bbc_DATA<2>                                 7     17    FB2_14  8    I/O     I/O     STD  SLOW 
bbc_DATA<1>                                 7     17    FB2_15  9    I/O     I/O     STD  SLOW 
bbc_DATA<0>                                 7     17    FB2_17  10   I/O     I/O     STD  SLOW 
bbc_nIRQ                                    1     1     FB3_6   25   I/O     O       STD  SLOW 
scsi_nDATA<0>                               3     3     FB6_2   74   I/O     I/O     STD  SLOW 
scsi_nCONF                                  2     12    FB6_5   76   I/O     O       STD  SLOW 
scsi_INTnEXT                                1     1     FB6_6   77   I/O     O       STD  SLOW 
scsi_nSEL                                   1     1     FB7_14  59   I/O     O       STD  SLOW 
scsi_nRST                                   1     1     FB7_15  60   I/O     O       STD  SLOW 
scsi_nACK                                   1     1     FB7_17  61   I/O     O       STD  SLOW 
scsi_nDATA<7>                               3     3     FB8_5   64   I/O     I/O     STD  SLOW 
scsi_nDATA<6>                               3     3     FB8_6   65   I/O     I/O     STD  SLOW 
scsi_nDATA<5>                               3     3     FB8_8   66   I/O     I/O     STD  SLOW 
scsi_nDATA<4>                               3     3     FB8_9   67   I/O     I/O     STD  SLOW 
scsi_nDATA<3>                               3     3     FB8_14  71   I/O     I/O     STD  SLOW 
scsi_nDATA<2>                               3     3     FB8_15  72   I/O     I/O     STD  SLOW 
scsi_nDATA<1>                               3     3     FB8_17  73   I/O     I/O     STD  SLOW 

I'll get these changes programmed onto the CPLD now. I'll probably also need to solder the resistors back on. That might be a bit of a challenge!

[hoglet]

I think this is already implemented in the code?

Code: Select all

	// SCSI device databus bidirectional control
	wire [7:0] scsi_nDATA_in;
	wire [7:0] scsi_nDATA_out;
	
	// Here the input and output of the databus needs to be tied together
	// since the Acorn SCSI host adapter will drive the BBC databus output
	// latch from the data in latch if the SCSI bus isn't driven (this is 
	// used by ADFS to detect the presence of the host adapter, so we have
	// to emulate it even if the logic isn't needed for the SCSI).
	assign scsi_nDATA = (scsi_InO) ? scsi_nDATA_out : 8'hZZ;
	assign scsi_nDATA_in = (~scsi_InO) ? scsi_nDATA : scsi_nDATA_out;

Does that look right?

I don't think it is, because during a write scsi_nDATA can still be actively driven high.

Instead of this line:

Code: Select all

    assign scsi_nDATA = (scsi_InO) ? scsi_nDATA_out : 8'hZZ;

I think you need something like:

Code: Select all

    assign scsi_nDATA[7] = (scsi_InO & ~scsi_nDATA_out[7]) ? 1'b0 : 1'bZ;
    assign scsi_nDATA[6] = (scsi_InO & ~scsi_nDATA_out[6]) ? 1'b0 : 1'bZ;
    assign scsi_nDATA[5] = (scsi_InO & ~scsi_nDATA_out[5]) ? 1'b0 : 1'bZ;
    assign scsi_nDATA[4] = (scsi_InO & ~scsi_nDATA_out[4]) ? 1'b0 : 1'bZ;
    assign scsi_nDATA[3] = (scsi_InO & ~scsi_nDATA_out[3]) ? 1'b0 : 1'bZ;
    assign scsi_nDATA[2] = (scsi_InO & ~scsi_nDATA_out[2]) ? 1'b0 : 1'bZ;
    assign scsi_nDATA[1] = (scsi_InO & ~scsi_nDATA_out[1]) ? 1'b0 : 1'bZ;
    assign scsi_nDATA[0] = (scsi_InO & ~scsi_nDATA_out[0]) ? 1'b0 : 1'bZ;

I can't think of a way to achieve this with a single line!

(Hopefully the Xilinx tools won't barf at multiple assignments like this}

Dave