Display Trick Idea - would like some thoughts...

All about ST/STE demos

Moderators: Mug UK, lotek_style, Moderator Team

elliot
Atari User
Atari User
Posts: 40
Joined: Tue Mar 17, 2009 2:00 pm

Display Trick Idea - would like some thoughts...

Postby elliot » Wed Apr 17, 2013 12:18 am

I used to spend huge amount of time programming on the STE and always loved the border removal, etc effects. Anyway, about 23 years ago I had an idea for a screen "hack" but I never managed to make it work (it needed knowledge of timers and scan syncing, etc which I did not have then).

This idea has been bugging me and I wanted to run it past some people to know if it is possible or not! I do not mind either way I just want to know.

In short the idea is for an STE to display pixel perfect 4096 colours with ease anywhere. Bear with me for moment and I will explain (it will be a little pseudo code);

First we setup the screen with a matrix, we have a 32K chunk of memory which the shifter is displaying, in this 32k chunk we setup the pixels to display colours as follows (think top left corner of screen). Pixel shows the X value the colour lines are "raster" lines (the colours are encoded in the normal bitmap format).

The fist line just indicates pixel 0, 0 on the screen then 1, 0 and so on. After that it is the colour displayed (i.e. 2 is colour 2 from the pallet, FFFF8242)
pixel 123456789ABCDEF123456789ABCDEF123456789ABCDEF ----> all the way to 320 pixels
Colour 23456789ABCDEF23456789ABCDEF23456789ABCDEF23456789 -----> all the way to 320 pixels
Colour 23456789ABCDEF23456789ABCDEF23456789ABCDEF23456789 -----> all the way to 320 pixels
Colour 23456789ABCDEF23456789ABCDEF23456789ABCDEF23456789 -----> all the way to 320 pixels
Colour 23456789ABCDEF23456789ABCDEF23456789ABCDEF23456789 -----> all the way to 320 pixels and so on

So if the screen palette was loaded with (from ffff8240) 000, F00, 111, 222, 333, 444, 555, 666, and so on On the screen would be black border, a vertical line with red (the F00, at pixel one) and then shades of grey until pixel 16 which would be another red pixel. I really hope this part makes sense, tell me if not.

Okay now we need to look at our picture data. This is stored as a word per pixel, a word a pixel works out as 320x2x200 which is 128K. If the screen data is red, green, blue then red, green, blue for each pixel then out data will look like this;

0F00, 00F0, 000F, 0F00, 00F, 000F and so on.
0F00, 00F0, 000F, 0F00, 00F, 000F and so on.
0F00, 00F0, 000F, 0F00, 00F, 000F and so on.
0F00, 00F0, 000F, 0F00, 00F, 000F and so on.

Okay so now we have a screen matrix showing colours 2 - 16 and we have pixel colour data stored as words...

This is the tricky part. We set a timer to interrupt close to pixel 0, 0 (timer or HBL, I do not know), we then setup the Blitter to do some shifting of data, in short the Blitter will fill the colour pallet with raw data from out screen data.

We set the source data to be our screen data (the 0F00, 00F0..... and so on) and we set out destination to be FFFF8242 (one colour above the background). I am also going to say some Blitter terms which I am not sure on (please be forgiving, it has been many years).

