High-color video playback on STE

[Petari]

http://atari.8bitchip.info/HobbitTrl50fps.avi

There is no DL-able official 48 fps Hobbit trailer (all with HFR what can see is 'hack' ). So, I made 50fps, special for our good old STE. Used MVtools2 - playback speed is same as normal, 24 fps trailer's. This is not perfect, of course, but errors are barely visible - mostly by scene changes. Sometimes it looks pretty good, like morphing.
What is bad is that whole trailer is not looking really good - contrast is low, not really colorful. In any case, motion is better.

Coming:  real 50 fps short clips.

[Cyg]

Hi,

New version 17 is now available : http://www.top250filmsdvd.com/atari/higheSTcolor17.exe

- quality a little improved, not really visible by eyes except when compared a picture before and after, some few pixels are better
- 48 col mode : color 0 is black at column 0, my previous timings used color 0 at column 0 for another custom color, now color 0 starts at column 1
- overscan : another try, 230 pixels in heigth. I added an empty line and 40 unused colors to be aligned with my timings which are using from palette 41 to 48 on the line before for the beginning of the current line. Nothin to change from the player side.
- blockoflines : new option, to group lines of pixel on a same palette configuration, ex: 48 shared colors for 2 lines of pixels means a final size of 42KB instead of 52KB
- auto-heigth, depending on the heigth of the source file only

Another try, Hobbit trailer in 12.5 fps / 48 colors, dither=5 : http://www.top250filmsdvd.com/atari/hob5.zip  tested with NP158DE

Cyg

[Petari]

http://atari.8bitchip.info/Nena50fps.avi

TV recording, converted with highestcolor16c .  Btw. it is very easy to make 50fps from TV interlaced recordings - will add to guide how..

I'm  doing currently another Hobbit trailer at 50fps - what done (trailer2) is not looking so good. Trailer1 is better.

Will convert with new version - on list is Atari clip in res 320x240 .  And will try is possible somehow to use shared colors for 2 lines for UltraSatan playback. With it can little increase line count. But still not enough for 25 fps.

[Petari]

Final mode:  320x240px. Dual palette, 25fps. Old Atari video now with correct speed and aspect ratio:

http://atari.8bitchip.info/Acs240.avi

[Petari]

 Remember Tomb Raider 1 cut-scene videos ? They are in 320x120px, 15 fps, 15bpp, low compression ratio. I converted couple to 320x158, 12 fps - good for UltraSatan and emulators.     http://atari.8bitchip.info/CANY.rar


   Atari STE  hi-color audio-video (AV) playback modes :


For now, audio is always  mono, 25033 Hz, and 8-bit (that can not be other).
May go on stereo, 25033 in some cases - will see it later.

More interesting is video part:

Hi-color here means more than 16 colors at once on screen. Based on fast palette change during
video displaying, with special, synhronised code. First SW using it was Spectrum 512. In meantime
some newer SW is developed, on same base, but with more options, better quality and SW for PC - what is important when we need to convert thousands of pictures for animations.

Hi-color can have 4096 colors at once on STE, or even about 30K perceptual, if alternating 2 little different palettes between fields (2 fields make 1 frame by TV) .  But 4096 colors per screen means not that any pixel may have any of 4096 colors - we have maximum of colors per horizontal line - what is less than line pixel count, because palette change speed is limited. Color/line count goes usually from 48 to 80 (only with CATA) . It is usually enough for pretty good quality.
Interesting is to compare it with 256 color, indexed mode - what may see on Falcon or TT (+VGA, etc) :
256 color, indexed mode means that any pixel can have any of 256 colors, defined in palette, what holds 256 different color nuances, usually defined with 18 bits - so 256K colors (like 512 by ST).  In most of cases, 256 colors will look better than 4096. Why ? Because there is more selectable in palette, and no special line color count limit.  RAM usage of 2 ways is pretty similar. And STE hi-color occupies CPU heavily during line displaying - CPU is free for other things only in top and bottom border periods.

After this rhetoric, let's see available modes developed by me, and supported by Photochrome and HigheSTcolor converters - still developed by Douglas Little and Cyg.

First param. is resolution Hor x Vert pixels, then frames per second, palettes - SP or DP (single or dual) and colors per line.
Data rate is with audio (what is only 25KB/sec in all cases)

