Amiga 500 can do it too - display Revision 2017 modern graphics compo pictures

[khph_re]

Originally Posted by Trachu

do not get me wrong. I appreciate your effort and hope you will continue to find something more fit to amiga limitations.

I'll continue looking, probably into alternative disk formats/ compression. If i find anything of any use, i'll post here.

There's plenty of code out there for compression and disk formats, but a lot rely on being able to code. Never my strong point. I was always an art guy.

I have an A500, but i relied on the A1200 to feed it disks and programs from ADF, with the A1200 boxed up, it's hard to test anything.

[DamienD]

Originally Posted by khph_re

I have an A500, but i relied on the A1200 to feed it disks and programs from ADF, with the A1200 boxed up, it's hard to test anything.

Um, WinUAE perhaps could help here

That's what most old school coders / programmers use to test things these days

[Trachu]

Originally Posted by khph_re

I'll continue looking, probably into alternative disk formats/ compression. If i find anything of any use, i'll post here.

There's plenty of code out there for compression and disk formats, but a lot rely on being able to code. Never my strong point. I was always an art guy.

I have an A500, but i relied on the A1200 to feed it disks and programs from ADF, with the A1200 boxed up, it's hard to test anything.

Dont need to look anymore. You wanted you have it.
Sometimes big discoveries are just a matter of pure luck.
I think i have what we all OCS Amigians are looking for - highly compressible dynamic hires converter

Scavengers picture if treated as 16c would take only 52kB in PNG format
Minimum slicing errors
High detail retention
Minimum banding
More original colors.

I included also shaded head from this thread http://www.pouet.net/topic.php?which=11055

Britelite are you still not interested? ;-)

[pandy71]

DMA limitations can be (IMHO) partially overworked by using less bitplanes and drive BPLxDAT by Copper/CPU (useful for 4 bpl lowres to efficiently double number of color registers, perhaps can be useful also for 2 and 3 bpl hires - this probably will require software like this http://www.leonik.net/dml/sec_pcs.py on Atari ST and carefully cycled color LUT updates).

PNG with max compression (without optimization) - 12 bit per pixel (over 600 colors, OCS bitwise - 4 bit per component) vs 16 color (4 bit per pixel).

[Trachu]

Originally Posted by pandy71

DMA limitations can be (IMHO) partially overworked by using less bitplanes and drive BPLxDAT by Copper/CPU (useful for 4 bpl lowres to efficiently double number of color registers, perhaps can be useful also for 2 and 3 bpl hires - this probably will require software like this http://www.leonik.net/dml/sec_pcs.py on Atari ST and carefully cycled color LUT updates).

PNG with max compression (without optimization) - 12 bit per pixel (over 600 colors, OCS bitwise - 4 bit per component) vs 16 color (4 bit per pixel).

ok, so lets clarify few things.
Atari ST has 8MHz while Amiga has only 7.19. This means each raster line in Atari ST has more cycles to be used - mainly in off screen area, thats why the border is larger.
Atari ST register change using CPU takes as much cycles as done it by Copper, the difference in approach lies elsewhere.
Atari ST Hires is using only 2 bitplanes so 4 colors total, and you can change single color every 16 pixel plus all total 4 colors change every line. You can also precache those 4 colors.
On Amiga considering hires you can have following modes:
1. 2 Bitplane 4 colors and single color change every 16 hires pixels plus all total 4 colors change every line. You can also precache those 4 colors.
2. 3 Bitplane 8 colors and single color change every 32 hires pixels plus all total 8 colors change every line. You can also precache those 8 colors.
3. 4 Bitplane 16 colors - you can not change any color within the line but you can change total 14 colors every line as long as you wont use Overscan.

IMHO the in most cases best results can be seen on option 3, but actual result can vary from picture to picture. On those page you brought the examples where wiselly chosen and represent easy targets, but if you would look at the girl you would see plenty of limitations this mode 1 brings.

Because Atari ST has smaller picture most popular are Overscanned Lowres 416x272x52cc/line, which if you would put 2 monitors side by side looks like middleres compared to Amiga.
In this mode you can have 4 Bitplane 16 colors and single color change every 8 pixels plus all total 16 colors change every line.

Bottom line Amiga can do everything what ST can, while ST programmers are doing everything so we would falsely think ST can also do everything what Amiga can ;-)

[pandy71]

Agree with most of above but:
Do not forget that BPLxDAT can be preloaded with fixed pattern and you may save some free cycles at a cost of computation complexity (but maybe memory can be saved at a cost of worse compression for picture - unavoidable increase in overall entropy) - for example Hires with 3 bitplanes and BPL4DAT can be preloaded with for example pattern $00FF so first 8 pixels will use color registers from 0 to 7 and next 8 pixels will use color registers from 8 to 15, side to this CLUT can be updated dynamically.

ST AFAIK can't do anything except moving data from source to target due heavy CPU usage (lack of dedicated HW - even overscan is possible due bug in graphic HW and need proper CPU cycling).

Also you mentioned important limitation for dynamic CLUT - it works well only with limited set of pictures - preferably highly detailed but limited overall tonal characteristic (unless serious breakthrough in conversion algorithms).

On AGA this limitation may be partially overworked by using CLUT switching (single write may switch group of registers - i still thinking on adding to OCS/ECS external SRAM addressed by Denise output and accessible trough one of not used chip-set address - RGA bus - having for example 32768 24 bit wide CLUT may be easiest way to extend Amiga OCS/ECS graphic capabilities).

Last one - ST can't do 640x512 in 16 colors due HW limitations and even marginally faster CPU can't do anything with this (additionally - most of those special modes on Amiga are insensitive to CPU speed - Dynamic Hires can work very nice with 68060).

[Toni Wilen]

Originally Posted by pandy71

Do not forget that BPLxDAT can be preloaded with fixed pattern and you may

Not really. This can only work in OCS/ECS only lores "7-plane" mode where DMA loads planes 0 to 3 normally, planes 4 and 5 stay active and can be loaded with CPU or copper.

[pandy71]

Originally Posted by Toni Wilen

Not really. This can only work in OCS/ECS only lores "7-plane" mode where DMA loads planes 0 to 3 normally, planes 4 and 5 stay active and can be loaded with CPU or copper.

Oh... HRM says that BPLxDAT is usually loaded by DMA but it can be loaded by CPU and/or Copper...

[Toni Wilen]

Originally Posted by pandy71

Oh... HRM says that BPLxDAT is usually loaded by DMA but it can be loaded by CPU and/or Copper...

Yes but unfortunately Denise forces all inactive planes to output zeros so any BPLxDAT write to inactive plane does nothing. (Except in "7 plane" mode where Agnus thinks mode is 4-plane but Denise thinks it is 6-plane). Having separate bitplane enable mask for Agnus and Denise would have been quite nice.

Writing to BPL1DAT is (the only?) really useful feature, it horizontally enables sprites immediately, even if DDFSTRT has not been passed yet.

[pandy71]

Originally Posted by Toni Wilen

Yes but unfortunately Denise forces all inactive planes to output zeros so any BPLxDAT write to inactive plane does nothing. (Except in "7 plane" mode where Agnus thinks mode is 4-plane but Denise thinks it is 6-plane). Having separate bitplane enable mask for Agnus and Denise would have been quite nice.

Writing to BPL1DAT is (the only?) really useful feature, it horizontally enables sprites immediately, even if DDFSTRT has not been passed yet.

Oh... this ruin my concept completely... I assume turning ON and after defined (to be estimated) time OFF some bitplanes (BPUx) will not work?

[AnimaInCorpore]

Originally Posted by Trachu

Bottom line Amiga can do everything what ST can, while ST programmers are doing everything so we would falsely think ST can also do everything what Amiga can ;-)

