Amiga movies possible on stock OCS machine?

[Zac67]

No real sense in DMAing into fast RAM and then transferring to chip RAM, so it's easiest to DMA (or PIO read) directly into double frame buffers. If there's a bit of fast RAM (for PIO overhead) there's probably no large penalty on PIO vs DMA. Access to IDE registers will happen in fast memory, as will ROM access. Driver and system structures residing in chip RAM will slow operation considerably however.

6 bitplane gfx costs you half CPU (or SCSI DMA) bandwidth on chip RAM during bitplane DMA. Since you're using no overscan, you can make up for part of the bandwidth loss during horizontal and vertical blanking.
You've got 225 DMA slots in each line, 312 lines/PAL frame. From the 225 cycles, the  CPU can potentially use 112 (113?), 40 are lost to gfx, leaving 72. 72*256 + 112*56 = 24704 cycles per frame

16 bit chip RAM allows you to write 49408 bytes per frame, the A3000's 32 bit chip RAM would double that to 98816 bytes. Running 25 fps means you've got two frames for a full refresh (61440 bytes), so it shouldn't really be a big problem with optimized code, possibly even with a chip RAM only system!

[desiv]

6 bitplane gfx costs you half CPU (or SCSI DMA) bandwidth on chip RAM during bitplane DMA. Since you're using no overscan, you can make up for part of the bandwidth loss during horizontal and vertical blanking.
You've got 225 DMA slots in each line, 312 lines/PAL frame. From the 225 cycles, the  CPU can potentially use 112 (113?), 40 are lost to gfx, leaving 72. 72*256 + 112*56 = 24704 cycles per frame

16 bit chip RAM allows you to write 49408 bytes per frame, the A3000's 32 bit chip RAM would double that to 98816 bytes. Running 25 fps means you've got two frames for a full refresh (61440 bytes), so it shouldn't really be a big problem with optimized code, possibly even with a chip RAM only system!

Doesn't all that assume you are sending the entire screen data?
Can't you just send the changed data across?
Or would that take more CPU to figure out that to transfer?

desiv

[Ral-Clan]

Doesn't the software "Clarissa" claim to be able to play Amiga anims at full 30fps framerate even on a stock 68000 machine?

[Zac67]

Doesn't all that assume you are sending the entire screen data?
Can't you just send the changed data across?
Or would that take more CPU to figure out that to transfer?

We were assuming uncompressed data. With a fast CPU and well compressable video you can top that rate easily (the faster the CPU the better the compression yield).

[Zac67]

Doesn't the software "Clarissa" claim to be able to play Amiga anims at full 30fps framerate even on a stock 68000 machine?

Depends on the gfx resolution area you're transferring - 16 color hires overscan is completely impossible, even with fast RAM and CPU.

[Piru]

If there's a bit of fast RAM (for PIO overhead) there's probably no large penalty on PIO vs DMA. Access to IDE registers will happen in fast memory, as will ROM access.

My understanding is that the I/O registers are as slow as the chip memory.

[Zac67]

My understanding is that the I/O registers are as slow as the chip memory.

Dunno about the A600 but the CPU socket solutions attach to the CPU side as do all sidecar variants. No need to request a cycle from Agnus since all that stuff is clearly beyond its address range.

[...]
After looking at the 600's schematics the above should count for June Bug as well.

Possibly you've mixed that up with CIA speed - they're on the CPU bus, too but lots of wait states make them pretty slow.

[Amiga_Nut]

Nice little discussion  going on here, input is appreciated.

So if we had a 320x200 image size in 6 bits that would be...

320x200 x 6 bitplanes gives us a nice easy 48,000 bytes...plus a couple of bytes for palette info for each image. NO compression so far...to keep it simple and make sure the CPU just fetches our data with no hindrance or extra work required to the data.

So if it is possible to initiate the streaming of the raw 48,000 bytes to an area of chip ram then all you do is display contents as soon as load is finished and start loading the next frame into the second area of chip ram (ditto display screen 2 when this is complete and repeat rinse)

You could also set up an area of memory to load in the raw data for Paula and as long as you can keep loading in the 1/25th or whatever of audio data quicker than your playback rate uses it up in the movie player then this should work fine also right?

I assume that setting the location of the start of actual screen memory once loaded with the correct data we have pre-packaged in the uncompressed 48k file is a simple register update too?

I'm trying to find the Clarissa review in an old magazine I know I have but I don't think that could load anims from disk only memory.

[ddniUK]

As this is a clone of the thread started over on EAB, I post the vids that I posted there.
They are videos showing HAM6 playback through native chipset. Needs an 030 processor, but actually running on 060 here. Will repost direct capture of Amiga output on 030 and 060 this w/e.

http://www.youtube.com/watch?v=Rc6_d1H_9u0
http://www.youtube.com/watch?v=6q491Z-vmbw

[ddniUK]

Hi all, I have been speaking to the author of the HAM6 encoding software and playback app (T.J Edminster).
He has agreed for it to be released into the public domain.
The archive should be kept intact and any new software derived from this should credit him as the original author.

http://www.filefactory.com/file/a1d5c0h/n/avi4hv.zip

[Amiga_Nut]

Hi all, I have been speaking to the author of the HAM6 encoding software and playback app (T.J Edminster).
He has agreed for it to be released into the public domain.
The archive should be kept intact and any new software derived from this should credit him as the original author.

http://www.filefactory.com/file/a1d5c0h/n/avi4hv.zip

On the direct output videos you took what speed 030 are you using this application for? 25/33/40/50mhz?

[ddniUK]

Hi It was on a 50mhz 030

[stefcep2]

i used to convert all my low-res anims to interlace and then run them through clarissa.  It made a a big difference to the smoothness of the animation.  I understand Clarissa splits each frame in two and shows every even scanline in one and follows immediately with showing every odd scanline of the same frame.  I don't know what the bandwidth implications are but the results were much much smoother.  I'm not sure that Clarissa can run on a 1 MB A500 though.