Demo Coder Challenge - Vampire Beta Project !

[Thorham]

Originally Posted by Megol

But I guess the question was for what is the best graphics mode to use for demonstrating the Phoenix video decoding capabilities and then it wouldn't be a good fit.

HAM would be cool if you can somehow get a good converter to be fast enough.

Originally Posted by pandy71

nope, is not good as FS assume "lossless" error distribution where HAM is "lossy" and it can increase error due incorrect dithering - dithering for HAM need to be shaped in a way where HAM limitations are minimized.

When I tried it with my own code it seemed fine for HAM8 and was absolute crap for HAM6. Perhaps taking HAM in account isn't a bad idea.

Originally Posted by pandy71

HAM high quality... seem that every HAM converter (i saw to this moment) use very simplistic HAM model (1 pixel based) where probably this method will never provide HQ - IMHO 3 or 4 pixels error calculation with good CLUT and psychovisual model should be used to provide HQ HAM.

Sounds good, although it will probably be way too slow on 20/30 for image viewers. Still, interesting idea.

[pandy71]

Originally Posted by Thorham

When I tried it with my own code it seemed fine for HAM8 and was absolute crap for HAM6. Perhaps taking HAM in account isn't a bad idea.

HAM-8 seem to have less problems due bigger CLUT and possible high resolution thus some limitations of HAM can be easily hidden.

Originally Posted by Thorham

Sounds good, although it will probably be way too slow on 20/30 for image viewers. Still, interesting idea.

Generally HQ graphics functions are slow, how many resizers perform operation in linear RGB space (i.e. perform inverted gamma, resize, redo gamma correction)?

Also psychovisual models need to be (IMHO) implemented - perhaps 1 gray pixel will be less visible than 2 pixels such as light magenta-yellow - i mean with limited resolution (low res) and quantization range (4 bit) lot of things can be important.

But AFAIK optimal mathematical model for HAM not exist - perhaps with help of some people on ImageMagick or similar software forum it can be created... this definitely good area for some Matlab work (and lot of testing).
Final algorithm perhaps can be not so NP costly but even simple LQ HAM conversion HW can be best solution t bring HAM back to community - imagine that no one practically use HAM except some copper tricks.
If ST guys can play HQ samples on YM2149F i see no reason to forgot about HAM.

Btw - i never saw any video compression (even simple - similar to for example DXT) on Amiga, same for color space - mentioned in past YCgCo that is multiplierless, fully integer and have good (comparable to YCbCr) characteristic.
Definitely there is lot of areas on Amiga where last 10- 20 years science progress can be used to do something new (by something new i mean not sightly faster version of C2P - seem that for some people C2P or comparable code is the essence of coding - same as sine dot plot or comparable effect).

[Vot]

I would talk to people who had written h264 encoders etc

[pandy71]

Originally Posted by Vot

I would talk to people who had written h264 encoders etc

Can be nice at least to ask where to search for tools and knowledge about this problem - i have no experience in this kind of research - it involve not only psychovisual models but also practical analysis and creating various models.

[meynaf]

Originally Posted by Megol

Meynaf:
I have no problem disagreeing with people, it is through discussion with people with different viewpoints and experience one can learn new things. Perhaps we just talk past each other or something?

I think the discussion here is too theoretical and cannot advance much on that ground. Code samples, numbers to show, would help IMO.

Originally Posted by Megol

If one have an accelerator with local fast RAM that talks to the chipmem via the standard mechanism the peak performance for C2P hardware should be limited by the chip RAM bandwidth. Yes I'm smart

But that is also the only limit for video performance. DMA overhead can be reduced to insignificant percentages by smart buffering and having competent caching of Fast RAM. Hardware supported C2P can be done in the background while the processor renders the next frame or calculates some stuff. As long as the data output from the C2P hardware is less than the maximum write bandwidth possible to chipmem it can be essentially free.

Theoretically yes, but you bring in a condition that's not met - as merely displaying a 6 bpp screen on ECS already eats more than half the chip cycles.

Originally Posted by pandy71

HAM high quality... seem that every HAM converter (i saw to this moment) use very simplistic HAM model (1 pixel based) where probably this method will never provide HQ - IMHO 3 or 4 pixels error calculation with good CLUT and psychovisual model should be used to provide HQ HAM.

I doubt error calculation on several pixels would give much benefit. A basic psychovisual model is already there in my code, as red, green and blue don't have the same weight, btw.

Originally Posted by pandy71

And vertical dithering as it will not introduce any errors (HAM errors are propagated only in one direction).

Hmm, nice vertical patterns...

Originally Posted by pandy71

I didn't started this so don't blame me - but i will be more than happy to end it.

Sorry, but you DID start it. Read back in the thread to see this.

Originally Posted by pandy71

Perhaps, however 68020 seem to be "most complete" and as most of 68030 improvements are related to CPU system architecture thus they not apply to FPGA accelerator board (FPGA can exploit different mechanisms, buses etc).
So i would say most complete CPU is 68020 and well written code for 68020 seem to be also OK for 68030.

68020 and 68030 are very similar. I just choose 68030 instead of 68020 because i don't include CALLM/RTM in my wish list.

Originally Posted by pandy71

This is how i understand You - directly linking amount of transistors in modern FPGA and number transistors in for example 68030.

No direct link for me, but anyway, as the LEs are an abstract concept, why not ?

Originally Posted by pandy71

Nope as there is no direct link between both technologies... each of them have own uniqueness - take any book related to VLSI design - FPGA are not fixed function VLSI

Not everything has changed... In both cases you still handle binary electric signals...

Originally Posted by pandy71

Time, money, human resources etc - lack of chance to be success, another fail etc.

