Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: Amiga_Nut on November 18, 2009, 11:11:17 PM
-
I was wondering just how far you could take the OCS chipset with a fast IDE or CF adaptor storage medium using say an Amiga 600 or A500/2000/1000 with a fast hard drive. (well fast for 2003/2004 etc when 6gb was a lot!)
I have a similar thread in another Amiga board about this but hoping some people here could help.
The dream is 24FPS or as close as possible on a stock 7mhz OCS/ECS Amiga in either 320x200 or 320x256.
Now if you had the frames stored in an uncompressed format is it possible to pull in a 6 bitplane image (48kb) uncompressed for each frame with a palette per frame and througput it in the OCS/ECS chipset bandwidth @ 20FPS. So about 1mb/s sustained speed for EHB/HAM6 20FPS movie @ 320x200x6bitplanes.
Can the blitter write this much data per second....can you use DMA to load in the data without the blitter into assigned screen memory from the IDE hard drive interface?
Any technical advice appreciated on this....would like to end up with something that can show the world what really was possible technically in 1985...and how little things have actually changed in one quarter of a century with winbloze and arty farty OSX computer for sale today :)
-
Using 6bitplanes instead of 4 will slowdown chipmem access. I remember watching an impressive video at youtube from a north american amiga group showing an A2000 playing a pair of ham videos. I don't know the software they used but I always wonder about the sound part. You could try cdxl anims although these are usually quarter-screen.
-
Interesting, but if you're using CF, then how is that still 1985? Might that defeat your own purpose? Why not use a Vlab Motion board with MovieShop or how about a Toaster/Flyer system? (both older than CF and very much Amiga-centric)
-
Those demo coders can do some crazy things on stock machines, depends how creative you are.
-
I'm sure it's possible, there's a video on Youtube of the Matrix Reloaded playing on a 1Mhz Atari 800XL.
-
Yeah, I think it's possible. The only you issue you might run into streaming it off an HD(CF Card) on 7mhz machine would be if you aren't using DMA.
Are there DMA IDE adapters for the A500?
There are probably SCSI DMA controllers. Worst case you need to buy a CF->IDE->SCSI adapter.
-
Hm, I recall watching four windowed Eric Schwartz animations on my stock A500 (512/512) back in the day - all Turbo Silver created and animated ones...his F117 flyby was one of them, IIRC.
Of course, in a 320x256 screen or whatever resolution it was, you figure a quarter of that size...not too demanding even for a 7mhz machine! :D
-
I saw an A500 with 1 meg of ram with stock CPU playing at least 15 FPS HAM 348x240 animations at the World of Commodore Pasadena back in the day. I guess it would have been 92?
A company had a DMA HD sidecar and a A2000 card (same card) that could do this. I think it was playing like Star Wars or something. Looked great!
I want to say it was the Trifecta card by ICD.
http://www.amiga-hardware.com/showhardware.cgi?HARDID=557
Link says it was IDE... wow.
FOUND IT!
http://www.amigahistory.co.uk/woc92.txt
"ICD was showing their new Trifecta hard drive. It was running 4.5
minutes of Star Wars (where they escape from the Death Star) Full
screen lores nolace HAM at 30 fps & audio on a stock Amiga 500 w/1Mb
of chip RAM. The drive was transferring data at 1.9Mb/sec, total
size of video was 350K. I honestly though they had a VCR plugged
into the monitor when I first saw it. I had to walk around behind to
check if there was a composite connection. I'd heard about these
kinds of demos before, but I don't think it really sinks in until you
see it in person." quote from Matt Davidian
-
Of course, in a 320x256 screen or whatever resolution it was, you figure a quarter of that size...not too demanding even for a 7mhz machine! :D
CDXL was 1/4 screen due to the fact the CD drive could only stream data that fast. CDXL format was not limited to 1/4 screen. Remember CDTV was 1x CD-Rom.
On CD32 you could a lot better CDXL animation.
I think the CDTV had the best video play back from 1x CD on the market without MPEG.
-
@omnicron10
it's a pity that a libcdxl is not available so ffmpeg or memcoder could use it to encode cdxl anims easily. I saw some instructions to create cdxl files and it was quite painful :-(
-
CDXL was 1/4 screen due to the fact the CD drive could only stream data that fast. CDXL format was not limited to 1/4 screen. Remember CDTV was 1x CD-Rom.
On CD32 you could a lot better CDXL animation.
I think the CDTV had the best video play back from 1x CD on the market without MPEG.
This was 1989, well prior to the CDTV, well prior to CDXL. These were bog standard IFF anims. They're probably up on aminet if you go looking for them.
-
When I say 1985 all I really mean is the OCS/ECS chipset bandwidth was capable of this task.
And I thought as there are IDE adaptors for A500/1000 machines using the ICD kits to install notebook 2.5" IDE drives technically it is possible to fit a CF card to these internal boards (they go in the 68000 CPU socket I believe)
But really it is A600 and up to use easily on a real machine I guess. I've seen the HAM animations on youtube they're 15fps using a custom format on an 030 A2000 machine I believe.
My idea was if you take a standard set of uncompressed frames that literally slot directly into screen memory to minimize the CPU bandwidth negating any decompression which you can then use for DMA transfers of the frame from your storage device etc. Hell compared to even Win2000 we are talking peanuts in file sizes really ;)
Also there are two packages I remember. One was Clarissa's SSA animation format and also another program for playing IFF anims direct from the hard drive called BigAnim or something? Don't know if SSA has HD playback routines or if BigAnim has provision for sound.
The goal is to make something that people can at least run on UAE on an A500 config if they don't have the hardware like an IDE --> CF solution etc. You can still get incredibly fast 40Gb 7200RPM Toshiba/Fujitsu/IBM 2.5" IDE drives which are very good, speed up XP execution on sub-optimal memory size (<256mb) very well so the through put and seek times are just where you want them and probably man enough for the job.
It's something to make people who don't know about the Amiga sit up and look in amazement at how little things have really changed in 1/4 of a century as far as a desktop computer for the home goes. A bit of fun too yes but it just struck me as it is the right time to do this :) You just know no Mac v1/ST/PC of the era had the technology....maybe the Amiga was only lacking fast media in 1985....which is a powerful point to show...and what better way than through the medium of youtube so a new generation can go "Really? that's awesumz d00d" etc ha
So I guess what we are asking is...is it possible for the Amiga to load in 48k images of uncompressed HAM6 @ 320x200 in 1/25th of a second AND put them into the display area. I'm not fussed about compression in the era of HD drives being measured in Terrabytes on new PCs. Someone said the Blitter bandwidth for this is 2mb per second divided by 2 (need two channels for a straight copy) so it's almost there...technically.
-
\
My idea was if you take a standard set of uncompressed frames that literally slot directly into screen memory to minimize the CPU bandwidth negating any decompression which you can then use for DMA transfers of the frame from your storage device etc. Hell compared to even Win2000 we are talking peanuts in file sizes really ;)
Problem is, DMA is a hardware thing. None of the 68000 socket HD controllers have DMA. The CPU has to be involved. The Zorro slot Trifecta card by ICD has DMA IDE support. That is why it could do full HAM 30 FPS on a stock A500/A2000.
\
So I guess what we are asking is...is it possible for the Amiga to load in 48k images of uncompressed HAM6 @ 320x200 in 1/25th of a second AND put them into the display area. I'm not fussed about compression in the era of HD drives being measured in Terrabytes on new PCs. Someone said the Blitter bandwidth for this is 2mb per second divided by 2 (need two channels for a straight copy) so it's almost there...technically.
On a non DMA controller stock OCS/ECS machine 68000? Maybe. With DMA? Yes. It has been done.
-
I thought as there are IDE adaptors for A500/1000 machines using the ICD kits to install notebook 2.5" IDE drives technically it is possible to fit a CF card to these internal boards (they go in the 68000 CPU socket I believe)
These devices don't handle DMA.
My idea was if you take a standard set of uncompressed frames that literally slot directly into screen memory to minimize the CPU bandwidth negating any decompression which you can then use for DMA transfers of the frame from your storage device etc.
Except that there is do DMA, not with ICD and similar kits at least. So basically each word will be copied from the 16-bit IDE data register by using the CPU. Writes to chip memory aren't fast either.
So lets do some math. 320 x 256, 6 planes at 24fps would require 1474560 bytes per second transfer speed.
When display DMA is set up to display HAM6 (or EHB) and you're writing the the chip memory I believe the display DMA will slow the operation down (IIRC, not sure about this one, it's been a while..). This combined with the fact that the IDE data I/O register reads aren't free either makes me think it won't be possible with PIO.
If you get real DMA to the chip memory, then it is easily possible (assuming you can reach the calculated limit of 1440KB/s, of course).
-
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!
-
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
-
Doesn't the software "Clarissa" claim to be able to play Amiga anims at full 30fps framerate even on a stock 68000 machine?
-
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).
-
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.
-
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.
-
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.
-
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.
-
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
-
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
-
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?
-
Hi It was on a 50mhz 030
-
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.