Reverse Engineering the Macintosh SE PCB & Custom Chips for 1:1 reproduction

[quorten]

@buserror I'm using your simavr simulator.  I'm observing the one-second pin clock stretching behavior even when I edit out all the other serial communication logic.  But good call out that I can remove the interrupt disables for port reconfiguration.

 

For now you'll have to look at schematics of other machines to see the RTC in-circuit since the pages are missing from the Macintosh SE main logic board schematic, there are the Bomarc schematics of similar machines and also the redrawn Macintosh SE/30 schematics.

Edited September 5 by quorten
Schematics

[Kai Robinson]

The Mac plus might perhaps be most useful?

[quorten]

The Mac Plus schematic does have pull-up resistors on the RTC chip enable, serial clock, and serial data lines.

[buserror]

8 hours ago, quorten said:

@buserror I'm using your simavr simulator.  I'm observing the one-second pin clock stretching behavior even when I edit out all the other serial communication logic.  But good call out that I can remove the interrupt disables for port reconfiguration.

 

For now you'll have to look at schematics of other machines to see the RTC in-circuit since the pages are missing from the Macintosh SE main logic board schematic, there are the Bomarc schematics of similar machines and also the redrawn Macintosh SE/30 schematics.

Cool, with simavr you can trace the exact time the interrupt is /raised/, so you can see what the delta raise vs pin toggle occurs.

Altho, in your interrupt handler for the pin toggle, perhaps you shoudl re-enable the interrupt JUST after the toggle (in fact, you can do it on the /previous/ line as the reenabling takes 2 cycles), the rest of the expression (checking the pin value) can be done with interrupt enabled in the handler, it's not critical. -- since it's 32 bits operation it takes quite a few cycles on the AVR.

[Kai Robinson]

From the documentation: 

Quote

65C22N is a pin compatible replacement of NMOS 6522 devices with current limiting resistors on output ports. Input buffers supply 200uA pull-up current at 2.4V in the input mode.

 

[quorten]

Okay, that's really good stuff to know from reviewing the electrical configuration in the RTC communications circuit.  Now I've removed the pull-ups from the inputs because they are unnecessary, and I've changed the bi-directional data line to use open-drain signaling.  The 1-second pin still doesn't use open-drain signaling, but should it?

 

Updated source code, the link is again pinned to a particular commit:

 

https://github.com/quorten/macsehw/blob/e2483ddd596f49565c5126f33bd8b571d4a9e98a/firmware/rtc/MacRTC.c

Edited September 5 by quorten
Fix minor typos

[quorten]

Okay... Macintosh emulators are weird.  Mini vMac emulates the RTC serial communications by updating on the rising edge of the serial clock, MAME (formerly MESS) emulates by updating on the falling edge of the serial clock.  But they both work okay.  Reading through this carefully, I've made one change to how I handle serial communications of the last bit: instead of holding the output 0.5 cycles I now hold the output 1.5 cycles.  Apparently, if you use falling edge instead of rising edge, then holding output for 1.0 cycle works just fine too.

 

One thing though that makes all of this easier is if the ROM always disables the chip before starting communications of the next command.  And, of course, the fact that we have open-drain signaling that makes bi-directional confusion more forgiving.

 

Probably the way to get the point of truth answer for a 1:1 reproduction would be to observe the RTC under an oscilloscope.

Edited September 5 by quorten
Correction, oscilloscope on RTC

[quorten]

On 9/3/2020 at 7:34 AM, Kai Robinson said:

the ADB might be simpler....is there any way of reading out the ROM contents of the chip? It's a PIC16CR54.

Since you asked... here's my answer.  Fortunately, you can read the ID words of the PIC16CR64, and I believe that should be just enough information to tell you if you can dump the code contents or if code protect is enabled.  If code protect is enabled, you might either get back all zeros on read or read will fail completely.  The lowdown is in the programming specification, which I've found here.

 

http://ww1.microchip.com/downloads/en/DeviceDoc/30190h.pdf

 

I'm guessing this is a mask ROM device, so if you can't read the memory by conventional methods, another option would be to crack open the chip packaging and photograph the silicon with a microscope or DSLR macro photography... it's only 512 words max memory.

[Kai Robinson]

The one problem i have is that i can't read the contents, either with a pickit or my tl866 II eprom programmer. 

 

I did find this, but not sure if the code listing would be applicable to the 'controller' : http://ww1.microchip.com/downloads/en/AppNotes/00591b.pdf

[robbo007]

Hi guys,

I've got an original board and my CR1 diode has blown and I need to replace it. I see on the list of parts its this:

CR1	1N4150

 

Whats the Voltage I need? Would these do? I'm located in Spain. Can seem to find a good place to buy them from other than amazon.es.

 

https://www.amazon.es/DIOTEC-SEMICONDUCTOR-Conmutador-1-N4150-50-piezas/dp/B07D63BSCH/ref=sr_1_1?__mk_es_ES=ÅMÅŽÕÑ&dchild=1&keywords=Diode+1N4150&qid=1599314246&sr=8-1

 

Cheers,

 

 

[BadGoldEagle]

@robbo007 Anything above 12V will be fine. 

[Kai Robinson]

More documentation found for the ADB: https://developer.apple.com/library/archive/technotes/hw/hw_01.html

[buserror]

Thanks @Kai Robinson, received my wall art