We set the X count to be 15 words (sorry I can't remember if the Blitter registers work in words or bytes) The Destination is set to FFFF8242, this is the point we are filling the palette.
The destination X increment set to a word The destination Y increment set to -15 words (can we use negative numbers in the blitter?). The source is set to our data (this is the 128K chunk) The source X increment is set to a word The source Y increment is set to 0

We then set the Blitter off, with luck it will fill the colour palette with data as the shifter chip moves the scan line across the screen.

Scenarios I foresee;

I the Blitter is too slow for the electron beam - all is lost and the idea is down the drain.

The Blitter is (by chance) perfectly in line with the scan line and moves data to the palette all through the screen display - very unlikely.

The Blitter is faster than the scan line and needs re-synching every now and then (with luck every 4 scan lines but probably every 30 pixels). Timing could be amended by a Timer OR we could fill source data with some extra blanks to delay the Blitter (this would make the source data messy but is a pay off).

The best scenario is that each scan line we have to reset the Blitter for the next 320 pixels.

Just imagine if this method works in Med res, with a border removed and interlace this would be 640x480x4096 (nearly VGA).

I would appreciate a response even if it is no.

Thanks guys.

Elliot...

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: Display Trick Idea - would like some thoughts...

Postby mc6809e » Wed Apr 17, 2013 12:54 am

A single blitter write takes 4 CPU cycles. One read and one write take 8. Every 8 CPU cycles is 16 pixels so the blitter is too slow for this.

elliot
Atari User
Atari User
Posts: 40
Joined: Tue Mar 17, 2009 2:00 pm

Re: Display Trick Idea - would like some thoughts...

Postby elliot » Wed Apr 17, 2013 1:02 am

Okay is all I needed to know. It has just been bugging me is all and now I know.

I did suspect the blitter did not have the muscle for it but I thought I would post just in case.

Okay now I am clinging on but what about the Mega STE?

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Display Trick Idea - would like some thoughts...

Postby Nyh » Wed Apr 17, 2013 7:07 am

elliot wrote:Okay now I am clinging on but what about the Mega STE?

Just the same. All in the Mega ST runs at the same speed as in the ST, except for the processor, which runs a 16 MHz. To get many colors you need a fast data bus. For the trick you described to work the computer would have to run at 64MHz in stead of 8MHz.

Hans Wessels

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Display Trick Idea - would like some thoughts...

Postby Nyh » Wed Apr 17, 2013 7:09 am

mc6809e wrote:A single blitter write takes 4 CPU cycles. One read and one write take 8. Every 8 CPU cycles is 16 pixels so the blitter is too slow for this.

At low resolution one pixel is one CPU cycle. The blitter can change color every 8th color.

Hans Wessels

elliot
Atari User
Atari User
Posts: 40
Joined: Tue Mar 17, 2009 2:00 pm

Re: Display Trick Idea - would like some thoughts...

Postby elliot » Wed Apr 17, 2013 2:06 pm

Man that is really too slow ...... every 8 pixels... So every 8 pixels it can change one word?

Is it just BUS speed or is the Blitter a little pants? I do seem to remember doing some things in CPU as is was just quicker (screen clears I think).

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2310
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Display Trick Idea - would like some thoughts...

Postby calimero » Wed Apr 17, 2013 5:16 pm

Nyh wrote:. For the trick you described to work the computer would have to run at 64MHz in stead of 8MHz.

which part of computer?

Shifter already run on 32MHz in basic ST from 1985. right?

it is not speed of computer/CPU but rather design or "organisation" of computer... could Amiga do the trick?
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1750
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Display Trick Idea - would like some thoughts...

Postby Cyprian » Wed Apr 17, 2013 5:22 pm

calimero wrote:it is not speed of computer/CPU but rather design or "organisation" of computer... could Amiga do the trick?


this is due to bus bandwidth which is determined by memory access time.
Exactly the same issue exists in Amiga where during visible a line Cooper can change color every 8th low res pixel, and CPU every 8th or 12th low res pixel
Lynx II / Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: Display Trick Idea - would like some thoughts...

Postby mc6809e » Thu Apr 18, 2013 3:13 am

Cyprian wrote:
calimero wrote:it is not speed of computer/CPU but rather design or "organisation" of computer... could Amiga do the trick?


this is due to bus bandwidth which is determined by memory access time.
Exactly the same issue exists in Amiga where during visible a line Cooper can change color every 8th low res pixel, and CPU every 8th or 12th low res pixel


I think on the Amiga it's possible every 4th pixel. The copper does half on the even cycles and the CPU does the other half on the odd cycles. Bitplane DMA must be turned off, however, to make room for the CPU.

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1750
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: Display Trick Idea - would like some thoughts...

Postby Cyprian » Thu Apr 18, 2013 6:04 am

ok, actually blitter can also do change color every 4th when use halftone registers
Lynx II / Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Display Trick Idea - would like some thoughts...

Postby Nyh » Sun Apr 21, 2013 10:41 pm

elliot wrote:Man that is really too slow ...... every 8 pixels... So every 8 pixels it can change one word?

Is it just BUS speed or is the Blitter a little pants? I do seem to remember doing some things in CPU as is was just quicker (screen clears I think).

It is the memory bus speed. One bus cycle takes 4 clock ticks. So reading a word takes 4 cycles and writing it into the color registers takes another 4 clock ticks.

When the blitter uses halftone RAM as source it can do only write cycles and change color every 4th clock tick. But halftone RAM is only 16 words big. The CPU can write register contents every 4th clock tick to color registers with MOVEM but only to increasing memory addresses. The 16 registers can hold 32 words.

Good programmers have thought about the color changing problem on a ST. AFAIK the maximum number of color changes for a normal ST is 58 per scanline.

Hans Wessels

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Display Trick Idea - would like some thoughts...

Postby AtariZoll » Mon Apr 22, 2013 8:08 am

Beside slow bus, there is another problem with idea: you can not use timer for this, because will not get exact moment in pixel, when to start shifter writes. All hi-color code use same trick for sync start, and it is based on reading current video addr. low register.
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
bod/STAX
Atari Super Hero
Atari Super Hero
Posts: 508
Joined: Wed Nov 24, 2004 8:13 pm
Location: Halesowen, West Midlands, England

Re: Display Trick Idea - would like some thoughts...

Postby bod/STAX » Mon Apr 22, 2013 7:31 pm

mc6809e wrote:I think on the Amiga it's possible every 4th pixel. The copper does half on the even cycles and the CPU does the other half on the odd cycles. Bitplane DMA must be turned off, however, to make room for the CPU.


I always thought that the Copper in the Amiga could do a 4 pixel write either with tricks or not.

I assumed this is how a lot of those roto-zoomers were done on the Amiga.

A little off-topic.

How were those 1 pixel plasmas done on the Amiga?

For example in the Silents Global Trash demo.

Looking at them it's obviously a calculated pattern but are there RGB copper bars running through them?

I know Hemoroids did a version of this effect.
So let it be written, So let it be done. I'm sent here by the chosen one.

mc6809e
Captain Atari
Captain Atari
Posts: 159
Joined: Sun Jan 29, 2012 10:22 pm

Re: Display Trick Idea - would like some thoughts...

Postby mc6809e » Tue Apr 23, 2013 12:09 am

bod/STAX wrote:
mc6809e wrote:I think on the Amiga it's possible every 4th pixel. The copper does half on the even cycles and the CPU does the other half on the odd cycles. Bitplane DMA must be turned off, however, to make room for the CPU.


I always thought that the Copper in the Amiga could do a 4 pixel write either with tricks or not.

I assumed this is how a lot of those roto-zoomers were done on the Amiga.

A little off-topic.

How were those 1 pixel plasmas done on the Amiga?

For example in the Silents Global Trash demo.

Looking at them it's obviously a calculated pattern but are there RGB copper bars running through them?

I know Hemoroids did a version of this effect.


It takes two even memory cycles to do a copper write -- one for the write instruction, and one for the 16-bit value. There are four even memory cycles every 16 pixels so there are eight pixels between writes. But note that the write doesn't have to be constrained to eight pixels boundaries. The actual write can occur on a four pixel boundary. It's just that the palette register can't be changed by the copper more frequently than once every eight pixels.

It's also possible to change a palette register twice in four pixels by carefully timing copper and CPU writes if one is willing to tolerate a six pixel delay afterword and no bitplane DMA. Instead of 4px-4px-4px-4px changes you have 2px-6px-2px-6px depending on the relative phases of the CPU and copper writes.

I don't think true plasmas are being done during the Global Trash demo. Looks like basic color cycling of a 32 color display. It's possible they're using HAM to get more colors and just cycling the bottom 16 palette registers.

WayneKerr
Atari nerd
Atari nerd
Posts: 49
Joined: Mon Mar 03, 2003 7:41 pm

Re: Display Trick Idea - would like some thoughts...

Postby WayneKerr » Sat Apr 27, 2013 10:59 am

The "RGB plasmas" you refer to on the Amiga were done with a calculated 'pattern' as you guessed, h/w scrolling used to "wobble" per scanline with the R/G/B colours handled separately and 'mixed' into the copperlist with the Blitter.
The 4x4 rotozoomers are done simply by having a 1-pixel high picture of 4-pixel wide coloured bars (colour 1-15 and then repeat as needed for the width of the effect) - this is stretched the height of the effect using the modulo and multiple colour-changes per line with the copper for each 4x4 "pixel"...

evil
Captain Atari
Captain Atari
Posts: 185
Joined: Sun Nov 12, 2006 8:03 pm

Re: Display Trick Idea - would like some thoughts...

Postby evil » Sun Apr 28, 2013 8:25 am

elliot wrote: the Blitter is too slow for the electron beam - all is lost and the idea is down the drain.


As has been said, this is the case. 8 pixels per change (or 4 pixels with halftone, but that's limited to just one palette).

Zerkman released his MPP display-tech together with blitter mode (56 colours per line), you can download code, conversion tools etc from his site: http://zerkman.sector1.fr/index.php?pos ... ile-format

All in all, it is still pretty much what was already done by Spectrum 512 in 1987, only that without blitter it "only" does 48 colours per line :) I still have to hand it to that russian guy who did Spec 512. Not only the displaymode, but he actually managed to make a useable painting program for it, I think nobody have ever since (ok, Dougs unreleased Chroma might have pulled it off).


Also I don't think you can clear the screen faster with CPU. movem.l still uses 8 cycles per longword and you need re-starting the movem many times that will build up overhead, blitter do it in one pass. But movem.l clearing is not far from the blitter. However to clear individual bitplanes, the blitter has no mercy, it will leave the cpu far behind.

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Re: Display Trick Idea - would like some thoughts...

Postby ljbk » Sun Apr 28, 2013 9:26 am

Spectrum 512 can change 48 colors per line but in fact only 42 are "really" changed (3 times logical colors 1-14) by the paint program.
Logical color 0 is normally black and logical color 15 is used as the foreground color (mouse).
A plain Atari STF, with no blitter, can change (at least) 53 colors per line in PAL (512 cycles per line) but this leaves room for nothing else: no mouse, so no "true color" paint program, no digi-sound (it is possible with Spectrum 512) ... and the changes are not as "constant" as with Spectrum 512.
I can not tell if the visual results would be much better than with Spectrum 512 or if it would be very close.

Paulo.

User avatar
calimero
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2310
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Display Trick Idea - would like some thoughts...

Postby calimero » Sun Apr 28, 2013 11:55 am

evil wrote:
elliot wrote:All in all, it is still pretty much what was already done by Spectrum 512 in 1987, only that without blitter it "only" does 48 colours per line :) I still have to hand it to that russian guy who did Spec 512.

