AirTalk between Mac Plus & miniVMac on Raspberry PI 5

[Snial]

I thought I'd share my little journey of getting AirTalk to work between my Plus & miniVMac on my π5. OK, so firstly, yes I'm fortunate enough to have one of those, as-yet-rare 5's (4GB RAM, because hey - who needs more ;-) ) thanks to a leaving present from the most recent company I was working at: ByteSnap in Longbridge, Birmingham, UK. It took a while to arrive, delays almost worthy of Sinclair in the early 1980s and at one point I thought it was going to arrive in January, but then it did an unBrexit & got posted a couple of weeks ago. I then had to order an micro HMDI adapter, a power plug for good measure & I took the opportunity to order a 32GB µSD.

Naturally, the most important thing to do with a Raspberry PI is to run a Macintosh Emulator on it. In the past I've managed to get the excellent PCE/MacPlus emulator to work on my PI 3, but for simplicity's sake (and because I understood it could work with miniVMac via the AirTalk threads), I decided to install that and, for fun I decided to compile it myself. I started with the standard Version 36.04 but found that it wouldn't support the -lt -lto udp setup option, so I then found the 'Beta' 37.03. I built the setup tool as normal (gcc setup/tool.c -o setup_t) and then ran this setup:

./setup_t -t larm -m Plus -speed z -lt -lto udp > setup.sh
sh setup.sh (because I can't be bothered to chmod)
make -j4 (because the PI 5 is fast and I mustn't waste those MIPs :-O )

I have a standard 40MB HD image with System 7.0.1 and my standard tools (i.e. ClarisWorks 3, WriteNow 2.0, Think C 5, Compact Pro & Stuffit Lite). There's plenty of space on it for my projects, because well, 40MB is enough for anyone!

Then I went over to the very helpful AirTalk Getting Started page and followed the instructions. Currently I've had to transfer data between my Macs in a fairly convoluted way. Either I've transferred from my Intel Mac mini via a CF card to my PowerBook 1400c and then via my SCSI ZIP 100 to my Mac Plus, which involved some unplugging and plugging in (unwise); or I've run miniVMac on my PI 3 and then transferred to my USB ZIP 250 to my SCSI ZIP 100. More recently I've been playing with AppleTalk between my PB 1400c and my Mac Plus, which involved a trip down my guesswork memory lane.

So, here's the thing: very wonderfully I was able to obtain a couple of AirTalk units from the eminent @cheesestraws at the recent fab & fun UK Meetup at the middle of November. I knew they were great, but you might find this hard to grasp, but at first I struggled to see how I was going to use them, because at the moment I need just one cable to hook up my PB1400c to my Plus and a pair of AirTalks needs 2 + 2x PSUs.

But when I finally got around to reading the original AirTalk thread I finally realised that I could directly get an emulator on my PI to talk to my real Plus. I think the other level of confusion was that I was told at the Meetup that AirTalk didn't really connect to a proper IP network, nor netatalk and so I had imagined that it was just some ESP32 to ESP32 wireless comms (like they ran their own AP to do it).

Hence when I finally did get it, I was pretty keen to get it going. And it works quite nicely - first time in fact! Thanks everyone for making it easy (despite my best efforts ;-) ) ! Of course I had to use the Zip drives to copy the Chooser Extension to the Plus (Stuffit Lite and Drop Stuff for System 7.1 both work) but then the experience of setting up Wifi on the Plus was a real joy: like a bit of 21st century inserted straight into the late 80s! After a reboot and running the Sharing control panel to start file sharing, it was ready to be tested.

Then I switched to miniVMac on the PI 5 (which already had AppleTalk on); starting AppleShare from its Chooser led me to being able to select my Mac Plus server (called Plus) and from there mount Skids HD40.



I copied a few small files in both directions. It's great fun and somewhat magically surreal. As has been reported quite a bit, the initial file transfer setup took quite a while (about 30s to a minute), but after that file transfers were fast enough for my needs.

So, a great success! What it means is that I can simplify my emulated Mac to Mac Plus file transfer setup as I just need e.g. the PI 5, the Plus, a HD and AirTalk. I'll use it for developing a few simple apps on miniVMac and transfer them to the Plus for authenticity!

-cheers all!
PS. I might go back to using PCE/MacPlus for the very simple reason that that emulator instruction loop runs at a much finer granularity (1ms by default, but I got it down to 0.5ms on the PI 3 instead of 16.7ms on miniVMac) and the JavaScript version now apparently supports AppleTalk. So maybe that can be back ported to the main code base in C and it'd massively reduce the latency.

 

[Phipli]

Thanks for posting the details of your experiments.

I tried to compile it on my ARM based Pinebook Pro a while back, but the resulting executable just showed an empty window.

 

[cheesestraws]

Woo, glad it's working for you!

I'm curious about the PCE/macplus + AppleTalk thing - do you know which branch it is of that codebase that has that in it?

 

[Snial]

Thanks for posting the details of your experiments.

That's OK, I was hoping it wouldn't be too old-hat and ordinary. Airtalk is very well established now!

I tried to compile it on my ARM based Pinebook Pro a while back, but the resulting executable just showed an empty window.

I've heard of the Pinebook. Cortex A53. I think that makes it a bit similar to the BeagleBone. Not knowing much about the setup (Manjaro Linux, whatever that is?) I guess it would have to be a Window Manager problem?

Woo, glad it's working for you!

Me too ! I had a little look at the Chooser Accessory, but not in much detail. It seemed quite neat.

I'm curious about the PCE/macplus + AppleTalk thing - do you know which branch it is of that codebase that has that in it?

It's here:
https://github.com/mrcodechef/pce-js-with-localtalk
I haven't tracked down the LocalTalk changes yet, nor have I run the JS version, only the ordinary JS version. I've compiled and run the 'C' version of PCE/macplus when I was unsuccessfully experimenting with Cubase Lite + MIDI on a PI (it's stupid that Linux doesn't let you just choose any baud rate like an MCU would).

-cheers from Julz

 

[Snial]

Woo, glad it's working for you!

I'm curious about the PCE/macplus + AppleTalk thing - do you know which branch it is of that codebase that has that in it?

The alternative would be to propagate miniVMac's approach to handling localTalk over UDP. One of the interesting aspects of PCE/macplus is its approach to configuration. So, if you read the config file (pce-macplus.cfg.in) in this folder:

https://github.com/mrcodechef/pce-js-with-localtalk/tree/emutos/src/arch/macplus

You find that there's a section on mapping the serial port to various devices, such as a real serial port or a file.

serial {
    # The port number. Use 0 for the modem port and 1 for
    # the printer port.
    port = 0

    # Up to multichar characters are sent or received
    # without any transmission delay. For a real serial port
    # this value is 1 but larger values can speed up
    # transmission.
    multichar = 1

    # Not all character drivers are supported on
    # all platforms.
    #driver = "null"
    #driver = "posix:file=ser_a.out"
    #driver = "pty:symlink=ser_a"
    driver = "stdio:file=ser_a.out:flush=1"
    #driver = "tios:file=/dev/ttyS0"
    #driver = "tcp:port=5555:telnet=1:telnetinit=1:usectl=1"
}

serial {
    port = 1
    driver = "stdio:file=ser_b.out"
}

So, before you compile it, you can select the driver you're interested in. In that case, maybe UDP support isn't much more complex than choosing something like: udport=????. I, of course, was mapping serial to the PI 3's GPIO serial port and I had to change the PI's serial clock rate in order to fudge 38400 to be 31250. Ha, and, a bit of trivia: the reason why it's 31250 for MIDI, is because I'm pretty sure they used an MC6850 ACIA chip for the earliest MIDI devices (at least in testing), so then they just clocked it at 1MHz (so /16 gives 31250).

 

[Phipli]

I guess it would have to be a Window Manager problem?

Oh, I assume it was my incompetence.

So, a great success! What it means is that I can simplify my emulated Mac to Mac Plus file transfer setup as I just need e.g. the PI 5, the Plus, a HD and AirTalk. I'll use it for developing a few simple apps on miniVMac and transfer them to the Plus for authenticity!

Hum, running mini vmac on my amd64 Linux laptop, I can see the share, and connect to it, from my Mac Classic, but it seems to be failing to respond to a lot of requests. I'm seeing the TX lights on the Airtalk flash about once every 2 seconds, with only occasional RX activity. I didn't have this when I was using two AirTalks.

So little traffic is getting through that you can just about view a disk's contents, but file transfers are futile.

Your setup just worked? I've tried fiddling with the emulator speed to see if it would help, as well as the "autosloW" setting.

 

[Phipli]

Right. It now works. I didn't actually try anything new, I just shutdown the classic instead of restarting (to power off the AirTalk), and quit and relaunched the emu (for the 4th time). I've also switched to ethernet along the way on the laptop, and left mini vmac at full speed this time.

 

[cheesestraws]

I've also switched to ethernet along the way on the laptop

This might be it. Aggressive power saving on the WiFi can seriously dent LToUDP throughput - modern Macs do this, and Linux may also.

 

[Snial]

Oh, I assume it was my incompetence.

Does anyone else have a PineBook? I was going to get one a while back, but didn't think I had a massive use for it. Another thing occurred to me, did you compile for SDL or X? If SDL, did you install the right version on the PineBook?

Hum, running mini vmac on my amd64 Linux laptop, I can see the share, and connect to it, from my Mac Classic, but it seems to be failing to respond to a lot of requests. I'm seeing the TX lights on the Airtalk flash about once every 2 seconds, with only occasional RX activity. I didn't have this when I was using two AirTalks.

So little traffic is getting through that you can just about view a disk's contents, but file transfers are futile.

Your setup just worked? I've tried fiddling with the emulator speed to see if it would help, as well as the "autosloW" setting.

Yes, it just worked! The initial latency was about a minute, but after that it seemed fine. I didn't copy much, just my R20 16-bit RISC emulator; and a couple of utilities (BinUnPk) and a WriteNow document. I can't say I tested it to destruction.

Right. It now works. I didn't actually try anything new, I just shutdown the classic instead of restarting (to power off the AirTalk), and quit and relaunched the emu (for the 4th time). I've also switched to ethernet along the way on the laptop, and left mini vmac at full speed this time.

Brilliant! I haven't even tried running mini VMac at anything greater than 1x with AppleTalk enabled. However, looking at the miniVMac code, the LocalTalk support appears to be independent of actual serial speeds: the SCC data transmission just hooks directly into the UDP code.

 

[Phipli]

If SDL, did you install the right version on the PineBook?

I think I tried both after the first failed, but it is a few months back now.

Does anyone else have a PineBook? I was going to get one a while back, but didn't think I had a massive use for it

It's a nice little machine except the keyboard is not the best and the trackpad is the worst I've ever used. I'd only ever suggest using one with a mouse. Real shame.

I'm happy to have it, but I hope the next generation of machines learn from their mistakes.

 

[Snial]

For my Mac 256K, I did a bit of hacking with miniVMac as a proof-of-concept. Looking at the main loop for miniVMac I noticed that it should be fairly easy to get it to check LocalTalk every ms (or less) instead of every 60th of a second (17ms). I'll still go back to PCE and port it that way, because there's quite a few nice things about PCE, but this might be an easier hack for now.

Normally (as we know) LocalTalk gets checked every 17ms via this function in PROGMAIN.c:

LOCALPROC SixtiethSecondNotify(void)
{
#if dbglog_HAVE && 0
    dbglog_WriteNote("begin new Sixtieth");
#endif
    Mouse_Update();
    InterruptReset_Update();
#if EmClassicKbrd
    KeyBoard_Update();
#endif
#if EmADB
    ADB_Update();
#endif

    Sixtieth_PulseNtfy(); /* Vertical Blanking Interrupt */
    Sony_Update();

#if EmLocalTalk
    LocalTalkTick();
#endif
#if EmRTC
    RTC_Interrupt();
#endif
#if EmVidCard
    Vid_Update();
#endif

    SubTickTaskStart();
}

SixtiethSecondNotify is called from

LOCALPROC m68k_go_nCycles_1(ui5b n)
{
    ui5b n2;
    ui5b StopiCount = NextiCount + n;
    do {
        ICT_DoCurrentTasks();
        n2 = ICT_DoGetNext(n);
#if dbglog_HAVE && 0
        dbglog_StartLine();
        dbglog_writeCStr("before m68k_go_nCycles, NextiCount:");
        dbglog_writeHex(NextiCount);
        dbglog_writeCStr(", n2:");
        dbglog_writeHex(n2);
        dbglog_writeCStr(", n:");
        dbglog_writeHex(n);
        dbglog_writeReturn();
#endif
        NextiCount += n2;
        m68k_go_nCycles(n2);
        n = StopiCount - NextiCount;
    } while (n != 0);
}

As input, n is the number of cycles for 1/60th of a second, scaled by the speed. This is then divided up into smaller tasks. So, I guess the call to LocalTalk could be added to the ICT tasks, at a real-time rate of 1kHz (or some other, even higher value).