Jump to content

SCSI to Ethernet Adapter on New Hardware


Recommended Posts

Yup, exactly. I figured the delay you added might have been helping; the thought behind using the timer instead of a _delay() call was keeping link_check_rx() at the original speed for non-DISCONNECT situations.

 

I just pushed the change to Github. If you try it let me know how it goes. It still hasn't fixed the problem here on my SE, where it's acting like it's worse than what you and @Chopsticks have been experiencing on the SE/30s. This might be something where the device is just being too fast for the slower processors maybe?

Link to post
Share on other sites
  • Replies 242
  • Created
  • Last Reply

Top Posters In This Topic

  • 68kMLA Supporter
22 hours ago, saybur said:

Yup, exactly. I figured the delay you added might have been helping; the thought behind using the timer instead of a _delay() call was keeping link_check_rx() at the original speed for non-DISCONNECT situations.

 

I just pushed the change to Github. If you try it let me know how it goes. It still hasn't fixed the problem here on my SE, where it's acting like it's worse than what you and @Chopsticks have been experiencing on the SE/30s. This might be something where the device is just being too fast for the slower processors maybe?

I was messing around earlier and made a couple of changes to the link_check_rx() loop:

 

1) (After finally figuring out how to do it) I set up a timer in the loop; and

2) I added a condition that the system needs to have gotten a "No Operation" message 

 

Before it will proceed with the reconnect in the link_check_rx() loop.

 

So far I've been playing around for ~4 hours without it crashing.  I was able to use Fetch to transfer a 135MB file (~65k/s) and I transferred a 210MB file (~45k?/s I wasn't there when it finished) with AppleShare.  I'm now decoding System 7.5.3 from BIN using Stuffit Expander on my network volume and so far it seems to be working OK.

 

This could be completely out to lunch but from your writeup on the protocol, you noted that the system seemed to send a No Operation after it received a packet.  Your firmware doesn't  anything with the message but I hypothesized (and could be completely out to lunch) that it might act as as signal to proceed.  Or at the very least, it maybe seems to keep the devices in sync better somehow.

 

I sent a copy of the updated firmware to Chopsticks - I'm curious to see how it works for him - I only made a few changes to the firmware so once I hear back from Chopsticks, and if he's successful, I'll post them and maybe you can provide some thoughts on whether it's just a fluke or not.

Link to post
Share on other sites

Excellent! Hopefully it works for him too. I'll try something similar here and see what happens.

 

Your thought about NO OPERATION is definitely possible. One issue I had while decoding the device protocol was not having enough I/O on the loggers to sniff /ATN directly: I had to infer its presence based on when the Nuvolink switched to MESSAGE OUT. Targets can always go to MESSAGE OUT on their own without /ATN present (AFAIK scuznet only switches when /ATN is asserted). The firmware/driver could be using /ATN to do something nonstandard, like "if /ATN is not asserted do not send packet, the Mac is not ready."

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)

Well it all seemed to work fine - I just installed 7.5.3 on a ScuzNet partition from a disk image that was on my AppleShare server (also connected via ScuzNet).  So in total that was probably close to 5.5 hours of uptime without any issues and full time network use.  After installing 7.5.3 I did get a bus error when I went to restart - clicking restart on the bomb dialog box restarted as expected.  I'm now going to try to install the Ethernet drivers in 7.5.3 and see how it goes.  Note that the bus error on shutdown seems pretty consistent on my 7.1 system I was using before.  We'll see if it's any better on 7.5.4.  Note I'm using the Focus drivers.

 

If it helps, the changes I made were:

 

LOGIC.C

Add global variable

uint8_t readyForNext = 1;

 

In Logic Message out:

Added readyForNext=1; to the end of:

if (message == LOGIC_MSG_ABORT)

else if (message == LOGIC_MSG_BUS_DEVICE_RESET)

else if (message == LOGIC_MSG_DISCONNECT)

else if (message == LOGIC_MSG_REJECT)

else if (message == LOGIC_MSG_NO_OPERATION)

 

 

