Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by saybur

  1. 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:
  2. 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
  3. 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
  4. 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
  5. 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?
  6. 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.
  7. 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.
  8. 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
  9. 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
  10. 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.
  11. Thanks! I'm not sure the circuit could fit into that form factor easily. What is the use case you're thinking of?
  12. 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.
  13. Definitely. My only concern with USB is the power negotiation step; I figure this board has a peak draw of ~950mA, including the terminator, which would exceed standard USB's 500mA. When you get into the higher power levels, AFAIK you have to actively negotiate with the supply, which is more complicated than just throwing a barrel jack on the board and calling it a day. USB-C has the CC pins to indicate power availability, and I was considering going that route as an alternative. I've heard horror stories about bad USB-C cables, and I'm not 100% sure I understand the spec, but from
  14. I'm doing a revision of the hardware to add extra features and correct some bugs. @ronan also made good observations about things to fix, which is appreciated. Here's the list of what I'm working on: Move from KiCad 4 to KiCad 5, and change the footprints to match the awesome new library versions. Add USB for reprogramming & config updates (not sure if USB-C or just micro at this point, and I'm uncertain about powering via USB or leaving the barrel jack). Change the linear regulators to use more reasonable packaging, they're significantly oversized. Fix the oversi
  15. That's mostly how I figured it, assuming a 250mA load: (5-3.3) * 0.25 * 235 to get the 100C rise. The 250mA was just a ballpark figure, based on the max 180mA the ENC28J60 uses while transmitting plus a random amount extra; you'll probably want to run through what the max current consumption is for the various components to build a power budget and then add a bit extra for safety.
  16. I'd suggest swapping the MIC5319 for an alternative 3.3V regulator. SOT-23-5 won't be able to reject all that much heat; if you figure a max draw of ~250mA and a 5V input voltage (worst-case after the diodes), that's a ~100C temperature rise for that package. An alternative might be the MCP1825: it has minimal capacitor requirements, is available in SOT-223, and has a similar dropout voltage.
  17. I'm not very knowledgeable about the Mac driver side of the equation. There might be a hack to make the driver skip the gesalt check, but if there is I'm not aware of it. Another avenue might be to try the Focus drivers instead. From what I've read the Focus EtherLAN SC is basically just a rebranded Nuvolink SC, but I've never tried using their drivers on a scuznet board. I suspect they probably changed some stuff in the INQUIRY response to keep this from being easy.
  18. Oh, OK, I get where that's going now. I'd suggest not doing it that way; there are situations where you will need to read the data bus when C/D is not asserted. It would probably be easiest to assign it to a free I/O pin to maximize your control. Yes, they're specific to the 2.63V variant. Standard SCSI terminators are 110ohm, so that'd be the likely choice.
  19. I haven't had this ever happen to me, usually it just complains about the device not being present. What computer and OS are you running? I've been badly distracted by the (lame) real world but I did manage a quick pass through the schematic. I'm completely unqualified to look at the STM32 side of things, so the following are just observations on the SCSI / Ethernet parts. Like I've mentioned elsewhere in this thread, I'm no expert on this or anything, so definitely feel free to ignore the below advice without any concerns! All the driver chips are LS series in t
  20. Awesome, thanks to both of you for that information. I'll take a look and let you know if that did it.
  21. Great graphic, that's how I'd do it. Since the 245 is permanently reading from the bus you should be able to tie DIR without a problem. In case the bus floats for some reason (bad termination?) you might want to toggle /OE only when you know data is on the bus. The LVT transceivers have a 10ns/V transition time recommendation with "outputs enabled," so the current scuznet firmware does toggle /OE to avoid having the outputs on except when necessary, in case the SCSI bus is being sluggish during transitions. I don't know if this is strictly "needed" or not. For bus reading, the buff
  22. Thanks! The original design used the 574 with the latch clock hooked to /ATN, with the idea being to potentially fiddle with doing (slow) synchronous transfers; during periods when the board needed to read when /ATN was not active, an extra 74126 gate was used to block /ATN and let the microcontroller drive the latch. In the end, I felt like this caused more problems than it was worth, so I pulled the /ATN hookup from the released board but left the 574 there to minimize the disruption to the code. If I had to do it over again, I'd choose the 74LVT245 just to save an I/O
  23. Yay, awesome! Let me know if it causes any more grief, and glad I could help.
  24. All right, the most recent commits on Github have a much more comprehensive test suite ready to go. It requires building a simple loopback adapter for the DB25 connection, with instructions in the repo. At the moment, this will check all of the SCSI lines and the connection to the Ethernet controller, but not the memory card. Hopefully this will highlight whats going on if its a problem with the hardware.
  25. I've added a "testing" subdirectory to the Github repo that can be used to build a special firmware for doing post-assembly verification of a PCB. It's not comprehensive at all right now, but my goal is to expand it to cover as many of the connections into the microcontroller as possible. Boards like this have so many small parts that they are really annoying to debug if the hand-soldering is not perfect; I remember assembling some SCSI2SD clones a few years ago, and how much I appreciated having the scsi2sd-util helping me out when I had dry joints on some pads. @landoGriffin, I h
  • Create New...