gatos-devel Mailing List for GATOS

Hi,
whenever I try to capture (use the video in feature on) composite input
in PAL mode with avview 0.12, only one frame is displayed. When I switch
to NTSC, this does not happen.

This is debian unstable + kernel 2.4.23 + XFree 4.3 + km (cvs, today) +
drm-kernel 1.100.0-11 + gatos experimental 11 + avview 0.12
on AMD Athlon XP 1800+ + 1GB + KT266A + Radeon 64 VIVO.

XFree 4.3 from http://penguinppc.org/~daniels/
km, gatos, drm-kernel from http://gatos.sf.net

Does the message "VBI data capture is only supported for NTSC Tuner"
that appears in XFree86.0.log mean that this is a known limitation ATM?
Is there any chance of getting it to work with my setup? Will there be
a binary release that does PAL capture? Will there be a binary release
that does TV-out? Will I ever stop asking stupid questions?

Thanks in advance!

	Chris.


dmesg reports


Linux video capture interface: v1.00
Kmultimedia API module version alpha-3.0 loaded
Kmultimedia module version alpha-3.0 loaded
Page size is 4096 sizeof(bm_list_descriptor)=16 sizeof(KM_STRUCT)=960
km: using irq 11
Register aperture is 0xed000000 0x00080000
kms variables: reg_aperture=0xf9038000
km: DMA_GUI_STATUS=0x00000002 entries=2
sizeof(kmfl_template)=624 sizeof(KM_FIELD)=48
Device ATI Technologies Inc Radeon R100 QD [Radeon 7200] 01:00.0 
(0x1002:0x5144) corresponds to /dev/video0
kms variables: reg_aperture=0xf9038000

[drm] AGP 0.99 aperture @ 0xe8000000 64MB
[drm] Initialized radeon 1.100.0 20021218 on minor 0
Purging transfer queue
km: no data is available until AVview or xawtv is started

radeon_get_window_parameters: width=640 height=240
Capture buf size=307200
RADEON_BUS_CNTL=0x5133a3b0
Starting GUIDMA queue
radeon_get_window_parameters: width=640 height=240
Stopping GUIDMA queue
km: closed stream, 0 buffers captured
Purging transfer queue



/var/log/XFree86.0.log reports



(II) Module vgahw: vendor="The XFree86 Project"
         compiled for 4.3.0, module version = 0.1.0
         ABI class: XFree86 Video Driver, version 0.6
