• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Emulation: Binaries for Mini vMac 37 with LToUDP

tashtari

PIC Whisperer
Realized today that with the mysterious disappearance of the Gryphel Project's Paul Pratt that Mini vMac 37 with LToUDP support hasn't seen (and may never see) general release. I still have a working key for the Mini vMac variations service, so I've obtained and am posting some binaries here in case they're useful to anyone:
  • Linux ARM
  • Linux PPC
  • Linux x86-64
  • Mac Apple Silicon
  • Mac Intel
  • Windows x86
 

Attachments

  • minivmac-variations.zip
    345.8 KB · Views: 30

twelvetone12

Well-known member
Is Mini vMac on GitHub? I was able to build it on Mac and Linux (not windows), would it be possible to make a fork with binary releases (and maybe fixes)?
 

Phipli

Well-known member
Realized today that with the mysterious disappearance of the Gryphel Project's Paul Pratt that Mini vMac 37 with LToUDP support hasn't seen (and may never see) general release. I still have a working key for the Mini vMac variations service, so I've obtained and am posting some binaries here in case they're useful to anyone:
  • Linux ARM
  • Linux PPC
  • Linux x86-64
  • Mac Apple Silicon
  • Mac Intel
  • Windows x86
Thanks tashtari, much appreciated :)

Is it worth sticking a copy on Macintosh Garden?
 

Arbee

Well-known member
Is LToUDP different from the older Mini vMac networking support (which the IIgs emulators GSPort/GSPlus also support), or is it just that Paul's stock builds don't include it?
 

Phipli

Well-known member
Is LToUDP different from the older Mini vMac networking support (which the IIgs emulators GSPort/GSPlus also support), or is it just that Paul's stock builds don't include it?
@cheesestraws is the expert (as I believe he implemented it), but as a user, LToUDP is the one that works with AirTalks, meaning I can share files between an emulator and a real computer.
 

tashtari

PIC Whisperer
Is LToUDP different from the older Mini vMac networking support (which the IIgs emulators GSPort/GSPlus also support), or is it just that Paul's stock builds don't include it?
I'm not sure whether stock builds included any LocalTalk support at all, but LToUDP is definitely a different (and better) mousetrap than what was supported previously. I have a vested interest in LToUDP since it's used in TashRouter and TashTalk's tashtalkd, as well as AirTalk...
 

NJRoadfan

Well-known member
I'm not familar with Mike Fort's LToBPF. It looks similar to LToUDP in that it shovels raw LLAP frames over an Ethernet network.

The AppleTalk support in GSport/GSplus is much more substantial. It is a true LLAP-to-ELAP bridge. That is the emulated IIgs acts like an EtherTalk Phase 2 client on the network. It takes LLAP packets coming out of the emulated SCC, strips them to just the frame data, applies ELAP headers, and then ships them out via a libpcap interface. It also has a AARP service that ties into the LocalTalk discovery on the emulated IIgs.
 

cheesestraws

Well-known member
Is LToUDP different from the older Mini vMac networking support (which the IIgs emulators GSPort/GSPlus also support), or is it just that Paul's stock builds don't include it?

GSPort as far as I know has essentially a little localtalk bridge built into it, so it bridges to native Ethertalk, not LToUDP. The reason I didn't do this for mini vmac / AirTalk is that it doesn't work with a reasonable number of end-user WiFi APs (see this thread: https://68kmla.org/bb/index.php?thr...hy-ddp-appletalk-doesnt-work-with-wifi.45811/ where @NJRoadfan's excellent detective work finally pinned down the precise mechanism), and I think it also makes assumptions that don't work terribly well with routers.

LToUDP's use case was very much my own network, which involves both, so that's why it is the way it is.

I'm not familar with Mike Fort's LToBPF. It looks similar to LToUDP in that it shovels raw LLAP frames over an Ethernet network.

Yup, LToBPF/LToE does that, but it does it in raw Ethernet frames, rather than UDP encap. The main advantages of LToUDP over it are 1. that it's more robust to being routed/bridged/whatever and 2. that it doesn't require privileged access to the network stack. There are probably advantages of the BPF approach too, I'm just not sure what they are...
 

Snial

Well-known member
I was using an LToUDP build on my PI 5 a couple of months back with AirTalk, but trying to improve the performance by either porting LToUDP to the PCE emulator or improving the emulation granularity on miniVMac. It turns out that getting miniVmac to check AppleTalk UDP packets every millisecond (by hooking the same check into the Subtick 'task') doesn't make it go faster.

 

NJRoadfan

Well-known member
GSport/GSplus have a flag to enable a "turbo" mode. It disables the rate limiting/timing in the SCC emulation.
 

NJRoadfan

Well-known member
Looking at the LToVRBPF source, its sending a raw LLAP packet with an Ethernet II frame type of 0x089B, the same as EtherTalk Phase I DDP. With not much more code (mostly an AARP implementation), this could have been an EtherTalk Phase I bridge! The process ID likely wasn't needed as the packets have source/destination address information in them.
 

tashtari

PIC Whisperer
Could someone with a Mac (Intel and/or Apple Silicon) download the archive above and check to see if the Mac binaries work? My newest Mac is a 6100, so I'm not able to do it myself...
 

rplacd

Well-known member
Sending out prayers that there’s a cleaned up version of the source out in the aether, that doesn’t use whatever bonkers build system there is…
 

Gunzel

Active member
The intel binary runs on my MacBook Air M2 under Rosetta to the point where it complains there is no ROM file (I have never run Mini vMac before so I don’t have all that setup).

The Apple Silicon binary won’t run, an alert comes up saying it is damaged.
 

tashtari

PIC Whisperer
The Apple Silicon binary won’t run, an alert comes up saying it is damaged.
Thanks for checking. I just regenerated the binary from the variations service and it's identical to the one in the zip file above, I guess it's nothing I did. Oh well, at least the Intel one works.
 

Gunzel

Active member
Apologies, I tried the Apple Silicon build on my wife's M1 Air running Ventura and it worked. Transferring that binary back to my M2 it worked as well. So it looks like something went awry with the extraction process on my end initially that resulted in a damaged binary.

I also tried the intel binary on a a Mac mini 2014 running Monterey and it works there as well.

I guess I better find some ROMs :)
 

eharmon

Well-known member
For Apple Silicon Macs, if it says it's damaged you need to remove the quarantine bits first. Assuming you're using the default shell (zsh) you can run this in Terminal from the same directory as the app to remove the quarantine bit from every file (recursively):
Code:
$ foreach bit (*); sudo xattr -r -d com.apple.quarantine $bit; end;
 

Gunzel

Active member
Thanks @eharmon, what a wonderful error message from Apple, now I’ll know what to look for. I suspect the quarantine extended attribute must have got lost when the file got moved onto the NAS to move to the other machine.
 

NJRoadfan

Well-known member
Is there anything special to enable LToUDP on the Intel macOS builds? Got the binary running, but not seeing any network activity from my Macbook Air running Catalina over WiFi.
 

NJRoadfan

Well-known member
Fixed the problem. Had to turn off "IGMP Proxy" on my router! Seems with it on, multicast traffic wasn't making its way over to Ethernet and vis versa. Yikes, this is a problem.
 
Top