I'll have to wait until you release a BT878 version to test. Have you solved the interrupt problem yet? If you're getting a usable image without interrupts, perhaps you could do the same with the BT878 that the Connexant chip is based on.
I'm afraid I can't actually do any Bt8x8 work until I get the new SDK... again!
I've been messing around with it all morning and my code looks fine, but I've just noticed something - the RISC program is held in main memory on the Bt8x8! Of course this means the card will probably need a nice contiguous lump of memory, so we're back to needing AllocVecTags() again. The Conexant chipset has 2K or something of SRAM onboard, so the program is loaded directly onto the card.
So I'm afraid that once again you're back on the waiting game until the new SDK. Sorry!
In the meantime, anyone who's got a Cx2388x card please try it!
Hmm, should I get a connexant based card. The problem is, I haven't found one that has a dual NTSC/PAL tuner. I'm currently in Canada (an NTSC zone) but I will be returning to New Zealand later (a PAL zone). I really don't feel like buying hardware that I'll have to dump less than a year from now.
Ah well, at least you're making progress, and, AmiTV should be rather advanced by the time the SDK arrives. BTW, is the RISC program really going to be larger than 2k (didn't Rogue say that the allocation block size was supposed to be 4k?).
Any guess if these should (theoretically) work with your software?
Additionally, did AmiTV also support the bt848 and bt878 chipsets? Somewhere it was said the Conexant chip were successors to the bt chips. And there was another page with a huge list of cards supported by the linux version of that driver:
I am indeed writing support for the Bt8x8 chipset but....
a) Using it correctly (with interrupts) is liable to hang an AmigaOne solid. I'm hoping this isn't a problem with future OS4 devices. b) I can't get it to work until the new SDK comes out.
So in other words, don't hold your breath as even when it is 'working' it's liable to crash your machine!
The Cx2388x chipset is indeed the successor to the Bt878 (which was the successor to the Bt848), but it seems a lot more stable so far.... though that might just be chance!
Isn't there a possibility to have Spirantho get hold of the latest OS4 beta and SDK? Rogue? IMHO it's kind of stupid to "hinder" important software development on this small platform. We need all drivers and software we can get ASAP.
IMHO it's kind of stupid to "hinder" important software development on this small platform. We need all drivers and software we can get ASAP.
Oh please...
The reasons for the delays in the SDK have been pointed out repeatedly. I also said there is nothing I can do about it. My hands are full.
So far no one has volunteered to work on the binutils, and as long as that doesn't happen, the new SDK has to wait until I have time to do it myself, which, I'm sorry, will take QUITE a while.
This has nothing to do with "hindering" developers, I just can't change it.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
No, I quite understand what you're saying. It's not as though you're overstaffed working on OS 4 or anything!
What I don't understand, though...
Why does IExec->StartDMA() fail with a return code of -1 when the block isn't contiguous? I'd expect it to return the correct string of DMAStructs for Scatter/Gather, rather than just failing.... I'm sure there's a good reason for it though. :)
Why does IExec->StartDMA() fail with a return code of -1 when the block isn't contiguous? I'd expect it to return the correct string of DMAStructs for Scatter/Gather, rather than just failing.... I'm sure there's a good reason for it though. :)
This should not happen. Where is that block located? If it is in video ram, then the reason is simple: It's a bug. StartDMA needs a VMArea, and there is no VMArea over the PCI areas, so any attempt at StartDMA in that area fails.
If it's in main memory, it should definitely return a scatter/gather list.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
Maybe it's a side-effect of the old SDK I'm using with the new memory system then, because that's what's happening, even in main memory.
If I do AllocMem(size, MEMF_PUBLIC | MEMF_HWALIGNED) and size is greater than about 2K-3K then StartDMA() returns 0 or -1 (not sure which). If it's less then it returns 1, as you'd expect, and I can use it. This is the limitation I'm working with....
I used to use AmiTV on the old (update 3 I believe) OS4 - I'd love to have a new version too! I still have the BT878 card, so if you need any help (Alpha/Beta Testing, etc) give me a shout. I believe you have my email, but a PM will do just as nicely...
My AmigaOne's PCI slots are all in use, but if the Sam440EP makes it to the market, it will have all the functionality I need onboard.. Ideally I'd like to get a riser for it, and populate its slots with a Catweasel and a tv card of some description. I'm quite excited about your project!
I hope you'll be able to implement recording when you're done. Maybe just support a popular standard like mpeg2, and then people could do their own conversions somehow. I'd love to be able to hook up video sources to my A1/Sam and for example put sport clips online (big tackles!! smash!!) :)
You like big tackles ? you should watch Rugby Union ! anyway - I thought the SAM was only going to have a singular PCI slot ?
I should watch Rugby Union? You know I'm from New Zealand, right?? :)
Actually, I had no idea !! your avatar blurb doesnt say, see... in which case - keep on watching Rugby Union ! remember that one from the Lions tour when one o' your guys practically dumped on of ours on his head ? (I think he was Irish but could be wrong...)
Quote:
The SAM only has 1 PCI slot, but I'm talking about getting a riser card, which would plug into the PCI slot and provide 2-3 more.
fair enough then, I always forget about those - having 4 on me mainboard un'all..