8BitChip Forum

Atari => Software => Topic started by: Petari on 25-09-2012, 14:28:44

Title: High-color video playback on STE
Post by: Petari on 25-09-2012, 14:28:44
I made couple short videos with audio :  http://atari.8bitchip.info/HCPL.ZIP
Used Photochrome 4096 color mode, fullscreen, 12.5 fps, audio is 25033 Hz, mono.
It is very demanding considering CPU time, disk space, loading speed. Max some 6 sec. playback at once is possible.
Requirements:  STE or MSTE with 4MB RAM , 3.5 MB free RAM. Hard disk. TV/Monitor capable to work at 50Hz (PAL). May try with some emul. Steem, Hatari. On ST will be no sound, and less colors.   Too much ?  Well, it is still not enough for some contigous playback :-)
This could be base for enhanced Space Ace.

Contigous playback with 4096 colors ?  Extremely demanding, especially at 25 fps and fullscreen. I have some ideas how to achieve it on STE. But it will not work with UltraSatan, to say ahead. Only with Cartridge or IDE IF + little mod. + raw hard disk access and special SW. If it will work some day, expect aprox. VHS quality - there will be noise too, audio quality similar to mono, analog VHS. Sharpness may be better than average VHS. About 45 min on 4GB.
Title: Re: High-color video playback on STE
Post by: Cyg on 26-09-2012, 11:43:51
Hi Petari,

Good to see new stuff on STE :-)
I made something similar last year using my new hicolor rendering technic on ST with no sound, you can see some details at the bottom of my thread on Atari Forum http://www.atari-forum.com/viewtopic.php?t=21148
I improved the rendering quality a little since.
I tried some UPX and my own algorithm compression with no big success in term of size (-10 to -30% at best for complexe pictures, surely more for cartoons using complexe trails between 4 bits pixels and not the 4 plans Atari coding). Whatever, it takes a bunch of time to uncompress and also a lot of space in memory if everything is preloaded.

Using another technique of image animation in hicolor, I made an "infinite zoom" effect.
Using 10 pictures I manage a motion blur in between to smooth the transition. You can see 2 examples here :
http://www.youtube.com/watch?v=WlUan662xGM
http://www.youtube.com/watch?v=1qRfYI8cMGY
Pictures are made of 200 to 400 different colors in fullscreen 400x250. I simplified the encoding process to use only 48 colors every 6 lines to give a good enough rendering result and few memory consumption.

You could also take a look at Photochrome 5 encoding for a better encoding than Spectrum, Hicolor is not released yet :-)

Best regards and stay Atari !
Cyg / BLaBla
Title: Re: High-color video playback on STE
Post by: Petari on 26-09-2012, 15:01:28
Hi Cyg,

I know your similar hi-color video playback - it is scene from Avater. I was not able to judge how noisy it is really, because of constant rotation.
I did conversions with Photochrome 5, on PC. With mode 3, what is not present on Photochrome 4. It was necessary because some errors on white pants, in video 1. Have some mailing with Douglas Little - he did some updates in last week.

I saw your another demo too - quite impressive.

About contigous playback - we can forget data packing. There is simple no CPU power and time for it. I don't think that it is big flaw today, when storage is cheap.
The real problem is that CPU is busy with moving color data to shifter all time during scanlines. And you can not use DMA/ACSI disk transfer, because it slows CPU down. 

But, as said in first post here - there is a chance:  and with even better quality.  With special hack in STE (very simple mod) + cartridge or special IDE IF + Compact Flash card, it is possible to achieve 25 fps, fullscreen, with DMA audio .
With hack we can have very big transfer from CF card (or hard disk):  peek speed is over 2.5MB/sec. It means that can load 32KB bitmap data in periods without scanlines (about 35% time). And best is that can load color data into shifter directly from IDE disk.
By using simple commands:   move.l  (a0)+,d0  in order.  It is faster that movem and gives better distribution. HW  mod is needed to reverse operation - it will write to (a0) instead of reading from.  I guess that we can have about 68 colors/line with it.
See this:  http://atari.8bitchip.info/astide.php  - second project, cartridge port IF. Transfer rate is 2354 KB/sec . 
Well, all it needs accurate timings in SW, + support in converion SW, because is not compatible with anything what exists.

Title: Re: High-color video playback on STE
Post by: Cyg on 26-09-2012, 17:42:29
Great, if you want to test it under my hicolor process, feel free to send me your pictures to encode.

I can try to package my encoder (running on PC) and the rendering routines to be more user friendly than they are for my only use.
I have several modes :
192 pixels large with 48 colors : the best in average density
256 pixels large with 52 colors
320 pixels large with 54 colors + 2 fixed colors
400 pixels large with 48 colors : STE only because of the blitter and hardware address mode on every scanline => for the next demo :-)

