New SCSI Host Adaptor

[dominicbeesley]

First thing would be to check the termination is pulling the data bus high quickly enough? Apologies if that already checked. As dave says this looks like it should work. I need to try and get time to check tonight whether the data lines really are open collector on my own board

[dp11]

can you try replacing the line

Code: Select all

	assign scsi_nDATA_in = (~scsi_InO) ? scsi_nDATA : scsi_nDATA_out;

with

Code: Select all

	assign scsi_nDATA_in = scsi_nDATA  ;

Which matches the original hardware.

[dp11]

Once open collector is working correctly , if you were to respin the board you can parallel up the outputs for more current.

[KenLowe]

First thing would be to check the termination is pulling the data bus high quickly enough? Apologies if that already checked. As dave says this looks like it should work. I need to try and get time to check tonight whether the data lines really are open collector on my own board

From what I can tell, pull up is happening almost instantaneously. I'm maybe not measuring or reading it properly on the scope, though. There are certainly 2 x open collector 7438s on the data lines of my Viglen board, which matches the circuit diagram.

can you try replacing the line

Code: Select all

	assign scsi_nDATA_in = (~scsi_InO) ? scsi_nDATA : scsi_nDATA_out;

with

Code: Select all

	assign scsi_nDATA_in = scsi_nDATA  ;

Which matches the original hardware.

Just tried that, but it doesn't appear to have made any difference. Updated report attached. However, this modification does work with the original data bus logic.

Once open collector is working correctly , if you were to respin the board you can parallel up the outputs for more current.

Good idea. There are plenty of spare I/O pins.

[dp11]

Could you try in the verlog setting bbc_INTnEXT low. This will reduce the number of pterms used on the trisate node. I wonder if there is some sort of timing issue.

[KenLowe]

I notice the spare output pin are connected to ground. What you can do which might help slightly is set them to be outputs and drive them low.

Done, although I'm not sure if this is the best way to achieve this?

Code: Select all

module SCSIAdaptor(
	// Set spare I/O to outputs
	output [9:0] pins01_25,		// 10 spare pins
	output [15:0] pins26_50,	// 16 spare pins
	output [5:0] pins51_75,		// 6 spare pins
	output [10:0] pins76_100,	// 11 spare pins

	<----SNIP---->
	
	);

	// Set spare outputs to 0
	assign pins01_25 = 10'b0;
	assign pins26_50 = 16'b0;
	assign pins51_75 = 6'b0;
	assign pins76_100 = 11'b0;

	<----SNIP---->

endmodule

[dp11]

That looks fine. Can you look at the ground level again.

[KenLowe]

Could you try in the verlog setting bbc_INTnEXT low. This will reduce the number of pterms used on the tristate node. I wonder if there is some sort of timing issue.

Not to sure how to do this as it's defined as an input? I could just get rid of that term altogether.

That looks fine. Can you look at the ground level again.

Doesn't seem to have made much difference:

Ctrl-Break

*DIR ROMS

*LOAD ADFS130 3000

[dp11]

Could you try in the verlog setting bbc_INTnEXT low. This will reduce the number of pterms used on the tristate node. I wonder if there is some sort of timing issue.

Not to sure how to do this as it's defined as an input? I could just get rid of that term altogether.

Yep just get rid of the input definition and set it to be a wire instead and assign it to zero.

The scope traces don't show much of a difference. It does no harm and might improve signal integrity .

[KenLowe]

Yep just get rid of the input definition and set it to be a wire instead and assign it to zero.

Well, it's not changed the ground level, but it's got rid of the noise:

Ctrl-Break

I'll switch back to the open collector data bus logic, and see how it performs now...

[KenLowe]

I'll switch back to the open collector data bus logic, and see how it performs now...

Success!!!

A huge thank you once again for all the pointers. The bbc_INTnEXT flag seems to have been the main cause of the issues! It's not really relevant for this external board, so I'll just leave it out.

Updated report and verilog file attached for anyone that's interested.

[dp11]

Excellent.

But the really question is why ? is is because there is noise on bbc_INTnEXT signal which gets fed into the CPLD which upsets things when you need the extra pterms. Is there a subtle timing issue? or something else?

If you are never going to use it internally then the extra ground pin on the 1MHz cable would be good if you want to retain the flexibility then a capacitor to ground would help.