LINK.C

Add global variables and an include for  <avr/interrupt.h>

 static uint8_t readyForReselection = 2; 

extern uint8_t readyForNext;

 

 

Changed:

link_check_rx as follows:  Note that I have readyForReselection as 2 as I was first experimenting with longer times that went over what seemed to be the two bytes for the timer.  I haven't gone back to try to clean this up yet.  Essentially it would be waiting for 2048 cycles.  Might be able to speed it up further but I haven't played with the values yet.

 

if (last_identify & 0x40)
        {
            if (! asked_for_reselection)
            {
                
                
                if (readyForNext == 1 && readyForReselection ==2)
                {

                    debug(DEBUG_LINK_RX_ASKING_RESEL);
                    phy_reselect(target_mask);
                    asked_for_reselection = 1;
                    TCE0.PER = 1024;
                    TCE0.INTCTRLA = TC_OVFINTLVL_MED_gc;
                    TCE0.CTRLA = TC_CLKSEL_DIV1_gc;
                    readyForNext = 0;
                    readyForReselection = 0;

                }

            }
        }

 

And the interrupt routine:

 

ISR(TCE0_OVF_vect)
{
    readyForReselection++;
    TCE0.CTRLGSET;
    

}

 

Edited by superjer2000
Link to post
Share on other sites
  • 68kMLA Supporter
On 3/5/2021 at 11:40 PM, superjer2000 said:

Well it all seemed to work fine - I just installed 7.5.3 on a ScuzNet partition from a disk image that was on my AppleShare server (also connected via ScuzNet).  So in total that was probably close to 5.5 hours of uptime without any issues and full time network use.  After installing 7.5.3 I did get a bus error when I went to restart - clicking restart on the bomb dialog box restarted as expected.  I'm now going to try to install the Ethernet drivers in 7.5.3 and see how it goes.  Note that the bus error on shutdown seems pretty consistent on my 7.1 system I was using before.  We'll see if it's any better on 7.5.4.  Note I'm using the Focus drivers.

 

Out of curiosity, roughly how long did it take to install 7.5.3 this way?

Link to post
Share on other sites
  • 68kMLA Supporter
20 hours ago, aperezbios said:

Out of curiosity, roughly how long did it take to install 7.5.3 this way?

It was pretty quick.  I used the 19 part install from the Garden.  Fully over the network with Scuznet I used StuffIt to turn the BINs into the SMI and then did the install and for those two activities I’d say around 40 minutes. It’s hard to say for sure as I was just checking up on it every so often. 

Link to post
Share on other sites
  • 68kMLA Supporter

Given that I think that ScuzNet will be a fully workable solution for the SE/30 what I’d like to do is swap out the DB25 connector for an internal IDC50 and change the power connector to an internal drive molex.  I would then mount the ScuzNet internal, 3d print a back cover plate and extend the Ethernet cable with a the type of short panel mount extension I used for my IIe and IIgs for the Uthernet. That would them be functionally equivalent to an internal SCSI2SD and PDS Ethernet card for ~$50 cad.

 

Time to try to learn KiCAD I guess.

Link to post
Share on other sites
  • 68kMLA Supporter
On 3/5/2021 at 11:58 PM, saybur said:

Excellent! Hopefully it works for him too. I'll try something similar here and see what happens.

 

Your thought about NO OPERATION is definitely possible. One issue I had while decoding the device protocol was not having enough I/O on the loggers to sniff /ATN directly: I had to infer its presence based on when the Nuvolink switched to MESSAGE OUT. Targets can always go to MESSAGE OUT on their own without /ATN present (AFAIK scuznet only switches when /ATN is asserted). The firmware/driver could be using /ATN to do something nonstandard, like "if /ATN is not asserted do not send packet, the Mac is not ready."

I think I am slowly descending into madness - 

 

