Jump to content
Kai Robinson

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

Recommended Posts

Yea I did this very same thing with different types of hardware that utilized combinational PALs. 

 

But the tools I used were very different, I used a tool that I made that converts the bin to a specific list of inputs and output states. 

 

As well as running it through a Python script that converts it back into primary logic. 

 

ive learned that these analyzers have issues dealing with inverted states. so if you inverted the OE, I bet it would clean that mess up. 

Share this post


Link to post
Share on other sites
On 8/10/2020 at 7:02 AM, Kai Robinson said:

BTW - this is the finished board, i was so busy doing it, i forgot to post it :D

DSC_0008.JPG

It's amazing! So glad you opted high reliability machine pin sockets, they're a beautiful touch aesthetically.

Share this post


Link to post
Share on other sites

I wonder if that would be true of desoldered IC legs? They have some vertical play built into the interface and the machined sockets might take a better bite out of desoldered pins. Dunno, interesting question.

 

 

Edited by Trash80toHP_Mini
apparently I can no longer type or spell.

Share this post


Link to post
Share on other sites

A bit of a common sense check on *IPL0 on the GLU, since we also have the BBU connecting to *IPL0 via a +5V pull-up resistor, this value should only ever be high-impedance or GND, correct?  If so, that common sense can certainly take a chunk out of the complexity of the OE equations.  That just leaves FCLK.oe as the exceedingly complex OE equation to be dealt with.

Share this post


Link to post
Share on other sites

Also, I see I0 is labeled as Not Connected (NC) but it is still referenced in the  of the OE equations !FCLK.oe, !B6.oe, and !IPL0.oe equations.

 

Simplifying !B6.oe by hand looks like this.

 

!B6.oe =               !WRDATA & !ENBL1 & !PA4 & !CLK & !PA3 & !RTxCB & !OE & !RTxCA & !OutA & !IPL0 & !ENABLE_L & !ENABLE_U & !FLOPPY_WR & !FCLK
       # !PB6 & !IRQ &  WRDATA & !ENBL1 & !PA4 & !CLK & !PA3 & !RTxCB & !OE & !RTxCA & !OutA & !IPL0 & !ENABLE_L & !ENABLE_U & !FLOPPY_WR & !FCLK;

 

!OutA.oe is fairly well simplified as presented.

Share this post


Link to post
Share on other sites
On 8/11/2020 at 2:27 AM, Kai Robinson said:

Hmm - want to take a crack at the .bin i extracted? :)

 

Sure, send it my way. Let me know the number of inputs and outputs. 

Share this post


Link to post
Share on other sites

This is what the script I use does: (This isnt a Mac, but yet a different 68K computer)

 

 

module top (
    input IACK,
    input RW,
    input REROM,
    input AS,
    input A12,
    input A13,
    input A14,
    input A15,
    input A16,
    input A17,
    input A18,
    input A19,
    input A20,
    input A21,
    input A22,
    input A23,
    output ~q7,
    output ~q6,
    output ~q5,
    output ~q4,
    output ~q3,
    output ~q2,
    output ~q1,
    output ~q0
);

assign ~q7 = (RAM Select)
  (~IACK & REROM & ~AS & ~A21 & ~A22 & ~A23)
;

assign ~q6 = ($FDF000 to $FDFFFF) (Peripheral Select)
  (~IACK & REROM & ~AS & A12 & A13 & A14 & A15 & A16 & ~A17 & A18 & A19 & A20 & A21 & A22 & A23)
;

assign ~q5 = ($FD0000 to $FD3FFF) (EEPROM Select)
  (~IACK & REROM & ~AS & ~A14 & ~A15 & A16 & ~A17 & A18 & A19 & A20 & A21 & A22 & A23)
;

assign ~q4 = (External Peripherals Enabled)
  (~A21 & ~A22 & ~A23) | (RAM Space)
  (A17 & A18 & A19 & A20 & A21 & A22 & A23) | (ROM Space)
  (~A14 & ~A15 & A16 & A18 & A19 & A20 & A21 & A22 & A23) | (EEPROM Space)
  (A12 & A13 & A14 & A15 & A16 & A18 & A19 & A20 & A21 & A22 & A23) | (Peripheral Space)
  (AS) |
  (~REROM) |
  (IACK)
;

assign ~q3 = (Unused)
  (~IACK & REROM & ~AS & ~A12 & A13 & A14 & A15 & A16 & ~A17 & A18 & A19 & A20 & A21 & A22 & A23)
;