if somebody miss: http://www.asterius.com/atari/spectrum.html
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2978
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: Display Trick Idea - would like some thoughts...

Postby AtariZoll » Sun Apr 28, 2013 12:06 pm

Cyg did code for 54 colors/line - what is aprox. max possible with unmodded STE . Unfortunately, it has same flaw as Zerkman's MPP - works well only in Steem - because possible different wake-up states on real STE may experience bad dots.
Experience says that not only color number per line is important, but proper preprocessing, dithering, error diffusion - for good looking result.
I can say that Cyg did here really good job - he posted some demo screens here, then links to some hi-color videos. Would be really good to finish that conversion SW and make fixes for real STE :D
Famous Schrodinger's cat hypothetical experiment says that cat is dead or alive until we open box and see condition of poor animal, which deserved better logic. Cat is always in some certain state - regardless from is observer able or not to see what the state is.

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Re: Display Trick Idea - would like some thoughts...

Postby ljbk » Sun Apr 28, 2013 1:06 pm

ljbk wrote:Spectrum 512 can change 48 colors per line but in fact only 42 are "really" changed (3 times logical colors 1-14) by the paint program.
Logical color 0 is normally black and logical color 15 is used as the foreground color (mouse).
A plain Atari STF, with no blitter, can change (at least) 53 colors per line in PAL (512 cycles per line) but this leaves room for nothing else: no mouse, so no "true color" paint program, no digi-sound (it is possible with Spectrum 512) ... and the changes are not as "constant" as with Spectrum 512.
I can not tell if the visual results would be much better than with Spectrum 512 or if it would be very close.