(II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 
0x0000
(II) RADEON(0): PCI bus 1 card 0 func 0
(**) RADEON(0): Depth 24, (--) framebuffer bpp 32
(II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
(==) RADEON(0): Default visual is TrueColor
(**) RADEON(0): Option "AGPMode" "4"
(**) RADEON(0): Option "AGPFastWrite" "on"
(==) RADEON(0): RGB weight 888
(II) RADEON(0): Using 8 bits per RGB (8 bit DAC)
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Reloading /usr/X11R6/lib/modules/linux/libint10.a
(II) RADEON(0): initializing int10
(II) RADEON(0): Primary V_BIOS segment is: 0xc000
(--) RADEON(0): Chipset: "ATI Radeon QD (AGP)" (ChipID = 0x5144)
(--) RADEON(0): Linear framebuffer at 0xe0000000
(--) RADEON(0): MMIO registers at 0xed000000
(--) RADEON(0): VideoRAM: 65536 kByte (64-bit DDR SDRAM)
(II) RADEON(0): Primary Display == Type 1
(II) Loading sub module "ddc"
(II) LoadModule: "ddc"
(II) Reloading /usr/X11R6/lib/modules/libddc.a
(II) Loading sub module "i2c"
(II) LoadModule: "i2c"
(II) Loading /usr/X11R6/lib/modules/libi2c.a
(II) Module i2c: vendor="The XFree86 Project"
         compiled for 4.3.0, module version = 1.2.0
         ABI class: XFree86 Video Driver, version 0.6
(II) RADEON(0): I2C bus "DDC" initialized.
(II) RADEON(0): PLL parameters: rf=2700 rd=60 min=12000 max=35000; 
xclk=16600
(==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0)
(II) RADEON(0): Validating modes on Primary head (DDCType: 3) ---------
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) RADEON(0): I2C device "DDC:ddc2" registered at address 0xA0.
(II) RADEON(0): I2C device "DDC:ddc2" removed.
(II) Loading sub module "vbe"
(II) LoadModule: "vbe"
(II) Reloading /usr/X11R6/lib/modules/libvbe.a
(II) RADEON(0): VESA BIOS detected
(II) RADEON(0): VESA VBE Version 2.0
(II) RADEON(0): VESA VBE Total Mem: 65536 kB
(II) RADEON(0): VESA VBE OEM: ATI RAGE128
(II) RADEON(0): VESA VBE OEM Software Rev: 1.0
(II) RADEON(0): VESA VBE OEM Vendor: ATI Technologies Inc.
(II) RADEON(0): VESA VBE OEM Product: RG6
(II) RADEON(0): VESA VBE OEM Product Rev: 01.00

(II) RADEON(0): VBI data capture is only supported for NTSC Tuner at the 
moment
(II) RADEON(0): VIDEO BIOS TABLE OFFSETS: bios_header=0x0124 mm_table=0x037e
(II) RADEON(0): MM_TABLE: 01-0c-00-1f-06-00-00-66-02-00-00-06-00-00
(II) Loading sub module "theatre"
(II) LoadModule: "theatre"
(II) Loading /usr/X11R6/lib/modules/multimedia/theatre_drv.o
(II) Module theatre: vendor="The XFree86 Project"
         compiled for 4.3.0, module version = 1.0.0
         ABI class: XFree86 Video Driver, version 0.6
(II) RADEON(0): No response from device 0 on VIP bus
(II) RADEON(0): Device 1 on VIP bus ids as 0x4d541002
(II) RADEON(0): No response from device 2 on VIP bus
(II) RADEON(0): No response from device 3 on VIP bus
(II) RADEON(0): Detected Rage Theatre as device 1 on VIP bus with id 
0x4d541002
(II) RADEON(0): Detected Rage Theatre revision 00000003

(II) RADEON(0): 0x55 0xaa
(II) RADEON(0): video decoder type is 0x40d8 versus 0x40d8
(II) RADEON(0): Composite connector is port 2
(II) RADEON(0): Rage Theatre: Connectors (detected): tuner=0, 
composite=2, svideo=0
(II) RADEON(0): RageTheatre: Connectors (using): tuner=0, composite=2, 
svideo=0
(II) RADEON(0): video decoder type used: 0x0006
(II) RADEON(0): Rage Theatre setting standard 0x0000
(II) RADEON(0): Rage Theatre Checkpoint 1
(II) RADEON(0): Rage Theatre Checkpoint 2, counter=10  (21)
(II) RADEON(0): Rage Theatre Checkpoint 3
(II) RADEON(0): Rage Theatre Checkpoint 4 i=97387
(II) RADEON(0): Rage Theatre Checkpoint 5 counter=181 (4)
(II) RADEON(0): Rage Theatre setting standard 0x0000
(II) RADEON(0): Rage Theatre setting standard 0x0000
(II) RADEON(0): X context handle = 0x00000001
(II) RADEON(0): [drm] installed DRM signal handler
(II) RADEON(0): [DRI] installation complete
(II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers
(II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers
(II) RADEON(0): [drm] dma control initialized, using IRQ 11
(II) RADEON(0): [drm] Initialized kernel agp heap manager, 5111808
(II) RADEON(0): Direct rendering enabled
(==) RandR enabled

I am curious - did anyone try to use alsa compatibility library with
AVview ?

                          best

                             Vladimir Dergachev

Hi Ken,
Friday, 28 November, 2003, 13:38:39, you wrote:
[...]
> But their reply is " We intentionally remove that part and will not release."
They can't. Probably their macrovision licence doesn't allow them to.

> "Find GATOS yourself"!!!! Damn good answer!!
:)

> Luckily, we also find one tvout.c source from internet, Like Nikolai said, we
> based on that and find that from http://www.uglyscar.com/gatos/src/gatos-0.0.5/src/tvout.c
> we find register related to impactv2 register. We are fighting on it.
the "official" url is http://gatos.sourceforge.net/cvs-gatos-ati.tar.gz
(It is old cvs repository backup. In order to actually extract files,
first unpack it, then 'cvs init ...' and 'cvs checkout ...' locally)

> We also tried to use the assemble method to access the BIOS register.
> We successfully switch on and off TV but still we can only use VBE
> call int (10) function. When we use the debugger to test int
> (10) process, we find seems ATI have protect that process so it just
> loop back and nothing can show.
Yes indeed, there are some problems:

* rom memory area is typically read-only after power-on init,
  therefore debugger can't put its breakpoints as usual so
  you only can step-into, not step-over, or otherwise execution
  just won't stop;

* rom code is typically able to modify itself during power-on
  init, therefore you'll never know what exactly happened on
  the very startup. Yes apparently ATI does this.

* if you try to re-run power-on init procedure after regular
  bootup your hardware is most probably not in that state as
  it was just after power-on, so you might just see different
  things happening.

To overcome these issues IMHO it is necessary to boot without
touching video card at all. Inserting additional video card as
primary will not help here, because it will eat up the resources
(address ranges) which would be needed to normally init the
second one.
A possible way is to tweak main rom bios to force it just skip
video init. This way you can see 'original' code with all hidden
parts, you can really see how hardware behaves and you can set
breakpoints! I tried it and it worked (courtesy of Award Boot
Block(tm) feature) Somewhat messy however.
So, I have my videom rom image saved with all those 'hidden' things
visible. I'm not yet sure what they actually do though.

> So now what we can do is to stick on that tvout.c source. Hope we can
> make it success.
I'll get back to tvout.c a bit later again.

> Besides, since ATI haven't give us that part (confidential information)
> when we success we will release that source to public for all LT-PRO,
> Mobility user to access TV-OUT function on any platform
That would be great!
-- 
Best regards,
 Nikolai Zhubr

> (PowerPC or SUN.. any platform cannot access VGA BIOS) as there is already
> no violation of NDA with ATI.

> By the way, thanks all for the effort on it. We hope it can be success shortly. Thanks for the opensource and we should protect and fight for it.

> with best regards,
> Ken Chung
> Business Consultant
> <One Team dying on LT-PRO TV Out Project......>

Dear all,

Really thanks for your help on that.=20

In fact we also do a more simple way - Ask ATI for the TV-OUT Register =
information (confidential information with NDA). But their reply is " We =
intentionally remove that part and will not release." "Find GATOS =
yourself"!!!! Damn good answer!!

Luckily, we also find one tvout.c source from internet, Like Nikolai =
said, we based on that and find that from =
http://www.uglyscar.com/gatos/src/gatos-0.0.5/src/tvout.c we find =
register related to impactv2 register. We are fighting on it.

We also tried to use the assemble method to access the BIOS register. We =
successfully switch on and off TV but still we can only use VBE call int =
(10) function. When we use the debugger to test int (10) process, we =
find seems ATI have protect that process so it just loop back and =
nothing can show.

So now what we can do is to stick on that tvout.c source. Hope we can =
make it success.

Besides, since ATI haven't give us that part (confidential information) =
when we success we will release that source to public for all LT-PRO, =
Mobility user to access TV-OUT function on any platform (PowerPC or =
SUN.. any platform cannot access VGA BIOS) as there is already no =
violation of NDA with ATI.

By the way, thanks all for the effort on it. We hope it can be success =
shortly. Thanks for the opensource and we should protect and fight for =
it.

with best regards,
Ken Chung
Business Consultant
<One Team dying on LT-PRO TV Out Project......>

| Date: Wed, 26 Nov 2003 22:05:15 +0300
| From: Nikolai Zhubr <s0...@ho...>
| To: Vladimir Dergachev <vo...@mi...>
| CC: gat...@li...
| Subject: Re: [GATOS]TV-OUT function on PowerPC (ATI RAGE LT PRO)
|=20
| [sorry if this appears twice, had mail server problem]
|=20
| Hi,
| Monday, 24 November, 2003, 18:31:32, Vladimir Dergachev wrote:
| > On Mon, 24 Nov 2003, Nikolai Zhubr wrote:
|=20
| >> Hi,
| >> P.S., I'd be happy if someone look through and try to find
| >> some code pattern(s) relevant to accessing ImpacTV. Or to
| >> guess at least :) And yes, it is all intel-style asm, sorry,
| >> that is what disasm able to produce, anyway I'm not so good
| >> reading AT&T one (Should be converted to C as soon as it works)
|=20
| > Have you taken a look inside mach64 ati.2 driver ? There are =
functions for
| > accessing ImpactTV there.
|=20
| Not in ati.2, but I've surprisingly found lots of interesting
| stuff in tvout.c,.h from old cvs tarball. The code looks even
| reasonably functional, though I didn't try to run or compile
| it. No doubt sub_91C1 is mostly the same thing as tvout_write32.
|=20
| Now I'm wondering,
| - from nice register names etc it looks much like someone did
|   actually have some specs somehow;
| - why is this code sitting there without any use then?
| --=20
| Best regards,
|  Nikolai Zhubr
|=20
| >                       best
|=20
| >                         Vladimir Dergachev
|=20
| >> --
| >> Best regards,
| >>  Nikolai Zhubr
| >>
| >> Monday, 24 November, 2003, 2:52:07, Nikolai Zhubr wrote:
| >> > Hi,
| >> > Saturday, 22 November, 2003, 8:20:28, dashken wrote:
| >> >> It should use ImpactTV2 but its embedded into the chip already.
| >>
| >> >> So you can still help us on that!!!
| >>
| >> >> By the way, if you got those data let us ask some more specific =
information.
| >>
| >> > Note, I don't have any information on tv-out other than I can =
shake
| >> > out of my own card myself ;o)
| >>
| >> > Now, fighting with it during this weekend gave the following =
piece
| >> > of knowledge: http://zhubr.tamb.ru/v01.asm
| >> > This is not just some stupid dump of video bios. Honest. This =
code
| >> > is self-consistent in that is doesn't have any external _code_ =
refs
| >> > and all of the procedures are (somehow) used.
| >> > Still _data_ refs are not yet done and all "unknown". Those need
| >> > much more efforts.
| >>
| >> > I suspect a lot of stuff is not strictly tv-out and can be simply
| >> > removed. OTOH, there might be some power-on tv-related
| >> > initialization needed, which is not there and it would probably
| >> > be hard to locate.
| >> > Anyway. Whoever might be interested / aware of, have a look and
| >> > try to enjoy. Any enlightening ideas and expert comments are =
welcome.
| >>
| >>
| >>
| >>
| >> -------------------------------------------------------
| >> This SF.net email is sponsored by: SF.net Giveback Program.
| >> Does SourceForge.net help you be more productive?  Does it
| >> help you create better code?  SHARE THE LOVE, and help us help
| >> YOU!  Click Here: http://sourceforge.net/donate/
| >> _______________________________________________
| >> Gatos-devel mailing list
| >> Gat...@li...
| >> https://lists.sourceforge.net/lists/listinfo/gatos-devel
| >>
|=20
|=20
| > -------------------------------------------------------
| > This SF.net email is sponsored by: SF.net Giveback Program.
| > Does SourceForge.net help you be more productive?  Does it
| > help you create better code?  SHARE THE LOVE, and help us help
| > YOU!  Click Here: http://sourceforge.net/donate/
| > _______________________________________________
| > Gatos-devel mailing list
| > Gat...@li...
| > https://lists.sourceforge.net/lists/listinfo/gatos-devel
|=20
|=20
|=20
|=20
|=20
| --__--__--
|=20
| _______________________________________________
| Gatos-devel mailing list
| Gat...@li...
| https://lists.sourceforge.net/lists/listinfo/gatos-devel
|=20
|=20
| End of Gatos-devel Digest
| 

