Q: control is a C&T 65550?

Q: control is a C&T 65550?

[Jason Y. Sproul]

Is it correct that the /chaos/control chip is essentially a Chips &
Technologies 65550? If so, does anyone have the variances from the 65550
datasheet, and if not, what the heck is it? :^)

........................................................................
Jason Y. Sproul                    http://www.con.wesleyan.edu/~jsproul/
jsproul@wesleyan.edu        jsproul@iced.com        http://www.iced.com/
     Eagles may soar, but weasels don't get sucked into jet engines.


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Daniel Jacobowitz]

On Tue, Jun 08, 1999 at 07:51:39AM -0400, Jason Y. Sproul wrote:
> 
> Is it correct that the /chaos/control chip is essentially a Chips &
> Technologies 65550? If so, does anyone have the variances from the 65550
> datasheet, and if not, what the heck is it? :^)

It's my understanding that it's not.  No one has any documentation on
it to my knowledge... I'd love to add hardware cursor support, which
I'm fairly sure it has, to controlfb.  But I can't do it without some
sort of reference.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Geert Uytterhoeven]

On Tue, 8 Jun 1999, Daniel Jacobowitz wrote:
> On Tue, Jun 08, 1999 at 07:51:39AM -0400, Jason Y. Sproul wrote:
> > Is it correct that the /chaos/control chip is essentially a Chips &
> > Technologies 65550? If so, does anyone have the variances from the 65550
> > datasheet, and if not, what the heck is it? :^)
> 
> It's my understanding that it's not.  No one has any documentation on
> it to my knowledge... I'd love to add hardware cursor support, which
> I'm fairly sure it has, to controlfb.  But I can't do it without some
> sort of reference.

Move the cursor under MacOS and see which registers or video memory addresses
change?

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Daniel Jacobowitz]

On Tue, Jun 08, 1999 at 04:00:48PM +0200, Geert Uytterhoeven wrote:
> On Tue, 8 Jun 1999, Daniel Jacobowitz wrote:
> > On Tue, Jun 08, 1999 at 07:51:39AM -0400, Jason Y. Sproul wrote:
> > > Is it correct that the /chaos/control chip is essentially a Chips &
> > > Technologies 65550? If so, does anyone have the variances from the 65550
> > > datasheet, and if not, what the heck is it? :^)
> > 
> > It's my understanding that it's not.  No one has any documentation on
> > it to my knowledge... I'd love to add hardware cursor support, which
> > I'm fairly sure it has, to controlfb.  But I can't do it without some
> > sort of reference.
> 
> Move the cursor under MacOS and see which registers or video memory addresses
> change?

That's one of those if-i-had-more-time things - and more specifically,
if I knew how to dump video regs under macos.  Is it trivial?

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Geert Uytterhoeven]

On Tue, 8 Jun 1999, Daniel Jacobowitz wrote:
> On Tue, Jun 08, 1999 at 04:00:48PM +0200, Geert Uytterhoeven wrote:
> > On Tue, 8 Jun 1999, Daniel Jacobowitz wrote:
> > > On Tue, Jun 08, 1999 at 07:51:39AM -0400, Jason Y. Sproul wrote:
> > > > Is it correct that the /chaos/control chip is essentially a Chips &
> > > > Technologies 65550? If so, does anyone have the variances from the 65550
> > > > datasheet, and if not, what the heck is it? :^)
> > > 
> > > It's my understanding that it's not.  No one has any documentation on
> > > it to my knowledge... I'd love to add hardware cursor support, which
> > > I'm fairly sure it has, to controlfb.  But I can't do it without some
> > > sort of reference.
> > 
> > Move the cursor under MacOS and see which registers or video memory addresses
> > change?
> 
> That's one of those if-i-had-more-time things - and more specifically,
> if I knew how to dump video regs under macos.  Is it trivial?

It's the way all those hardcoded tables arrived in the frame buffer devices for
Apple's video hardware.

Don't ask me more... What's MacOS?

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Paul Mackerras]

Daniel Jacobowitz <drow@false.org> wrote:

> That's one of those if-i-had-more-time things - and more specifically,
> if I knew how to dump video regs under macos.  Is it trivial?

This is where I use xmon.  There is a macos version at (I think)
ftp://ftp.linuxppc.org/users/paulus/misc/xmon.bin.  From memory, the
control registers are at 0x90010000 and the RADACAL (ramdac/cursor
chip) registers are at 0xf301b000.

The other thing to do is to browse through the darwin sources from
apple and see if they have a control driver somewhere.

IIRC, the hardware cursor uses some extra bytes on each scan line and
some registers in the RADACAL.

Paul.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Daniel Jacobowitz]

