• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Photo Request : 5500, 6500 and TAM Logic Board

Phipli

68040
Hey folks, pretty please I'm interested to see the differences in what resistors are fitted on the 5500, 6500 and TAM. Could you take a photo of the following resistors and let me know what computer the board is from? Especially interested in the TAM.

Resistors of interest :

R165
R272
R273
R224

They're likely to be all next to each other.
 
They’re on the underside!? Here’s a picture of the underside of a 6500: it seems to me that R273 is near the bottom right corner of the square TI chip. (couldn’t find the other ones)
 
Im curious, why are you interested in those particular resistors?
They set part of the machine ID. The boards are identical, but in part, these tell it what computer it is.

I wanted to see how they were different between the three machines, or if they were the same.

If all three were different, it would be easy to trick a 6500 or 5500 into making the TAM unique startup sound.

Discussion elsewhere means it is likely that the difference uses another method, plus nobody has provided info on the 5500 or TAM :(
 
Ooh, that’s interesting! It’s even interesting the other way around: if we could document the differences between a 5500/6500 logic board and a TAM one, it would allow to replace it more easily in case of failure or even make a 300MHz TAM!

I will have a 5500 LB in a few days, found one cheap. I sure will take all the necessary pictures!
 
if we could document the differences between a 5500/6500 logic board and a TAM one, it would allow to replace it more easily in case of failure or even make a 300MHz TAM!
That's all pretty easy - you just remove the extra ports and fit a 6500 or 5500 board in a TAM. The only downside is unless we work out how they know they're different, it makes the wrong boot chime and reports itself as another computer. It would just work though. They're basically the same computer, just a different case and screen... And some missing ports.
 
Good to know that the differences are minimal. One day I’ll tear down my TAM just to see by myself how they Frankensteined the whole thing!
 
Found them on my 5500's logic board. Luckily the components seem to be numbered fairly logically. They're all populated on the 5500. Large pictures attached...
  • R165 is on the top between the edge connector and J16
  • R224 is on the bottom near U16, Phipli's small red circle
  • R272 and R273 are right next to each other on the bottom near U27, Phipli's larger red circle
  • They are all 4.7k
 

Attachments

  • IMG_2526.jpg
    IMG_2526.jpg
    2.4 MB · Views: 34
  • IMG_2527.jpg
    IMG_2527.jpg
    2.6 MB · Views: 30
  • IMG_2528.jpg
    IMG_2528.jpg
    2.6 MB · Views: 31
They set part of the machine ID. The boards are identical, but in part, these tell it what computer it is.

I wanted to see how they were different between the three machines, or if they were the same.

If all three were different, it would be easy to trick a 6500 or 5500 into making the TAM unique startup sound.

Discussion elsewhere means it is likely that the difference uses another method, plus nobody has provided info on the 5500 or TAM :(
Is there a way to dump the ROM of these machines? Maybe their ROMs are different?
 
Almost every Power Macintosh model uses its own ROM. Some parts of it contains common stuff. But the HW specific part varies from machine to machine. That's true for built-in drivers as well.

the 5500/6500/TAM are all based on the same gazelle motherboard, so they really do use the same ROM's in this case :)

They set part of the machine ID. The boards are identical, but in part, these tell it what computer it is.

I wanted to see how they were different between the three machines, or if they were the same.

If all three were different, it would be easy to trick a 6500 or 5500 into making the TAM unique startup sound.

Discussion elsewhere means it is likely that the difference uses another method, plus nobody has provided info on the 5500 or TAM :(

I swear there is another thread on here about making a 6500/5500 play the TAM chime and that yeah its set by some resistors, but I think by the computer chassis itself, IE you can take a 6500/300 board slide it into a TAM and it will TAM chime, put a TAM board into a 5500 and ya get a regular chime etc
 
They set part of the machine ID. The boards are identical, but in part, these tell it what computer it is.

I wanted to see how they were different between the three machines, or if they were the same.

If all three were different, it would be easy to trick a 6500 or 5500 into making the TAM unique startup sound.

Discussion elsewhere means it is likely that the difference uses another method, plus nobody has provided info on the 5500 or TAM :(
Those resistors are wired derectly to the OHare ASIC, see U5 (343S0172).
They form the so-called BoxID that can be obtained by reading OHare's CPU_ID register.
Disassembling of the logic board is not required.

The OHare CPU_ID register is located at 0xYY000034 where "YY" represents the base address of the chip assigned during machine startup.
Apple's HWInit sets OHare's base address to 0xF3000000.
Thus reading one byte at 0xF3000034 will return the BoxID set up by the above mentioned resistors.

Please keep in mind that Apple engineers used different names for well-known things causing confusions:
CPU_ID has nothing to do with the processor itself, CPU stands for logic board design in this case
BoxID usually means enclosure, for example, Gazelle or TAM

Here the disassembly of the startup bong playback routine from the Gazelle ROM:
Code:
fn_FFF03D68:
    lisori    r3, 0xF3000000    # load OHare's base address
    lisori    r4, 0x34          # offset to the IDs register
    lwbrx     r4, r4, r3        # read OHare's IDs register with endian swap
    rlwinm.   r4, r4, 0,17,17   # isolate bit 6 of the Media Bay ID subregister
    bne       l_FFF03D90        # branch if it's set
    lisori    r3, 0xFFE00010    # load base address of the Gazelle bong
    b         loc_303D98

l_FFF03D90:
    lisori    r3, 0xFFE80010    # load base address of the TAM bong

l_FFF03D98:
    lwz       r4, 0(r3)

In other words, the startup bong playback routine looks at bit 6 of the Media Bay ID register.
This bit reflects the status of the DEV_ID2 pin that is connected to SRS_PRSNT signal.
SRS_PRSNT (active low) means surround sound is present if this signal is pulled low (see R207 pulldown in the Gazelle schematic).

If SRS_PRSNT is pulled low, the ROM will play the Gazelle startup bong.
Otherwise, you'll hear the TAM bong.
 
In other words, the startup bong playback routine looks at bit 6 of the Media Bay ID register.
This bit reflects the status of the DEV_ID2 pin that is connected to SRS_PRSNT signal.
SRS_PRSNT (active low) means surround sound is present if this signal is pulled low (see R207 pulldown in the Gazelle schematic).

If SRS_PRSNT is pulled low, the ROM will play the Gazelle startup bong.
Otherwise, you'll hear the TAM bong.
Is bit 6 of media bay ID register set when the media bay is set for PCI (0x50)?
When the media bay is set for PCI, Open Firmware sets MIO_OH_FC_PCI_MB_EN and MIO_OH_FC_NOT_MB_RESET.
Open Firmware does something only for media bay IDs 0x0# (swim3), 0x1# (swim3), 0x3# (ata), 0x5# (pci).
Need someone with a real TAM to know what the register is actually set to.
The TAM boot chime works in DingusPPC emulation for pm6500 when bit 14 of MIO_OHARE_ID (the register at 0xF3000034) is set (change ~0x00004000 to ~0)

What does it mean for the media bay to be set to PCI (instead of ATA of SWIM3)?
 
Open Firmware does something only for media bay IDs 0x0# (swim3), 0x1# (swim3), 0x3# (ata), 0x5# (pci).
Where did you get this ID mapping from?

The TAM boot chime works in DingusPPC emulation for pm6500 when bit 14 of MIO_OHARE_ID (the register at 0xF3000034) is set (change ~0x00004000 to ~0)
Yes, that's right. Bit 14 corresponds to bit 6 of the Media Bay DEV_ID subregister.
The IDs register at 0xF3000034 actually contains four 8-bit registers: CPU_ID (bits 0-7), Media Bay DEV_ID (bits 8-15), MON_ID (bits 16-23) and FP_ID (bits 24-31).

What does it mean for the media bay to be set to PCI (instead of ATA of SWIM3)?
I don't know because I never saw how such a media bay is implemented in HW. AFAIK, desktop enclosures don't implement it. Only portables do.

A closer look at the Power Mac 6500 schematic reveals the following mapping for the Media Bay DEV_ID register (see sheet #7):

DEV_ID_0 --> bit 4 (bit 12) --> SCC_ENAB
DEV_ID_1 --> bit 5 (bit 13) --> /SNOOP_EN
DEV_ID_2 --> bit 6 (bit 14) --> /SRS_PRSNT

In other words, the Media Bay DEV_ID register has different meanings for desktop and portable machines.
SW, including Open Firmware, should read the CPU_ID register first to judge which HW to expect.
 
Where did you get this ID mapping from?
Open Firmware 2.0.3 has this word:
Code:
: init-media-bay
	colon_definition_function_9a5
	colon_definition_function_99f
	0c >> 0f and
	case
		0 of colon_definition_function_9a1 endof
		1 of colon_definition_function_9a1 endof
		3 of colon_definition_function_9a2 endof
		5 of colon_definition_function_9a3 endof
		colon_definition_function_9a6
	endcase
	;
If you examine the unnamed words, you can see what feature control bits of OHare they are changing.
It's easier if you compare this to Open Firmware 2.4 from Beige G3 which has names for all the words.
Code:
: init-media-bay
	enable-mb-power
	ids@
	0c >> 0f and
	case
		0 of mb-swim-enable endof
		1 of mb-swim-enable endof
		3 of mb-ata-enable  endof
		5 of mb-pci-enable  endof
		disable-mb-power
	endcase
	;
Verify that all the feature control bits are the same between each version of Open Firmware. Open Firmware 2.4 uses bit numbers:
Code:
0 constant in_use_led
1 constant -mb_pwr
2 constant pci_mb_en
3 constant ide_mb_en
4 constant floppy_en
5 constant ide_int_en
6 constant -ide0_reset
7 constant -mb_reset
8 constant iobus_en
9 constant scc_cell_en
0a constant scsi_cell_en
0b constant swim_cell_en
0c constant snd_pwr
0d constant snd_clk_en
0e constant scc_a_enable
0f constant scc_b_enable
10 constant -port_via/desktop_via
11 constant -pwm/mon_id
12 constant -hookpb/mb_cnt
13 constant -swimiii/clonefloppy
14 constant aud22run
15 constant scsi_linkmode
16 constant arb_bypass
17 constant -ide1_reset
18 constant slow_scc_pclk
19 constant reset_scc
1a constant mfdc_cell_en
1b constant use_mfdc
1c constant resvd28
1d constant resvd29
1e constant resvd30
1f constant resvd31
while Open Firmware 2.0.3 uses bit mask literals (bit 2 is 4, bit 7 is 0x80).

Yes, that's right. Bit 14 corresponds to bit 6 of the Media Bay DEV_ID subregister.
The IDs register at 0xF3000034 actually contains four 8-bit registers: CPU_ID (bits 0-7), Media Bay DEV_ID (bits 8-15), MON_ID (bits 16-23) and FP_ID (bits 24-31).


I don't know because I never saw how such a media bay is implemented in HW. AFAIK, desktop enclosures don't implement it. Only portables do.

A closer look at the Power Mac 6500 schematic reveals the following mapping for the Media Bay DEV_ID register (see sheet #7):

DEV_ID_0 --> bit 4 (bit 12) --> SCC_ENAB
DEV_ID_1 --> bit 5 (bit 13) --> /SNOOP_EN
DEV_ID_2 --> bit 6 (bit 14) --> /SRS_PRSNT

In other words, the Media Bay DEV_ID register has different meanings for desktop and portable machines.
SW, including Open Firmware, should read the CPU_ID register first to judge which HW to expect.
You're right. Only the following Macs with Open Firmware 2.0.1 actually call init-media-bay:
PowerBook 3400c
PowerBook G3 Kanga
PowerBook G3 Wallstreet
PowerBook G3 Wallstreet PDQ

These other Macs that include init-media-bay don't call it:
2.0f1 Beige G3 233
2.0.2 PM 4400 and 7220
2.0.3 PM 6500 and TAM
2.4 PM G3
2.0f1 PM G3 Desktop
2.3 Power Express 1
2.0a9 Power Express 2

I suppose then they are able to use the media bay register however they like.
 
Back
Top