Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by saybur

  1. 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.
  2. 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.
  3. 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.
  4. 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 keyboar
  5. 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.
  6. 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 o
  7. 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.
  8. 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 th
  9. 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
  10. 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
  11. 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 wou
  12. 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?
  13. 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.
  14. All right, source is up: https://github.com/saybur/scuznet Any questions, feel free to fire away!
  15. 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,
  16. 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 w
  17. First off, thanks for a great writeup, I enjoyed reading through your blog post. This is an *excellent* idea for long term maintainability - the moldering AppleTalk code in the kernel and/or old versions of netatalk are causing headaches for people, and this seems like a solid way to solve that problem. I did have a question about how addressing is working: as far as I can grasp, you're just passing the LLAP packets, and letting the Macs fight it out for LLAP address resolution? Or is there something going on on that front that I'm missing? I know you mentioned this would hopefu
  18. This implementation bit-bangs the interface, mainly to keep away from new old stock hardware. Apart from the microcontroller, all the SCSI control hardware uses jelly bean logic. I wanted to use this project as a launchpad for really learning how SCSI works, so I figured having to handle the physical layer in addition to the logical one would help with that. As for time, I started work on this back in September, when I finally managed to get my hands on the Nuvolink. I would have preferred to find a less obscure device, though I think it was for the best in the end: it turns out
  19. That's really neat, I'd never heard of SMDI before. It shouldn't be too awful to make your own initiator; on the hardware side, things are very similar, with only minor changes in which signals you're required to drive. The initiator logic would be different, but implementing it shouldn't be any more difficult in scope than the kind of thing I had to do for this project. As an example, this board would not be able to act as an initiator the way it's currently hooked up: there are no drivers for /ACK and /ATN, and it doesn't listen to /MSG, /I/O, /C/D, or /REQ, but all of those co
  20. This is all in AVR C, with a tiny touch of inline assembly for a few timing-sensitive operations. The Arduino in the pictures is forced into reset: I'm just using it as a USB UART to get packets from the board to my PC for debugging.
  21. Some more progress: the unknown extended message can apparently just be ignored. If the firmware does that instead of sending MESSAGE REJECT things... just work. That's not a very satisfying answer and I hope it isn't creating a hidden problem. On the plus side, large transfers are working, and the files are intact on arrival. Huzzah! I also did some work on the packet reception code in general. The real hardware has some long wait times (~100-150us) as it switches phases during packet reception. I was originally emulating this behavior. However, those do not appear to be im
  22. It's a pair of cheap 8 bit USB logic analyzers, using sigrok to capture the data to VCD files. You can see them in the pictures attached directly to the 50 pin internal SCSI port on the open-top Mac LC on my desk. I've got some separate programs I threw together to merge the captures, sync them based on a shared line, and decode the SCSI information. This method only gets 15 lines of the 18 SCSI lines, but /ATN, /RST, and /DBP can be (mostly) inferred from the other signals. The bigger problem I've had is getting the captures reliably synced up: the clocks on these units must be really bad
  23. Well, I think I've identified the problem. During packet reception, after a DATA IN phase when the packet is sent, the device moves to MESSAGE OUT and usually gets NO OPERATION. It then moves either back to DATA IN to send another packet or moves to MESSAGE IN, sends DISCONNECT, and releases the bus. However, there are times that instead of getting NO OPERATION it gets an extended message code (0x01). The emulated device treats that as an error, sending back MESSAGE REJECT: apparently, that is not OK, and causes subsequent operations to fail. After implementing basic extended message hand
  24. The device responds as through it were two different targets, one a HDD and the other the Ethernet device. To the computer they appear to be separate. This PCB version is designed to be put into one of these cases when finished: https://www.hammfg.com/part/1455L802 I was hoping that one of these should (hopefully?) remove the need to equip a computer with a SCSI2SD at all. Final testing will require the HDD emulation being finished, but the SPI clock for the SD card should allow speeds in the range of ~1.5 MB/s. That's not great, but I can't imagine pushing a Mac
  25. Per request, here are some rough speed tests. All are on a Mac IIci running 7.5.5, copying files from the network to the local HDD (SCSI2SD v4 clone) via the devices below. The remote computer is a PC running Basilisk under Linux. The files being copied are a directory of several items ranging from ~800kB to 5MB. I timed the transfers with a stopwatch, so take the results with a grain of salt. Farallon EtherWave NuBus Card: 38.6 MB in 1m53s, or ~2.73 Mbit/sec Nuvolink SC, real hardware: 38.6 MB in 4m23s, or ~1.17 Mbit/sec "scuznet" emulated device: 5.1 MB in 35s, or ~
  • Create New...