Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by saybur

  1. On 5/10/2021 at 12:34 PM, superjer2000 said:

    I’m not sure how I feel about those Prusa printers. Prusa printers are used to print new Prusa printers. It all sounds like a great idea until we lose control and there is more of them than us and the printers figure out how to extract filament from human beings.  Not so fun then, is it??


    It was a weird day and I really needed the laugh, thank you! :)


    On 5/10/2021 at 10:18 PM, Chopsticks said:

    If it’s not to much trouble it’d be great if you can pm me the files, I have to do and order of other boards at jlcpcb in the next 2-3 days so adding this latest scuznet revision to that order is only a few dollars. I don’t mind if there’s turns out to be an issue and the boards become coasters fwiw.


    I've attached a copy. You obviously know but in case anyone else comes along a reminder that these are not tested. I'll post a final revision to Github once I've built some of these new ones.


  2. 8 hours ago, Chopsticks said:

    also saybur what's the status of the version 2 board, i.e vibe checked you githut repo but still no update there. I'd like to help out with testing when the new version is ready though my machines are somewhat limited to a couple se/30's, and Mac Iici and a Quadra 630.


    in regards to the idc50 pin connector:

    the normal db25pin connector and the idc50 have flipped pins for lack of a better description and you mentioned that having both connectors is a bit troublesome, is that because its a 2 layer board or is it more complicated then that?

    im just asking because I think if that is the case then it probably makes sense to just have 2 versions, and internal 3.5 inch version and the current external version. it going down this road then it allows for some more flexability with the internal version i.e having a daughter board with the magjack and possibly in future incorporating a wifi module onto the main board or the daughter board.

     personally I think that having a daughter board for internal installs makes sense for the lan connector but again if might make more sense to allow provision for a wifi mule on and internal board space wise


    I got stuck working on the internal/external PCB design and put the project down for a few days to think about it. My Prusa also showed up, which has been competing with this project for attention. So far the printer has been winning, Prusa makes a pretty nice piece of equipment (at least for this 3D printing newbie)! :)


    After mulling it over, I think I'm going to stick with the version 2 layout I posted that is external-only. Even removing the mounting holes, I was still running into fundamental issues with the board layout when the IDC50 connector was added. I'm pretty sure the problems can be fixed, but I really don't want to toss out the verified aspects of the original design. Also, on a more "meta" level, I'm mentally ready to move on to other aspects of this project, like incorporating the Daynaport support @superjer2000 added and making some additional software-side fixes. With everything being open source, I would definitely encourage anyone who wants to take a shot at a hybrid board to do so and post how things go. I'd really interested in what people come up with. Stuff like your awesome 3D printed rig shows how creative this community can be when they want to accomplish something!


    I'll be shipping these boards off to JLCPCB later today or tomorrow. Once they get back and I can verify they're working I'll post the files publicly. If you'd like a copy in advance, let me know and I can PM them. Just be aware they're totally untested and you may end up with a nice stack of drink coasters.


    8 hours ago, Chopsticks said:

    also one3 last thought regarding the psu for the board, as some boards have trouble with powering via term power would it make sense to use a boost/buck psu configuration?


    That's probably the smart approach. I've never designed a board with a switching regulator and am a little nervous about the requirements, so I've traditionally stuck to linears. Especially if someone wanted to make a version for a Powerbook the switching regulator would help cut down on power consumption.


    On 5/8/2021 at 10:37 PM, Chopsticks said:

    btw I don't think it supplys termination power to pin 25 from memory its disconnected on this pcb


    It's also disconnected on scuznet, which sources termination power off +5VDC exclusively. IMHO it's pretty hit-or-miss whether TERMPWR is reliable. Between bad fuses, models that omit it, abnormally low voltage, etc, I figure it's easier to ignore the line.

  3. I took a brief look through that ESP-Hosted documentation and it does look promising for what you want. The physical interface is similar:

    • The usual 4 SPI lines,
    • A "Enable/Reset" line like "/E_RST" on scuznet,
    • A "data ready" line like "/E_INT," active high instead of low on scuznet,
    • A "handshake" line, which is an addition. You'll need to scavenge a pin somewhere off the microcontroller for this one.

    The logical interface looks quite different and doesn't appear to have the pointer-based system the ENC28J60 uses. That could probably be worked around. There definitely would need to be additional code for the Ethernet/WiFi frame conversions, but I'm not familiar with how WiFi works and don't know how hard that would be.


    As for WiFi configuration, I've been toying around with the idea of moving all the configuration information to the flash card in a future scuznet firmware, instead of storing the data in EEPROM. The flash card would be in FAT32, with each virtual hard drive being a file on the device. This would make it way easier to do system setup in something like Basilisk and would also let configuration be done in a text file on the card (or something). Maybe if that was implemented, you could add WiFi configuration information in that config file? It wouldn't be as elegant, but it sounds much easier than having to write a Mac utility to send SCSI commands.

  4. 8 hours ago, superjer2000 said:

    From your comments on the cross crossing of the connections between the 25pin and 50 pin connectors, it might make a difference from a PCB layour perspective, but I am indifferent on mounting holes as it would be easy enough to build a 3d printed bracket that would allow for easy mounting.  Definitely agree on the flying leads for power to free up some space.


    I've been trying to keep away from needing 3D printed parts, mostly due to not having a decent 3D printer myself (I do have a Prusa i3 on order somewhere in their backlog and I know enough OpenSCAD to be able to make something crude). If 3D printing isn't a dealbreaker for people or if a purchasable case isn't important, maybe that's the approach to use: a 100x100mm board without those holes would be much easier to lay out than the internal/external combo form factor. Does anyone have thoughts on that?


    8 hours ago, superjer2000 said:

    I don't know if you had thought much about it, but I'd love your perspective on the feasibility of a wifi version to see if it's something that might be worth pursuing.  My background is pretty limited here but I think that ESP-HOSTED I linked to before might work.  I don't have any other Scuznet PCBs here, so I'm thinking I might remove the network chip from one of the two I have built and wire in an ESP32 in its place.


    I don't know much about the ESP32 ecosystem. If they (and/or the Arduino cores) support raw packets, my guess is you'd be better off rewriting the entire firmware from scratch targeting that platform and drop the XMEGA entirely. The Nuvolink has picky timing requirements due to the reselection step and is probably out of the question, but your Daynaport version should be doable without super-high timing accuracy. @cheesestraws mentioned some other chipset options and the low-level issues you might run into. It's a big project, and probably outside the scope of scuznet, IMHO. If you get it working it would definitely be awesome, having internal WiFi in my Powerbook 145 would be so cool!


    Alternately, I wonder if anyone has tried RaSCSI on the Raspberry Pi Zero W in a Powerbook. That might be the easier approach.


    5 hours ago, pfuentes69 said:

    All that effort is so much appreciated!!!


    Thanks! I'm really glad people have found this project interesting :)

  5. I've spent some time this week trying out different layouts to get both internal and external connections on the same PCB. The consensus seems to be that is the best approach, which I don't disagree with: it would be nicest to order one set of PCBs, possibly pre-populated with the passives, and use them everywhere. Unfortunately I haven't had much luck coming up with a workable design that doesn't require ripping everything up and basically starting the layout from scratch. There are some other wrinkles to consider:

    • The width of the 50-pin connector means that power has to go somewhere else. I think flying leads are the best option, since it lets the board have a simple pair of +5VDC / GND pins that you could attach a Molex lead to, or a barrel plug for outside the case.
    • Apple went with a strange layout on the DB-25 connection where the data and control lines are opposite of what they are on the standard 50-pin connector. This requires some weaving of traces or flipping one of the connectors. I have no idea why they did this, maybe it was something about the Plus logic board.
    • In the prototype layouts, I added mounting holes for the standard 3.5 inch and 2.5 inch bottom-mount hard drives. The former works directly, and the latter can be used with those cheap SSD-to-3.5 brackets. On my clone SCSI2SD v4 boards this was very helpful for giving flexibility on mounting. The downside is it eats lots of space and really mucks up the existing layout. Maybe this would work better if these were discarded?

    Anyway, after this I'm still thinking separate boards for internal/external. That said, I'm no PCB layout expert and I would be thrilled if there was an alternative. If anyone wants to take a shot at it I'd love to see the results.

  6. On 4/24/2021 at 6:40 PM, pfuentes69 said:

    For the rest, I think it should be doable to put the place for the 50p SCSI internal connector and a floppy style power connector. Like this people can choose if soldering the DB25 or the internal port.


    I think that's a good idea, but unfortunately it doesn't quite fit on the board. I think @Chopsticks is on the right track with a separate all-internal design, moving the ENC28J60 and associated hardware to a daughtercard.


  7. I finally got some more time to devote to this project and implemented version 2 PCB changes. I've attached a rendered image of the board.


    One significant change was switching from microSD to full SD. This should simplify soldering of the annoying little connector and make it easier to swap cards with the case put together.


    There was a discussion a page or two back about how to power the board, whether through USB, termination power, or the current approach. After doing some more research, I landed on keeping power through the barrel jack only. My thinking was:

    • Adding USB requires relying on a "dumb" USB supply or adding proper enumeration support, along with some mechanism to turn off the termination regulator and/or other components to avoid drawing too much power when connected to a computer. I wanted to avoid having to implement this if I could get away with it.
    • USB-C has alternative power detection options through the cable resistors. The analog ports on the microcontroller are blocked and it would have required significant rework to expose them, and I didn't want to add more parts to the board to do it with external circuitry.

    I did add a micro USB plug, but the board cannot be powered through it. It is present mainly to help program blank chips with the factory-supplied DFU bootloader, and for future expansion.


    Other changes:

    • Base schematic updated from Kicad 4 to 5. Footprints were switched to the ones in the new packages.
    • The SI-60062-F Ethernet connector is now quote-required on Digikey. Switched to the more common RJMG1BD3B8K1ANR.
    • The board depth was increased by half a millimeter to account for the case-wiggle in the Hammond 1455L801. Mounting holes were also added per request.
    • The packaging on the power regulators was changed. The 3.3V regulator was oversized, it is now down to SOT-223. The 2.63V termination regulator was switched to TO-220 to simplify soldering and save some board space.
    • A second LED was added to help with diagnostics.
    • Numerous other minor changes, like switching all resistors to 0603 packaging and tweaking the BOM.

    I'd love to hear if anyone has suggestions for other things to modify. I'm planning on sending off for prototypes sometime in the next few days, and if things work I'll post the files on Github. If you want them in advance let me know, but be aware they are untested.


  8. On 3/29/2021 at 12:22 PM, RetroTheryboy said:

    Maybe someone knows why ATN is called in OS versions > 8?  is this a SCSI 2 thing ?  


    The spec allows ATN to be driven during selection, which should just be the Mac asking the hard drive to move to a MESSAGE OUT phase following selection.


    The indefinite-low screenshot you posted shows C/D asserted but MSG and I/O de-asserted, so it looks like the device is hung up in the COMMAND phase. REQ is driven, so the firmware is asking the Mac to give it a command byte that it never receives. Just a guess, but maybe the firmware is hardcoded to move to COMMAND after responding to selection, even with ATN asserted? That might make the Mac driver freeze up if it wasn't expecting that response.

  9. 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!

  10. 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.

  11. 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.

  12. 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 (?).

  13. 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.

  14. 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."

  15. 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?

  16. On 3/1/2021 at 3:56 AM, Chopsticks said:

    So far I have hooked everything up to my iici and AppleTalk seems fine.


    Thanks for checking this. That matches here, where things seem fine on faster/newer systems - seems to work on a LC 475 too.


    On 3/1/2021 at 3:01 AM, superjer2000 said:

    If you don't mind, I'd really like to ask a few questions about some of the specifics of how this is working.  I have been through enough of the firmware to have an "OK" understanding of what it's doing generally but there are lots of details I would really like to get clarity on.


    Sure thing. I'm no expert on AVR C or anything but I can hopefully shed some light on the thinking behind parts of the implementation.


    One thing I noticed is the firmware is violating the DISCONNECT message delay of 200us. I've added handling for that via a timer and my SE is no longer doing the fast-flash error. Instead, it is just taking forever to authenticate with my G3 iMac and eventually crashes with "divide by zero". I'll continue to do some debugging this weekend and see what else I can figure out.

  17. 20 hours ago, Chopsticks said:

    i do have a iici logic board around here so I might give that i quick test if I get time today as if all my issues go away then it must be something to do with the way the se/30 scsi works and/or is implemented??


    If it isn't a hassle that would be great to check - mine has been pretty solid with my IIci and it would be nice to verify with someone else's setup. Based on how the _delay() calls @superjer2000 added improved stability, I wouldn't be shocked if faster systems or newer ROMs were more tolerant of whatever the bug(s) are.


    20 hours ago, Chopsticks said:

    fwiw both my se/30’s exhibit the exact same symptoms and they are divergent logic board revisions from what I can tell. Not sure if that’s useful knowledge or not though


    It is useful, thanks - all these systems having basically the same problem sure seems to point to an error on my part in the firmware.


    I hauled out my old original SE and I think I've been able to replicate some of what you all have reported: during AppleTalk authentication, my board started doing a dim LED flashing like it was repeatedly trying to do some activity and the OS locked up. I'll be doing some more debugging to see what's actually going on over the next few days and will see if I can make headway.

  18. First off, apologies for the issues. It seems pretty obvious there is a firmware bug causing all this grief. Thank you for doing so much work debugging this issue, and I hope navigating the code wasn't too obnoxious.


    To give some more data points, my main testing machines for scuznet are a IIci and a LC. Things seemed to be working flawlessly on both systems. I'm going to diversify my testing rigs and hopefully I can get my rig to crash like you all have been experiencing.


    On 2/28/2021 at 1:14 AM, superjer2000 said:

    I see lots of delays and comments in the code about the Scuznet driver needing various delays - Those delays are almost all commented out. 


    Those were from early on when I was still reverse-engineering the protocol. The real device has those pauses and I initially tried to emulate them, but when things worked without them I just commented those out.


    On 2/28/2021 at 1:14 AM, superjer2000 said:

    2) Any thoughts on what is causing the SCSI bus/Scuznet to go into a panic freezing up the ScuzNet?  If I can get that sorted then adding in that delay into the packet receive routine would make this pretty stable and as noted, performance for me was pretty good (although when Chopsticks made the change to his firmware his AppleShare download speed seemed much lower than mine.


    This might be caused by a stuck REQ/ACK handshake, which would keep the scuznet stuck in a data transfer and showing a steady activity light. This could be worked around by enabling the watchdog timer, which I'll add to my TODOs. If the underlying issue causing the lockups is fixed, I'm guessing this problem may go away on its own.

  19. 13 hours ago, superjer2000 said:

    "I would love to solder a few more Scuznet adapters" - said no-one ever. :-)  


    Yeah, I completely agree. This board was the first "big" project I tried with 0605 components, and oh man, they really push the limit for what I can do by hand. This is definitely something that would benefit from factory assembly, at least of the passive components, or reflowing in one of those sweet DIY ovens I keep seeing around the Internet.


    13 hours ago, superjer2000 said:

    All of that being said, soldering some components to a board is obviously nothing in comparison to the hardware design, protocol reverse engineering and software development that Saybur undertook to create (and then share) this device.  I can't think of many 68k projects that are as ambitious as this one and I am in awe that it exists.  Thanks Saybur!  I'm looking forward to getting these up and running.


    Thanks for the kind words! I'm really glad this project has been interesting to people. I had always wanted an adapter like this and was not thrilled with how expensive they've gotten over the years. For your boards I'd love to hear how things go with the final assembly too.

  20. Whoa, unplugging the Ethernet cable unfreezes the mouse? That's really weird. The firmware ignores the link detection information in the PHY and never reports anything other than the link being present on the SCSI media sense command, so unplugging should have no effect on program flow at all, either in the Mac driver or the firmware. @cheesestraws may be on to something here: maybe this is a weird hardware/software interaction?


    To be 100% sure that there isn't some outside influence, can you try this on a network that contains only two Macs, one with the scuznet and the other using standard onboard Ethernet (or whatever), running bare-bones vanilla MacOS? That should narrow the possible sources of problems, or at least remove network gremlins from the picture.

  21. The network cable is very interesting. Does that happen every time you try it? A crash immediately if the cable is connected, and a crash on restart/shutdown if the cable is disconnected?


    One other thing: does the on-board LED start blinking a half-second on, half-second off thing at any point during operation? Particularly when the crash happens?

  22. The crash on AppleTalk startup makes me think there is something weird going on with this particular board, FWIW. The test firmware is not comprehensive, it was written quickly to help diagnose soldering issues where pins were bridged or a whole chip was borked. More subtle issues may be missed by it.


    Based on your note about the HDD formatting, I'm assuming the emulated hard drive is working fine. That should rule out most SCSI bus issues and SCSI driver chip problems. Please mention if that's not the case. If the HDD is also not working, those two items probably need checking.


    Another option is compiling the normal firmware with debugging support and hang a listener off the UART test pin, and monitor what the board is sending. This is dumb printf() type stuff, and might also not report anything all that useful, but it might give a hint as to where things are crashing.

  23. Based on what you're describing, I'd guess there is a hardware problem on the new board. I added a test dongle design and firmware for helping to diagnose these issues on Github; if you have a chance, try that out, it may give a hint as to what's going on.


    The documentation is a little out of date: the latest firmware should support the commands needed to format using generally-available tools. I've used the standard HD SC utility with the usual ResEdit modification, but I'll add the SCSI Director 4.0 note next time I update Github.



  24. When I had trouble doing this, I had to get into scsi2sd-util and hack in additional debugging to get more than the a terse "things didn't work" message. I don't have the modified versions I made, unfortunately.


    To roll your own, in scsi2sd-util.cc there's a (myHID->scsiSelfTest() ? "Passed" : "FAIL") statement. I believe the value returned there is the same integer returned in the firmware's self-test, defined in scsiPhy.c, where certain bits are set if particular tests failed. You could change the line so instead of doing a pass/fail conditional it just writes the results of scsiSelfTest() to the console so you can check which bits are set.


    In all cases with me the problems I had were with with bridged / dry pins on the main SoC. The 0.5mm spacing is tight and it's hard to see if there is a problem there, even using a loupe.

  • Create New...