[KenLowe]

Excellent.

But the real question is why ? is it because there is noise on bbc_INTnEXT signal which gets fed into the CPLD which upsets things when you need the extra pterms. Is there a subtle timing issue? or something else?

Great questions.

[KenLowe]

If you've been following the discussion in this thread, you will be aware that I was having some issues getting reliable operation of the SCSI host adaptor. With the help of some very talented people on this forum, we resolved the last of these issues yesterday evening, and I now have the board running reliably on several different SCSI drives.

These boards were primarily built for my own personal use, but I did buy some extras following the notes of interest on the first page of this thread. For those who are still interested, I am now happy to offer these up for sale. Cost will be £22.50, which includes UK based P&P. Cost is slightly higher than my initial estimate to cover custom fees that I had hoped wouldn't apply. Please PM me if you would like to proceed, and we can arrange payment. If you can't PM, then drop a note here, and I'll get in touch with you via PM, and provide you with alternative contact details.

As mentioned in an earlier post, I've had to add in a patch wire to correct a routing error on the board. At this stage I'm not intending to place a new order for boards to correct this error, but in time I will be posting up the Kicad files, so others can place orders in the future if they wish.

***NOTE that this board is to be used with SCSI1 drives that support 256 byte sectors. Please check that your drive supports 256 byte sectors. Most only support 512 byte sectors. Check this post out for some additional information***

Finally, here's a couple of photos of one of my drives with the board installed. This has been installed in a case that originally housed a full height 40 track floppy drive:

SCSI Host Adaptor with patch wire

SCSI & Floppy drives in full height open case

SCSI & Floppy drives in full height closed case

[danielj]

DS1Z_QuickPrint10.png

Isn't that low still not within spec though (looks 0.6/0.7ish when spec says 0.5V max, 0.2v ideal)? It might work sometimes, but if it's marginal then there's always the chance that it's not going to behave properly? - pg. 3 in the document hoglet linked: http://www.ti.com/lit/an/slla035/slla035.pdf - even a tiny bit of noise from somewhere could send it out of whack?

d.

[KenLowe]

DS1Z_QuickPrint10.png

Isn't that low still not within spec though (looks 0.6/0.7ish when spec says 0.5V max, 0.2v ideal)? It might work sometimes, but if it's marginal then there's always the chance that it's not going to behave properly? - pg. 3 in the document hoglet linked: http://www.ti.com/lit/an/slla035/slla035.pdf - even a tiny bit of noise from somewhere could send it out of whack?

d.

That might be the case. I've had a few soak testing over the last 24hr on different drives and they've all performed flawlessly. That said, it has all been with Fujitsu drives (various different models), so other drives may behave differently. This is not meant to be a commercial venture, and I'm not trying to make any money out of this; merely covering (most of) my costs.

As I said, this was a really a project for personal reasons, but with the opportunity for others to buy one of my boards (warts and all) if it's of interest to them. As I mentioned in my previous post, the Kicad files will be posted up in due course for anyone to take the current design, and adapt for their own needs. This could include buffering if desired.

Obviously, if my board doesn't work for anyone, then they're entitled to their money back. I should have maybe made this clearer.

Thanks for pointing this out. I do like to be fully transparent on these things.

Edit: One other point worth noting is that there actually appears to be two different 'low' values. I assume one is when the SCSI drive is driving the bus, and the other is when the CPLD is driving the bus. Right now I'm not sure which one is the higher of the two. At a guess, based on the trace using the old Viglen board, it's the CPLD, but I'd need to check this.

[KenLowe]

Isn't that low still not within spec though (looks 0.6/0.7ish when spec says 0.5V max, 0.2v ideal)? It might work sometimes, but if it's marginal then there's always the chance that it's not going to behave properly? - pg. 3 in the document hoglet linked: http://www.ti.com/lit/an/slla035/slla035.pdf - even a tiny bit of noise from somewhere could send it out of whack?

I was having a look through some of the SCSI drive manuals yesterday (for other reasons), and I came across this for a couple of batches of Seagate drives:

One batch of Seagate drives:

Code: Select all

Vil (low-level input voltage) = 1.0 V maximum (signal true); minimum = Vss – 0.5 V.
Vih (high-level input voltage) = 1.9 V minimum (signal false); maximum = Vdd +0.5V.