Paulo.


When i say 53 colors, i mean changed ones.
In fact, i can use 55:
- logical color 0 is unchanged: 1 color;
- logical colors 1-12 are changed 4 times: 48 colors;
- logical color 13 is changed 3 times: 3 colors;
- logical color 14 is changed 2 times: 2 colors;
- logical color 15 is unchanged: 1 color;
39 out of the 53 changes occurr during bitmap display: we have a complete set of 14 new logical colors during HBL.
The funny pixels can be avoided by not using the changing logical color at the changing pixel.


Paulo.

evil
Captain Atari
Captain Atari
Posts: 185
Joined: Sun Nov 12, 2006 8:03 pm

Re: Display Trick Idea - would like some thoughts...

Postby evil » Sun Apr 28, 2013 6:51 pm

ljbk wrote:Spectrum 512 can change 48 colors per line but in fact only 42 are "really" changed (3 times logical colors 1-14) by the paint program.
Logical color 0 is normally black and logical color 15 is used as the foreground color (mouse).


The Spectrum file stores 48 colours, and viewers will show them all (probably the paint program too, but with funny mouse colour, but I havn't tested). So Spectrum 512 tech does 48. Some conversion tools, eg Photochrome, can select between all 48 or the "legal" colours.


ljbk wrote:A plain Atari STF, with no blitter, can change (at least) 53 colors per line in PAL (512 cycles per line) but this leaves room for nothing else: no mouse, so no "true color" paint program, no digi-sound (it is possible with Spectrum 512) ... and the changes are not as "constant" as with Spectrum 512.


This is made by Zerkman in the MPP mode 0, here's a description of all four modes:

Mode 0: 320x199, CPU based, displays 54 colors per scanline, with non-uniform repartition of color change positions.
Mode 1: 320x199, CPU based, displays 48 colors per scanline, with uniform repartition of color change positions.
Mode 2: 320x199, blitter based (STE only), displays 56 colors per scanline, with uniform repartition of color change positions
Mode 3: 416x273, CPU based, displays 48+6 colors per scanline, with overscan and non-uniform repartition of color changes.

All these modes can also be combined with double image/palette interlace. It can give quite spectacular results. With these "in between" colours, the theoretical number of experienced colours each line is doubled.

Displaycode, conversion tools (incl. source), viewing program for Atari are all available from Zerkmans site: http://zerkman.sector1.fr/index.php?pos ... ile-format.
I will also update my demo sequencer package some day as I've already implemented all MPP modes.

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Re: Display Trick Idea - would like some thoughts...

Postby ljbk » Sun Apr 28, 2013 9:17 pm

I have to say i did not know about "Zerkmans site".
I just went there now and had a look.
His program changes:
- 3 times all logical colors;
- a 4th time logical colors 0 to 5;
I agree we have 54 color changes in that source, but again, i say that it can be discussed if it is interesting to change 4 times the logical color 0 (border color) when handling a non fullscreen pic unless we want raster colors in the border. Those changes have a maximum of 148 cycles between them (if i did not fail my calcs :) ) when we have a 192 pixels (cycles) border so in fact if we don't want rasters, 2 of the 4 changes to locigal color 0 are useless. So we are reduced to 52 usefull color changes.

