Forums - All Posts - The Amigans website

Forum Index

Board index » All Posts (Spirantho)

Bottom

« 1 ... 22 23 24 (25) 26 »

Spirantho

Re: DMAing between PCI cards

Posted on: 2007/8/13 19:00 #481

Quite a regular

@Rogue

Quote:

Does the chip not support a scatter/gather list?

Have you looked at the PCI device, whether it has a PCI pin and line assigned?

To be honest I'm not exactly sure, as my knowledge of such things is rather limited (this is the first proper driver I've written, after all). I do know that I can program exactly where I want each pixel to be put in memory, though, which is how I'm working round the lack of a contiguous lump of memory.

As for the PCI pin and line... how can I tell for sure if it's assigned? Certainly the code which worked on the Bt8x8 chipset doesn't work on the Cx2388x chipset even though they're practically the same hardware. How can you diagnose these problems?

Sorry for so many questions, I'm a bit in the dark here but there's not very much documentation on writing device drivers under AmigaOS 4 (not surprisingly given how you're too busy writing the OS itself!)

Thanks again!

--
Ian Gledhill
ian.gledhill@btinternit.com (except it should be internEt of course...!)
Check out my company's shop: http://www.mutant-caterpillar.co.uk/shop/ - specialising in Sinclair Spectrums but will be adding Amigas!

Topic | Forum

Spirantho

Re: Techie questions regarding the nuw Amiga OS4 update

Posted on: 2007/8/13 18:04 #482

Quite a regular

@Hans

Quote:

Hans wrote:
@Spirantho

So large allocvec allocations might be fragmented physically in memory? I didn't realize that; although it's only important when you're writing a driver.

I think so. Certainly I know that if you do a StartDMA() on anything larger than a few KB then StartDMA() fails.

In the old SDK you could use AllocMem() with a "contiguous" tag, and then StartDMA would succeed on large blocks, but since AllocMem was deprecated in favour of AllocVecTags you can't do that any more and you can't ever do a StartDMA unless you happen to be dealing in a small enough chunk.

Topic | Forum

Spirantho

Re: Techie questions regarding the nuw Amiga OS4 update

Posted on: 2007/8/13 14:09 #483

Quite a regular

@Rogue

Quote:

Darn, I wasn't aware that AllocVecTags wasn't out there yet... that is indeed a problem.

Why d'you think I've been yelling so noisily about the lack of SDK since January? :)

It means that absolutely no way anyone outside of the people with the Beta SDK can allocate a contiguous chunk of memory - which isn't good for device drivers like I'm writing!

Topic | Forum

Spirantho

Re: DMAing between PCI cards

Posted on: 2007/8/13 14:07 #484

Quite a regular

@Rogue

Quote:

Rogue wrote:
@Spirantho

I am not aware that there should be any kind of problem with the DMA buffer size. For starters, 4k should be safe since that is the page size.

It's not a problem per se, it's just a side-effect of not being able to allocate contiguous blocks of memory. Once I can do that it should just work. I hope!

Quote:

Quote:
Now if I could just work out why the interrupt routine isn't being triggered even when the interrupt is being raised... but that's a different matter entirely I'll worry about when I've got things displaying again.

What machine is this card in? Does it have a bridge?

Bog standard A1XE G4@800. Interrupts worked fine when I was using the Bt8x8 chipset, but the CX2388x chipset raises the interrupt from what I can see but the interrupt routine never gets called. The registers on the Cx2388x say it's raised, I can read the interrupt register and it's triggered - it just never calls the routine. It may be a peculiarity of the Cx2388x chipset though.

Topic | Forum

Spirantho

Re: Techie questions regarding the nuw Amiga OS4 update

Posted on: 2007/8/13 12:22 #485

Quite a regular

@Rogue

Great, that'll help a lot. Debugging a library is very difficult without DebugPrintF!

Quote:

Rogue wrote:
@Spirantho
I am sorry for the delay of the SDK, but one major factor in this is a problem with binutils stripping too much for the shared object support, resulting in unusable binaries when you strip them.

Since my time is limited, and my knowledge of binutils is even more limited, this is dragging on. Just releasing the autodocs and includes will not do much good.

It's actually just the includes I need. I need to be able to allocate a contiguous lump of memory, approximately 432KB (768x576 - PAL resolution, in other words) and it's impossible without AllocVecTags(). The function's there in the library, I just can't use it without the correct include.

I've found a way of making it use one DMA chunk per line but that means 576 different DMA lists. Yummy. I think a contiguous lump would make life rather easier...

Quote:

(edit) I am not aware of any problem with DMA with buffers of more than 2k. As a matter of fact, I am very sure that the IDE devices use larger DMA transfers.

No, but they're using AllocVecTags() whereas I'm using AllocMem() and hoping for the best as there's no alternative!

