TashIO: Clone of BeeHive Technologies's ADB I/O

[Phipli]

Latest version of my design...

I tweaked the schematic.

I've deviated from the original terminal pinout, be warned.

Edit - small but important tweaks

 

[tashtari]

a second controller in the Macintosh that would create a second, independent ADB bus, so you could have more devices.

Ah, that's more into the software side of things, with which I am less familiar. The ADB Manager might have the capability to recognize a secondary controller, but I doubt it... but I could be wrong.

 

[Melkhior]

Ah, that's more into the software side of things, with which I am less familiar. The ADB Manager might have the capability to recognize a secondary controller, but I doubt it... but I could be wrong.

That's what I'm worried about... I'll have to investigate. Thanks for the pointers to your debugging stuff.

 

[keelan]

Ah, that's more into the software side of things, with which I am less familiar. The ADB Manager might have the capability to recognize a secondary controller, but I doubt it... but I could be wrong.

I haven't seen anything in the ADB manager that hints at it supporting more than one host controllers; all of the functions are structured around there being a single linear address space.

But I was thinking, all of the ADB I/O commands include the two bit unit ID in the command, and they don't use SRQs for anything, so it would be possible for all of the units to occupy a single ADB address. Just spitballing, but unit ID 0 could be the primary unit, that handles the boot-time address shuffle process, and any talk/listen register 3 commands, with all of the other units acting as secondary units, only responding to ADB I/O specific talk/listen register 1/2 commands that contain their address. By "observing" all of the register 3 commands targeted at the primary unit, the secondary units could essentially clone the primary unit's ADB address.

 

[Phipli]

Considering thay ADB was for low speed peripherals, and can technically address up to 255 devices, they might not have ever considered it. Is they anything extra that can be done with a second bus?

 

[keelan]

I was thinking maintain compatibility for the existing four outputs, but extending the protocol to recognise extra variations using the "don't care" bits in the ADB commands?

I suspect the ADB I/O as we know it was carved out of a more complex device, one with more inputs and outputs. The protocol feels like it's unnecessarily verbose for a device with 8 I/O pins.

I batted around the idea of using the extra bits in the protocol to make a bigger device, but the problem there is that we would lose all compatibility with the original software. We still have the C source, so new software could be easily created to use a fancy pants new protocol, but for two of what I think are the most commonly used interfaces (HyperCard and AppleScript), the source is not available.

I'm going to try contact Magnus Pettersson, he was the guy behind the original mac software for the ADB I/O. He might still have his old files.

 

[keelan]

Considering thay ADB was for low speed peripherals, and can technically address up to 255 devices, they might not have ever considered it. Is they anything extra that can be done with a second bus?

The protocol only has room for 4 bit addresses, or 16 devices. The toolbox code uses 8 bit values for the addresses, but the underlying protocol only has room for 4 bits of address.

 

[Phipli]

The protocol only has room for 4 bit addresses, or 16 devices. The toolbox code uses 8 bit values for the addresses, but the underlying protocol only has room for 4 bits of address.

Ah sorry, I didn't realise it had a 16 device limit.

 

[Phipli]

but for two of what I think are the most commonly used interfaces (HyperCard and AppleScript), the source is not available.

For HyperCard it will be usefully similar - XCMDs / XFCNs were... if I remember... code resources and there are examples with CodeWarrior. I don't know anything about AppleScript extensions.

I'm going to try contact Magnus Pettersson, he was the guy behind the original mac software

That would be great - it can be really handy when the original devs get involved. I'd be interested to know the history of the product.

 

[tashtari]

all of the ADB I/O commands include the two bit unit ID in the command

They don't - the ADB I/O unit number is communicated through bits 11 and 10 of the Talk 3 command (which are technically supposed to be random) and the MSBs of the Talk 1 and 2 commands. The ADB I/O software uses this to enumerate the four units and associate them with their current four-bit ADB address.

they don't use SRQs for anything

