Page 1 of 1

Breaking the ST limits

Posted: Sun May 11, 2008 9:26 am
by ZWF/Paradox
Hello,

inspired by the small discussion held on spinys gallery thread, i would like to hear about anything that got beyond the STs limit and how it was done.

There are several Spectrum 512 pics, most scanned stuff. The title screen of wings of death is one of the rare handmade 512 pix out there.
Also i know NeoChrome gives the ability to use up to 200 (?) colours via rasters in one picture. Mic/Dune uses that quite often i think. The Fantasia title had about 48 colours if i remember that correctly.
Borders are rarely used, which gfx programm supports drawing in it anyway ?

Any other tricks etc not yet mentioned ?

Re: Breaking the ST limits

Posted: Sun May 11, 2008 9:47 am
by sh3-rg
I used fullscreen construction kit that I think pasted a number of Degas PI1s together to make the big screen. Can't remember the exact dimensions, was about 17 years ago ;)

kev

Re: Breaking the ST limits

Posted: Sun May 11, 2008 12:08 pm
by GT_Turbo
Synthetic Arts can display fullscreen picture, you can find it on DHS ( http://dhs.nu/files_gfx.php, do a search for Synthetic Arts v3 )


GT :)

Re: Breaking the ST limits

Posted: Mon May 12, 2008 7:57 am
by spiny
a few of the medway boys menu intros used palette rasters - the war of the worlds one is one that sticks in my mind, as I tried to rip it and couldn't work out why it looked odd, until I realised the bottom half had a different set of colours :)

Re: Breaking the ST limits

Posted: Mon May 12, 2008 1:31 pm
by bullis1
I think a lot of border-breaking images were made by drawing the seperate sections and joining them by code. This was until some tools became available later on.

This is slightly off-topic, but I have a strange obsession with medium resolution. I've always wanted to see images or screens with more than 4 colours in medium resolution, and especially med-res with broken borders.

Re: Breaking the ST limits

Posted: Sat May 17, 2008 6:44 pm
by ZWF/Paradox
Hello,

on STE there is the Paradox Highres mode http://www.pouet.net/prod.php?which=12237. It works in Midres with with ets. 14000 colours. I would like to do some gfx for that mode some day, but there is no good tool available for it atm.

Re: Breaking the ST limits

Posted: Tue May 20, 2008 1:27 pm
by bullis1
ZWF/Paradox wrote:Hello,

on STE there is the Paradox Highres mode http://www.pouet.net/prod.php?which=12237. It works in Midres with with ets. 14000 colours. I would like to do some gfx for that mode some day, but there is no good tool available for it atm.


Sadly I've never been able to see that prod running because I don't have an STE machine. They have always been hard to come by where I live.

Re: Breaking the ST limits

Posted: Tue May 20, 2008 9:10 pm
by beastie
bullis1 wrote:
ZWF/Paradox wrote:Hello,

on STE there is the Paradox Highres mode http://www.pouet.net/prod.php?which=12237. It works in Midres with with ets. 14000 colours. I would like to do some gfx for that mode some day, but there is no good tool available for it atm.


Sadly I've never been able to see that prod running because I don't have an STE machine. They have always been hard to come by where I live.


It's not the same, but everyone in the similar situation to bullis1, can try the file attached here - it's another superb piece of code showing how to break gfx limits on ST. It allows us to display TGA (Targa) images with the 24-bit colour depth using the technique similar to HAM (hide and modify). The code is written by Ray/TSCC.

Check this out (works with Steem, although, you may use any 8 Mhz ST/STE for sure). Read the readme included before you'll start playing with this stuff. And it's nice, the m68k code is attached.

Thanx to Ray! First, I can shock my Amiga friends with that one on vanilla ST, then... I can show them the piece of code presented at pouet.net - hahahaha... It gives them a kick of energy for another 2 weeks of productive comparisions ST vs Amiga :-) With the ST everything is possible!

Re: Breaking the ST limits

Posted: Wed May 21, 2008 12:39 pm
by bullis1
I have heard of this before in the past. In recent time I seem to have lost the file and forgot about it, so it's nice to have it again. Thanks.

Re: Breaking the ST limits

Posted: Thu May 22, 2008 11:12 am
by spiny
spiny wrote:a few of the medway boys menu intros used palette rasters - the war of the worlds one is one that sticks in my mind, as I tried to rip it and couldn't work out why it looked odd, until I realised the bottom half had a different set of colours :)



doh, I meant Pompey menus, not Medway menus :)

Re: Breaking the ST limits

Posted: Mon Mar 09, 2009 1:51 pm
by ppera
Paradox Highres is really impressive. But I don't like that it needs floppy and 60Hz. Is there any chance to see sources, fileformat of HRM pic. files ?

Re: Breaking the ST limits

Posted: Tue Mar 10, 2009 10:45 am
by Nyh
ppera wrote:Paradox Highres is really impressive. But I don't like that it needs floppy and 60Hz. Is there any chance to see sources, fileformat of HRM pic. files ?

