Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[LarsG5]

Haven't been active here for more that 4 years, so I thought I'd ask whether some progress regarding getting Cardbus to work under OS 9 has been made? I've seen a post regarding USB 2.0 potentially working, so yeah, I truly hope Cardbus working is just a matter of time

[UnexpectedBomb]

Haven't been active here for more that 4 years, so I thought I'd ask whether some progress regarding getting Cardbus to work under OS 9 has been made? I've seen a post regarding USB 2.0 potentially working, so yeah, I truly hope Cardbus working is just a matter of time

Hello! I was working on this exact thing until the backlight on my 667 DVI TiBook's display died    So I ended up pivoting to some other projects.

I bought a replacement inverter board in the hopes that it will fix the issue. If so, I will resume this effort soon. Given that the EHCI stack has already been built, the CardBus piece of the equation would hopefully be relatively trivial to solve. Stay tuned.

[LarsG5]

Hello! I was working on this exact thing until the backlight on my 667 DVI TiBook's display died    So I ended up pivoting to some other projects.

I bought a replacement inverter board in the hopes that it will fix the issue. If so, I will resume this effort soon. Given that the EHCI stack has already been built, the CardBus piece of the equation would hopefully be relatively trivial to solve. Stay tuned.

BRUH, i won't be able to sleep tonight out of excitement, fingers crossed!

[vectrex]

A vote from me as well for the cardbus!

My Firewire doesnt work at all, installed using the unsupported image install, which worked well in target disk install from a TiBook.

USB works great on all slots.

''unsupported usb device, click ok" prompt shows at every boot, unaware of how or what to use to silence that.

Also would share that these machines have major heat issues which can cause the lower ram slot and the ram itself to become defective. Spent several days diagnosing what i thought was an L2/L3 cache freezing. in both os 9 and OS X, but it turns out it was the lower ram slot all along (the one closest to battery). pitch the bad ram *whizzzzzzz*.  I havent tested to see if the lower ram slot is permanently knackered.

Dropping the processor speed (which affects cache too) in the energy savings settings helps immensely with heat, but some of you might be doing more with the machine and in that case you can flip it over on your lunch break and cook an egg on the underside. Suprisingly working well at a crippled 666mhz! (devil hand emoji)

[LarsG5]

A vote from me as well for the cardbus!

That's basically the only issue I have with this model - I would love to be able to plug my Cardbus SCSI card which only works under OS9 - need to use my Ti for this purpose instead.

''unsupported usb device, click ok" prompt shows at every boot, unaware of how or what to use to silence that.

AFAIK it's the Bluetooth - back when I was more knowledgable about those stuff I was able to write a script for OF to disable it, unfortunatelly now I don't know how to do that anymore, though the answer is definitely here, somewhere on this forum.

[UnexpectedBomb]

@LarsG5 I apologize, I think I misunderstood what you were originally asking about  I've been working on bringing true USB 2.0 speeds to NEC-chipset CardBus USB 2.0 cards for TiBooks under OS 9 (which I just finished!) so your post caught my eye, but now I realize you were talking about CardBus working specifically on the 17" AlBook, which it sounds like currently it doesn't at all. Unfortunately, the only CardBus Mac I own is my 667 DVI TiBook; I have no AlBook of my own to test on. Really wish I had one now.

HOWEVER... I designed a test probe app for you to run on your 17" AlBook. This simple app will determine if the CardBus port can be reached under OS 9 on the AlBook. After you run it, a text log file will be generated; please send me that file. Based on my CardBus work thus far, I am fairly confident that a proper CardBus solution could be developed for the AlBook, but again, I'd need a test subject first. (Care to loan me yours? Haha)

Additionally you can test out the app on your own TiBook, as it will also recognize CardBus cards themselves and document their properties, such as whether they are (in the case of a USB card) NEC-chipset or some other incompatible chipset like VIA.