After a quick comparison on few pictures, I think my hicolor is really better than Photochrome 5 m3 but I did not test every parameters on it.
Here some samples, using one picture and 2 swaping pictures result (size is doubled) :
(http://www.top250filmsdvd.com/atari/03-Original.png)
Original

(http://www.top250filmsdvd.com/atari/03-photochrome.png)
Photochrome 5 -m3

(http://www.top250filmsdvd.com/atari/03-Hicolor%20S.png)
Hicolor

(http://www.top250filmsdvd.com/atari/03-photochrome%202%20swaps%20result.png)
Photochrome 5 -m3, fade result from 2 swaping pictures

(http://www.top250filmsdvd.com/atari/03-Hicolor%202%20swaps%20result.png)
Hicolor, fade result from 2 swaping pictures

Photochrome has another issue on the global lighting, results are always a bit brighter than the original.

Cyg / BLaBla
Title: Re: High-color video playback on STE
Post by: Petari on 27-09-2012, 13:39:56
I'm not totally satisfied with Photochrome - there is too much 'noise' at animations, even when it is suplied with not so much colors. And need for m3 means slow conversions.
I will post you URL, when can DL pic serial for conversion.  It will be 320x200 png, 16M colors.  And want 320 px. result. , single field + if possible, source code for displaying 1 frame - for PAL (50 fps) mode - so I can combine i with playback SW.
If you prefer some other pic format, let me know .
Title: Re: High-color video playback on STE
Post by: Cyg on 27-09-2012, 16:49:55
All right !
I made a test with a cartoon style picture, it's not so easy to convert than it seems especially if the source includes artefacts, as they tend to me more visible after optimisation :-)
I will give you the ASM replay routines, no pb at all !

Best regards,
Cyg / BLaBla
Title: Re: High-color video playback on STE
Post by: Petari on 28-09-2012, 11:03:45
Yes. I did some normal movie segments, there is less noise (shimmering) visible usually.
I will try to do this weekend some experiments with cart. port IDE adapter. To see how much colors can have per line. Will try to make some pattern and displaying it.
It would be good that you send me your line timing, color info writiong to shifter concept too - I think that I saw it somewhere, but to avoid searching for.  It will help me in doing it faster/better.
Title: Speed possibilities
Post by: Petari on 01-10-2012, 16:53:14
I did some testings about possible data transfer speeds with cartridge port IF CATA.
After some thinking and looking docs, I went on movem solution, but in special way:

Usually, data transfer goes by reading data into CPU from source and then writing to dest. If we can write directly to dest from source, it will work much faster - in theory 2x.  IDE ports is ideal for such thing, because it autoincrements data adresses. So, we can do transfer by activating IDE for read and then data will appear on data bus, while setting RAM to write on specific loc. But no such CPU instruictions.  Opposite is possible:   move.l  (a1)+,d0 - executing it wits special logic will result in write content of adr. a1 to IDE port.  And it means peek speed of 2.66 MB/sec - what is used in my CATA design.
To achieve opposite - reading from attached IDE drive we need trick - simple mod in ST(E) by cutting CPU R/W line leading to MMU - then logic on ID can invert it when needed - by instruction same as above:  move.l (a1)+,d0  -  then it will write what is on bus to adr at a1.

With movem we can do even faster. But I avoided it so far, because there is small bug with movem -
it performs 1 mem. read cycle more at the end. And it triggers IDE port counter too, so we loose 2 bytes at read. But, with inverting logic, read will be write, and overshot writes exactly
where we need it !

I did test with CATA driver using movem - and with inverting R/W signal logic:


superFast   *  - reading with movem !
* Destroys all registers except a7 and a5

   move.w  #$2700,sr *disable interrupts

* Need to save sp and a5 :

move.l sp,$30.w
move.l a5,$34.w

*activate RLA :
   IdeSelpDataFR
 

* Needs change on line /RW to MMU -
* so by IDE data read MMU gets write instead
* reading ! 
* This is some kind of semi-DMA
* because data goes directly from IDE to RAM
* or vice-cersus.

   movem.l  (a1)+,d0-d7/a0/a2-a7    *  15x4 bytes + 2 bytes overshot = 62 bytes
   addq.l   #2,a1
   movem.l  (a1)+,d0-d7/a0/a2-a7
   addq.l   #2,a1
   movem.l  (a1)+,d0-d7/a0/a2-a7
   addq.l   #2,a1
   movem.l  (a1)+,d0-d7/a0/a2-a7
   addq.l   #2,a1
   movem.l  (a1)+,d0-d7/a0/a2-a7
   addq.l   #2,a1
   movem.l  (a1)+,d0-d7/a0/a2-a7
   addq.l   #2,a1
   movem.l  (a1)+,d0-d7/a0/a2-a7
   addq.l   #2,a1
   movem.l  (a1)+,d0-d7/a0/a2-a7     * so far 62x8 = 496 bytes
   addq.l   #2,a1

*   movem.l  (a1)+,d0-d2        * 3x4 +2 bytes = 14 > 510 so far
*   addq.l   #2,a1
*   move.w   (a1)+,d1     *  last 2 bytes

* better :
   move.l  (a1)+,d0
   move.l  (a1)+,d0
   move.l  (a1)+,d0
   move.l  (a1)+,d0

  IdeSelpR   * LAO off
  move.l $34.w,a5
  move.l $30.w,a7
  move.w srkeep-vbas(a5),SR

  rts



Because of bug it is slower than could be. Still, I got over 2.5MB/sec with filesystem read, with not optimised driver.  Raw speed should be over 3MB/sec.

Now, I want to use same for color palette loading directly into shifter, from IDE port (CATA IF).

But because of bug, it needs special approach. After some time, I concluded that using 15x word transfer is the best - then overshot will write 16-th color too.  All it in 72 CPU clocks.



hiColor   *  4096 color support 

* SR=2700 already !

   move.l sp,$30.w
   lea   $FFFF8240.w,a0

*activate RLA :

   IdeSelpDataFR

* 1 line - must be exactly 512 T states of CPU


* Need 199 times in row !


hiCline     *  a0 must be set to $FF8240 at entering

* Early ideas :
* may use other addr. registers to start with higher color
* or, much better, start with $FF823E !  -  not possible - gives bus error !

*    movem.l  (a0),d0-d7    * 16 colors + half at beginn, dummy,  because overshot
** above is 12+8x8 = 76 T states
*   movem.l  (a0),d0-d6   * 152
*    movem.l  (a0),d0-d6    * 228
*    movem.l  (a0),d0-d6     * 304
*    movem.l  (a0),d0-d6     * 380
*    movem.l  (a0),d0-d6     * 456   *  too much already ?


*    movem.l  (a0),d0-d6   * transfers 14 + half colors because overshot
** above is 12+8x7 = 68 T states

** so, maybe to add :

*    movem.w   (a1),d0-d1   * rest 6 bytes  , with overshot
** above is  12+4x2 = 20 T states
** so, for 16 colors need 88 T states

** Repeat above 4 times - 352 T states 64 colors


* fill with nops to get 512 cycles


* Better variant :

  * a0 = $FF8240

   movem.w  (a0),d0-d7/a1-a7   * 15 colors, +1 via overshot,
* so all 16, no resol. reg damage
* above is 6+15*2 = 72 T states

   movem.w  (a0),d0-d7/a1-a7    * 144

   movem.w  (a0),d0-d7/a1-a7     *  216

   movem.w  (a0),d0-d7/a1-a7     * 288

   movem.w  (a0),d0-d7/a1-a7     * 360

   movem.w  (a0),d0-d7/a1-a7     * 432

   movem.w  (a0),d0-d7/a1-a7     *  504

   nop    * 508
   nop    * 512  - end of line

* code len is 32 bytes

* Above means 16x7 colors = 112, but pixels are only through 320 t states.
* so 320/72 - about 70 colors - ??? or little  more ?


* repeat yet 198 times :
 


The question is:  what is the best moment to start with palette update ?  Of course, we preload first 16 colors in H-blank. Then at which pixel to start update ?
And I think that we should go on all 16 colors update  , except last one, where no time for all 16 - and no sense, as running out of pixel area.

I want to make test patterns for this - where will be visible how many colors can have per line (because on-fly palette change what color will be shown depends on color index # - and is it updated already, or in shifter is still precious value) , + to see will it really work enough fast. Should, because modern drives, cards are much faster that old Atari - cheap Kingston 4GB can over 15 MB/sec, and access time is under 0.5 mS .
Title: Re: High-color video playback on STE
Post by: Cyprian on 01-10-2012, 23:50:27
High color video player look pretty amazing on STE.

Quote from: Petari on 01-10-2012, 16:53:14With movem we can do even faster. But I avoided it so far, because there is small bug with movem - it performs 1 mem. read cycle more at the end.

cool research, I only heard about bug in CLR.l
Can you please give exact example of buggy movem instruction?


Title: Re: High-color video playback on STE
Post by: Petari on 02-10-2012, 10:59:31
There are diverse bugs in 68000. Most of them is not harmful - usually only slows down. It seems, that designers were satisfied that it works without big problems, and not optimised further. I saw some articles online about it.

Movem:  it is visible from listings above.
For instance, command  movem.l (a1),d0-d7  will transfer 32 bytes at adr. a1 to registers d0-d7.  But at end, it will perform additional word read from adr.  a1+32, in empty.  Except little slower work, it has no other side effects - for normal usage. However, if you want to use it for very fast IDE hard disk read, it is useless - because 2 bytes are lost - additional read in empty at end will trigger IDE counter, and it will suply +2 bytes, which go lost.  This is what I experienced some 4 years ago.
You may see from cycle tables that movem from memory is 2 cycles longer than movem to memory - where no bug.

In my desparate effort to make 25 fps hi-color playback possible, I just went to idea to try movem from memory in reversed direction - when logic sets MMU to write to RAM instead normal read. I expected that then it will write that additional 2 bytes right to proper loc, since it should be regularry incremented.  And it happens - works reliable and very fast. Peek speed is about 3.6 MB/sec.
Note that in that case data appearing on bus (from IDE port) goes to RAM directly. It goes of course to CPU registers too, but it is not relevant.

1 min movie fragment at 25 fps is under work.
Title: Re: High-color video playback on STE
Post by: Cyg on 02-10-2012, 13:29:39
Looks terrible !

But Petari, you need to encode the movie respectfully to your displaying method based on inverted movem, isn't it ?
If you send me a screenshot with random colors, colors index and pixel graduation of your display result, I can make a specific configuration in my Hicolor encoder and send it to you the executable to encode your movie frame by frame.

(http://www.top250filmsdvd.com/atari/HicolorConfig.png)
I usually calibrate my configuration with this kind of screen test made of 16 big horizontal color bandes with pixels marks every 2/4/8 to see where the color changes exactly, interleaced is not necessary.

Best regards
Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 02-10-2012, 14:16:09
Exactly - it needs new/updated encoding SW. And should be better, thanks to more colors per line possible.
I made some primitive test pattern for testings, but it appeared that my Sandisk CF card went dead, while Kingston 4GB can not do read multiple, what is essencial here.  I will try with 2.5 inch hard disk today later. But CF should be better because faster access times.
And I think, that I can do version compatible with existing hi-color formats.
Just need to maintain same timing as line displaying rutines - so adding some nops here and there, or like... Then 320x200 at 25 fps will work fine. With sound.

Is this your displaying code ? :

; HigheSTcolors display rout. 1992-2011 Cyg / BLaBla
; colors 0 and 1 are global
lea   $ff8244,a6
lea   colors,a7
rept 199 ; 199 lines only, first line is lost because of the synchronisation, possibility for a lower border removal
movem.l (a7)+,d0-d7/a0-a5   ; load 28 colors
movem.l d0-d6,(a6)         ; display 14 colors at the beginning of the right border
movem.l (a7)+,d0-d6         ; load 14 colors
movem.l d7/a0-a5,(a6)      ; display 14 colors right after the end of the left border
movem.l (a7)+,a0-a5         ; load 12 colors
movem.l d0-d6,(a6)         ; display 14 colors
movem.l a0-a5,(a6)         ; display 12 colors
move.w (a7)+,(a6)         ; display 1 last color (3 nop)
endr

And for Photochrom too.

But currently doing 1 min video, with res 320x160 - then should be enough time to read 51KB in remaining non-scanline times of 1/25 sec, with so high transfer rate. And source is even at larger AR.
Then can use slightly modded Photochrome code - adjusted to 160 lines, and with improved start - starting at line 40, so will be centered vert.

Thanks for offering code update. I will need it for sure. Just need to solve that read multiple problem (by color update must be no waitings. So, need card which can at least some 64 sectors in read multiple mode). Will look for some new CF card - but choice is not big in shops, and prices are high. Likely will need to order it.
Title: Re: High-color video playback on STE
Post by: Cyg on 02-10-2012, 14:33:34
Yes it's mine in its 320 pixel wide version with 54 colors + 2 colors per line from 1 year ago, I don't think I have improved it since.
You will also need to know when it exactly starts to be centered.

I also have  a 48 colors 400 pixels wide (fulscreen left/right/top&bottom) version, using blitter / STE only and I think I had a fullscreen version compliant with every ST but never used.

Cyg
Title: Re: High-color video playback on STE
Post by: Cyprian on 02-10-2012, 18:49:10
Quote from: Petari on 02-10-2012, 10:59:31In my desparate effort to make 25 fps hi-color playback possible, I just went to idea to try movem from memory in reversed direction - when logic sets MMU to write to RAM instead normal read. I expected that then it will write that additional 2 bytes right to proper loc, since it should be regularry incremented.  And it happens - works reliable and very fast. Peek speed is about 3.6 MB/sec.
Note that in that case data appearing on bus (from IDE port) goes to RAM directly. It goes of course to CPU registers too, but it is not relevant.

does it mean that your CATA is able to detect MMU cycles? and use those cycles to write data to RAM? that really crazy idea :)

If it really works, maybe it would be possible to feed directly Shifter (with video data) during MMU cycles?



Title: Re: High-color video playback on STE
Post by: Petari on 03-10-2012, 10:53:59
No. The trick is that logic will invert R/W line only when RAM access is performed + that mode is set. Therefore transfer code self must executing from cartridge ROM - so may distinguish simple.
Of course, cart port adapter can not detect much - there are only few CPU lines.
Direct access to shifter/MMU ? It would need some serious cuttings in machine, I guess.
I thouhght about something related - fast RAM access during non-scanline periods. Then 8MB/sec would be possible for about 34% of time. But likely again lot of cuttings + complicated logic.
Title: Re: High-color video playback on STE
Post by: paulwratt on 04-10-2012, 09:42:47
Quote from: Cyg on 02-10-2012, 14:33:34
I also have  a 48 colors 400 pixels wide (fulscreen left/right/top&bottom) version, using blitter / STE only and I think I had a fullscreen version compliant with every ST but never used.

Cyg

Can you post both of that code also?

I'm looking for ideas for a game "display driver" that can do "hicolor", especially if it works on "every ST", and "400px wide".

Obviously I might end up with less colors than what you guys are getting/using, but I think what the two of you have done so far will give the solutions I need

thanx

Paul
Title: Re: High-color video playback on STE
Post by: Petari on 04-10-2012, 13:55:24
I made 3 demos of contigous playback. All are 1 min, 320x160 px. May try in Steem or Hatari.

http://atari.8bitchip.info/Play1min.rar  - 40MB .
http://atari.8bitchip.info/HCPL.rar   -  36MB .
http://atari.8bitchip.info/avat.rar - 48MB .
First one was hardest to convert to PCS with acceptable quality.

Cyg: can we try with your hi-color system ? Will you send me encoding SW, or I should send you pictures ?
Title: Re: High-color video playback on STE
Post by: petsasjim on 07-10-2012, 18:36:55
Hi,Iam Petsasjim1 (The Commenter From youtube Videos).
first to say again,i know nothing about "programming",but i am here as an only an old user(not only atari user),gamer who plays games mostly and searches "little deeper" for utilities and specifications in hardware (sometimes like to comparing things) (only as an simple user,gamer and not an programmer or hardware maker) (but also comparing things in software and hardware in any machine is my computer-consoles life - and also gaming is same thing of course)
I am  REALLY VERY IMPRESSED  for the 4 versions of your various Atari ste videos you offered and i downloaded them (also i read the instructions tou wrote),till now i was only expected this "whole video thing" only in an "atari falcon (dsp)"(ok,i know that falcon already plays vcd with dsp)
i tested with steem all videos but i test specific "avatar video" at least in all memories (4,2,1,512k) and it runs even in 2 mb memory exactly like 4mb memory and also even in 1mb and 512k (even with worse framerate).it is an unbeleivable thing for me.But now,i would like to ask some questions :::

1)supposed to be on an "atari ste,with 2 or 4 mb" and your "cartridge ide hardware" and with an "ide hard disk" will run all these videos "EXACTLY AT THE SAME SPEED" as on my "pc,(2 core,2.9 amd regor) steem" and my "common ntfs hard disk"? or may be on normal 2-4mb atari ste with "cartridge ide" dont have "so glorius" framerate as an "pc with steem"?
2)what is the file format of an ide which connected your "cartridge ide interface" on an real atari ste? (fat?)
3)i know that atari falcon plays video cd (vcd) with its "dsp".But i dont interesting to a converstion in "dsp" right now.so,could atari falcon with the same or other (enchanced) "ide cartridge" makes better video resolution? with better video colors palette? with also better framerate? or atari falcon could do "exactly the same" videos with the atari ste with that or even future enchanced ide hardware from you?
4)another question (sorry i have lots of questions).could an very small atari st/1e video (10 seconds) be saved in "ramdisk" and then with the help of an "utility" run "directly from ramdisk"? could it be possible? please tell me this.
5)is possible for atari ste machines to "wear" "dsp chip" with any modifications (and play video vcd -cheap 1990 table like later 1993 cdi vcd)

if this "cartrige ide" was back then in 1990 i think lots of things will happen.not only on atari industry (i cant imagine what would be happened),but also in "computers video formats" and general "cheap atari video table machines" all these in my opinion always.

last but no least,if you could make a "copyright (R)" for your "cartridge-ide peripheral cable or hardware and software" (i didnt see any photo of ide cartridge until now) for use for commercial purposes.

so,good luck in all your works.
Title: Re: High-color video playback on STE
Post by: paulwratt on 08-10-2012, 07:51:42
@petari

BTW I got ur original archive videos to work fine in STEem, but not in Hatari (just started using it) - both on windows - try linux later

Paul
Title: Re: High-color video playback on STE
Post by: Petari on 08-10-2012, 10:31:24
Quote from: paulwratt on 08-10-2012, 07:51:42
@petari

BTW I got ur original archive videos to work fine in STEem, but not in Hatari (just started using it) - both on windows - try linux later

Paul


You need to set GEMDOS hard disk emulation in Hatari - set DIR of PC where Atari files are as Atari GEMDOS drive (C) .
Title: Re: High-color video playback on STE
Post by: Petari on 08-10-2012, 10:52:39
Quote from: petsasjim on 07-10-2012, 18:36:55
Hi,Iam Petsasjim1 (The Commenter From youtube Videos).
first to say again,i know nothing about "programming",but i am here as an only an old user(not only atari user),gamer who plays games mostly and searches "little deeper" for utilities and specifications in hardware (sometimes like to comparing things) (only as an simple user,gamer and not an programmer or hardware maker) (but also comparing things in software and hardware in any machine is my computer-consoles life - and also gaming is same thing of course)
I am  REALLY VERY IMPRESSED  for the 4 versions of your various Atari ste videos you offered and i downloaded them (also i read the instructions tou wrote),till now i was only expected this "whole video thing" only in an "atari falcon (dsp)"(ok,i know that falcon already plays vcd with dsp)
i tested with steem all videos but i test specific "avatar video" at least in all memories (4,2,1,512k) and it runs even in 2 mb memory exactly like 4mb memory and also even in 1mb and 512k (even with worse framerate).it is an unbeleivable thing for me.But now,i would like to ask some questions :::

1)supposed to be on an "atari ste,with 2 or 4 mb" and your "cartridge ide hardware" and with an "ide hard disk" will run all these videos "EXACTLY AT THE SAME SPEED" as on my "pc,(2 core,2.9 amd regor) steem" and my "common ntfs hard disk"? or may be on normal 2-4mb atari ste with "cartridge ide" dont have "so glorius" framerate as an "pc with steem"?
2)what is the file format of an ide which connected your "cartridge ide interface" on an real atari ste? (fat?)
3)i know that atari falcon plays video cd (vcd) with its "dsp".But i dont interesting to a converstion in "dsp" right now.so,could atari falcon with the same or other (enchanced) "ide cartridge" makes better video resolution? with better video colors palette? with also better framerate? or atari falcon could do "exactly the same" videos with the atari ste with that or even future enchanced ide hardware from you?
4)another question (sorry i have lots of questions).could an very small atari st/1e video (10 seconds) be saved in "ramdisk" and then with the help of an "utility" run "directly from ramdisk"? could it be possible? please tell me this.
5)is possible for atari ste machines to "wear" "dsp chip" with any modifications (and play video vcd -cheap 1990 table like later 1993 cdi vcd)

if this "cartrige ide" was back then in 1990 i think lots of things will happen.not only on atari industry (i cant imagine what would be happened),but also in "computers video formats" and general "cheap atari video table machines" all these in my opinion always.

last but no least,if you could make a "copyright (R)" for your "cartridge-ide peripheral cable or hardware and software" (i didnt see any photo of ide cartridge until now) for use for commercial purposes.

so,good luck in all your works.

Great ! You can write without capitals too :-) Falcon can play vcd ?  Well, I'm sure that can, but certainly not at it's resolution - 356 x 200 (240) or something like. It is just too demanding even with DSP. Actually, even MP3 stereo is even too much for DSP. I tried some players - they play at lover res and lover framerate. It is normal. and not fault of programmers. I remember from PC times arounf 1996 - then VCD playback was first possible. Requirement was min P1 class at 100MHz + local bus (PCI) video card with some playback support (much more than blitter does).

Those 'contigous' videos can play even with 512KB RAM.

1.  My goal is to playback at 25 fps and fullscreen of Atari STE, or at least close to it - like 320x160 - what is good for aspect ratio 16:9, currently most used. On real Atari STE. But it is just not possible with current hard disk speeds (if someone has solution, let me know).

Here you may DL video capture of playback on real STE:  http://atari.8bitchip.info/movpst.php

Cartridge IF + little mod in STE is required to get some very high hard disk reading speed. I will publish soon all docs for it. With it, and fast hard drive or even better Compact Flash card it can over 2.5 MB/sec via FAT16 filesys. And about 3 MB/sec in raw read. And it is enough for 25 fps at 320x160.

2. Cart. IF uses FAT16, and DOS/TOS compatible partitioning. TOS has limit of 512MB/partition.
For hi-color playback FAT16 is not good. It adds slowdowns, and 512MB limit may be problem too. Therefore, I will use raw disk access for it.
Just leave some space at end of drive, and write videos there. It is not elegant solution, but really don't see better.

3. This playback and format is not usable on Falcon or TT, because is based on accurate CPU timing.
On Falcon, 256 color playback is possible without bigger problems at 320x200 - only with IDE, what is faster than SCSI.

4. First 2 videos (links in this thread) made are exactly it - with Ramdisk . But no space for 10 secs.

5. DSP is not something with what we should deal in 2012. If you want some powerful add on for ST(E), choose something modern, and what is possible to buy.

6. Cartridge IDE was made by Polish Paskud - I don't know exactly when. But my solution is much faster.

Commercial purposes ? Hardly - there is no so much people interested.
Title: Re: High-color video playback on STE
Post by: Petari on 08-10-2012, 10:53:09
More details, real HW capture here: http://atari.8bitchip.info/movpst.php

Title: Re: High-color video playback on STE
Post by: petsasjim on 09-10-2012, 23:31:38
Hi PETARI,

1)""Great ! You can write without capitals too""
i like very much capitals even now.so in huge public places (lke youtube) i always prefer write with caps lock because i like it very much.now in forums its differrent.in some forums like "recorded amiga games" i ask to use caps lock and they let me use them,but my topics have few words (like longplay requests only).but i dont want to stress you because the previous reply i wrote was "really big" so........."better no caps lock" in some places like private forums with lots of discusions even i prefer caps.
2) i'm glad you use ramdisk in your first 2 videos.this think i said (ramdisk) just come to my mind,randomly,when you said "low res 4096 color video for atari ste" before i saw these videos you offered from here.
3)""Commercial purposes ? Hardly - there is no so much people interested.""
ok,for copyrights,you know.
4)""Cartridge IDE was made by Polish Paskud - I don't know exactly when. But my solution is much faster.""
certainly sure.
5)""On Falcon, 256 color playback is possible without bigger problems at 320x200""