The HRM files are very simple:

<HighresMedium> *.HRM

This format is found in only one demo: "HighResMode" by Paradox. The
pictures are interlaced in medium resolution with 35 colors per line.
The files are packed with Ice. The unpacked format is as follows:
64000 bytes screen data, 160 bytes per scanline, 400 lines
28000 bytes palette data, 70 bytes per line
-----
96000 bytes

Code: Select all

/*
 *  Given an x-coordinate and a color index, returns the corresponding
 *  HighResMedium palette index.
 *
 *  by Hans Wessels; placed in the public domain januari, 2008.
 */
int find_hrm_index(int x, int c)
{
  x+=80;
   if(c==0)
   {
     return -1+4*(int)((x+0)/80);
   }
   else if(c==1)
   {
     return 4*(int)((x-8)/80);
   }
   else if(c==2)
   {
     return 1+4*(int)((x-40)/80);
   }
  return 2+4*(int)((x-48)/80);
}


I have never disassembled the display routine itself but I expect it to be as simple as the Spectrum routine. It should be possible to display it both 50 and 60 Hz. Please not a 50 Hz scanline is 4 clock cycles longer.

Hans Wessels

Re: Breaking the ST limits

Posted: Tue Mar 10, 2009 1:40 pm
by ppera
Thanx Nyh. I found better thing: Photochrome. It has less res. but still pictures look better. And there is a converter from known formats to PCS. Works at 50, 60 Hz . It is freeware, and I disassembled viewer. Not hard to follow how all it works. Best is that works on STs too.

Re: Breaking the ST limits

Posted: Tue Mar 10, 2009 3:14 pm
by Nyh
ppera wrote:Thanx Nyh. I found better thing: Photochrome. It has less res. but still pictures look better. And there is a converter from known formats to PCS. Works at 50, 60 Hz . It is freeware, and I disassembled viewer. Not hard to follow how all it works. Best is that works on STs too.

It is not too hard to make HRM files work on a normal ST too. You just have to take apart the two screens.

For photrochrome I have very efficient display code:

Code: Select all

disp_50_60Hz:
     move   #$2700,SR
     movem.l D0-A6,-(SP)
     move.l  SP,USP
     lea     $FFFF8209.w,A6
     moveq   #0,D0
     moveq   #$40,D7
sync_wait:
     move.b (A6),D0
     beq.s   sync_wait
     sub.w   D0,D7
     lsl.w   D7,D0
     move.w  #$E,D0
wait_disp:
     dbra   D0,wait_disp          ; D0 = 0xffff at the end of the loop
     nop
     nop
     movea.l colpr_ptr(PC),SP
     move.w  d0,19104(SP)         ; -1
disp_loop:
fix_50_60:
     add.l   d0,d0                ; add.l d0,d0, 8 clocks, 50 Hz
                                  ; add.w d0,d0, 4 clocks, 60 Hz
     movem.l (SP)+,D0-A6
     movem.l D0-D7,$FFFF8240.w
     movem.l A0-A6,$FFFF8240.w
     move.l  (SP)+,$FFFF825C.w
     lea     $FFFF8240.w,A0
     move.l  (SP)+,(A0)+
     move.l  (SP)+,(A0)+
     move.l  (SP)+,(A0)+
     move.l  (SP)+,(A0)+
     move.l  (SP)+,(A0)+
     move.l  (SP)+,(A0)+
     move.l  (SP)+,(A0)+
     move.w  #0,$FFFF8240.w
     move.l  (SP)+,(A0)+
     tst.w   (SP)
     bge.s   disp_loop
     move.l  USP,SP
     movem.l (SP)+,D0-A6
     move.l  #rte_label,$68.w      ; disable HBL
     move.b  #$23,(SP)             ; disable HBL (SR fix)
rte_label:
     rte

Complete code included in the zipfile.

Hans Wessels

Re: Breaking the ST limits

Posted: Wed Mar 11, 2009 12:16 am
by CiH
On an entirely related note, the Targa (TGA) viewer supplied with Apex Media on the Falcon works nicely with bog standard STFM (4096 colours) and STe (32768 colours!) in a 320 x 200 resolution. The latter does a reasonable impression of a poor man's photo-realism. It can load in larger sized targa images but tends to degrade the image quality by scaling it down. You are best off carefully cropping or scaling a chosen image yourself to best fit the 320 x 200 format. There is also very little screen flicker, which is one area that Ray's otherwise excellent TGA viewer could improve on 8)

Unfortunately, the .GIF and .JPG Apex viewers don't work on the ST-series as these other viewers use some Falcon specific DSP code. :(

Re: Breaking the ST limits

Posted: Wed Mar 11, 2009 2:32 pm
by ppera
Well, as I see multicolor viewers for ST(E) use same basic trick as Spectrum512 - changing palette on fly. With some improvements as alternating frames to increase color depth and count.
Ray's TGA viewer uses 3 alternating frames with diverse color tones to get some impression of true color. But I think that idea is not good. There is too much flicker because of much difference between frames.
Actually, viewers are simpler part. What determines quality is processing SW - program for converting true color pictures to some special format usable on ST(E) machines. And it is where Photochrome wins.

