Jump to content


  • Content Count

  • Joined

  • Last visited


Recent Profile Visitors

492 profile views
  1. 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 pack
  2. 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?
  3. Thanks for checking this. That matches here, where things seem fine on faster/newer systems - seems to work on a LC 475 too. 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
  4. 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. 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:
  5. 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. Those were from early on when I was still reverse-engineering the protocol. The real dev
  6. 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. 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 he
  7. 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 usin
  8. 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?
  9. 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.
  10. 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.
  11. 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 s
  12. Ah, I get what you guys are aiming for. Just to explore the concept: It looks like a 2.5" HDD is about 100x70mm, which is basically the same size as this board, so the circuit could probably still fit OK. You'd want to keep the base SCSI interface and SD card, but rip out the ENC28J60 and replace it with some kind of wireless access device. That part might be problematic; the ESP8266 type devices have their own TCP/IP stacks, but the Nuvolink protocol assumes lower-level access to the network. It looks like some people have figured out how to make the ESP8266 enter promiscuous mode
  13. On the power side, after doing some more research I don't believe the USB-C approach will work easily. The ADC pins on the Xmega are all blocked in the current layout and I'm not keen on changing that if I can avoid it - it took quite a while to arrive at the current layout, I'm pretty happy with how things are, and it has been tested to work. There are some external ICs to support USB power but they seem to all be in hobbyist-unfriendly packages that would make this (already tricky) board harder to solder. As for sourcing from TERMPWR, after doing the math I'm leery of doing that.
  14. Thanks! I'm not sure the circuit could fit into that form factor easily. What is the use case you're thinking of?
  15. No, I think you're right, from what I've heard most chargers (especially cheap ones) don't seem to follow the rules and just deliver +5V until they hit their limits (or Bad Things happen, the Big Clive YouTube videos on those things are hair-raising). I'm more concerned about plugging the board into a computer for programming, where the amount of power available is likely to be restricted to the USB spec.
  • Create New...