Thanks for taking the time to dig in and open a PR! 256 byte does not get tested as much so glad you were able to test and propose a solution. I'll hopefully have some time to review your PR's in the next few days.

Sorry for the long delay - getting the release ready took longer than I had hoped!

I think the same bug exists in the write() path too, causing an unaligned write.

I wonder if we do this in start_dataInTransfer if it could be a lower level and simpler fix - we could just fall back to the old behavior for non-aligned transfers instead of trying to work around them. Assumption is that any system using 256 byte is likely an older - pre synchronous SCSI anyways so the FastSeek perf change would be negotiable at best.

If you'd like I can put together a draft of what I'm talking about for review and if you could test it I'd appreciate it - let me know and thanks again for digging in!

Yes the main problem is that it uses the lba from the sd-card in direct translation, so it will break for 256 bytes lba like xebec and others

Please welcome to propose an alternative solution

Per

Please give this a try 59e1d3f on branch https://github.com/BlueSCSI/BlueSCSI-v2/compare/eric/fix-256-byte

Thanks.
I will have a try next week since i need to get all equipment back on the table also i need to apply the rest of xebec code on top of your commit, since im testing against the xebec system

Hi Eric

Made some test, but the only system i had avalible is a Xebec system. So applied the other pull request on top of your change. Both read and write works

Per