Ethernet via SCSI2SD V6

[PotatoFi]

Over in the RaSCSI thread, @inertialcomputing mentioned that the SCSI2SD has USB support, and could theoretically support a USB ethernet adapter to function as a SCSI ethernet device. This is pretty intriguing... in compacts (Classic, SE, Classic II, SE/30), there are two major hurdles on these machines: storage and network connectivity. PDS cards are rare and super expensive, and when it comes to hard drives, it's not a question of if they will fail; it's a question of when.

The SCSI2SD v6 sells for $100, which seems like a lot until you consider that it could replace both failing storage devices AND expensive ethernet cards. I sent an email over to the SCSI2SD developer about it, and there are two routes forward: a USB ethernet adapter via the USB header, or swapping the microcontroller for a similar model that supports 10/100 ethernet.

Challenges involved with going the USB ethernet adapter route:

• The SCSI2SD has an unpopulated USB header that has never been tested; the original intention was for USB flash drives
  
• Would have to write a USB ethernet adapter driver (but there is possibly existing code available)
  
• Implement SCSI commands (there's no documentation about this, so it would be pretty difficult)
  
• Possibly writing System 6/System 7 ethernet drivers (sounds hard)
  

Challenges involved with going the microcontroller route (swapping STM32F205 for a STM32F207)

• Not sure if the correct pins are broken out, even the SCSI2SD developer isn't sure as this was beyond the scope of his design
  
• Implement SCSI commands
  
• Write System 6/System 7 ethernet drivers
  

So... possible, but unless we had some real development talent, it's not going to happen. Me personally: if I could contribute $50 to a project to make it happen and buy a $100 SCSI2SD V6, I would do it in a heartbeat. That's a $150 investment - the same price as an Asante card for my Mac SE, and if it helped open up the door for others to get network support, that makes it even more worthwhile.

As for SCSI commands, I do have a Farallon EtherMac/SCSI, which could possibly be used as a starting point for figuring out SCSI commands. If that device could be emulated on the SCSI2SD, then that could remove the need to System 6/System 7 drivers. It just depends on how difficult the protocol analysis on that piece of hardware is. Way outside of my skillset. 

 

[Trash80toHP_Mini]

Drivers have been the choke point at most every turn for projects like this. SCSI to Ethernet might be a workable wedge for a hack. Tools for disassembly of existing drivers have come a long way and folks around here have been doing that on several projects. IIRC SCSI based solutions are slow? In that case v6 with Fast/Narrow SCSI2 would be a winner. I've been pushing the notion of SCSI 2 for the 68030 PDS for some time as the last death zone mountain to be scaled in the quest for the ultimate SE/30. Fast/Narrow SCSI 2 NuBus cards aren't made entirely of unobtanium as is in the case of the JackHammer.

I'd ask the developer if supporting a Raspberry Pi Zero W on the USB connection to do the deed would be too much trouble? Such might reduce development from the SCSI2SD side of things from the near-impossible to only the level of seriously non-trivial. Developing drivers for Pi is within the skillset of many here and the new Zero W has Wi-Fi built in at an insanely low cost.

edit: might as well interject a bat-scat crazy tangent right off the bat. as it were  :blink: Can't think of the name offhand, but one of the SCSI to Video solutions ran on non-color compacts. Might we only need the driver to hack? Zero W also has a handy HDMI port.

HEH! Beat the edit window! http://lowendmac.com/2013/scuzzygraph-and-scuzzygraph-ii/

 

[paws]

The problem is mainly convincing the Mac to speak ethernet across the SCSI bus and getting the STM32 to turn that into into something we can use. Depending on what actually goes over the SCSI bus, this can be quite trivial or require lots of reverse engineering.

Networking on the STM32 side is not too much of a problem, IP stacks and drivers for USB networking devices exist in the open,I've tried turnkey demos for at least ChibiOS. I'm not sure what the Pi would do, although I suppose it can act as a cheap and flexible USB->Wifi dongle.

Scuzzygraph is interesting, but it says that it has an "intelligent graphics processor" so unless you're emulating that on the "modern side" of the equation its drivers aren't going to be much use. But it is an interesting concept.

 

[Trash80toHP_Mini]

I'm not sure what the Pi would do, although I suppose it can act as a cheap and flexible USB->Wifi dongle.

I was thinking that having SCSI2SD hand off the workings to Pi at a second SCSI ID would make doing so on v6 a worthwhile enhancement/economies of scale inducing improvement to the v6 product an enticing proposition. Opening up driver development to the Pi crew would be a more of generic application/improvement to the v6 product for all its many applications outside the Mac community.

Pi amounts to an "intelligent graphics processor" as it stands, no? Anything that does anything out on the SCSI bus requires an intelligent processor by definition. How complicated that might be when it comes to turning QuickDraw routine input across SCSI to HDMI signals is far beyond my ken, but development is already proceeding to same from NuBus in another thread. To me, getting that input funneled throut the SCSI port seems more the problem than implementing the very well documented QuickDraw side of things on Pi/whatever.

 

[PotatoFi]

I'd ask the developer if supporting a Raspberry Pi Zero W on the USB connection to do the deed would be too much trouble?

Thanks for your input, but there's existing discussion about using a Raspberry Pi in conjunction with SCSI here. In the interest of staying on topic, let's discuss the Raspberry Pi options over there. I'll avoid going into the noted downsides of using an RPI here because they've already been discussed in the RaSCSI thread.

The problem is mainly convincing the Mac to speak ethernet across the SCSI bus and getting the STM32 to turn that into into something we can use. Depending on what actually goes over the SCSI bus, this can be quite trivial or require lots of reverse engineering.

I wonder at the possibility of emulating Farallon EtherMac/SCSI on the SCSI2SD. E.g., looking at how the Farallon driver talks to the EtherMac/SCSI, and just developing firmware for the SCSI2SD V6 that causes it to behave like a Farallon EtherMac/SCSI. Then the 68k driver problem is sorted. So the path to functionality looks something like this:

• Analyze, document how the Farallon EtherMac/SCSI driver talks to the hardware
  
• Emulate Farallon EtherMac/SCSI behavior on the SCSI2SD
  
• Get a specific USB Ethernet adapter driver working
  

 

[Trash80toHP_Mini]

Sorry, but avoiding any application specific firmware development at all for the v6 product would be exactly on point. Keeping firmware development for v6 limited to supporting Pi as a general purpose product enhancement would be a far more attractive proposition for the developer I would think, no?

edit: I have been following that discussion in the RaSCSI thread, it was the inspiration for my input here. RaSCSI would be an unnecessary, complicated route. SCSI2SD is a right here, right now shipping product with applications far outside the realm of the Mac community. Ask and ye may well receive something more workable for further development far more quickly than the route you're planning?

 

[Trash80toHP_Mini]

One last thought and then I'll bow out: off the top of my head, the USB port is an unimplemented, as yet untested feature option for further v6 development? If not GPIO at least relatively dumb support for Pi I/O is a request worth making to the developer IMHO.

 

[Cory5412]

On the v6, USB is used for:

1) mounting the SD card on a modern computer

