• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

SCSI to Ethernet Adapter on New Hardware

superjer2000

Well-known member
this is smiler to the issues ive had, firstly do double check you solder connections and make sure all the flux is gone. as for the sdcard I formatted mine as MBR Fat32 in my modern computer then I reformatted it with scsi director 4 fwiw. what brand sd card are you using, might be worth trying another card just to rule that out.


Last question - where did you get your PCBs? I'm assuming it's not the case but there could be an issue with the PCB.  I got mine from  @switch998 was kind enough to print and mail out the extras- it looks like he got his assembled - @switch998 did your board(s) end up working without issue, including with AppleTalk?

 

Chopsticks

Well-known member
Thanks. I’ll give this a try although when I was playing around with it yesterday it seemed like I wasn’t getting any network activity (even over tcp) unless AppleTalk was  turned on over Ethernet.  Now that was on my SE30 that had an internal nic so ,habe there was an issue there.  
 

in an earlier message you indicated you had it working on a IIci. Did I read that correctly?  I’m trying to figure out if this issue is a compact Mac thing or not.  I haven’t pulled out a non compact Mac to test yet. 
I had one working with ftp originally but after further testing I discovered the issues I now have. at the time I was only transferring files around 1-4mb in size. only tried on a couple se/30's ill have to read back over my notes and forum posts to see if I tried it with the iici logic board I have around here as I can't remember if I did or didn't to be honest

Last question - where did you get your PCBs? I'm assuming it's not the case but there could be an issue with the PCB.  I got mine from  @switch998 was kind enough to print and mail out the extras- it looks like he got his assembled - @switch998 did your board(s) end up working without issue, including with AppleTalk?
I had to seperate runs of pcbs made, I used JLCPCB both times, but I do get a fair amount of different circuitboards made through them the last couple years if not longer. ive never had an issue with any of the pcbs made so far so I guess its possible they goofed something up in fabrication but as I got new boards made a couple months later at this point I don't think there is a issue with that.

 

superjer2000

Well-known member
@Chopsticks  thanks for all this. I’ve started  with the logging process and have put in some of my own debugging  messages to help figure out what’s happening. I’ll report back once I have a better idea what is happening. 

 

superjer2000

Well-known member
If I remember correctly, it was a soldering issue. There were a couple pins bridged.


Thanks - I think that is going to be at least part of my issue as well.

I started playing with the firmware a bit to put in other debug points to see where things aren't working, starting with the SD card.  The board is failing to initialize after its 250 tries which prompted me to download kicad so I could open up the schematics / board layout and check the signals to the SD card which all seem to just tie in to the ATxmega other than power/ground.  Probing there seems to indicate I have a bridge between Pins 43 (SD_MOSI) and 44 (Ground) on the ATxmega, although I cannot see it with my magnifying glass it's gotta be there as there is a short on those two pins. 

I'm generally used to not having any soldering issues so this is a bit of a surprise but that being said, going through and troubleshooting my mistakes here will be fun.

Once I get that sorted, I'll keep plugging away at the ethernet freeze issue - To ease troubleshooting, I swapped out the binary debugging codes with single characters so I can more easily monitor what is happening as it's happening.

 

Chopsticks

Well-known member
@Chopsticks  thanks for all this. I’ve started  with the logging process and have put in some of my own debugging  messages to help figure out what’s happening. I’ll report back once I have a better idea what is happening. 
no worries, let me know if you find anything and/or have any other tests you think are worth doing. i make a lot of pcb's and deal with surface mount soldering almost daily as well as a lot of restoration/repair work so i've been very stumped as to the cause and really just want to figure out what the issue is

 
Last edited by a moderator:

saybur

Well-known member
Well, this is different.

Right off the bat, I want to acknowledge how much help I've received with this project over the last few months, particularly from @Chopsticks and @superjer2000. Many of the vanished posts in this thread contained feedback given while graciously testing my red-hot code. It's a shame that there isn't a history of it, but for anyone coming along I just wanted to say how much I've appreciated the discussions and contributions.