The code changes above seem to make ScuzNet fully stable on my SE/30 (other than the Bus Error on shutdown which happens 80% of the time (100% of the time after running a TCP/IP application)) but it was bothering me as to what the issue was so I thought I'd go about trying different permutations of the changes I made to see where it stopped working and I am at a bit of a loss...

 

I'm not sure how much of am impact waiting for messages from the initiator before proceeding with a reconnect has on stability.  It does seem like there is a relationship as when waiting for messages as I outlined above, coupled with ONE VERSION of the timer routine, it seems to be completely solid.  I can take out the message handling and keep the timer routine and it seems almost perfectly solid but I did have a couple of hangups ~60mb into a 130mb copy (but oddly enough without any activity light on the ScuzNet - usually the light does the quick brightness blink when it freezes the Mac or the light goes solid when Scuznet seems to freeze - in this case, the Mac wouldn't respond although the mouse worked and the ScuzNet light was off.)...

 

Anyways, as noted, the timer seems to be the most important item to impart stability rather than waiting for messages but what is confusing me to no end is:

 

I outlined how I handled the timer in the code snippet above.  That works perfect.  I changed the timer PER to 1 and the machine froze on boot with a solid light.  I am now running with PER= 256 and so far it seems stable.  I thought a lower PER might make transfers faster but that doesn't seem to be the case at least between 256 and 1024 in the above code).  I seem top top out at about 75k/s in Fetch.

 

I THOUGHT I should be able to change the timer code to make it simpler as follows (i.e. not wait for two timer trips but just reset the flag on the first timer trip) but that does not work.  In all cases, the computer would freeze at booth (with the quick/dim flashing on the Scuznet).  I tried changing the PER to 2048 (i.e. two loops of 1024) and just could not get it to work.  I thought maybe the interrupt was being called and resetting the flag too early, or maybe it was taking a couple of cycles and only part of the byte was updating or the compiler was optimizing and not taking the ISR change into account, so I tried making readyForReselection volatile, I tried disabling interrupts when I update the flag to 0 in the loop, I moved the readyForReselection higher up in the routine (i.e. before resetting the timer etc.) and nothing works.

 

So I'm not sure if this is telling as to what the underlying issue may be or not - if calling the ISR in the specific way where the flag is incremented is causing some other change somewhere else - I thought maybe it was causing an extra cycle so I bumped up the timer a bit but that didn't help as as noted I'm having luck with the timer set at 256 with the original code.  Maybe I'm not understanding how the timer code is working either - But looking for any thoughts and feedback on why the below would be acting differently.  That being said, the original code changes are seeming to work perfectly as least on my SE/30.  I'm going to try my Classic II next, but I would feel so much better if I knew why they worked.

 

  •  

 static uint8_t readyForReselection = 1; 

 

if (last_identify & 0x40)
        {
            if (! asked_for_reselection)
            {
                
                
                if (readyForNext == 1 && readyForReselection ==1)
                {

                    debug(DEBUG_LINK_RX_ASKING_RESEL);
                    phy_reselect(target_mask);
                    asked_for_reselection = 1;
                    TCE0.PER = 1024;
                    TCE0.INTCTRLA = TC_OVFINTLVL_MED_gc;
                    TCE0.CTRLA = TC_CLKSEL_DIV1_gc;
                    readyForNext = 0;
                    readyForReselection = 0;

                }

            }
        }

 

And the interrupt routine:

 

ISR(TCE0_OVF_vect)
{
    readyForReselection=1;
    TCE0.CTRLGSET;
    

}

 

Link to post
Share on other sites
  • 68kMLA Supporter

So as noted, the ScuzNet has been (other than the shutdown bus error issue I still need to troubleshoot) perfectly trouble free on my SE/30.  I haven't figured out yet how best to figure out what's happening there - I'm thinking that when Shutdown occurs, some command is issued by the Mac to all SCSI devices and the Scuznet isn't responding as expected - I poked around the SCSI Manger Apple document but didn't see anything that jumped out at me on my first glance.)

 

I thought I'd give it a shot on an SE next.

 