A different batch of Seagate drives:

Code: Select all

Logic Level	Driver Output		Receiver Input
NEGATED (0)	>2.5 V: <5.25 V		>2.0 V: <5.25 V
ASSERTED (1)	<0.4 V: >0.0 V		<0.8 V: >0. 0 V

The 0.8v minimum is quite close to my CPLD output (but still on the right side), and certainly higher than the 0.2 / 0.5 v that the SCSI spec calls for.

I can't find the equivalent for the Fujitsu drives I'm currently using, but this might help explain why I'm not having any issues.

[KenLowe]

I received a couple of Seagate drives at the weekend that claimed to support 256 byte sectors, so I set about testing these on my beeb. Mixed results.

SCSI drive 1
Doesn't seem to respond at all. It hangs up whenever I try to do a Request Sense or Mode Sense

SCSI drive 2
Works with my original Viglen host adaptor. No termination set on the drive.
Works with my new adaptor, but only if the Seagate drive (set at ID0) has no termination, and is daisy chained with my Fujitsu drive (set at ID1) which is terminated.
I've subsequently reformatted this drive to 256 byte sectors, and 90 mins later, I can use ADFS to read & write to this drive using either of the above setups.

Focusing on drive 2 for now, I've started poking around with a scope, and noticed the following happening on the SCSI RST line when I do a Ctrl-A-Break. In these test cases, I've got the SCSI adaptor connected to the Seagate drive, with no termination at the drive. The Fujitsu drive is not connected. The blue trace is SCSI RST (pin 40), and the yellow trace is SCSI I/O (pin 50):

Original Viglen Host Adaptor

CPLD based Host Adaptor

I notice that the original SCSI circuit diagram has a 2k2 pull up resistor on the nRST line at the 1MHz end of the board, before going though a couple of buffers, whereas this is missing on my board. I can't see why that would make any difference. The SCSI RST line is open collector on my board, as is the case on the original Viglen board. Further investigation required.

[dp11]

Somebody isn't open collector on the blue trace

[KenLowe]

Somebody isn't open collector on the blue trace

Can I just clarify. When you say that somebody isn't O/C, I assume you're referring to the second graph, where I measure an intermediate voltage of about 1V on the blue trace during a reset?

I'm certain it's not the CPLD, as the output is just as we set earlier:

Code: Select all

assign scsi_nRST = (~bbc_nRST) ? 1'b0 : 1'bz;

It's almost as if the SCSI reset line is missing pull up at the Seagate drive, but the thing that's confusing me is that the original host adaptor works fine with this Seagate drive (without termination), and my new host adaptor works fine if I add a Fujitsu drive (with termination) onto the SCSI bus. I just can't get my host adaptor to work with the Seagate drive on its own, with or without termination.

I'm still working it.

[KenLowe]

It's almost as if the SCSI reset line is missing pull up at the Seagate drive

So, I added 2k2 pull up to the 3 SCSI signals RST, SEL & ACK and guess what????

It works!!!

But what still confuses me is why my original Viglen board works with these Seagate drives without pull up on these lines???

Edit 1: Having tested a bit further, only SEL & ACK seem to need the pull up. The RST signal appears to work fine without it. I thought I'd also give my other Seagate drive a test on this setup, but it's still not working, so it must be a different issue. One for another day.

Edit 2: I've just checked the Viglen host adaptor, and as per the circuit diagram, there's definitely no pull up on any of these 3 lines, so I really don't know what's happening

[simoni]

