Ooh, that is great news! Hopefully the net.c cleanup is making your life easier, but if you have suggestions for changes there I'm all ears.
On the hard drive side, I've pushed fixes for several bugs but I haven't gotten the underlying boot issue Chopsticks experienced figured out completely. Here's what I found.
I was asleep at the wheel on several items, including completely breaking 'forcefast' support: it wasn't doing anything at all and was basically an alias for 'normal.' That likely explains the bad performance Chopsticks observed. That should be fixed: forcefast now does what it says on the tin. I also did a code cleanup and made the contiguous check run a bit faster.
For the boot issue, if you sit and wait on the gray screen for several minutes (while, say, you're scratching your head and adding new debugging statements) the system will
eventually boot on a 'mode=fast' drive. This is the error pattern I'm seeing:
- scuznet boots up and does a contiguous check, which clears fine. Mac still has a black screen.
- Mac goes to the gray bootup screen and issues a SCSI /RST. scuznet reboots and begins doing a contiguous check on [hdd1]
- Mac starts asking for data from [hdd1]. scuznet, in between issuing f_lseek() calls for the check, begins returning data. This part seems to go OK, no errors are being reported.
- Mac suddenly stops issuing read requests to scuznet. scuznet is fine with this, and finishes the contiguous checks.
- After a few minutes the Mac returns to asking for data and the boot process resumes.
Watching the timing of events, each time the Mac stops asking is when a significant amount of time (~500-700ms) have elapsed between scuznet driving /BSY low in response to selection and actually starting to send data (the /BSY response is immediate to comply with SCSI timing requirements, but if there is a pending f_lseek() it can take a while to get around to fetching the command bytes). The Mac does not seem to like this at all and stops asking for data for several minutes.
Assuming this delay is what the problem is, I'll need to get into FatFs and hack in a way to short-circuit the f_lseek() call if the SCSI bus is active. I'll look at that tomorrow, then explore what's up with the Nuvolink crashing.
Edit: one other thing: 'raw' mode support has been removed in the latest update to help reduce the complexity of that part of the code. If that's an issue for anyone please let me know.