I can see my AppleShare server but it takes probably 5 to 10 seconds to show up in the Chooser after I select AppleShare.  Connecting to it then is pretty quick, it mounts and I can open the volume.

 

On System 7.1 when I try to copy something from my server I get the little AppleShare arrows and the Mac mouse stays responsive, but the copy never starts.  There is on going (and what appears to be repetitive based on the led) activity on the Scuznet so the network is doing something but the copy doesn't ever start (or at least it doesn't in the time I've left it (~3 minutes.)

 

On 6.0.8 I still get the same delay in the chooser, but I can copy from my server just fine (at least for a couple of test files).

 

Any recommendations on how to troubleshoot why a copy is getting hung up in System 7.1?  I have all of the cleartext and guest UAMs setup in netatalk.    I should try to copy something to the server from the SE - I tried WireShark to see if I could see what packets are being moved along but after the server is selected I don't seem to get any more packet activity for the ScuzNet's MAC address even when I'm viewing the directory of the AppleShare server etc.

 

 

Link to post
Share on other sites
On 3/6/2021 at 9:30 PM, superjer2000 said:

I think I am slowly descending into madness

 

Right there with you, I've been banging my head on my desk with this one. With a 6.0.8 installation on the scuznet SD card, it works perfectly on my IIci - establishing a connection to the server (7.5.5 running under Basilisk) is pretty quick, transfers are slow but functional, and no crashes to speak of. I move the box to my SE, same everything, and bam, problems galore - Wireshark shows that AppleTalk Echo packets from the server are not being replied to, connecting to the server is unstable and overall very slow, and as soon as I try to list the server files the system locks up. It is weird.

 

I'm running the most recent commit from the Github repo, without your changes - I'm guessing that those changes will probably help, so I'll be trying them later.

 

As for the timer, I spent some time thinking about it and I'm not sure why the two versions are behaving so differently. While the variable should be volatile, it might still be working anyway if the compiler is figuring out what you're trying. The underlying problem may still be some weird timing issue, which is being affected by little things like this?

 

For 7.1, I'm still hoping that if the underlying issue here can be squashed that some of these other problems will go away on their own. Maybe that's just wishful thinking.

 

In any event, thanks again for digging into this so much. I'll keep plugging away here too and hopefully at least make headway on why all this is happening.

Link to post
Share on other sites
  • 68kMLA Supporter

I’ll be honest, getting this going on an SE is just a side project of curiousity. I don’t have any intention of using Scuznet on a 68000 machine - my use case is the two SE/30s I have that don’t have Ethernet cards and for that, with these inexplicable code changes, this works perfectly and at a speed that’s comparable to my internal Ethernet card.  
 

I am going to try to reinstall 6.08 and see if that works as I did have luck with my se and 6.08, it was just 7.1 I couldn’t get it to work with (copying hangs with AppleTalk arrows in corner). I might try system 7.0.1 as well. 

Link to post
Share on other sites

OK, I'm finally starting to make some progress on this problem.

 

I'm noticing way more instances of the extended message 0xFF on my SE... like, many, many times more. It always seems to be appearing after a packet was sent from the scuznet to the Mac. I'm thinking this is a "I didn't catch that, please resend" type message, with a format like:

  • 0x01 [extended message]
  • 0xFF [vendor-specific code, in this case Nuvolink "plz resend"]
  • 0x00 [upper 8 bits of length]
  • 0x2B [lower 8 bits of length]

The length values seem to (mostly) match the previously sent packet. I'll have to do some refactoring to test this out, but FYI on what I've discovered so far.

 

This also seems to explain why all those AppleTalk Echo packets are being ignored - I think they are being correctly received on the box, sent to the Mac, but the Mac isn't "seeing" them and the protocol goes all wonky for a while until higher-level AppleTalk recovery occurs (?).

Link to post
Share on other sites

I think I've got it! That weird message is actually a request to transmit, not resend. Switching to DATA OUT and fetching a packet is the correct response, followed by disconnecting from the Mac. I've updated the protocol description and pushed code to Github that implements it.

 