Here's the repo where you can find the test probe app (called CardBusCompat.bin) as well as the system extension I developed to unlock USB 2.0 on CardBus in OS 9:

https://github.com/UnexpectedBomb/MacOS9-USB2-EHCI/releases#release-cbrel

Just expand via Stuffit and launch. Let me know if you have any trouble.

[vectrex]

=== CardBusCompat 1.0 ===
Read-only: writes only the config-address selector, which is how any config read is addressed.

--- MACHINE: is there a CardBus bridge? ---
  bridge vendor-id 0x0000104c
  bridge device-id 0x0000ac56
  CardBus bridge FOUND.

--- CARD: what is in the slot? ---
  No USB 1.1 function published UNDER THE BRIDGE. Either no card is inserted, or
  Mac OS 9 does not recognise it (some cards are invisible to Mac OS 9 entirely).
  USB 1.1 functions published in total 0x00000000
  of those, NEC (vendor 0x1033) 0x00000000

--- MACHINE: can we reach config space the way the extension does? ---
  Cannot test: no card function is published, so there is no known-good answer to check
  the raw path against. Insert a CardBus card Mac OS 9 recognises and run this again.

========================= VERDICT =========================
MACHINE:  UNKNOWN - a CardBus slot exists, but testing it needs a card Mac OS 9 recognises.
CARD:     NONE - no card detected in the slot.
===========================================================

A log named 'CardBus Compatibility Log' has been written to your startup disk.

[UnexpectedBomb]

@vectrex thank you for running that compatibility checker and providing the results! I'm realizing I had an outdated version on the repo; if you re-download now it should be v1.6. My fault. Run that one and it should tell us what we need to know about the AlBook's CardBus landscape.

Already this result confirms that your CardBus controller is a TI PCI1510, which Mac OS 9 had never seen before (hence the "dead"-ness of the port). The original v1.0 checker had a defect that made it unreliable at properly detecting inserted cards, so that's another reason to want the results coming from v1.6 if you had a card inserted when you ran it.

Edit: The most important part will be whether the "compatible" line contains the generic "cardbus-bridge", as the TiBook's does.
If it does... game on. I might be able to design a universal CardBus fix that would work for AlBooks too, without ever needing to get hands on one myself.

[vectrex]

Thanks UnexpectedBomb!

Here is the latest report:


=== CardBusCompat 1.6 ===
Read-only: writes only the config-address selector, which is how any config read is addressed.

--- MACHINE: is there a CardBus bridge? ---
  bridge vendor-id 0x0000104c
  bridge device-id 0x0000ac56
  bridge revision-id 0x00000000
  name = cardbus |
  device_type = cardbus |
  compatible = pci104c,ac56 | cardbus-bridge |
  model = TXN,PCIXXXX-00 |
  bridge AAPL,address 0xf2009010
  bus-range = (ABSENT)
  driver,AAPL,MacOS,PowerPC = ABSENT (the ROM did NOT match this node; no socket driver, no Card Services)
  CardBus bridge FOUND.

--- CARD: what is in the slot? ---
  Mac OS 9 published NOTHING under the bridge.
  No USB 1.1 function published UNDER THE BRIDGE. Either no card is inserted, or
  Mac OS 9 does not recognise it (some cards are invisible to Mac OS 9 entirely).
  USB 1.1 functions published in total 0x00000000
  of those, NEC (vendor 0x1033) 0x00000000