Hi everyone,

  I've just released a new version of my tv output driver for ati.2.
The main improvement is the support for cards having the tv output
module inside the Radeon chip (an Embedded Rage Theater, ERT, as I
call it for a lack of a more official name). Cards in this category
include all radeon 9xxx and most (all?) AIW boards.

Installing the new driver is simple: download the "tv_output" branch
from ati.2 CVS, compile and install it following the usual instructions.
Once installed, all you need to have tv output is to set the "TVOutput"
option in XF86Config-4 to either "ntsc" or "pal". After this tv output
should be enabled whenever resolution is set to 800x600 (this is the
only resolution that is currently supported).

Some caveats:
- Your card must have a 27 MHz reference oscillator (all Radeons I had
a chance to look at have it, so this should be no problem)
- Your monitor should be able to sustain 50 or 60 Hz vertical refresh
frequency (according to tv standard you're using)
- NTSC is not very tested (my PAL TV set just shows some sort of a B/W
image for NTSC signals)
- No testing was done on DVI/LCD cards at all
- I will update the tv output page on GATOS as soon as
possible, at the moment is outdated.

Well, that's it for now. Let me have your feedbacks!


Bye,
Federico Ulivi - Milan (Italy)
http://utenti.lycos.it/fulivi



____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

[sorry if this appears twice, had mail server problem]

Hi,
Monday, 24 November, 2003, 18:31:32, Vladimir Dergachev wrote:
> On Mon, 24 Nov 2003, Nikolai Zhubr wrote:

>> Hi,
>> P.S., I'd be happy if someone look through and try to find
>> some code pattern(s) relevant to accessing ImpacTV. Or to
>> guess at least :) And yes, it is all intel-style asm, sorry,
>> that is what disasm able to produce, anyway I'm not so good
>> reading AT&T one (Should be converted to C as soon as it works)

> Have you taken a look inside mach64 ati.2 driver ? There are functions for
> accessing ImpactTV there.

Not in ati.2, but I've surprisingly found lots of interesting
stuff in tvout.c,.h from old cvs tarball. The code looks even
reasonably functional, though I didn't try to run or compile
it. No doubt sub_91C1 is mostly the same thing as tvout_write32.

Now I'm wondering,
- from nice register names etc it looks much like someone did
  actually have some specs somehow;
- why is this code sitting there without any use then?
-- 
Best regards,
 Nikolai Zhubr

>                       best

>                         Vladimir Dergachev

>> --
>> Best regards,
>>  Nikolai Zhubr
>>
>> Monday, 24 November, 2003, 2:52:07, Nikolai Zhubr wrote:
>> > Hi,
>> > Saturday, 22 November, 2003, 8:20:28, dashken wrote:
>> >> It should use ImpactTV2 but its embedded into the chip already.
>>
>> >> So you can still help us on that!!!
>>
>> >> By the way, if you got those data let us ask some more specific information.
>>
>> > Note, I don't have any information on tv-out other than I can shake
>> > out of my own card myself ;o)
>>
>> > Now, fighting with it during this weekend gave the following piece
>> > of knowledge: http://zhubr.tamb.ru/v01.asm
>> > This is not just some stupid dump of video bios. Honest. This code
>> > is self-consistent in that is doesn't have any external _code_ refs
>> > and all of the procedures are (somehow) used.
>> > Still _data_ refs are not yet done and all "unknown". Those need
>> > much more efforts.
>>
>> > I suspect a lot of stuff is not strictly tv-out and can be simply
>> > removed. OTOH, there might be some power-on tv-related
>> > initialization needed, which is not there and it would probably
>> > be hard to locate.
>> > Anyway. Whoever might be interested / aware of, have a look and
>> > try to enjoy. Any enlightening ideas and expert comments are welcome.
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?  SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Gatos-devel mailing list
>> Gat...@li...
>> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>>


> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel

Hi,

I sent a reply to Dan, but my post was rejected due to size.  They were 
already bzip2 -9, so there's no way to make them smaller.  But I finally 
got around to posting them to the web, so you can pick them up at:

http://pages.sbcglobal.net/superchkn/diff-gatos.2.6.0-test7.patch.bz2

If you have any questions, email and I'll get back eventually ;-)  If it 
sucks and doesn't work, sorry, I had some spare time and just wanted to 
see if I could get it to compile and interface with the 2.6 test kernel.

These patches are against 2.6.0-test7 drm and km needs to be built in 
the tree (the diff should automatically make.  These aren't complete 
since they don't have the sysfs parts implemented, but they do build and 
install.   I have texturing issues in 3D apps, but that could be due to 
the dri tree I grabbed back in September.  I don't have the hardware to 
test this on so I don't know if it works, I just added my chip id to 
test it, so it would go through the detection phase and never 
initializes, but at looks like it should work.  I may not have updated 
everything correctly in the drm though so it may just stomp all over 
some random memory location at times.  Let me know if it seems to do 
that and I might look at it more intently and see what I missed.  But 
then I might not depending on how much spare time I have...

You'll need to have the ati2 gatos server modules installed and this 
should work with that.  It should be fairly trivial to update newer 
versions of the 2.6 test series.  The only modifications that will have 
to be done are against the kernel drm and I don't believe that changes 
much anyway.

This should at least be a start for those interested in porting to 2.6 
and hopefully lessens the amount of work that needs to be done to get 
everything working fully.  I just don't have the time to tackle the 
larger parts like sysfs right now.

-Wes-


Daniel Kasak wrote:

> Hi all.
>
> I remember a post recently re: drm-kernel needing some work ( trivial 
> work from memory ) before being 2.6-ready.
> Is anyone planning on doing this, and if so ... when?
> It's not particularly important ( for me ) - I need drm-kernel for 
> tv-out, and currently I can't compile alsa with a 2.4 kernel ( no idea 
> why ).
> Anyway, if someone has plans, just a rough ETA would be cool so I can 
> decide which way I'm going :)
>
> Dan
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>

On Wed, 26 Nov 2003, Nikolai Zhubr wrote:

> Hi,
> Monday, 24 November, 2003, 18:31:32, Vladimir Dergachev wrote:
> > On Mon, 24 Nov 2003, Nikolai Zhubr wrote:
>
> >> Hi,
> >> P.S., I'd be happy if someone look through and try to find
> >> some code pattern(s) relevant to accessing ImpacTV. Or to
> >> guess at least :) And yes, it is all intel-style asm, sorry,
> >> that is what disasm able to produce, anyway I'm not so good
> >> reading AT&T one (Should be converted to C as soon as it works)
>
> > Have you taken a look inside mach64 ati.2 driver ? There are functions for
> > accessing ImpactTV there.
>
> Not in ati.2, but I've surprisingly found lots of interesting
> stuff in tvout.c,.h from old cvs tarball. The code looks even
> reasonably functional, though I didn't try to run or compile
> it. No doubt sub_91C1 is mostly the same thing as tvout_write32.
>
> Now I'm wondering,
> - from nice register names etc it looks much like someone did
>   actually have some specs somehow;
> - why is this code sitting there without any use then?

Christian Lupien worked on this. He wrote some TV-out code, but it had
some problems, and back then xatitv was a separate program and it was
not clear how to program tv-out  without conflicting with X.

                     best

                         Vladimir Dergachev

Hi,
Monday, 24 November, 2003, 18:31:32, Vladimir Dergachev wrote:
> On Mon, 24 Nov 2003, Nikolai Zhubr wrote:

>> Hi,
>> P.S., I'd be happy if someone look through and try to find
>> some code pattern(s) relevant to accessing ImpacTV. Or to
>> guess at least :) And yes, it is all intel-style asm, sorry,
>> that is what disasm able to produce, anyway I'm not so good
>> reading AT&T one (Should be converted to C as soon as it works)

> Have you taken a look inside mach64 ati.2 driver ? There are functions for
> accessing ImpactTV there.