During the forum downtime I've been continuing to work on this project. I wanted to post the important user-facing items:
  • The networking code has received a much needed facelift, which included the squashing of several big ENC28J60-related bugs. This appears to have improved stability with the Nuvolink emulation. I'm very interested in seeing if someone was willing to try this out on their SE/30 and report back with their experiences.
  • The contiguous check for 'mode=fast' has been changed to operate in the background. Until it clears, the file can continue to be accessed via the FAT filesystem, so these volumes can now be booted reliably. I've stopped using 'forcefast' here due to this change and have been pretty happy with the results, FWIW.
  • The offline self-test code has been integrated into the main firmware and can be triggered with 'selftest=yes' in the [scuznet] section.
  • I've opened up the wiki on Github and started documenting more aspects of the project. If there are things that need to be added or cleared up, please let me know. I'm way too far into the weeds right now to have a good sense if what's up there now is remotely sufficient (or helpful), and I'm guessing that more information is sorely needed.
There were many other lower-level changes, but I'll leave that to the Github commit log rather than cluttering this thread. If any change is of particular interest, I'm happy to discuss it.
 

Chopsticks

Well-known member
Well, this is different.

Right off the bat, I want to acknowledge how much help I've received with this project over the last few months, particularly from @Chopsticks and @superjer2000. Many of the vanished posts in this thread contained feedback given while graciously testing my red-hot code. It's a shame that there isn't a history of it, but for anyone coming along I just wanted to say how much I've appreciated the discussions and contributions.

During the forum downtime I've been continuing to work on this project. I wanted to post the important user-facing items:
  • The networking code has received a much needed facelift, which included the squashing of several big ENC28J60-related bugs. This appears to have improved stability with the Nuvolink emulation. I'm very interested in seeing if someone was willing to try this out on their SE/30 and report back with their experiences.
  • The contiguous check for 'mode=fast' has been changed to operate in the background. Until it clears, the file can continue to be accessed via the FAT filesystem, so these volumes can now be booted reliably. I've stopped using 'forcefast' here due to this change and have been pretty happy with the results, FWIW.
  • The offline self-test code has been integrated into the main firmware and can be triggered with 'selftest=yes' in the [scuznet] section.
  • I've opened up the wiki on Github and started documenting more aspects of the project. If there are things that need to be added or cleared up, please let me know. I'm way too far into the weeds right now to have a good sense if what's up there now is remotely sufficient (or helpful), and I'm guessing that more information is sorely needed.
There were many other lower-level changes, but I'll leave that to the Github commit log rather than cluttering this thread. If any change is of particular interest, I'm happy to discuss it.
thanks for the kind words,
I'll test out the new firmware, just to clarify though, "mode=normal" replaces 'mode=fast' and checks if the hdd image file is contiguous and if so switched to raw access? im assuming that 'mode=fast' and 'mode=forcefast' are no longer valid arguments in scuznet.ini?
 

saybur

Well-known member
All three are still supported, like so:
  • "normal" accesses through the FAT filesystem only. Highest compatibility, but slow with larger cluster sizes (particularly on FAT32).
  • "fast" is low-level access bypassing the FAT filesystem, but only after the continuity check clears: before that it acts just like "normal," just slightly slower while the background check is running. If the file is fragmented the continuity check will fail and it will switch to using FAT only.
  • "forcefast" goes right to low-level access. If the file is contiguous, this is fine. If the file is fragmented, Bad Things will happen.
These options should really be named "slow", "default", and "dangerous", in that order :) I've switched to using "fast" for everything.

The "raw=XXX:YYY" option is still in the firmware too, but per the disappeared post I'll probably remove it in a future update unless someone really wants to keep it around.
 

Chopsticks

Well-known member
so ive tried out the new firmware with the nuvo emulation enabled but I still get the freeze in fetch with a movable mouse pointer and reseting the Mac required a power cycle on the scuznet fo hit to see the hdd to boot from.

also the hard drive emulation is very sluggish, I have a 2gb hdd.img file and I have to use mode=forcefast to get it to boot, I when I use mode=fast I don't actually get the Mac past a grey screen on power up, I never seems to get the the 'floppy' icon to look for boot device.

as for AppleShare going from one se/30 to this se/30 using the novo emulation I get around 55KB/s transfer on average but it has hit 60KB/s at times, however while copying a 25mb file it hangs at around 9.5mb with the mouse courser still movable. again I have to power cycle the scuznet to see the boot drive.

