Jump to content

cheesestraws

6502
  • Content Count

    64
  • Joined

  • Last visited

Recent Profile Visitors

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

  1. cheesestraws

    Developing a portable user-land AppleTalk stack

    OK, here's a Mini vMac with LocalTalk over UDP support. Please play with it. Source code is, of course, included If you don't like running random binaries, rebuild it; make clean && make will work LocalTalk ought to just be plug and play. You should be able to launch multiple Mini vMacs and have them just be able to see each other automatically (though I have only tested this build with multiple copies of the emulator on the same machine, because I'm still in a hotel. small print: this will only work inside a single IP subnet, but most home networks etc are single IP subnets. If you have WireShark installed or similar you should be able to see the packets whizzing around If you've managed to build the code I posted earlier, you should be able to use llapping -a to see all the nodes on your virtual network, and llapping <node> to ping a node. I've only tested this on my personal MacBook Pro running 10.11. It may or may not work on other platforms at the moment. Please let me know if this works for you / does not work for you. minivmac-upload.zip
  2. cheesestraws

    Developing a portable user-land AppleTalk stack

    OK, here's some disappointing code: https://github.com/cheesestraws/appletalk I'll post a hacked Mini vMac when I get back to my hotel (turns out it's not on this laptop). Next stop is EtherTalk and a DDP ping example. After that, multiple address support per port and a bridge between EtherTalk and LToUDP!
  3. cheesestraws

    SCSI to Ethernet Adapter on New Hardware

    Writing adevs is a right pain in the posterior </unsolicited opinion>
  4. cheesestraws

    Developing a portable user-land AppleTalk stack

    Yes, please! I'm intrigued. Today's progress: I have an LLAP ping utility working, analogously to ARP pings on Ethernet. It can both scan an attached LToUDP network and ping an individual node on the network: prydwen:llapping cheesey$ ./llapping usage: ./llapping -a Scan the LToUDP network and report on all up nodes ./llapping [node] Pings the given node with LLAP ENQs prydwen:llapping cheesey$ ./llapping -a Node 44 responded in 7.003581ms Node 118 responded in 14.570215ms Node 235 responded in 10.000884ms prydwen:llapping cheesey$ ./llapping 118 lapACK from 118 in 12.545842ms lapACK from 118 in 12.169505ms lapACK from 118 in 13.506241ms lapACK from 118 in 17.27405ms lapACK from 118 in 5.377009ms ^C prydwen:llapping cheesey$ I think I've done all the paperwork now to make the git repo public. If people would like to have a go, I'll publish it tomorrow and post links and an experimental minivmac build...
  5. cheesestraws

    Developing a portable user-land AppleTalk stack

    Ah, yes. No, I'm quite in agreement with you here. The way I have done it under personally is to have a script that as root creates a tap device, chmods its corresponding file in /dev and adds it to the bridge, then drops privileges to run the emulator with its ethernet port aimed out the tap interface. This is ... not trivial to set up but works rather well. One of my "nice-to-haves" would be a "port" for this bridge that could talk the BII AppleTalk-over-UDP hack. The way that works is that the IP address in the "real" network is encoded in the MAC address for the "virtual" network, so DDP packets can be sent directly wrapped in IP just knowing the MAC address of the destination. I can't remember if this is in SheepShaver too, but if it *is*, this would be a sensible way to bridge "virtual" networks together without needing any special privileges on the emulators at all.
  6. cheesestraws

    Developing a portable user-land AppleTalk stack

    I have looked at quite a lot of AppleTalk code and often learned from it. But the goals of those projects are not the same as this one: they often will not build properly with recent tooling, they were built for people who already knew what they were doing, and a non-trivial number of them seem to require kernel support. Also, 1980s C code has not aged well in terms of security and the network conditions it is likely to find itself under. This makes them unsuitable for use in the situations where I intend this to be used (see the first post in this thread for my rationale for doing this). So far, at least for the link-layer stuff, the appendix to Inside Appletalk has been much more useful, as it is designed to be read and to be explanatory.
  7. cheesestraws

    Developing a portable user-land AppleTalk stack

    I think the way to go about this is at first a bridge, and then a full router, between LToUDP and EtherTalk, running on the UNIX side of things. This is pretty much my first "major" project planned with this stack once I have EtherTalk support in it. EtherTalk is just standard Ethernet frames with a SNAP header. So in theory there's no reason it wouldn't work over wireless - that said, a lot of home-targetted wireless equipment is inadequately-tested rubbish, so whether it will actually pass anything other than IP is a little questionable. That said, IIRC, IP on wireless is also transmitted with a SNAP header so it will probably work in more situations than people expect. You just posted a link to abridge, which already does EtherTalk in user-space . It's just ethernet. The software will either need to be run as root or use an unprivileged tap device bridged to the real ethernet device, or something, but that's pretty much par for the course with software doing weird stuff with Ethernet. There's nothing at all magical about EtherTalk that it needs to be implemented in the kernel. This isn't particularly relevant to the dongle discussion though, as that will not be doing any EtherTalk at all: it will be just talking bog-standard IP multi/broadcast, which should be coped with by even fairly rubbishy home infrastructure. When I've got half-reasonable EtherTalk support this will basically be the first project I'll be doing with it. If you would like to hack on it with me your input would be very welcome :-).
  8. cheesestraws

    Developing a portable user-land AppleTalk stack

    If the "algorithms" section at the back of Inside AppleTalk is accurate, the RTS/CTS stuff at least is done in software, but wired off interrupts from the SCC. I'm not sure if this accurately reflects the actual code in use, but the timings seem achievable if you are able to immediately drop everything and service RTS/CTS state or ENQ/ACKs. Also according to that section, duplicate address detection should work outside those timings, but what it doesn't seem to specify is what the LocalTalk stack does with the knowledge that there is a duplicate address. If it just reruns address acquisition, then that's great - if it does something less predictable, then that might be a problem. I have a suspicion that the very low timeouts especially on ENQ/ACK and address acquisition and so forth are to improve the interactive latency of the system - LocalTalk always feels to me far snappier than it has any right to given its age and actual available bandwidth - and I suspect that's because the latency of the system is kept intentionally as low as it can be. Yup, I was assuming I'd have to have one of the more modern SCCs wired up to the ESP. An auxiliary microcontroller squirting data over a high-speed UART to the ESP, or something along those lines, would be even more sensible, and probably pretty easy, since many of the uses of the smaller ESP stuff seems to be "various serial stuff to IP" bridges. Did you ever manage to get sending working?
  9. cheesestraws

    Developing a portable user-land AppleTalk stack

    Don't get your hopes up too much! At the moment this is literally just an LLAP packet parsing/construction and address acquisition library. I haven't got any further than that yet, along with mini vmac support. I think I've got all the stuff I need to do done for the paperwork to release code at my end, so the first thing I'm going to do is to get the patches to Mini vMac to the point where they're not embarrassingly bad and submit those, then I'll try to write a couple of demo applications and release that for comments. But yeah, this isn't yet at the stage where you'll be able to write an AFP server on top of it or anything. I do actually have the source code to avpn - it is around on his website somewhere, because I got it then had to ask on his forums what license it was under. I did hack it to speak (an earlier version of) the LToUDP protocol, but it's very unstable and I don't really know why. It's below the level I usually hack at on the classic MacOS, I'm afraid. I also vaguely remember that MacTCP doesn't speak multicast (very well? at all?) and multicast is actually quite useful (the loopback interface on OS X doesn't support broadcasts, so if you want to run multiple emulators on an OS X box, it's multicast all the way!). edit: the source code to avpn is in the archive with the binary that can be downloaded from here: http://www.synack.net/~bbraun/macapps.html. It requires to be built with a specific version of CodeWarrior, I can't remember which one off the top of my head. The real problem here is that any computer that could talk LToUDP through an atlk/adev probably already has Ethernet, and so EtherTalk is a better option. EtherTalk will be supported in this library/implementation, it's just I haven't got to it yet. The only other option would be running LToUDP over MacIP over LocalTalk through a bridge, which frankly seems like a recipe for total disaster. The other thing is that all the documentation on how to write atlk/adevs seems to have disappeared completely, unfortunately: there was, at one point, a developer document telling you how to do it, but I have never found a copy, and when I asked on his forum, bbraun hadn't found a copy either. So this makes writing one/hacking on one a frustrating and intricate experience. So, with all that in mind, I much prefer the idea of giving real macs LToUDP using a hardware dongle, as discussed a bit upthread. That way, you just get something you can plug in and it goes, even on Macs without the wherewithal to run their own IP stack. I've got this idea in my head that you could configure it by sending DDP packets to a "magic" address that would actually do things like select the wireless network. But that's ... definitely further down the line.
  10. cheesestraws

    Solid State Drive for G3?

    As a parenthesis, can I just say how interesting it is to have someone around who has hard requirements for their classic macs, rather than just wants like I have? I have little to contribute at this point but I just wanted to say how good these threads are to read. I will contribute if and when I can.
  11. cheesestraws

    Developing a portable user-land AppleTalk stack

    Thanks for the feedback and the kind words! As far as address allocation goes, yes, I'm just passing the LLAP packets and letting the macs and whatever else are listening sort out address allocation using the normal ENQ/ACK code. This seems to be working quite well so far: I have a reimplementation of address acquisition in Go which seem to play nicely with several hacked mini vmac instances. One thing I am worried about is latency; the LLAP spec is very ... tight about timings. IP is a comparatively leisurely protocol in many ways, and I need to intentionally introduce some latency and then induce some address collisions to see how well they're handled. This may require revisiting, but I hope MacOS is a little more permissive than the spec says it ought to be. Once I've got this working reliably, the next step is to try to implement EtherTalk, then implementing the router protocols and trying to get routing working between the two. In fact, my plan, inasmuchas I have one, boils down to working through Inside Appletalk in order... I'm concentrating on LToUDP at the moment because I'm stuck in a hotel room an ocean and a continent from home and it's something I can run on a single laptop. And also my home network is in a state of profound disarray... Oh, very nice. My dream was to take something like an ESP8266 and make a little "wireless dongle" that would wrap LLAP packets in LToUDP and fire them out on the local wireless network, which sounds like something doable with your hardware perhaps? The IP side is where I live most of the time, I'm woefully inadequate at electronics.
  12. cheesestraws

    Developing a portable user-land AppleTalk stack

    I've posted an initial description of my embedding of LocalTalk in UDP here: https://windswept.home.blog/2019/12/10/localtalk-over-udp/. I think I've worked out most of the glitches in it (at least it seems to be working reliably here). Comments welcome.
  13. Rather than posting randomly in the "what did you do to your mac today" thread, I thought I'd make a separate thread for this project in here. Hope it's in the right place and people find it interesting and want to throw ideas at me. The plan/project is to write a userland AppleTalk stack aimed at UNIX-like OSes that prioritises talking to vintage macs, especially from the 68k era. Netatalk no longer bothers with DDP, and AppleTalk in-kernel support in operating systems will, at some point, go away, probably rather sooner than later. It is being written in Go, partly because it's the main programming language currently in my short-term memory and partly because channels are useful. The other important theme here is that I want to write this prioritising code clarity and readability rather than performance. I've often been trying to work out how to interact with a device and looked at the sample code, and then I have two problems rather than one, the second being to understand the sample code. I'd prefer that not to be the case for this. Due to the terms of my employment, I can't release any code until I get the project signed off (sigh), but code *will* be coming. At the moment, you're not missing much anyway, honestly. Also, updates to this will be very sporadic for various life and health reasons. State of affairs as of mid-December 2019: I've implemented a slightly hacky Localtalk over UDP multi/broadcast thing for minivmac, using most of the same code as the existing LToE code. I think this is more flexible for reasons I am happy to go into if anyone wants me to, but is mostly for my own dev convenience. There is actually a bug in minivmac, even using LToE, that prevents duplicate address detection working. The chances of anyone hitting this in the wild are fairly remote, but I think I've fixed it and I'll submit a patch when I can. I have the ability to send and receive LLAP packets over an LToUDP network and parse them. The "physical" layer and the LLAP layer are separate, so in theory it ought to be possible to swap out LToUDP for LToE or "real" localtalk later. I have the ability to acquire a network address on this network and participate in the duplicate address detection protocol with a virtual network of minivmac instances. I can parse short-header DDP packets, but if I want to send any I have to craft them by hand.
  14. cheesestraws

    Make the sound volume higher...

    You probably want a little amplifier. A headphone amplifier might do the job, since presumably that's what's in the cheap pair of speakers? You can get perfectly reasonable ones of those for not much money.
×