SCSI2SD v6 on A2000 GVP Combo 030 25Mhz

[Irl]

I had a lot of trouble piecing all of the information I needed together, so I want to summarize everything here for others.

My A2000:

Rev 6 Motherboard
Kickstart 3.x
Gotek as DF0
Chinon 3.5" as DF1
MegaChip 2Mb
Indivision ECS
A2286 Bridgboard
SupraRAM with 8MB (Configured to 6MB by jumpers)
GVP Combo 030 Rev 4 with 4.15 ROM and 13MB RAM
SCSI2SD
VideoToaster ("2000")
X-Surf 100

Termination:

Note: Do not mix Active and Passive termination, it won't harm anything but it will cause many errors. Also, Active is better than passive if you are deciding between the 2. The SCSI2SD V6 has Active termination with termination power.

• IDC50 Active Internal 50-Pin Male SCSI Terminator for Ribbon Cables - ST-502
• This IDC50 Active Terminator did not work with my setup.
  
• DB25M, SCSI Terminator, Active
• The DB25M Active Terminator worked great.

SCSI configuration that worked:

• Removed the 2 resistor packs from the GVP Combo 030
• Installed the DB25M Active Terminator directly to the external port of the GVP (No cable, this replaces the passive termination resistor packs with an active terminator to match the active termination in the SCSI2SD)
• Currently using a 3 ended cable with the middle unused and the the GVP and SCSI2SD V2 on the other end.

Crude diagram :
DB25M-AR=|GVP=====EMPTY=====SCSI2SD

Configuration of SCSI2SD V2:

Important Notes:

I have a 16GB SD Card. This means (roughly) 16,000,000,000 bytes which is 14.90116119384766 GB to computers. This is because, to a computer, 1024B =1K, 1024K = 1M, 1024M = 1G and so forth.
Here is the equation for this calculation (Assumption of GB sized device:
N=Size in bytes of storage device
((N/1024)/1024)/1024=Size a computer will see.

Why is this important?
A.) When I attempted to use my SCSI2SD as 4x4GB partitions, the last partition would always show up as unsupported in HDInstTools. If I came in at 14GB or less, it would allow me to use the last virtual drive on the SCSI2SD. (This is an educated theory of why this happened, I did not get this answer from the creator of SCSI2SD)

General:

• Enable SCSI terminator ON
• Startup Delay 0
• SCSI Selection Delay 0
• Enable Parity ON (Thanks mark_k)
• Enable Unit Attention On (Thanks mark_k)
• Enable SCSI2 Mode ON
• Enable disk cache ON
• Enable SCSI Disconnect OFF (ON may be better with multiple SCSI devices. Thanks mark_k)
• Respond to short SCSI selection pulses ON
• Map LUNS to SCSI IDs OFF

Devices:
These settings are mostly preferences. I saw many times to avoid making the boot drive larger than 2GB.
Under "SD card start sector" ALWAYS enable the "Auto" feature.
Sector Size should remain 512B

What is my setup?

DH0 = 2GB (Workbench)
DH1 = 3GB (Software)
DH2 = 3GB (Files)
DH3 = 3GB (Backup)
DH4 = 3GB (BridgeBoard) (Somewhere to put hardfiles, etc)
Total size = 14GB

[wmaciv]

See thread below for my (similar) discoveries with the v6. I too found that keeping the drives at 3gb on a 16GB card avoided the dreaded "last drive" problem with HDTools.

I have just now tinkering with my GVP combo 030 rev4 and will see how that works out. Already, just plugging it in and leaving the A2091 as the HD controller with half (8MB) of the GVP combo RAM mapped into the ZII address space and the A2091 RAM jumpered to zero MB (off), I am just shy of 3 MB/sec transfer.

Not sure how much of a boost tying the v6 directly to the accelerator SCSI port will provide above that.

Mac

http://www.amibay.com/showthread.php...V6-board/page3

[mark_k]

Originally Posted by Irl

• Enable Parity OFF
• Enable Unit Attention OFF
• Enable SCSI Disconnect ON
• Respond to short SCSI selection pulses ON

Now you have things (mostly) working it might be a good idea to change some of those settings. I would set parity to ON (otherwise data transfer errors might occur silently), unit attention ON (off would be used if you were using the SCSI2SD with an old Macintosh Plus). Since you only have one SCSI device, you could set enable scsi disconnect to OFF.

Could "respond to short selection pulses" being OFF improve compatibility with different terminators etc.?