[Kai Robinson]

@buserror Show us what you do with it

I have 4 more pieces of 'wall art' (failed blue pcb run), left. The new rev 1.4c boards are due in shortly, whih hopefully WONT be wall art

[quorten]

Alright... I've tested my RTC firmware under simavr simulation with a nice interactive test bench setup that can also quickly be turned into an automated test suite, and I've fixed two small bugs.  Now the firmware properly supports the entire PRAM register access protocol and can be used as such, except...

 

Clock problems, yes.  Though I programmed a minor workaround for the second slipping issue, the bigger issue is that running the AVR at 32.768 kHz is not fast enough for a decent serial data clock speed: 50 Hz serial data clock is much too slow.  About 100 cycles are required to process one serial data clock edge.  By contrast, with 8 MHz AVR core speed, we could probably support up to an 20 kHz serial data clock.  Exactly how fast of a serial clock do we need to support?

 

In any case, looks like we need to entirely retool how we handle the 32.768 kHz clock input, but hopefully that will make processing the 1-second interrupt much more accurate.

 

Again, here's a link to my work in progress, pinned to the commit as of today.

 

https://github.com/quorten/macsehw/tree/2bce9ed244a39e49b951e4fb567a308bd5037b1d/firmware/rtc

Edited September 10 by quorten
Clock speeds

[buserror]

@quorten well done. One thing you can so is run the AVR from the built in oscillator (8Mhz down to 256khz if I remember), much, MUCH quicker than 32k -- you can still use the 32k crystal as timing reference for one of the timer so it stays accurate, but will have a lot more cycles to do the rest.

[quorten]

So, the first question.  Who wants to try out a replacement RTC that's pretty much ready to go?

 

https://github.com/quorten/macsehw/tree/385867165613ad08207191b636d70cf82b467505/firmware/rtc

 

Now, for the tech discussion.  Unfortunately, I found out that the ATTiny85 does not have the hardware capabilities to use the 32k crystal as a timing reference while the core clock runs at 8 MHz.  The only option to connect directly to a crystal and capacitor buffer circuit is via direct drive of the system clock.  The 20-pin SOIC/TSSOP ATTiny87 does, however, have the necessary hardware features, but that would require an adapter circuit board.

 

In any case, given the hardware limitations of the ATTiny85, I believe I now developed a pretty solid firmware for it.  The AVR clock is run at 8 MHz and a timer based off of the internally generated clock generates the 1-second interrupt signal.  The crystal connection is not used at all, so the pins are set to pull-up inputs.  This does mean that time drift will be a much bigger problem than usual.

 

Also, after thinking through things more from writing my automated test suite, I decided that triggering serial communication events on the falling edge may be more defensive programming than triggering on the rising edge... given the fact that I've seen mention that the ROM erroneously reads the output data just after the rising edge of the clock rather than just before like it is stated to in the Hardware Reference.

 

The automated test suite itself needs more work on how it handles timing with simavr... due to timing issues it can have intermittent failures when simulating at higher clock speeds.  Another thing is that I'm almost done extending it so that it can also be used in physical hardware test, via Raspberry Pi.  (Actually sysfs GPIO could be used to support any Linux board, though I personally don't like sysfs GPIO.)

Edited September 13 by quorten
Punctuation/grammar

[Kai Robinson]

By all means feel free to use the ATTiny87 - i'd recommend prototype with a through hole, but if it works, i'd knock up an adapter for the TSSOP-20 package that can fit in the confined space. 

[techknight]

Anyways...... 

 

has the new boards come in yet? Sitting at the edge of my seat for weeks so far is killing me! 

 

haha. 

Edited September 14 by techknight

[Phipli]

Can you make it that if the computer sets the date to before 1980, the AVR adds 100 years to the date? That would solve the date and time 2 digit year issue.

 

Also is the new chip going to be 2040 proof? Cool if I could drop one in and the date kept working past 2040... or is that an OS issue rather that the clock chip?

Edited September 14 by Phipli

[Kai Robinson]

DHL are due to deliver the new batch tomorrow - assuming customs charges aren't due...

[quorten]

@Phipli The 2-digit year issue is an OS issue, the RTC only keeps track of time in seconds.  Also, I'd say being 2040-proof is mostly an OS issue too, the OS needs to make a decision where in the extended PRAM memory to store the high-order time bytes.  The OS can also update those manually as long as the computer is powered on once every 136 years.

 

Testing out an ATMega328P with a 32.768kHz crystal-controlled asynchronous timer is probably going to be next up.  The setup is, after all, generally useful for another AVR project I was planning on doing.

Edited September 14 by quorten
Note for 32.768kHz crystal

[quorten]

A note you can add to the BOM for the PCB.  Crystal Y1 should have a load capacitance of 12.5pF.  This is tne most common kind of 32.768kHz crystal but maybe it's worth stating explicitly since the matching of the corresponding capacitors depends on this.

[techknight]

17 hours ago, Kai Robinson said:

DHL are due to deliver the new batch tomorrow - assuming customs charges aren't due...

 

Ah nice. Hopefully it turns out perfect this time around.

[Kai Robinson]

Well, they're here.... GND tests show... THE EXCLUSION WORKS!!!  The rear I/O should now be good to go, it's not shorted anymore, and the rear ADB and serial ports are grounded correctly now.