• Please review our updated Terms and Rules here

SCSI2SD question

tradde

Veteran Member
Joined
Apr 30, 2003
Messages
2,137
Location
Katy, Tx
I am going to post this here as it has to do with my pdp-11/84. I have an older SCSI2SD board (green v3.0). It works fine with the 5.0 firmware. Yet, I can't seem to get it to save new settings.
I have not played with this in some time, so have likely forgotten how. I tried some things, but they do not take. After quitting SCSI2SD or unpowering the old settings come back. The newer v6 does not even see my card. Trying to move the SCSI id's down as I am using a real HD with 4 (2GB partitions?) on the SCSI2SD. I "saved" the setttings to an XML file. Then tried to load from there. Wrote to the hardware and I see a nice progress in the status box. But still my settings do not save. Maybe this was a bug back in the day of the "green" boards? I do not know. What I am trying to do is to write my MSCP image from being created by xxdpdir.pl from AK6DN (thank you). It boots on Simh and XXDP runs. So I think the image is good. Running the OKDAG0 diag fails as expected as Simh doesn't "do" cache. So I wish to write this image to a real SCSI disk (2GB). My newer machines do not easily allow plugging in an older PCI Adaptec card. I had one machine where it worked with an PCI adaptor. But on my current machine it plugged in and the system booted, but the mouse was non functional which was really odd. I assumed it was some IRQ conflict. So now putting the Adaptec into my old Gateway-2000 and trying to install Slackware 12. I got it to boot, but did not qet a prompt to install to a HD. The Gateway normally has FreeDOS installed and I doubt it can DD an image. Thanks for any suggestions for the SCSI2SD.
 
I have a SCSI2SD v3.0 board attached to the UC17 UNIBUS SCSI controller in my 11/34.
I use firmware v4.8.4 on it and the 32b utility program runs fine on my WinXP system to control it thru the USB bus interface.
On the 11/34 I have it set for four scsi IDs, 0-3, and it has partitions for unused/testing, RSTS/E, RT11, and XXDPv25, of various sizes from 32MB to 1GB.
The populated partitions boot and run fine.

I keep the WinXP machine around because my Adaptec PCI SCSI card works under XP and I can talk to SCSI drives using CYGWIN 'dd' to copy images.
Not for the SCSI2SD card per se, but for a disk box that I also use that has three seagate 2GB spinning magnetic scsi drives and a scsi CDROM drive.
The three scsi drives have images for 2.11BSD (for my 11/44, not the /34), RSTS/E, and RT11. The CDROM is basically the XXDPv25 RL02 image converted to MSCP.
 
Last edited:
Oh, the SCSI2SD software runs find on my Mac. But the settings I change are not saved. I too have this board to use on my 11/84 with a UC17. Always worked fine. But I never enabled more than the first partition. I figure why not use all 4. Then I can put BSD 2.11 on one and RSTS on another. And have 2 more for other things. But right now I am trying to solve my cache error by setting up XXDP. I no longer have a Windows box. I prefer Linux. But my primary Linux box is new. I dumbly got rid of the old Linux box I had 4 or 5 years ago. Didn't think I was going to be using it. How wrong I was.
 
Weird, when I try to use it it sees all 4 partitions when I boot the PC. Maybe it will always see 4? But only 1 shows as enabled in the SCSI2SD tool. Not quite to the point where I am ready to dump something to it to find out. My old PC is being a real pain installing an older Linux. This PC only has 32M. But Slackware 12 installs live and runs fine. But on trying to copy it to a disk it fails in weird ways. First I had to set the boot option to "huge.s" for the memory it has. That worked. But on running SETUP to actually copy to disk it mostly fails to find the CD drive that is booted from. This is weird. And after it failed the CD drive would not even open on pushing the button. But on a restart the drive opens just fine. Looks like I will have to try another PC. But I will have to put one together from spare parts for this. I will look at this thread that you mentioned. Thank you.
 