Not in ati.2, but I've surprisingly found lots of interesting
stuff in tvout.c,.h from old cvs tarball. The code looks even
reasonably functional, though I didn't try to run or compile
it. No doubt sub_91C1 is mostly the same thing as tvout_write32.

Now I'm wondering,
- from nice register names etc it looks much like someone did
  actually have some specs somehow;
- why is this code sitting there without any use then?
-- 
Best regards,
 Nikolai Zhubr

>                       best

>                         Vladimir Dergachev

>> --
>> Best regards,
>>  Nikolai Zhubr
>>
>> Monday, 24 November, 2003, 2:52:07, Nikolai Zhubr wrote:
>> > Hi,
>> > Saturday, 22 November, 2003, 8:20:28, dashken wrote:
>> >> It should use ImpactTV2 but its embedded into the chip already.
>>
>> >> So you can still help us on that!!!
>>
>> >> By the way, if you got those data let us ask some more specific information.
>>
>> > Note, I don't have any information on tv-out other than I can shake
>> > out of my own card myself ;o)
>>
>> > Now, fighting with it during this weekend gave the following piece
>> > of knowledge: http://zhubr.tamb.ru/v01.asm
>> > This is not just some stupid dump of video bios. Honest. This code
>> > is self-consistent in that is doesn't have any external _code_ refs
>> > and all of the procedures are (somehow) used.
>> > Still _data_ refs are not yet done and all "unknown". Those need
>> > much more efforts.
>>
>> > I suspect a lot of stuff is not strictly tv-out and can be simply
>> > removed. OTOH, there might be some power-on tv-related
>> > initialization needed, which is not there and it would probably
>> > be hard to locate.
>> > Anyway. Whoever might be interested / aware of, have a look and
>> > try to enjoy. Any enlightening ideas and expert comments are welcome.
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?  SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Gatos-devel mailing list
>> Gat...@li...
>> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>>


> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel

On Sat, 22 Nov 2003 10:54:14 -0500 (EST)
Vladimir Dergachev <vo...@mi...> wrote:

> 
> 
> On Fri, 21 Nov 2003, Kumasaka Yohsuke wrote:
> 
> > Hi all.
> >
> > I got a problem that seems to be in relation to ati.2.
> >
> > I'm trying to draw YUV (YUY2) picture with hardware YUV overlay by
> > using SDL. Problem is, with large size YUV picture, it couldn't
> > draw normally. I tried with four sizes; 400x300, 640x480, 800x600
> > and 1024x768, and following results.
> >
> > 400x300:   Normally drawn.
> > 640x480:   Normally drawn.
> > 800x600:   Left side of window (about 80%) is normally drawn.
> >            Right side of window (about 20%) is colorful noise (not static).
> > 1024x768:  Not normally drawn at all.
> >            Left side of window (about 70%) is vertical stripe of some colors.
> >            Right side of window (about 30%) is colorful noise (not static).
> >
> > I'm developping on XFree86 4.3.0 on Debian linux 3.0, chipset is
> > ATI RAGE XL and using ati.2 driver.
> 
> Your card cannot display large image sizes, I think the horizontal
> resolution is limited by 768. Also, for display, the entire picture is put
> into video memory and your card probably does not have enough of it.
> 

Thank you for your advice.

Since I couldn't read that RAGE XL's limitation from the spec, I confused
about the casue of problem. I tried with newly bought radeon 7500 video card,
it's successfully drawn.

Yohsuke Kumasaka

> I would not be surprised that the result of displaing 1024x768 image is a
> bug in the driver which ignores failure to allocate chunk of video memory.
> 
>                            best
> 
>                               Vladimir Dergachev
> 
> >
> > I found similar report in this ML (Help Xv and ATI Rage XL 2003-05-21 01:48),
> > but I couldn't found the solution.
> >
> > Anyone know how to fix this problem or have some info ?
> >
> > Best Regards,
> > Yohsuke Kumasaka
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Gatos-devel mailing list
> > Gat...@li...
> > https://lists.sourceforge.net/lists/listinfo/gatos-devel
> >
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
> 
> 

---
熊坂 洋輔  / 日本コントロールシステム（株）
E-mail: kum...@ni...
TEL: 045-477-5971 => 2020(内線)

On Tue 25 November 2003 03:57, Nikolai Zhubr wrote:
> Hi,
> Monday, 24 November, 2003, 18:31:32, Vladimir Dergachev wrote:
> [...]
>
> > Have you taken a look inside mach64 ati.2 driver ? There are
> > functions for accessing ImpactTV there.
>
> No actually...
> Well, looking into it right now, but yet I wouldn't say it
> explains something.
> However I've found a place where tv-out is quite definitely
> accessed in some way (can be seen on tv) so I just need some
> more tests to get the idea...
>
> sub_9429  proc    near
>           nop
>           push    eax
>           push    bx
>           mov     bx,0A0h  ; <<=3D=3D A0 looks like some index or
> register call    sub_922F ; <<=3D=3D this looks like "get dword" or =20
>    eax,1
>           and     eax,0FFFFFFF7h
>           call    sub_91C1 ; <<=3D=3D this looks like "put dword"
>           pop     bx
>           pop     eax
>           retn
> sub_9429  endp

Here's what I make of it:

--------------------
1EC7
=09Code:
=09=09t1 =3D dx
=09=09dx =3D get_register_base (1ED3)
=09=09dx +=3D t1
=09=09
=09Analysis:
=09=09Given a register offset, returns the absolute register by
=09=09adding the register base address.

9175
=09Code:
=09=09t1 =3D 0xEE
=09=09dx =3D get_register_address (1EC7)
=09=09t2 =3D read16 from port dx (register 0xEE)
=09=09write16 (t2 | 0x8000) to port dx (register 0xEE)
=09=09while ((read16 from port dx) & 0x4000)
=09=09=09wait
=09=09write16 (t2) to port dx
=09
=09Analysis:
=09=09Sets bit 15 in register 0xEE, then waits for bit 14 to become
=09=090. Then restores the original contents of 0xEE and exits. Wait
=09=09for something to finish? Looking at 91C1 and 922F, this seems
=09=09to wait for the chip being ready to receive or give the next
=09=09byte for multibyte registers accessed through a single-byte
=09=09channel.

918E
=09Code:
=09=09call wait_next_byte (9175)
=09=09t1 =3D 0x8CB0 (36016)
=09=09t2 =3D data_012C
=09=09if (t2:7..8 =3D=3D 10b)=09// mode select? see sub_5C16
=09=09=09t1 |=3D 2
=09=09dx =3D 0xEC
=09=09call get_register_address (1EC7)
=09=09write16 (t1) to port dx (register 0xEC)
=09=09dx +=3D 2 (now 0xEE)
=09=09write16 (0x8023) to port dx (register 0xEE)
=09=09dx =3D 0x0F
=09=09call get_register_address (1EC7)
=09=09write16 (0x8387) to port dx (register 0x0F)
=09
=09Analysis:
=09=09Waits for something to finish?, then writes values to registers
=09=090xEC, 0xEE and 0x0F. The value written to 0xEC depends on the
=09=09high field in data_012C, which seems to be a mode indentifier.
=09=09
91C1
=09Code:
=09=09clear interrupts
=09=09ecx =3D eax
=09=09t1 =3D read8 from register 0xC5
=09=09write8 (t1 & 0xBF) to register 0xC5=09// clear bit 6 of reg 0xC5
=09=09call 918E (set something)
=09=09
=09=09write8 (data_5BC7) to register 0xF4
=09=09write8 (bl) to register 0xF8
=09=09call wait_next_byte (9175)
=09=09write8 (bh) to register 0xF8
=09=09call wait_next_byte (9175)
=09=09
=09=09write8 (data_5BC8) to register 0xF4
=09=09write8 (cl) to register 0xF8
=09=09call wait_next_byte (9175)
=09=09write8 (ch) to register 0xF8
=09=09call wait_next_byte (9175)
=09=09
=09=09t1 >>=3D 16
=09=09
=09=09write8 (data_5BC8) to register 0xF4
=09=09write8 (cl) to register 0xF8
=09=09call wait_next_byte (9175)
=09=09write8 (ch) to register 0xF8
=09=09call wait_next_byte (9175)
=09
=09=09write8 (t1) to register 0xC5 =09=09// restore original value
=09
=09Analysis:
=09=09Perhaps 0xF4 is an index register, with 0xF8 being data register.
=09=09Maybe this is a gateway to another chip, or to another part of the
=09=09chip? ImpacTV?
=09=09
=09=09Index data_5BC7 is selected, and bx is written to it byte by byte.
=09=09Then index data_5BC8 is selected, and ECX is written to it byte by
=09=09byte. In between writing bytes, 9175 is called, so this routine
=09=09probably waits for the card to signal that it has read the byte
=09=09and is ready for the next byte. This seems to be a double layer of
=09=09index/data registers: 0xF4 and 0xF8 access the other chip, which
=09=09has an index register at data_5BC7 and a data register at
=09=09data_5BC8. bx is the register on the second chip that ecx is
=09=09written to.

