Search results

The second attempt at address arbitration seems to come somewhere from the AppleTalk stack. I tried this in raw.c where I'm sure there is only one call to set the address, and I get the same result as you, but in no place I set the address twice! I will have a deeper look, personally I'm not a...

Mini update: I finally build a high-tech adapter for a real localtalk network, and tried everything with MacOS 9.1 which worked well (except copying files to the pc) My high-tech USB to LocalTalk (not shown the PhoneNet link) Happy MacOS 9.1 on my PowerBook G3 PDQ. I wanted to try it with...

Mini update: I implemented a basic ENQ responder and basic arbitration for the address, and cleaned up stuff around the code. It is slowly getting there :) Next steps are making a read usb -> lt interface so I can test it with other macs, and trying to figure out what is wrong with afpd.

Yes afpd seems to do some weird stuff with permissions, I will have a look there later, for the moment I want to make sure the driver is working, finish up what is missing, and clean it up. BTW I merged you patch, many thanks!

Pull-up added, the framing errors seem to have disappeared! Now there is a problem with afpd that I cannot copy filoes from the mac to the pc, but it does not seem the driver's fault, I have no idea what is going on :( (printing and copying files to the mac works perfectly)

The serial on the modem port continuously outputs data even when it disables the transceiver, so the interference could come from that (keep in mind, my setup is dodgy on this respect)

No problem, it is just to add a pull-up after mi tri-state buffer in my setup :) I suspect that is what generates the frame errors on my system.

Quick question: on TashTalk 1 the LocalTalk input should be idle low or high?

I can do that when the driver is opened by the line discipline, I will have a look. I'm not sure about the buffers not flushing, since they should be de allocated when the driver is closed, but I can test that.

I'm going to add the pull{up/down} (I don't remember which) and try to get some scope screenshots for you later this week.

@NJRoadfan This is so cool!! Fantastic!! Sorry I did not send you my netatalk conf, I am away and I can't access my linux box, I was thinking of setting up a document with the various configurations we have. Thanks for the code, I will include the mods in the repo. I think there should be no...

Yeah German customs can be quite opaque, I should have had you send it to CH. No problem, I will build my own :) I got the trancievers for the USB2LT thing I want to build! But it will take some time.

Mmh yes the CRC is not included in the MTU which is checked before and CRC added later. In theory you should not be able to send bigger packets with sendto() than 587 bytes from userspace, at least I could never manage to send bigger pkts. You should be able to increment the MTU, the tt driver...

Soo.. I think I fixed it! :oops: It was the buffer that sometimes would not completely flush. I added that and well... I can transfer files from my pc! I forgot how slow it is with big files.

Yes that's my plan! Digikey just dropped a package yesterday with some PICs and I will make exactly that, when I have the next slot for this project. Unfortunately my RPi hat is still lost in German customs :(

My hunch is that something gets messed up when transmitting a stream of big packets, since aecho works perfectly but the packets are quite slow, afp on the other hand sends them almost back-to-back. But I'm not 100% sure where, I will need to make a tash-sniffer so I can either log packets on...

I had a moment today and I tried to stress the system with packets up to the MTU. I made an echo that had a 587 byte payload which translated to 597 bytes on the line (with header and checksum). I got perfect echos back. But if I run afpd and try to get a file, I see many big packets going out...

Yup I think it is the same problem we had - on some boards. For internal use it is ok, but we cannot risk giving one to a consumer.

It was around a year and a half ago or so, we did quite a bit of boards with them ok, then the next few batches had some problems, like solder mask burning away when reflowing (!), I can ask our guy responsible more details, but since we wanted to use these in production for products we sell we...