Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by saybur

  1. I've been spending some time recently making a SCSI to Ethernet adapter using all-new hardware. I managed to snag a Nuvotech NuvoLink SC off eBay, and after doing some analysis of how it talks with the driver over SCSI, I've decoded the vendor-specific parts of the communications protocol and implemented a compatible version on a custom PCB. Here's some pictures of the board and test setup: https://imgur.com/a/ZJFfrSG The board is based on a ENC28J60 Ethernet chip and XMEGA AU series microcontroller, with a SD card thrown in the mix for good measure to emulate a hard drive. Networking has been tested under System 6 and EtherTalk seems to work fine with an unmodified Nuvotech driver. That said, this is definitely just a prototype, so there are plenty of things that still need to be done: Test with MacTCP or OpenTransport on newer versions of the OS. There is conflicting information I've found online about how compatible this particular driver is. See about compatibility with other SCSI to Ethernet adapters. Focus bought Nuvotech and appears to have re-released everything under their brand, so getting their driver working would likely be pretty easy. I'd ideally aim to get compatibility with a driver known to be stable with Open Transport in particular (if one exists). Other, wiser members might have some ideas on that. Finish the HDD emulator, which is only partially working. Spin a board revision that has USB for firmware updates instead of the vendor PDI interface, and fix some of the other annoying problems I caused myself with the hardware design. Fix the significant bugs that I'm sure still are lurking in the code. It's been a bit of a slog to get to this point, and I mainly wanted to share this with the community and see what others thought of the project. Plus, I was pretty happy to have pictures of this thing working: I've been banging my head on my keyboard with it for a while. My short-term plan for this board is to release the protocol documentation, design, and code under GPLv3 and let others poke around with this. I'll be working on getting the firmware into a slightly nicer state over the next few days and then throw all the files up on Github. I do not have any interest in making this to a kit / product / etc: if anyone would like to take a stab at that, you'll be free to do so under the license. At minimum, the protocol documentation will hopefully be of some value to the community. If anyone has questions or comments, please fire away. Thanks for reading!
  2. 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 have a feeling this won't cover what you're experiencing yet, but I hope to get the control lines added to the board test firmware here over the next couple days.
  3. Yeah, I agree that makes power issues seem way less likely. For the UART, 500kbaud is correct, but the device uses binary, not ASCII. Try that and see if data appears; debug.h has the symbol meanings. The LED will light during startup very briefly and again during bus transactions. Non-data transfers are fast enough it usually will just flicker briefly.
  4. I pushed an update to Github to help narrow down if this is a power problem. The Xmegas have a nice register that shows what the cause of the last reset was; I added a handler so if a reset was triggered by a brown-out the device will halt and go into a LED blink loop (1/2 sec on, 1/2 sec off). I figure a brown-out is a Bad Thing no matter what causes it, since it probably indicates the PSU is bad. If you could, try the most up to date firmware and let me know what you see. If you don't get the looping blink, could you let me know what state the LED is in when the system freezes?
  5. It should be 500kbaud, but it's mostly just symbols at certain code points. I should really get a proper debugger some time... Thinking about this more, I wonder if it might be a power problem: the Ethernet controller draws extra juice to transmit, and it might be enough to cause the MCU to do a brown-out reset if the USB power source isn't up to the task. I was thinking of adding an LED pattern on reset so you could see it, but if you tie into the debug line you should be able to observe a reset that way too.
  6. No, it should be working at the point you're at. I don't have the firmware in front of me, but as far as I can recall the weird INQUIRY response is normal. Basic bus transactions must still be fine to get the info from the Nuvolink utility, so I'm guessing it's not anything with your soldering. Are you using the most recent commit in the git repo, and did you compile with debugging enabled? I'll get my board out tonight and see if I can get some additional stuff added that might be helpful in figuring this out.
  7. saybur

    Arduino SCSI device - Work in Progress

    Yeah, just in the documentation so people know not to connect external terminators. Apart from asserting /RST anytime another target tries to talk I doubt there is a way to force having just one device. If the transfer speeds are low you might be able to get away with some pretty nonstandard termination that wouldn't exceed the power budget. Maybe try something super simple, like 1K pull-ups to 3.3V? There are transmission line effects to consider, but that's black magic I have no experience with. AFAIK there were some Macs that had automatic termination supplied by the mainboard as well, which might cause grief in some setups.
  8. saybur

    Arduino SCSI device - Work in Progress

    The STM32F103C8 is only rated to sink up to 150mA total across the device; even with only 1 active terminator on the bus that limit will probably be exceeded. It might be worth limiting the SCSI bus to just this one device and omit the terminator? Alternately, buffer chips driving the output lines would also fix the problem, but that'd obviously increase complexity and cost.
  9. The old school advice on tantalums was to derate by 50%, so maybe this is just an instance of failure from running too close to the margins, even from the factory? It might be worth going to 20 or 25V on the replacements.
  10. saybur

    ADB switch box

    Microchip has a great writeup talking through the low-level behavior of the bus if you end up making a microcontroller project: http://ww1.microchip.com/downloads/en/AppNotes/00591b.pdf If you tackle this, maybe a multicore chip like the Propeller would be a good fit to do the software decoding/encoding of the ADB timing? I don't know hardly anything about them, but it sounds like having separate execution "threads" would be good for keeping track of the mess of different signals all going at once.
  11. I personally use and like the Olimex AVR-ISP-MK2, a clone of the real AVRISP mkII. Mouser and Digikey have it for ~$24 and it is useful across the main 8-bit AVR line: it does ISP for regular AVRs and PDI for Xmegas like on this board (though not UPDI on the new mega0/tiny1 chips). Most of the tutorials out there are for the standard AVRs using ISP, but I did see a Raspberry Pi program for PDI here: https://github.com/DiUS/xmega-pdi-pi2 It looks like it hasn't been updated in a while though.
  12. saybur

    RaSCSI Development Thread

    Great to hear, I'm glad people are getting use out of it. Let me know if you see holes in the docs, I can fill those in from the original hardware if needed.
  13. saybur

    IIci ADB Issues

    I've got a troubled IIci and was hoping some wise soul here might have a good idea about what to try next. This system boots up but does not register anything over ADB. Shaking the mouse during or after startup does nothing, nor does typing anything on a keyboard. After the machine boots, pressing the interrupt brings up the usual prompt. This keyboard and mouse are my bench ones I use for testing machines and work on other systems. I verified that 5V is present on the ADB power pin and ~4.7V (or something similar, I don't quite recall) is on the data pin. Soft power from the keyboard also works fine. I hooked up my oscilloscope to the data line to watch what it was doing, and it is... kind of weird. The edges are nice and clean but the data doesn't seem to make any sense: the normal sync, command byte, and stop bit are all there, but the system keeps sending a $FF command byte over and over again, long after the computer has finished booted. After shaking the mouse during bootup I can see it stretching the stop bit to do a service request, but the system never responds, and just keeps spamming $FF. The timings look OK, including between the transactions. It's been a while since I worked with ADB, but I'm pretty sure $FF is an illegal command - Inside Macintosh says the addresses go through $E, and do not include $F, for what that's worth. To get a comparison I hooked up my working IIci and snooped ADB on that. It started by sending $1F, which makes more sense, and I did see a longer transaction when it probed the mouse without getting a service request. The mouse worked after the system booted up. This system came to me untested and I've done the normal work done on it: I've replaced the existing electrolytics on the logic board, scrubbed affected areas with IPA, recapped, and dried 48 hours. There was more green rust than normal on several areas near the caps, which was also cleaned up. This includes the area near the ADB chip, which was quite green, but I'm fairly confident it has been extensively cleaned. The existing Astec PSU has been swapped with a known working Astec from the good IIci for testing. In operation it is showing 11.9V and 5.1V on the main rails (this is not a recapped unit, but I do have caps in the mail for both power supplies and intend to do that later). HDD, expansion cards, and cache card have been pulled. I tried this with both the memory that came with the system and other, known-good SIMMs. One other thing: when cold booting today, I did get a boot chime, followed a second or two later by death chimes and a black screen. The system was OK when rebooted. I left it off for 15 seconds and tried again, and the same thing happened, but the time between the boot chime and the death chimes was much longer, like 10 seconds or so. It didn't do it again afterwards, and did not do it before when I was first testing this machine. This prompted me to swap the memory with good sticks and leave the computer alone while I ate dinner. When I came back, same basic thing: boot, then death chimes, then it was OK after repeated startups. Sorry for the long post, and I appreciate everyone who took the time to read it. If you have an idea, feel free to fire away.
  14. saybur

    RaSCSI Development Thread

    Hey, a fellow Iowan! I'm glad to hear you were OK, that was one wild storm. We just got power back a few hours ago in Ames, so hopefully they'll get things fixed for you soon.
  15. saybur

    RaSCSI Development Thread

    As long as you're using the 641-1s the bus conflict shouldn't be a problem, but the Pi may not be able to see the Mac responding on BSY while PI-TAD is high. That looks like the same setup as with the standard RaSCSI, so I wonder if it just doesn't support reselection? If you're wanting to save on costs, maybe a different approach is dropping IC1 completely and modify the code to not drive or listen to DBP. It will break support with standard initiators but (AFAIK) on-board Mac SCSI doesn't care about the state of the parity line. Alternately, there are plenty of spare drivers on IC3, so you could modify things to just drive DBP but not listen to it during most operations. Sorry to chime in on this after you've ordered boards BTW. I have gotten really frustrated before with doing an order and *then* getting some wild idea of something that could have been changed.
  16. Sorry about that, I updated the BOM after making my prototype but didn't change the Makefile. Fixed on Github. So you're aware, I have not tested the 64A3U (my prototype uses the 128A3U) but the chips should be identical except for the extra memories, which the firmware doesn't use.
  17. saybur

    RaSCSI Development Thread

    I'd suggest not making that substitution. There are a couple things that might be hazardous: Even the wimpy TTL drivers on the 245s can probably drive the Raspberry Pi GPIOs beyond their maximum voltage (3.3V). It might be working currently via the RPi protection diodes, but that's not safe to rely on. The SCSI spec requires BSY, SEL, and RST to be OR-tied, since they can be driven low by multiple devices simultaneously. I'm not familar with how the RaSCSI works, so depending on how careful you are with the PI-TAD and PI-IND signals you might be able to avoid a bus conflict this way, but it could cause problems. For example, this setup couldn't safely execute a reselection of the initiator, since that requires driving I/O low while the Mac would be needing to drive BSY. The SCSI spec requires drivers capable of sinking 48mA, but the 245 drivers are only rated to 24mA. You might be able to get away with this with just one set of terminators on the bus, but if more than one set are on they'll be pushed beyond their maximum. Disclaimer: I'm not an EE, just a hobbyist. I'd welcome correction from anyone more knowledgeable if anything I said is wrong.
  18. I finally got enough additional commands implemented that a patched copy of HD SC 7.3.5 can format the emulated drive, which is so much nicer than having to pull the SD card and have to format it on a separate computer. I also did some more speed testing on my IIci and got ~1.25MB/s on reads and ~768kB/s on writes. The same computer also has an older SCSI2SD clone board, which averaged ~1.15MB/s read and ~1.00Mb/s write performance. Testing was done with 100-600K transfer sizes using SCSI Evaluator 1.07. I'd take these results with a grain of salt, and I'd be curious if anyone reading can verify similar SCSI2SD performance in a IIci. Future plans include increasing write performance and seeing if any of these tweaks can be applied to the Ethernet controller as well. I also want to test this on a Plus and see if the thing works with the quirky SCSI implementation that computer has. I hope to get my Plus recapped in some free time coming up, and I'll see what that testing shows.
  19. I just pushed an update to Github that gets the speed to ~950kB/s on my modern desktop with an AVA-2906 host (originally it was more like ~550kB/s). Theoretical maximum with the microcontroller's CPU clock is probably something like 1.8MB/s, so there is still quite a bit of room for improvement. Also, I'm also planning on getting mode information into the firmware to allow formatting and the like: Linux is not happy with this device not providing it, though AFAIK it isn't strictly required by the spec. There are also plenty of other bugfixes that likely need to be applied as well.
  20. One is 2.63V for the terminator, and the other is 3.3V for everything else. These could probably be switching regulators rather than big old linears, but I'm not familiar with switching regulator design and I didn't want to mess with that as part of the project. The weird 2.63V voltage is used instead of the standard 2.85V on the terminator due to Digikey not stocking 110ohm 10-SIP bussed resistors, so I went with an alternate configuration using a lower voltage and more common 100ohm parts (this is supported as part of the spec, though I've never seen a device using it in the wild). It would be trivial to replace the two regulator adjust resistors and move to the standard 110ohm resistor packs if desired. Power consumption has not been measured, but it likely isn't all that high: figure ~100mA for the SD card, 180mA for Ethernet, and ~480mA for the terminator as the main power sinks. Keeping with the KISS philosophy on the power side, the regulators are oversized and have pads for extra heatsinks in case that was necessary, but during testing they barely got warmer than ambient air while outside the case. If a reference would be of interest, I've added the BOM I used when making my boards to Github. That should more or less be accurate: I dropped the unnecessary 128A3U XMEGA part down to 64A3U, as the extra memories are not necessary for the firmware.
  21. I don't really know anything about A/ROSE (or much about classic Mac driver development). Was that specific to NuBus hardware, or did vendors make drivers for SCSI devices as well?
  22. That's actually easier than receiving, it turns out. I'll get my old notes together and post the work thus far in a separate thread to keep from derailing this discussion.
  23. All right, source is up: https://github.com/saybur/scuznet Any questions, feel free to fire away!
  24. I do vaguely remember the timing on LLAP being oddly tight for hardware of that vintage. I'm not familiar with the Zilog chips they used for serial, but maybe the low-level handshaking was done completely in hardware, so they figured they could get away with very low timeouts to improve performance? I'd be interested in hearing how that part of the project goes. I don't know much about the ESP8266. To do the line decoding, you do need some decent control over timing, or at least have a pretty good idea of how long your code will get interrupted by the WiFi handling. At minimum, it should be possible to strap a micro to the ESP module and do things that way to get more control. It's a pretty cool idea though: LocalTalk over WiFi, what a world! And safe travels as well!
  25. It's honestly just due to my lack of familiarity with the ARM ecosystem. I'm not an EE, just a hobbyist. I've done several projects with garden variety 5V AVRs, so it wasn't nearly as big a leap for me to do it with an XMEGA instead: I wanted to focus on learning the SCSI bus and figuring out the specifics of the Nuvolink, and not have to fight an unfamiliar MCU in the process. I agree with you and @technight that this would be objectively better from a technical perspective on an ARM chip, and hopefully the protocol documentation and/or the source for this board will be useful for anyone wanting to take a stab at that. Also, man, I do feel bad for the XMEGA designers. They are super cool little microcontrollers, but they were just too little, too late to really take a slice of ARM's pie. If anyone reading this is familiar with AVRs and wants to see what that CPU core can really do, they're worth at least playing around with. The ASM in this is minimal, and is just there for time critical access to the MCU's protected registers. It would not need to be ported. And thanks to both of you for the nice comments For anyone following along, everything basically works now on my test setup: I'm booting my IIci off the prototype, downloading files from the server, unpacking, playing Swoop off the drive, etc. I'm working on finishing up a minor PCB tweak that fixes the most egregious errors it and then this should be ready to post. Edit: @techknight, not technight, sorry.