My guess would be that the additional pull-up/pull-down is causing the 3v3 CPLD output to swing between 0-5V rather than 0-3v3 - if the connected logic is TTL it shouldn't make any difference since the centre-point is 2v5. If the connected logic is CMOS though, 2v5 isn't enough as you need 3v5 to swing high (and 1v5 to swing low). This is a bit of a gotcha when converting 5V TTL systems as they work fine with CMOS levels - but not when you use 3v3. This is an issue with building stuff for both the Master and the Beeb for example - the Beeb is 5V TTL, but the Master is 5V CMOS (if you look at the Master's schematic you'll see additional components on the external ports to 'convert' them to TTL - the internal ports don't have that which is why the BeebSCSI internal adapter is necessary).

So, on the drives, look at the line buffers and see if there is a difference - the part numbers of the 74 series chips usually gives it away, they are different for CMOS and TTL.

The most 'correct' fix would be to add a 5V line buffer IC to the CPLD<->SCSI side (with open-drain) - this will correctly produce TTL levels and keep the current draw under control from the CPLD GPIO - it wasn't necessary on the BeebSCSI design as the CPLD was driving the AVR (so the drive current was 'known' and small).

[dp11]

I think focusing on the at blue trace will help. The two non ground levels are interesting. The 3v level suggests either something is driving to 3v or is being pulled to 3v ( termination ). The drive could have active termination , so more than just resistors. It might be worth zooming in on the rising edge , which will tell you if it is just leakage pulling the signal up. Then understanding the intermediate level I'm sure will give you some clues to what is going on.

[KenLowe]

My guess would be that the additional pull-up/pull-down is causing the 3v3 CPLD output to swing between 0-5V rather than 0-3v3 - if the connected logic is TTL it shouldn't make any difference since the centre-point is 2v5. If the connected logic is CMOS though, 2v5 isn't enough as you need 3v5 to swing high (and 1v5 to swing low). This is a bit of a gotcha when converting 5V TTL systems as they work fine with CMOS levels - but not when you use 3v3. This is an issue with building stuff for both the Master and the Beeb for example - the Beeb is 5V TTL, but the Master is 5V CMOS (if you look at the Master's schematic you'll see additional components on the external ports to 'convert' them to TTL - the internal ports don't have that which is why the BeebSCSI internal adapter is necessary).

So, on the drives, look at the line buffers and see if there is a difference - the part numbers of the 74 series chips usually gives it away, they are different for CMOS and TTL.

The most 'correct' fix would be to add a 5V line buffer IC to the CPLD<->SCSI side (with open-drain) - this will correctly produce TTL levels and keep the current draw under control from the CPLD GPIO - it wasn't necessary on the BeebSCSI design as the CPLD was driving the AVR (so the drive current was 'known' and small).

Thanks for guidance, and as you suggest I do think the issue may be linked to the different logic 1 thresholds, as my working pull ups are tied to 5v. However, what I still struggle with here, is that the CPLD output is meant to be open collector (drain?), so there should be no 3v3 output from the CPLD to fight with. As per the original circuit diagram, I will try driving the signals through some 74LS07 hex buffers to see what difference that makes, but I'll need to order some up first.

Regarding the drives line buffers, I'm not sure what to look for, however the Product Manual states the following:

Code: Select all

Interface signal levels and logical sense at the drive I/O connector for “N,” “W,” and “WC” models are defined as follows:

Vil (low-level input voltage)  = 1.0 V maximum (signal true);  minimum = Vss – 0.5V.
Vih (high-level input voltage) = 1.9 V minimum (signal false); maximum = Vdd + 0.5V.
Vihys (Input Hysteresis) = 425 mV minimum

It's a relatively modern drive:

Seagate ST34371WC

[KenLowe]

I think focusing on the at blue trace will help. The two non ground levels are interesting. The 3v level suggests either something is driving to 3v or is being pulled to 3v ( termination ). The drive could have active termination , so more than just resistors. It might be worth zooming in on the rising edge , which will tell you if it is just leakage pulling the signal up. Then understanding the intermediate level I'm sure will give you some clues to what is going on.

It is active termination on the drive; although I think I've currently got that disabled (I've tried with them both enabled and disabled). I'll disconnect the pull ups and get some more zoomed in traces.

[KenLowe]

I'll disconnect the pull ups and get some more zoomed in traces.

Here's some scope traces showing what happens on reset without pullup on the reset line. This is with active termination enabled on the drive. It's pretty much the same without:
>

Zoomed out

>

On falling edge

>

Zoom in of Rising edge

>

Rising edge - part 1

>

Rising edge - part 2

[KenLowe]

My guess would be that the additional pull-up/pull-down is causing the 3v3 CPLD output to swing between 0-5V rather than 0-3v3.

I've just powered the pull ups via 3v3 instead of 5v, and it's works with either.

The drive could have active termination , so more than just resistors.

It is active termination on the drive; although I think I've currently got that disabled (I've tried with them both enabled and disabled).