Here is my 53 color change structure and the pixels where the changes occur:
A6 points to $FFFF8242:

Code: Select all

   movem.l   (a7)+,d0-d7/a0-a5
   movem.l   d7/a0-a5,(a6)
   lea   (a6),a4         04
   lea   (a6),a5         04
   move.l   (a7)+,(a4)+      20   017,021
   move.l   (a7)+,(a4)+      20   037,041
   move.l   (a7)+,(a4)+      20   057,061
   move.l   (a7)+,(a4)+      20   077,081
   move.l   (a7)+,(a4)+      20   097,101
   move.l   (a7)+,(a4)+      20   117,121
   move   (a7)+,(a4)+      12   133
   movem.l   d0-d6,(a6)      64   145 -> 197
   move.l   (a7)+,(a5)+      20   213,217
   move.l   (a7)+,(a5)+      20   233,237
   move.l   (a7)+,(a5)+      20   253,257
   move.l   (a7)+,(a5)+      20   273,277
   move.l   (a7)+,(a5)+      20   293,297
   move.l   (a7)+,(a5)+      20   313,317


As you can see this code is halfway between the Spectrum 512 regular changes and the Zerkman code.
Only tests, like PNG/BMP converts, with specific built SW, can tell which of the two solutions is better.
I have never built such a program for this format because there is no free time for anything else so it is not very interesting.
For other formats like fullscreen ones, or custumized ones, you just have to look at The Overscan Demos to find out that i did build such programs back in 1989/1990.

