PowerBook 1400 series ROM and RAM tidbits

Trash80toHP_Mini

NIGHT STALKER
If both your cards are 24MB your donor board appears to be exhibiting an improved reaction the behavior of the 133MHz version mentioned in the everymac advisory in your IP. This now leads me to the 166' Developer Note.
1400-Block_Diagram.jpg
Can you determine and compare the production dates of the logic boards and the PBX Bus Bridge/Memory Controllers on your two boards?

WAGs: the donor is an early production unit a/o PBX (underside of board directly beneath the CPU card connectors.) is an earlier version?

Wondering if Apple fixed the 133's boot memory failure for the most part, but didn't quite fix the memory system issue of the 133 entirely on early production boards? Apple did a lot of "quiet replacements/upgrades" of failed systems (PB100 in my case) when they came in for service.

Comparatively few of the early 166 units would have immediately been upgraded past stock memory. Those that were likely had memory cards transferred from 133MHz units. Memory was very expensive in the backwhen, so full loadouts with a pair of 24MB cards were likely very rare.

Dunno, take a look.;)


edit: I'll bet a shiny nickel that the donor board works just fine with a 32MB/16MB combo?
 
Last edited:

Snial

Well-known member
This is a good idea but I don’t know how to…
I guess if you boot the PB1400 into a fairly minimal System 7.5.3 with VM off, then there's room for the OS and a reasonable application in the 8MB of soldered RAM. If I remember correctly, (though I do have the newer IM:Memory book); the system heap will be in low memory and then apps are allotted from the top of memory down. I wonder if it's possible to write a small extension which resets RAM to just 8MB, then run the memory test app (to be written). Except, I think you may be saying it won't boot anyway in that configuration because of the memory 'fault'?

8MB factory works by itself => 16MB
0 MB Factory + 2x 24MB User RAM works => 56MB.
8 MB Factory + 1x 24MB User RAM works => 40MB.
8 MB Factory + 2x 24MB User RAM fails, memory error.

However, having re-read about the PB1400 memory controller I don't think it's that simple at all, physical RAM slots can be allocated anywhere. The PB 1400 has the PBX Memory controller. OK, this is my hypothesis: it's a bug in the early ROM, fixed later (or vice-versa):

1716047067019.png
...
1716047114005.png
1716047147784.png

So, there's a RRAS for each expansion card + Mobo + Factory. Then the 32 x nybble PBX registers are populated so that each 2MB region points to the right card, but within a card, memory must be contiguous.

For example, you can't interleave Mobo at (0, 4, 8, 12} and Factory RAM at (2, 6, 12, 14}, because e.g. addresses at 2MB would clash between Mobo RAM and Factory RAM. The base addresses and offsets aren't added, they're or'd.

This means that the 8MB Mobo + 8MB Factory + 2 x 24MB would have to be organised as:

0MB = 1st 24MB RAM
24MB = 8MB Mobo. ;No User RAM card above 24MB doesn't access anything, so Mobo RAM can go there.
32MB = 2nd 24MB RAM.
56MB = 8MB Factory. ;Ditto, for Factory RAM

This gives 64MB {U1,M,U2,F}. Let's say there's a bug with the earlier ROM which makes it less flexible in that it can't handle that combination and instead tries to do something like {U1,M, F, U2}. U2 can't be placed at 40MB - its first 8MB works, but the second 8MB would probably clash with itself.

8MB is {M}
12MB is {M,F}
16MB is {M,F} or if it's 4MB F and 4MB U1: {M, F, U1}, that's OK.
20MB is {M, F, U1}, or if it's 4MB F and 8MB U1: {M, U1, F}, or {U1, M, F}.
24MB {M, F[4], U1[4], U2[4]}, or {M, F[8], U1[4]} or {M, U1[8], F[4]}.
32MB {M[8], F[4], U1[4], U2[16]}, or {M, F[8], U1[16]}
Note, is 36MB an option? It would be {M[8], F[8], U1[16], U2[4]}.
40MB {M[8], F[8], U1[24]}
56MB {U1[24], M[8], U2[24]}

