• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

TashTalk: Single-Chip LocalTalk Interface

tashtari

Active member
nothing still in use today talks Phase 1, including the Linux kernel drivers for AppleTalk
Do the kernel drivers even enter into it, though? Netatalk 2.x talks Phase 1, or at least the options make it appear that it does, so if you create a tap and put EtherTalk Phase 1 frames into it, and Netatalk picks them up, what does the kernel know or care?
 

cheesestraws

Well-known member
Both IP and AppleTalk stacks are actually in kernel space; netatalk provides application services but doesn't do actual network-level stuff. This made sense when maximum performance was the goal here. Unfortunately, at this point, all this means it that when the Linux people decide to break the kernel AppleTalk stack again, netatalk stops working and there's nothing much anyone can do about it, especially given the rather dodgy attitude towards patches in the Linux kernel.

This, among other reasons, is why, pace some people, I do not believe that netatalk2, especially on Linux, is a feasible middling- or long-term solution to providing network services to older machines.
 

mactjaap

Well-known member
For now AppleTalk is saved in Linux kernel. I have it working with a modern Linux on my MacIPRpi. Bug is fixed thanks to a fellow 68kmla member.

But LocalTalk PC Cards stopped to work after Debian 3.0 (Woody). For now I’m testing from Debian 2.2 to Debian 6. As said… will make a separate post about this. Also acquired a DL2000 card which works with COPS driver. Seems more modern then the first LocalTalk PC Cards. I hope to get it working.
 

mactjaap

Well-known member
I haven't forgotten about my promised hat layout; I've just been crazy busy for the last week or so...
Absolutely great you are working on the Rpi hat! If you can design and build it more people will be able to test the setup. Lots of success!
 

bdurbrow

Well-known member
Finally got a chance to get some work done on the hat...

It's setup to fit directly on top of a Pi Zero-W, and I wanted to put the pin names for the Pi's GPIO header on the board's silkscreen, but there just wasn't enough room.

I also don't have any ICSP pins for programming the PIC on the board yet. In the final version, I'd rather not have to pop the PIC out of it's socket to do a re-flash.

It's preliminary, and untested, but here's what I've got so far:

Screen Shot 2021-09-27 at 12.53.55 AM.jpg

Solder side copper:
Solder.png


Component side copper:
Component.png
 

bdurbrow

Well-known member
Added an ICSP header and some jumpers to isolate the ICSP pins on the PIC from the other devices during programming.

Screen Shot 2021-09-27 at 2.26.45 AM.jpg
 

cheesestraws

Well-known member
A couple of thoughts:
  • All normal mac serial cables are crossover. DCE/DTE isn't a thing in the mac world. Localtalk boxes would also rely on straight wiring. To me, having the jumper for crossover/straight is an invitation to people making it not work and then complaining about it. Pretty much nothing else that plugs into Mac serial has a crossover/straight switch.

  • I don't see any TVS diodes; and you just know someone is going to be running this attached to a phonenet network that runs out a window, or something. I was looking at the SM712/SP712s which seem to be very available (even in the JLCPCB SMD assembly process)
 

bdurbrow

Well-known member
Yes, but you can't always get a Mac-specific cable. Hence the jumpers.

TVS diodes will be added... as mentioned, it's a preliminary layout. I generally put them on everything unless the chip already has it built-in.
 

bdurbrow

Well-known member
Interestingly, both DigiKey and Mouser seem to be out of inexpensive RS422/RS485 TVS diodes. Had to order them from China via eBay. Won't be here til' December, though... so until then, hooking it up to anything that could exceed the ESD protection of the ISL83076EIBZA is strictly verboten!
 

ronan

Well-known member
I also don't have any ICSP pins for programming the PIC on the board yet. In the final version, I'd rather not have to pop the PIC out of it's socket to do a re-flash.

You could use a serial/spi/i2c bootloader so that you don't need them :)
 

tashtari

Active member
Finally got a chance to get some work done on the hat...
Cool! I'm really excited about making this more accessible to more users. (And cleaning up my work bench, into the bargain!)
You could use a serial/spi/i2c bootloader
A firmware update function in the serial protocol (it'd have to be done over the UART, there are no pins free for anything else) would definitely be a useful bit of functionality. I've looked into it a little and it's doable - the PIC12F1840 has a self-write function - it's just a matter of upsetting the delicate balance of the existing code. Regardless, though, having ICSP pins on the board is still definitely a good idea in case of bricking, &c.
 

tashtari

Active member
I imagine closer to 10 given the number of active people on this thread, but I could be wrong - I'll certainly buy one (I lack the skill to solder surface-mount components).
 

bdurbrow

Well-known member
if you're up for posting one to the UK

I'm not looking to get rich off of these; so I'll be charging close to actual BOM cost plus actual shipping. I have access to UPS, FedEx, and USPS (which in your case gets delivered via Royal Mail); and I can send them via any class you want.

I'll have a cost breakdown soon; I just need to go gather some numbers...
 

bdurbrow

Well-known member
OK, I think I'm looking at about $15 each + shipping; add an extra $2 if you want stacking headers instead of regular ones. That leaves a little margin to cover my miscellaneous costs (solder; flux, gas to go to ship it, etc).
 
Top