Many thanks for your quick replies!

Topic | Forum

Spirantho

Re: DMAing between PCI cards

Posted on: 2007/8/13 12:16 #486

Quite a regular

@Rogue

Excellent... so I should just need to IMMU->GetPhysicalAddress( OverlayBitmapAddress ) or whatever, and then I should be able to StartDMA() on it?

Ironically enough had I been able to do that already I probably wouldn't be needing to wait for the updated SDK as the Framebuffer should be contiguous anyway.

In the meantime I'll just carry on what I'm doing at the moment (DMAing into main memory, then copying into frame buffer overlay memory). Or at least what I'm trying to do at the moment, albeit in 2K DMA chunks!

Now if I could just work out why the interrupt routine isn't being triggered even when the interrupt is being raised... but that's a different matter entirely I'll worry about when I've got things displaying again.

Topic | Forum

Spirantho

DMAing between PCI cards

Posted on: 2007/8/13 11:39 #487

Quite a regular

Hi everybody,

One of the things about doing WinTV card development is that I need to find the best speed, and I think that the usual way is for the WinTV card (which is a BusMastering card) to dump its output straight into the graphics card memory.

How can you go about doing this?
I've created an overlay surface and got the address of the bitmap associated with it. When I tried to StartDMA on it, though, the system kind of went kablooie a bit (i.e. it hung solid).
Do I need to mess around with Physical Addresses and the like?

Anyone got any advice? Thanks!

Topic | Forum

Spirantho

Re: Techie questions regarding the nuw Amiga OS4 update

Posted on: 2007/8/13 11:33 #488

Quite a regular

@abalaban

Quote:

abalaban wrote:
Also it's sad SDK is delayed further, because it's a long time now since it's been last updated Even a small update with new include and autodocs at least for Final would be good.

Quite..... I've just about given up waiting and I'm having to work around the fact that DMA doesn't work on buffers larger than about 2K.

Incidentally, this post isn't just a *grump*-where's-my-SDK-*grump* posting, but I noticed that I'm no longer getting any serial debug output when I use IExec->DebugPrintF(). Did something change or have I just forgotten to enable something...?

Pleeeease though, new SDK? Even if just enough to deal with the parts that were broken?

Topic | Forum

Spirantho

Re: Sam440 and Hyperion's AOS4.x

Posted on: 2007/8/7 11:01 #489

Quite a regular

I certainly intend to get a Sam440.... I still suspect the A1 hardware of causing lock-ups in the interrupt handling for TV card drivers, but I won't know for sure until I get my grubby mitts on another OS4 capable machine, i.e. OS 4 for my 4000 (and the appropriate upgrade to my Prometheus), or probably the SAM.

'course I'll never get anything done unless an up-tp-date SDK comes out....

Topic | Forum

Spirantho

Re: Picasso96 PIP support

Posted on: 2007/7/25 10:28 #490

Quite a regular

Good good, I know where to look now!

Thanks for the quick help, guys....!

Topic | Forum

Spirantho

Re: Picasso96 PIP support

Posted on: 2007/7/24 10:29 #491

Quite a regular

@rwo

That did it. I had to lock the workbench screen and pass the Screen * structure into the P96 call.

The debug string I used was actually a %p (as pointers are ULONGs aren't they?), but I changed it to %lx just to be sure and it still returned 2.

I now have a PIP window!

Is there proper documentation for this sort of thing? I can't find any info about needing to pass in the screen pointer or anything like that, nor about error codes. Error 2 therefore appears to be "Don't know what screen to use" and error 3 appears to be "PIP window already open".

I'm still stuck without DMA though. I was almost hoping that I could bypass AllocVecTags() completely and call StartDMA on the bitmap created by P96PIP_OpenTags(), but alas, no. Calling StartDMA on the PIP Bitmap just hung the machine solid.

Looks like I'm back to waiting on that SDK then.....

Topic | Forum

Spirantho

Picasso96 PIP support

Posted on: 2007/7/23 10:20 #492

Quite a regular

Hi everybody,

Figured while I was waiting for a working SDK I'd play around with overlay mode a bit.....

Can't get it to work, though. The documentation very helpfully says "See Includes for possible failure reasons". Which would be great if I could find anything at all anywhere.

The function I'm calling is:
mWindow = IP96->p96PIP_OpenTags( P96PIP_ErrorCode, &tError, WA_Left, 10, WA_Top, 10, P96PIP_SourceFormat, RGBFF_YUV422, P96PIP_SourceWidth, mPrefs->Width, P96PIP_SourceHeight, mPrefs->Height, WA_InnerWidth, mPrefs->Width, WA_InnerHeight, mPrefs->Height, WA_IDCMP, IDCMP_RAWKEY | IDCMP_MOUSEBUTTONS | IDCMP_INTUITICKS | IDCMP_NEWSIZE, TAG_DONE );

mWindow is set to NULL afterwards, and P96PIP_ErrorCode fills tError with 0x02. What this means I haven't a clue. It may mean that the Radeon hasn't had any breakfast today and doesn't feel like co-operating for all I know.
Is there better documentation on P96 PIP stuff? Or even examples anywhere?

Can anyone help? Ta!

Topic | Forum

Spirantho

Re: Hello Amigans!

Posted on: 2007/6/18 10:57 #493

Quite a regular

Excellent.... another Amiga addict in Wales...! :)