922F
=09Code:
=09=09clear interrupts
=09=09t1 =3D read8 from register 0xC5
=09=09write8 (t1 & 0xBF) to register 0xC5=09// clear bit 6 of reg 0xC5
=09=09call 918E (set something)

=09=09write8 (data_5BC7) to register 0xF4
=09=09write8 (bl) to register 0xF8
=09=09call wait_next_byte (9175)
=09=09write8 (bh) to register 0xF8
=09=09call wait_next_byte (9175)
=09=09
=09=09write8 (data_5BC8) to register 0xF4
=09=09set bit 10 of register 0xEE=09=09=09// ??
=09=09call wait_next_byte (9175)
=09=09
=09=09al =3D read8 from register 0xF8
=09=09call 9317
=09=09//=09if (data_0172 =3D=3D 0x50) al ^=3D 0x81=09// toggle bits 0 and=
 7
=09=09
=09=09call wait_next_byte (9175)
=09=09al =3D read8 from register 0xF8
=09=09
=09=09call 9317=20
=09=09//=09if (data_0172 =3D=3D 0x50) al ^=3D 0x81=09// toggle bits 0 and=
 7

=09=09bh =3D al
=09=09call wait_next_byte (9175)
=09=09al =3D read8 from register 0xF8
=09=09
=09=09call 9317
=09=09//=09if (data_0172 =3D=3D 0x50) al ^=3D 0x81=09// toggle bits 0 and=
 7
=09=09
=09=09cl =3D al
=09=09call wait_next_byte (9175)

=09=09clear bit 10 of register 0xEE=09=09=09// ??

=09=09al =3D read8 from register 0xF8
=09=09call 9317
=09=09//=09if (data_0172 =3D=3D 0x50) al ^=3D 0x81=09// toggle bits 0 and=
 7
=09=09
=09=09ch =3D al
=09=09
=09=09write (t1) to register 0xC5
=09=09
=09=09return eax =3D cx:bx
=09=09
=09Analysis:
=09=09Seems to be the reverse of 91C1. Reads a dword. Note the odd
=09=09fiddling of register 0xEE in the middle, 91C1 doesn't have this.

9429
=09Code:
=09=09bx =3D 0xA0
=09=09eax =3D call impactv_get_dword (922F)
=09=09set eax:0
=09=09clear eax:3
=09=09call impactv_put_dword (91C1)
=09=09
=09Analysis:
=09=09Selects a mode on the impactv chip or tv-out section of the rage
=09=09lt?
--------------------

I'm not sure whether this actually accesses the ImpacTV chip or a=20
TV-out portion of the Rage LT chip, or maybe even the RAMDAC, so=20
the impactv_get_dword and impactv_put_dword names are heavy=20
guesswork. 922F has some weird things going on there...

I had a brief look at the TV-out code in CVS, but couldn't at first=20
glance correlate anything. I'm wondering about this VIP bus though,=20
Rage Theatre is on it, perhaps registers 0xF4 and 0xF8 address the=20
VIP bus? Then data_5BC7 would hold the address of the index=20
register of the tv-out chip, which is written to 0xF4, and then the=20
register on the tv-out chip is written from bx through 0xF8 to the=20
index register of the tv-out chip. And then data_5BC8 holds the=20
address of the data register of the tv-out chip, which is selected=20
on register 0xF4, and then the data is written to 0xF8 or read from=20
0xF8.

How different are Radeon AIW and Rage LT Pro?

Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key

On Nov 18, Lourens Veen <lo...@ra...> wrote:
> > On Nov 2, Markus Gaugusch <ma...@ga...> wrote:
> > > Hi, I have a Sony Vaio FX laptop with integrated ATI
> > > Mach64/Mobility M1. Everything works fine (ati.2 driver, no
> > > DRI), but I'd like to get a dual head configuration working. I
> > > tried the following, but it returns with an error message. The
> > > snippet is from some other mailinglist archive and works with
> > > matrox cards.
>
> Are you sure that the hardware supports this? I don't think I've seen a
> laptop that could do dualhead LCD/external yet...not that I'm an expert
> on laptops mind you, but I wonder.
I've tried this setup under Windows. Apart from too little VGA memory for
external 1280x1024 (maybe there is too much reserve for 3D, don't know,
but 1024@16bpp worked), it works. Is there anyone motivated to include
support? :)

Markus
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
ma...@ga...     X     Against HTML Mail
                      / \

On Tue 25 November 2003 04:06, Nikolai Zhubr wrote:
> Lourens,
> thanks for analysis, actually I think I've found some "critical"
> code pattern and most of the code in v01.asm is not necessary. So
> please wait until I remove some stuff... :)

Okay. It could still be useful I guess, I don't know if there is=20
already a card register base address detection routine for=20
example...perhaps the one in the BIOS is better?

Note that I don't know anything about these cards, nor have I looked=20
at the Gatos source :-). I've just been reading the mailinglist for=20
a while.

Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key

On Tue 25 November 2003 03:30, Nikolai Zhubr wrote:
> Hi,
>
> Monday, 24 November, 2003, 15:02:30, Lourens Veen wrote:
> > On Mon 24 November 2003 12:41, Nikolai Zhubr wrote:
> >> Hi,
> >> P.S., I'd be happy if someone look through and try to find
> >> some code pattern(s) relevant to accessing ImpacTV. Or to
> >> guess at least :) And yes, it is all intel-style asm, sorry,
> >> that is what disasm able to produce, anyway I'm not so good
> >> reading AT&T one (Should be converted to C as soon as it
> >> works)
> >
> > I'm wondering about the mix of 16-bit and 32-bit instructions.
> > Are you sure this is correct?
>
> Absolutely. Any 386 instruction may have some magic prefix to
> force it be 16-bit or 32-bit. Typically 386 assemblers consider
> operands' sizes and insert prefixes automatically.

I knew that, but what I failed to realise was that x86 CPUs start in=20
real mode, so that the BIOS runs in 16-bit mode. Hence it uses 16=20
bit code with some 32 bit instructions here and there, instead of=20
all 32 bit instructions.

Thanks,

Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key

Lourens,
thanks for analysis, actually I think I've found some "critical"
code pattern and most of the code in v01.asm is not necessary. So
please wait until I remove some stuff... :)
-- 
Best regards,
 Nikolai Zhubr

Tuesday, 25 November, 2003, 0:27:06, Lourens Veen wrote:
> On Mon 24 November 2003 00:52, Nikolai Zhubr wrote:
>> Hi,
>>
>> Saturday, 22 November, 2003, 8:20:28, dashken wrote:
>> > It should use ImpactTV2 but its embedded into the chip already.
>> >
>> > So you can still help us on that!!!
>> >
>> > By the way, if you got those data let us ask some more specific
>> > information.
>>
>> Note, I don't have any information on tv-out other than I can
>> shake out of my own card myself ;o)
>>
>> Now, fighting with it during this weekend gave the following
>> piece of knowledge: http://zhubr.tamb.ru/v01.asm
>> This is not just some stupid dump of video bios. Honest. This
>> code is self-consistent in that is doesn't have any external
>> _code_ refs and all of the procedures are (somehow) used.
>> Still _data_ refs are not yet done and all "unknown". Those need
>> much more efforts.
>>
>> I suspect a lot of stuff is not strictly tv-out and can be simply
>> removed. OTOH, there might be some power-on tv-related
>> initialization needed, which is not there and it would probably
>> be hard to locate.
>> Anyway. Whoever might be interested / aware of, have a look and
>> try to enjoy. Any enlightening ideas and expert comments are
>> welcome.

