• 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

fehervaria

New member
@Kai Robinson It is very amazing project! I love to see how you go through on each reversengineer's problems and do beautifull job at the end.  :beige:

Do you plan to rebuild the Macintosh SE "only" at Logic Board level, or are you planning for the Analog Board too? Or the Magical Miniscribe 8425SA harddisk, what was the original for that SEs?

 

Kai Robinson

Well-known member
@Phipli & @buserror - You're welcome to a faulty one for £10 + the postage - DM me with your addresses :)

@fehervaria - Analogue board is doable, much easier than the logic board, just need a dead one sent to me - they're single sided boards, from what i can see. I do have the SE/30 boards arriving, and the Mac Classic (which is a cost reduced SE) boards, so they're in the pipeline, but i can knock out the Analogue board over a weekend, probably, if someone has a dead one!

 

buserror

Active member
Right, I've added a bit of sponsorship to @Kai Robinson for my wall-board, if anyone else feel like helping, remember you would be hard pressed to find something you would hang on your wall for less than  £30 :)

Also, on a side topic regarding the attiny85 RTC chip, I'm the author of https://github.com/buserror/simavr  - I can simulate pretty much any AVR firmware with simulated external input before you have to flash it and put it on a board, if anyone needs a bit on support getting that working, feel free to ping me.

 

Phipli

Well-known member
Just a thought... I know Compact Macs are very popular atm, and the SE/30 is a worthwhile follow up to the best computer ever made (the SE)... but it might be good to do a IIcx or something rather than every compact Mac first. Consider that it is easier to build up a new desktop as you can use an ATX supply and an LCD screen! Also not a huge difference between the SE/30 and IIcx designs.

Note this isn't specifically a request / demand, I'm over the moon to see this project happening as I have an SE.

 
Last edited by a moderator:

Kai Robinson

Well-known member
@buserror - welcome to have a crack at the ATTiny85 RTC code, the more we can replace with off the shelf, the better! Still want to try and get the GLU logic chip and the ADB done - the ADB might be simpler....is there any way of reading out the ROM contents of the chip? It's a PIC16CR54.

 

quorten

Well-known member
@buserror Nice -- that would help sidestep one issue in testing.  Namely, I say this is only for the sake I am new to AVR/Arduino and I need to figure out what is the problem with the currently written I/O routines using Arduino-specific libraries, otherwise the correct code to program the chip with comes pretty much straight out of existing Macintosh emulators, Mnii vMac I was looking at.  I did fix a few errors in the current code... but probably I'm just going to rewrite it from scratch using emulator source code as a reference to get a clean, bug-free implementation.

 

techknight

Well-known member
Well as soon as you get onto the SE/30 project, im ready to jump in for prototyping. I have a few battery kaboominated SE/30 boards. 

 

quorten

Well-known member
Alright... I've cleaned through the existing source code for the replacement RTC and should have a feature-complete version now, with no fundamental design flaws like the previous versions had.  However, it's not tested yet, so there could be a few bugs.  Anyone interested to code review this or even try a spin with physical hardware?

The source code compiles with avr-gcc (and avr-libc) and it no longer has any dependencies on Arduino code libraries.  There are two versions you can compile, the 20-byte PRAM chip and the 256-byte XPRAM chip, 256-byte XPRAM is the default.

https://github.com/quorten/macsehw/blob/1e91a8b426ecac3230fe9b218b4f3b2720658943/firmware/rtc/MacRTC.cpp

 

buserror

Active member
Alright... I've cleaned through the existing source code for the replacement RTC and should have a feature-complete version now, with no fundamental design flaws like the previous versions had.  However, it's not tested yet, so there could be a few bugs.  Anyone interested to code review this or even try a spin with physical hardware?

The source code compiles with avr-gcc (and avr-libc) and it no longer has any dependencies on Arduino code libraries.  There are two versions you can compile, the 20-byte PRAM chip and the 256-byte XPRAM chip, 256-byte XPRAM is the default.

https://github.com/quorten/macsehw/blob/1e91a8b426ecac3230fe9b218b4f3b2720658943/firmware/rtc/MacRTC.cpp


Couple of question here: is there a pullup resistor on the board for the data line? If so, you probably should not /drive/ the pin as an output, but configure it as open drain, this is pretty much to ensure both end are not driving the pin at the same time (which would damage both drivers).

Also, for the clock pin, I notice it is also INT0 as well as PCINT2 on the AVR, so you could use an interrupt vector for that, and put the AVR to sleep in between. Rigth now the AVR runs full speed all the time to resample the clock signal. /Ideally/ you would put the CPU to sleep /all the time/ and let the clock pin interrupt wake you up, process the current clock cycle, then go right back to (deep) sleep. With that the CPU will use power just when it's driven, and for toggling the RTC pin on a separate timer handler...

 

quorten

Well-known member
Yeah, I thought about using edge interrupts for the serial clock pin, that would make the code more elegant too (and more similar to Mini vMac).  Now I'm getting around to testing this design under simulation, and I found that the clock divider wasn't actually configured as it claimed to be... TCCR0B should be 0b011, not 0b111.  However, even so when I configure it like that, looks like I have the annoying problem that the one second pulse is consistently stretched a little longer than one second.  I'm guessing this must have to do with something like interrupt processing slowing down the timer counter advance or something.

 

buserror

Active member
@Kai Robinson I couldn't find the RTC chip on the schematic. Do you think the 65C22 has internal pullups?

@quorten I noticed you enable/disable interrupt in various places in the firmware, in some place I don't think it's actually necessary to do so (when reconfiguring ports for example) -- it's possible that the 'stretching' that occurs is because the interrupt is delayed by one of these blocks. You could see if it's the case by tracing the interupt generation vs the interrupt delivery. What sim are you using?

 

quorten

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

 
Last edited by a moderator:

quorten

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

 

buserror

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

 
Top