I believe my previous statement about active termination was incorrect. Reading through the manual for the Seagate drive again:

“WC” and “DC” models use the single connection attachment (SCA) connector. This 80-pin connector is designed to plug directly into a back panel or plane. No external cables are required. Active terminators on the back panel must be provided by the user.

Even though there are termination jumpers on the drive PCB, I'm not convinced they actually do anything. I'm using a commercially available 80 to 50 pin adaptor at the back of the drive, and if I set a jumper on the drive that is meant to put TermPwr onto the bus, and measure the voltage on the TermPwr pin at the 50 pin connecter, there is no voltage present. So, as described in the manual, it sounds like I need to provide termination on the back panel instead, which is what I have been doing on these 3 control lines to get it working.

Long and short of it all is that I'm now happy there's nothing actually wrong with the host adaptor board !
I'm still not sure why the Viglen board works without pull up on these three lines, though . I suspect it must be marginal.

Edit: I've just checked the manual again, and TermPwr isn't even present on the 80 pin connector at the drive, so it's no surprise that I'm not measuring anything on the TermPwr pin of the 50 pin connector!

Edit2: Here's a photo showing the pull up resistors connected to the back of the 80 to 50 pin adaptor board, and a couple of photos showing my host adaptor connected to this board via my adaptor board. Obviously, this setup is just for test purposes, and I'll likely design a dedicated 80 to 50 pin adaptor board with integral pull up for these 80 pin drives, so that the host adaptor just sits on top of the drive, like it does for my 50 pin drives.

[egel]

In my collection of old SCSI disks I searched for a working disk. I haven't found one yet. What properties should I search for so there is a chance it will work?
What I have found so far that they should be able to have SCSI-1 and 265 bit sectors. Is this correct? Or should the disk have even more properties?
Which drives are known to work?
* Fujitsu M2684SAU?

[KenLowe]

In my collection of old SCSI disks I searched for a working disk. I haven't found one yet. What properties should I search for so there is a chance it will work?
What I have found so far that they should be able to have SCSI-1 and 265 bit sectors. Is this correct? Or should the disk have even more properties?
Which drives are known to work?
* Fujitsu M2684SAU?

What problem do you have with your collection of old SCSI disks? In what way do they not work?

I have been able to interface with Fujitsu M2861SAM, M2682SAM & M2684SAM. These drives work well, however you do need to change them to 256 byte sectors and then low level format them before ADFS will recognise them. I can't recall what the difference is between the SAM and the SAU, but I think I've also successfully interfaced to an SAU drive.

I have also been able to interface with the Seagate ST34371. These drives also work well, but need a few low level SCSI config changes (256 byte sectors, unit attention & SCSI-1) to get them working. Also, if you issue a *BYE command to these drives, they will spin down but will not spin up again until you either power cycle the drive, or issue a low level Request Sense command and then remount the drive. There is a UK ebay seller currently selling some of these at a very reasonable price, but they are the 80 pin versions, so will require a special adaptor to interface with my host adaptor board. I've got some of these on order. See renders below.

Other important points:

• You must be able to disable parity checking. This is normally done by jumpers on the drive.
• You must be able to switch from 512 byte sectors to 256 byte sectors. This is normally done by issuing low level commands to the SCSI drive.
• Must be able to modify Unit Attention behaviour so that the drive doesn't sit in a Check Condition state waiting for a Request Sense command after reset (see viewtopic.php?f=3&t=3272&p=43561#p43561). Again, this is normally done by issuing low level commands to the SCSI drive, but may also be selectable via jumper.
• You can typically only connect one drive, and it must be set to SCSI ID 0. You may be able to add additional drives if you can add them as LUNs.
• The drive must have termination.
• You can only access a maximum of 512MB (&200000 sectors) on the drive, even if the drive has greater capacity.
• The drive must support SCSI-1 operation. Look for drives where this can be selected via low level SCSI Change Definition command or via jumpers.

[KenLowe]

Well, I'm quite pleased with the SCSI 80 pin adaptor board. That's the SCSI host adaptor board now successfully interfaced with the 80 pin Seagate ST34171WC:

Only annoyance is that I chose the wrong PCB footprint for the pull up resistors, so the thru hole spacing for the resistor legs is wrong. That will be fixed shortly with a smaller footprint resistor.