On Wed, Jun 09, 1999 at 09:54:18AM +1000, Paul Mackerras wrote:
> Daniel Jacobowitz <drow@false.org> wrote:
> 
> > That's one of those if-i-had-more-time things - and more specifically,
> > if I knew how to dump video regs under macos.  Is it trivial?
> 
> This is where I use xmon.  There is a macos version at (I think)
> ftp://ftp.linuxppc.org/users/paulus/misc/xmon.bin.  From memory, the
> control registers are at 0x90010000 and the RADACAL (ramdac/cursor
> chip) registers are at 0xf301b000.
> 
> The other thing to do is to browse through the darwin sources from
> apple and see if they have a control driver somewhere.
> 
> IIRC, the hardware cursor uses some extra bytes on each scan line and
> some registers in the RADACAL.

Ahah, xmon might be quite useful here.  Also, were I to browse Darwin,
would I be able to use that information?  Have those licence problems
ever been straightened out?


Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Paul Mackerras]

Daniel Jacobowitz <drow@false.org> wrote:

> Ahah, xmon might be quite useful here.  Also, were I to browse Darwin,
> would I be able to use that information?  Have those licence problems
> ever been straightened out?

I don't see that there are any licence problems.  It's open source,
after all.  You don't have to sign any NDA.  The licence is OK as
you're not going to redistribute or even use it, you're just going to
read it, and ideas/knowledge/facts aren't covered by copyright.

Anyway, I think Apple is (slowly) coming to see that the availability
of Linux for their machines is an advantage, not a threat.

Paul.

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Daniel Jacobowitz]

On Wed, Jun 09, 1999 at 09:54:18AM +1000, Paul Mackerras wrote:
> The other thing to do is to browse through the darwin sources from
> apple and see if they have a control driver somewhere.

Licence issues aside, they don't have video drivers there, as far as I
can see.  Lots of other little goodies, but no video drivers.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Michel Lanners]

On   8 Jun, this message from Daniel Jacobowitz echoed through cyberspace:
> 
> On Tue, Jun 08, 1999 at 04:00:48PM +0200, Geert Uytterhoeven wrote:
>> On Tue, 8 Jun 1999, Daniel Jacobowitz wrote:
>> > On Tue, Jun 08, 1999 at 07:51:39AM -0400, Jason Y. Sproul wrote:
>> > > Is it correct that the /chaos/control chip is essentially a Chips &
>> > > Technologies 65550? If so, does anyone have the variances from the 65550
>> > > datasheet, and if not, what the heck is it? :^)
>> > 
>> > It's my understanding that it's not.  No one has any documentation on
>> > it to my knowledge... I'd love to add hardware cursor support, which
>> > I'm fairly sure it has, to controlfb.  But I can't do it without some
>> > sort of reference.
>> 
>> Move the cursor under MacOS and see which registers or video memory addresses
>> change?
> 
> That's one of those if-i-had-more-time things - and more specifically,
> if I knew how to dump video regs under macos.  Is it trivial?

Not with my favourite tool: MacsBug. Problem is that MacsBug includes
some kind of control driver, that is able to switch control into its
own mode, preserving the original VRAM contents from MacOS... except
the cursor, of course. So, when you look at control's registers with
MacsBug, you see MacsBug's values, not MacOS'.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Michel Lanners]

On   8 Jun, this message from Daniel Jacobowitz echoed through cyberspace:
>> Is it correct that the /chaos/control chip is essentially a Chips &
>> Technologies 65550?
> 
> It's my understanding that it's not.

I think so too. The little documentation available about control tells
us it has fundamental differences with c&t 65550. Plus, the 65550 is
designed specifically for an LCD panel in portable applications.

> No one has any documentation on
> it to my knowledge... 

Not really specific documentation; but some things can be learned by
looking at Apple's Spec library, in the PDF datasheet about the
original 7500/8500 series computers.

> I'd love to add hardware cursor support, which
> I'm fairly sure it has, to controlfb.  But I can't do it without some
> sort of reference.

For the interested, here is a little writeup of what I have learned over
the years ;-) about control:

- The system consists of two or three pieces, not of a monolithic chip
like most grafic chips today (c&t 65550 would be an example of that
monolithic class, integrating bus interface, VRAM interface, control
logic, and sometimes RAMDAC).

- The video subsystem resides on its own PCI-like bus, which is a
64-bit bus, clocked the same as the CPU bus (40-50 MHz), attached to the
CPU bus by a bridge (named chaos).

- control is the interface chip that attaches the VRAM to this PCI-like
bus. Although it probably has other control functions, those are little
known. One of those functions is defining video signal timing
parameters.

- The VRAM is a dual-port DRAM (relatively slow), unlike most modern
video adaptors, that use some kind of standard (single-port) modern RAM
(SDRAM, SGRAM, etc...). The bus towards control (i.e. towards the CPU)
is 64 bits wide; towards the RAMDAC it is 128 bits wide (at least in
max VRAM configurations).

- The RAMDAC is an Apple ASIC as well, named RaDaCal, integrating the
RAMDAC, CLUT and a hardware cursor device. Use and programming of the
hardware cursor are yet undocumented. The known details are that the
cursor needs to be drawn by the OS as some kind of sprite, in an
offscreen VRAM portion reserved at the end of each scanline. The
vertical position needs to be drawn at the right offset, whereas the
horizontal position of the cursor is taken care of by RaDaCal, probably
by setting the horizontal position info in a register. Vertical
movements therefore need a redraw by the OS.