Something else to consider ... http://zuluscsi.com/

I have both v1.1 and RP2040 variations of cards and find them much easier to use than the original SCSI2SD.

The file storage is on FAT32 SD/microSD cards, and you are just copying files around rather than allocating disk blocks yourself.
 
Something else to consider ... http://zuluscsi.com/

I have both v1.1 and RP2040 variations of cards and find them much easier to use than the original SCSI2SD.

The file storage is on FAT32 SD/microSD cards, and you are just copying files around rather than allocating disk blocks yourself.

And there is no setup application per se. Just an .ini file on the SDcard that you edit with any old text editor to change the default behavior.

The only thing I don't like is the requirement that files associated with SCSI IDs must be named like HDn.img where n is the SCSI ID 0..7.

That's ok for a default behavior when running with no configuration file, but under each [SCSIn] block in the config file why can't I have an IMAGE = "my_file_name.dsk" type of config, rather than having to rename my meaningful filenames to some emulation specific nonsense.

Oh well, the source is on GITHUB, so ...
 
Now you're talking. I don't mind the GUI but it is a pain to get set up right. I will look into a ZULU SCSI. Hmmm, maybe that could be easily changed. Is kind of odd to be that kind of requirement for name.
 
Now you're talking. I don't mind the GUI but it is a pain to get set up right. I will look into a ZULU SCSI. Hmmm, maybe that could be easily changed. Is kind of odd to be that kind of requirement for name.

Looking at the source it is probably possible, because multiple image file names are possible for CD type devices (ie, IMG0=, IMG1=, etc) and it cycles thru them on each eject command.
But the default code makes a lot of assumptions about the device type and SCSI id/lun assignment based on the leading characters of the filename...
It appears that code is leveraged from the 'BlueSCSI' project, and that is the way it was done there...

I did I sort test and found performance of the RP2040 version on my 11/34 with UC17 to achieve about 10,000 blocks read in 10 sec, or about 512KB/sec.
That is about 50% faster than I can get with my SCSI2SD v3.0 on the exact same hardware (is about 6,500 blocks read in 10 sec).

Haven't gone in a tried to reconfigure the UC17 yet thru it's command interface, a project for another day.
 
And there is no setup application per se. Just an .ini file on the SDcard that you edit with any old text editor to change the default behavior.

The only thing I don't like is the requirement that files associated with SCSI IDs must be named like HDn.img where n is the SCSI ID 0..7.

That's ok for a default behavior when running with no configuration file, but under each [SCSIn] block in the config file why can't I have an IMAGE = "my_file_name.dsk" type of config, rather than having to rename my meaningful filenames to some emulation specific nonsense.

Oh well, the source is on GITHUB, so ...
I could have sworn the file names only have to start with HDn followed by maybe one other char or string for block size, but then could contain the rest of filename could be an arbitrary name before the extension.

Edit: post above kind of covers this, sorry if this is wholly redundant.
 
I could have sworn the file names only have to start with HDn followed by maybe one other char or string for block size, but then could contain the rest of filename could be an arbitrary name before the extension.

Edit: post above kind of covers this, sorry if this is wholly redundant.

Mayne, dunno. Have not tried that. Documentation indicates the form is like XXnu_bbb.img, where XX is HD or CD etc, n is SCSIID, u is LUN, bbb is blocksize.
If u or bbb is not supplied they default to '0' and '512'. Filename is stored in a char[64], so it is 64 char max incl extension.
Maybe random characters after the (optional) _bbb are ok. Have not tried that. Will have to read some more code ...
 
Mayne, dunno. Have not tried that. Documentation indicates the form is like XXnu_bbb.img, where XX is HD or CD etc, n is SCSIID, u is LUN, bbb is blocksize.
If u or bbb is not supplied they default to '0' and '512'. Filename is stored in a char[64], so it is 64 char max incl extension.
Maybe random characters after the (optional) _bbb are ok. Have not tried that. Will have to read some more code ...

