• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Mac SE ADB Controller

Scott Squires

Well-known member
This is the firmware extracted from the ADB controller chip (342S0440-B) from a Mac SE. The chip is a PIC16CR54. It was delayered by Johan Grip, stained and imaged by John McMaster, and the firmware extracted from the die images by Olivier Galibert.

It should be possible to put this firmware onto a currently-available PIC16F54. There might have been errors during transcription. But based on preliminary examination of the code, it looks very very promising.
 

Attachments

  • 342s0440-b.zip
    4.7 KB · Views: 60
Last edited:

max1zzz

Well-known member
Is this the same code that was pposted on Kai's thread a month or so ago? If it is unfortunately I couldn't get it to work so it appears there may be some transcription errors. However I have very little experiance with PIC microcontrollers so it is entirely possible I messed up programming the micro in some way
 

Skate323k137

Well-known member
I don't have any of those PIC on hand to test. I just ordered some.

PICs are definitely trickier than EPROMs, given the different settings available and the nature of the code and function. I have seen the exact same code work with some eprom programmers and not others, so never give up with PICs easily.

I don't feel like cracking open my working SE to test it but if someone in the US wants to test it I'll program one and send it along for science.
 
Last edited:

tevruden

Member
I did try this with a PIC16F54 and a TL866II and it didn't get past the gray screen before the mouse pointer, but that might fully be a process error on my part flashing it.
 

Skate323k137

Well-known member
I did try this with a PIC16F54 and a TL866II and it didn't get past the gray screen before the mouse pointer, but that might fully be a process error on my part flashing it.
Do you want to share your settings? I got in a pile of blanks, and I wouldn't mind programming a few for people / yourself to test. PICs are finnicky beasts to program sometimes :/
 

Skate323k137

Well-known member
I have a TOP2049 and TOP3000 on hand, both of which I've had good luck programming various PICs on (and EPROMs, and GALs)

Not the fastest programmers in the world but the device support is pretty decent for the cost. Someday I'll buy an industrial programmer, just can't justify it when the TOP's do everything I need at the moment.
 

tevruden

Member
Do you want to share your settings? I got in a pile of blanks, and I wouldn't mind programming a few for people / yourself to test. PICs are finnicky beasts to program sometimes :/
It was the straight defaults in XGecu. I can def test that but first, I have a few more spares so I can try with a different programmer over the weekend while I have the test SE board out to add a socket to the CPU.
 

Skate323k137

Well-known member
Sounds good.

It's unfortunate there are so many config settings on PICs. I program them for arcade stuff and I swear the exact same files/configs that work for some people don't work for others. At least they're reprogrammable so you can try a few configs over each chip and not be out anything.
 

tevruden

Member
Sounds good.

It's unfortunate there are so many config settings on PICs. I program them for arcade stuff and I swear the exact same files/configs that work for some people don't work for others. At least they're reprogrammable so you can try a few configs over each chip and not be out anything.
Update:

I did realize that I needed to enable at least CLOCKIN on the PIC16F54 but that didn't seem to improve the situation. The EEPROM seems to read/write fine but hooking up a logic analyzer the chip doesn't actually seem to do anything after power on compared to the standard ADB chip. I tried going through and programming it with a PICkit 3, but that had the same amount of success, complicated by the programmer wanting a .hex file and the files in the zip being a straight dump of the firmware. After that I started looking at the binary blob in Ghidra trying to get it to decompile properly.

I can definitely try someone else's 16F54 to finally rule out programming issues.
 

Scott Squires

Well-known member
The disassembly is included in the zip. Trying to troubleshoot based on Ghidra decompiled C is probably not going to be very helpful, in my experience.

Did you produce an appropriate hex file? I was messing around with that, I could check my notes.
 

tevruden

Member
I'm aware, however, I'm not really familiar with PIC assembly so looking at this:

0c5: 665 btfsc PORTA, RA3 ; reg: 0x005, bit: 3
0c6: b15 goto function_049
0c7: 665 btfsc PORTA, RA3 ; reg: 0x005, bit: 3
0c8: b13 goto function_048