If anyone pulls and compiles this latest version I'd love to hear how well it works, especially on the SE/30s. On my SE the firmware is now working properly and was able to transfer smaller files without issue. It's slow enough I haven't been able to test larger files yet, but I'm hoping this fixes that issue as well.

Link to post
Share on other sites

Hey guys, I’ve just read these latest forum posts. Sorry I haven’t replied etc lately. Been swamped with uni homework the last 2 weeks so I haven’t really been online much.

 

I have some free time later today so I will compile the latest firmware and test on my se/30 and let you know how it goes on my end.

it looks like a lot of progress has been made these past couple weeks from what I’ve read..

Link to post
Share on other sites

well I can connect to my AppleShare server, it shows up as soon as I click AppleShare in the chooser, I can mount volumes and browser with no issues, but I have the same issue mentioned about where I can move the mouse around fine but I can't click on anything and the copy never begins.

then after awhile I get a flashing "SCSI communication Lost' error in the middle of the screen and eventually  a dialogue comes up saying the AppleShare connection to my server was lost once I click ok I can use the se/30 again with no issues.

oh and while that is happening the led isn't flashing on the scuznet its just off the whole time

 

as for reboot/shutdown I still get a bomb/crash to macsbug

 

testing some large file transfers via ftp (fetch) atm just to see if there's any change and/or issues there

 

EDIT:

 

well after a few minutes it crashes to macsbug when doing a fetch transfer

 

Edited by Chopsticks
Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)

@saybur  I’ll give that it a shot and update with the results. I was playing around a fair bit over the last week and got it reasonably stable for AppleTalk on my SE with System 6.0.8 but it wouldn’t work with 7.1.  One thing I’m looking at as adapting the Daynaport SCSI Link to the Scuznet as following the RaSCSI development it seems pretty straightforward, there is a fair amount of documentation on the protocol as it’s Been used successfully on the Atari and work has happened to port it to RaSCSI.  Before I go down that road, I wanted to see if you had considered that or not to see if there was a reason you didn’t emulate the Daynaport?
 

@Chopsticks Did you try that firmware I emailed you?  It’s not solving the underlying issue but the delays embedded in it made the Scuznet fully stable on my SE30.

Edited by superjer2000
Link to post
Share on other sites
  • 68kMLA Supporter

@saybur  The new firmware is definitely an improvement - On my SE/30 it:

 

* Booted fine;

* Allowed me to connect to my AppleShare server;

* Started a copy right away; but

* It crashed probably 3 or 4MB into a 24MB copy.  Same symptom as before - the ScuzNet activity light went on solid - 

 

I agree it's likely getting stuck in some loop and hanging up the system.  I had tried on a prior firmware to figure out what loop it's getting caught up in as there aren't that many but moving around the position of the led_on/led_offs to see where it's entering a loop but not exiting but it doesn't seem to always be consistent.  I'm going to try that again with the newer firmware.

 

I'm also going to see if I can do a quick proof of concept with the Asante drivers by repurposing some of the RaSCSI work to see if that's any more stable as the protocol used by those drivers seems to be a fair bit simpler.

Link to post
Share on other sites

At least there was some improvement, but it's frustrating the issue is obviously still not fixed. I'll see if I can get the SE to crash and get more information on where the failure is coming from.

 

I think implementing the Daynaport/Asante is a great idea. Doing the Nuvolink was just down to the hardware I could get my hands on. At the time, I was not aware that anyone had done a writeup of those other devices. Especially if they are simpler, it might help improve stability/performance.

Link to post
Share on other sites
  • 68kMLA Supporter
20 hours ago, saybur said:

At least there was some improvement, but it's frustrating the issue is obviously still not fixed. I'll see if I can get the SE to crash and get more information on where the failure is coming from.

 

I think implementing the Daynaport/Asante is a great idea. Doing the Nuvolink was just down to the hardware I could get my hands on. At the time, I was not aware that anyone had done a writeup of those other devices. Especially if they are simpler, it might help improve stability/performance.

 