- There is probably a third chip in the system, which generates the
clock signals. This can be deduced from the fact that clock parameters
are set via an I2C bus off cuda, and not through either RaDaCal or
control.

Obviously, all of the above information can be totally wrong ;-). If
there is any Apple engineer in the audience who knows better, please do
speak up!

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Daniel Jacobowitz]

On Thu, Jun 10, 1999 at 10:51:08PM +0200, Michel Lanners wrote:
> - The RAMDAC is an Apple ASIC as well, named RaDaCal, integrating the
> RAMDAC, CLUT and a hardware cursor device. Use and programming of the
> hardware cursor are yet undocumented. The known details are that the
> cursor needs to be drawn by the OS as some kind of sprite, in an
> offscreen VRAM portion reserved at the end of each scanline. The
> vertical position needs to be drawn at the right offset, whereas the
> horizontal position of the cursor is taken care of by RaDaCal, probably
> by setting the horizontal position info in a register. Vertical
> movements therefore need a redraw by the OS.

I intend to see what I can do about documenting the hardware cursor. 
With all the excellent advice I've gotten, I expect it won't be too
difficult.

> Obviously, all of the above information can be totally wrong ;-). If
> there is any Apple engineer in the audience who knows better, please do
> speak up!

Unfortunately, the Apple engineers in the audience aren't allowed to :(

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Michel Lanners]

On  10 Jun, this message from Daniel Jacobowitz echoed through cyberspace:
[snip'ed the details]
> 
> I intend to see what I can do about documenting the hardware cursor. 
> With all the excellent advice I've gotten, I expect it won't be too
> difficult.

One thing I have done to look at hoe this stuff is working is to put
the cursor under Macos and/or MacsBug at some precise location (top
left corner), and look at the data in the invisible last portion of
each scanline in VRAM. That should tell us how and in what format the
cursor bitmap needs to be drawn. Restricting the cursor movement to
horizontal movements, and looking at RaDaCal's registers, should tell
us where the horizontal position needs to be set.

Unfortunately, as to the registers that control the appearance of the
cursor (visible/not visible; its colors, etc...), I have no iddea where
exactly on RaDaCal they are, and how to identify them except by poking
at registers from a distance...

>> Obviously, all of the above information can be totally wrong ;-). If
>> there is any Apple engineer in the audience who knows better, please do
>> speak up!
> 
> Unfortunately, the Apple engineers in the audience aren't allowed to :(

What a shame! After all, the control hardware can be seen as a legacy
device, being surpassed by any and all current video chips... or might
Apple be hiding some really cool and powerful feature deep inside
control? I doubt it....

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Benjamin Herrenschmidt]

On Fri, Jun 11, 1999, Michel Lanners <mlan@cpu.lu> wrote:

>Unfortunately, as to the registers that control the appearance of the
>cursor (visible/not visible; its colors, etc...), I have no iddea where
>exactly on RaDaCal they are, and how to identify them except by poking
>at registers from a distance...

This could probably be found by tracing Apple's control driver. There are
a few video driver calls used to control the hw cursor, they are
documented, and I know at least two ways of tracing that: one is the
mac-on-linux emulator, and the other is Apple's serial-based 2 machines
debugger using the ROM stub. (It should be downloadable on Apple site
along with other ETO/MPW stuffs). This debugger can debug HW device
drivers loaded at very early boot time or hardware interrupts, and so
should have no problem tracing the control driver.

>What a shame! After all, the control hardware can be seen as a legacy
>device, being surpassed by any and all current video chips... or might
>Apple be hiding some really cool and powerful feature deep inside
>control? I doubt it....

I don't think so. There is however some kind of "graphic accelerator" for
control in MacOS, It's quite small, I don't know if it only provides
better blit routines optimised for non-cachable space, or eventually
hacks the MMU to make the fb space cahable (for bursts), I don't think
there's anything like a blitter or a DMA engine in control.

-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>




[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: Q: control is a C&T 65550?

[Jerry Quinn]

Benjamin Herrenschmidt wrote:
> 
> On Fri, Jun 11, 1999, Michel Lanners <mlan@cpu.lu> wrote:
> 
[snip] 
> >What a shame! After all, the control hardware can be seen as a legacy
> >device, being surpassed by any and all current video chips... or might
> >Apple be hiding some really cool and powerful feature deep inside
> >control? I doubt it....
> 
> I don't think so. There is however some kind of "graphic accelerator" for
> control in MacOS, It's quite small, I don't know if it only provides
> better blit routines optimised for non-cachable space, or eventually
> hacks the MMU to make the fb space cahable (for bursts), I don't think
> there's anything like a blitter or a DMA engine in control.

Do you have any guess what the graphic accelerator for Platinum does? 
At the moment, platinum is also used just as a frame buffer. 

-- 
Jerry Quinn                             Tel: (514) 761-8737
jquinn@nortelnetworks.com               Fax: (514) 761-8505
Speech Recognition Research

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]