Yes, so if F[8] or F[4] had to be the second RAM bank if it was installed (or a slightly more flexible sequence), I think you can have pretty much any RAM organisation up to 56MB. 16MB modules align quite nicely anywhere {U1[16], M[8], F[4]} = 16+12 = 28MB, is that possible? So, if the earlier ROM couldn't do {U1, M, U2, F} then it can't manage 64MB nor 60MB, but it can do 56MB.

Anyway, just a hypothesis.

-cheers from Julz
 

Trash80toHP_Mini

NIGHT STALKER
HRMMM? Sill thinking a 32MB/16MB combo will work with the early ROM?

Production dates?
_Hardware:
_Logic Board
- PBX
Firmware:
- - ROM
 

croissantking

Well-known member
If both your cards are 24MB your donor board appears to be exhibiting an improved reaction the behavior of the 133MHz version mentioned in the everymac advisory in your IP. This now leads me to the 166' Developer Note.
View attachment 73776
Can you determine and compare the production dates of the logic boards and the PBX Bus Bridge/Memory Controllers on your two boards?

WAGs: the donor is an early production unit a/o PBX (underside of board directly beneath the CPU card connectors.) is an earlier version?

Wondering if Apple fixed the 133's boot memory failure for the most part, but didn't quite fix the memory system issue of the 133 entirely on early production boards? Apple did a lot of "quiet replacements/upgrades" of failed systems (PB100 in my case) when they came in for service.

Comparatively few of the early 166 units would have immediately been upgraded past stock memory. Those that were likely had memory cards transferred from 133MHz units. Memory was very expensive in the backwhen, so full loadouts with a pair of 24MB cards were likely very rare.

Dunno, take a look.;)


edit: I'll bet a shiny nickel that the donor board works just fine with a 32MB/16MB combo?

Is the PBX the large chip with a foam pad glued to it?

Interestingly, on my board which accepts 64MB RAM, this has been reworked/replaced - very crudely.
 

Attachments

  • IMG_7279.jpeg
    IMG_7279.jpeg
    2.2 MB · Views: 20

Snial

Well-known member
Is the PBX the large chip with a foam pad glued to it?

Interestingly, on my board which accepts 64MB RAM, this has been reworked/replaced - very crudely.
So, not a Firmware issue? I can't see where the rework is, do you mean the large chip's legs look like they've been hand-soldered? OK, I can see the issue, lots of legs are slightly offset :-O !
 

Trash80toHP_Mini

NIGHT STALKER
That's very likely a factory reworked board sent out as a replacement service part or in a MUG refurb machine sale setup. I got a couple of refurb machines that way. ISTR that's how I got my 2300c a/o my P6360.

You said you swapped your ROMs between boards? Mine are soldered topside, labeled High/Low. Are your boards socketed?
Pics? Gotta see THAT! 😬

Could very well have been TREX ASIC revision and Firmware fixes done simultaneously. At this point my money is on something missed in development between the two groups that wasn't caught in pre-production testing.
 
Last edited:

croissantking

Well-known member
You said you swapped your ROMs between boards? Mine are soldered topside, labeled High/Low. Are your boards socketed?
Pics? Gotta see THAT! 😬
Lol no, they’re not socketed. My boards will be the same as yours, I had to desolder with hot air etc. Initially I planned to use the 166 board, but then the RAM issue came up. It’s sounding to me from this discussion that it’s a production bug rather than a faulty logic board.
 

croissantking

Well-known member
Can you determine and compare the production dates of the logic boards and the PBX Bus Bridge/Memory Controllers on your two boards?

WAGs: the donor is an early production unit a/o PBX (underside of board directly beneath the CPU card connectors.) is an earlier version?
Looking at the date codes of the various chips it looks the like 166 board (the one you call the ‘donor’, right?) is quite a lot newer than the ‘good’ (originally 117) board. So this rules out the idea that there was a bug that was fixed later on. Unless… the reworked PBX chip on the 117 board is relevant here. I should look at date codes, but am a bit reluctant to dissemble my PB1400 again and to peel off the foam pad which I guess is needed for thermal purposes.
 