Regarding drive capacity, instead of guessing at the exact drive size, use a program like SCSIUtil or SCSIQuery to tell you the exact number of sectors. Then you can ensure the fake geometry which HDToolBox uses covers the entire drive and no more.

[wmaciv]

Okay, just updated to 6.1 firmware; no issues updating, but lost significant speed on the A2091/GuruROM setup. Went from almost 2.95 MB/sec to 2.35. Not sure what happened, but probably going back to 6.0.13 for the time being.

Mac

[Marchie]

This is covered in my other thread, but since you guys seem to know what you're doing - I'm encountering wildly different drive sized between the utility and the Amiga, there seems to be a vague correspondence between the number of cylinders my HD prep utility sees and the size of the drive, but nothing like what what I've configured on the PC (eg: 4gb = 124mb).

Is there somewhere I can read-up on cylinders, sectors, etc. and how they are interpreted by the Amiga (or the SD card adapter?)?

Sorry if these are stupid questions, sometimes I think I'm the only person on this forum without a degree in electrical engineering...

[Irl]

Originally Posted by mark_k

Now you have things (mostly) working it might be a good idea to change some of those settings. I would set parity to ON (otherwise data transfer errors might occur silently), unit attention ON (off would be used if you were using the SCSI2SD with an old Macintosh Plus). Since you only have one SCSI device, you could set enable scsi disconnect to OFF.

Could "respond to short selection pulses" being OFF improve compatibility with different terminators etc.?

Regarding drive capacity, instead of guessing at the exact drive size, use a program like SCSIUtil or SCSIQuery to tell you the exact number of sectors. Then you can ensure the fake geometry which HDToolBox uses covers the entire drive and no more.

Hey, thanks! I will try changing those settingst. While I was sorting out the other issues, those settings either seemed to have either no effect or were more stable while the termination was mixed (active and passive).

The size issue seemed to be reflected in the SCSI2SD utility. It appeared that the utility is measuring the size in powers of 2 whereas the SD is labeled as 16GB calculated in powers of 10. So, If I tried to use more than 16,000,000,000 bytes on the card, the last "drive" would not be usable. And to the scsi2sd utility in windows, 16GiB would be 17179869184 bytes.

This is a common issue on modern systems and is why formatting a 250GB drive results in ~232GiB partition.

[Irl]

Originally Posted by Marchie

This is covered in my other thread, but since you guys seem to know what you're doing - I'm encountering wildly different drive sized between the utility and the Amiga, there seems to be a vague correspondence between the number of cylinders my HD prep utility sees and the size of the drive, but nothing like what what I've configured on the PC (eg: 4gb = 124mb).

Is there somewhere I can read-up on cylinders, sectors, etc. and how they are interpreted by the Amiga (or the SD card adapter?)?

Sorry if these are stupid questions, sometimes I think I'm the only person on this forum without a degree in electrical engineering...

As they say "there are no stupid questions"..

This Wiki article does a decent job explaining how they work on real disks: https://en.wikipedia.org/wiki/Cylinder-head-sector (Excerpt: (512 bytes/sector)×(63 sectors/track)×(255 heads (tracks/cylinder))×(1024 cylinders)=8032.5 MiB)

Where the SCSI2SD is concerned, these values are whatever is acceptable by the host (Amiga) and will add up to the total size of the drive. Keep the bytes per sector at 512. This calculator might help: http://www.csgnetwork.com/mediasizecalc.html

[Irl]

Originally Posted by Marchie

sometimes I think I'm the only person on this forum without a degree in electrical engineering...

I don't have any engineering degrees, but I work in IT and like to tinker with electronics.

[grelbfarlk]

Originally Posted by wmaciv

See thread below for my (similar) discoveries with the v6. I too found that keeping the drives at 3gb on a 16GB card avoided the dreaded "last drive" problem with HDTools.

I have just now tinkering with my GVP combo 030 rev4 and will see how that works out. Already, just plugging it in and leaving the A2091 as the HD controller with half (8MB) of the GVP combo RAM mapped into the ZII address space and the A2091 RAM jumpered to zero MB (off), I am just shy of 3 MB/sec transfer.

Not sure how much of a boost tying the v6 directly to the accelerator SCSI port will provide above that.

Mac

http://www.amibay.com/showthread.php...V6-board/page3

Unfortunately the SCSI on the GVP Combo 030, 040 cards is pretty slow. On a good day they'll hit 2MB/s.

