Direct-disk animation replay

[drac030]

Hi

 

I am experimenting with replaying animations directly from a disk file. This of course requires a fast, parallel hard drive, and a fast DOS. The disk I use is a 2.5-inch, 2 GB Toshiba attached through an IDEa interface. The DOS I use is SpartaDOS X 4.42. It is recommended to replay the video file from a partition formatted to 512 bytes per sector, as the I/O is faster then. My computer is a PAL 130XE.

 

The replayer will display the numer of frames replayed and the numer of frames per second, so you may consider it a sort of performance test

 

1) for a standard Atari:

 

http://drac030.krap.pl/vs.arc

 

or

 

http://drac030.krap.pl/vs.zip

 

The archive expands to about 5.5 MB, it is advisable to unpack it on a PC and transfer the unpacked files onto the Atari disk. There are two short cartoons there grabbed from http://www.tvigle.ru

 

The display is monochrome, 320x192 ( GR.8 ). The replay speed here is 8-8.5 frames per second.

 

2) for a VBXE-equipped Atari:

 

http://drac030.krap.pl/vx.zip

 

The archive expands to about 8.5 MB. This time it is a short film featuring Buster Keaton The display is in 128 grayscale shades, 128x192 (VBXE lowrez narrow), but in fact the resolution of a single frame is 128x64 in 256 gray shades (VBXE, however, has "only" 7 bits of intensity per component).

 

The replay speed here is 10-10.5 frames per second.

 

The *.VS and *.VX files are just raw data, and the respective replayers (VS.COM and VX.COM) are very simple. Use:

 

VS FILENAME.VS

 

or

 

VX FILENAME.VX

 

at DOS prompt. When a DOS has no command line interface, the programs will try to open OUT.VS and OUT.VX, respectively. Also, on MyDOS, the programs will hold the display after termination, so that one can read the results.

 

Many thanks to Larry for early testing.

[Rybags]

My real machine doesn't have HDD, but managed to get the VS one going in Atari800Win+ although it seems a bit slow.

 

No luck with Altirra on either type... I get ERROR 146 using it's H: device.

 

Any chance of some YouTube videos of this?

 

I'd reckon with VBXE we could do some real nice quick RLE unpacking with the blitter.

[drac030]

My real machine doesn't have HDD, but managed to get the VS one going in Atari800Win+ although it seems a bit slow.

 

Here under A800Win+, with SIO patch enabled, it is even a bit too fast: 34.68 FPS on a 512-byte-per-sector ATR and a half of that on a 256-bps ATR. Much depends on the DOS: some of them are painfully slow even if the I/O device itself is fast.

 

No luck with Altirra on either type... I get ERROR 146 using it's H: device.

 

No surprise, this emulator has many bugs.

 

Any chance of some YouTube videos of this?

 

I have no camera here, but maybe someone else could do the video. Preferably someone who has the "ideal" config (SDX 4.4, IDEa, VBXE).

 

I'd reckon with VBXE we could do some real nice quick RLE unpacking with the blitter.

 

Yes, it is certainly worth considering. The data would have to be actual compressed data + a series of BCBs direcly expanding them into video memory. Also, each frame would need a sort of a header to mark whether it is compressed this way or not. Will experiment with that.

[phaeron]

My real machine doesn't have HDD, but managed to get the VS one going in Atari800Win+ although it seems a bit slow.

 

No luck with Altirra on either type... I get ERROR 146 using it's H: device.

 

Any chance of some YouTube videos of this?

 

I'd reckon with VBXE we could do some real nice quick RLE unpacking with the blitter.

 

If you are using MyDOS, you can't load the executable off of H: directly in Altirra because MyDOS expects the CIO handler itself to do the program load via a non-standard CIO call. If you are using SpartaDOS X, I wouldn't expect this to work at all since AFAIK it has no support for CIO block devices.

 

If you copy the executable to disk and edit it so that it refers to H: instead of D:, it should work fine. It runs slowly off of H: on both emulators because the native CIO interface calls the CIO handler for a device once for every byte; DOS itself usually has a bypass to make this much faster, called Burst I/O in Atari DOS. I've been meaning to implement this in Altirra at some point. MyIDE emulation would work, but it's a bit painful given the current copy speed off H:.

 

I'm not sure how you would do RLE unpacking with the VBXE blitter, since blitter itself doesn't support variable ratio data expansion. The 6502 would be too slow, and I doubt trying to generate blitter lists is going to work that well considering that 16-bit addition with the blitter is painful. What the blitter could do, however, is motion prediction/compensation, sort of like a reduced version of ZMBV without the Deflate compression. Codebook compression would work well, too.

[Rybags]

For RLE repetition, you just use a blt_and_mask = 0.

 

That way, source fetching is skipped and the fill data will be blt_xor_mask.

[phaeron]

For RLE repetition, you just use a blt_and_mask = 0.

 

That way, source fetching is skipped and the fill data will be blt_xor_mask.

 

Right, but the hard part is how to do it in a way that you're either not spending all of your time setting up the blits on the CPU or burning a huge amount of memory on precomputed blit lists.

[Rybags]

For animation, it might be more efficient with VBXE to use a similar technique to CyberPaint on the ST.

 

It does RLE + XOR of whatever data is already there.

 

Also with VBXE you don't really have to do things linearly - you could just as easily do vertical strips, or maybe even some sort of cell-based system similar to MPEG and most modern codecs.

 

 

Re the blit lists - it'd probably be easier to do it in 2 stages. First blit copies the operands to the second blit list.

 

Huge amount of RAM - sure. But I'm currently working on a demo that's likely to use over half the VBXE RAM just in Blit Lists and tables.

[+CharlieChaplin]

Hmm,

 

I remember the TIP-Animations, they have a max. resolution of 160x100 pixels with approx. 256 colours. But most of the time when they used full-screen resolution they were either quite slow or flickery (or both) running from XRAM... but they used some sort of RLE compression.

 

Maybe with the VBXE we can have movies with 320x240 (or 320x200) pixels with 256 colours and RLE compression. Running such movies off of a harddisk should be quite fast. And if doing such movies and viewers for the A8, one should think of separate viewer versions for a) the standard 1.8 Mhz XL/XE with VBXE and b) the "faster" 65816 equipped XL/XE with 7 or 14 Mhz and with VBXE...

 

Without VBXE one could try to load TIP movies (instead of TIP-Animations) with 160x100 pixels and 256 colours off of the harddisk (instead of XRAM like the Tip-Animator does). The Tip Conv. 1.1 by Epi already does batch conversion, so one can extract many thousand frames from a movie (e.g. from AVI with Irfan-View) and then convert them in one go into TIP format. Next thing to do here would be a PC program that converts the thousands of TIP pics/frames into one RLE compressed file that can be played back with an A8 TIP-movie (harddisk-) player...

 

...just some thoughts... -Andreas Koch.

[Mathy]

hello Drac030

 

Why use DOS? If you use ATASPI, you can directly access HDD sectors. Read all about ATASPI check out my ATASPI page.

 

sincerely

 

Mathy

[drac030]

Why use DOS?

 

Mathy, of course, noone is required to use DOS. The point is, however, that storing a video stream in a file is convenient. E.g. it is much more convenient to be able to store 5 video files in two directories on a disk, than to be forced to reserve one partition per video file. Although I of course admit that using raw transfers would allow to improve vertical resolution. Just that's not the point (as using a PC would improve it yet more).

 

The real point is that certain DOS-es allow to do interesting things, and certain other ones just waste CPU time.