Well, AFAIK the Amiga has no real graphics resolution which supports 70 Hz so your claim isn't true.

[ross]

Originally Posted by AnimaInCorpore

Well, AFAIK the Amiga has no real graphics resolution which supports 70 Hz so your claim isn't true.

mmh, http://amiga.lychesis.net/knowledge/ScreenModes.html

An A500 ECS machine can do it.

Bye,
ross

[AnimaInCorpore]

Originally Posted by ross

mmh, http://amiga.lychesis.net/knowledge/ScreenModes.html

An A500 ECS machine can do it.

Bye,
ross

Sounds great. So it was the most used resolution for productivity then?

[ross]

Originally Posted by AnimaInCorpore

Sounds great. So it was the most used resolution for productivity then?

Well, not in a vanilla machine (it's slow like hell ).
But someone with accelerator or A3000 used it (with low bitplane).

Cheers,
ross

[pandy71]

Originally Posted by AnimaInCorpore

Well, AFAIK the Amiga has no real graphics resolution which supports 70 Hz so your claim isn't true.

Please define "real graphics resolution" , be aware that Amiga can display on OCS anything from 15Hz up (assume 1024 limit) and on ECS from 7.5Hz up (and stilll this is not HW limit) side to this ST is unable to be flexible as Amiga (not possible to build something like A2024 for ST).

OCS Amiga 70Hz can use around 200 lines vertical resolution and ECS can display same graphics format as ST (640x400@70Hz).
Btw nowadays such discussion is meaningless for progressive screens (LCD, PDP, OLED etc).

Originally Posted by ross

Well, not in a vanilla machine (it's slow like hell ).
But someone with accelerator or A3000 used it (with low bitplane).

Not single bitplane (i.e. ST mode)

[khph_re]

Originally Posted by Trachu

Dont need to look anymore. You wanted you have it.
Sometimes big discoveries are just a matter of pure luck.
I think i have what we all OCS Amigians are looking for - highly compressible dynamic hires converter

Been keeping an eye on that thread, I have you found a link to the executable?
All iv'e seen is the screenshot of the program.

It would be nice, if after each major demo event, an OCS disk of the entries was released.

[kovacm]

back in 80s Amiga had nothing that would compare to ST SM124.
My father bought ST because of SM124 and I believe many others.

Anyway, I am trying to figure out what Trachu achieved? Loaded 24bit images in Photoshop and convert them in 16 color with dithering?
Sorry if I missed something... but Dougs converter is much more than this.

[khph_re]

Originally Posted by kovacm

back in 80s Amiga had nothing that would compare to ST SM124.
My father bought ST because of SM124 and I believe many others.

Anyway, I am trying to figure out what Trachu achieved? Loaded 24bit images in Photoshop and convert them in 16 color with dithering?
Sorry if I missed something... but Dougs converter is much more than this.

If you required flicker free B&W, the Atari was great. Of course, you couldn't play many games on the SM124. A common problem later Amiga's also suffered from.
Personally, I chose colour and additional resolution over retaining my eyesight!

That converter has done a good job, is that the one mentioned in the Pouet thread?

[kovacm]

Originally Posted by khph_re

That converter has done a good job, is that the one mentioned in the Pouet thread?

No. It is Photoshop CS6.