I'm not sure if performance would better as the Daynaport just seems to pool the device for packets rather than having the device reconnect when it has packets but given how you have built some pretty robust interfaces for all of the networking elements, I think that moving it over will be pretty straightforward.

 

All that being said, I am having much better luck with with the new firmware after adding in a couple of delays as per below.  

 

I was trying to track down where the system was freezing by putting the led on/off here thinking it might have been getting caught up in one of the loops here and to my surprise it seemed to work on my test copy.  I thought maybe again there was just a bit of a slowdown introduced by the led switching.  That change seems to have allowed me to get through the copies I was having issues with before.  Fetch is still freezing up on a test file but that seems to be a specific Fetch/test file issue as it is working with other files.  I'll play around a bit more here and see if this is actually making a difference or if it's a fluke.  I am still getting the bus error at shutdown - Not sure what's causing that.

 

image.png.11f02799376b6674f691d6f192c745b1.png

Link to post
Share on other sites
  • 68kMLA Supporter

Well, this seems to be pretty solid with those delays.  I have done some large file copies (100+ MB) without any real issues.  Fetch did lock up for me a couple of times when starting a copy but that was before any real network activity and it seemed to be related to files that had partially downloaded before - I think it's a Fetch issue.

 

I was also able to play Bolo on my SE/30 with ScuzNet (see the other Hacks and Development thread) and it worked perfectly.

 

I am still curious as to what might be causing the Bus Error problem at shutdown.  It seems like the hardware isn't responding to something that the driver is issuing when the computer shuts down as the machine pauses for a second at shutdown and then throws the bus error.  I turned on logging to see if anything came up (like an extended message or something) and I didn't see anything.  I just realized I also get the bus error if I try to change to Printer Port from Ethertalk in the AppleTalk control panel, so it seems to happen when the computer tries to disconnect from the Ethernet network..

 

I'll take any feedback on how best to debug this issue, but otherwise this seems to be working perfectly for me.

Link to post
Share on other sites
  • 68kMLA Supporter
Posted (edited)
21 hours ago, superjer2000 said:

Well, this seems to be pretty solid with those delays.  I have done some large file copies (100+ MB) without any real issues.  Fetch did lock up for me a couple of times when starting a copy but that was before any real network activity and it seemed to be related to files that had partially downloaded before - I think it's a Fetch issue.

 

I was also able to play Bolo on my SE/30 with ScuzNet (see the other Hacks and Development thread) and it worked perfectly.

 

I am still curious as to what might be causing the Bus Error problem at shutdown.  It seems like the hardware isn't responding to something that the driver is issuing when the computer shuts down as the machine pauses for a second at shutdown and then throws the bus error.  I turned on logging to see if anything came up (like an extended message or something) and I didn't see anything.  I just realized I also get the bus error if I try to change to Printer Port from Ethertalk in the AppleTalk control panel, so it seems to happen when the computer tries to disconnect from the Ethernet network..

 

I'll take any feedback on how best to debug this issue, but otherwise this seems to be working perfectly for me.

 

Still going to work on this, but I am not getting the bus error on my Classic II (and the ScuzNet is working perfectly fine there as well).  I'm using the Scuznet to boot both systems so it's not a system software thing either.  I'm going to pull down my other SE/30 without a network card and see if that one has the bus error as well.  EDITED:  Scratch what I said above...  I am getting the same bus error on my Classic II.  It kicked into MacsBug - At least that makes me feel a bit better that it's not some weird hardware issue on my SE/30

Edited by superjer2000
Link to post
Share on other sites

I'm going to add those delays to the repo tomorrow. If they're increasing stability that's great and they should have a pretty minor performance impact at that spot. Given how many real Nuvolink delays are shortened or removed, maybe the issue now really is just due to the emulated device moving a little faster than the driver can handle.

 

21 hours ago, superjer2000 said:

I just realized I also get the bus error if I try to change to Printer Port from Ethertalk in the AppleTalk control panel, so it seems to happen when the computer tries to disconnect from the Ethernet network..

 