Mode 1:  320x158px, 12.5 fps, 48c/l.  SP.  Data rate:  519 KB/sec.
   Only this mode works on UltraSatan - if SD card is enough fast.

  Following modes are all for CATA, fast read:

Mode 2: 320x159px, 25 fps, 48c/l - standard PCS timing. SP. Data rate :  1013 KB/sec.
   Good compatibility with possible timing variations.
 
Mode 3: 320x199px, 25 fps, 48c/l - standard PCS timing. SP. Data rate :  1427 KB/sec.
   Good compatibility with possible timing variations.  Obsolete - will be not supported in standard CATA ROM.

Mode 4:  320x198px, 25 fps, 80c/l . SP or DP. Data rate: SP: 1625 KB/sec . DP: 2450 KB/sec.
  Indeed best quality.

Mode 5: 416x228px Overscan, 25 fps, 48c/l. DP (can SP too, but not recommended - gives not lower datarate).    Data rate:  2375 KB/sec.
  More res=more details. Ideal for less colorful stuff.

Mode 6: 320x199px. 25 fps, 54c/l. SP or DP. Data rate SP:  1425 KB/sec. DP: 2050 KB/sec .
  Uses Cyg's  54c/l . Good for animated/cartoon.

Mode 7: 320x198px. 50 fps. 48c/l. SP (of course) . Data rate: 2500 KB/sec .
  STE display is actually 50fps, progressive - so why not playing in it's native mode, if disk transfer is fast enough. And era of HFR is coming (High Frame Rate - Hobbit, Avatar 2) .  It is easy to convert usual TV, 25 fps interlaced to 50 fps progressive, lower vertical res - exactly good for our prehistoric STE !

Mode 8:  320x240px, 25 fps, 48c/l.  DP . Data rate:  2088 KB/sec .
Good for old-fashion 4:3 AR material.


Marry Xmas 

[Petari]

Added mode 9.
See for more:   http://atari.8bitchip.info/movpst.php
Tomb Raider fans should like it 

[Cyg]

Nice
Why not filling the gap by doubling the line in heigth ? Except if you use the available free cpu during the black lines for something else than palettes update and not enough CPU to copy a 2nd time each odd line on the even ? (1 read + 2 writes with movem should be the fastest method)

I am finishing to debug the 1pix 2pal and 2pix 2 pal mode, some bugs appeared since I made changes&optimizations on the 1pix 1pal mode.

I worked hard today & nigth on the 1pix 2pal with block of 6 lines sharing same colors into a new overscan display timings (48 col per line using blitter + 1 global color + per line video adress dynamic change) for my hicolor effects on my next demo, STE only.

Cyg

[Petari]

Shared palette is certainly good for demos, but for movie playback, where we have too busy CPU is not good.

Gap between lines is used for bitmap data copy - there is little more time than needed. But not possible to show copy of previous line - then CPU would be occupied 90% with color updates.  Bitmap must be copied, because with DMA can not load in desired way - 160 bytes in line, then skip next 160, load 160 ... etc .  DMA can load only with 512 byte blocks. So, I load bitmap data to some buffer, and copy to final dest in black lines, with proper code to skip black lines.

With IDE, where things are under CPU control, it would be possible.

[Petari]

I made simple rutine to check timings - not really good for determine is it A or B, but there are differences between Steem, Hatari and real machines. Result 16 bytes pattern is different .

Code Select Expand


*  determine timing

* Sampling 16 values is enough :

move.l $70.w,vblEnt
move.l $68.w,hblEnt
move.l #saVb,$70.w
move.l #hbl1,$68.w

move.w $468.w,d2
add.w #16,d2

.wa16 nop

cmp.w $468.w,d2
bne.s .wa16

bra.s after



saVb movem.l d0/a6,-(sp)
lea $FFFF8209.w,a6    * 8T
 

move #$2100,sr
.wa stop #$2100

move.b (a6),d0   

beq.s .wa


rec move.b d0,$600.w   *
addq.w #1,rec+2


addq.l #1,$466.w
addq.l #1,$462.w
movem.l (sp)+,d0/a6
hbl1 rte




after
move.l vblEnt(pc),$70.w
move.l hblEnt(pc),$68.w