Introducing (and interest check) AirTalk: Wireless plug-and-play LocalTalk dongles

[RolandJuno]

That's a lot of framing errors. In order for TashTalk to flag a framing error, it has to have detected a zero on the line that it detects as the attempted beginning of a flag byte (0b01111110), followed by more than six ones, which seems a little too precise of an error to have been triggered by line noise...

Anyway, I'd be interested to hear what the debug output is like when a print job is in progress. (Even more interested to see some scope traces of the line, but that may be asking too much...)

I did a print job and there's a lot more of the same "tashtalk: framing error of 0 bytes" errors streaming by-- multiples at a time. I made a video to illustrate this. In it, I show the serial debug output, the Mini VMac that initiates the printing over LocalTalk UDP, the ImageWriter II AppleTalk itself, and the AirTalk so you can see the activity. Hope this is useful.

I saved the serial debug output as well: https://pastebin.com/xdKU75tP

I could do some scoping if that would help but I'd need some more guidance from you (where to scope and what to scope with-- I have both an digital oscilloscope as well as a cheap logic analyzer).

Cheers!

 

[cheesestraws]

This is either the ImageWriter doing something a bit weird or the TashTalk transceiver doing something a bit weird; I hope you won't mind if I get out of the way and let you and @tashtari talk about this because at present my useful input in this conversation is going to be a bit limited!

 

[jazzius]

I did a print job and there's a lot more of the same "tashtalk: framing error of 0 bytes" errors streaming by-- multiples at a time. I made a video to illustrate this. In it, I show the serial debug output, the Mini VMac that initiates the printing over LocalTalk UDP, the ImageWriter II AppleTalk itself, and the AirTalk so you can see the activity. Hope this is useful.

I saved the serial debug output as well: https://pastebin.com/xdKU75tP

I could do some scoping if that would help but I'd need some more guidance from you (where to scope and what to scope with-- I have both an digital oscilloscope as well as a cheap logic analyzer).

Cheers!

Printing with the Airtalk seems cool, but the only vintage Apple Printer I have is a Color StyleWriter 2500 and the only Ink Cartridge I have for it is super old and dried up. Haha.

 

[tashtari]

I could do some scoping if that would help but I'd need some more guidance from you (where to scope and what to scope with-- I have both an digital oscilloscope as well as a cheap logic analyzer).

I think what'd be most useful at the outset would be to take a look at the LocalTalk bus itself (assuming you're using LT or PhoneNet dongles) and see if anything looks sus, as the kids say. I'd look first of all for line noise, though I don't think that's what's happening here.

Next thing I'd look for is whether the clock rate from the ImageWriter is out of spec. LocalTalk uses differential Manchester encoding (see the link for a diagram) at 230400 bps, so there should be a steady clock with inversions every ~4.34 µs, sometimes with a transition in between. If that's way off base, that could account for the framing errors, though if it was, I'd expect that no data would get through at all...

 

[twelvetone12]

thanks! The extension loads and I can select the modem port, now I need to figure out a way to see if it actually works (I don't have another mac unfortunately), I guess if I hook up the scope to the TX pin I should see the initial LocalTalk messages when the computer powers up right?

I did not forget about this project, it took me ages to get hold of a PIC (hopefully my pickit still works) but I still cannot find a connector. Turns out Tx needs a pullup or you will see no data, so I need for the AMP 104652-2 to show up before I can test further. The INIT and control panels let me select the modem port for Localtalk, so it is just a question to see if the data is there.

 

[cheesestraws]

it took me ages to get hold of a PIC (hopefully my pickit still works)

If it doesn't, I can pop a couple of spare Tashtalks in the post for you. I've got quite a number

 

[tashtari]

Turns out Tx needs a pullup or you will see no data

Do you mean Tx on the TashTalk PIC? Because that shouldn't need a pullup...

 

[twelvetone12]

Nope on the serial port on the Mac. I could not see anything with the scope the and it seems others had the same experience without pull-up.

 

[tashtari]

Nope on the serial port on the Mac. I could not see anything with the scope the and it seems others had the same experience without pull-up.

Ah, okay, you had me worried for a second. =)

 

[twelvetone12]

A small update on my project to run Localtalk on the internal modem port: (short version) it does not work.
(longer version)... yet hopefully?
I finally received the proper connectors so I could probe the internal connector, and finally had a moment to actually do it. If I connect with a program like zterm I see data on the Tx line, and I can decode it with my scope. yay! But if use the Network control panel to set the port to Modem for Appletalk, tx is silent.
So I started looking in the schematic if my chance I missed maybe a signal that needs to be asserted? It seems not, but looking close at the SCC page in the schematic I can see the buffer:


the "enable port A" pin of the buffer is connected to a suspicious-looking signal, MODEM_PCNTL, which connects then to the Misc GLU.
When I open the port with zterm, that signal goes low and all is good, but when I select the port for localtalk, it is high and the output disabled.
But when localtalk is enabled I see activity on TXDA on the left side of the buffer!