[mark_k]

Apparently so. But they can DMA to the on-board 32-bit RAM (which you can configure to sit outside the lower 16MB address space), so it's still worth using it in preference to a Zorro II controller in that case.

[mark_k]

Originally Posted by Marchie

This is covered in my other thread, but since you guys seem to know what you're doing - I'm encountering wildly different drive sized between the utility and the Amiga, there seems to be a vague correspondence between the number of cylinders my HD prep utility sees and the size of the drive, but nothing like what what I've configured on the PC (eg: 4gb = 124mb).

Is there somewhere I can read-up on cylinders, sectors, etc. and how they are interpreted by the Amiga (or the SD card adapter?)?

Modern drives (in fact all SCSI drives) are accessed in terms of sectors. For example your drive capacity could be 12345600 512-byte sectors (numbered 0 to 12345599). To read some data, the computer could issue a READ command for 12 sectors starting at sector 3020, for example.

The actual physical layout of cylinders, sectors and number of heads of the drive isn't visible to the computer. But as a kind of historical artifact, when specifying partitions using a mount file (or in the disk RDB area) the Amiga needs (fake/arbitrary) geometry values. The fake geometry values have to satify this:
(number of cylinders) × (number of tracks) × (sectors per track) <= total number of sectors

HD prep software should choose roughly-good-enough fake geometry, but that may not cover the entire drive, leaving some unused sectors at the end. (With HDToolBox, clicking Read Configuration should do that.)

What may be relevant to the "wildly different" drive sizes you mention, is a 4GB wraparound problem. If the prep software works with byte sizes (as opposed to number of sectors), it can get confused if the drive size if over 4GB (or even 2GB). For example, if your actual drive size is 7GB, the prep program may think that the drive size is 3GB (since the calculation "wrapped around" at the 4GB point) and generate fake geometry values accordingly.

So I think it's best to manually specify the fake geometry. That way you can be sure it covers the entire drive. (As I mentioned above, use SCSIUtil or SCSIQuery to print the actual number of sectors in the drive, then you can figure out suitable values for cylinders, heads and sectors per track.)

[Marchie]

That's both enlightening and helpful, thanks mark_k

[blatboy]

This is great info. I wasn't able to get >4GB drives to work at all on my A3000... regardless if the drive was at the end of the card or not. (Thread) In the end I may use a CF card solution. However, this info does give me more fodder for testing. Thanks

[Irl]

Originally Posted by blatboy

This is great info. I wasn't able to get >4GB drives to work at all on my A3000... regardless if the drive was at the end of the card or not. (Thread) In the end I may use a CF card solution. However, this info does give me more fodder for testing. Thanks

I was able to setup a single 14GB SCSI2SD drive before I moved on to splitting it up. Workbench* was able to show the correct drive size in the title bar of the drawer, but HDInstTools showed the size as a negative value. I opted to split the drive into smaller chunks to avoid issues with any older applications I may use. I also have one of them formatted FAT for use with my A2286 (Still need to get an OS for it).

*Workbench 3.1 using 3.x (45.064) Kickstart

[thebajaguy]

A couple of items to keep in mind for the GVP controllers (and a number of others from the past era):

The FastROM (3.x/4.x) drivers will behave with up to <4GB disks. Step over the 4GB line and you will have wrap problems with the block numbers of the SCSI target. Because of the next issue, file systems, I recommend 'slicing' up any larger flash media in the PC setup tool for 2GB pieces. In any case, I recommend making the first slice, and partition, 2GB to boot from.

If you have plans to use a file system that addresses beyond the classic FFS limit of 2GB, keep the actual disk 'slice' under 4GB unless you have access to GuruROM v6.11 or newer, which can go beyond the 4GB device size. This would naturally apply to the A2091 version of the GuruROM, too, or any known revisions of C= scsi.device that have been properly updated for the same reason. I defer to other experts when it comes to patching or updating a Kickstart ROM-based scsi.device driver like that.

Classic FFS partitions should be kept to <2GB due to signed 32-bit integer limits in the original code. If you have an updated FFS that can handle beyond that (Read about TD_64 extensions that were proposed and implemented by 3rd parties years since). Be sure it doesn't get contaminated with an older version on a boot floppy when you make changes. In any case, don't go beyond a 4GB partition unless you also have the underlying driver able to go beyond 4GB SCSI block counts.