--- MACHINE: can we reach config space the way the extension does? ---
  Subject: the CardBus BRIDGE itself, because no card function is published.
  chain (the extension takes the FIRST AAPL,address it meets):
   level 0x00000000
  name = cardbus |
  device_type = cardbus |
    AAPL,address 0xf2009010
   level 0x00000001
  name = pci |
  device_type = pci |
    AAPL,address = (ABSENT)
    host-bus reg[0] (second candidate base) 0xf2000000
   level 0x00000002
  name = device-tree |
  device_type = bootrom |
    AAPL,address = (ABSENT)
   level 0x00000003
  name = Devices |
  device_type = (ABSENT)
    AAPL,address = (ABSENT)
  subject bus 0x00000000
  subject device 0x00000013
  CANDIDATE 1: the extension's own rule (first parent AAPL,address).
    base 0xf2009010
    CONFIG_ADDRESS 0xf2809010
    CONFIG_DATA 0xf2c09010
    cycle type: 0 (the subject is on bus 0)
    trusted reading (ExpMgr) 0xac56104c
    raw reading (type-1) 0xac56104c
    selector retries (0 is ideal) 0x00000000
    RESULT: this base reproduced the known-good answer.
  CANDIDATE 2: the canonical rule (host bus reg base).
    base 0xf2000000
    CONFIG_ADDRESS 0xf2800000
    CONFIG_DATA 0xf2c00000
    cycle type: 0 (the subject is on bus 0)
    trusted reading (ExpMgr) 0xac56104c
    raw reading (type-1) 0xac56104c
    selector retries (0 is ideal) 0x00000000
    RESULT: this base reproduced the known-good answer.
  Both bases reach the same registers, which is the UniNorth aliasing, measured.
  ORACLE PASSED: the raw path reproduced a known-good answer.

========================= VERDICT =========================
SOCKET:   NOT BOUND - the ROM did NOT attach a socket driver to this bridge.
          Mac OS 9 carries socket support for two CardBus controllers only,
          TI PCI1210 (pci104c,ac1a) and TI PCI1410 (pci104c,ac50). Card Services
          itself is loaded by the same rule, so on this machine the whole PC Card
          stack is absent, not merely idle. Every PC Card will appear dead.
          Please send this log: the 'compatible' line above is the exact data needed.
MACHINE:  YES, AS FAR AS AN EMPTY SLOT CAN SHOW - the config-address pair is verified
          by a type-0 read of the bridge. Nothing was in the slot, so the type-1 path
          the extension uses for a card was not exercised. Re-run with a card inserted
          to confirm the rest; any CardBus card will do, it need not be supported.
CARD:     NONE PUBLISHED - Mac OS 9 published no card. The slot could not be swept to confirm.
===========================================================

A log named 'CardBus Compatibility Log' has been written to your startup disk.

[UnexpectedBomb]

@vectrex that result is looking VERY promising. One final run please, on v1.8 (I found and fixed a reading bug in the version you had, so a fresh download is needed). It's up on the repo now.

The checker now dumps the bridge's own registers, which tells us whether Open Firmware ever configured your CardBus slot or left it untouched. That should finally decide how fixable this is.

Run it once empty and once with any CardBus card inserted. Best case scenario: the checker recognizes an inserted card and detects its functions. If it does, I could cut a custom ROM for testing and theoretically have this thing functional for the first time ever.

EDIT: I made a newer v1.9 checker that also tell me what version of the Mac OS ROM you are running, so I will know how to patch it. Run v1.9 instead, especially with a card inserted.

[smilesdavis]

Love the realtime AI fixes

[UnexpectedBomb]

Love the realtime AI fixes

  Honestly, this is an interesting problem to me, having just done a bunch of CardBus work AND having done similar "enablement" work on the FW800 MDD already. The AlBook seems to have similar hardware-blocking woes, and I think it's possible that some of the other stuff I've developed for the MDD FW800 (namely the FireWire port extension fix) could also help out the AlBook. Once I get Bluetooth and Airport Extreme released, they should hopefully apply to the AlBook as well.

[IIO]

now that you say it, yes, some of the not supported powerbooks do use USB 2 for the keypad, for example.

[LarsG5]

Hi, so here's the log from my Al, v. 1.9, hopefully I did everything correctly. This one is with a generic USB card in the Cardbus slot:

=== CardBusCompat 1.9 ===
Read-only: writes only the config-address selector, which is how any config read is addressed.