worth noting that both LED's are stuck on while I get the hangs. power cycling the Mac the right led next to the sd card flashes though.
also the nuvolink emulation does seem to be more stable then it used to be, In the past I couldn't even change to 'alternate ethernet' in the appletalk control panel so I could never connect to an AppleShare. also it would hang the system if I tried to restart the Mac.

going back to the daynaport emulation doesn't appear to help with the sluggish hdd performance
daynaport transfer from an appleshare is about 19KB/s but it does the same hang as the nuvo emualtion
doing a reboot and trying out appleshare again got me speeds around 34KB/s on average but I did get at times upto 39KB/s but after 17mb if hung the Mac with the mouse pointer still movable

and using fetch I get about 88KB/s with not issues

im not sure why appletalk failed on the daynaport emulation, ive never had that before
 

saybur

Well-known member
Thanks for trying it out so fast! I'll dig into the network lockups tonight and see if I can replicate them on my hardware.

The issue with 'fast' is weird, I haven't had anything like that here. Is the sluggish performance happening with 'forcefast' too?
 

superjer2000

Well-known member
@Chopsticks This is similar to what I noted and reported on github. I did a small 6MB AppleShare transfer which worked OK with reasonable speed (~65kB/s) but a Fetch transfer froze up very fast and was super slow to ramp up. No issue with hard drive performance for me though. @saybur how are you testing your AppleShare transfer speeds? It seems really weird that there would be such a marked difference between an SE/30 and a IIsi.
 

saybur

Well-known member
also the hard drive emulation is very sluggish, I have a 2gb hdd.img file and I have to use mode=forcefast to get it to boot, I when I use mode=fast I don't actually get the Mac past a grey screen on power up, I never seems to get the the 'floppy' icon to look for boot device.

Good news (sort of): I tried a different SD card, starting from scratch with a 'size=2048' file in fast mode, and I think I've been able to replicate this issue. I'll dig into it and figure out what's going on.

worth noting that both LED's are stuck on while I get the hangs. power cycling the Mac the right led next to the sd card flashes though.

That's a good hint, and probably points to a SCSI transfer getting stuck. That's one of the spots where the code can deadlock with /REQ driven, waiting for a /ACK that never comes. The box would be resetting when the Mac reboots and drives /REQ low to reset the whole SCSI bus.

For the LEDs, that should have been on the list of changes. On V2 boards the green LED is now always on and the amber LED flashes activity. I thought it worked better with the external case you designed: without the front LED it was difficult to see if the unit was on.

@saybur how are you testing your AppleShare transfer speeds? It seems really weird that there would be such a marked difference between an SE/30 and a IIsi.

Agreed. You'd think they'd be pretty close to one another given all the system similarities. I'm just copying ~10MB files and doing timing with a stopwatch, nothing fancy. I'm going to do some more extensive testing with some giant files and see if I can capture a lockup.
 

superjer2000

Well-known member
Agreed. You'd think they'd be pretty close to one another given all the system similarities. I'm just copying ~10MB files and doing timing with a stopwatch, nothing fancy. I'm going to do some more extensive testing with some giant files and see if I can capture a lockup.
Actually - I can wrap my mind around it. I've been working on changing how Scuznet-Daynaport handles packets and am up to ~74kB/s on AppleTalk on my SE/30. I tested my PB 145B though with the same Firmware and got well over 100kB/s so there is a pretty significant difference between 030 machines with a few extra mhz.

I am having troubles with TCP/IP with the new firmware and I don't think there will be much of a speed bump for Fetch but I'll know shortly.
 
Last edited:

saybur

Well-known member
Actually - I can wrap my mind around it. I've been working on changing how Scuznet-Daynaport handles packets and am up to ~74kB/s on AppleTalk on my SE/30. I tested my PB 145B though with the same Firmware and got well over 100kB/s so there is a pretty significant difference between 030 machines with a few extra mhz.

I am having troubles with TCP/IP with the new firmware and I don't think there will be much of a speed bump for Fetch but I'll know shortly.

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.
 

saybur

Well-known member
Just caught a nasty bug I introduced in the 'forcefast' code. Fixed on Github; you likely want to re-pull. I'm not on my A game tonight :p
 

superjer2000