is it possible in an overclocked 68060 falcon (always with your hardware,with your way) in these videos to have bigger "video resolution" than 320x200? (interlace or non interlace) (such 320x400*640x200*640x400 with at least 256 colors)?

6)kind a strange question : do you think that is it "software possible" and "hardware possible" to make this thing for "commodore amigas" too? [mostly for a500,a500plus (big left cartridge port)] and [a600,a1200 left pcmcia port] (deep inside me i believe-it is possible-but i talk only as a "user" without the knowledge).
7)from your knowledges,what is the best ever "cpu upgrade" for an "atari st/e" series only ( because i never owned a "big machine" - mega or TT)  official and unofficial (hack or overclock) (cpu upgrade) - and with which biggest "mhz"?
Title: Re: High-color video playback on STE
Post by: Petari on 10-10-2012, 11:05:13
5. I did not focus on playback on Falcon. Certainly, normal Falcon is still too slow, even with DSP - for decompressing some modern codec.  And likely, even 68060 at some 100MHz is good only for mpg1 (VCD).
640x200 or more is too much. Such resolutions required P2 range CPU at 600MHz. 

What I do is to avoid decompression - then datarate goes very high. With more res and colors it goes very-very much, and no so fast disk transfers possible.

As I stated, all this is just little experimenting of what is possible. But I don't want to go too far with it. STE is good target platform. For Falcon, you should see existing solutions - like Mplayer.

6. I'm pretty much sure that something similar is possible on Amiga. All depends from how fast can read data from hard disk (CF card).

7. I really don't know much about. And not fan of them. As I see, there is many problem with them, limited SW compatibility. Prices are still high.  My goal is not to have some faster oldie - if want fast machine then turn on PC  :)
TT is fastest - thanks to 32MHz CPU, but bus in TT is still at 16MHz - it means that some complex code runs not much fasterthan on Falcon - 3D for instance.

Title: Re: High-color video playback on STE
Post by: petsasjim on 10-10-2012, 13:11:47
nice,i understand.thank you for your time and your answers.
have a nice day.
Title: Re: High-color video playback on STE
Post by: Cyprian on 14-10-2012, 17:08:17
Quote from: Petari on 10-10-2012, 11:05:13TT is fastest - thanks to 32MHz CPU, but bus in TT is still at 16MHz - it means that some complex code runs not much fasterthan on Falcon - 3D for instance.

actually, term "16MHz bus" is really misleading because when we look at TT's nembech results we can see that it has more or less 2MHz bus for ST RAM and 3MHz bus for TT ram :)
Title: Re: High-color video playback on STE
Post by: Petari on 15-10-2012, 10:39:27
Quote from: Cyprian_K on 14-10-2012, 17:08:17
actually, term "16MHz bus" is really misleading because when we look at TT's nembech results we can see that it has more or less 2MHz bus for ST RAM and 3MHz bus for TT ram :)

I would discuss little about it:  as I know, difference appears only at higher resolutions and more colors. And the reason is that video buffer is always in ST RAM. At ST resolutions no slowdown, but by higher ones bus can not feed both video and CPU, so CPU must sometimes to wait.
By TT RAM no such conflict, of course.  Try membench at different resolutions, and will see what I talk.
I was even on idea to execute some 3D code in TT RAM, for speed. But exactly, because above, and that 3D games work in ST low res there will be no speed gain.
Title: Re: High-color video playback on STE
Post by: Petari on 15-10-2012, 10:40:09
Added some new videos and little speed blah on page:  http://atari.8bitchip.info/movpst.php
Title: Re: High-color video playback on STE
Post by: Cyprian on 15-10-2012, 23:02:32
Quote from: Petari on 15-10-2012, 10:39:27
Quote from: Cyprian_K on 14-10-2012, 17:08:17
actually, term "16MHz bus" is really misleading because when we look at TT's nembech results we can see that it has more or less 2MHz bus for ST RAM and 3MHz bus for TT ram :)

I would discuss little about it:  as I know, difference appears only at higher resolutions and more colors. And the reason is that video buffer is always in ST RAM. At ST resolutions no slowdown, but by higher ones bus can not feed both video and CPU, so CPU must sometimes to wait.
By TT RAM no such conflict, of course.  Try membench at different resolutions, and will see what I talk.
I was even on idea to execute some 3D code in TT RAM, for speed. But exactly, because above, and that 3D games work in ST low res there will be no speed gain.

I wouldn't like to off topic this interesting dicussion.
16Mhz bus in TT, this is fine speed for 68030 with 32Mhz due to it needs two or more cycles for bus-mastering.
According to Profibuch, TT has the same ST-Ram timing (250ns) and access split as ST - even cycles for Shifter, odd for CPU. Therefore 68030 has access to ST-Ram every 500 ns (as in ST) and it is real bottleneck.
Regarding video resolution, there is no difference in Nembench's results between ST-Low and TT-Low.
Title: Re: High-color video playback on STE
Post by: Petari on 16-10-2012, 10:59:44
There should be dependance of speed from resolution - when ST RAM is used. I don't know nembench - but you need to set code to run from ST RAM. And may do some tests with simple code full with mem transfers - then measure exec. time in differerent res. Then execute it with FastRAM flag set . I always believe most to own code  :)
I don't know exact timings of TT Fast RAM - so, you are right, I guess, considering bus timings. I actually repeated what saw on some pages about TT .

Title: Re: High-color video playback on STE
Post by: sasa on 16-10-2012, 16:17:59
Quote from: Petari on 15-10-2012, 10:40:09
Added some new videos and little speed blah on page:  http://atari.8bitchip.info/movpst.php

Most impressive so far
Can we get the files for Steem/ste, mste ?
Title: Re: High-color video playback on STE
Post by: Petari on 17-10-2012, 10:53:57
I must write here some explanations: 
Idea about high-color video playback was given some years ago, on forums. Then I said (after simple calc.) that it is not possible, at least not at 25 fps and some bigger res - because of need for very fast disk readings. Plus, converting to PCS format is pretty slow, and no batch conversion possible - as there was only ST version of Photochrome available. Even with accelerated Steem, it takes some 20 secs to convert 1 pic. Imagine 1 min of video, what is 1500 frames - how long it would take ...

Now, thanks to renewed interest about high-color displaying on ST(E) - we have already at least 4 formats: Photochrome, Spectrum, Cyg and MPP. And fast batch conversion on PC is possible - at least with Photochrome and MPP. And Photochrome is under development still.
So, one problem is solved.  Disk speed problem is of course not possible to solve with SW only. In any case, at least some 2-3MB/Sec data rate is needed.  And it is possible only with mine CATA adapter + little mod in STE. I don't see any other way for real Atari STE HW.

Hopefully, CATA will be available soon - I need to do some SW too - because fast loading code part must be in CATA ROMs.

So, because no people having enough fast hard disk adapters, I did not post STE SW and AV files. Instead it, couple ones for emulators. On them, it is easy thing, because disk loadings via GEMDOS emulation are very fast.
But real thing is playback on STE. Plus, AVI files of captures are much shorter than RAR-ed HAV files (not well packeable).

Then, I did most of stuff in fast conversion mode - still in experimenting phase, mostly.  Will redo some in Photochrome m3 mode, but it needs several hours for 1-2 min material. Then may post yet couple demos for emulators.

Currently trying to solve 320x200 px. playback on STE (in Steem it works fine, of course) .  My org. idea of using Read Multiple command is not usable on usual hard disks and CF cards (no support in drives), so I try it in little different way.  Will see how it be ..

And I want to try with MPP format too. As Cyg did not respond, will spare some time planned for that format  ;D  - I just point that all this needs really plenty of time.

Title: Re: High-color video playback on STE
Post by: sasa on 18-10-2012, 02:10:15
thanks for the explanation
which is the maximum speed on the mste with scsi hdd ?
Title: Re: High-color video playback on STE
Post by: Petari on 18-10-2012, 13:20:37
I measured about 1300KB/sec with Quantum 2GB drives, what was best I seen - and it is near to theoretical max. with MSTE internal IDE adapter - 1350 KB/sec.  Need 2x more for this  :)   .
Btw. fastest SCSI on Ataris is with ICD Link2 adapter - it can some 1800KB/sec with good drive.

Btw #2:  I practically solved fullscreen (320x200 px) playback, just need to fix some minor errors.  It can not be done with SCSI at all, because of way how updating colors - possible only with IDE disks.  Video soon.
Title: Re: High-color video playback on STE
Post by: paulwratt on 19-10-2012, 01:54:11
did someone delete that user and their posts yet? Jetenify

need a Capcha on the signup page (if there is not one)
Title: Re: High-color video playback on STE
Post by: Petari on 19-10-2012, 10:24:34
Spammers, please go on some more visited forum  ;D  We are small community.

Fullscreen AV playback - added funny demo on page:    http://atari.8bitchip.info/movpst.php
Title: Re: High-color video playback on STE
Post by: Petari on 26-10-2012, 16:17:19
Big improvements in quality:   http://www.youtube.com/watch?v=w5EbCT0W_Ds&feature=youtu.be

Done with new PCS5.10B - many new options there .
Will add files good for Steem, Hatari on site soon ..
Title: Re: High-color video playback on STE
Post by: petsasjim on 27-10-2012, 16:20:06
hi Petari, i have 2 questions,please.sorry,if the questions are "strange".

1)is possible all this perfect work be done on an 8bit machine (like atari 130xe) with lower resolution,lower fps,fewer colors (256 is the palette) with an specific utility (like PCS5.10B on  atari ste) but based on a 8bit paint program.(atari 130xe has a cartridge slot,too).

in the end of has video playback

http://www.youtube.com/watch?v=lUsDSNtRkTk

http://www.youtube.com/watch?v=9kT3ND_K-tg

