Jump to content

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


Recommended Posts

@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 by quorten
Schematics
Link to post
Share on other sites
  • Replies 444
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to post
Share on other sites

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 by quorten
Fix minor typos
Link to post
Share on other sites

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 by quorten
Correction, oscilloscope on RTC
Link to post
Share on other sites
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.

Link to post
Share on other sites

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,

 

 

Link to post
Share on other sites

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 by quorten
Clock speeds
Link to post
Share on other sites

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

Link to post
Share on other sites

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 by quorten
Punctuation/grammar
Link to post
Share on other sites

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 by Phipli
Link to post
Share on other sites

@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 by quorten
Note for 32.768kHz crystal
Link to post
Share on other sites

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...