--- IDENTITY: which Mac, and which Mac OS ROM ---
  model = PowerBook5,1 |
  compatible = PowerBook5,1 | MacRISC3 | Power Macintosh |
  MacOSROMFile-version = 10.2f1 |

--- MACHINE: is there a CardBus bridge? ---
  bridge vendor-id 0x0000104c
  bridge device-id 0x0000ac56
  bridge revision-id 0x00000000
  name = cardbus |
  device_type = cardbus |
  compatible = pci104c,ac56 | cardbus-bridge |
  model = TXN,PCIXXXX-00 |
  bridge AAPL,address 0xf2009010
  bus-range = (ABSENT)
  driver,AAPL,MacOS,PowerPC = ABSENT (the ROM did NOT match this node; no socket driver, no Card Services)
  CardBus bridge FOUND.

--- CARD: what is in the slot? ---
  Mac OS 9 published NOTHING under the bridge.
  No USB 1.1 function published UNDER THE BRIDGE. Either no card is inserted, or
  Mac OS 9 does not recognise it (some cards are invisible to Mac OS 9 entirely).
  USB 1.1 functions published in total 0x00000000
  of those, NEC (vendor 0x1033) 0x00000000

--- MACHINE: can we reach config space the way the extension does? ---
  Subject: the CardBus BRIDGE itself, because no card function is published.
  chain (the extension takes the FIRST AAPL,address it meets):
   level 0x00000000
  name = cardbus |
  device_type = cardbus |
    AAPL,address 0xf2009010
   level 0x00000001
  name = pci |
  device_type = pci |
    AAPL,address = (ABSENT)
    host-bus reg[0] (second candidate base) 0xf2000000
   level 0x00000002
  name = device-tree |
  device_type = bootrom |
    AAPL,address = (ABSENT)
   level 0x00000003
  name = Devices |
  device_type = (ABSENT)
    AAPL,address = (ABSENT)
  subject bus 0x00000000
  subject device 0x00000013
  CANDIDATE 1: the extension's own rule (first parent AAPL,address).
    base 0xf2009010
    CONFIG_ADDRESS 0xf2809010
    CONFIG_DATA 0xf2c09010
    cycle type: 0 (the subject is on bus 0)
    trusted reading (ExpMgr) 0xac56104c
    raw reading (type-1) 0xac56104c
    selector retries (0 is ideal) 0x00000000
    RESULT: this base reproduced the known-good answer.
  CANDIDATE 2: the canonical rule (host bus reg base).
    base 0xf2000000
    CONFIG_ADDRESS 0xf2800000
    CONFIG_DATA 0xf2c00000
    cycle type: 0 (the subject is on bus 0)
    trusted reading (ExpMgr) 0xac56104c
    raw reading (type-1) 0xac56104c
    selector retries (0 is ideal) 0x00000000
    RESULT: this base reproduced the known-good answer.
  Both bases reach the same registers, which is the UniNorth aliasing, measured.
  ORACLE PASSED: the raw path reproduced a known-good answer.

--- BRIDGE: its own PCI configuration ---
  0x04 command/status 0x02100007
    memory decode enabled: YES
    I/O decode enabled: YES
    bus master enabled: YES
  0x10 socket register base (BAR0) 0xa0003000
  0x18 bus numbers and CardBus latency 0x20010100
    primary bus 0x00000000
    SECONDARY (CardBus) bus 0x00000001
    subordinate bus 0x00000001
  0x1c memory window 0 base 0x90000000
  0x20 memory window 0 limit 0x9ffff000
  0x24 memory window 1 base 0x00000000
  0x28 memory window 1 limit 0x00000000
  0x2c I/O window 0 base 0x00001000
  0x30 I/O window 0 limit 0x00008ffc
  0x34 I/O window 1 base 0x00000000
  0x38 I/O window 1 limit 0x00000000
  0x3c int line / int pin / bridge control 0x040001ff
  => PROGRAMMED. The bridge has a secondary bus number, so firmware or software has
     already configured it and a driver could inherit that work.

