Jump to content


  • Content Count

  • Joined

  • Last visited

Recent Profile Visitors

157 profile views
  1. 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?
  2. 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.
  3. All right, source is up: https://github.com/saybur/scuznet Any questions, feel free to fire away!
  4. 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!
  5. 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.
  6. 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 hopefully be the start of a full userland AppleTalk stack, so was the routing side of things something further down the pipeline? (and if I'm off base, feel free to correct my ignorance, I probably need to crack Inside AppleTalk again sometime...) As for your comment about proper LocalTalk networks: it's been a while since I've messed around with it, but at one point I came up with a pretty simple piece of hardware to take raw SDLC data off the LocalTalk network and send it into a standard UART. The idea at the time was to offload the real-time Manchester decoding onto a small microcontroller, so a piece of userland software could participate in the LocalTalk network. I got far enough with it to be able to decode packets and read them with an Arduino, but I got distracted with other projects, and I was not looking forward to the looming problem of how to get the LLAP data into a format that could be useful. It looks like you may have solved my problem! Anyway, awesome job with this, and best of luck getting the code release signoff soon.
  7. 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 the communication method is, like, a absolutely perfect match for the way the ENC28J60 chip works. And thanks to everyone in this thread for the encouragement, it's much appreciated! Fixing up the HDD code now, which I have working well enough to finally be able to read and write files from the OS - playing Barrack on a IIci is a glacial experience, but it at least works as a proof of concept.
  8. 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 could be changed around if needed. SCSI2SD boards (at least the GPL'd versions) should have the hardware hooked up to act as an initiator if they wanted to, though I don't think that's been done in any firmware that's been released. If you're looking for a board that already exists to do some messing around with, that might be a productive avenue to explore.
  9. 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.
  10. 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 important, and after commenting them out packet reception is noticeably faster. A speed test using the same dataset as in previous post: "scuznet" emulated device: 38.6 MB in 3m49s, or ~1.35 Mbit/sec That's about 15% faster than the same test on the real Nuvolink, which I'm pretty happy to see! It'll need more testing to verify if there's an actual improvement overall, but it's encouraging none the less.
  11. 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, since they drift quite a bit over a capture period.
  12. 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 handling, the exact message bytes sent each time I've observed this are [0x01, 0xFF, 0x00, 0x2B]. Unfortunately, that is a vendor-specific message, and my cheap logic analyzers are having problems catching the real device performing this relatively rare step. I'm guessing it's probably just "resend last packet," so I'll do some more debugging and see if grumpy-pants over here will accept that response
  13. 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 Plus/SE/IIsi/etc much beyond that on the SCSI bus anyway. That said, the schematic will be open, so anyone wanting to experiment with alternate approaches will be welcome to do so! I'm guessing it would be possible, but it could cause signal integrity issues when using faster transfer rates. As it was, the SCSI-2 spec has limits on cable length due to propagation issues, which having a split up topology couldn't help with. The 25 pin SCSI port also wasn't well regarded by SCSI fans at the time due to having bad grounding, so anything that adds to that might be troublesome. The command protocol that Nuvotech used doesn't do hardly any offloading to the device. The main commands the driver executes are a vendor-specific CMD 0x05 command that dumps a packet to the device for sending, and reads data back by having the device reconnect and write a slightly modified version of what it found on the wire. Almost all processing is done on the computer CPU. I do wonder if other devices do things differently, given how little standardization appears to have happened with these things.
  14. 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 ~1.17 Mbit/sec Note that a single file was used for the emulated device, because this testing revealed there is a major firmware bug: larger batches of files are causing the device to lock up. I'll have to dig into that one and figure out what exactly is going on. That's what I get for only testing with smaller text files initially, lol. Firmware bugs, whee!
  15. It should be significantly faster. AppleTalk caps out at 230.4kbits/sec, so maximum throughput on that should be something like ~28 kilobytes per second. You do have me wondering though, so I'll check and see how this performs vs. the real Nuvolink SC and a NuBus Ethernet card and report back.