> Well, I wouldn't consider myself an expert, but I used to program 
> VGA cards in Turbo Pascal and inline assembler back in the DOS 
> days, and seeing all this assembly made me want to see how much I 
> remembered. So I had a go at it. I started out by finding out who 
> calls who in this code (hint: cat v01.asm |grep -e 
> "^sub_\|---\|call" filter out all but proc headings and calls), and 
> then proceeded to take the leaf procs in the call tree (ie those 
> that don't call anyone else), decompile them into pseudocode and 
> try and figure out what they do. Note that not all are actually 
> real procs (which save registers and stuff), it seems that the 
> compiler was set to optimise for size, and it either didn't inline 
> some inline functions, or it factored out common code.

> The calling convention seems to pass arguments in registers as much 
> as possible, and return values in ax or al. Some routines do it 
> differently though, for example the card base address detection 
> function which returns the result in dx. Odd.

> sub_19EA is weird, it seems to write 30 zero bytes to the base of 
> the stack, however, the direction flag is not set, so it is unclear 
> whether the bottom part of the stack is overwritten, or it it 
> writing above the top of the stack (stack grows downward on x86).

> The rest seems to be utility functions, and card detection routines. 
> More details in my notes below:

> ----------------------------------------
> Subroutines that don't call anything else:

> 077D
>         expr(if (bx < 11800) (bx == 0) else (bx == 23600))

> 19EA
>         write 30 zero bytes to stack base (??)

> 1ED3
>         Code:
>                 if (data_0116 == 0)
>                         return dx = 0
>                 t1 = read16 from port hi8(data_0116) || 0x0E
>                 if (t1 == data_0172)
>                         return dx = hi8(data_0116)
>                 for (t2 = 0xFF; t2 > 0; t2--)
>                         t1 = read16 from port t2 << 8 || 0x0E
>                         if (t1 != data_0172)
>                                 continue
>                         t1 = read8 from port t2 << 8 || 0x84
>                         t1 = t1 * 128 + C000
>                         if (t1 == data_0134)
>                                 return dx = t2 << 8
>                 return dx = 0

>         Analysis:
>                 Detect card and return register file base address? Try to
>                 read register 0xE, then read register 0x84 and check its
>                 content against data_0134. Return the high byte of the
>                 working address range. This makes data_0116 a cache or
>                 initial base address value that is tested first.

> 4BA8
>         return bx = data_4BB2[bx & 0xFF - 1]
        
> 4BB8
>         return cl = max(1, position of highest 1 bit in ax)

> 4C61
>         Code:
>                 bx = 1600 * (bx & 0xFF)
>                 ax = 5900 * ax * 64 
>                 ax = ax / bx
>                 dx = ax % bx
                
> 50BB
>         Code:
>                 al = 0

>         Analysis:
>                 Clear equals flag? Set zero flag?

> 50FB
>         Code:
>                 ax += 99
>                 al = ax / 100
>                 ah = ax % 100

>         Analysis:
>                 Divide ax by 100, round up? Decimal fixed point? Clock rate
>                 calculation perhaps?

> 5708
>         return al = read8 from port dx

> 5BE6
>         expr(data_BD03 != 84)

> 5C16
>         Code:
>                 if (((data_012C & 0xC0) == 0x40) ||
>                     ((data_012C & 0x0F) == 0) ||
>                     ((data_012C & 0x0F) == 4) ||
>                     (data_5BC9 == 26))
>                         return al = 0
>                 if ((data_012C & 0x0F) == 1)
>                         return al = 1
>                 if ((data_012C & 0x0F) == 3)
>                         return al = 3
>                 if (((data_012C & 0xC0) == 0x80) ||
>                     ((data_012C & 0x0F) != 2))
>                         return al = (data_012C & 0x0F)
>                 return al = 0
                        
>         Analysis:
>                 Seems like there are two fields in data_012C, one at bits
>                 6 and 7, and one at bits 0..3. The high field seems to
>                 have either one of its bits set, but not both. Some sort
>                 of mode select? The value of the low bits is returned if
>                 it is not 2 or 4, or if the high bits are 10, otherwise
>                 0 is returned.

> 5C4E
>         al = (data_012C & 0xC0) >> 6    // selects high field, see above

> 5EC8
>         bx = ax = 0x5EBO // = 24240

> 6234
>         Code:
>                 t1 = read8 from port 0x3CC (EGA graphics 1 pos)
>                 if (t1 & 1)
>                         return dl = 0xD4
>                 else
>                         return dl = 0xB4

>         Analysis:
>                 According to http://chipdir.stts.edu/reg/vga.txt, this
>                 returns 0xD4 if the crtc index register is 0x3D4, or
>                 0xB4 if it is 0x3B4. Note that the associated data
>                 register is at 0x3D5 or 0x3B5 respectively.

> 9317
>         if (data_0172 == 0x50)  // == 80
>                 al ^= 0x81      // flip highest and lowest bit

> 9663
>         ax = 0

> A5E8
>         Code:
>                 t1 = read8 from port 0x3C4
>                 write8 1 to port 0x3C4
>                 t2 = read8 from port 0x3C5
>                 write8 t1 to port 0x3C4
>                 return (t2 & 1)

>         Analysis:
>                 This reads the VGA clock mode register and sets the equal
>                 flag if 8/9 dot clocks mode is selected. Test for grayscale
>                 mode???

> A5FE
>         Code:
>                 t1 = read8 from port 0x3C4
>                 write8 1 to port 0x3C4
>                 t2 = read8 from port 0x3C5
>                 write8 t1 to port 0x3C4
>                 return (t2 & 8)

>         Analysis:
>                 This read the VGA clock mode register and sets the equal
>                 flag if 40/80 column mode is selected. Test for textmode???

> B481
>         Code:
>                 t1 = data_B4BA[ax:4..7, bx:0..2]
>                 ax = ax:4..7 - t1:0..3
>                 return ax = ((ax << 4) | t1:0..3) << t1:4..5
                
>         Analysis:
>                 Reads a byte (4 significant bits) value from a 16x8 table
>                 at data_B4BA, then subtracts that value from the high
>                 nibble of ax, and overwrites the low nibble of ax with it.

> B552
>         TODO


> I'll probably be busy the rest of the week, but I hope to work on it 
> some more in the near future.
 
> Lourens

Hi,
Monday, 24 November, 2003, 15:02:30, Lourens Veen wrote:
> On Mon 24 November 2003 12:41, Nikolai Zhubr wrote:
>> Hi,
>> P.S., I'd be happy if someone look through and try to find
>> some code pattern(s) relevant to accessing ImpacTV. Or to
>> guess at least :) And yes, it is all intel-style asm, sorry,
>> that is what disasm able to produce, anyway I'm not so good
>> reading AT&T one (Should be converted to C as soon as it works)

> I'm wondering about the mix of 16-bit and 32-bit instructions. Are 
> you sure this is correct?
Absolutely. Any 386 instruction may have some magic prefix to
force it be 16-bit or 32-bit. Typically 386 assemblers consider
operands' sizes and insert prefixes automatically.
-- 
Best regards,
 Nikolai Zhubr

> Lourens

Hi,
Monday, 24 November, 2003, 18:31:32, Vladimir Dergachev wrote:
[...]
> Have you taken a look inside mach64 ati.2 driver ? There are functions for
> accessing ImpactTV there.
No actually...
Well, looking into it right now, but yet I wouldn't say it
explains something.
However I've found a place where tv-out is quite definitely
accessed in some way (can be seen on tv) so I just need some
more tests to get the idea...