Re: Breaking the ST limits

Posted: Wed Mar 11, 2009 2:40 pm
by ppera
Nyh wrote:For photrochrome I have very efficient display code. ....


Fine. In original is a lot of repeating HBL seqs. Although, at end it is not too big when packing executable.
I made some changes as dropping out Vert. Hz select by flag in PCS file - better is to hold refresh rate suported by user's monitor.
Plus, don't see much sense of RLE (made some pics, and it shrinked some 5% in average) or even ICE compression - nice pictures with many details compress very little.
How about fixing HBL code for Falcon ? :D Just for some compatibility (of course Falcon can display things better with regular modes). But you don't have Falcon, as I know....
It should be not so hard - just need exact cycles on 68030 of used instructions ....

Palette selection

Posted: Sat Mar 14, 2009 1:36 pm
by ppera

Code: Select all

/*  Based on code by Hans Wessels, Public Domain 2008
 */
int find_pcs_index(int x, int c) {
    int x1 = 4 * c, index = c;

    if (x >= x1)                index += 16;
    if (x >= x1+64+12 &&  c<14) index += 16;
    if (x >= 132+16   && c==14) index += 16;
    if (x >= 132+20   && c==15) index += 16;

    x1 = 10 * c - (c&1) * 6;

    if (x >= 176+x1   &&  c<14) index += 16;

    return index;
}


I try to implement it in ASM, but it seems that there are problems somewhere. I have errors in first 16 horizontal pixels of lines already - actualy 0-7 seems OK, 8-15 contents errors.

Code snippet:

Code: Select all

.....
  move.w  d4,d7   *d4 holds palette index
  asl.w   #1,d4      * x 2
  asl.w   #2,d7      * mult it by 4
  cmp.w  d5,d4     *d5 holds x coord.
  bcs.s  nextp
  move.w 0(a1,d4.w),d4   *colors
  bra.s   write_it
nextp   move.w 32(a1,d4.w),d4

write_it
.....


Any ideas ?

Re: Breaking the ST limits

Posted: Sat Mar 14, 2009 2:41 pm
by nativ
Am I thinking of the Revolution demo or another??

Long Burger down one side and feature some STE screens?

anyway..................

What is happening with the 512 4096 16 million colour raster screen ( The one where you can scroll up and down through the colours?)
I am assuming it's using the 32k colour trick split across the pallette?

any clues?

EDIT::::::::::::::

Reality is a lie is the Demo and it's an STe only screen that has a palette scroll trick, any infos apprieciated.

Thanks

Ashley

Re: Breaking the ST limits

Posted: Thu Mar 19, 2009 1:47 pm
by ppera
Solved displaying of PCS on Falcon, with all 32K colors - there is small error in Nyh's formula for x above 176.
Don't know is it worth to make some Windows PCS showing and converting program...

Re: Breaking the ST limits

Posted: Fri Mar 20, 2009 11:32 am
by Nyh
ppera wrote:Solved displaying of PCS on Falcon, with all 32K colors - there is small error in Nyh's formula for x above 176.
Don't know is it worth to make some Windows PCS showing and converting program...

Please inform me. Where is the bug? I have tested the code on all PCS pictures I have and got correct results. Can you send me a PCS file that triggers the bug?

Thanks, Hans Wessels

Re: Breaking the ST limits

Posted: Fri Mar 20, 2009 1:15 pm
by ppera
Instead: x1 = 10 * c - (c&1) * 6; there needs to be: x1 = x1 = 10 * c + 1 - (c&1) *6; So, in case of even c it will add 1, in case of odd will sub 5. Actually then will be something like Belczyk's formula for SPU for those columns.
I observed it in first conversion - scan of ZOOL cover, converted. Did not check with other PCS files, as corrected it immediately. Who knows, maybe for most of PCS your formula is OK - as that pic. ZOOL is pretty though task for Photochrome - there are some artifacts at right edge in conversion (with PCS viewers too).
P.S. : checked some PCS files with original formula - there are artifacts in all off them after convert. Sometimes just few, but they are there.

Re: Breaking the ST limits

Posted: Thu Oct 11, 2018 7:13 pm
by Eero Tamminen
ppera wrote:Ray's TGA viewer uses 3 alternating frames with diverse color tones to get some impression of true color. But I think that idea is not good. There is too much flicker because of much difference between frames.


Johan's MGif image manipulation program supports similar thing also for monochrome monitors, to show images in grayscale. With Atari's mono monitor ~72Hz refresh rate, alternating 3 differently dithered frames has much less visible flicker than with lower refresh rate color monitors. That was actually my favorite viewer for the PovRay raytracing results I did on ST. :-)

(If one is running Mgif on Falcon, I think it used DSP code for speeding loading of jpegs, and applying user specified convolution matrixes to the images.)