Topic | Forum

Spirantho

Re: Radeon cards - please list your config here

Posted on: 2007/4/28 10:50 #494

Quite a regular

1. 17 0x1002 0x5159 ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
2. INTERRUPT=YES
3. -
4. AmigaOne XE G4@800 512MB RAM

Topic | Forum

Spirantho

Re: Where oh where can my SDK be....

Posted on: 2007/4/19 10:40 #495

Quite a regular

@Rogue

Thanks for the reply. You'll have to excuse my impatience as I know there's a lot of work to do in an SDK and you're all very busy... but it's so frustrating seeing all these people deprived of software when there's people like myself who can't do any coding just because of one or two files which are being held up by stuff that I don't need (yet!).

Topic | Forum

Spirantho

Re: Where oh where can my SDK be....

Posted on: 2007/4/18 11:53 #496

Quite a regular

@Raziel

Thanks for that info....

... but I wish they'd prioritise a bit more developer-friendly. I'm not sure they realise that the lack of a complete SDK means that until it comes out no developer can write a driver - all because of one or two files.

I understand why they want to make the SDK encompass all the new stuff, but in doing so they're holding up development on other projects which have nothing to do with it. Kind of annoying....

Topic | Forum

Spirantho

Where oh where can my SDK be....

Posted on: 2007/4/18 10:53 #497

Quite a regular

Is there any update on a working SDK?

I think it's getting a bit silly now. The last update fundamentally broke some really important parts of the SDK for anyone wanting to do any drivers (which are pivotal for the OS), and we still don't have an update.

For four months now I've been wanting to work on getting more done on my TV card and I've not been able to because of the lack of an SDK.

I know SDKs don't grow on trees, but this is getting daft. Can't we at least have a diff to the parts of the docs/includes that are broken?

Sorry to sound impatient but how on earth are people expected to code for an OS when the only SDK that exists publically is out of date and useless when it comes to things like driver writing? It's getting incredibly frustrating.

(For those not in the know: the last update changed the function AllocMem() and a parameter was removed which was essential for allocating a contiguous DMA'able chunk of memory. You now need to use AllocVecTags() I think but that function doesn't exist in the latest 51.22 SDK. Hence it's impossible to DMA anything with the current SDK!)

Topic | Forum

Spirantho

Re: Where is the SDK?

Posted on: 2007/2/14 17:43 #498

Quite a regular

@ssolie

Sooner the better for the new SDK as far as I'm concerned as I can't do any TV-card work till I've got it...

so just make sure the new SDK is nice and clear on DMA and interrupts and the like, and I'll be happy!

Topic | Forum

Spirantho

Re: Own up... who broke the UK locale?

Posted on: 2007/2/1 15:06 #499

Quite a regular

@BillE
[quote="BillE"]

On the whole unless you are over 90 I think the metric settng is more relevant in the UK, after all anyone who did any science at school will tend to use metric units anyway.

Only in the USA do they still insist on using old "British" units in the modern era

[/quote]

Er... no. :)

You need both. After all, what's the national speed limit in this country? 60 miles per hour. That's one very obvious use of Imperial measurements, but there are others....

I know my weight is about 8.5 stone. No idea in Kg. But if I pick up an object I'll always estimate it in g or Kg.

I know my height is about 5'10" - 5'11"... but my pace is approximately a metre.

Ah, the joys of being British. And people say we're idiosyncratic.... strange.....

Topic | Forum

Spirantho

Re: What happened to IExec->StartDMA()...?

Posted on: 2007/1/5 17:49 #500

Quite a regular

@ssolie

Quote:

ssolie wrote:
@Spirantho
The AllocVecTags() function and other changes will be made available in the updated SDK.

@sg2
Are you sure you can do DMA drivers without the updated SDK on the new kernel?

Looks like that's what it needs. Kind of annoying really... spend ages waiting for overlay code and now I've got it I can't compile even a normal version yet. Hope the SDK doesn't take too long!

@sg2
The AllocVec returns the number I put in the debug output at the top.

Topic | Forum

Top

« 1 ... 22 23 24 (25) 26 »