They do use SRQs - per page 49 of the manual, if a pin is configured as digital on Port B and the signal on it changes, the ADB I/O will raise a SRQ and Talk 0 will give the same reply as Talk 1 (which is what is usually used to read Port B). I'm not sure if any software ever used this sort of interrupt-on-change functionality but I implemented it in TashIO just in case...

 

[tashtari]

Maybe I'm being too conservative, but I don't see much in the way of good ways to expand the existing protocol. The fact that so many bits are labelled as don't-cares means that we can't maintain compatibility with existing software because we can't depend on how it'll set them, and all the command/register combinations are spoken for except for Listen 0. As long as we're getting the original code, we might as well create an entirely new protocol with its own handler ID...

 

[Phipli]

Maybe I'm being too conservative, but I don't see much in the way of good ways to expand the existing protocol. The fact that so many bits are labelled as don't-cares means that we can't maintain compatibility with existing software because we can't depend on how it'll set them, and all the command/register combinations are spoken for except for Listen 0. As long as we're getting the original code, we might as well create an entirely new protocol with its own handler ID...

I'm not sure that we need to maintain compatibility, but a couple of other thoughts. Using a shift register we have a spare pin that we can add another pullup / pulldown to to indicate a compatibility mode, and operate completely as normal (using a shift register, but treating the protocol as stock). Secondly, even though it says "don't care", the software might (probably does) always send the same thing.

It doesn't matter though. I was only thinking about it because other interface boxes I have use numbered commands so you can just add extra command numbers in the protocol. If it had been similar it would have given us extra outputs - electrically it is trivial.

 

[keelan]

They do use SRQs - per page 49 of the manual

Oh, I guess I should pay closer attention to the manual! I don't remember any software using that functionality. If I'm not mistaken, for something to take advantage of the SRQ functionality, it would need to be implemented as a driver, rather than a "user space" program, and I can't think of anything that implemented an ADB I/O system extension.

 

[Phipli]

This is an archive of everything I was able to download that was a PDF or hqx (I think). Two files threw errors, and there is also useful info in the actual html pages that I didn't grab. The main software download is one of the files that throws an error frustratingly.

 

[keelan]

The main software download is one of the files that throws an error frustratingly.

I still need to pull an image of my ADB I/O disk, but the floppy didn’t contain anything particularly special. I think it had the HyperCard stack and maybe the AppleScript extensions. It was just a physically shippable version of stage same stuff available on the website.

 

[Phipli]

I still need to pull an image of my ADB I/O disk, but the floppy didn’t contain anything particularly special. I think it had the HyperCard stack and maybe the AppleScript extensions. It was just a physically shippable version of stage same stuff available on the website.

Is this on the disk? Its what I assumed was broken.

 

[keelan]

First signs of life! This is just a simple test, I’m reading the ID jumpers and outputting their values on port B (no ADB code in play at all), but it helped me sort out the PIC’s config words. I didn’t know that low voltage programming mode steals RB3, which is one of the unit ID pins.

I also received my order of black screw terminals. I’m liking the look.

Please don’t judge me for my power supply enclosure. An AT power supply fits into an Apple II floppy enclosure beautifully, and the ‘90s were a different time.

 

[keelan]

Is this on the disk? Its what I assumed was broken.

Yes, that’s the same stack that’s in the XCMD download.

 

[Phipli]

First signs of life! This is just a simple test, I’m reading the ID jumpers and outputting their values on port B (no ADB code in play at all), but it helped me sort out the PIC’s config words. I didn’t know that low voltage programming mode steals RB3, which is one of the unit ID pins.

I also received my order of black screw terminals. I’m liking the look.

Please don’t judge me for my power supply enclosure. An AT power supply fits into an Apple II floppy enclosure beautifully, and the ‘90s were a different time.View attachment 48932

Excellent work! It looks really nice in black and purple.

I hope that is an LED with a built in current limiting resistor?

 

[keelan]

I hope that is an LED with a built in current limiting resistor?

Each terminal on port B has a 270 ohm resistor in series with the PIC’s pin.