2) managing the configuration of the tool, using an application on your modern computer. (same as the v6's micro USB port.)

If @inertialcomputing (who might not be able to reply to this thread, I don't know if they have a non-vendor account, just for awareness) says it can be reimplemented, that's probably true, but that's what it does today.

Unless there's a USB-A header or a USB host header that's currently not implemented, I haven't seen such a thing on my board but I haven't, like, reviewed the design. (re-reading while I work on this post, it looks like there is a header, and now that I read "with the intention of potentially adding a flash drive" I think I reember that being mentioned.)

From a practicality perspective, the less expensive  scsi2v5 is really most practical for almost all 68k macs. v6 becomes "important" only in the highest end and highly upgraded 68k Macs, and even then it's only important if you actually need what it can deliver relative to the v5 and you actualy use the machine(s) for that task.

That said, if it can deliver ethernet and storage to a compact mac, and it can stay at approximately the same price, I can see the value thought changing, even if the storage performance is degraded. I don't know the particulars and capabilites of the SCSI2SD's CPU.

Given that we're in the realm of "hundred dollars for an SCSI2SD plus whatever it'll cost for a new revision of the scsi2sd plus any other hardware involved, I'm tempted to ask another question:

What about a modern localtalk/ethertalk bridge? 

If you can force a Pi or some other device to speak RS-485 you can sort of sidestep the need to add a NIC directly to a single machine and share appletalk-based resources with multiple machines.

I need to work with @wthww on this but there was talk of whether or not it might be possible to do an appletalk-encapsulating VPN. SO, if this hypothetical modern ET/LT bridge can *also* be an appletalk VPN (vtools) then some other different possibilities are available.

The other thing is that it should be possible to get such a bridge to also do MacIP bridging, making TCP/IP connections possible, for FTP, HTTP, email, etc.

It's less sexy than developing a new ethernet card or a scsi NIC but it might do the trick and be ready and available faster plus one bridge added to a localtalk network built out with phonenet adapters can serve the needs of multiple computers, unlike a scsi2SD+LAN scenario where you'd need all that additional hardware for each machine you wanted to set up this way.

And, one more note: the potential use case here extends beyond compacts, I think. I can see this kind of thing being useful for anybody with an LC-class machine and a IIe pds card they'd like to use, or anybody who has any number of PowerBooks, plus just anybody who has a mac that hasn't had ethernet added, or a system where something other than ethernet was the priority.

I don't know how practical this would be but the other-other-other thing I can see is building these with phone jacks on them like some of the existing LT/ET bridges do, with the implication that they'll be at the end of a phonenet chain.  If needed, build a modern one-jack phonenet adapter and then phone wiring of any length can be used. You could potentially build it with multiple jacks, as a modern implementation of one of the starlan controllers that also happens to be a bridge/router.

A Pi might be able to do this with its GPIO pins, but given that the SCSI2SD and floppyemu got built, I would say we shouldn't be afraid to think of this as being something that's not a pi.

The other-other-other thing is like old cisco routers could talk appletalk, and I believe some of them might even have had localtalk jacks, so it might be possible to just find a supply of those and have somebody build up a guide for setting them up.

 

[Cory5412]

As a gimme because I know some people are utterly incapable of resisting integrating the Pi into every single idea, if you could add an RS-485 interface to one and speak localtalk over it, you couuld probably work with the a2server pi image to just run your pi as a localtalk file server for apple II and vintage mac.

 

[PotatoFi]

Ok... this... this makes a TON of sense. Doing a modern AppleTalk/LocalTalk bridge moves us out of the realm of difficult and highly proprietary PDS or SCSI territory, and into something that *maybe* is better understood and easier to work with (AppleTalk/LocalTalk)? And to @Trash80toHP_Mini's point, the Raspberry Pi is easier to develop on.

Moving it outside of the Mac unit resolves the lack of instant-on problems, and pushes it further into the "universal" territory - where everyone can take advantage of the project.

So I'm super unaware of exactly what can be done over LocalTalk and AppleTalk. But for me, getting ethernet onto a Mac is for TCP/IP. I want to interact with the modern internet with my 30+ year old machine (if you're asking why, you're on the wrong forum). Would a modern, Raspberry Pi-based AppleTalk/LocalTalk bridge be about to route TCP/IP traffic?

 

[Gorgonops]

I need to work with @wthww on this but there was talk of whether or not it might be possible to do an appletalk-encapsulating VPN. SO, if this hypothetical modern ET/LT bridge can *also* be an appletalk VPN (vtools) then some other different possibilities are available.

Do you need Ethertalk or is Appletalk-over-IP enough? The latter shouldn't be a problem with most existing VPN software. If you really need to encapsulate DDP packets... I can think of ways to do that using layer2 bridging, I think?

I'm apparently now the proud owner of an LC III. I haven't even quite laid hands on it yet and I'm guessing it's going to need capacitors, but if it works I might have at hand the technical resources to test something out. But to get started I'd need to know what you're thinking in terms of server and client software platforms.

(Edit: I guess you mentioned a Raspberry Pi as a client, so I'm going to assume the architecture would be vtools -> some sort of Linux server -> Internet -> Raspberry Pi client -> ethertalk/localtalk bridge -> localtalk Mac?)

 

[Cory5412]

AppleTalk is DDP. You can talk the apples over serial (localtalk) or over ethernet (ethertalk).

IP is IP, except if you're encapsulating it inside appletalk at which point it's macIP IIRC.

The point, and layer 2 encapsulation might do it, IDK, would specifically be to make connecting to vtools easier for people.

I believe that @bbraun had an appletalk VPN going and I've long meant to hit him up, but IDK if he's active on here any more and so I'd have to sign up for his site or get his email and, well, "life."

That said, what BBraun was running for his site was a little more focused on getting some other appletalk applications (games, specifically, IIRC) going and also only worked with, IIRC, system 7, so my thought was that by moving that task to a router or bridge piece of hardware and if you're designing something new toss in RS485 so you can talk the apples over serial as well, you can include system 6 and older as well as, say, Apple IIgses.

All of that said: I haven't been able to try talking the apples with vtools from a 7.1 machine on serial yet. I need to get one of the resistor terminators for my LT connectors and I'm being lazy about it so it likely won't happen until I just go and raid my storage locker again. Until then, I can probably only talk the apples in a closed loop.

 

[Gorgonops]

AppleTalk is DDP. You can talk the apples over serial (localtalk) or over ethernet (ethertalk).

I'm sorry, I used the wrong word there. Instead of "Appletalk over IP" I meant "Appleshare over IP". That does not use DDP. Does "vTools" do something besides AFP that you need Appletalk for? (Seriously, I'm speaking totally from ignorance here what vTools does other than file sharing.) I looked up what BBraun did, which is encapsulating DDP inside of UDP, and it's a shame that it doesn't look like he decided to share more information about the server portion of the software. (Which I assume he wrote?)

Here's a page that discusses tunneling DDP using vtund, which is a generic packet encapsulation/transport layer. I *kind* of wonder if/suspect Bbraun's client software is a direct client to a vtund server, it would be a relatively straightforward way to do it as the vtund protocol is elementary, especially if he doesn't enable encryption. Unfortunately his client software looks like it's hardwired to call home to his server and his server alone, so unless you can contact him and get him to spin you a special version (or a version that allows you to freely enter a server node) that's not going to work.

But if you don't mind using a Raspberry Pi as a router than the techniques in that article would be completely valid... although I'm thinking I'd probably do something *other* than vtund if you're planning to host very many clients since it doesn't really look to me like it'd scale that well out of the box.

 

[Cory5412]

VTools can only use appletalk for file sharing. It also has a web site, https://vtools.68kmla.org, FTP is available, and eventually I intend to host email on it, but those will all only work with TCP/IP.

The reason to use an appletalk/DDP bridge/tunnel/vpn for vtools would exclusively be to be able to tlak to it from something too old to speak ASIP specifically.

I haven't tested on my own whether or not this'll work, I need to pop the 7.1 CD into my 840 and give it a go.

 

[Gorgonops]

The reason to use an appletalk/DDP bridge/tunnel/vpn for vtools would exclusively be to be able to tlak to it from something too old to speak ASIP specifically.

According to this any version of System 7 on up should be able to run a version of the AppleShare client that has IP support? (I'm pretty sure I remember using ASIP in 7.5.5 on Basilisk II, anyway?) *If* that's true considering that most machines that are realistically capable of networking can run System 7 that sounds like a pretty small niche to have to fill.

(And, yeah, cue the rage from someone with a Plus equipped with a SCSI network card.)

As noted using a Raspberry Pi to proxy onto a client's local LAN segment looks totally doable on a small scale, I do sort of have questions about how scalible it'd be. I assume Bbraun's setup essentially proxy-arps the clients onto his local segment without zones, which is a strategy that page I referenced frowns on because you'll be bridging all the broadcasts from everyone's network to everyone else's network, but it's probably (mostly) fine for him because the clients are individually running the software so there's no "broadcast" on each client's end like you would have with a Raspberry Pi sitting on someone's LAN.  But maybe he does do zones, obviously we can't do anything but speculate unless Bbraun or an expert user of his service chimes in.

 

[Bunsen]

the Pi / if you could add an RS-485 interface to one and speak localtalk over it

It's RS-422, and yes, you can.  I know RS-232 can be bit-banged out the GPIO; I assume RS-422 wouldn't be substantially more difficult.  At worst one might need one or two extra ICs [*].

It's possible to hive off one core of the quad-core CPU in the Pi, and some RAM, for an RTOS or baremetal code, leaving the other three + GPU to run a full *nix.  This might help with bitbanging.  The two environments share a RAM window to exchange data.

The go-between *nix distro for a Pi or Pi-like to prepare The Internet for consumption by a 68k Mac (over Ethernet) is a solved problem, via mactjaap's MacIPgw or MacIPpi.  Adding PPP over serial for a single machine should be trivial; full-blown Localtalk/Appletalk for a network of multiple machines may be a little more work, but netatalk and other such packages exist.

For extra credit, one could attempt to use LocalTalk's ability to accept an external clock signal, and overclock the network for faster transfers.

[*]possibly overkill: the Zilog Z80182 has a pair of RS-232/RS-422 HDLC capable intelligent UARTs.  LocalTalk is based on HDLC.  It would require a little bit of its own ROM and RAM, unless the Pi can handle it via Linux's Remote Processor thingy, like the 6502 in this project.  Either way, it would require some Z80 coding.

[*]Simpler, if and they are still available, might be one or more Zilog SCCs 

 

[Bunsen]

IMO, that idea of dedicating a core to bitbanging might make RaSCSI faster (assuming a multicore Pi-like).  

There's a baremetal version of RaSCSI for the $5 Pi Zero, which provides storage emulation (SCSI to SD) only, as the other services such as networking are obviously not available without an OS.  If that ran on one core, the other three could potentially bridge Wifi/Ethernet etc.

 

[Bunsen]

At worst one might need one or two extra ICs

On that note, the obvious way around the issues associated with bitbanging the SCSI bus is to think like the Tiny SCSI Emulator, and use an actual SCSI PHY.  They're still floating around in the usual NOS back-channels, including much faster ones than the original 5380.

Unfortunately David Kuder seems to have abandoned work on TSE, and the successor project shows no work since announcement.

 

[PotatoFi]

There seem to be many, many paths forward... the tough part is finding the development resources.