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...
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...
tashtalkd's function is to bridge between TashTalk's serial protocol and LToUDP - AirTalk does the same thing, bridging LocalTalk to LToUDP. Netatalk 2.x only speaks EtherTalk, so what you need is to bridge LocalTalk/LToUDP to EtherTalk. On a Mac, LocalTalk Bridge will do this; on an RPi...
@Dandu Thanks for the links! I've only begun to scratch the surface of all that's there (even though I don't speak French) but if the Power Rangers Zeo game is any indication, at least some games operate on the principle of showing pictures of the buttons, which would emphasize color over...
I haven't made a schematic but there is a connection diagram at the top of the .asm file: https://github.com/lampmerchant/tashtrio/blob/main/firmware/tashtrio.asm#L27
So, thanks to @sfiera 's generosity, I now have a Pippin controller and was able to quite easily RE its protocol. (Details here if you're interested.)
I'm now contemplating a PIC firmware project that will allow the use of a more easily obtainable controller (probably SNES or Playstation) as a...
I don't see Geneva 9 in the list, that could be the root of your problem. In any case, from what you've described, I doubt this is a TashTwenty issue...
If you can get Python running on a IIgs... =)
But seriously - no, TashTwenty won't work on a IIgs as they don't support DCD (the protocol used by the Hard Disk 20). They do support SmartPort, which is a notionally similar protocol, but it's totally incompatible with DCD.
Oh, I should emphasize: TashTalk 1.x and 2.x are not pin-compatible, so (if you have the capability to do so) do NOT upgrade the TashTalk on your AirTalk or bdurbrow's TashTalkHat - it will stop working.
If you have one of the TashTalk 2 RPi hats, you can upgrade but won't see any benefit from...
Version 2.1.0 of the TashTalk firmware is out! You can get it from github here:
https://github.com/lampmerchant/tashtalk
Nobody using TashTalk right now should feel any pressure to upgrade, as there are no bugfixes. (Knock on wood, there are no known bugs to fix...)
What this version adds...
At some point it'd be great to work with someone with a 6100 to put a bus analyzer on the port and try to figure out what's going wrong. This may be a TashTalk problem, and that worries me...
Oh, neat, I completely missed that that feature exists in ADB Parser.
Assuming that struct is MSB to LSB top to bottom (my C is very, very rusty), you're exactly correct - that's the standard ADB mouse protocol indicated by handler ID 0x01 (for 100 cpi) or 0x02 (for 200 cpi).
This is normal...
The basic ADB mouse protocol has a bit that is sometimes labelled as being used for the second button, though the only two-button ADB mouse I have seems to implement a drag-lock for its second button (it might support a special handler ID, I haven't tested). Your mouse might be using this but...
@cheesestraws Thanks for sharing this, it was useful to read. TashTalk notwithstanding, networking is not my long suit and most things about AppleTalk above LocalTalk are mysterious to me.
It makes me wonder how complicated an undertaking it would be to make a router in a PIC16F1788 with one...
I should note here that some debugging with FinkRMT on the IRC channel has shown that the TashTalk 2 hat won't work with an Apple serial cable (not a use case for which I planned), you need to use a LocalTalk or PhoneNet dongle.