Regarding the Spectrum 512 program handling 42 colors despite having the code and the format for 48, i am 100% sure of that, as i am handling SPU/SPC files since late 1988. Of course, other programs can fill up the 48 colors but again with logical color 0 changing at pixel 1 (pixel 0 may flicker with one of the RGB values changing) and 321 (1 pixel into the border(with first border pixel possibly flickering)), unless we want border colors, logical color 0 change is not very usefull except for the part between pixel 1 and 161. Spectrum 512 uses that logical color 0 to allow the user to select a color to use (palette). Color 15 is the "orange" one that changes to grey when the mouse goes over the color cubes. It is also the color the program uses to do the drawing operations like line, fill and so on. When the user changes color, the program processes those changed pixels with logical color 15, with extreme speed (!), and distributes them other the remaining logical colors.


Paulo.

PS:
A variant can allow to change logical color 15 during the border (pixel 321):

Code: Select all

   movem.l   (a7)+,d0-d7/a0-a5
   movem.l   d7/a0-a5,(a6)
   lea   (a6),a4         04
   lea   (a6),a5         04
   move.l   (a7)+,(a4)+      20   021,025
   move.l   (a7)+,(a4)+      20   041,045
   move.l   (a7)+,(a4)+      20   061,065
   move.l   (a7)+,(a4)+      20   081,085
   move.l   (a7)+,(a4)+      20   101,105
   movem.l   d0-d6,(a6)      64   117 -> 169
   move.l   (a7)+,(a5)+      20   185,189
   move.l   (a7)+,(a5)+      20   205,209
   move.l   (a7)+,(a5)+      20   225,229
   move.l   (a7)+,(a5)+      20   245,249
   move.l   (a7)+,(a5)+      20   265,269
   move.l   (a7)+,(a5)+      20   285,289
   move.l   (a7)+,(a5)+      20   305,309
   move   (a7)+,(a5)+      12   321


And all this can be "delayed" by up to 2 nops: 309->313 or 317 and 321->325 or 329 and (021,025) -> up to (029,033).
Again, only tests, like PNG/BMP converts, can sort out the best solution.
Differences should not be very big even compared to the Spectrum 512, 42 colors per line + black, reference.
May be it is possible to change Zerkman C source to handle these two alternatives.

User avatar
ljbk
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Thu Feb 19, 2004 4:37 pm
Location: Estoril, Portugal

Re: Display Trick Idea - would like some thoughts...

Postby ljbk » Tue Apr 30, 2013 8:13 am

Hi !

Just for the sake of "records", it seems that a plain Atari STF can be able to display (at least :) ) 58 different colors on a single scan line with 56 changing.
Of course, changes are done in a totally non-uniform way and probably the (BMP/PNG convert) results are better with a more uniform change of less colors.

Here are some of the theorical possibilities derived from my original 53 colors routine:

Code: Select all

58 colors (2 fixed + 56 changing every scan line) (A6=$FFFF8242):
- logical color 0
- logical color 15
- changing 4 times logical colors 1..14

   movem.l   (a7)+,d0-d7/a0-a5   124   -127/385
   movem.l   d0-d6,(a6)      64   -003/509 (BORDER)
   movem.l   d7/a0-a5,(a6)   64   009 -> 061
   movem.l   (a7)+,d0-d7/a0-a5   124   185
   movem.l   d0-d6,(a6)      64   197 -> 249
   movem.l   d7/a0-a5,(a6)   64   261 -> 313
   or.l   d0,d0      8   321