--- SLOT: the socket's own card-detect register ---
  Skipped: AAPL,address and BAR0 disagree, so nothing here is safe to dereference.
    AAPL,address page 0xf2009000
    BAR0 page 0xa0003000

  The registry had no bus-range, so the sweep below uses the secondary bus
  number read from the bridge's own config space instead.

--- SLOT: raw sweep of the bridge's secondary bus ---
  This sees the card itself, whether or not Mac OS 9 published anything for it.
  sweeping bus 0x00000001
  device 0x00000000
    function 0x00000000
    vendor/device 0x00351033
    class-code 0x000c0310
      = USB 1.1 (OHCI)
  device 0x00000000
    function 0x00000001
    vendor/device 0x00351033
    class-code 0x000c0310
      = USB 1.1 (OHCI)
  device 0x00000000
    function 0x00000002
    vendor/device 0x00e01033
    class-code 0x000c0320
      = USB 2.0 (EHCI)
  functions that answered in total 0x00000003

========================= VERDICT =========================
SOCKET:   NOT BOUND - the ROM did NOT attach a socket driver to this bridge.
          Mac OS 9 carries socket support for two CardBus controllers only,
          TI PCI1210 (pci104c,ac1a) and TI PCI1410 (pci104c,ac50). Card Services
          itself is loaded by the same rule, so on this machine the whole PC Card
          stack is absent, not merely idle. Every PC Card will appear dead.
          Please send this log: the 'compatible' line above is the exact data needed.
MACHINE:  YES - the config-address pair is verified (type 0, on the bridge) AND a card
          answered a type-1 sweep of the slot's bus, so both cycle types work here.
CARD:     NEC chipset present, but Mac OS 9 published nothing for it (raw sweep only).
===========================================================

A log named 'CardBus Compatibility Log' has been written to your startup disk.

[LarsG5]

And this one is with the Cardbus slot empty:

=== CardBusCompat 1.9 ===
Read-only: writes only the config-address selector, which is how any config read is addressed.

--- IDENTITY: which Mac, and which Mac OS ROM ---
  model = PowerBook5,1 |
  compatible = PowerBook5,1 | MacRISC3 | Power Macintosh |
  MacOSROMFile-version = 10.2f1 |

--- MACHINE: is there a CardBus bridge? ---
  bridge vendor-id 0x0000104c
  bridge device-id 0x0000ac56
  bridge revision-id 0x00000000
  name = cardbus |
  device_type = cardbus |
  compatible = pci104c,ac56 | cardbus-bridge |
  model = TXN,PCIXXXX-00 |
  bridge AAPL,address 0xf2009010
  bus-range = (ABSENT)
  driver,AAPL,MacOS,PowerPC = ABSENT (the ROM did NOT match this node; no socket driver, no Card Services)
  CardBus bridge FOUND.

--- CARD: what is in the slot? ---
  Mac OS 9 published NOTHING under the bridge.
  No USB 1.1 function published UNDER THE BRIDGE. Either no card is inserted, or
  Mac OS 9 does not recognise it (some cards are invisible to Mac OS 9 entirely).
  USB 1.1 functions published in total 0x00000000
  of those, NEC (vendor 0x1033) 0x00000000