That's extremely helpful, thanks. If it involves that stage it may be due to some weird behavior with the commands used only during startup/shutdown, like 0x0C and such. At least it makes it easier to try and catch without doing a system reboot!

Link to post
Share on other sites
  • 68kMLA Supporter
On 3/14/2021 at 12:47 AM, saybur said:

I'm going to add those delays to the repo tomorrow. If they're increasing stability that's great and they should have a pretty minor performance impact at that spot. Given how many real Nuvolink delays are shortened or removed, maybe the issue now really is just due to the emulated device moving a little faster than the driver can handle.

 

 

That's extremely helpful, thanks. If it involves that stage it may be due to some weird behavior with the commands used only during startup/shutdown, like 0x0C and such. At least it makes it easier to try and catch without doing a system reboot!

 

I had missed that comment in the protocol document about 0x0C on start up and shutdown.  Unfortunately, I'm not sure if the insight that the bus error occurs both on shutdown and when switching from "Alternate Ethernet" will be of much help.  I threw in some debugging outputs in logic_command() where it would dump all of the received commands (including the extra command parameters) out to the serial log - I didn't see anything that is being triggered when I switch to LocalTalk, although I do get the crash.  It seems that the Mac only crashes when I've been using AppleShare - it happens everytime I mount a volume and use it, but it didn't happen this AM when I didn't use AppleShare but just logged into some BBSs with MacSSH.

 

I'm starting to wonder if it's maybe just an incompatibility with the driver and system 7.1 (and newer) (or maybe open transport).  I've installed MacsBug and it seems like something is trying to write to an invalid memory location, although I can't tell what (and I'm definitely not versed in MacsBug).

 

I might try to install System 7.01 and reinstall system 7.1 without open transport and see what happens then.

Link to post
Share on other sites
  • 3 weeks later...
  • 68kMLA Supporter

ScuzNet Daynaport Emulation now available

 

I'm not sure how many people have built or gotten their Scuznet devices operational (they are not the easiest to solder and require a PDI programmer) but the value in my mind can't be beat.  Total cost to build a Scuznet (excluding time) is probably about US$40 and for that you get a device that provides solid state storage like a SCSI2SD and emulates a SCSI Ethernet adapter.  The creator @saybur designed (what has been for me) rock solid hardware and did a phenomenal job of making the firmware extremely easy to follow.  I am sure this project has significant potential including emulating CD-ROMs (like RaSCSI) , being adapted for internal use and even integrating with WiFi instead of a wired connection which would make it a great fit for a PowerBook.

 

The only downside was the Nuvolink emulation that Scuznet was based on didn't work reliably for a couple of us (myself and @Chopsticks experienced various freezes and bus errors on shutdown/restart).  The Nuvolink seems to be a fairly complicated device (although with very strong network performance).  Inspired by @landoGriffin's comments made on Captain's Quarters II BBS on the simpler Daynaport SCSI to Ethernet device, I made some modifications to Scuznet to provide Daynaport emulation instead.  This was pretty straightforward to do given how well organized and documented the Scuznet firmware is.

 

The upside has been very solid network reliability (no crashes, freezes etc., even after transferring 1GB or so of MacFlims) but the downside is slower network performance which I believe to be due to the Macintosh driver, coupled with the Daynaport only sending one packet at a time whereas the Nuvolink would continue to send packet data until the Mac asked it to stop).  On my SE/30, Scuznet-Nuvolink delivered about 50kB/s transferring files from an AppleShare server and 70kB/s on Fetch FTP whereas Scuznet-Daynaport delivered about 35kB/s and 55kB/s, respectively.

 

I have added a fork on GitHub (bear with me, this is the first time I've ever uploaded anything to GitHub so I might have done this completely wrong) and I have also included a precompiled version of the .elf firmware.

 

https://github.com/superjer2000/scuznet

 

Please don't hesitate to provide any feedback or comments.

 

Thanks!

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...