@sg2

That's the second time someone's mentioned a function called AllocVecTags (or AllocVecTagList)...

I'm using the SDK on the Hyperion FTP site, v51.22... I'm starting to suspect there's a newer version which I don't have but without which I can't do anything... am I correct?

@sg2

Which bit exactly do you need?
I can send you the bit where I call StartDMA() and the allocation... if you really want it I can send you the bit after StartDMA too but there doesn't seem much point as it's never called (StartDMA returning NULL of course)...



The bit about the FrameBufferPhysical is where I was trying to get the physical address. I didn't need to do that before. Also of course I didn't need to worry about going into Supervisor state or anything before.
Also the LockMem() wasn't there before, I just put that in to see what would happen after it was suggested above.



This code probably looks very familiar if you wrote the autodoc. :) tResult is set to 0 of course, signifying the DMA failing to start.

Help? :)

@sg2

Quote:

They were written well but I think a little out of date now. :)

I'm away from my code ATM but...
The code which allocates the buffer is just a standard
IExec->AllocMem( size, MEMF_PUBLIC | MEMF_HWALIGNED) I think.
As for what happens between the StartDMA and the EndDMA I can't remember, pretty much the same as the autodoc! However as StartDMA is returning NULL it doesn't get that far anyway! It's the StartDMA itself which is broken....

@rachy

This is a small part of the output of my program:

[CODE]
Starting DMA at 0x0x66624000, size=442368, flags = 0.
Can't start DMA transfer.
[/CODE]

It's fairly self-explanatory. :)

I just tried calling IExec->LockMem on the address, no difference.
But that address looks rather virtual to me, which I imagine may be no good for DMAing....

And yes, I am aware of that fact. :) The code works fine under Update 4. It currently returns NULL though.

All I need is to tell the Amiga that this block of memory is to be DMA'ed to by the TV card.

Hi everybody,

Had another quick go at TV card drivers under the final update and they no longer work at all....

IExec->StartDMA() now returns NULL so it's not starting the DMA properly. I suspect this is because the address I'm trying to start the DMA at looks suspiciously virtual (it was allocated MEMF_PUBLIC | MEMF_HWALIGNED I think it was). It always worked before but I seem to recall AllocMem() is no longer guaranteed to return a physical address, even in MEMF_PUBLIC.

Just for the heck of it I tried IMMU->GetPhysicalAddress() on the address that was allocated but this call just calls the Grim Reaper.

Does anyone have an example of how to use DMA (or interrupts for that matter though I may be ok on that) under the final update? Are there any open source DMA-capable drivers?

Thanks!


Quote:

Possible, but I doubt it.. I'm not really doing much with all that, and I doubt the interrupt handling has changed much.

I've emailed Rogue about getting access to such things, but he's not replied. He is rather on the busy side, though!

Quote:

Unfortunately it's not a matter of faith, it's a matter of possibility.

I can only work on chips for which I have the datasheets. While I do have the datasheet for the CX23882 chip, I don't have the necessary sheets for the other chips (this card has a hardware MPEG encoder and a hardware MPEG decoder).. If I can't get hold of the datasheets, then there's no way I can get it to work!

OTOH, if I do get hold of it we should be able to have the full hardware MPEG en/decoder PVR functionality!

This is what I got:

Card Specs

(you can get it from other places of course)

You could get a cheaper version without all the widgetry of course, at the moment I've only got as far as the CX23882 chip, partly as it's most important, and partly as it's the only chip on the card I have the datasheet for!

I wouldn't recommend going much out of pocket though as I don't know when or even if I'll ever get a fully working TV app - kinda busy most days, but hoping to get something released over xmas/new year!

Quote:

I can't get the Bt8x8 working with interrupts without locking the machine solid. So at best - until I have overlay drivers - you'll have a very slow Amiga while it's running. I've not tested it but I may be able to use the same system as I'm using on the CX2388x version, i.e. a busy loop checking for the interrupt but not raising said interrupt in the interrupt chain. It might work, but will always be sloooow. It suffered often from the same bandwidth issues, too.

Roll on overlay drivers...

Yes, it is possible... and something else on my list to try... the reason I've not done so yet is because I had a similar problem on the Bt8x8 version and changing to 16 bit made little difference, from what I recall, and was hassle because of ARGB formats and endianness and stuff.

The fact that the TV card defaults to 32-bit also suggests a modern machine should be able to cope....

Time for a little AmiTV update. :)

First, the good news....

I have CX2388x drivers kinda working! That is I've got a stable picture, animating at 50fps on my workbench. I've tried it with a C64 and a Tom and Jerry CED (kinda like a cross between a DVD and an LP), and both look perfect. Only got a PAL source working so far but as that's the more difficult one to get working I'm chuffed.

Now the bad news....

You don't want to know how I'm getting the 50fps! I'll tell you anyway, though!

The CX2388x raises an interrupt when told to in its RISC program. I'm doing a busy main loop, and then rendering to the window whenever the interrupt flag is set. Of course this is rather slow and kind of destroys the point of interrupts. However...
I can't get the Amiga to call the interrupt routine! This worked on the Bt8x8 card (too well, it crashed the system most of the time!). I'm doing the usual stuff...

PCIDevice->MapInterrupt();
(create the interrupt structure)
IExec->AddIntServer()