Use of PFS or SFS, which have >2GB functionality, I will defer to other people with more experience, and their docs. I would only caution going >4GB on a controller driver that isn't able to - you are in danger of experiencing integer wrap problems if the file system requests a block over 4GB.

On older GVP v1.98 FastPrep disks, there is the Expert mode of the tool that allows one to tick the Sync mode flag. There are other RDP tools that can do it too. For GuruROM, and any board that supports Sync transfers, that rdb flag is typically needed to be able to negotiate above Async SCSI. The GuruROM has a tool (similar to GVPSCSICtrl) called OmniSCSICtrl (IIRC) with an option to turn on Sync negotiation with a target manually. It would be advisable to also make sure Disconnect/Reconnect is enabled if you are using more than one device on the cable.

Another item to be aware of is the disk partitioning tools are also mostly 32-bit integer-based, and going beyond 2GB or sometimes 4GB on a partition will result in wrap-around. Know the capabilities of your RDB/Partitioning tools before you go over 4GB. HDToolBox I believe has been updated to handle it in a later version. GVP FastPrep won't be good to use on partitions over 2GB.

RDB Last Disk and Last LUN flags are important for some drivers. It's the flag that a driver may interpret, at boot time, whether to look further up the numeric chain for devices. Most drivers scan device ID 0, starting at LUN 0, then LUN 1, LUN 2, etc... Then on to ID1, and scan LUNs, etc, until stopping after finishing ID 6. Setting the Last Disk stops the scan at that SCSI ID. Setting the Last LUN stops the scan at that LUN. Most of the time, drives with no LUNs are actually LUN 0. Adapter boards may implement LUNs. Setting the flag is suggested in many cases to speed up boot time (time to scan the bus for drives, devices, and partitioning), but up to the driver as to how long to wait for timeout. FastROM supports the flags. GuruROM I believe ignores them (come back later with the OmniSCSICtrl tool to find/mount/modify them). Older scsi.device ROMs tended to not be willing to address any devices at addresses after encountering the flag (newer version behavior I have no experience with).

I hope that helps with some understanding of what is at play.

[Irl]

Originally Posted by thebajaguy

A couple of items to keep in mind for the GVP controllers (and a number of others from the past era)...

Very good information! I also recommend PFS. One thing that is often over-looked when attempting to setup PFS is that, while you use HDInstTools to get the drive RDB and partitions prepared, you need to use the tool pfsformat to format, or you will end up with PFS in your RDB but FFS format laid on the partition.

Most of the PFS guides I saw simply talked about setting up RDB and partitons and then casually say to format the drives without noting that pfsformat must be used.

[Jope]

Originally Posted by Irl

Most of the PFS guides I saw simply talked about setting up RDB and partitons and then casually say to format the drives without noting that pfsformat must be used.

I just use sys:system/format with the quick option when I do a pfs3 disk. Pfsformat is handy for setting filename sizes and the sort. I usually just go for the defaults there, so the 3.1 format has served me well.

[idrougge]

PFSformat does not have to be used; all Amiga filesystems can be formated using the standard Amiga format command (at least if you specify quick format). What PFSformat and SFSformat do is allow you to specify filesystem specific settings such as whether to have a .recycled directory and its name.

[Irl]

Originally Posted by idrougge

PFSformat does not have to be used; all Amiga filesystems can be formated using the standard Amiga format command (at least if you specify quick format). What PFSformat and SFSformat do is allow you to specify filesystem specific settings such as whether to have a .recycled directory and its name.

Good to know. I was using the Check4GB tool because it showed the filesystem and it kept showing the PFS partition as FFS. That is why I thought this was the case. After I used the PFSFormat tool, Check4GB showed it as PFS.

[thebajaguy]

I'm going to add one more item into my GVP notes up above that I forgot to include. Always go with the full Mask value (0xFFFFFFFE), at partition prep time, as the gvpscsi or omniscsi driver knows how to handle DMA to RAM both on the GVP accelerators (and other accelerators), and Zorro II boards. To have anything less will hurt performance. The only times one may have problems is if the RAM is AddMem'd, and doesn't support DMA, and gets placed into the Zorro II RAM space. <br />
<br />
The driver (below the file system level) is the most efficient and reliable way to handle non-DMA supported memory ranges. Mask is a kludge at the file system level (if the file system supports it) that still doesn't fix non-DMA-capable RAM access during direct-SCSI communications (like when you are prepping a boot block, checking for disk changes on removables, tape drives, and possibly emulators that might have their own media layout on a target SCSI ID).