• 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.

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

Kai Robinson

Well-known member
From the documentation: 

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

Well-known member
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

 
Last edited by a moderator:

quorten

Well-known member
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.

 
Last edited by a moderator:

quorten

Well-known member
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.

 

robbo007

New member
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,

 

Kai Robinson

Well-known member
@buserror Show us what you do with it :D

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 :D

 

quorten

Well-known member
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

 
Last edited by a moderator:

buserror

Active member
@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

Well-known member
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.)

 
Last edited by a moderator:

Kai Robinson

Well-known member
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

Well-known member
Anyways...... 

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

haha. 

 
Last edited by a moderator:

Phipli

Well-known member
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?

 
Last edited by a moderator:

quorten

Well-known member
@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.

 
Last edited by a moderator:

quorten

Well-known member
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.

 
Top