CircuitBored
Well-known member
Very exciting stuff! I can't wait to get my hands on one. Congratulations to everyone involved in bringing this project to life.
I implemented a userspace barebones LocalTalk to EtherTalk bridge for my project, prior to getting the kernel module working. I believe I emulated the approach used by the Farallon EtherWave Printer Adapter. It was pretty hacky and incomplete, but it did work as a proof of concept. I've attached a zip of the userspace portion of the code (GPLv2). Hope this is useful!
Sure thing! See attached. Unfortunately 68kmla doesn't allow me to upload a tar.gz file so I'll have to go with zip. I do believe it should be possible to adapt this code to work with TashTalk. Notes:Is it possible to post the code to the kernel module somewhere?
I was reading my code to try and remember why I did it that way, and I think the answer is simply that there's no time to send a frame-start sentinel. We don't know for sure that a frame is starting until we get the first byte of it (it could just be flags, i.e. almost but not quite a frame) at which point we need to start the UART transmitting that byte. As such, the chip's UART's output ends up being either "stick this byte on the end of your buffer" or "your buffer now contains a frame, process it" or "your buffer contains nonsense, dump it".TashTalk sends a whole frame and than a frame complete/error/aborted marker. This seems backwards to me as usually the beginning of a frame or packet gets a marker.
I was reading my code to try and remember why I did it that way, and I think the answer is simply that there's no time to send a frame-start sentinel. We don't know for sure that a frame is starting until we get the first byte of it (it could just be flags, i.e. almost but not quite a frame) at which point we need to start the UART transmitting that byte
I'm guessing the actual SCC chip normally checks if a CRC is valid? Also I'm going to assume the CRC byte is stripped out by the host before being processed by the AppleTalk stack.