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

Mac SE ADB Controller

tashtari

Well-known member
"I've discovered more writing on the parchment!"

Looking at the code some more, based on the timing in sending the '1' start bit, I think the external clock is 2 MHz exactly.

Also, further confusing the issue about the data direction registers, there are a pair of subprograms that ostensibly clock a byte into and out of the VIA using the same pin in both directions (pin 9, RB3, CB2 on the VIA). I had previously thought this was an output. This doesn't make sense unless the PIC's GPIO ports are open-collector - a 1 meaning let float and a 0 meaning pull to ground. It'd explain some other stuff I'm seeing in the code. Thing is, that's not how the GPIO ports on the PIC16F54 work. Maybe Apple made some kind of deal with Microchip to make a special open-collector version of the PIC16CR54, because that's not how the PIC16CR54 works, either...

This is a problem, because it means one can't shim a couple instructions in to make the PIC16F54 work like the special Apple PIC16CR54, nor is there a register substitution that can be made to do the same. At this point, what I've seen makes me think it'd be better to target imitating the chip rather than duplicating it.
 

tevruden

Member
I checked both pin 9 from the GLU and pin 16 on the PIC, and my scope reads 3.672 MHz but super jittery. I checked pin 6 and 7 for any sort of signal but didn't see any. I have logic analyzer dumps that track pins 1-3, 8-10, 17 and 18 if that'd shed light on anything.
 

tashtari

Well-known member
my scope reads 3.672 MHz
Huh, that surprises me. The code I was basing that off of had exactly 17 cycles between pulling the ADB pin low and releasing it, which at a 2 MHz clock (500 kHz instruction clock) is 34 us, which is almost 35 us, the nominal low time for a '1' bit in ADB.
 

tashtari

Well-known member
I've been attempting to make some sense of the disassembly. I've got some fairly substantial pieces worked out, but I don't really understand what the protocol is between the VIA and the PIC. CB1 and CB2 are a clock/data synchronous serial port, that's clear, PB5 and PB4 seem to be control signals from the VIA, but their significance is still opaque. PB3's purpose is even less clear; sometimes it seems to be pulled low to signal an error, but it's also pulled low to signal that one of the devices on the bus has done an SRQ. Dunno.

Anyway, I'm uploading what I've got so far in case this is useful to anyone else.
 

Attachments

  • macse_adb_asm_20220311.zip
    6.7 KB · Views: 10

mdeverhart

Well-known member
The MiST project has an implementation of the ADB controller wired up to a model of the VIA. The VIA core is used in a number of other projects, so hopefully it’s close to the actual VIA hardware.

 

demik

Well-known member
Also, further confusing the issue about the data direction registers, there are a pair of subprograms that ostensibly clock a byte into and out of the VIA using the same pin in both directions (pin 9, RB3, CB2 on the VIA). I had previously thought this was an output. This doesn't make sense unless the PIC's GPIO ports are open-collector - a 1 meaning let float and a 0 meaning pull to ground. It'd explain some other stuff I'm seeing in the code. Thing is, that's not how the GPIO ports on the PIC16F54 work. Maybe Apple made some kind of deal with Microchip to make a special open-collector version of the PIC16CR54, because that's not how the PIC16CR54 works, either...
Could it be that since that's port is connected to the VIA, it's using some VIA shenanigans or even the pullup from the VIA if it's present ?
 

tashtari

Well-known member
I realize this is a very long long shot, but does anyone have an SE board with a socket for the PIC, a PIC16F54, something that can program it, and a logic analyzer?

I modified the dumped firmware into a build for the PIC16F54 that is meant to mimic the open-collector output of the original chip, and it works well enough for the machine to boot, but not well enough for the ADB to actually work, and some observations of the bus would go a long way toward figuring out what's going on...
 

Attachments

  • macse-adb.zip
    11.4 KB · Views: 1

Skate323k137

Well-known member
I realize this is a very long long shot, but does anyone have an SE board with a socket for the PIC, a PIC16F54, something that can program it, and a logic analyzer?

I modified the dumped firmware into a build for the PIC16F54 that is meant to mimic the open-collector output of the original chip, and it works well enough for the machine to boot, but not well enough for the ADB to actually work, and some observations of the bus would go a long way toward figuring out what's going on...
I would have to see if any of my SE logic boards have that IC socketed. Exactly which chip is it on the logic board? Is it usually in a socket?

Otherwise I do have PICs, a means to write them, and a logic analyzer
 

tashtari

Well-known member
Exactly which chip is it on the logic board?
Wikipedia has a picture of it here.

Is it usually in a socket?
No, sadly, it's not, you'd have to install one yourself...

I did get someone on Discord to test it, and the code works perfectly, except, due to differences between the original PIC and the PIC16F54, it runs twice as fast as it should. D'oh. I'm currently working on porting it to the PIC16F88, a newer PIC that has the same pinout...
 

tashtari

Well-known member
The code is a mess and the comments are not to be relied upon, but here it is, a working port of the Mac SE ADB controller to the PIC16F88, and thusly a pin-compatible drop-in replacement. I'm going to try and clean it up, finish trying to understand what the original code was doing and comment as such, but here it is in its current state in case anyone wants to have a look and/or try.
 

Attachments

  • macseadb88-withsource.zip
    7 KB · Views: 5
Top