sub_9429  proc    near
          nop
          push    eax
          push    bx
          mov     bx,0A0h  ; <<== A0 looks like some index or register
          call    sub_922F ; <<== this looks like "get dword"
          or      eax,1
          and     eax,0FFFFFFF7h
          call    sub_91C1 ; <<== this looks like "put dword"
          pop     bx
          pop     eax
          retn
sub_9429  endp
-- 
Best regards,
 Nikolai Zhubr

>                       best

>                         Vladimir Dergachev

>> --
>> Best regards,
>>  Nikolai Zhubr
>>
>> Monday, 24 November, 2003, 2:52:07, Nikolai Zhubr wrote:
>> > Hi,
>> > Saturday, 22 November, 2003, 8:20:28, dashken wrote:
>> >> It should use ImpactTV2 but its embedded into the chip already.
>>
>> >> So you can still help us on that!!!
>>
>> >> By the way, if you got those data let us ask some more specific information.
>>
>> > Note, I don't have any information on tv-out other than I can shake
>> > out of my own card myself ;o)
>>
>> > Now, fighting with it during this weekend gave the following piece
>> > of knowledge: http://zhubr.tamb.ru/v01.asm
>> > This is not just some stupid dump of video bios. Honest. This code
>> > is self-consistent in that is doesn't have any external _code_ refs
>> > and all of the procedures are (somehow) used.
>> > Still _data_ refs are not yet done and all "unknown". Those need
>> > much more efforts.
>>
>> > I suspect a lot of stuff is not strictly tv-out and can be simply
>> > removed. OTOH, there might be some power-on tv-related
>> > initialization needed, which is not there and it would probably
>> > be hard to locate.
>> > Anyway. Whoever might be interested / aware of, have a look and
>> > try to enjoy. Any enlightening ideas and expert comments are welcome.
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?  SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Gatos-devel mailing list
>> Gat...@li...
>> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>>


> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel

On Mon 24 November 2003 00:52, Nikolai Zhubr wrote:
> Hi,
>
> Saturday, 22 November, 2003, 8:20:28, dashken wrote:
> > It should use ImpactTV2 but its embedded into the chip already.
> >
> > So you can still help us on that!!!
> >
> > By the way, if you got those data let us ask some more specific
> > information.
>
> Note, I don't have any information on tv-out other than I can
> shake out of my own card myself ;o)
>
> Now, fighting with it during this weekend gave the following
> piece of knowledge: http://zhubr.tamb.ru/v01.asm
> This is not just some stupid dump of video bios. Honest. This
> code is self-consistent in that is doesn't have any external
> _code_ refs and all of the procedures are (somehow) used.
> Still _data_ refs are not yet done and all "unknown". Those need
> much more efforts.
>
> I suspect a lot of stuff is not strictly tv-out and can be simply
> removed. OTOH, there might be some power-on tv-related
> initialization needed, which is not there and it would probably
> be hard to locate.
> Anyway. Whoever might be interested / aware of, have a look and
> try to enjoy. Any enlightening ideas and expert comments are
> welcome.

Well, I wouldn't consider myself an expert, but I used to program=20
VGA cards in Turbo Pascal and inline assembler back in the DOS=20
days, and seeing all this assembly made me want to see how much I=20
remembered. So I had a go at it. I started out by finding out who=20
calls who in this code (hint: cat v01.asm |grep -e=20
"^sub_\|---\|call" filter out all but proc headings and calls), and=20
then proceeded to take the leaf procs in the call tree (ie those=20
that don't call anyone else), decompile them into pseudocode and=20
try and figure out what they do. Note that not all are actually=20
real procs (which save registers and stuff), it seems that the=20
compiler was set to optimise for size, and it either didn't inline=20
some inline functions, or it factored out common code.

The calling convention seems to pass arguments in registers as much=20
as possible, and return values in ax or al. Some routines do it=20
differently though, for example the card base address detection=20
function which returns the result in dx. Odd.

sub_19EA is weird, it seems to write 30 zero bytes to the base of=20
the stack, however, the direction flag is not set, so it is unclear=20
whether the bottom part of the stack is overwritten, or it it=20
writing above the top of the stack (stack grows downward on x86).

The rest seems to be utility functions, and card detection routines.=20
More details in my notes below:

----------------------------------------
Subroutines that don't call anything else:

077D
=09expr(if (bx < 11800) (bx =3D=3D 0) else (bx =3D=3D 23600))

19EA
=09write 30 zero bytes to stack base (??)

1ED3
=09Code:
=09=09if (data_0116 =3D=3D 0)
=09=09=09return dx =3D 0
=09=09t1 =3D read16 from port hi8(data_0116) || 0x0E
=09=09if (t1 =3D=3D data_0172)
=09=09=09return dx =3D hi8(data_0116)
=09=09for (t2 =3D 0xFF; t2 > 0; t2--)
=09=09=09t1 =3D read16 from port t2 << 8 || 0x0E
=09=09=09if (t1 !=3D data_0172)
=09=09=09=09continue
=09=09=09t1 =3D read8 from port t2 << 8 || 0x84
=09=09=09t1 =3D t1 * 128 + C000
=09=09=09if (t1 =3D=3D data_0134)
=09=09=09=09return dx =3D t2 << 8
=09=09return dx =3D 0

=09Analysis:
=09=09Detect card and return register file base address? Try to
=09=09read register 0xE, then read register 0x84 and check its
=09=09content against data_0134. Return the high byte of the
=09=09working address range. This makes data_0116 a cache or
=09=09initial base address value that is tested first.

4BA8
=09return bx =3D data_4BB2[bx & 0xFF - 1]
=09
4BB8
=09return cl =3D max(1, position of highest 1 bit in ax)

4C61
=09Code:
=09=09bx =3D 1600 * (bx & 0xFF)
=09=09ax =3D 5900 * ax * 64=20
=09=09ax =3D ax / bx
=09=09dx =3D ax % bx
=09=09
50BB
=09Code:
=09=09al =3D 0

=09Analysis:
=09=09Clear equals flag? Set zero flag?

50FB
=09Code:
=09=09ax +=3D 99
=09=09al =3D ax / 100
=09=09ah =3D ax % 100

=09Analysis:
=09=09Divide ax by 100, round up? Decimal fixed point? Clock rate
=09=09calculation perhaps?

5708
=09return al =3D read8 from port dx

5BE6
=09expr(data_BD03 !=3D 84)

5C16
=09Code:
=09=09if (((data_012C & 0xC0) =3D=3D 0x40) ||
=09=09    ((data_012C & 0x0F) =3D=3D 0) ||
=09=09    ((data_012C & 0x0F) =3D=3D 4) ||
=09=09    (data_5BC9 =3D=3D 26))
=09=09=09return al =3D 0
=09=09if ((data_012C & 0x0F) =3D=3D 1)
=09=09=09return al =3D 1
=09=09if ((data_012C & 0x0F) =3D=3D 3)
=09=09=09return al =3D 3
=09=09if (((data_012C & 0xC0) =3D=3D 0x80) ||
=09=09    ((data_012C & 0x0F) !=3D 2))
=09=09=09return al =3D (data_012C & 0x0F)
=09=09return al =3D 0
=09=09=09
=09Analysis:
=09=09Seems like there are two fields in data_012C, one at bits
=09=096 and 7, and one at bits 0..3. The high field seems to
=09=09have either one of its bits set, but not both. Some sort
=09=09of mode select? The value of the low bits is returned if
=09=09it is not 2 or 4, or if the high bits are 10, otherwise
=09=090 is returned.

5C4E
=09al =3D (data_012C & 0xC0) >> 6=09// selects high field, see above

5EC8
=09bx =3D ax =3D 0x5EBO // =3D 24240

6234
=09Code:
=09=09t1 =3D read8 from port 0x3CC (EGA graphics 1 pos)
=09=09if (t1 & 1)
=09=09=09return dl =3D 0xD4
=09=09else
=09=09=09return dl =3D 0xB4

=09Analysis:
=09=09According to http://chipdir.stts.edu/reg/vga.txt, this
=09=09returns 0xD4 if the crtc index register is 0x3D4, or
=09=090xB4 if it is 0x3B4. Note that the associated data
=09=09register is at 0x3D5 or 0x3B5 respectively.

9317
=09if (data_0172 =3D=3D 0x50)=09// =3D=3D 80
=09=09al ^=3D 0x81=09// flip highest and lowest bit

9663
=09ax =3D 0

A5E8
=09Code:
=09=09t1 =3D read8 from port 0x3C4
=09=09write8 1 to port 0x3C4
=09=09t2 =3D read8 from port 0x3C5
=09=09write8 t1 to port 0x3C4
=09=09return (t2 & 1)

=09Analysis:
=09=09This reads the VGA clock mode register and sets the equal
=09=09flag if 8/9 dot clocks mode is selected. Test for grayscale
=09=09mode???

A5FE
=09Code:
=09=09t1 =3D read8 from port 0x3C4
=09=09write8 1 to port 0x3C4
=09=09t2 =3D read8 from port 0x3C5
=09=09write8 t1 to port 0x3C4
=09=09return (t2 & 8)

=09Analysis:
=09=09This read the VGA clock mode register and sets the equal
=09=09flag if 40/80 column mode is selected. Test for textmode???

B481
=09Code:
=09=09t1 =3D data_B4BA[ax:4..7, bx:0..2]
=09=09ax =3D ax:4..7 - t1:0..3
=09=09return ax =3D ((ax << 4) | t1:0..3) << t1:4..5
=09=09
=09Analysis:
=09=09Reads a byte (4 significant bits) value from a 16x8 table
=09=09at data_B4BA, then subtracts that value from the high
=09=09nibble of ax, and overwrites the low nibble of ax with it.

B552
=09TODO


I'll probably be busy the rest of the week, but I hope to work on it=20
some more in the near future.
=20
Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key

On Mon, 24 Nov 2003, Alessio Dessi wrote:

> Hi i'd like to know if this ATI card is supported
>
> ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE

Does your card have TV-in ? If you are trying to do TV-out then you need
to compile the driver yourself.

                           best

                             Vladimir Dergachev

>
>
> I'm running debian unstable and i've installed gatos and avview packages
> , rebooting I can see the console messages on the TV but when X start
> nothing more
>
> dunno if this is a problem of refresh rate or something else
>
> any suggestion to get my tvout working?
>
> thanks in advance
>
> Alessio
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>

Hi i'd like to know if this ATI card is supported

ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE


I'm running debian unstable and i've installed gatos and avview packages
, rebooting I can see the console messages on the TV but when X start
nothing more 

dunno if this is a problem of refresh rate or something else 

any suggestion to get my tvout working?

thanks in advance

Alessio

On Mon, 24 Nov 2003, Nikolai Zhubr wrote:

> Hi,
> P.S., I'd be happy if someone look through and try to find
> some code pattern(s) relevant to accessing ImpacTV. Or to
> guess at least :) And yes, it is all intel-style asm, sorry,
> that is what disasm able to produce, anyway I'm not so good
> reading AT&T one (Should be converted to C as soon as it works)