That's really another story.

Originally Posted by pandy71

Perhaps with time yes but i would say that we don't have enough resources to start multiple projects then we should focus on something that can be used by largest possible group.

That's not exactly multiple projects. Most of the code is common, only a change in some global define says what to use.

Originally Posted by pandy71

Yes, i agree, it is old but also only this one exist - for future HW i think whole concept should be changed - imagin graphics - you can build own 3D accelerator etc but on FPGA it will be slow, not even close to performance old Riva TNT, where in fact you can use just data from Amiga buffer and sent them over PCIe to local GPU buffer (like on modern graphics board).
So instead redesigning wheel perhaps we should focus how to provide existing buses (e.g. PCIe) in Amiga and standard and widely available HW.
We can't beat market - i think that Commodore at some point just realize this - even on plain PCI, slowest GC was faster than any planned future Amiga chipset.

And the day one chip on your mobo dies and none is available anymore to replace it, what do you do ?

Originally Posted by pandy71

Once again - as one of Your arguments is that with modern FPGA it should be possible to do the same but better than on past VLSI then i need to point that yes but this can be very expensive and we can't ignore this - that's all. Side to this not many FPGA's is capable to provide 1 or 2GHz clock except some resources.

Perhaps a Cyclone 5 is enough and it's not that expensive, is it ?

Originally Posted by pandy71

Yes, but once again this is architecture limitations, any limitations will affect both - DMA and CPU as bus is used by slow (in nowadays perspective blitter). My point is always the same - instead waiting for bus cycle in CPU use specialized HW that will do transfer in background - CPU can be used during waiting for normal operation.

Of course the cpu can be used while your DMA runs, but nevertheless it's not fully transparent.

Originally Posted by pandy71

And this is why HAM is delta compressed video buffer with hardware decoder.
Next pixel depends on previous one (under some exceptions) - this method is large class various techniques named "difference coding" and it is not limited to subtraction only.
This is not delta coding from audio signal but this is still delta coding as general principle.

With that definition really many things become delta coding. So you see JPEG as delta coding too ?

Originally Posted by pandy71

At first i pointed already i'm not programmer even if i can write code in few programming languages, second i don't think that simplistic 1 pixel RGB model is good for HQ HAM conversion as in quoted HRM HAM description we need at worst case scenario 3 pixels to fully change pixel color.
So HQ HAM conversion imply this kind of strategy (not sure which method can be optimal to minimize HAM error - perhaps Viterbi search perhaps something else).

If you're able to write code in a few programming languages, perhaps you could make some tests to support your point of view. You know, sometimes nice theoretical ideas fail completely when put into practice !

Originally Posted by pandy71

At last - You explicitly wrote that HAM is not good for animation and it is only for static ictures but my point was that this is incorrect - without definition what is animation (as static is quite clear) this claim is just incorrect.

I wrote that HAM is not good for animations and is better for still images, but i didn't write that it was impossible to do anims with it. Is that what you understood before ?

Originally Posted by pandy71

I agree, HAM is not a magic, HAM have own limitations but still - this only one mode in Amiga where under some limitations you can have pseudo high/true color.
I see no reason to ignore it and stuck with 32/256 CLUT (as EHB CLUT have own limitations and still it is limited to only 64 colors at best).

Of couse i'm not ignoring it, i'm using it in my picture viewer and a lot of care has been put into it.

Originally Posted by pandy71

Nope, first if we changing 1 pixel in local buffer than converting whole buffer (and this is why im talking about HW HAM encoder) to HAM thus there is no problem with "HAM fringes", HAM limitations can be reduced by correct coding (for example with CLUT pixels HAM errors can reduced - they will not propagate behind CLUT pixel)

It will not propagate behind CLUT pixels obviously, but it will still propagate 'til it reaches the next CLUT pixel or enough pixels to get it right. So you will not see anything enormous, but you can still see a small change at the right of the changed pixel.

Originally Posted by pandy71

Once again - if you can have C2P HAM in HW this is not important - i don't understand why you insist to do this in software.

C2P is just moving of bits and isn't complicated to do in HW. But HAM is really another story, with decision taking depending on what was previously emitted. I don't think it can be done in HW cheaply, and C2P alone wouldn't have a big benefit.

Originally Posted by pandy71

This is not so simple as this imply to do serious research (and my knowledge is from different area)- i know simplistic algorithm but IMHO it is suboptimal and this was my point - after 30 years we don't have even rough idea how to deal with HAM in terms of HQ conversion. IMHO this is very serious math problem...

As there is apparently nobody to solve that old math problem, it's empty talk i'm afraid.

Originally Posted by pandy71

Also psychovisual models need to be (IMHO) implemented - perhaps 1 gray pixel will be less visible than 2 pixels such as light magenta-yellow - i mean with limited resolution (low res) and quantization range (4 bit) lot of things can be important.

Usually green is more visible than red, which is more visible than blue, and this alone is a nice improvement.

Originally Posted by pandy71

If ST guys can play HQ samples on YM2149F i see no reason to forgot about HAM.

ST guys can play samples on YM2149 with careful volume calibration but this only gives them the rough equivalent of a 6-bit D/A. I used to be a ST guy before going to Amiga so you can't fool me on this

[Gunnar]

Lets try to go back to the original topic.

Lets say we have an OCS/ECS AMIGA. OK?
Imagine an A1000 or A500 or A600...

The screen modes with the modes colors are either EHB or HAM6.

Lets say we have the we have a source image.
This could be a still like a JPEG or PNG or something changing like a chunky screen from a game, a simulated MAC or a video.

The common factor of the input data is its not planar - and it has more colors than we do.