Trash80toHP_Mini

NIGHT STALKER
Looking at the date codes of the various chips it looks the like 166 board (the one you call the ‘donor’, right?) is quite a lot newer than the ‘good’ (originally 117) board.
You never said you were working with two different model boards? Now I'm confused:
- dates are right, the 117 was discontinued the day the 166MHz was released
- you're saying you have a 166MHz processor card that works on a 117MHz board? That's not supposed to work at all.
- you're saying you got a 117MHz board to address 64MB? That's not supposed to be possible.
 

croissantking

Well-known member
You never said you were working with two different model boards? Now I'm confused:
- dates are right, the 117 was discontinued the day the 166MHz was released
- you're saying you have a 166MHz processor card that works on a 117MHz board? That's not supposed to work at all.
I thought I explained this in my original post, sorry it wasn't clear!

Let me recap:

- I started with a PowerBook 1400c/117 which I upgraded with a 166MHz CPU card underclocked to 133MHz (yes, you are correct, it will not work at 166MHz on a 117 board).​

- I obtained a bare 166 board with no CPU card or RAM. I intended to fit this into my PowerBook 1400c chassis, in order to be able to use my 166MHz CPU card at full speed.​

- I tested out the 166MHz board and found out about the RAM problem (limited to 56MB). So I decided to swap over the ROM chips and see what would happen.​

- With the ROMs swapped, my 117 board now boots at 166MHz. My 166 board no longer boots at 166, and the RAM problem remains. This is a good outcome as I now have a maxed out machine which was my aim.​
- I would still like to resolve the RAM issue on the spare board, however - hence this thread.​

- you're saying you got a 117MHz board to address 64MB? That's not supposed to be possible.
This is incorrect, my 117 board always worked with 64MB RAM, even before the ROM swap. All boards are in theory upgradeable to 64MB RAM. The 56MB limit/problem is undocumented but affects many boards.
 
Last edited:

greystash

Well-known member
I was mucking around with my 1400c today and came across something interesting. I installed 8MB system RAM and 2x 32MB expansion cards.
To begin with my system would crash on startup until I disabled extensions. After booting into the system it recognised that 80MB RAM was present! (8MB onboard, 8MB system, 32MB x2 expansion memory).

The unfortunate thing is that the system is very unstable and doesn't seem to be addressing the RAM correctly. It crashes often when allocating memory and will only boot with a minimal system. I've tested this on both OS7 and OS 8.6 and got the same results.

Is there any way this can be addressed so the full amount of memory can be utilised? I am using a Sonnet Encore so I'm not sure if that has anything to do with the issues described.
 

Attachments

  • 32MB-Underside.jpg
    32MB-Underside.jpg
    738.9 KB · Views: 9
  • 32MB-Topside.jpg
    32MB-Topside.jpg
    729 KB · Views: 6
  • Picture-4.jpg
    Picture-4.jpg
    94 KB · Views: 7
  • Picture-3.jpg
    Picture-3.jpg
    48.4 KB · Views: 7
  • Picture-1.jpg
    Picture-1.jpg
    44.2 KB · Views: 7

Snial

Well-known member
I was mucking around with my 1400c today and came across something interesting. I installed 8MB system RAM and 2x 32MB expansion cards.
To begin with my system would crash on startup until I disabled extensions. After booting into the system it recognised that 80MB RAM was present! (8MB onboard, 8MB system, 32MB x2 expansion memory).

The unfortunate thing is that the system is very unstable and doesn't seem to be addressing the RAM correctly. It crashes often when allocating memory and will only boot with a minimal system. I've tested this on both OS7 and OS 8.6 and got the same results.