Have you taken a look inside mach64 ati.2 driver ? There are functions for
accessing ImpactTV there.

                      best

                        Vladimir Dergachev

> --
> Best regards,
>  Nikolai Zhubr
>
> Monday, 24 November, 2003, 2:52:07, Nikolai Zhubr wrote:
> > Hi,
> > Saturday, 22 November, 2003, 8:20:28, dashken wrote:
> >> It should use ImpactTV2 but its embedded into the chip already.
>
> >> So you can still help us on that!!!
>
> >> By the way, if you got those data let us ask some more specific information.
>
> > Note, I don't have any information on tv-out other than I can shake
> > out of my own card myself ;o)
>
> > Now, fighting with it during this weekend gave the following piece
> > of knowledge: http://zhubr.tamb.ru/v01.asm
> > This is not just some stupid dump of video bios. Honest. This code
> > is self-consistent in that is doesn't have any external _code_ refs
> > and all of the procedures are (somehow) used.
> > Still _data_ refs are not yet done and all "unknown". Those need
> > much more efforts.
>
> > I suspect a lot of stuff is not strictly tv-out and can be simply
> > removed. OTOH, there might be some power-on tv-related
> > initialization needed, which is not there and it would probably
> > be hard to locate.
> > Anyway. Whoever might be interested / aware of, have a look and
> > try to enjoy. Any enlightening ideas and expert comments are welcome.
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>

Hi i'd like to know if this ATI card is supported

ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE


I'm running debian unstable and i've installed gatos and avview packages
, rebooting I can see the console messages on the TV but when X start
nothing more 

dunno if this is a problem of refresh rate or something else 

any suggestion to get my tvout working?

thanks in advance

Alessio

On Sun, 2003-11-23 at 04:11, Vladimir Dergachev wrote:=20
> On Sat, 22 Nov 2003, Michel [ISO-8859-1] Dnzer wrote:
>=20
> > > However, it appears that XFree86 is in feature freeze for 4.4.0 (sinc=
e
> > > yesterday), which implies that I'll try to switch to 4.4.0 as soon as=
 I
> > > get some free time.
> >
> > Note that this won't be in 4.4.0.
>=20
> Really ?=20

Yes, the feature freeze has already been in effect since October.

> We only need the DRM and DRI .so drivers.

The current .so drivers from DRI CVS should work with GATOS; the same
may even be true for the DRM, but I'm not sure.


> Are there some sort of packaged releases of DRI one can work against ?
> I don't mind installing from CVS myself, but if GATOS ati.2 source is
> against DRI tree I don't want to have to package binaries for the entire
> DRI tree.

If you base GATOS on the DRI tree after 4.4.0 is merged in, it should
work on top of stock 4.4.


--=20
Earthling Michel D=C3=A4nzer      |     Debian (powerpc), X and DRI develop=
er
Software libre enthusiast    |   http://svcs.affero.net/rm.php?r=3Ddaenzer

On Mon 24 November 2003 12:41, Nikolai Zhubr wrote:
> Hi,
> P.S., I'd be happy if someone look through and try to find
> some code pattern(s) relevant to accessing ImpacTV. Or to
> guess at least :) And yes, it is all intel-style asm, sorry,
> that is what disasm able to produce, anyway I'm not so good
> reading AT&T one (Should be converted to C as soon as it works)

I'm wondering about the mix of 16-bit and 32-bit instructions. Are=20
you sure this is correct?

Lourens
--=20
GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key

Hi,
P.S., I'd be happy if someone look through and try to find
some code pattern(s) relevant to accessing ImpacTV. Or to
guess at least :) And yes, it is all intel-style asm, sorry,
that is what disasm able to produce, anyway I'm not so good
reading AT&T one (Should be converted to C as soon as it works)
-- 
Best regards,
 Nikolai Zhubr

Monday, 24 November, 2003, 2:52:07, Nikolai Zhubr wrote:
> Hi,
> Saturday, 22 November, 2003, 8:20:28, dashken wrote:
>> It should use ImpactTV2 but its embedded into the chip already.

>> So you can still help us on that!!!

>> By the way, if you got those data let us ask some more specific information.

> Note, I don't have any information on tv-out other than I can shake
> out of my own card myself ;o)

> Now, fighting with it during this weekend gave the following piece
> of knowledge: http://zhubr.tamb.ru/v01.asm
> This is not just some stupid dump of video bios. Honest. This code
> is self-consistent in that is doesn't have any external _code_ refs
> and all of the procedures are (somehow) used.
> Still _data_ refs are not yet done and all "unknown". Those need
> much more efforts.

> I suspect a lot of stuff is not strictly tv-out and can be simply
> removed. OTOH, there might be some power-on tv-related
> initialization needed, which is not there and it would probably
> be hard to locate.
> Anyway. Whoever might be interested / aware of, have a look and
> try to enjoy. Any enlightening ideas and expert comments are welcome.