assign ~q0 = (ROM Select) ($FE0000 When Not REROM, $000000 when REROM)
  (~IACK & RW & ~AS & A17 & A18 & A19 & A20 & A21 & A22 & A23) |
  (~IACK & RW & ~REROM & ~AS & ~A17 & ~A18 & ~A19 & ~A20 & ~A21 & ~A22 & ~A23)
;

endmodule

 

Share this post


Link to post
Share on other sites

Here you go. The pin assignments are as the PALASM:

/* Dedicated input pins */

pin 1   = I0; /* NC*/
pin 2   = PB6; /* PB6 */
pin 3   = IRQ; /* IRQ */
pin 4   = WRDATA; /* WRDATA */
pin 5   = ENBL1; /* /ENBL1 */
pin 6   = PA4; /* PA4 */
pin 7   = CLK; /* CLK INPUT*/
pin 8   = PA3; /* PA3 */
pin 9   = RTxCB; /* /RTxCB */
pin 11  = OE; /* OE */

/* Programmable output pins */

pin 12  = RTxCA; /* Combinatorial output */
pin 13  = OutA; /* Fixed high output w/ output enable */
pin 14  = IPL0; /* Combinatorial output w/ output enable */
pin 15  = ENABLE_L; /* Combinatorial output */
pin 16  = ENABLE_U; /* Combinatorial output */
pin 17  = FLOPPY_WR; /* Combinatorial output */
pin 18  = B6; /* Fixed high output w/ output enable */
pin 19  = FCLK; /* Combinatorial output w/ output enable - FCLK on BBU Pin 44 */

 

glu.bin

Share this post


Link to post
Share on other sites

I will have to double-check, but I dont know if thats actually a clean dump. if an OE pin isnt active, then wherever that bit lies in your dumper, everything should be cut off until that pin activates. But in this dump, I dont see that. 

Share this post


Link to post
Share on other sites

Hmm - OE is permanently pulled low via R12 (150Ohm) - doesn't connect to anything else. With the HAL/PAL16L8 - if OE ever goes HIGH, then everything is disabled. 

Edited by Kai Robinson

Share this post


Link to post
Share on other sites

well im gonna crunch it here and see what comes out the other end. How did you have your Input pins wired in correlation to how you dumped the PAL bin?

Edited by techknight

Share this post


Link to post
Share on other sites

Looks like the python script I use is now crashing ( I havent used it since Win 7 and now on Win 10) and I cant get it to run. 

 

Anyways, I simplified the BIN file, Can you try this new one? 

 

 

test2.bin

Share this post


Link to post
Share on other sites

Yea I trimmed out all the nonsense, kept only the 10-input valid logic states. Since none of your outputs are actualy inputs as far as I can tell, I decided to eliminate those from the BIN. 

 

Here is what I use for deciphering PALs:

https://github.com/psurply/ReGAL

 

Also, Here is the truth file I built from your Bin: 

test2_truth.csv

Edited by techknight

Share this post


Link to post
Share on other sites

Ohh, ok.... whoops :)

 

if I could get a list of known inputs from the I/O side, I can route the properly to the truith output for the python script to work. 

Edited by techknight

Share this post


Link to post
Share on other sites

The pins are connected as such: 

1 i0 to NC
2 i1 to pb6 on 6523
3 i2 to irq on 53c80
4 i3 to wrdata on IWM/SWIM
5 i4 to /enbl1 on IWM/SWIM
6 i5 to pa4 on 6523
7 i6 to 16M output from osc
8 i7 to pa3 on 6523
9 i8 to /RTxCB on 85C30 & BBU pin 40
10 GND
11 i9 to /OE (Pulled LOW through R12)
12 o0 to /RTxCA on 85C30
13 o1 to Output A on 26LS32 - U4C
14 o2 to /IPL0 on BBU
15 o3 to /ENABLE on Lower Drive via filter
16 o4 to /ENABLE on Upper Drive via filter
17 o5 to FLOPPY_WR on all drives
18 o6 to NC
19 o7 to fclk on IWM/SWIM & BBU pin 44
20 VCC

Share this post


Link to post
Share on other sites

Also - upon further signal inspection the 338-6523 is NOT likely to be a 6523 TPI as originally thought - the pins match up to the 6522 config instead, some obfuscation on Apple's part but would make the most sense since the 6522 is used in everything else, and there's nothing being used on what should be Port C, IRQ is connected to the other IRQ pins, R/W connected to R/W etc. I'd love to be able to edit my original post. At least that means one less custom chip to use - you can indeed use a brand new WDC 65C22N instead. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×