Well-known member
Actually - I can wrap my mind around it. I've been working on changing how Scuznet-Daynaport handles packets and am up to ~74kB/s on AppleTalk on my SE/30. I tested my PB 145B though with the same Firmware and got well over 100kB/s so there is a pretty significant difference between 030 machines with a few extra mhz.

I am having troubles with TCP/IP with the new firmware and I don't think there will be much of a speed bump for Fetch but I'll know shortly.

I exaggerated a bit on my 145B results. Well over = 102kB/s.

So the new firmware is getting:
SE/30
AppleShare 75kB/S
Fetch: 86kb/S

PowerBook 145B
AppleShare 102kb/s
Fetch about 91kB/s and continuing to climb but really slowly.

All times above are writing to the Scuznet disk (FAT32 but with forcefast on)
 

superjer2000

Well-known member
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.

I'm actually running a big of an amalgam of the newer disk code and the older networking code as it seemed to work fine for my purposes and I didn't have to revise things that dramatically. Attached is an compiled version of the firmware (for the 64A3U V01 board) if anybody wants to give it a shot. (note that this firmware uses the scuznet.ini file, and only supports Daynaport networking).
 

Attachments

  • Scuznet-Dayna-AtalkAccel 643AU.zip
    35.4 KB · Views: 3

Chopsticks

Well-known member
Just caught a nasty bug I introduced in the 'forcefast' code. Fixed on Github; you likely want to re-pull. I'm not on my A game tonight :p
I can report that has fixed up my sluggish hdd issue, mode=forcefast now runs well. I haven't done any other testing yet. I may get time tonight to test out some things but if not I'll have time tomorrow to check things out. I did do a quick AppleTalk transfer test with the Dayna emulation and I get the same issues I reported last time.

as for th 'raw support, being that there are three options for mode= and fast/forcefast have the same ballpark speed as the raw open there's not need for it anymore so if removing it has simplified the code a bit then that's a bonus in my opinion.

Good news (sort of): I tried a different SD card, starting from scratch with a 'size=2048' file in fast mode, and I think I've been able to replicate this issue. I'll dig into it and figure out what's going on.
id recommend making the size=2047, there's a 2gb limit on these old Macs/system software and I forget what hard drive format software it was but one of them even said to make hfs volumes no larger then 2047mb. in fact im pretty sure my hard drive image is actually 2000mb in size in case that matters
 

superjer2000

Well-known member
Just caught a nasty bug I introduced in the 'forcefast' code. Fixed on Github; you likely want to re-pull. I'm not on my A game tonight :p
Hi Saybur, was the bug (and the prior note that forcefast wasn't doing anything), introduced with these recent changes? The codebase I'm working off of was from around June 29th and everything seems stable and disk performance with forcefast seems pretty snappy.
 

saybur

Well-known member
I exaggerated a bit on my 145B results. Well over = 102kB/s.

That's still excellent performance! I'm curious about the code changes, it's a far cry from the truly terrible throughput I'm getting on my Dayna tests; to be fair when both of you tested it you were getting much better results, so maybe I'm using a bad driver or something.

id recommend making the size=2047, there's a 2gb limit on these old Macs/system software and I forget what hard drive format software it was but one of them even said to make hfs volumes no larger then 2047mb. in fact im pretty sure my hard drive image is actually 2000mb in size in case that matters

Good call, I forgot about that limit. Good old HFS :D

Hi Saybur, was the bug (and the prior note that forcefast wasn't doing anything), introduced with these recent changes? The codebase I'm working off of was from around June 29th and everything seems stable and disk performance with forcefast seems pretty snappy.

It was introduced and then promptly fixed within 15 minutes, so you're safe. Just a silly error working on the wrong file pointer. I mainly posted because that one could have been hazardous to data on your drive.

I believe I've fixed the hard drive problem from last night: the solution is to open a second file pointer in read-only mode just for the continuity check calls so the f_lseek() doesn't have to rewind to the beginning of the disk and then seek all the way back through the FAT chain. After doing this the Mac began booting fine off the drive while the continuity check was in progress. This technically violates the rules for FatFs but the way scuznet access the volume, both for the normal read/write pointer and the second read-only pointer, should make it consequence-free. I'll test this out a bit to be sure while working on the networking issues Chopsticks reported.
 
Top