--- MACHINE: can we reach config space the way the extension does? ---
  Subject: the CardBus BRIDGE itself, because no card function is published.
  chain (the extension takes the FIRST AAPL,address it meets):
   level 0x00000000
  name = cardbus |
  device_type = cardbus |
    AAPL,address 0xf2009010
   level 0x00000001
  name = pci |
  device_type = pci |
    AAPL,address = (ABSENT)
    host-bus reg[0] (second candidate base) 0xf2000000
   level 0x00000002
  name = device-tree |
  device_type = bootrom |
    AAPL,address = (ABSENT)
   level 0x00000003
  name = Devices |
  device_type = (ABSENT)
    AAPL,address = (ABSENT)
  subject bus 0x00000000
  subject device 0x00000013
  CANDIDATE 1: the extension's own rule (first parent AAPL,address).
    base 0xf2009010
    CONFIG_ADDRESS 0xf2809010
    CONFIG_DATA 0xf2c09010
    cycle type: 0 (the subject is on bus 0)
    trusted reading (ExpMgr) 0xac56104c
    raw reading (type-1) 0xac56104c
    selector retries (0 is ideal) 0x00000000
    RESULT: this base reproduced the known-good answer.
  CANDIDATE 2: the canonical rule (host bus reg base).
    base 0xf2000000
    CONFIG_ADDRESS 0xf2800000
    CONFIG_DATA 0xf2c00000
    cycle type: 0 (the subject is on bus 0)
    trusted reading (ExpMgr) 0xac56104c
    raw reading (type-1) 0xac56104c
    selector retries (0 is ideal) 0x00000000
    RESULT: this base reproduced the known-good answer.
  Both bases reach the same registers, which is the UniNorth aliasing, measured.
  ORACLE PASSED: the raw path reproduced a known-good answer.

--- BRIDGE: its own PCI configuration ---
  0x04 command/status 0x02100007
    memory decode enabled: YES
    I/O decode enabled: YES
    bus master enabled: YES
  0x10 socket register base (BAR0) 0xa0003000
  0x18 bus numbers and CardBus latency 0x20010100
    primary bus 0x00000000
    SECONDARY (CardBus) bus 0x00000001
    subordinate bus 0x00000001
  0x1c memory window 0 base 0x90000000
  0x20 memory window 0 limit 0x9ffff000
  0x24 memory window 1 base 0x00000000
  0x28 memory window 1 limit 0x00000000
  0x2c I/O window 0 base 0x00001000
  0x30 I/O window 0 limit 0x00008ffc
  0x34 I/O window 1 base 0x00000000
  0x38 I/O window 1 limit 0x00000000
  0x3c int line / int pin / bridge control 0x044001ff
  => PROGRAMMED. The bridge has a secondary bus number, so firmware or software has
     already configured it and a driver could inherit that work.

--- SLOT: the socket's own card-detect register ---
  Skipped: AAPL,address and BAR0 disagree, so nothing here is safe to dereference.
    AAPL,address page 0xf2009000
    BAR0 page 0xa0003000

  The registry had no bus-range, so the sweep below uses the secondary bus
  number read from the bridge's own config space instead.

--- SLOT: raw sweep of the bridge's secondary bus ---
  This sees the card itself, whether or not Mac OS 9 published anything for it.
  sweeping bus 0x00000001
  Nothing answered. The slot is genuinely empty or the card is unpowered.

========================= VERDICT =========================
SOCKET:   NOT BOUND - the ROM did NOT attach a socket driver to this bridge.
          Mac OS 9 carries socket support for two CardBus controllers only,
          TI PCI1210 (pci104c,ac1a) and TI PCI1410 (pci104c,ac50). Card Services
          itself is loaded by the same rule, so on this machine the whole PC Card
          stack is absent, not merely idle. Every PC Card will appear dead.
          Please send this log: the 'compatible' line above is the exact data needed.
MACHINE:  YES, AS FAR AS AN EMPTY SLOT CAN SHOW - the config-address pair is verified
          by a type-0 read of the bridge. Nothing was in the slot, so the type-1 path
          the extension uses for a card was not exercised. Re-run with a card inserted
          to confirm the rest; any CardBus card will do, it need not be supported.
CARD:     NONE - nothing answered a raw sweep of the slot's bus, so it is genuinely empty.
===========================================================

A log named 'CardBus Compatibility Log' has been written to your startup disk.