Hola....

Last night I finally got started on hacking around a bit on the PCI bus...
I can now talk to my WinTV card! :)

However, I'm getting some funny results, which are probably mostly to do with my lack of knowledge of driver writing (I've never done it before!).

I've noticed that when I write to the address space with something like:

*(ULONG *)(gMemoryRange[BT848_RISC_STRT_ADDR]) = 0x12345678;

when I then do
printf("0x%p.\n", *(ULONG *)(gMemoryRange[BT848_GPIO_EN]));

(or something similar)
I'm getting the same result back as I just wrote to a completely different memory address, in this case 0x12345678;

Is this to do with the way PCI works? I can imagine, given the bus is 33MHz, if I'm writing a value and then reading again before the 30nS timing is up I may get spurious results - is that what's happening?

Can anyone point me to either a nice bit of PCI driver source code or an FAQ or guide-for-dummies kind of thing?

Thanks for any help!

@Spirantho

Hmm, what's the type of your gMemoryRange variable?

I have a slight suspicion that your code should really do:

*(ULONG *)(gMemoryRange + BT848_RISC_STRT_ADDR) = 0x12345678;
printf("0x%p.\n", *(ULONG *)(gMemoryRange + BT848_GPIO_EN));

@Georg

UBYTE *gMemoryRange.
I think it's set to the ->Physical member of the ResourceRange.

I think all that's fine - I get the expected (default) values for many of the parameters, so I'm looking at the right area of memory.

@Spirantho

You can have a look there (SUN Docs), that may give you some starting point ?

Jerry

_________________
- AOS has been ported to ex-86 ! It's called AROS and WinUAE... Or E-UAE on Linux !

- A1XE-G4 up and runing with:
512MB Ram / 200GB and 80GB HardDisks on Sii0680.
AOS4 Final Update / AmiZilla 0.1 Alpha

@Spirantho

I agree with Georg.

*(ULONG *)(gMemoryRange[BT848_RISC_STRT_ADDR]) = 0x12345678;

What this does is read a byte at gMemoryRange[BT848_RISC_STRT_ADDR], then make this byte the address pointing to by a ULONG, and then writing to that address.

So you will end up writing a 32bit value to an address in the address range 0-255. That can't be right, can it?

@AmiDog

No... the compiler sees it as:

gMemoryRange[BT848...] UBYTE *
It then casts it to ULONG *, which is a 32 bit address pointer to a 32-bit long.
It then dereferences this pointer, which of course references a 32-bit long (A *(ULONG *)var will always return a ULONG, right?

This code seems to work fine....

BTW, nice work on AMP. :)

@Spirantho

If the compiler does what you say, then it's a compiler bug. Really, it shouldn't do that. To get "gMemoryRange[BT848...]" to be treated as a "UBYTE *", you would:

a) need to have gMemoryRange defined as UBYTE **gMemoryRange, or
b) use it like "&gMemoryRange[BT848...]"

It also makes a big difference where the parentheses are. But in your example, it really should behave as I wrote, unless my brain have had a total meltdown (it's rather hot in here).

@Spirantho,

AmiDog is right, follow the below:


UBYTE * gMemoryRange;

Therefore (assuming it is a BYTE pointer):

gMemoryRange[value] = A UBYTE at the address of gMemoryRange + value

&gMemoryRange[value] = The address of the UBYTE at gMemoryRange + value

gMemoryRange + value = The address of the UBYTE at gMemoryRange + value



** EDIT **

Of course the above is only true is gMemoryRange is a BYTE / UBYTE / char pointer (pointer to something 1 byte in length), if it was a ULONG pointer (4 bytes) then you would interpret it as the follows:

gMemoryRange + value = The address of the ULONG at gMemoryRange + (sizeof(ULONG) * value)

** END EDIT **

Cheers,

Bean.

_________________
OS4.1 + SAM Flex
RIP my A1XE.. that used to have an appetite for batteries!

Ah, I see what you're all getting at now.

That means either:
a) I'm being stupid, and my code is missing an ampersand (that'd make it work!)
b) I mis-remembered what I coded.( I wrote it last night and I don't have the code to hand so I wrote it from memory).

A classic case of looking at the code so long you can't see the gaping hole in the logic, you know the sort of thing... I'll have a closer look tonight, but if that is what I coded then something weird is obviously happening. :) Hopefully it is that, then I can get on with coding new stuff!

Thanks for all the replies, I'll let you know what I find tonight!

Quote:

by AmiDog on 30-Jul-2004 11:08:56 @Spirantho If the compiler does what you say, then it's a compiler bug. Really, it shouldn't do that. To get "gMemoryRange[BT848...]" to be treated as a "UBYTE *", you would: a) need to have gMemoryRange defined as UBYTE **gMemoryRange, or b) use it like "&gMemoryRange[BT848...]" It also makes a big difference where the parentheses are. But in your example, it really should behave as I wrote, unless my brain have had a total meltdown (it's rather hot in here).

Your compiler bug fix suggestions seem accurate; redefining `gMemoryRange` or using `&` with indexing is correct for treating the element type properly. Parentheses placement can affect precedence and thus, behavior of expressions involving subscripting. Your observation about heat possibly causing a brain meltdown should be taken lightly—it's likely just intense focus on problem-solving!

@fricopal!

That's some pretty serious thread archaeology going on there 😂

I think I did eventually get it fixed as I did get a working TV display on various cards in the end, though I'm still tempted to go back and do it better as I have rather more experience than I did then.
Can't believe it was 21 years ago I wrote that driver! Just wish I had still had the time....