So we need to do two things here.
A) We need to do a color reduction / conversion
B) We need to do C2P

Now lets say we have a fast 68K CPU - much faster than any 68030 every produced.

Lets say we are happy with 30 FPS.
We do not need 50 FPS. This means the chip memory limit of the OCS/ECS AMIGA is not a provblem. We can do C2P to EHB 64 color screen or to HAM6 screen and reach 30 FPS.

Now what is the best conversion that we are able to do / able to code?

A real time conversion from chunky 15bit screen
to 64 color fixed color EHB planar screen is not that difficult.
I did this and it works fine with 30 FPS on my A600.

Could we do better?

Ideally from this discussion some code should pop out.
So that people like that port games or use SDL games or write emulator,
can really benefit from this here.

[meynaf]

Originally Posted by Gunnar

Ideally from this discussion some code should pop out.

Some code has already popped out.

[khph_re]

Originally Posted by Gunnar

The screen modes with the modes colors are either EHB or HAM6.

Could you not do sliced modes? That would give you a palette change every 8 pixels and every scanline.

[Gunnar]

Originally Posted by khph_re

Could you not do sliced modes? That would give you a palette change every 8 pixels and every scanline.

This is actually a good idea.
How many color register can we load each line in the blank area?

[pandy71]

Originally Posted by Gunnar

This is actually a good idea.
How many color register can we load each line in the blank area?

With DMA - perhaps 16... http://ada.untergrund.net/?p=boardthread&id=442&page=0

I don't think that sliced modes are good but perhaps i will be surprised (i wish to be surprised!).

Originally Posted by meynaf

I doubt error calculation on several pixels would give much benefit. A basic psychovisual model is already there in my code, as red, green and blue don't have the same weight, btw.

Perhaps not, perhaps yes... once again as HAM require at least 3 pixels then IMHO error shaping should involve all 3 pixels in calculation.

Originally Posted by meynaf

Hmm, nice vertical patterns...

Maybe if you insist - still you can have dithering in horizontal but you can't ignore HAM errors. IMHO vertical is error free thus dither biased to vertical will be better on HAM - sadly bandwidth is not enough to do this also in temporal direction.

Originally Posted by meynaf

Sorry, but you DID start it. Read back in the thread to see this.

As i promised to end i will ignore all you personal "arguments".

Originally Posted by meynaf

68020 and 68030 are very similar. I just choose 68030 instead of 68020 because i don't include CALLM/RTM in my wish list.

Once again - 68020 is most complete set of instructions, later Motorola reduced instruction list thus IMHO 68020 can be seen as most vital reference however as FPGA is something else then i see no reason to implement each 68020 instruction.

Originally Posted by meynaf

No direct link for me, but anyway, as the LEs are an abstract concept, why not ?

Because OR in VLSI can use 2 transistors where in FPGA it can be realized by LUT that consist 200 transistors.

Originally Posted by meynaf

Not everything has changed... In both cases you still handle binary electric signals...

Oh please, they share lot things but we talking about architectural differences not packages - functions are realized in FPGA in different way thus no direct match and if you add to this routing signals trough die then you have something else.

Originally Posted by meynaf

That's not exactly multiple projects. Most of the code is common, only a change in some global define says what to use.

Everything is hidden in details and those details are very important - almost doesn't mean the same.

Originally Posted by meynaf

And the day one chip on your mobo dies and none is available anymore to replace it, what do you do ?