I didn't realize that, btfsc PORTA, RA3 was a shortcut to "test pin RA3, skip if clear" thus the disassembly in ghidra. The de-compilation is a nice to have but there's other things I wanted like the control flow graph.

I ended up producing the attached hex file in the most bass-ackwards of ways: using the TL866 to flash the code to the PIC then reading it back out with the PICkit. If anyone sees any issues I can change and re-flash.
 

Attachments

  • 342s0440-b.hex.zip
    1.5 KB · Views: 8
Last edited:

max1zzz

Well-known member
I can definitely try someone else's 16F54 to finally rule out programming issues.
FWIW I spent some time trying with this firmware dump last year and got nowhere with it (Programming with both my TL866 and with my PICKIT 3)

I did find that the TL866 sets the flags incorrectly on the PIC (The checkboxes in the GUI are labelled incorrectly, I can't remember exactly which ones are mislabled so you'll have to check them by reading them back with the PICKIT)
 

tashtari

PIC Whisperer
Was talking with @Scott Squires about this yesterday evening and looked into it a bit. I think the biggest reason nobody's seeing any activity when they program a PIC16F54 with this firmware is that it doesn't ever set the TRIS (data direction) register - the I/O pins are always in a high-impedance state. Apple must have struck some kind of custom deal with Microchip that the TRIS register would be pre-programmed, though no version of the chip for which I've been able to find a spec sheet offers this as a feature. Weird. It might be possible to modify the firmware so the TRIS register is set on startup, but this would take some creativity because the firmware appears to use all 512 words of the PIC16F54's memory; I don't see anything in the disassembly that looks like junk.

Other observations:
  • The firmware does not make use of the PIC16F54's built-in timer and only uses the instruction clock for timing. It also does not use the watchdog timer, and hence doesn't make use of the OPTION register at all.
  • According to the bomarc schematic, the bus pin of the SE's two ADB ports is connected both to pin 2 and pin 3. Pin 3 is the clock input to the built-in timer that the firmware doesn't use. Weird.
  • Pin 2 (RA3, the pin sensing the ADB bus line) is always set the opposite of pin 1 (RA2, the pin which, when high [I think] drives the ADB bus low), even though pin 2 is an input and what it's set to shouldn't matter. Weird.
  • On the basis of the unrolled loop that reads the command response from a device (function_029 through function_049), the external clock (pin 16; pin 9 from the GLU) I'm guessing at somewhere around 2.5 MHz. It's hard to say exactly, it looks like the code is meant to accept a lot of variance in the device's timing.
  • Assuming I'm right about the external clock speed, the oscillator selection should be the "XT" oscillator and the configuration word should be 0b000000001001 (code protection off, watchdog timer off, XT oscillator mode).
  • The firmware reads pins 6 and 7 (RB0 and RB1) in function_071 even though these don't appear to be connected to anything on the bomarc schematic. Weird.
  • The firmware uses the uppermost eight bytes of its teensy twenty-five-byte SRAM as a data buffer (ADB frames contain a maximum of eight bytes).
  • Based on usage, I'm reasonably sure that pins 8, 9, and 10 (RB2, RB3, and RB4; CB1, CB2, and PB3 from the VIA according to the bomarc schematic) are outputs from the PIC, and that pins 17 and 18 (RA0 and RA1; PB4 and PB5 from the VIA according to the bomarc schematic) are inputs to the PIC.
I hope someone finds this useful. If anyone has anything else by way of burning questions, let me know - I have a halfway-decent eye for PIC assembly and can at least try to figure it out.
 

Scott Squires

Well-known member
Thanks for looking into this, @tashtari , and writing up a very helpful summary! Apple must have made some optimizations to get the the firmware down to exactly 512 words... Maybe we can come up with one more optimization to make room for TRIS register initialization. Not my idea of fun though. Alternatively, using a different chip with more program space on an adapter board. Perhaps we can make it work for the SE/30 too.
 
Top