Now the scope decodes the pulses as 0x55 (or ascii 'U') at the localtalk speed, I'm not sure if it makes sense? In any case if I disable Appletalk or switch to the Printer port that signal disappears.

Now I think it is a software problem, probably a register must be set to to assert MODEM_PCNTL? I could not find any reference on this, probably because it is an internal signal. I went through the application notes for the Portable and the PB100, plus the Hardware manual of 1990 but I could not find anything useful, except that both the Portable and the PB100 should share the same rom (at least this is what the manual says), but the Misc GLU seems quite different.
Moreover the PB100 dev note quite clearly says that both ports support Appletalk:

I guess then the thing to do is figure out what controls MODEM_PCNTL. Maybe I'm just missing something very obvious here Or maybe we can make an INIT that sets the proper register... Any ideas and pointers are welcome!

 

[tashtari]

Don't know how helpful this is, but the pattern you're seeing that reads as 0x55 when interpreted as RS232 at 230400 bps is consistent with the SCC clocking out an endless series of ones in AppleTalk/SDLC. It would not surprise me to learn that this is the SCC's idle state when in SDLC mode and that it depends on other circuitry to turn the RS422 drivers on when transmitting and off when done.

 

[twelvetone12]

Ah yes true, the driver has TXEN/ controlled by RTS, I guess in this case I would need to disconnect TX to the TashTalk when not transmitting right? (i.e. add a switch that interrupts the signal path when RTS is high)

 

[tashtari]

Yeah. If TashTalk sees an endless series of ones, it'll sit around waiting for a flag byte and never transmit anything because it assumes the bus is in use.

 

[twelvetone12]

True, I need to keep this in mind if I manage to find a way to assert MODEM_PCNTL.

 

[twelvetone12]

Today I worked a bit more on this and after a crash course in MacsBug I was set to figure out a solution.
Poking in the docs there are a couple cool functions, AOn and AOff (and their relative BOn and BOff) which turn on/off port A and B of the SCC. These are aliases for the PMgrOp trap with different values in D0. A fourth one is AOnIgnoreModem() which on the Portable does not turn on the modem power. Ignoring port B (which is the printer port), AOn and AOff do what is expected: if I select the Modem port in the Networking control panel and then do a call to AOn() I see the serial data coming off the internal modem port! Which is great, except that the PCNTL signal is always disabled at boot and after I select the port from the control panel. After (too) many hours of debugging I figured out that when switching the ports, the system code turn off everything and then calls AOnIgnoreModem(), which on the Portabe makes sense because localtalk would be on the external port, so the modem can be turned off, but on the PB100 it does not assert PCNTL. For that a call to AOn() is needed.
At this point I'm again a bit stuck, because I suppose the code for switching the port is in ROM? I decompiled the "Localtalk (Modem)" extension and as I expected there are no calls to _PMgrOp, so I guess the code has to be somewhere else.
At this point any ideas on how I could make a patch are welcome

 

[cheesestraws]

Hrm. One option here might be to patch the _PMgrOp trap so that AOnIgnoreModem behaves like AOn?

 

[cheesestraws]

At this point any ideas on how I could make a patch are welcome

Have a go and see whether this does anything sensible. I don't have any hardware with the power manager to test it on handy (or any real hardware at all) but what this ought to do is to intercept all calls to _SerialPower with d0=5 and set d0=4 instead. Which should hopefully make AOnIgnoreModem behave like AOn.

Since I haven't even been able to run this it comes with even less guarantee than usual...

 

[twelvetone12]

Haha I wish I saw your message earlier this morning, you did exactly what I am struggling to do. Will test and report back! thanks!

 

[twelvetone12]

I tried your INIT and unfortunately it crashes at startup Since I only have THINK C 5 on my PB100 I went on and retyped almost everything (I just changed how the global variable is accessed), and after quite I bit of grief with it always crashing I figured out `cmp.w 0x05, d0` and friends should be immediate ops: `cmp.w #0x05, d0`. Small detail = 1 hour of debugging Now it works! When I select "modem" from the control panel I seen traffic on the external port on the scope! Now I just need to verify that the control signals get passed correctly, hook it up to an rs422 tranceiver and see if it actually works! I'm pretty excited (but unfortunately I will be travelling and for a couple weeks it will be on standby)
The only annoying flaw right now is that the INIT gets loaded fairly late at boot, so after Localtalk is initialized, and the port does not come up automatically, one must turn appletalk on and off for it to work. Maybe in the future if this actually work we can figure out a patch. For now, I'm pretty happy to see the tx signal

 

[cheesestraws]

Oops! Yeah, I was coding it rather blind, I'm afraid...

Glad it's working now. Yes, we can hook it in earlier in the boot sequence later if the rest works