57/58 colors (1 fixed + 56 changing every scan line) (A6=$FFFF8242):
- logical color 0
- logical color 1 fixed on even lines
- logical color 15 fixed on odd lines
- changing 4 times logical colors 2..14 on odd lines
- changing 4 times logical colors 3..15 on even lines

   movem.l   (a7)+,d0-d7/a0-a5   124   -127/385
   movem.l   d0-d6,(a6)      64   -003/509 (BORDER)
   movem.l   d7/a0-a5,(a6)   64   009 -> 061
   movem.l   (a7)+,d0-d7/a0-a5   124   185
   movem.l   d0-d6,(a6)      64   197 -> 249
   movem.l   d7/a0-a5,(a6)   64   261 -> 313
   addq   #2,a6      8   321
   movem.l   (a7)+,d0-d7/a0-a5   124   -127/385
   movem.l   d0-d6,(a6)      64   -003/509 (BORDER)
   movem.l   d7/a0-a5,(a6)   64   009 -> 061
   movem.l   (a7)+,d0-d7/a0-a5   124   185
   movem.l   d0-d6,(a6)      64   197 -> 249
   movem.l   d7/a0-a5,(a6)   64   261 -> 313
   subq   #2,a6      8   321

57 colors (1 fixed + 56 changing every scan line) (A6=$FFFF8242):
- logical color 0
- changing 2 times logical color 1
- changing 4 times logical colors 2..14
- changing 2 times logical color 15

   movem.l   (a7)+,d0-d7/a0-a5   124   -127/385
   movem.l   d0-d6,(a6)      64   -003/509 (BORDER)
   movem.l   d7/a0-a5,2(a6)   68   013 -> 065
   movem.l   (a7)+,d0-d7/a0-a5   124   189
   movem.l   d0-d6,(a6)      64   201 -> 253
   movem.l   d7/a0-a5,2(a6)   68   269 -> 321

56 colors (56 changing every scan line) (A6=$FFFF8244):
- changing 2 times logical color 0 (1 of them useless(border color))
- changing 4 times logical colors 2..14
- changing 2 times logical color 15

   movem.l   (a7)+,d0-d7/a0-a5   124   -135/377
   movem.l   d0-d6,(a6)      64   -011/501 (BORDER)
   movem.l   d7/a0-a5,-4(a6)   68   005 -> 057
   movem.l   (a7)+,d0-d7/a0-a5   124   181
   movem.l   d0-d6,(a6)      64   193 -> 245
   movem.l   d7/a0-a5,-4(a6)   68   261 -> 313



And of course, if i change the or.l d0,d0 to move a6,(a6) and i do everything 4 pixels earlier, i will have 59 colors on the same line ... :lol:


Paulo.

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Display Trick Idea - would like some thoughts...

Postby Nyh » Tue Apr 30, 2013 10:47 am

ljbk wrote:Just for the sake of "records", it seems that a plain Atari STF can be able to display (at least :) ) 58 different colors on a single scan line with 56 changing.

Correct:
http://www.atari-forum.com/viewtopic.php?f=81&t=21148#p187790

Hans Wessels

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Re: Display Trick Idea - would like some thoughts...

Postby Nyh » Tue Apr 30, 2013 10:55 am

evil wrote:All in all, it is still pretty much what was already done by Spectrum 512 in 1987, only that without blitter it "only" does 48 colours per line :) I still have to hand it to that russian guy who did Spec 512. Not only the displaymode, but he actually managed to make a useable painting program for it, I think nobody have ever since (ok, Dougs unreleased Chroma might have pulled it off).

Boris Tsikanovsky did not only solve the multiple colors per line problem. But he even solved the ACIA jitter problem. While in full color mode in Spectrum 512 you can use the mouse. The routines he is using to accomplish this in Spectrum 512 are still quite astonishing.

Hans Wessels


Social Media

     

Return to “Demos - General”

Who is online

Users browsing this forum: No registered users and 6 guests