Jump to content


  • Content Count

  • Joined

  • Last visited

Contact Methods

  • Website URL

Profile Information

  • Location
    Kyoto, Japan

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. sfiera

    Sfiera’s Conquests

    I haven’t decided what to do with the TAM unit itself. I can’t set up both TAMs, because I’d need a second bass unit, a second keyboard, and a second apartment. I really only bought it for the cards inside, and the smart thing to do would probably be to flip the unit, but first I’d need to work through how to start selling and shipping here.
  2. sfiera

    Sfiera’s Conquests

    Acquired a second TAM unit, and this one really does not look so good: But as they say, it’s what’s on the inside that counts, and what’s on the inside is: A Sonnet G3/500 accelerator A Sonnet Tango USB/FireWire PCI card An Ethernet Comm II card Plenty of RAM A fan? I wasn’t really sure about the fan. I took it off to have a look, and it certainly doesn’t seem to be standard for the G3 card. I can’t imagine it would get very good airflow in that position either, and it was a bit hard to fit the back of the unit on. I wasn’t sure where the power was coming from, but I investigated further and… …and I’m still not sure where the power is coming from. The previous owner must have gone through a fair bit of effort to get that fan in there. Actually, when running off a G3 card, is there any reason the fan over the original CPU needs to run anymore? The easiest power source would have been the existing fan header, I’d think. I was missing the keyboard on my TAM, and I also managed to find a replacement. For some reason, the ADB cable from the keyboard was severed about a centimeter from the base, so the keyboard was exhibited as “not usable, for parts”. But! There are still two perfectly good ports on the keyboard, and all ports are created equal in ADB. I opened up the keyboard, cut out what was left of the original cable, and hooked up one of the “downstream” ports. Works fine! Eventually I’ll probably solder on a replacement, but until I find a satisfactory donor cable, this works fine. Lastly:
  3. I think the iBook must just have previously lived on another network. Changed it to 0xff00 manually and set it back to automatic, and that sticks. With some Wiresharking, I figured out part of why the Quadra wasn’t working as a client of Mini vMac. NBP responses include the address of the sender. I was rewriting the LToU packets to assign them to network 0xff00, but the NBP responses were telling the Quadra to contact network 0. However, just leaving the network as 0 doesn’t work for some reason… still investigating. Here’s an in-progress Wireshark dissector. Short headers only so far. ltou_protocol = Proto("LToU", "LocalTalk-over-UDP") fieldSender = ProtoField.uint32("ltou.sender", "sender", base.DEC) fieldDstNode = ProtoField.uint8("ltou.dstNode", "destination node", base.DEC) fieldDstSocket = ProtoField.uint8("ltou.dstSocket", "destination socket", base.DEC) fieldSrcNode = ProtoField.uint8("ltou.srcNode", "source node", base.DEC) fieldSrcSocket = ProtoField.uint8("ltou.srcSocket", "source socket", base.DEC) fieldSize = ProtoField.uint16("ltou.size", "size", base.DEC) fieldOpcode = ProtoField.uint8("ltou.opcode", "LLAP opcode", base.DEC) fieldDDPType = ProtoField.uint8("ltou.ddpType", "DDP type", base.DEC) ltou_protocol.fields = { fieldSender, fieldDstNode, fieldDstSocket, fieldSrcNode, fieldSrcSocket, fieldSize, fieldOpcode, fieldDDPType, } local ddp = DissectorTable.get("ddp.type") function ltou_protocol.dissector(buffer, pinfo, tree) length = buffer:len() if length == 0 then return end pinfo.cols.protocol = ltou_protocol.name local subtree = tree:add(ltou_protocol, buffer(), "LocalTalk-over-UDP Data") subtree:add(fieldSender, buffer(0,4)) subtree:add(fieldDstNode, buffer(4,1)) subtree:add(fieldSrcNode, buffer(5,1)) subtree:add(fieldOpcode, buffer(6,1)) -- Short DDP Header subtree:add(fieldDstSocket, buffer(9,1)) subtree:add(fieldSrcSocket, buffer(10,1)) subtree:add(fieldSize, buffer(7,2)) subtree:add(fieldDDPType, buffer(11,1)) ddpType = buffer(11,1):uint() size = buffer(7,2):uint() ddp:try(ddpType, buffer(12, size - 5):tvb(), pinfo, tree) end local udp_port = DissectorTable.get("udp.port") udp_port:add(1954, ltou_protocol)
  4. I implemented it but haven’t gotten it working again yet. Some observations: In EtherTalk (AARP), you can probe a request on any network, but that’s not possible under plain LocalTalk (LLAP) with an ENQ. I guess this isn’t that surprising, since ENQ is there to check for address collisions, and you can’t collide with an address on another network. In the original abridge design, EtherTalk packets are sent verbatim, so hwaddrs are preserved across the bridge. This is fine since pcap is in promiscuous mode and will pick them up anyway. Now, I’m unwrapping and rewrapping them on each side, and so the reconstructed EtherTalk packets get marked with the hwaddr of the bridge. I think that sounds correct for how packets should be addressed through a router. Previously, when EtherTalk packets were flowing through the bridge, I didn’t really think too much about the short vs. extended DDP distinction, since I always had to immediately convert to extended. Now I don’t, but maybe it would be better to require extended headers within the bridge, and only have the LToU adapter consider short headers. I’m still confused about networks, such as how THIS-NET and THIS-NET-RANGE are chosen. My Quadra (7.5? 7.6?) picked 0xff00, which is what I’d expect (EtherTalk = extended network = pick from startup range 0xff00~0xfffe when no RTMP). Mini vMac picks 0 (LocalTalk = non-extended = 0 when no RTMP). I was testing today with an iBook (8.1) and it picked 0xa0f1, which I don’t understand.
  5. I think I found a logical error in my code, though I’m not sure what to about it yet, so I’m musing here in text. It concerns the case I was trying before, where I attempted to bridge EtherTalk/Ethernet to LToU/WiFi (two interfaces), and an AARP “Request” packet comes in (on Ethernet) attempting to map a network/node to a hwaddr. LToU doesn’t have the concept of hardware addresses, so if LToU has seen that network/node (on WiFi), then the bridge should respond with the Ethernet hwaddr. I wrote the bridge with EtherTalk packets as the underlying data type being passed around (because I started from bbraun’s abridge and abridge only handles EtherTalk). So, right now, the EtherTalk capturer hands the packet to the LToU transmitter, which says “I can’t convert an AARP request to LToU” then checks if it has ever received anything from that network/node. If so, it responds to the AARP request without transmitting anything to the network. But, because that’s the WiFi side of the bridge, it fills out the response the WiFi hwaddr instead of the Ethernet hwaddr. I’m thinking the implementation should switch to LLAP packets as the underlying data type. Then, the EtherTalk side of the bridge would be the one responsible for filling out responses to AARP requests (and would naturally send the Ethernet hwaddr). The other question is whether to respond, but I don’t think it matters which end of the bridge is responsible for deciding that, right?
  6. Here are some current Mac builds: Mac Plus on macOS Mac II on macOS They’re built from github.com/sfiera/mini-vmac-builder and all that’s needed to build new versions is to update $LATEST in the Makefile. They are signed but not notarized; woe betide whosoever should upgrade to Catalina. I could build Debian binaries too but don’t have the expertise to do Windows. Note that the Mac II version starts without any acceleration. I found that it would crash during startup if acceleration was on. It’s fine to turn it back up again after startup finishes.
  7. Speaking personally, what I'd like to have in the long term is a AFP server that is designed to do the kinds of things I want to do (like “access Google Drive from my Quadra at home”) and not the ones that netatalk seems to (like “integrate Macs into a multi-user Unix environment”). And, of course, for it to have a clear future, unlike netatalk2-over-DDP.
  8. For the record, I noticed an oversight on my part. When I first tested Mini vMac as an AFS client, I used a 6.0.8 image. Since 6.0.8 doesn't have built-in file sharing, when I later tested Mini vMac as a server, I used a 7.x.x image. However, I didn't first verify that Mini vMac on 7.x.x could also serve as a client. It's possible that that wouldn't work either—even likely, I think, due to my ignorance about networks. I probably either need to assign a network to the LToU side (or both) with RTMP, as cheesestraws said, or else translate verbatim, without converting between short and extended DDP headers (which may break System 6 compatibility). One thing that would be helpful, if anyone has a chance, would be tcpdump logs of communication between 6 and 7 (EtherTalk atalk-or-aarp or LToU port-1954). But, no hurry, as I won't have the chance to experiment any more myself for at least a week.
  9. Oh, but no more experiments for a couple weeks. I’m heading on vacation (assuming international air travel is still a thing come Thursday) and I need to put away my toys. Might still put in a little work on the repo. Is there simpler client software to exercise the networking stack than AppleShare? I see there’s an echo protocol, but the only client I know is netatalk’s aecho, nothing to run on a Classic machine.
  10. I tried adding in an extra bridge, hooking up a Plus to the Quadra, which runs LocalTalk Bridge. It was able to see machines on the far end, but not connect to them. I also tried going the opposite way, with the Quadra as a client and Mini vMac as the server. This doesn’t seem to be working right either. I think it is something about the networks. To start with, I assumed that I could naively translate short headers to network 0xFF00, but now I’m not sure that’s the case. I was seeing things like: 2020/03/02 13:38:18 09:00:07:ff:ff:ff <- dc:a6:32:1a:e9:31: snap: atlk: ddp [0000] 65280.95:250 <- 0.22:238 03: [96 1 4 62 2 1 0 20 34 0 255 255 0 0 0 2 7 127 19 127 2 0] 2020/03/02 13:38:20 09:00:07:ff:ff:ff <- dc:a6:32:1a:e9:31: snap: atlk: ddp [0000] 65280.95:250 <- 0.22:238 03: [96 1 4 62 2 1 0 20 34 0 255 255 0 0 0 2 7 127 19 127 2 0] 2020/03/02 13:38:22 09:00:07:ff:ff:ff <- dc:a6:32:1a:e9:31: snap: atlk: ddp [0000] 65280.95:250 <- 0.22:238 03: [96 1 4 62 2 1 0 20 34 0 255 255 0 0 0 2 7 127 19 127 2 0] 2020/03/02 13:38:23 09:00:07:ff:ff:ff <- dc:a6:32:1a:e9:31: snap: atlk: ddp [0000] 0.95:246 <- 65280.22:251 03: [64 0 4 61 5 1 0 0] I didn’t actually try to figure out what’s going on there yet, but it’s weird that packets would simultaneously be addressed from 65280.22 to 0.95 and from 0.22 to 65280.95. Maybe I should go back and actually read Inside AppleTalk instead of just skimming for the packet definitions, hah.
  11. Weekend project: Lower left, a Mini vMac LTOU client. Upper right, a Quadra serving its hard drive with AFP over EtherTalk. Off-screen, an RPi running a bridge between the two. I started with bbraun’s abridge, converted it to Go, and extended it to support LTOU. It took basically the weekend to sort everything out, but it appears to work. Still some stuff I’m not so confident about. For example, I think EtherTalk always uses extended DDP headers; I think LocalTalk does both kinds but I’ve only seen short headers, and I don’t really know how networks are supposed to work. Repo: https://github.com/sfiera/multitalk
  12. sfiera

    Sfiera’s Conquests

    Drivers here: Atmark Controller Key Assign Software The drivers didn’t seem to work for me, but the trackball and left trigger work as a mouse without any drivers installed.
  13. sfiera

    Sfiera’s Conquests

    Pippins don’t seem to be difficult to find in Japan, though my interest level and tolerance for a non-working machine haven’t matched the price point of anything I’ve seen. This is in fact an Atmark Controller For Macintosh. Comes with drivers on a floppy disk (still sealed, but I’ll take an image and share when I open it). The connector is not the Pippin Apple Jack connector, but a regular ADB connector. Curiously, the connector omits the power pin, which sort of makes sense, but I haven’t seen that on other ADB devices (like Apple mice).
  14. sfiera

    Sfiera’s Conquests

    Even more impressive to me is the attention they paid to the DB-9 plug, which would normally be hidden behind the computer: (though I am a little disappointed that the ends of the pins don’t have Assimilation Process logos like the Apple pins do) I saw it in your thread, liked it, and then saw one for sale just a couple days later and couldn’t resist. Unfortunately, I only have a Plus keyboard, and two numpads is two more than I have a need for, but it’s still kind of neat that it’s both.
  15. sfiera

    Sfiera’s Conquests

    I got a fever, and the only prescription is more trackballs. Haven’t tested either yet, but the Pippin/ADB controllers (a pair of them) appear to be unused.