Well it looks like the random file name characters after the leading HDn_512_ don't matter, so they can be user friendly ...
Code:
[10ms] Platform: ZuluSCSI RP2040
[10ms] FW Version: 23.04.11-release Apr 11 2023 16:09:22
[11ms] DIP switch settings: debug log 0, termination 1
[11ms] SCSI termination is enabled
[12ms] Flash chip size: 2048 kB
[14ms] SCSI target/disk mode selected by DIP switch, acting as a SCSI disk
[23ms] SD MID: 0x74, OID: 0x4A 0x45
[23ms] SD Name: USD
[23ms] SD Date: 7/2014
[23ms] SD Serial: 0x45847FA6
[26ms] Reading configuration from zuluscsi.ini
[27ms] Active configuration:
[27ms] -- SelectionDelay = 255
[28ms] -- EnableUnitAttention = Yes
[28ms] -- EnableSCSI2 = Yes
[29ms] -- EnableSelLatch = No
[30ms] -- MapLunsToIDs = No
[31ms] -- EnableParity = Yes
[134ms] Finding HDD images in directory /:
[135ms] -- Opening /HD0_512_2.11BSD_1144_ra72.dsk for id:0 lun:0
[197ms] ---- Read prefetch enabled: 8192 bytes
[197ms] -- Opening /HD1_512_RSTSv96_1144_ra81.dsk for id:1 lun:0
[225ms] ---- Read prefetch enabled: 8192 bytes
[226ms] -- Opening /HD2_512_RT11v53_ra81.dsk for id:2 lun:0
[265ms] ---- Read prefetch enabled: 8192 bytes
[266ms] -- Opening /HD3_512_XXDPv25_rl02.dsk for id:3 lun:0
[269ms] ---- Read prefetch enabled: 8192 bytes
[275ms] -- Platform supports ROM drive up to 1692 kB
[276ms] ---- ROM drive image not detected
[276ms] SCSI ID:0 BlockSize:512 Type:0 Quirks:0 ImageSize:976609kB
[277ms] SCSI ID:1 BlockSize:512 Type:0 Quirks:0 ImageSize:445536kB
[278ms] SCSI ID:2 BlockSize:512 Type:0 Quirks:0 ImageSize:307200kB
[278ms] SCSI ID:3 BlockSize:512 Type:0 Quirks:0 ImageSize:10240kB
[379ms] Initialization complete!
 
Last edited:
Don, thanks for the note about the ZuluSCSI working with a UC17. I have a UC07 and I suppose this ZuluSCSI would be fine with it?
 
The few times I have had issues with ZuluSCSI on picky systems, the development / support has always taken my debug logs and fixed the issue or advised. Definitely a solid product.
 
Don, thanks for the note about the ZuluSCSI working with a UC17. I have a UC07 and I suppose this ZuluSCSI would be fine with it?

I have a couple of those also, they work fine. Better price on their web store page vs eBay, tho:
Whoops, sorry, maybe not for you. You are in Australia where shipping cost is an issue. So maybe better, or not. Don't know how eBay vs their web page handles the shipping.

Best deal for US buyers tho is thru their website.
 
Last edited:
Wow... these are affordable.. I just ordered a Zuluscsi to keep around if needed. under $60 shipped for the solder your own.
And now there's a kit-based variant of ZuluSCSI RP2040, ZuluSCSI Compact Homebrew that costs even less

ZuluSCSI RP2040 delivers up to 9.5MB/sec of throughput on reads, and around 6MB/sec for writes, significantly faster than the SCSI2SD V5 family, at a lower price point.
 

Attachments

  • ZuluSCSI-Compact-Homebrew-KIT-2.jpg
    ZuluSCSI-Compact-Homebrew-KIT-2.jpg
    857.7 KB · Views: 9
Back
Top