cheesestraws
Well-known member
Oh, now that is a good idea.
-
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.
TashTalk: Single-Chip LocalTalk Interface
- Thread starter tashtari
- Start date
Oh, now that is a good idea.
twelvetone12
Well-known member
TBH I personally would prefer a solution just with the mini din, so then you plug whatever you need, phonenet, localtalk or just a serial cable with one machine 
Edit: well actually nobody would prevent us to do both, one with mini din and one with the transceiver+Integrated transformer, it will be a pretty simple circuit in any case.
Edit: well actually nobody would prevent us to do both, one with mini din and one with the transceiver+Integrated transformer, it will be a pretty simple circuit in any case.
sfiera
Well-known member
I think the problem is the need for VDD2. LocalTalk cabling just has signal and ground, right?
twelvetone12
Well-known member
Yes making VDD2 seems quite simple, the datasheet even suggests what transformers to use If you guys are interested I can draft a schematic for both adapters (I surely want to make the one with the rs422 minidin port)
If you guys are interested I can draft a schematic for both adapters (I surely want to make the one with the rs422 minidin port)twelvetone12
Well-known member
I made another thread so we don't OT too much here: https://68kmla.org/bb/index.php?threads/usb2lt-tashtalk-usb-to-localtalk.45282/
tashtari
PIC Whisperer
Some people have expressed interest, so I ordered some more PCBs and made up some more TashTalk 2 RPi hat kits. They're in my Ko-fi store: https://ko-fi.com/tashtari/shop
tashtari
PIC Whisperer
TashTalk v2.1.1 has been released!
This release fixes a bug with certain transceiver setups by which latency between TashTalk turning the driver off and the receiver returning to idle/high would cause TashTalk to mistakenly detect a frame immediately after sending an RTS frame, preventing it from transmitting at all. See this thread for more details (and thanks to @twelvetone12 for reporting this issue and working with me to reproduce it!) This release also fixes a very minor off-by-one bug that would cause TashTalk to retry sending an RTS frame 33 times instead of the intended 32.
Upgrading requires a Microchip programmer such as a PICkit or ICD.
Users of TashTalk v2.0 and v2.1 may upgrade to v2.1.1 but it should not be considered necessary at this time unless your transceiver setup is unable to transmit LocalTalk data frames at all. TashTalk 2 Raspberry Pi hats do not appear to have this issue.
AirTalk users and other users of TashTalk v1.x firmware must not upgrade to v2.1.1 or any v2.x version of the firmware. TashTalk v2.x introduces a breaking change in the microcontroller's pinout and upgrading to v2.x firmware without a corresponding change in board routing will cause your system to stop working.
This release fixes a bug with certain transceiver setups by which latency between TashTalk turning the driver off and the receiver returning to idle/high would cause TashTalk to mistakenly detect a frame immediately after sending an RTS frame, preventing it from transmitting at all. See this thread for more details (and thanks to @twelvetone12 for reporting this issue and working with me to reproduce it!) This release also fixes a very minor off-by-one bug that would cause TashTalk to retry sending an RTS frame 33 times instead of the intended 32.
Upgrading requires a Microchip programmer such as a PICkit or ICD.
Users of TashTalk v2.0 and v2.1 may upgrade to v2.1.1 but it should not be considered necessary at this time unless your transceiver setup is unable to transmit LocalTalk data frames at all. TashTalk 2 Raspberry Pi hats do not appear to have this issue.
AirTalk users and other users of TashTalk v1.x firmware must not upgrade to v2.1.1 or any v2.x version of the firmware. TashTalk v2.x introduces a breaking change in the microcontroller's pinout and upgrading to v2.x firmware without a corresponding change in board routing will cause your system to stop working.
Last edited:
tashtari
PIC Whisperer
TashTalk v2.1.2 has been released!
This release further fixes (or, depending on your perspective, re-fixes) the bug mentioned in the previous release where frames were falsely detected after sending an RTS frame. Now, rather than a fixed delay, the firmware waits for the line to go idle. I probably should have done this in the first place, but was worried about spinning indefinitely - on further examination, I do not believe this will be a problem.
In addition to the above, the node ID bitmap is now zeroed out on startup - previously there was a small risk that TashTalk would respond on behalf of random node IDs before software zeroed out the node ID bitmap, this is no longer a concern.
Upgrade instructions and cautions are the same as for v.2.1.1 above.
This release further fixes (or, depending on your perspective, re-fixes) the bug mentioned in the previous release where frames were falsely detected after sending an RTS frame. Now, rather than a fixed delay, the firmware waits for the line to go idle. I probably should have done this in the first place, but was worried about spinning indefinitely - on further examination, I do not believe this will be a problem.
In addition to the above, the node ID bitmap is now zeroed out on startup - previously there was a small risk that TashTalk would respond on behalf of random node IDs before software zeroed out the node ID bitmap, this is no longer a concern.
Upgrade instructions and cautions are the same as for v.2.1.1 above.
tashtari
PIC Whisperer
Another bit of news, I've announced a new TashTalk-adjacent project. Please check out TashRouter!
tashtari
PIC Whisperer
TashTalk v2.1.3 and v1.0.1 have been released!
These releases put in place a more robust fix for the issue that v2.1.1 and v2.1.2 attempted to fix as well as fixing the incompatibility between TashTalk and the Power Macintosh 6100 and some similar machines. See release notes for further details.
Upgrading requires a Microchip programmer such as a PICkit or ICD.
Users of TashTalk v2.x versions prior to v2.1.3 may upgrade to v2.1.3 and users of TashTalk v1.0.0 may upgrade to v1.0.1, but it should not be considered necessary unless your setup is unable to communicate with one or more Macintoshes on your network (such as a Power Macintosh 6100).
Users of TashTalk v1.x must not upgrade to v2.1.3 or any v2.x version because of the change in pinout between v1.x and v2.x.
AirTalk users have TashTalk v1.0.0 and may upgrade to v1.0.1 as above.
These releases put in place a more robust fix for the issue that v2.1.1 and v2.1.2 attempted to fix as well as fixing the incompatibility between TashTalk and the Power Macintosh 6100 and some similar machines. See release notes for further details.
Upgrading requires a Microchip programmer such as a PICkit or ICD.
Users of TashTalk v2.x versions prior to v2.1.3 may upgrade to v2.1.3 and users of TashTalk v1.0.0 may upgrade to v1.0.1, but it should not be considered necessary unless your setup is unable to communicate with one or more Macintoshes on your network (such as a Power Macintosh 6100).
Users of TashTalk v1.x must not upgrade to v2.1.3 or any v2.x version because of the change in pinout between v1.x and v2.x.
AirTalk users have TashTalk v1.0.0 and may upgrade to v1.0.1 as above.
Does anyone here have a TashTalk and one of the below machines?
-Centris/Quadra 660AV/840AV
-Power Macintosh 61/71/8100
-Power Macintosh 72/73/75/76/85/86/95/9600
If so, can you test and see if you TashTalk without the above upgrade works with your machine? The thing all the above machines share is the Curio I/O chip. Based on some research, this chip contains a Zilog "Enhanced SCC" core with some "custom" LocalTalk extensions added onto it. One of the features mentioned in AMD's datasheet and Apple's internal communications is the chip's ability to automatically send a sync pulse with any data transmission. This is very likely the source of the various compatibility problems.
-Centris/Quadra 660AV/840AV
-Power Macintosh 61/71/8100
-Power Macintosh 72/73/75/76/85/86/95/9600
If so, can you test and see if you TashTalk without the above upgrade works with your machine? The thing all the above machines share is the Curio I/O chip. Based on some research, this chip contains a Zilog "Enhanced SCC" core with some "custom" LocalTalk extensions added onto it. One of the features mentioned in AMD's datasheet and Apple's internal communications is the chip's ability to automatically send a sync pulse with any data transmission. This is very likely the source of the various compatibility problems.
cheesestraws
Well-known member
Phipli
Well-known member
Their question seems to be the reverse, that they're asking people to test the un-upgraded firmware.
Regardless, the issue isn't as widespread as that lists suggests. I've been using them on the 9500, although with the intermediate beta firmware that didn't work on the 6100/66.
I've also used one at the meetup on my 7200, so that doesn't suffer the issue either. Really feels like it was limited to Nubus PowerMacs. I wouldn't be surprised if it impacted the 660/840 as well as they're fairly similar, but I haven't tested. I'll leave it to someone that has one set up.
I suspect the issue isn't there on PCI PPC.
Phipli
Well-known member
Side note...
Anyone in the UK wants their firmware updating, I don't mind doing it.
Drop me a message and we can sort it out. I have the hardware and software sat on the table about a foot from my elbow right now.
Warning, if you leave it too long I might have put away the stuff and be grumpy about finding it, so sooner is better.
"Macintosh HD" share is via an AirTalk from MinivMac.
Anyone in the UK wants their firmware updating, I don't mind doing it.
Drop me a message and we can sort it out. I have the hardware and software sat on the table about a foot from my elbow right now.
Warning, if you leave it too long I might have put away the stuff and be grumpy about finding it, so sooner is better.
"Macintosh HD" share is via an AirTalk from MinivMac.
Just spitballing a theory. Curio's enhancements seem to be the only thing really different from the rest of the Macintosh SCC implementations. I also can't rule out that a specific driver revisions of an extension called "Serial DMA" may be the culprit. This extension apparently fixed various bugs with the serial ports over the years. One of the revisions may outright disable Curio's LocalTalk enhancements. FWIW, TashTalk worked fine with my Beige G3 running 9.2.2.... but that machine has the Heathrow I/O chip. That chip appears to lack Curio's enhancements and only has a standard ESCC core.
I also have a non-Apple device that isn't working with TashTalk that I'm going to test with the revised firmware soon. My HP LaserJet 4MP's onboard LocalTalk doesn't seem to like it. The board has a Zilog ESCC, but who knows what HP's programmers did with it!
I also have a non-Apple device that isn't working with TashTalk that I'm going to test with the revised firmware soon. My HP LaserJet 4MP's onboard LocalTalk doesn't seem to like it. The board has a Zilog ESCC, but who knows what HP's programmers did with it!
Phipli
Well-known member
Did you see my previous reply? I've not had any trouble using the old firmware on PCI macs, I don't think it impacts as many models as you suggest. We might have heard more about it given that is every professional Mac from 1993 to 1997!
Finally got a PIC programmer and updated to 1.0.1. This solved all lingering compatibility issues I was having with LocalTalk devices. Besides the PowerMac 6100, the v1.0 firmware was not working with the LocalTalk port on my HP LaserJet 4MP. This has now been resolved.