Same as Clone-A (but i have lot of spare chips in home - i've prepared my self for nuclear war ).

Originally Posted by meynaf

Perhaps a Cyclone 5 is enough and it's not that expensive, is it ?

GX or SX? over 110k LE's - seem that it can be around 150E for FPGA - if rest will be bellow 100 - 150E with profit then fine for me.

Originally Posted by meynaf

Of course the cpu can be used while your DMA runs, but nevertheless it's not fully transparent.

This is why i wrote almost. - 1 100 - 200MHz cycle vs 1 3.58MHz cycle is huge difference.

Originally Posted by meynaf

With that definition really many things become delta coding. So you see JPEG as delta coding too ?

My impression is that JPEG use slightly different principles than HAM.
http://en.wikipedia.org/wiki/JPEG#JPEG_compression
http://en.wikipedia.org/wiki/Sophism#Modern_usage

Originally Posted by meynaf

If you're able to write code in a few programming languages, perhaps you could make some tests to support your point of view. You know, sometimes nice theoretical ideas fail completely when put into practice !

I pointed this many times - not consider my self as a programmer/coder. But it doesn't mean that i will not try to do some research on this area with time.

Originally Posted by meynaf

I wrote that HAM is not good for animations and is better for still images, but i didn't write that it was impossible to do anims with it. Is that what you understood before ?

This what i understood:

Originally Posted by meynaf

HAM6 isn't exactly a high color mode. It has constraints of neighboring pixels that make it unsuitable for anything but static rendering - which needs not be that fast.

If i misunderstood Your expression then sorry but it was not my fault.

Originally Posted by meynaf

It will not propagate behind CLUT pixels obviously, but it will still propagate 'til it reaches the next CLUT pixel or enough pixels to get it right. So you will not see anything enormous, but you can still see a small change at the right of the changed pixel.

So providing CLUT pixels on regular basis can reduce HAM error propagation even for dynamic content - i'm right or not?

Originally Posted by meynaf

C2P is just moving of bits and isn't complicated to do in HW. But HAM is really another story, with decision taking depending on what was previously emitted. I don't think it can be done in HW cheaply, and C2P alone wouldn't have a big benefit.

C2P is trivial and it is weird for me that lot of people trying to postpone this to software than to HW. I know that for some group of coders there is race who wrote faster C2P but at some point functionality is more important than position on finish line (to me) - C2P in HW will open large area of various application (mostly entertainment and widely recognized multimedia) on Amiga - this sound for me more interesting that 1 place on some compo. HW HAM even LQ but fast and quasi free for CPU will open another large area.
Cycle cost is exactly the same for HAM and for EHB. And quality... as we accepting crude pointresample, resolutions 40x256 then perhaps LQ HAM 320x256 or 320x512 will be not so bad.

Originally Posted by meynaf

As there is apparently nobody to solve that old math problem, it's empty talk i'm afraid.

I'm not a programmer but You are - instead cycling C2P You can start investigate this area - fully supporting You (i wrote this very serious - You have experience thus why not try?)

Originally Posted by meynaf

Usually green is more visible than red, which is more visible than blue, and this alone is a nice improvement.

http://en.wikipedia.org/wiki/Truism
But model, algorithm for HAM (HAM errors introduced in algorithm) are not exisit.

Originally Posted by meynaf

ST guys can play samples on YM2149 with careful volume calibration but this only gives them the rough equivalent of a 6-bit D/A. I used to be a ST guy before going to Amiga so you can't fool me on this

http://www.msx.org/downloads/related...cm-encoder-001
This one is over 8 bit and support sample rates over 44.1k - IMHO quite impressive example what can be done when proper tools and methods are used.

[britelite]

Originally Posted by pandy71

http://www.msx.org/downloads/related...cm-encoder-001
This one is over 8 bit and support sample rates over 44.1k

It gives "12 bit" sound at only 11khz though, higher frequencies are at 4/6 bit.

[pandy71]

Originally Posted by britelite

It gives "12 bit" sound at only 11khz though, higher frequencies are at 4/6 bit.

Yes - i never wrote that it is 12 bit at 44.1k but still it can provide over 8 bit only correct usage of HW. With proper method even "primitive" (relatively) HW can be OK - HAM should be seen as Amiga opportunity not ignored because lack of good algorithm.

[meynaf]

Originally Posted by pandy71

Perhaps not, perhaps yes... once again as HAM require at least 3 pixels then IMHO error shaping should involve all 3 pixels in calculation.

Choosing the 3 types of pixels together needs many computations, as all three have to choose between 4 combinations (i.e. 4 pixel types), so one must compare the error done for 4x4x4=64 choices. Perhaps a little too much for a reasonably fast conversion.

Originally Posted by pandy71

Maybe if you insist - still you can have dithering in horizontal but you can't ignore HAM errors. IMHO vertical is error free thus dither biased to vertical will be better on HAM - sadly bandwidth is not enough to do this also in temporal direction.

It seems to me that error diffusion doesn't work well with very big pixels, as in HAM6.

Originally Posted by pandy71

As i promised to end i will ignore all you personal "arguments".

Count on me to popup when you start again

Originally Posted by pandy71

Once again - 68020 is most complete set of instructions, later Motorola reduced instruction list thus IMHO 68020 can be seen as most vital reference however as FPGA is something else then i see no reason to implement each 68020 instruction.

So the 68020 is your reference. Fine with me. Now by what rules will you judge what to keep and what not ?

Originally Posted by pandy71

Because OR in VLSI can use 2 transistors where in FPGA it can be realized by LUT that consist 200 transistors.

Heck, if you want. It changes nothing for me. Consider the point agreed.
After all, my opinion is that what is good to put in a cpu doesn't depend on the implementation, but on the long-term programming needs. Why discussing implementation details then ?

Originally Posted by pandy71

Oh please, they share lot things but we talking about architectural differences not packages - functions are realized in FPGA in different way thus no direct match and if you add to this routing signals trough die then you have something else.

Same answer as above.

Originally Posted by pandy71

Everything is hidden in details and those details are very important - almost doesn't mean the same.

This is what conditional compilation is for : changing details with a common base. Anyway, somewhere, it's not my problem. My point is that the cpu should support all instructions that are needed from a software point of view.

Originally Posted by pandy71

Same as Clone-A (but i have lot of spare chips in home - i've prepared my self for nuclear war ).

Fine for your case, but not everyone is ready for the next nuke

Originally Posted by pandy71

This is why i wrote almost. - 1 100 - 200MHz cycle vs 1 3.58MHz cycle is huge difference.

And alas it's the 3.5Mhz that's used for the final output. Worse, a large part of it is already used for just showing the image (something like 6 clocks out of 8).

Originally Posted by pandy71

My impression is that JPEG use slightly different principles than HAM.
http://en.wikipedia.org/wiki/JPEG#JPEG_compression
http://en.wikipedia.org/wiki/Sophism#Modern_usage

But, my impression is that HAM use slightly different principles than Delta
As it is still based on previous pixels, it's a delta with your definition. Or you have to define where you put the limit.
Btw. Reasoning by the absurd to show that an assertion is wrong - which is what i did - isn't a sophism.

Originally Posted by pandy71

If i misunderstood Your expression then sorry but it was not my fault.

I wrote "unsuitable" (= ill-suited, not adapted to), not "impossible".
In case of doubt, just ask. English can be misleading, especially because none of us is a native speaker.

Originally Posted by pandy71

So providing CLUT pixels on regular basis can reduce HAM error propagation even for dynamic content - i'm right or not?

Yup, you're right. But unfortunately CLUT pixels can have only a few colors (16 for HAM6), so i'm afraid that you will rarely find the perfect match. Do you like the idea of using a CLUT pixel to reduce error propagation at the expense of a larger error ?

Originally Posted by pandy71

C2P is trivial and it is weird for me that lot of people trying to postpone this to software than to HW. I know that for some group of coders there is race who wrote faster C2P but at some point functionality is more important than position on finish line (to me) - C2P in HW will open large area of various application (mostly entertainment and widely recognized multimedia) on Amiga - this sound for me more interesting that 1 place on some compo. HW HAM even LQ but fast and quasi free for CPU will open another large area.
Cycle cost is exactly the same for HAM and for EHB. And quality... as we accepting crude pointresample, resolutions 40x256 then perhaps LQ HAM 320x256 or 320x512 will be not so bad.

As there is currently no hardware doing it, there is still sense in doing the C2P in software.

Originally Posted by pandy71

I'm not a programmer but You are - instead cycling C2P You can start investigate this area - fully supporting You (i wrote this very serious - You have experience thus why not try?)

My own investigations are already done. They have led to an implementation that you can download and test.

Originally Posted by pandy71

http://en.wikipedia.org/wiki/Truism
But model, algorithm for HAM (HAM errors introduced in algorithm) are not exisit.

By "are not exisit", do you mean "do not exist" ?

Yes, there is no math theory for HAM. But I don't think there is a single, good method. All have pros and cons. And I think my HAM8 implementation is a reasonable compromise. Have you checked it btw ?

Originally Posted by pandy71

http://www.msx.org/downloads/related...cm-encoder-001
This one is over 8 bit and support sample rates over 44.1k - IMHO quite impressive example what can be done when proper tools and methods are used.

What they do is just send 12 bits to the hardware. This does not mean 12-bit audio quality.
You have 3 channels each 4 bits of volume - total 12 bits, but many combinations lead to the exact same amplitude and the results are not linear.
So i'm afraid that the final output quality isn't even 8 bits.

Anyway, the fact good audio can be provided with the right method - does not imply that the same thing can be done with HAM.
Also note that this kind of argument can be "returned" to everyone who does not want to implement all 68020 instructions in HW. After all, it should be possible to have full 68030+68882 if the proper tools and methods are used.

[pandy71]

Originally Posted by meynaf

Choosing the 3 types of pixels together needs many computations, as all three have to choose between 4 combinations (i.e. 4 pixel types), so one must compare the error done for 4x4x4=64 choices. Perhaps a little too much for a reasonably fast conversion.

Probably this can be refined but worst case scenario - yes, it can be NP costly.

Originally Posted by meynaf

It seems to me that error diffusion doesn't work well with very big pixels, as in HAM6.

Personally i'm not enthusiast for FS and similar dithering method as they are unsuitable from animation point of view - however seem that you simply use display without correct reconstruction filter thus perceived picture is to sharp.

Originally Posted by meynaf

Count on me to popup when you start again

NC

Originally Posted by meynaf

So the 68020 is your reference. Fine with me. Now by what rules will you judge what to keep and what not ?

Nope, 68020 seem to be most complete MC68k ISA implementation thus it can be seen as a reference - selection what instructions should be implemented is different story.

Originally Posted by meynaf

Heck, if you want. It changes nothing for me. Consider the point agreed.
After all, my opinion is that what is good to put in a cpu doesn't depend on the implementation, but on the long-term programming needs. Why discussing implementation details then ?
.
This is what conditional compilation is for : changing details with a common base. Anyway, somewhere, it's not my problem. My point is that the cpu should support all instructions that are needed from a software point of view.

But at some point we achieve limits for particular technology (especially when costs involved in overall process)

Software is different story - i would say everything depends from programmer skills.
http://en.wikipedia.org/wiki/Zero_in...n_set_computer
http://en.wikipedia.org/wiki/One_ins...n_set_computer
http://en.wikipedia.org/wiki/Minimal...n_set_computer

Originally Posted by meynaf

Fine for your case, but not everyone is ready for the next nuke

But still as this topic is related to CPU than chipset i see no link especially when your earlier comments are serious.

Originally Posted by meynaf

And alas it's the 3.5Mhz that's used for the final output. Worse, a large part of it is already used for just showing the image (something like 6 clocks out of 8).

This is not argument as EHB use same amount of cycles as HAM - so fast HW accelerated HAM is usable as EHB.

Originally Posted by meynaf

But, my impression is that HAM use slightly different principles than Delta
As it is still based on previous pixels, it's a delta with your definition. Or you have to define where you put the limit.
Btw. Reasoning by the absurd to show that an assertion is wrong - which is what i did - isn't a sophism.

So you claim that HAM is DCT based (and remain implication of this) - fine for me but im afraid that you are alone with this type of claim.

Originally Posted by meynaf

I wrote "unsuitable" (= ill-suited, not adapted to), not "impossible".
In case of doubt, just ask. English can be misleading, especially because none of us is a native speaker.

Even going to semantics and understanding for non native English seem that real life with Amiga playing video in HAM mode proved that unsuitable is not particularly correct term.

Originally Posted by meynaf

Yup, you're right. But unfortunately CLUT pixels can have only a few colors (16 for HAM6), so i'm afraid that you will rarely find the perfect match. Do you like the idea of using a CLUT pixel to reduce error propagation at the expense of a larger error ?

And this is good question - perhaps CLUT can be created in such way where errors are minimal and perceived quality is high enough.
As 16 color LUT with relatively good results for WB screen already exist then perhaps this is not bad idea to test this also for HAM.
I agree - this will be not perfect but still perhaps acceptable in terms of NP and quality.

Originally Posted by meynaf

As there is currently no hardware doing it, there is still sense in doing the C2P in software.

And this was my point - as FPGA offer some flexibility then on Amiga it should address obvious architecture limitations.
As C2P is done on regular basis, on large amount of data and is simple data shuffling then it is perfect candidate to be done in HW.

Originally Posted by meynaf

My own investigations are already done. They have led to an implementation that you can download and test.

So once again i appreciate Your effort - thank You.

Originally Posted by meynaf

By "are not exisit", do you mean "do not exist" ?
Yes, there is no math theory for HAM. But I don't think there is a single, good method. All have pros and cons. And I think my HAM8 implementation is a reasonable compromise. Have you checked it btw ?

So i understand that as a creator (artist/programmer/craftsman) it is difficult to have distance but IMHO it is not optimal algorithm (i.e. error probably can be reduced further when more complex model for HAM will be created).
HAM8 is not interesting for as HAM as machine capable to do HAM8 is less limited than machine not capable to do HAM8.
So it was not checked.

Originally Posted by meynaf

What they do is just send 12 bits to the hardware. This does not mean 12-bit audio quality.
You have 3 channels each 4 bits of volume - total 12 bits, but many combinations lead to the exact same amplitude and the results are not linear.
So i'm afraid that the final output quality isn't even 8 bits.

IMHO more than 8 bit quality is possible - real life measurements will be affected by overall audio output quality but this is different story

Originally Posted by meynaf

Anyway, the fact good audio can be provided with the right method - does not imply that the same thing can be done with HAM.

Video, audio it is just signal - as You confirmed there is no ready to be used mathematical model for HAM then it is very hard to say what is possible or not, however knowing how HAM works by intuition can be said that if change require at worst case scenario 3 pixels then all those transition shall be involved to create full model of HAM - later such model can be used to minimize conversion errors - this how problems are solved.

Originally Posted by meynaf

Also note that this kind of argument can be "returned" to everyone who does not want to implement all 68020 instructions in HW. After all, it should be possible to have full 68030+68882 if the proper tools and methods are used.

Don't forget to add and unlimited (at some point) HW resources - then i can agree - but key to this discussion is what to do to have very fast CPU accelerator on Amiga with reasonably priced FPGA.

[meynaf]

Originally Posted by pandy71

Nope, 68020 seem to be most complete MC68k ISA implementation thus it can be seen as a reference - selection what instructions should be implemented is different story.

I wanted precisely to go to that "different story"...
So my question still is : what to keep and what not, and for which reasons ?

Originally Posted by pandy71

But at some point we achieve limits for particular technology (especially when costs involved in overall process)

Software is different story - i would say everything depends from programmer skills.

Hardware implementation also depend on people's skills.

Originally Posted by pandy71

But still as this topic is related to CPU than chipset i see no link especially when your earlier comments are serious.

I was just saying that building expansions for a hardware that's no longer produced, has no sense for me. Better build completely new hardware.

Originally Posted by pandy71

This is not argument as EHB use same amount of cycles as HAM - so fast HW accelerated HAM is usable as EHB.

But EHB is a lot faster to render than HAM so you don't need as much time here.

Originally Posted by pandy71

So you claim that HAM is DCT based (and remain implication of this) - fine for me but im afraid that you are alone with this type of claim.

YOU were the one to claim that Delta can be something that's not subtraction. So according to YOUR claim, DCT - which is not subtraction but still depends on the previously emitted - is Delta.

Originally Posted by pandy71

Even going to semantics and understanding for non native English seem that real life with Amiga playing video in HAM mode proved that unsuitable is not particularly correct term.

The would you prefer "not giving satisfactory results" ? Or "always giving poor results" ?

Originally Posted by pandy71

And this was my point - as FPGA offer some flexibility then on Amiga it should address obvious architecture limitations.
As C2P is done on regular basis, on large amount of data and is simple data shuffling then it is perfect candidate to be done in HW.

But the best way to do it in HW is to provide direct chunky modes.

Originally Posted by pandy71

So i understand that as a creator (artist/programmer/craftsman) it is difficult to have distance but IMHO it is not optimal algorithm (i.e. error probably can be reduced further when more complex model for HAM will be created).
HAM8 is not interesting for as HAM as machine capable to do HAM8 is less limited than machine not capable to do HAM8.
So it was not checked.

There is nothing "optimal" in this area IMO. And anyway, if one really wanted to get the best result, it would take so much computational time (even in HW) that it's not worth.

Originally Posted by pandy71

Video, audio it is just signal - as You confirmed there is no ready to be used mathematical model for HAM then it is very hard to say what is possible or not, however knowing how HAM works by intuition can be said that if change require at worst case scenario 3 pixels then all those transition shall be involved to create full model of HAM - later such model can be used to minimize conversion errors - this how problems are solved.

But the worst case scenario isn't even 3 pixels. It's usually much more, especially when you have very high frequencies in your image.

Originally Posted by pandy71

Don't forget to add and unlimited (at some point) HW resources - then i can agree - but key to this discussion is what to do to have very fast CPU accelerator on Amiga with reasonably priced FPGA.

A reasonably priced FPGA can have 100,000 LEs nowadays and I still believe it's enough - you do not need "unlimited" resources, just "enough" resources.

Btw. it seems the actual cpu for fpga arcade has full 68020 support (from what i've read in another thread).

And also remember that, in the other way, resources are not unlimited for software as well. You have a specified amount of clocks per second and you can't use more. So it's basically the same problem at the end : you need to be smart and if you are, great things can be achieved.

[pandy71]

Originally Posted by meynaf

I wanted precisely to go to that "different story"...
So my question still is : what to keep and what not, and for which reasons ?

Discussion already started - we can wait a bit to make it clear - from my perspective barrel shifter and bit field operation are important

Originally Posted by meynaf

Hardware implementation also depend on people's skills.

Yep, but main difference is that for HW you have (99.999% cases) warranty, for software not (in 99.999% cases) - lot of people see them-self as programmers or coders but sadly to others usually they can't write decent code at all...

Originally Posted by meynaf

I was just saying that building expansions for a hardware that's no longer produced, has no sense for me. Better build completely new hardware.

It have sense as long they will be people happy to buy such expansion - how many people can buy expansion for 150 - 200E and how many can buy expansion for 500 - 700E - time will tell.

Originally Posted by meynaf

But EHB is a lot faster to render than HAM so you don't need as much time here.

?? how the heck it can be faster if there are still 6 bitplanes?
Ok, once again - EHB 32 direct CLUT colours, HAM 16 direct CLUT colors, render picture in 16 colors then in second pass use HAM feature...
EHB have constantly bad quality where HAM can provide better quality - anyway each time whole frame is generated (as you don't transfer only changes)

Originally Posted by meynaf

YOU were the one to claim that Delta can be something that's not subtraction. So according to YOUR claim, DCT - which is not subtraction but still depends on the previously emitted - is Delta.

Once again - check what means difference coding - how DCT is for you delta (especially in frequency domain) this will be for me magic... but perhaps issue is in way how we see problem.

Originally Posted by meynaf

The would you prefer "not giving satisfactory results" ? Or "always giving poor results" ?

Nope, as i can run HAM converter then i can see difference - in many cases HAM problems are negligible. I know that behind HAM is bad hype in Amiga community but i see no reason to spread incorrect information's.
HAM have limitations, this is obvious but with good code it can provide results close to hicolor buffer on 6 bitplanes and this is most important as we have more MIPS to do this possible.

Originally Posted by meynaf

But the best way to do it in HW is to provide direct chunky modes.

Future, for moment where Amiga will fit in FPGA then we can do this - currently this mean that you need to have 2(3?) boards, one to emulate CPU, second to emulate Denise (and maybe third for Agnus) - none except Jens proved this in real life hardware - JimDrew mentioned that project he is involved have similar attitude (i.e. prove in real HW functionality for emulated chips)

Originally Posted by meynaf

There is nothing "optimal" in this area IMO. And anyway, if one really wanted to get the best result, it would take so much computational time (even in HW) that it's not worth.

But the worst case scenario isn't even 3 pixels. It's usually much more, especially when you have very high frequencies in your image.

So this is my point - i'm tired with posterized, pixelated rotators or similar super piece of code - EHB is just shortcut to avoid HAM - and once again - HAM limitations are usually exaggerated - people referring to blitting HAM with blitter then yes, with incorrect conversion errors spread across whole picture but this is not HAM problem but algorithm limitation that this kind of problem is not addressed at code level.
With more MIPS you can do HAM converter that can address this and other problems also i believe blitter will be no longer used to blit HAM screen as CPU will be way faster and also overall method for rendering picture is completely different.

Originally Posted by meynaf

A reasonably priced FPGA can have 100,000 LEs nowadays and I still believe it's enough - you do not need "unlimited" resources, just "enough" resources.

Btw. it seems the actual cpu for fpga arcade has full 68020 support (from what i've read in another thread).

And also remember that, in the other way, resources are not unlimited for software as well. You have a specified amount of clocks per second and you can't use more. So it's basically the same problem at the end : you need to be smart and if you are, great things can be achieved.

AS altera and many similar vendors (also softcore vendors) provide estimated number LE's for function then LE's usage can be approximated - seem that 100k LE's is absolute must for high speed modern CPU with simple FPU and as usually more LE's is better (as pointed by Gunnar they can be used for cache hoever for me external SRAM is cheaper than high density FPGA where most of LE's emulate cache SRAM, but i understand implication to adding external SRAM to overall design - this is not trivial and may not give expected gain).
FPGA Arcade is different story - i would say - waiting for product - price sounds reasonable - if it will be half as good as JimDrew say then i will buy it.
And i remember about clocks - this is why i writing - guys - forget about compo code for fastest c2p - this should be done in hardware - let focus on complex thing that can't be accelerated by HW.

[Thorham]

Originally Posted by pandy71

?? how the heck it can be faster if there are still 6 bitplanes?

Rendering is faster, not writing the actual bitplanes. Rendering in EHB is easy, just treat it like any old indexed mode where you first calculate the half bright versions of the lower 32 colors (VERY easy, and has to be done only once per image). For HAM it's more complicated. Only 3x1 or 4x1 pixel modes are easy in HAM, and then you're writing more pixels because the resolution is usually higher, making it slower again.

Or simple 16x16 pixel tile blitting. Very fast and easy in EHB or any other indexed mode, but for HAM you need to correct the right edges of all the tiles you blit, and to make that possible you also need the true/high color version of the tiles on top of the pre-converted tiles, making this slower (more memory access and more logic).

Indexed is almost always faster to render. Another example is true color to 216 colors conversion (6 red shades x 6 green shades x 6 blue shades). Exceedingly fast (needs only three small tables, and you get 4x4 Bayer ordered dithering almost for free as a nice bonus). Very useful for hires preview modes in image processing software (never seen a fast one, actually). With HAM you'll never get the same speed.

Only if you render with error diffusion (Floyd/Filter Lite) is HAM faster (and always better, of course).

[pandy71]

Originally Posted by Thorham

Rendering is faster, not writing the actual bitplanes. Rendering in EHB is easy, just treat it like any old indexed mode where you first calculate the half bright versions of the lower 32 colors (VERY easy, and has to be done only once per image). For HAM it's more complicated. Only 3x1 or 4x1 pixel modes are easy in HAM, and then you're writing more pixels because the resolution is usually higher, making it slower again.

Or simple 16x16 pixel tile blitting. Very fast and easy in EHB or any other indexed mode, but for HAM you need to correct the right edges of all the tiles you blit, and to make that possible you also need the true/high color version of the tiles on top of the pre-converted tiles, making this slower (more memory access and more logic).

Indexed is almost always faster to render. Another example is true color to 216 colors conversion (6 red shades x 6 green shades x 6 blue shades). Exceedingly fast (needs only three small tables, and you get 4x4 Bayer ordered dithering almost for free as a nice bonus). Very useful for hires preview modes in image processing software (never seen a fast one, actually). With HAM you'll never get the same speed.

Only if you render with error diffusion (Floyd/Filter Lite) is HAM faster (and always better, of course).

Assuming fixed palette - bad quality - same limitations as in simple HAM case... and my point was - Gunnar claims 750fps - of course not possible due HW limiations but... if c2p+HAM can provide 75fps (10 times slower) where HW limit is 30fps anyway then perhaps... perhaps HAM is not so bad - once more HW cost from system perspective is the same - 6 bitplanes and approximately 30fps possible - even if HAM rendering will cost 20 times more cycles there is still quality gain over limited EHB - EHB can be OK when dynamic CLUT can be used but this eat even more cycles than HAM and will require very precise timing (almost dedicated DMA to feed color registers) - going this at some point we can end just doing everything by CPU which seem to be i.n.s.a.n.e

[meynaf]

Originally Posted by pandy71

Yep, but main difference is that for HW you have (99.999% cases) warranty, for software not (in 99.999% cases) - lot of people see them-self as programmers or coders but sadly to others usually they can't write decent code at all...

Why would we have any warranty for HW ? What kind of warranty anyway ???
There are poor skilled programmers but there are poor skilled hardware guys as well.

Originally Posted by pandy71

It have sense as long they will be people happy to buy such expansion - how many people can buy expansion for 150 - 200E and how many can buy expansion for 500 - 700E - time will tell.

Time will tell indeed.

Originally Posted by pandy71

Once again - check what means difference coding - how DCT is for you delta (especially in frequency domain) this will be for me magic... but perhaps issue is in way how we see problem.

For me DCT is not delta of course, but HAM also is not delta. As you see HAM as delta, perhaps you have to specify where you put the limit. Because for now, your definition - depend on previous pixels - implies DCT is also delta.

Originally Posted by pandy71

Nope, as i can run HAM converter then i can see difference - in many cases HAM problems are negligible. I know that behind HAM is bad hype in Amiga community but i see no reason to spread incorrect information's.
HAM have limitations, this is obvious but with good code it can provide results close to hicolor buffer on 6 bitplanes and this is most important as we have more MIPS to do this possible.

Once again this is very theoretical. You do not know what is incorrect information or not, before having tried it. I know HAM8 already has problems for having seen them, so in HAM6 the situation can only be worse. Bad hype is another story ; of course the situation isn't as bad as some folks think. But it's not as good as you seem to think.

Originally Posted by pandy71

So this is my point - i'm tired with posterized, pixelated rotators or similar super piece of code - EHB is just shortcut to avoid HAM - and once again - HAM limitations are usually exaggerated - people referring to blitting HAM with blitter then yes, with incorrect conversion errors spread across whole picture but this is not HAM problem but algorithm limitation that this kind of problem is not addressed at code level.
With more MIPS you can do HAM converter that can address this and other problems also i believe blitter will be no longer used to blit HAM screen as CPU will be way faster and also overall method for rendering picture is completely different.

It is a fact that you can't blit anything on a HAM screen without having to redo some rendering. No rendering algorithm in the world will change this, unless you accept a real poor quality (i.e. nearly only clut pixels !).

Originally Posted by pandy71

AS altera and many similar vendors (also softcore vendors) provide estimated number LE's for function then LE's usage can be approximated - seem that 100k LE's is absolute must for high speed modern CPU with simple FPU and as usually more LE's is better (as pointed by Gunnar they can be used for cache hoever for me external SRAM is cheaper than high density FPGA where most of LE's emulate cache SRAM, but i understand implication to adding external SRAM to overall design - this is not trivial and may not give expected gain).
FPGA Arcade is different story - i would say - waiting for product - price sounds reasonable - if it will be half as good as JimDrew say then i will buy it.
And i remember about clocks - this is why i writing - guys - forget about compo code for fastest c2p - this should be done in hardware - let focus on complex thing that can't be accelerated by HW.

So the c2p should be done in hardware. Well, fine, but then it means creating cpu instructions for the c2p is useless ?
Also if we want to focus on a complex thing that can't be accelerated by HW - then what can it be ? Not HAM, as (at least for you) it can also be done in HW.
Oh yeah i will ask Gunnar to create a HAM instruction that he will call "phil"

[robinsonb5]

Originally Posted by meynaf

I know HAM8 already has problems for having seen them, so in HAM6 the situation can only be worse.

Being able to render to HAM in realtime changes things a little, however - because the eye will accept errors more readily in moving than in static scenes.

It is a fact that you can't blit anything on a HAM screen without having to redo some rendering.

Yes indeed - but if you're "blitting" to a truecolour chunky buffer it's going to be reconverted anyway.

So the c2p should be done in hardware. Well, fine, but then it means creating cpu instructions for the c2p is useless ?
Also if we want to focus on a complex thing that can't be accelerated by HW - then what can it be ? Not HAM, as (at least for you) it can also be done in HW.

I certainly think these things would be better done as a DMA process than with dedicated instructions. I find it strange that people don't find the prospect of a hardware DMA HAM/C2P conversion more exciting - maybe it just appeals to me as an engineering challenge!