but even though the CX2388x card is clearly raising the interrupt (I'm testing the interrupt flag and clearing it and getting the correct 50fps) my interrupt handler is never being called. Anyone got any ideas? The interrupt number is 26, the CX2388x uses interrupt pin A#. I think IRQ for A# in the UBoot screen is set to default (9 I think?) does that make a difference? All interrupts set to Level triggering in UBoot.

OK, that's part 1. It's annoying, perhaps not a showstopper as long as you don't want to do anything else while the TV is running. Here's part 2....

I can only get a small window! As soon as I use a reasonable sized window, say more than about 3/5 of the full resolution (768x576), the signal loses data - it looks like there's a bottleneck in the system somewhere and the FIFO buffers are full and overflowing. It's not consistent though, just some lines have pixels missing.
Can the DMA of the A1 (XE in this case) really be so slow that the TV card is waiting to DMA to the Amiga RAM and overflowing? Because of the data loss occasionally the card loses its sync and the RISC program stops and needs to be restarted. No good really. It's the only thing I can think of, though, that could be causing it to happen. A small display (say 320x256) works perfectly with no data loss.

I wonder if I could just increase the FIFO buffers... hmm... might work...
Just how slow is DMA on the A1? Bear in mind I'm trying to pump a 768x576x32 signal across the bus at 50fps. Still no overlay code remember.

Oh, yeah... does anyone here have a CX2388x-based card to test this? I'm using the latest WinTV PVR card (HVR-1300 or something) - the CX23882 is used in a lot of modern TV cards.

Quote:

Personally I'd say it is a bargain - given that the seller could get twice that amount without too much effort, I reckon.

OK, they cost less than that new, but supply and demand being what they are, in this case demand=rather high, supply=practically nil, ?300 is worth it. And you won't get many other chances to get a G4-powered OS4 machine for a little while I reckon....[1]

[1] Hope I'm wrong!

Speaking as a developer with an A1, not a lot of time but even less money, I think a bounty system would be a very good idea. I know I'd be a lot more likely to work on my TV card program if there was a bounty at the end of it, just to know that it'd be useful really! Equally same goes for porting MAME like I'm thinking of at the moment, if there were a bounty it'd be that much easier to sit down and code, code, code!

I also think a project-tracking section would be good - almost like a blog for on-going projects. There could be a section on the left of the mostly recently updated project, and maybe a project selected at random could be 'featured'. This might keep the quieter developers more in touch with the community.... and maybe encourage bounties!

You could even have a PayPal "Donate" button for each project, assigned to the project maintainer. Of course it would require honesty otherwise someone might just start a "project" of a well-loved app and watch money come in, without actually starting any code, so as usual it would be caveat emptor - or caveat donator anyway. But it's an idea!

Quote:

I may take a look but because the video code took a major overhaul in .107 I think I'm better off starting anew...

Hi Hitman,

I am very aware of your port - I used to run it and would often check for a new version, which for reasons you've just said didn't happen very often!

The codebase for MAME is changing still, though - v1.07 (I think it was) apparently had a MAJOR video-code rewrite which I need to find out more about.

I don't like relying on SDL - I'm sure it's not optimal and I reckon we could do so much more with MAME and MESS to bring it up to the level of MAME32 with nice GUIs and stuff built in rather than third party ones (or maybe merging a 3rd-party one in so it's more tightly linked?)

I still want to try and do a WarpOS version (a simple uni-CPU one) just for the heck of it but I need to find a way of making a cross-compiler for AOS 4 and WarpOS and nobody seems to have one! Hence I may be limited to AOS 4.....

Would it help you to maintain the port if you had two people working on it? I'd really like to see MAME/MESS properly supported...

Didn't put ALL my Amigas in the box - that'd be silly. :)

Got my A1G4 (most used) and the CSPPC 4000 in there though... they're the important ones!

Hi everybody,

Just wondering - has anyone been working on these (ultra-important) programs since Steffen Hauser's quick SDL port last year?

I might have a play myself but only if I'm not duplicating someone else's work....

(AOS4 primarily, then WarpOS second, then m68K third priority, naturally. :) )

This kind of echoes what I've been thinking - OS 4 first and then if it's easy enough, the OS 3.x version.

Is there a version of GCC that I can run to cross-compile for WarpOS and m68k? Particularly the former as I like emulators and obviously the 68060 struggles with C-based emulators and complicated machines.

Incidentally I have a number of machines to test on, so I don't need any external testers, but thanks. :)

Hi everybody,

Just playing around with Vice the other day and as it's not complete yet (missing dialogues) I was thinking of having a quick hack at the missing features myself. This got me to wondering....

Should we (I) be compiling anything for AmigaOS 3.x as well as AmigaOS 4.0? Surely we want more people to adopt the 'new standard' but there are still a number of users out there who can't afford or get AOS 4 capable machines.... For that matter, should I be compiling for WarpOS too?

Note that doesn't refer to Vice itself as the authors are doing a grand job on that anyway, I'm thinking more about other programs.

As a (related) side-note - I've found a tutorial on UtilitityBase.com which tells me how to install a cross-compiler for AmigaOS 4 under a un*x system (i.e. MacOS X and/or Cygwin, Linux et al) - what should I do to be able to cross-compile for AmigaOS 3.x (m68k and preferably WarpOS as well as I like speed. :) ) - anyone got any handy pointers?

Thanks all. :)

Is this the thread to say Hi?

Hi! :)

Now, who can I pester about misbehaving AOS4 machines with my TV cards? :)