LUN greater than 0 ignored
netmgr opened this issue · 8 comments
LUN greater than 0 causes the file to be ignored as though it wasn't there
HD11 - test.hda - this is ignored, led flashes 3 times
HD10 - test.hda - this works fine
VER: 1.1-20221203-USB
Am I misunderstanding the naming convention or is there a bug?
Having re-read the statement 'y - LUN ID - Optional but always 0.' I assumed that meant it would default to 0 if omitted, however I now suspect that you just cant have anything other than 0. If this is the case why is it there?
What machine are you? Computer such as Macintosh's do not support LUN's. I actually dont own any machines that do so it's not well tested. We do support them in a special case for the Mega STE.
Hi Eric
This is for the RM Nimbus 80186 - the BlueSCSI works to an extent.
The hard drives are arranged with 2 drives per controller so I can only access the primary drive using the SCSI ID/LUN 0.
If I want to gain the full compliment then 2 of the drives need to be set to SCSI ID/LUN 1
Looking at the Mega ST mode then that changes the LUN ID but leaves the SCSI ID at 0.
The ability looks to be there but would need some re-jigging at the code.
I could perhaps have a go, unless you think this is a quick fix yourself?
Please take a look and feel free to open a PR! I don't have any way to test LUN's so will have to rely on you and @mynameistroy (he's done some with LUN's lately)
So the BlueSCSI has such a limited amount of RAM and as a result the LUNs are generally disabled in order to save on that. At some point when some slimming can be done the adding them back could be a thing. Otherwise modifying the MegaSTE mode or simply enabling access to LUN1 as well isn't too hard.
However doing a little digging shows that it doesn't use LUNs but IDs for each device at least based on what I'm reading here
https://www.thenimbus.co.uk/upgrades-and-maintenance/scsi2sd
I've just gone with upping the number of enabled LUNs in the code and recompiled:
#define NUM_SCSILUN 2 // Number of enabled LUNs
That works perfectly. Was it dropped to a single LUN for memory reasons?
Any problems I might expect with this arrangement?
I'm running the following setup, as you can see two of them are on LUN address 1:
- HD00 Drive C.hda HDD / 42024960bytes / 41040KiB / 40MiB
- HD10 Drive D.hda HDD / 42024960bytes / 41040KiB / 40MiB
- HD20 Drive F.hda HDD / 42024960bytes / 41040KiB / 40MiB
- HD11 Drive E.hda HDD / 42024960bytes / 41040KiB / 40MiB
- HD21 Drive G.hda HDD / 42024960bytes / 41040KiB / 40MiB
ID:LUN0:LUN1:
0: 512:----:
1: 512: 512:
2: 512: 512:
3:----:----:
4:----:----:
5:----:----:
6:----:----:
@mynameistroy The link you have given indicates an issue with addressing the 2nd drive, its now clear that this is due to the need to address LUN 1 - I don't think SCSI2SD (as used in the example) has this flexibility whilst retaining control of the SCSI ID like bluescsi does (once enabled in the code).
Link quote:
Unfortunately the way in which the device adds drives, it does so on a 'per controller, 1st drive' basis
The Nimbus has it hard coded that the 2nd external drive must be on the 2nd drive of Controller 1.
This renders the 2nd external drive (E:) unusable, you do however get C: D: & F:_
Indeed it was lowered for memory reasons and just general lack of need. Rare cases such as this one aren't very common so saving the memory at the time considered the way to go.
It uses about 2% more RAM and average RAM usage depending on platform is around 64% so still lots of room really even if debugging is enabled.
I don't expect you'll have any issues and it's very likely LUNs will come back at some point by default.
Thanks getting this resolved