2)
you nicely said """Big improvements in quality:   

http://www.youtube.com/watch?v=w5EbCT0W_Ds&feature=youtu.be

congratulations.the new improvement is resolution (320x160 -> 320x200)
now please tell me, we talk now about your new improvements,if "atari ste" with your software-hardware patent have in video 320x200x4096x25fps
then in atari falcon is possible to reach a bigger resolution? and how bigger resolution you think? (i know that this is a result from your patent and ramdisk and not from cpu power and the ste videoshifter).tell me please what you think : "68030 and videl" dont help to reach some higher resolution? with your new standards?

thank you for your time.
Title: Re: High-color video playback on STE
Post by: Petari on 29-10-2012, 10:55:40
I don't think that is possible on some 8-bit at all. There is no 256 color palette for whole screen. And if would, then disk speed would be insufficient. Only with very limited colors.  Actually, I did movie playback without sound on Sinclair Spectrum - it looks pretty ugly, because limited colors, not only colot number is limited, but number of colours per block.

Even on Atari STE, with Photochrome, saying 4096 colors is just simplifiation - it stays for whole screen, but we have limit of colour number per line, and it is only 48 with PCS. Quality depends mostly from converter - how well it can convert original pic, where every pixel may have any color to this limit.  And even more problems:

Actually, new, big improvement is not 320x200 - I did it already about 2 weeks ago. Improvement is called  error diffusion.
With only 4096 colors problem is gradient - when color changes gradually, very little in some direction. Most noticeable at horizons, but on human faces too + darker parts. 4096 color is just not enough for it, and result are big 'stains' with same color instead smooth transition. Therefore error diffusion is used by such conversion - you may see it in all paint programs by color reduction.

Atari Falcon is not fast enough for bigger resolution video playback .  320x200 is max, where can get 25 fps. I'm sure. Using 256 color mode, and quality img. preprocessing.
Title: Re: High-color video playback on STE
Post by: jvas on 29-10-2012, 11:02:49
This is for the 8bit: http://www.youtube.com/watch?v=owHCjEWjAvs (MyIde interface through the cartridge port)
Title: Re: High-color video playback on STE
Post by: petsasjim on 29-10-2012, 11:19:28
""Improvement is called error diffusion.""

ah ok,i understand.

thank you for all your answers.again,one question.
what do you think is it better to have on video with an atari ste 4096 limited palette screen (48 per line)?
or an atari falcon "true" 256 colors on screen?
with other words which from two is "better looking"?
Title: Re: High-color video playback on STE
Post by: Petari on 29-10-2012, 15:01:56
Definetly 256 colors on Falcon.  Why - it is actually 256 colors from palette of 256000 colors, and any px can be any of 256 colors.  With this specs, and good preprocessing, you can get really good looking video, practically with almost perfect colors.
At res 320x200 (maybe 320x240). More not - disk speed lomits, then at higher res. Falcon will slow down too much (bus speed related).

Some more explanations:

Original img, with 16M colors:
(http://atari.8bitchip.info/p/face.png)

Converted to STE capable 4096c,  54colors/line:
(http://atari.8bitchip.info/p/faceMPP48Cl4096.png)
Errors are most visible on face.

Conv. to 256c , indexed:
(http://atari.8bitchip.info/p/face256.png)

Same as above with error diffusion:
(http://atari.8bitchip.info/p/face256ed.png)
Almost perfect.

For illustration, converted to 16c, indexed:
(http://atari.8bitchip.info/p/face16.png)

16c, indexed + error diffusion:
(http://atari.8bitchip.info/p/face16ed.png)

Title: Re: High-color video playback on STE
Post by: kovacm on 29-10-2012, 15:17:53
Quote from: Petari on 29-10-2012, 10:55:40
I don't think that is possible on some 8-bit at all. There is no 256 color palette for whole screen. And if would, then disk speed would be insufficient.

they have some "Sunrise IDE", MyIDE, SIO2IDE...
e.g. SIO at Atari XL is 52000 bit/s (only 6.5 KB/s) and video memory is up to 8KB. so only some kind of similar solution like CATA IF would enable video playback on XL...

QuoteAtari Falcon is not fast enough for bigger resolution video playback .  320x200 is max, where can get 25 fps. I'm sure. Using 256 color mode, and quality img. preprocessing.

320x200, 25 fps, 256 color - is arround 1.6MB/s?

standard Falcon IDE can transfer up to 2.8MB/s (PP, you manage to make faster IDE on ST tan on Falcon! :D)


EDIT:

BUT why not 320x200 in TC ?? it would be 3.2 MB/s - at least BUS slowdown is less than in 256 color mod but screen size is bigger thus better quality. And wouldn't 030 with cache be fast enough for at least simple RLE compression (in preprocessing video lines less prone to changing color for better RLE compresion)?
Title: Re: High-color video playback on STE
Post by: Petari on 29-10-2012, 15:52:15
Quote from: kovacm on 29-10-2012, 15:17:53

they have some "Sunrise IDE", MyIDE, SIO2IDE...
e.g. SIO at Atari XL is 52000 bit/s (only 6.5 KB/s) and video memory is up to 8KB. so only some kind of similar solution like CATA IF would enable video playback on XL...

320x200, 25 fps, 256 color - is arround 1.6MB/s?

standard Falcon IDE can transfer up to 2.8MB/s (PP, you manage to make faster IDE on ST tan on Falcon! :D)

EDIT:
BUT why not 320x200 in TC ?? it would be 3.2 MB/s - at least BUS slowdown is less than in 256 color mod but screen size is bigger thus better quality. And wouldn't 030 with cache be fast enough for at least simple RLE compression (in preprocessing video lines less prone to changing color for better RLE compresion)?

8 bit computers generally have much slower bus, and it alone is enough to make something similar not possible.

Yes, it is about 1.6MB/sec. And Falcon can more than you thought:
http://atari.8bitchip.info/ahpt.html
But only in lower res and color modes. If set true color, it will fall under 2300KB/sec.
SCSI is slower, about 1.7MB/sec max.
In reality, you can get max 80% of such speeds via filesystem, and only if take care about loading chunk sizes - fastest is when they are equal to cluster size or it's multiple.

Slowdown is of course more in TC mode - then 1 screen is 128KB, while with 256 colors it is 64KB. 128KB means that CPU is slowed down sometimes, because RAM and bus can not suply both video and CPU enough fast. But, as said, with 256 colors mode you can do almost perfect colors.
Only that preprocessing needs then more time and care - best is to divide video in scenes, and do each one with own palette - then will be minimum flickering.

Some simple compression would work by simpler pictures. But by usual material like movies or camera shots of people, gain is too little. Even with RAR you can not pack it well - sometimes can get only 10-20% shorter data.
Title: Re: High-color video playback on STE
Post by: petsasjim on 29-10-2012, 19:10:53
hi Petari,thank you for your instructive and specific answers,with the nice photo examples.
be good.
Title: Re: High-color video playback on STE
Post by: Cyg on 29-10-2012, 23:51:40
Hi Petari !

Sorry for the mute since the last weeks but I had a baby in between, my son came sooner than expected !

I just watch 2 of your trailers, Skyfall and SW, really great ! But if I think that the quality can be improved as most of the frames I captured use only 200 colors out of the 4096...

Could you send me some of your frames, so we can compare the result ?
I improved my algo in quality by few % but it takes longer time to encode, moreover I did it in VB.Net which is not optimal by design :-)

Can you still increase the bandwith to manage fullscreen display, something like 416x270 / 48 colors per line = 56160 + 25920 = 82 082 bytes per frame ?

I will prepare the replay package for 320x200 / 54 colors + 2 global color

CU
Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 30-10-2012, 11:05:29
Congratulations for your son, Cyg :-)
I think that 4096 colors is little misleading - more important is colors/line value. As it is limited to around 50.
Plus, by darker scenes, we have only few bits for colors, and it results in 'stainification' of pic. If you have some better term for it, let me know.
So, I think that error diffusion is what made big improvement. Even if it is not perfect yet.  And it is good to lighten little pic when is dark - will look better overall.
I can send you lot of frames. What format you want ?

No way to achieve 25fps 4096 color anim at higher res - at least not without some serious mods, updates in STE.
We can raise horizontal res, but vertical not. Beause then will be even less time to load bitmap data.  With 270 lines, you'll have only some15% time for loading, while need more data than with less lines.
Even horizontal is possible problem - because then disk may not prepare data enough fast.  Currently, at 320px I have about 20microSecs pause between sectors. It is enough with fast CF cards. But under 10 will be for sure not enough.

What I see as perspective is to stay at 320x200, but going on more colors/line. Fast load with CATA allows about 70 colors/line.
Using  movem.w (a0),d0-d7/a1-a7   transfers very fast 32 bytes (yes, because bug in CPU) directly from IDE to shifter - a0 is here destination $FF8240 . It takes only 72T states. Just repeat it 4 times in row, + one with less regs at end.

Title: Re: High-color video playback on STE
Post by: Cyg on 30-10-2012, 15:34:07
Thanks a lot :-)

I understand your bandwith issue, it would have be nice to have a 16/9 display in 400x200 for instance.
When you will be managed to display 70 colors per line, it will not testable on any other computer or emulator than yours, but I could adapt my converter after some few test with you, from a captured color test with pixel measures or maybe your more fluent at counting the cycles :-)

During your display at 25fps, I suppose you can not go up to 50fps because you need the top&lower borders during 2 vbl to fully load the next picture, about 2 * 80 lines * 512 cycles per line) ?

About the rendering, I just test your sample to show you my results :
- the original 4 million colors "perfect" pic
- a post-dithered picture with a floyd-steinberg algorithm using the existing colors
- a pre-dithered picture with a simple algorithm which prepare the original picture by choosing the cell or the floor value during the 4096 colors rounding method, and exchange the rule every pixel.

I ran these tests at work but my HigheSTcolor executable here is not perfect, it doesn't use the 2 global colors at all, the quality should improve by little with this 2 additional colors but I need to release it at home.

(http://www.top250filmsdvd.com/atari/1-Original.png)
Original, all sizes are doubled to display the details

(http://www.top250filmsdvd.com/atari/2-faceMPP48Cl4096.png)
MPP result as previously generated by Petari

(http://www.top250filmsdvd.com/atari/2-Hicolor%20result.png)
HigheSTcolor result, no dithering

(http://www.top250filmsdvd.com/atari/3-Hicolor%20PostDithered%20result.png)
HigheSTcolor, with post-dithering

(http://www.top250filmsdvd.com/atari/6-PreDithered%20Hicolor%20result.png)
HigheSTcolor, with pre-dithering

For darker pictures, I think both MPP & Photochrome seem to have a global illumination issue, the result is darker than the original, which does not help on this difficult case to optimize.
The dithering helps a lot in case of low color pictures.
Example:

(http://www.top250filmsdvd.com/atari/A1-Dark%20picture.png)
Original, a dark capture (bad quality and blurry...)

(http://www.top250filmsdvd.com/atari/A2-Dark%20picture%20Hicolor%20result.png)
HigheSTcolor, no dithering: bad result

(http://www.top250filmsdvd.com/atari/A3-Dark%20picture%20Hicolor%20PostDithered%20result.png)
HigheSTcolor, with post-dithering (floyd steinberg)

(http://www.top250filmsdvd.com/atari/A4-Dark%20picture%20Hicolor%20PreDithered%20result.png)
HigheSTcolor, with pre-dithering (round at cell or floor on odd or even pixels)

If from a frame to the next frame, you choose the pre-dithered picture with method 1 then the pre-dithered picture with method 2, it could lead to a feeling of mixed of the both, especially for static sequences or backgrounds. Maybe it's not so obvious at 25 fps, but it is at 50 fps.

(http://www.top250filmsdvd.com/atari/7-PreDithered%20Hicolor%20result%20mixed%2029000%20colors.png)
HigheSTcolor, theorical result of a fast display between 2 slightly different pre-dithered pictures

You could send me a few seconds sequence (100 frames ?) in PNG format or zipped bmp in 320x200 and maybe some of the results to compare.

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 30-10-2012, 15:56:52
400x200 is maybe possible. But let's solve some simpler things for beginning.

50 fps is too-too much.  During playback, I load half of bitmap of next frame in first border period (bottom, then top), in second one second half of bitmap + audio (1KB) . There are some paddings, because must maintain whole sector loadings.  Color data (same one) is loaded 2x in order, directly to shifter, and while it, data rate is not so critical, only that disk must not make pauses between sectors. 
With 320x200, synced color loading during scanlines is a must, because there is only some 33% of time available for over 800KB/sec. With 320x160, you can load everything in RAM, and use normal hi-color code, because have almost 50% of time for loading.

I will post you some sequences.
My eyes say that post dithering looks little better - but all this may be little subjective.
In any case, for animations we can not use 50 fps. And not 30K color modes too.   Except :  what may be interesting is 12.5 fps with 30K color modes - for some cartoons, which are made at 12 fps   .

Title: Re: High-color video playback on STE
Post by: Petari on 31-10-2012, 10:55:15
Here are 100 pic sequences:   http://atari.8bitchip.info/AVA2.ZIP
http://atari.8bitchip.info/LGR.ZIP
http://atari.8bitchip.info/UT2.ZIP

8MB is len of each. I choosed some harder cases - Avatar scene here is much harder case than flying. By LGR error diffusion is crucial. By UT2 too, I guess.
Just few samples done with other hi-color solutions:   http://atari.8bitchip.info/hand.ZIP
MPP lacks error diffusion, otherwise makes very accurate conversions. Don't know will Zerkman deal with error diff.  Douglas Little working currently on fixing problems (mostly hor. strikes appearing) with PCS, so let's wait little - I just received some test v., but will test it later.
Title: Re: High-color video playback on STE
Post by: Cyg on 31-10-2012, 15:57:24
Thank you Petari, I am going to process your pictures but my main issue is the overall performance of my optimizer. I decreased it yesterday night by 3 but it is still too slow (VB.net...). I am thinking about converting it to C++ now that it's stable, even if I am not fluent at C++.
I have one inner loop that takes 90% of the overall time consumption for only 50 lines of code for the whole function, it would have been easier if I could have made a specific code in C or C++ for this function only and call it into my VB.net code.

I had an idea during my long walk this morning due to metro issues, can you confirm that at every fps, you read the full palette informations, meaning that you read twice the same data every 2 fps and in realtime (during the scanline) ?
If yes, then you could easily read 2 full different palette informations if they are sharing a same bitmap ?

If yes, then we can achieve a 29000 colors display at vbl framerate, leaving a smoother idea and more colorful :-) Something like the fake 100hz or 200hz TV.

1 bitmap + 2 palettes is the way I do crossfade between 2 pics: the same bitmap/pixels are shared between 2 different palettes. 1 pixel has 2 possible color, the first lead to the first picture, the 2nd to the 2nd pictures, it just a matter of optimize for 6 dimensions and not 3 dimensions (RVB values per picture).
Then I just need to fade between every pairs of colors, but you don't even need to fade for 2 frames, you would only need to read the 1st pal then the 2nd pal.
The optimisation is harder/longer but the overall result is better, as you can see when I simulate the result that our eyes should see at 50 fps :
(http://www.top250filmsdvd.com/atari/higheSTcolor%20crossfade%201pix%202%20pal%20theorical%20result.png)

I keep on doing test for optimization, here are some new results from your samples :

(http://www.top250filmsdvd.com/atari/1-hand%20original.png)
Original

(http://www.top250filmsdvd.com/atari/3-handErrodiffusion.png)
Error diffusion

(http://www.top250filmsdvd.com/atari/4-hand%20MPP.png)
MPP result

(http://www.top250filmsdvd.com/atari/5-hand%20higheSTcolor.png)
higheSTcolor basic result

(http://www.top250filmsdvd.com/atari/5-hand%20higheSTcolor%20-%20predithered.png)
higheSTcolor pre-dithered result

(http://www.top250filmsdvd.com/atari/5-hand%20higheSTcolor%20-%20postdithered.png)
higheSTcolor post-dithered result

(http://www.top250filmsdvd.com/atari/6-hand%20higheSTcolor%20-%201bitmap%20+%202%20pal.png)
higheSTcolor theorical result for 1 pix + 2 pal as detailed above

(http://www.top250filmsdvd.com/atari/AV-0%20Original.png)
Original

(http://www.top250filmsdvd.com/atari/AV-higheSTcolor.png)
higheSTcolor

(http://www.top250filmsdvd.com/atari/AV-higheSTcolor%20predithered.png)
higheSTcolor pre-dithered

(http://www.top250filmsdvd.com/atari/AV-higheSTcolor%20postdithered.png)
higheSTcolor post-dithered


Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 31-10-2012, 17:49:14
Yes, I load every color data 2x in row - it means in case of PCS 2x20KB (longer because of paddings) in 1/25 sec - but there is time for it.
Using different palette infos for same bitmap then is great idea. Of course, it will increase file sizes, but that should be not problem.

Considering speed problems: I'm not some good C programmer. Only what can say is that crucial parts, which execute most of time and many times should use minimum function calls, best is not at all - at price of some more lines slow parameter transfers etc. will be avoided.
Title: Re: High-color video playback on STE
Post by: Cyg on 31-10-2012, 17:55:33
I just add another sample, generated with 1 bitmap and 2 pals mixed together to simulate the result for our eyes :

(http://www.top250filmsdvd.com/atari/AV-higheSTcolor%20-%201bitmap%20+%202pal)

Don't know if it's really better but blurry background is a nightmare to optimize with low number of colors.
I think the better is to check it during the animation and not only on a static picture, the same for the pre-dithered or post-dithered method.
I will run the optimisation for each kind of method but you have to be patient has it will take a long time to do.
I am on weekend during the next 4 days, it should be over when I will come back, I will also send you the read & replay code.

Cyg
Title: 80 colors/line
Post by: Petari on 02-11-2012, 14:24:07
I did ROM code for 80 colors/line. It is stable.


  Test patterns -  STE video capture

res is 640x396, on STE it is 320x198, so every px. doubled h-v.


There is update of 80 colors during 1 line.
With  movem - all 16 colors at once. 72T states.
72 px - nice visible at bottom.
Used 5 different color gradients, to see what palette is where.
First, what need to be preloaded is grey, then green,
then red, then blue and yellow as last. At end of line loading
grey for next line. Color 0 in it is border color too.
Bitmap indexes are in order:  0,1,2..15,0,1... 15 as px 319.
It stays for fist 10 lines, then all is shifted 1 px left,
so lines 10-19 start with 1. Lines 20-29 start with 2, etc.
Lines 160-169 are same with 0-9.
After it, all bitmap is 0.


With delay 4T in compare to PCS timing - PatD4.png:

On shot is well visible color distribution.
Grey palette is less present  than others,
because is gradually overwritten by green one.
Therefore, I think that start point should be moved
by some pixels right (adding some delay in code)
+28T/px seems as reasonable. - then we will have perfect
split on lines. Currently, there is 28px px black at end.
Of course, then there will be less 'yellow' palette, but can
not better - 320 is not divideable by 72 .

By me, the best timing, 32T - PatD32.png .

File struct for 80 col/line :

198x160 bytes bitmap data.
Padded to $7C00. Last 64 bytes contain initial color data.
First palette and optional second - if use 2 different palettes
for same bitmap, for getting better colors .


Color data for 198 lines:
160 bytes for 1 line. 3 lines together with 32byte padding
make 1 disk sector.  This is reason why 198 lines 'only' -
to be divideable by 3.
So, 66x512 bytes with paddings. But let it be task of SW
for joining pictures in anim file...

So, 198x160 bytes are color data.  Last 32 bytes must be
all same, and choosen border color - so will not be visible
line 199. (where initial colors for line 1 are) .

(http://atari.8bitchip.info/p/PatD4.bmp)

(http://atari.8bitchip.info/p/PatD32.png)




Title: Re: High-color video playback on STE
Post by: Cyg on 02-11-2012, 17:16:38
Hi Petari

Very impressive performance results ! 80 colors for 320 pixels will lead to a quality equivalent to my 192 pix with 48 colors, in average 1 color every 4 pixels.

I already have a full-set of Avatar 2 calculated with the pre-dithered method, it looks very nice. Tonight I am sending you this set, maybe another with post-dithered and the display source code + explanations of the format. Double palette for 1 shared bitmap is also under process but it takes longer to calculate because of its complexity, I will send you the current results for you to compare the results of each method (post dithered / pre dithered / double palette 29k colors).

I will read very carefully your screen-test above and will implement this timing in my optimizer, I propose you to make a test on one picture first to validate that cycles are in phase with pixels.

Best regards,
Cyg
Title: Re: High-color video playback on STE
Post by: Cyg on 02-11-2012, 23:27:36
Petari, what about the background color in the borders ?

If you want a black border I have to force index 0 to 0 on the 1st pal for the left border and on the 5th pal for the right border and the beginning of the left border on the next line.
Unless, borders will have horizontal colored lines.

Cyg
Title: Re: High-color video playback on STE
Post by: Cyg on 03-11-2012, 03:37:20
Petari,

Here a 1st package : http://www.top250filmsdvd.com/atari/Petari video HigheSTcolor.zip (http://www.top250filmsdvd.com/atari/Petari%20video%20HigheSTcolor.zip)

The source code is rought from my last demo, with a quick code cleaning but there is a lot of unuseful code, sorry, but it should only display the selected file.

VBL : the replay routine, really starts at prestab_pic
BSS.s : to configure the files to display

The higheSTcolor files are, for Avatar 2 :
- one no-dithering sample
- one post-dithering sample
- 100 pre-dithering sample, ready for video :-)
- one double palette sample

I will post the 100 pictures for each mode later tomorrow,

Cyg

Title: Re: High-color video playback on STE
Post by: Petari on 03-11-2012, 18:09:19
I made table for pixels  0-319 and indexex 0-15, and what table to use.
5120 bytes. Will post it later.
Will check your stuff ...

Title: Re: High-color video playback on STE
Post by: Cyg on 03-11-2012, 20:54:41
Hi Petari,

Yes a table will help, you confirm me to force to black index 0 on left & right borders ? I am preparing the trick in the converter.

Here the 2 last methods results :
http://www.top250filmsdvd.com/atari/AV2_1pix2pal.zip (http://www.top250filmsdvd.com/atari/AV2_1pix2pal.zip) : Avatar 2, 1 bitmap shared between 2 palettes for a 29 000 colors feeling at 50fps
http://www.top250filmsdvd.com/atari/AV2_Flat and post-dithering.zip (http://www.top250filmsdvd.com/atari/AV2_Flat%20and%20post-dithering.zip) : Avatar 2, 1 no-dithered bitmap, 1 post-dithered bitmap, 1 palette (identical for both bitmap)

Cyg
Title: Re: High-color video playback on STE
Post by: Cyg on 04-11-2012, 01:58:20
Petari,

I started configuring a 80 colors/line optimization, the first result shows a 10% decrease in the global error (euclidian distance to the original), so don't expect a really better rendering, except in some details and for the double palette method (-30%) as combinations are more numerous whereas colors remain as important.
The main issue for improving the quality is the number of distinct colors, 4096 are too few.

(http://www.top250filmsdvd.com/atari/54%20cols.png)
higheSTcolor, 54 colors per line

(http://www.top250filmsdvd.com/atari/80%20cols.png)
higheSTcolor, 80 colors per line, the nose and front is better, no change in the background

(http://www.top250filmsdvd.com/atari/post%20dithered%2054%20cols.png)
higheSTcolor post-dithered, 54 colors per line

(http://www.top250filmsdvd.com/atari/post%20dithered%2080%20cols.png)
higheSTcolor post-dithered, 80 colors per line

(http://www.top250filmsdvd.com/atari/higheSTcolor%20pre%20dithered%2054%20cols.png)
higheSTcolor pre-dithered double palette mix result 29k theoric colors, 54 colors per line

(http://www.top250filmsdvd.com/atari/higheSTcolor%20pre%20dithered%2080%20cols.png)
higheSTcolor pre-dithered double palette mix result 29k theoric colors, 80 colors per line

The files for your test : http://www.top250filmsdvd.com/atari/80 cols.zip (http://www.top250filmsdvd.com/atari/80%20cols.zip)
Pix files size 32000 bytes, the pal files should size 80*2*200=32000 bytes but I have kept the 2 global color information at the beginning despite it is not useful because index 0 and 1 are used in each of the palettes per line, so the pal size is 32004 bytes and the needed colors starts at 4, not 0.
2nd pal starts at pixel 32 like in your parD32 capture and a palette last for 72 pixels, but I am not sure if the absolute pixels is 31 or 32 due to a blur during the resize process.

Best regards
Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 05-11-2012, 10:49:58
I was offline during weekend. You did a lot in meantime, as I see  :)
Will look in it today afternoon.
Here is color/palette table:  starts at px 0, color idx 0, then idx 1 ... idx 15. Then px 1, idx 0,1,... Total 320x16 bytes.

http://atari.8bitchip.info/PXMAPD32.BIN

I made anim from 100 frames you posted (Ava2 scene) - looks pretty good. Need little to clean up it and add audio, then I will post it too. I used basically same code as with PCS playback except palette updates self, of course. There is centering by using Timer B. It is version for Steem, not real HW, so anyone can try.
Title: Re: High-color video playback on STE
Post by: Petari on 05-11-2012, 15:09:38
Here is it:

http://atari.8bitchip.info/CYG160.ZIP  (3.5MB)

There is muxed AV file, playback SW with src. for Steem, Hatari (not for real STE) + PC SW for muxing.
Title: Re: High-color video playback on STE
Post by: Cyg on 05-11-2012, 16:40:21
Very nice :-)

I think you choose to package the method with a dithering every 2 pixels.
I made it alternatively change the odd/even rule 1 frame every 2, to simulate a 25 fps 29k feeling but we can still a little see the dithered pixels.

Could you make it for the other methods, especially the other dithering and the "2 palettes 29k colors feeling" ?

I am working to adapt a simplified version of my .Net code to make it work in C for fast frame encoding purpose, not for other Hicolor FX that will remain in .Net.

Thank you
Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 06-11-2012, 11:06:58
I did not have time to try yet alternating palette (29K feeling), but will do it this days for sure.

Considering border color by 80 col/line:  it is somehow ST design problem - they should give special register for border color, and not using color idx 0.
  If read what I wrote here earlier, forget it. I solved separated color 0, index 0 of line and border color. That would mean in fact 82 colors/line. And increases not file size, because there are paddings already. And no need that hi-color conversion SW take care about it. All data will be aranged by muxing SW. You need to set SW so, that have 16 free selectable colors for preloaded (I mark it as Palette 0 of line) palette. And of course, same for other 4 palettes. Hopefully, it will make things simpler, and more free colors never harm.

Line code looks like :

line1   macro

   lea  $FFFF8240.w,a0   * 8T

        asr.l        #8,d0   * 24T
        asr.l        #8,d0
        asr.l        #8,d0
*        asr.l        #8,d0    * 96
*        nop


* Following gives 28T states less time for drive, so better to preload it ahead
* at previous sector
*    move.w  (a0),d0    * 8T   This is first color of palette 0, others
*  are OK already

* d1 holds color idx 0 of palette 0 for line :

    move.w  d1,(a0)   * 8T  - this writes at exact line start
    asr.l  #6,d0   * 20T

* Note: all readings from RAM, shifter are actually writes there, from IDE port
* due to CATA logic

    movem.w  (a0),d0-d7/a1-a7    * 72T, 32 bytes - overshot !
    movem.w  (a0),d0-d7/a1-a7   * 72T
    movem.w  (a0),d0-d7/a1-a7    * 72T
    movem.w  (a0),d0-d7/a1-a7   * 72T  , 288 so far
    movem.w  (a0),d0-d7/a1-a7   * 72T - this is for border and next line

    move.l  usp,a0   *4T  -  dummy buffer for paddings
    movem.w  (a0),d1-d7   * 16 bytes (overshot) , padding 1/2,  8+32=40T
states

* in d1 loaded next line pal0, color 0 !

    endm

Line2 is same, just 2 bytes less padding, by line3 no padding.  3 lines
together are in 1 sector.

It is on muxing SW to place all data on proper places. Player just need to
preload reg d1 with pal0, idx 0 color before starting hi-color show part.


Doing similar with usual from RAM copying code would be not simple, I
guess - I have here free time before color updates, while usual hi-color
code preloads registers with color data then.

What format your SW should produce for this:
I think that best is that you do:  200 or 199 lines bitmap, as it is already.
Then 32 bytes of preload, with all 16 free colors - border color will be set independent of it.
After it 199 line color data, starting at palette1, then 2, 3, 4, and 0 of next line.
160 bytes for 1 line. As you did already.
At end should be 32 zeros or better nothing (no need to fill preload data for not existing line 201, but not relevant for me, do as it is easiest for you). Muxing SW will place border color where is needed.
Title: Re: High-color video playback on STE
Post by: Petari on 06-11-2012, 15:30:02
Example with 80 col/line :

http://atari.8bitchip.info/Lorax80cplTest3.avi       (13MB)

Done with test version of new PCS, fast mode m4, error diffusion. Overall looks very good, especially as there is a lot of gradients in video.  Later I will do it with some slower, better quality mode ..
Title: Re: High-color video playback on STE
Post by: Cyg on 06-11-2012, 16:57:56
Nice video indeed, very colourful !

I hope to finish my C portage by tomorrow, it will include my modes 54 colors, pre&post dithering and maybe the 2 pals mode (or by thursday) + your 80/82 cols mode.
I believe that your previous bin file is no longer up to date ? You can explain by words or with any csv file the rule, absolute/relative index color, pixel coord where it starts & ends.

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 07-11-2012, 10:51:54
Bin file is OK and up to date. I was likely lucky with it - and perfectly fits new, independent border color scheme too, because end of line is at right moment - better said start moment of writing next line's first palette was at righ place for border update.

I don't use csv files. It is simple binary file with byte values, for 320 hor. pixels, and all possible color index values for them 0-15.
Values can be only in range 0-4. And mean palette number of 5 palettes for that line (0-4), from which color will be used - for current px and color index.

Starts of course at hor 0, vert 0 px (actually, vert is irrelevant, table stays for all lines). First 16 bytes are for px. 0,v. First color index 0, then 1,2 ...15. Color index is what stays in 4 bitplanes for that pixel.
Then for horizontal px. 1, again 16 bytes, for color indexes 0...15. And so on up to px. 319.
Size is of course 320x16 bytes.

I don't know what you mean under relative index color -  I know only indexes 0-15 for ST(E) low res mode.

Table is actually pretty much periodical. Changes (it is always change to palette up for some index) follow well clock cycles of used code. They happen usually after 4 cycles - right so much takes updating of 1 color (word write). When movem execution starts there is then 12 cycles with same pattern - because movem opcode fetch takes 8 cycles.  I hope that it was understandable .

Added video with custom border color:

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

Ah, and one question:  how do you perform pre-dithering/error diffusion ? Can I do it right with Photoshop or some other SW ?
Title: Re: High-color video playback on STE
Post by: Petari on 07-11-2012, 13:42:13
Tried Cyg 80 col test pic on STE :

(http://atari.8bitchip.info/p/Cyg80_1.png)

Of course, there are errors with some colors - it would be little miracle if it worked without timing table. Otherwise format self is good enough - but no need for global colors (4 bytes at start). I added option to set desired border color in muxing SW.

Btw. my test pic. PatD32.png is pretty accurate - there is no resize. I was able to adjust capturing card with BT Tweaker to get exact 640px width. But sometimes is really hard to judge exact pos. - it is analog thing, there are some ringings for instance. As said, it is pretty periodical, so I finished table faster than thought, last 200 px. entries went fast - I checked only couple times on screenshot. And is 100% OK.
Title: Re: High-color video playback on STE
Post by: Cyg on 08-11-2012, 21:48:03
Hi Petari,

I am very close to have my converter running on C and then going really faster.
Could you please send me some frames from the Lorax to tune my implementation and compare to your video result using Photochrome ?

Thanks !
Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 09-11-2012, 10:40:19
Sure. I will post it afternoon.
Photochrome code is not final version yet, of course.
I'm on to do first tests with dual palettes on real STE and ava2 conversions made by you. But don't have TV or some CRT monitor now. So, can look it only with TV card. Will try to make capture so, that blur together 2 frames - then should get average colors from 2 color data.

I want to try pre-error diffusion while converting 24bit pictures to 12-bit colorspace (4-4-4) - but can not find SW what can do it - do you know something ?
Title: Re: High-color video playback on STE
Post by: Petari on 09-11-2012, 14:55:18
Here is 400pic from Lorax:    http://atari.8bitchip.info/lor400fr.rar

If you can, please make seq. numbered with 4 digits, like:  (nam)0000.ext ... (nam)0399.ext   .  That way you can make anim file too with suplied muxing SW and try in Steem.

I thinkered little about overscan playback.  Rough calculation says that max about 400x220 can be possible.  At so high res, part of bitmaps need to load during scanlines - it means that we can not have much colors/line.  56 seems as max. That would be 3x14 . But I don't know how to do overscan, so need more details. Blitter is not option here - slower than cart. port reversed read.  If maintaining overscan takes too much CPU time, it is not possible.  Do you have line color update code without blitter ? If no, I can do some proper for cart. port, but need to know how to achieve 400px wodth.

Title: Re: High-color video playback on STE
Post by: Petari on 14-11-2012, 14:52:20
So far the best video:   http://atari.8bitchip.info/LorSierra24a.avi 
Gradients are almost perfect - and they seem as hardest problem. I made this with converting 24bpp images to 12bpp (4096) colors with Sierra 24a error diffusion at 100% .  Was seeking for long time for somethin like. Problem with almost all error diffusion ways is that they are not really good for animations. We need static pseudorandom dots of diffusion on static scenes - otherwise there will be unstable. Ordered diffusion produces such, but random looks much better. After it just used PCS to convert them without dithering - in this case 80 col/line mode.

Somehow related with above:    http://atari.8bitchip.info/CYG1602P.ZIP
This is video with player SW (Steem version) with alternating color data for 1 frame, made from
this:    http://www.top250filmsdvd.com/atari/AV2_1pix2pal.zip   

It works, and we have really feeling of more colors.  However, problem is that gradations are not stable.  It would be good to do more tests, with another material - for instance from Lorax pics, what I posted, so can see better difference.  I did not test on real STE so far, because I need to put part of code in ROM, what goes not so fast.  But think that in Steem can see even better unstability - especially if use run to next Vbl opt. in Steem Debugger.

And again related with above:  dual (alternating) color will be necessary for sure, for overscan.
It is because I can achieve it only by loading part of bitmap data during scanlines, so interleaved with color data . And that means that must load 2 different streams in any case, even if color data is same - so why not do alternating one then.  Data rate will be about 2.4 MB/sec for 416x231 px. And I have already almost so much with 80 colors/line mode.  With overscan will go back to 48 colors/line - no time to load more, because need to maintain overscan, what costs some CPU tiume.  At moment , I'm little stucked with overscan, because MPP works not really good on real STE. Need to fix some things in converting SW too . 


Title: Re: High-color video playback on STE
Post by: Cyg on 14-11-2012, 18:16:26
Hi Petari !

Sorry for the delay, I am very busy at business & home but I just finished a stable and quite optimized version of my converter in C. It is surely not the quickest but the result is nice, it takes 1 min per picture actually and I hope to divide it by 2 again. (I started from 1h in VB.Net !). But in fact the time depends of the quality, I try to find a parameter to make it dynamic, the fastest optimization could take 5-6s with an average result.

I also have to add some dynamic parameters before sending it to you : dithering mode, number of cols. I effectively have an overscan routine compliant with any ST, with around 48 colors that you could improve with your hardware tricks.

I agree about the stability & gradient.
The pre-dithering method + 2 alternative palettes should help a lot because it's stable. Post dithering is unpredictable as it depends on the available colour of the optimization.

I can not run CYG1602P.TTP under Hatari here at work, will try it with STeem at home in a couple of hours.

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 15-11-2012, 14:00:26
I will not use more than 48 colors/line with overscan. It could load more, even 5-6 palettes in theory, but problem is that no enough time to load bitmaps in border periods, so need to load part of bitmaps during scanlines - what means interleaved bitmap data with color data. What seems as good is:  3 palettes and 75 (avg) bytes of bitmap data in 1 line. It means that load 2/3 of bitmap during scanlines, and only 1/3 in borders. Should be good for 416x321 . With 416 px hor. there is 22 bytes +  of invisible data in line, and I must serve it too (no time for process any data manipulations). So, 230 bytes per line must be loaded.  How it is with 400 px hor. ?

With alternating palettes we should preprocess images to 15bit bpp, I guess. But usual tools, with error diffusion offer max 12bit fixed palettes (what is almost essencial for animations).  So, I don't know what is the best way to do preprocessing for alt. palettes.

Anim. playback should work in Hatari when you mount folder with files as GEMDOS hard disk .
Title: Re: High-color video playback on STE
Post by: Petari on 27-11-2012, 15:59:27
Overscan with dual palettes:

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

More details:  http://atari.8bitchip.info/movpst.php

Btw. found really useful and well made tool for color reduction with error diffusion, and for best place - Virtual Dub.  It is 'Error diffusion' filter - can set bit depths for each channel and other things.
Title: Re: High-color video playback on STE
Post by: kovacm on 27-11-2012, 17:05:14
Quote from: Petari on 27-11-2012, 15:59:27
Overscan with dual palettes:

http://atari.8bitchip.info/OverscanOvertake.avi
:) :) :) this look awesome! only at the end you have artefacts in few lines, otherwise: perfect!
Title: Re: High-color video playback on STE
Post by: Petari on 28-11-2012, 10:59:11
Yes. Errors by PCS conversion - which is still in Beta phase. Currently doing another one, with slower and better PCS conv. mode. 1 min for 1 frame.
Hopefully, Douglas Little will do updates soon.
Title: Re: High-color video playback on STE
Post by: Cyg on 28-11-2012, 12:52:56
Great ! Except a bug on the left at 1'00 ?

I had few hours these last days to almost finish my C version of higheSTcolor, still have few hours to work, I should deliver you something by tomorrow night (depending of my newborn son needs ;-) ).

It can go fast, 6s per picture for an quite good result and the quality is a little improved from what you saw before because now I think I have enough power for the algorithm to converge to the "ultimate" result.

What are your overscan colors/palettes timings ?

Best regards
Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 28-11-2012, 16:32:51
I corrected errors in overtake vid. Using PCS m5 - it is quite slow with default settings - 1 min for 1 conversion. Reconverted some 150 frames at end. URL is same.
Will do some others with overscan in days.

Overscan is res:  416x228 px . Good that no border left and right.  48 colors/line.  Can not more, because need to load parts of bitmap interleaved with colors.  And no way to have complete separated palettes for lines. 6 colors from last palette of upper line go to begin of line. I think that it is best what can achieve.  There is only 48T state for loading colors in H-blank. I can there load 10 colors. Plus, I couldn't center image vertically, because it would take too much CPU time. Not so big flaw, I think.  That palette sharing between lines slowdowns PCS conversion a lot. 
But this is max, what we can with overscan, I think.  Other useful res would be  320x240 - for 4:3 AR material.
I need to do some experiments with dot timings yet - sometimes I have errors on STE depending on it's warming, it seems.
Maybe need to shift 1px left or right.

Cyg, what preprocessings you use ?
Title: Re: High-color video playback on STE
Post by: Cyg on 28-11-2012, 17:10:18
Preprocessing : nothing (or directly included in the source image) and (x+y) alternative floor/ceil rounding rule, nothing new.
As postprocessing, Floyd steinberg, but a little lighter than before.
And modes are 1 pix + 1 pal, 1 pix + 2 pal, 2 pix + 2 pal

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 29-11-2012, 13:35:02
I meant "directly included in the source image" - what doing with some imaging SW before giving it to your converter ?

I added 3 conversions/captures on page:      http://atari.8bitchip.info/movpst.php   

Title: Re: High-color video playback on STE
Post by: Cyg on 29-11-2012, 16:54:18
I do nothing, I use the exact image (24bpp) without any preprocessing.

Error diffusion is done after the optimisation to benefit from the existing color from the optimized image. It use the final palette to find the best candidats for error diffusion.
The other solution is to do a pre error diffusion, but that could push a little more the pressure on the solver.
Both need to be compared, it depends on the capacity to solve a clean picture or a noisy picture (noise = pre-error diffusion).

Here are samples, 1 picture file, 1 palette file, 54 colors / line :

(http://www.top250filmsdvd.com/atari/no%20error%20diffusion.png)
no dithering

(http://www.top250filmsdvd.com/atari/dithering%20X+Y.png)
pre-dithering X+Y, my favorite : beautiful and very stable between frames

(http://www.top250filmsdvd.com/atari/dithering%20X+Y%20+%20post%20error%20diffusion.png)
pre-dithering X+Y + post error diffusion

(http://www.top250filmsdvd.com/atari/post%20error%20diffusion.png)
post error diffusion

(http://www.top250filmsdvd.com/atari/pre%20error%20diffusion%20(from%20a%20256%20color%20conversion).png)
pre error diffusion (from a 256 color conversion with XNView, not designed for that, I don't have any picture tool here at work)

(http://www.top250filmsdvd.com/atari/pre%20error%20diffusion%20+%20post%20error%20diffusion%20(from%20a%20256%20color%20conversion).png)
pre error diffusion + post error diffusion (from a 256 color conversion)

(http://www.top250filmsdvd.com/atari/0001.png)
Original picture

1 PIX + 2 Palettes trial :

(http://www.top250filmsdvd.com/atari/1pix2pal%2054cols%20theorique%20swapping%20result.png)
1 pix 2 palettes 54cols swapping result

(http://www.top250filmsdvd.com/atari/1pix2pal%2054cols%20theorique%20swapping%20result%20+%20post%20error%20diffusion.png)
1 pix 2 palettes 54cols swapping result + post error diffusion

(http://www.top250filmsdvd.com/atari/1pix2pal%2080cols%20theorique%20swapping%20result.png)
1 pix 2 palettes 80cols swapping result

(http://www.top250filmsdvd.com/atari/1pix2pal%2080cols%20theorique%20swapping%20result%20+%20post%20error%20diffusion.png)
1 pix 2 palettes 80cols swapping result + post error diffusion

I think I should push error diffusion a little on the double palette result as there are more colors available, result should be less noisy.

If you have any good pre-dithering picture, we can make a try.

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 30-11-2012, 15:46:18
In principle, post error diffusion should be better. But it is hard to achieve, I guess. PCS error diffusion still has some flaws, and I did not try every setting so far.
What for me worked best is pre-error diffuson or ordered dithering - latest is OK with 15bpp.
For single palette conversion we need to do error diffusion while converting to 12bpp - it is of course not to indexed palette (max 256 colors), but to 4 bit per color.  Best results I got with Sierra 24A error diffusion - it produces pretty much static dot patterns on static parts.

With dual palette is much better:  conversion to 15bpp with error diffusion or ordered dither produces almost invisible dots.
And best tool for animations is Error Diffusion filter for Virtual Dub - lot of settings. Static patterns with Floyd Steinberg E.D.

Here are example pictures:    http://atari.8bitchip.info/underw.zip

Capture of video:  http://atari.8bitchip.info/Underwater.avi

Same on YouTube:  http://youtu.be/urgixT_MPCU

Btw. it is less sharp than in reality - because I needed to filter out horizontal lines/bars, which are result of Atari's not standard video out - TV card can not capture it really good, and some shifting appears. Instead 625 lines, Atari produces 2x313 lines.

Btw. your last pic (80 col, 2 pals) looks really good.
Title: Re: High-color video playback on STE
Post by: Cyg on 30-11-2012, 16:56:45
Sierra24 seems very interesting, I made a first try and it shows no big changes after encoding :-)
But I think I still prefer the X+Y method for static picture.

I should post my exe here tonight, you will be able to try it by yourself !
For the moment I have a regression bug to solve and a global lightning on the X+Y method (something like halftone too light).
I also try to better balance the 2 palettes using 1 pix, the mixing result is good but the 2 individual pictures are not so nice, which could be a pb for quick eyes :-)
And I have to check that the result still displays fine on ST, and not only rely on my bmp preview on PC :-)

Cyg
Title: Re: High-color video playback on STE
Post by: Cyg on 01-12-2012, 00:58:11
Here is a beta version of my optimizer "higheSTcolor", the last enhancements are not optimized (in speed), I'll try to do it later...

http://www.top250filmsdvd.com/atari/higheSTcolor01.exe (http://www.top250filmsdvd.com/atari/higheSTcolor01.exe)

It should work fine for 1pix/1pal and 1pix/2pals but not yet for 2pix/2pal.

I let you see the option, basically it looks like :

higheSTcolor.exe -4 --mode=0 --dith=1 --pixpal=3 0000.bmp

Where "-4" mean quality between 1 and 5, speed is exponential and 3 leads to a good result
--mode for the displaying mode
--dith for the pre-dithering methods, there will always be a 2nd results with a post error-diffusion as it cost nothing and could lead to something better
--pixpal to specify the number of pix & pal
Sorry, no wildcards for the file...

Outputs :
*.pal : 1st palette file (no global color for the moment)
*.pa2 : 2nd palette file (useful when pixpal=2 or 3)
*.pix : 1st bitmap file
*F.pix : 1st bitmap file with error difusion
*_preview.bmp : preview file using the 1st pal
*_preview2.bmp : preview file using the 2nd pal
*_previewF.bmp : preview file using the 1st pal with error difusion
*_previewF2.bmp : preview file using the 2nd pal with error difusion

54 cols mode :
1pix, 1 pal:
higheSTcolor.exe -3 --mode=0 --dith=0 --pixpal=1 0000.bmp
higheSTcolor.exe -3 --mode=0 --dith=1 --pixpal=1 0000.bmp
1pix, 2 pal:
higheSTcolor.exe -3 --mode=0 --dith=0 --pixpal=3 0000.bmp
higheSTcolor.exe -3 --mode=0 --dith=1 --pixpal=3 0000.bmp
higheSTcolor.exe -3 --mode=0 --dith=2 --pixpal=3 0000.bmp
higheSTcolor.exe -3 --mode=0 --dith=3 --pixpal=3 0000.bmp

80 cols mode, change mode=0 by mode=1

Upcoming :
- overscan mode; could you please give me your color timings?
- 2pix + 2pal
- some speed optimisation

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 01-12-2012, 14:03:00
Here is timing for Overscan:  http://atari.8bitchip.info/OS6.csv

At top is PCS header. Means 416px hor. 16 colors per palette. 3 palettes.  2 palettes to skip. 0 is irrelevant.
The point is that because os not possible to load 16 colors in hor, border, there is sharing between lines. -1 in table means using last palette from upper line (where it is pal 2). 2 palettes to skip is because PCS skips first bitmap line data, and need to preload 1 palette before start with high-color line code.  Basically, for color data you need :  32 bytes of  pal -1 for first line, then 3 palettes for line, and so on ...
In last line, only 8 colors from last palette (2) will be used. You may padd the rest to 16 colors, or cut right after 8 colors.

I started conversion of 500 frames with your code. At qual 4 (and 80c/l)  it goes pretty slow.  When finishes, I'll mux, and see how it looks.   
I need switch to disable generation of preview BMP files (which are useful of course when do settings) - it takes too much space on disk when converting hunderts of pics.

At moment I work on animation playback suitable for people equipped with faster hard disk adapters and drives:  like UltraSatan, some newer IDE drive or CF card  or faster SCSI drive + ACSI-SCSI adapter. For instance Mega STE internal is enough fast - if using newer SCSI drive. Or ICD adapters.  Minimum is 1100KB/sec transfer rate.  Res. is 320x158px, 12.5 fps. More just can not.
I made code for 48 col/line hi-color, with custom border. 54 colors/line is not really good, because means more data, and we are very limited with loading time and speed.
Here is it :  - I can post later csv timing table for it.






lea $FFFF8209.w,a3

lea $FFFF8240.w,a6
lea $FFFF8250.w,a2
move.l a2,usp
lea $FFFF8242.w,a4
lea $FFFF8244.w,a5

clr.l $40.w   *  black border - or custom


moveq #0,d0
moveq #$40,d7
l2AF96 move.b (a3),d0
beq.s l2AF96
sub.w d0,d7
lsl.w d7,d0
move.w #12,d0    * 
l2AFA2 dbf d0,l2AFA2
nop
nop
movea.l palloc(pc),a7


rept 199    *  Or 158   if  movie for UltraSatan and co (1100KB/sec min data rate for 12.5 fps)


   movem.l  (a7)+,d0-d7/a0-a3     *108T (12+12*8)  preload 16+8 colors 
* complete P0 and first half  of P1

   movem.l  d1-d7,(a5)   * 64T   * P0 col 2-15
   move.w  d0,(a4)    * 8T     * P0 col1 , 15 colors of P0 written
   swap   d0    * 4T

* 184T so far

*boe -   border end
   move.w  d0,(a6)   * 8T  update color 0 of P0  at exact line start

   movem.l  (a7)+,d0-d3  *  12+4*8 = 44T   - second half of P1

   movem.l  a0-a3,(a6)     *  40 T  first half of P1 to shifter     at px 56

   move.l   usp,a3     * 4T    px

   movem.l  d0-d3,(a3)   *  40T   second half   P1    at px 100

   movem.l  (a7)+,d0-d7   * 76T , complete P2 pref.   at px 140

   movem.l  d0-d7,(a6)   *  72T   all 16 colors  P2   at px 216

* 28T states free here - just delay

    addq.l #1,d0   * 8T
    asr.l #6,d0   * 20T

*bos  -  border start
   move.w  $40.w,(a6)      * 16T    need 312T from  boe ( move.w d0,(a6) ) - here relative +8T wr.


endr





Title: Re: High-color video playback on STE
Post by: Cyg on 01-12-2012, 14:15:21
Just before encoding a bunch a 80 cols pictures, did you check that it now fits from a single sampling ? Just to avoid any CPU warming for nothing...

I am doing some "underwater" testing with all the differents dithering/error diffusion available.

I take the note for the option to enable/disable the preview files, you can also make a big batch file which del the files just after the encoding.

Cyg
Title: Re: High-color video playback on STE
Post by: Cyg on 01-12-2012, 23:47:21
Here the version 5 : http://www.top250filmsdvd.com/atari/higheSTcolor05.exe
Note :
- there was a little bug in version 2 for the .pal & .pa2 files, first 2 colors are unused despite the overall size seems to be right => the 2 very last colors are missing
- a major bug for 1pix + 2pal from version 3 to version 4, fine since version 5

- new 48 cols mode that should be compliant with your code (if I made no mystake in the opcode timings)
- --preview option : no preview by default
- correction of a quality bug, should improve by a little for dither=3
- dither=3 is now available when pixpal=1 (1 pix / 1pal) : it does about the same as the forced (X+Y)pre-dither but it evaluated the best candidates during the optimization, not as an input => less constraints => easier to find a correct solution.
- select more additional colors in the 1 pix + 1 pal method, improved the result by some few %
- double image optimization "motion blur", 1 pix + 2 pal

Mode 48 cols preview with dither=3 ("X+Y mod 2" V2) on 1 pix + 1 pal :
(http://www.top250filmsdvd.com/atari/dither%203%20for%201%20pix%201%20pal.png)
My new favorite, it beats the previous X+Y mode (pre-dithering), should be very stable

(http://www.top250filmsdvd.com/atari/dither%203%20for%201%20pix%201%20pal%20post%20error%20diffusion.png)
idem with a post error diffusion

If you do it at 12.5fps, does it mean that you are loading 4 times the palette ? (at every vbl) If yes, then it could be possible to motion blur frames in between without loading any extra-pixels (shared pixels), like I do in my last demos. Without any precalc you could double the frame-rate, 25 fps : 12.5 fps pix + 25 fps pal
But quality is decreasing.
It is available since version 04, you just have to rename the 2nd intermediate frame like the frame just before and add "_bis" : 0001.bmp and 0002.bmp renames as "0001_bis.bmp" to manage frame 1 & 2 in a single pix + 2 pal, then 0003.bmp & 0003_bis for frames 3&4, etc.
I am working a little on it to improve the result (I hope). It is not compliant with dither=1 but with other it should be fine, especially dither=3

Concerning undewater, Sierra 24 12 bits is effectively very good with 1 pix + 1 pal. I always like the "X+Y mod 2" method on a 24b source image, yet more now with the dither=3 option as described before.
For 1 pix + 2 pals, dither=3 on 24b source image is interesting because it is stable.

Version 5 now implement 2 kind of post error diffusion, use the --ed option :
--ed=1 : Floyd Steinberg, as before
--ed=2 : Sierra 2-4
--ed=3 : Atkinson

Advantage of a post dither VS a pre dither, because it is more complex to solve:

(http://www.top250filmsdvd.com/atari/dither1%20pre%20X+Y.png)

(http://www.top250filmsdvd.com/atari/dither3%20post%20X+Y.png)
dither 3, X+Y mod 2

Results should be about the same if optimisation was perfect, except it is far better with dither 3.

Cyg

Title: Re: High-color video playback on STE
Post by: Petari on 03-12-2012, 11:22:35
I was busy during weekend with some work around house, so had not much time to deal with this.
Tried first to make some 80c/l conversions. But there is something wrong - maybe in my code, maybe you did not get correct csv timing, so I got not correct displaying. I need to recheck first my muxing and playing code.
Then went on 54c/l. I noticed error with 4 zeros at start, and bad pixels at end of last line. Anyway, I made some conversions with dual palette, dithering modes 1-3 (tried only first v. what you posted). It looks pretty good, but I see some flickering on sky . I looked it only in Steem, did not finish playback SW for real STE. Likely will do it today, later, then will post some video capture.

One thing more, what can make muxing to AV file easier:  if you can, please make all 3 outputs (pix, pal, pa2) in single file. Just write them in order. It is simpler and faster to open just one file per frame instead 3, especially when need  to do it thousands time in row. It is easy to set proper offsets in SW, depending on part sizes.

Here is csv for 48col/line:   http://atari.8bitchip.info/48cl.csv

But you don't need to rush with implementing it - I need some more tests of timings, on different machines. It seems that we have some differences on STE, Mega STE ...

Code for 80col/line:



line1   macro

   lea  $FFFF8240.w,a0   * 8T

asr.l #8,d0   * 24T
asr.l #8,d0
asr.l #8,d0


    move.w  d1,(a0)   * 8T  - this should write at exact line start
    asr.l  #6,d0   * 20T


* Following executes reversed - writes to a0 instead read ! Src is IDE port, not registers.
    movem.w  (a0),d0-d7/a1-a7    * 72T, 32 bytes - overshot !
    movem.w  (a0),d0-d7/a1-a7   * 72T
    movem.w  (a0),d0-d7/a1-a7    * 72T
    movem.w  (a0),d0-d7/a1-a7   * 72T  , 288 so far
    movem.w  (a0),d0-d7/a1-a7   * 72T - this is for border and next line
   
    move.l  usp,a0   *4T
    movem.w  (a0),d1-d7   * 16 bytes (overshot) , padding 1/2,  8+32=40T states

* in d1 must go next line pal0, color 0 !

    endm



Overscan line code:



*  Overscan mode  -  416x228 px
* Not centered vertically

OverScan

* Set addresses :

lea $ffff8240.w,a0    * 8T
lea $ffff8250.w,a1
lea $ffff820A.w,a2
lea $ffff8260.w,a3


* above 5=40T

* address for loading bitmap data:  a6 
* a5 still free


  IdeSelpDataFR      *  16T  -  this must be executed from ROM !
* from now reversed read/write to dest

move.w d1,(a0)    * 8T  -  this sets first color in blank period

* sum 64T before line self

ol1 macro

  move a3,(a3) ;  8T

moveq #0,d0
move.b d0,(a3)       * 12T

*  Need  76+72+92+72+32+8 T states until next overscan setting. = 352T states exactly


* 28T :


  asr.l  #4,d1    * 16T
  asr.l  #2,d1      * 12T

* In lines 1,4,7... here just dummy delay code !


* Pause for drive possible this way:   8+20+28+8 = 64T


* Bitmap load

* Reversed !
movem.l (a6)+,d1-d7/a5    * loads 32+2 (overshot) bytes in 8+4x17=76T states
addq.l #2,a6   * bug compens  8T   

* Pal1 load in 2 stages :

movem.w   (a0),d1-d7 ;  8+4x8=40T  write colors - 8
movem.w   (a1),d1-d7 ;  8+4x8=40T  write colors - 8

* bmp  load

movem.l (a6)+,d1-d7/a5    * loads 32+2 (overshot) bytes in 8+4x17=76T states
addq.l #2,a6   * bug compens  8T


* Total 78 bytes loadable in 1 line > 3x78=234 - too good, need 224, so line 1 in group of 3
* delay instead  10 bytes load section

* Pal2 load in 2 stages :

movem.w   (a0),d1-d7 ;  8+4x8=40T  write colors - 8
movem.w   (a1),d1-d7 ;  8+4x8=40T  write colors - 8


* 352T after previous overscan setting

move.b d0,(a2) ; 8T
move a2,(a2) ; 8T

* Need 52T until next overscan setting

*Pal0 for next line, part 1 - but goes in this line too, little

movem.w   (a0),d1-d7 ;  8+4x8=40T  write colors - 8

* 12T free  - just delay here

lsl.l  #2,d1   * 12T

* 52T from last OS set.

move a3,(a3) ; 8T
* Here pixels end - pos 416
moveq #0,d0
move.b d0,(a3)    *12T

* 48T yet

* Pal0 for next line, part 2
movem.w   (a1),d1-d7 ;  8+4x8=40T  write colors - 8
nop
nop


endm




12.5 fps:  not possible to work with diverse palettes - ACSI (DMA) can not work during scanlines. So, 1 pal for 4 frames.
Title: Re: High-color video playback on STE
Post by: Cyg on 03-12-2012, 11:58:08
It looks like you were facing one of my bug : 4 bytes for nothing (in fact for global unused yet colors) and 4 last bytes missing.
Get the dither=3 a try on a 24 bit pictures with no pre-dithering, it is my preferred, sierra24 with dither=0 is good too.

Thanks for the routines, it will help for overscan as I will be able to test it, for 80 cols also with no possibility to validate it of course.
I tested the 48cols using your routine and it worked, timings are ok.

Best regards,
Cyg
Title: Re: High-color video playback on STE
Post by: Cyg on 03-12-2012, 14:53:15
Another trick I use in my demos is to share the colors between several lines of pixels and it still gives a nice looking result. I sucessfully tested to share 54 colors between 6 lines in an FX for a future demo.
It works fine because most often there is about the same colors used from line to another.

This reduce the palette size to load by the number of shares.
For instance, sharing colors between 2 lines will reduce the data loading of about 10kB per picture, it could be helpful if you are close to the limit, from 52 to 42kB for a 320x200 picture.

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 03-12-2012, 17:04:39
You can not use overscan code given here - it is version which loads part of bitmap interleaved with color data.

I will post you overscan code good for static pictures - where no cart. adapter needed. 48 colors/line too, just little different timings.

By animation playback with hi-color main problem is lack of time for load. Therefore I use sync. load during scanlines.  Majority of Atari ST(E) owners has some ACSI hard disk solution - like UltraSatan, some ICD adapter and SCSI drive, Mega STE has internal ACSI-SCSI adapter ...  And it is just not good for hi-color playback.  Syncro load is not possible, and even bare data load during scanlines not. Because DMA transfer will destroy timing - it stops CPU for some cycles.
If go on 158 lines, you have max.  9.5 mS to load 21 sectors. And it means min 1100KB/sec transfer rate, maybe little more even.  With 12.5 fps we need to load:  25KB for bitmap, 14.5KB for colors and 1KB for audio in 1/12.5 sec - or in 4 Vblanks. It gives 21 sector in 1 Vblank. Increasing line count means need for more data load, while time is less. With 200 lines you have only some 6mS for loading.

Surely that color sharing would decrease data amount - with proper material. We can later look into it. But still, will not be able to achieve 200 lines with ACSI. Then can load only some 12 sectors per V blank, what means 24 KB only in 1/12.5 sec - not even enough for bitmap self. 

Title: Re: High-color video playback on STE
Post by: Cyg on 03-12-2012, 18:22:42
Thx for the overscan routs, I will add this mode tonight.

Here is version 06 of higheSTcolor http://www.top250filmsdvd.com/atari/higheSTcolor06.exe (http://www.top250filmsdvd.com/atari/higheSTcolor06.exe)

- result files in 1 file : pix+pal+pa2 when needed
- faster : 6s for quality 2 which is quick good, 12s for quality 3 and 30s for quality 4
- bug correction in the quality re-evaluation, it improves the result by a little

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 04-12-2012, 10:49:12
I made some capturing with following conversion settings: 
higheSTcolor05.exe -3 --mode=1 --dith=3 --pixpal=3  %1
http://atari.8bitchip.info/CheCyg80cl.avi
There are timing errors - white and black pixels appear. You should shift timing 1px left and right and make 2 test executables with both to check it out - what only I can do at moment.  With PCS there is option to use custom timing table (csv files I posted here).
There is minimum noise, what is good. But sky gradient is not so good as with predithering/error diffusion.
http://atari.8bitchip.info/Cheetah.avi
Above is preprocessed with 15bpp error diffusion - best for dual palette.

Btw. practically same errors in gradient appear with PCS and post error diffusion too.

I will try today some of your new modes/settings. Still not solved 54 color mode playback SW, and need to work on 48c/l too.
Title: Re: High-color video playback on STE
Post by: Petari on 05-12-2012, 10:48:03
I did some conversions with v.06. It is significantly better.
Tried with  preprocessed, without dithering in your encoder. With dual palette. You may see how it looks in emulator.
http://atari.8bitchip.info/bipi.zip   40MB .
There is original MPG (no sound), can load directly with Virtual Dub and generate BMP files - after resizing, denoising, opt. error diffusion,  etc. Included player for emulators, and muxing SW for PC. If no sound, just don't select audio file, program will insert silence.
Player and muxer are only for 320x200, 54c/l. dual palette mode.

I don't know is it because no dithering set, but there is too much flickering - big differences between fields.

I don't get the purpose of F files (with F added after number) - if muxing them, getting just bad result, like with shifted timing.

This, with joined parts is fine - muxing goes better, faster.

Now, about timing problem:  I see bad dots on my STE, while in emulator is mostly OK.  What makes me think that you made timings for Steem ? Do you test on some STE ?
There is some difference in exact pixel timings for sure. I have same results on my STE and Mega STE. But sometimes it goes wrong - then I need to do hard reset or turn off machine. It is 1 from 10 cases, and maybe has something with warming too. About it was talked on other places too, so it is not only by me. 
So, we need to see what is it exactly, and are there differences between STE machines considering this.

And little about loading from disk during playback and what to care about:

Data loading from disks is possible only in whole sector (called block too) portions.
Standard sector size is 512 bytes. If we need only 10 bytes, still need to load
whole sector.

Syncro color update, direct from disk: in this case, we still need to work with whole
sector sizes. Additionally, some pause between sectors must be made, otherwise
it will fail.

108 bytes/line case:  if we just load 108, 108, ... etc. bytes in order, it will fail -
- because 512 is not divideable with 108, and sector change will happen in
middle of movem execution, so no pause. We need min some 10 microSecs - with modern disks.
Therefore padding must be done. With 108 bytes/line, need to padd 20 bytes
per line - then 4 lines will make 1 sector:  4x(108+20)=512. 
This is not the best case - padding incrases data size for about 16% . 
With 48c/l. so 96 bytes per line can have less padding - then group it in 5 lines for 1 sector.

With overscan, I have minimal paddings - because selected all params. in that goal.

Of course, no padding in lines needed if no syncro load - case of 12.5 fps ACSI playback. But still must padd to complete sector sizes, therefore I went on 198 lines.
Title: Re: High-color video playback on STE
Post by: Cyg on 05-12-2012, 12:10:08
Hi Petari,

Known warm problems can effectively sometimes happen that only a reboot can solve.
I think that some of us had a fix and/or a way to detect it.

For flickering, yes it is "normal" as you choosed the worst option for the 2 pal mode : 1 pal is for lighter value, 2nd is for darker.
You could prefer the dither=2 option which at no cost produce a discret "TV effect": 1 line every 2 is for the lighter or the darker colors, alternatively between lines & pals. Result is therefore more balanced.
dither=3 and dither=1 should be more stable, because balanced pixel per pixel alternatively, not line by line like dither=2 and frame by frame like dither=0

*F.hST (I changed the file extension, hST for higheSTcolor), is the same as the *.hST except with a post-diffusion error, as configured in --ed (1=Floy, 2=Sierra, 3=Atkinson).

Here is a version 07 : http://www.top250filmsdvd.com/atari/higheSTcolor07.exe (http://www.top250filmsdvd.com/atari/higheSTcolor07.exe)
- new option to shift some pixels, +-5 pixels , value of 5 means centered. I am not sure if is a global issue for all 80 cols or some palettes only. I believe the color is too longer active because some left colors are still active 5/10 pixels right.
- 10 to 20% faster, I am taking a look at faster compiler, small effort for a promised 10 to 40% speed decrease

Maybe you can find an obvious error in my pixel timings for 80 colors mode, here is the code I use :

   for (i = 1; i <= largeur; i++) // pixels start at 1 and end at largeur (320 or 416)
   {
      for (j = 0; j < 16; j++)  // pal 1
      {
         paletteFinale[j+2] = j; // real color index, between 0 and 15
         if (i > 0 + shiftpixels && i < 32 + (j) * 4 + shiftpixels) // pixel zone where color j is active
            paletteactive[j+2] = 1;
      }
      for (j = 16; j < 2*16; j++)  // pal 2
      {
         paletteFinale[j+2] = j - 16;
         if (i >= 32 + shiftpixels + (j - 16) * 4 && i <104 + (j - (16)) * 4 + shiftpixels)
            paletteactive[j+2] = 1;
      }
      for (j = 2*16; j < 3 * 16; j++)  // pal 3
      {
         paletteFinale[j+2] = j - 2 * 16;
         if (i >= 104 + (j - (2 * 16)) * 4 + shiftpixels && i < 176 + (j - (2 * 16)) * 4 + shiftpixels)
            paletteactive[j+2] = 1;
      }
      for (j = 3*16; j < 4 * 16; j++)  // pal 4
      {
         paletteFinale[j+2] = j - 3 * 16;
         if (i >= 176 + (j - (3 * 16)) * 4 + shiftpixels && i < 248 + (j - (3 * 16)) * 4 + shiftpixels)
            paletteactive[j+2] = 1;
      }
      for (j = 4 * 16; j < 5 * 16; j++)  // pal 5
      {
         paletteFinale[j+2] = j - ( 4 * 16);
         if (i >=248+ (j - (4 * 16)) * 4 + shiftpixels)
            paletteactive[j+2] = 1;
      }
   }

shifpixels is used for the new shifting option.

To calibrate it I usually generate a bitmap ruler like this one, a simple capture or photo of the screen makes the timings & colors readable by using a single set of 48/54/80 colors on every line :

lea lineHiColorPictureBackground,a1
move.l adr_pix_pic_current,a0
; add.l #160*6,a0
move.w #16,d7 ; heigth of the zones
.screenTestHiColor:
move.l (a1)+,d0
move.l (a1)+,d1
rept 20*6
move.l d0,(a0)+
move.l d1,(a0)+
endr
dbf d7,.screenTestHiColor

move.l adr_pix_pic_current,a0
move.w #16,d7
.screenTestHiColorMesure:
lea lineMesure,a1
rept 320/16
move.l (a1),d0
or.l d0,(a0)+
move.l 4(a1),d0
or.l d0,(a0)+
add.l #160-8,a0
move.l 8(a1),d0
or.l d0,(a0)+
move.l 12(a1),d0
or.l d0,(a0)+
add.l #160-8,a0
move.l 16(a1),d0
or.l d0,(a0)+
move.l 20(a1),d0
or.l d0,(a0)+
add.l #160-8,a0
move.l 24(a1),d0
or.l d0,(a0)+
move.l 28(a1),d0
or.l d0,(a0)+
add.l #160-8,a0

sub.l #4*160-8,a0
endr
add.l #160*5,a0
dbf d7,.screenTestHiColorMesure

with :

lineMesure
dc.w %0101010101010101
dc.w %0101010101010101
dc.w %0101010101010101
dc.w %0101010101010101
dc.w %0001000100010001
dc.w %0001000100010001
dc.w %0001000100010001
dc.w %0001000100010001
dc.w %0000000100000001
dc.w %0000000100000001
dc.w %0000000100000001
dc.w %0000000100000001
dc.w %0000000000000001
dc.w %0000000000000001
dc.w %0000000000000001
dc.w %0000000000000001

lineHiColorPictureBackground
dc.w 0,0,0,0
dc.w $FFFF,$0,$0,$0
dc.w 0,$FFFF,$0,$0
dc.w $FFFF,$FFFF,$0,$0
dc.w 0,0,$FFFF,$0
dc.w $FFFF,$0,$FFFF,$0
dc.w 0,$FFFF,$FFFF,$0
dc.w $FFFF,$FFFF,$FFFF,$0
dc.w 0,0,0,$FFFF
dc.w $FFFF,$0,$0,$FFFF
dc.w 0,$FFFF,$0,$FFFF
dc.w $FFFF,$FFFF,$0,$FFFF
dc.w 0,0,$FFFF,$FFFF
dc.w $FFFF,$0,$FFFF,$FFFF
dc.w 0,$FFFF,$FFFF,$FFFF
dc.w $FFFF,$FFFF,$FFFF,$FFFF


Cyg
Title: Re: High-color video playback on STE
Post by: Cyg on 05-12-2012, 19:35:32
version 08 : http://www.top250filmsdvd.com/atari/higheSTcolor08.exe (http://www.top250filmsdvd.com/atari/higheSTcolor08.exe)

- faster (-20%)
- a little quality bug corrected

version 09 : http://www.top250filmsdvd.com/atari/higheSTcolor09.exe (http://www.top250filmsdvd.com/atari/higheSTcolor09.exe)
- new dither=4 : Sierre 2-4 forced pre-dithered => no longer need of Ximagic. Don't work (for now) with 1pix + 2pal
- updated dither=0 for 1pix + 2pal : no longer a darker and a lighter palette, but 2 noisy pictures more balanced and a 29K colors feeling result

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 06-12-2012, 13:48:02
You make new versions faster than I can really test them  :)

Timing describer. Should be easier to follow and implement.


Meanings:   pixel # - usually 0-319  or  0-415
Pixel's color index:  0-15
Change is always in 4px steps, because write takes 4T states.
Therefore we can present shorter: 
start px, start index, end px, end index , palette # or 2 palette #s


80 colors/line - only on real STE .

0,0,31,15,0   -  everything is palette 0

32,0,95,15,0-1    -  this is with movem for all 16 colors, 64T states, step 4, as always. Index 0 at start is 1, then gradually others too...

96,0,103,15,1   -  all is palette 1  -  this is at reading of opcode for movem - 8T states

104,0,167,15,1-2   - movem, all 16 colors ....

168,0,175,15,2   -  opcode for movem

176,0,239,15,2-3   -  movem, 16 colors

240,0,247,15,3

248,0,311,15,3-4  -  updating pal4

312,0,319,15,4   -  all is palette 4 for last 8px


With 48 colors/line we have some partial palette updates:


0,0,55,15,0   -  all pal0

56,0,87,7,0-1    -  updating colors 0-7 with movem  32T

88,7,99,7,0-1   -  index 0-7 is pal1, other is still pal 0. This is 12T because addit. instruction of 4T

100,8,131,15,0-1   -  updating colors 8-15 with movem  32T

132,0,215,15,1   -  fetching colors from RAM with movem to registers + opcode read of next. 76+8 T states.

216,0,279,15,1-2   -  updating all 16 colors  64T

280,0,319,15,2   -  all is pal2 



Or better format:

start px, end px, start idx, end idx, palettes

80c/l :

0,31,0,15,0

32,95,0,15,0-1    * Note:  px count of transient area is always 4x count of colors changing, so 4x16=64 here.

96,103,0,15,1

104,167,0,15,1-2

168,175,0,15,2

176,239,0,15,2-3

240,247,0,15,3

248,311,0,15,3-4

312,319,0,15,4

***

48c/l :

0,55,0,15,0

56,87,0,7,0-1

88,99,7,7,0-1

100,131,8,15,0-1

132,215,0,15,1

216,279,0,15,1-2

280,319,0,15,2

*****

If there is only 1 palette value (5th one) then all color indexes for that pixel area are that palette value.
If there is 2 - and it is always  n-1  -  n , then it is transient area, where colors are updated - usually with movem, what has pretty consistent timing - I never had errors keeping:  8T states for opcode read, then 4T states for every write (2 bytes at once) to shifter.
So, in transient area you have repeated 4 time (for 4px) same transient color index (like in csv table you see same rows repeated 4 times).

With SW for playback we can control timing only in 4px steps - as you know likely. Existing pixel errors on real STE must be because different T cycles counts between movem instructions - only those which write to shifter are relevant.
It would be good if you could make timing in format as above for your 54 color/line scheme. Then can see is there some diff. between it and my timings (for STE).

Title: Re: High-color video playback on STE
Post by: Cyg on 06-12-2012, 19:46:59
Thx Petari,

Your timing help a lot.
For 80 cols I see a difference in your timing and my implementation, a one pixel difference.

I updated it in a version 11 : http://www.top250filmsdvd.com/atari/higheSTcolor11.exe (http://www.top250filmsdvd.com/atari/higheSTcolor10.exe)

News :
- a little faster (-20%)
- 80 cols new timings (1 pixel)
- Sierra predithering (dither=4) : lighter effect with a minimum threshold => less noise especially on big monochrome zone

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 07-12-2012, 14:24:12
File is ...10.exe .

We need little help from people owning STE or Mega STE computers. I will post here couple simple testing programs, so we can determine % of machines with timing A or B - I call it so for now.
Steem has timing B, while my STE timing A - when is warmed. When cool boots with A or B 50-50%.
No need for hard disk - will be shorter files.
Title: Re: High-color video playback on STE
Post by: Cyg on 07-12-2012, 14:34:45
What if using the VBL timer in that case ? It should be more stable on any machine, no ?

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 07-12-2012, 14:50:32
Vbl has nothing with this. And it is not timer :-).
Here is my explanation: memory cycle is 4T states by 68000. It activates in this case glue chip - what decodes address and then activates shifter chip for writing. In that process may happen +-1 T state difference - and no problems, because write self may take only 1 T, so in 4 cycles is some tolerance.
Chips are clocked from same source, but some delays are always there, so  phase shifting may happen .

Title: Re: High-color video playback on STE
Post by: Cyg on 15-12-2012, 00:01:25
new version, 16 : http://www.top250filmsdvd.com/atari/higheSTcolor16.exe (http://www.top250filmsdvd.com/atarai/higheSTcolor16.exe)

dither=5 , a mix between dither=3 (X+Y) mod 2 and dither=4 Sierra predithering, give it a try, it could sometimes be interesting...
It preserves the sharpeness as (X+Y) mod 2 and smooth the big monochrome areas.

Block of lines is available but it bugs a little and it slowdowns by 20%, but I still can optimize a little.

Also I changed the mode=2, 48 cols, with newest Petari timings, I hope they are correct...

Made some test on Alladin, it works pretty well !
You can use a picture with a Sierra dithering or directly let the dither=4 or dither=5 make its own Sierra.

Some samples to run with CYG2001P.TTP  (54 cols) :  http://www.top250filmsdvd.com/atari/Alladin.zip (http://www.top250filmsdvd.com/atari/Alladin.zip)
alad4.cav = dither=4 
alad4F.cav = dither=4 with a post dithering
alad5.cav = dither=5 
alad5F.cav = dither=5 with a post dithering

And for fun, a colorful video of an indian celebration called "Holi" a colorful celebration, very interesting to optimize :  http://www.top250filmsdvd.com/atari/holi3.zip (http://www.top250filmsdvd.com/atari/holi3.zip)  using dither=3

Sometimes a post-dithering improve the things especially the sharpeness, use files F*.hst, I changed the naming to be easily recognize by STEAV

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 15-12-2012, 14:38:01
Looks great. Keep up good work !
Guide for conversion in monday ...
Title: Re: High-color video playback on STE
Post by: Petari on 17-12-2012, 11:00:56
Added guide for converting into STE hi-color.   http://atari.8bitchip.info/gutoHav.html

It is just beginning. There is much more, what may be needed. Currently, I experience with MVtools, a quality framerate conversion. In some cases, it produces really flawless new frames. 

Nice trailer:  http://atari.8bitchip.info/CloudAtlasTrl.avi

I prepare 2 new formats:  320x198px at 50fps  - some say that only at 50 is real .
Overscan 320x240px, 25 fps - for old style 4:3 material. Both with 48color/line.
That would be all , I think, considering formats.
Title: Re: High-color video playback on STE
Post by: Petari on 21-12-2012, 11:15:01
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.
Title: Re: High-color video playback on STE
Post by: Cyg on 21-12-2012, 23:23:56
Hi,

New version 17 is now available : http://www.top250filmsdvd.com/atari/higheSTcolor17.exe (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 (http://www.top250filmsdvd.com/atari/hob5.zip)  tested with NP158DE

Cyg
Title: Re: High-color video playback on STE
Post by: Petari on 22-12-2012, 10:41:21
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.
Title: Re: High-color video playback on STE
Post by: Petari on 22-12-2012, 14:43:00
Final mode:  320x240px. Dual palette, 25fps. Old Atari video now with correct speed and aspect ratio:

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

Title: Re: High-color video playback on STE
Post by: Petari on 24-12-2012, 10:57:17
 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  :)
Title: Re: High-color video playback on STE
Post by: Petari on 27-12-2012, 13:55:13
Added mode 9.
See for more:   http://atari.8bitchip.info/movpst.php
Tomb Raider fans should like it  :)
Title: Re: High-color video playback on STE
Post by: Cyg on 27-12-2012, 21:36:18
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
Title: Re: High-color video playback on STE
Post by: Petari on 28-12-2012, 10:39:33
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.

Title: Re: High-color video playback on STE
Post by: Petari on 03-01-2013, 13:38:49
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 .


*  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