Is there any way this can be addressed so the full amount of memory can be utilised? I am using a Sonnet Encore so I'm not sure if that has anything to do with the issues described.
I don't think it's possible, because of the PBX memory mapping chip. If we go back to the developer notes for the PB1400allVersions:

index.php

Every Macintosh from the original 128kB Mac onwards had to perform some physical to physical memory mapping. On the 128kB Mac this was needed because the 68000 CPU booted from address 0, so ROM has to be there, but normally they wanted RAM there with ROM at 4MB. So, those early Macs started by mapping the ROM to both addresses and used a single bit in the VIA chip to disable ROM mapping, while enabling the RAM mapping at 0MB. So, then the Mac could boot and the first thing the ROM would do is make it jump to 4MB and then flip the VIA bit to enable RAM at 0MB.

As Macs became more complex in the Mac II era and later when Macs had multiple SIMM memory slots, the physical to physical mapping needed to become more complex. For example, on a Mac Plus, each pair of 8-bit SIMMs is a single bank of 16-bit wide RAM, so the 4 SIMMs make up 2 banks and each bank must be physically selectable. The Mac Plus uses actual resistors to make sure that if the first bank contains 0.5MB of RAM (2x 256kB SIMMs), the second bank's addresses start at 1MB and can only be 0.5MB in size. With 2MB or above, the first bank must contain 2MB and the second bank can be 0MB, 0.5MB or 2MB.

On the PB1400 models this physical mapping hardware is a chip called PBX. It contains 16 bytes x 2 x 4-bit entries for 32 x 2MB (=> 64MB) physical RAM slot and each entry is the bank number of the RAM module. Each bank can be up to 16MB. There's bank 0 is for Motherboard RAM (8MB) bank 1 for the Factory RAM card (usually 4MB or 8MB, but I think 12MB or 16MB is theoretically possible). Then banks 2..4 and 5..7 are for the user expansion RAM expansion slots. e.g. a 64MB fully expanded PB1400 might have PBX set up as: User2 Bank0

Physical Addr0MB2MB4MB6MB8MB10MB12MB14MB
0MBMotherboardMotherboardMotherboardMotherboardFactoryFactoryFactoryFactory
16MBUser1 Bank0User1 Bank0User1 Bank0User1 Bank0User1 Bank0User1 Bank0User1 Bank0User1 Bank0
32MBUser1 Bank1User1 Bank1User1 Bank1User1 Bank1User1 Bank1User1 Bank1User1 Bank1User1 Bank1
48MBUser2 Bank0User2 Bank0User2 Bank0User2 Bank0User2 Bank0User2 Bank0User2 Bank0User2 Bank0

So, although you could therefore put 8MB + 16MB + 2 x 48MB in the PB1400 (120MB!!!) the real limitation is the 32 x 2MB RAM slots that the PBX chip can manage. Trying to do more will cause physical memory to overlap addresses, which is probably what you're seeing here.

Having said that, specialised software (perhaps a specialised Extension or System folder INIT) could be used to access up to 120MB of RAM on a PB1400, though only 48MB could ever be recognised by Mac OS (the rest would be a RAM disk). How might we do that? The answer is that we'd force the OS to recognise only the first 48MB of slots in PBX, but the specialised software would bank-switch in other banks into the last 8 slots as needed:

Physical Addr0MB2MB4MB6MB8MB10MB12MB14MB
0MBMotherboardMotherboardMotherboardMotherboardFactoryFactoryFactoryFactory
16MBUser1 Bank0User1 Bank0User1 Bank0User1 Bank0User1 Bank0User1 Bank0User1 Bank0User1 Bank0
32MBUser1 Bank1User1 Bank1User1 Bank1User1 Bank1User1 Bank1User1 Bank1User1 Bank1User1 Bank1
48MBCarda BankbCardc BankdCarde BankdCardf BankgCardh BankiCardj BankkCardl BankmCardn Banky

Where Carda to Cardn can only ever be: {Factory, User1, User2} and Bankb to Banky can only ever be {Bank1 to Bank3}. It's a bit pointless though IMHO.
 
Top