Code - About the flickering border: using flickering to increase the resolution on the border.

About the flickering border
Alone Coder 

Use flicker to enhance
I decided on border resolutions at the end of 1996
years, back when I used the services of─
a constantly glitching unit called
Pentagon 48and therefore "coded" mainly on 
papers (only in December 1996 I became
go to Pentagon 128).  Perhaps 
it was these pieces of paper that helped convey the idea
through the years - the result was the KOT intro
at DiHalt 2012.

                  * * *

   On Pentagon, as well as on some others─
some Russian Spectrum clones (ATM Turbo,
Profi) the border is not quantized in 4 clock cycles, like 
on the branded Speccy (however, branded
deployment in those days was a mystery - ka─
everyone wrote according to what he had). And once
there is no quantization, then the horizontal resolution─
The size is theoretically 2 screen pixels,
1 processor cycle. But thispermission is not possible─
can be fully used.
   And this thought about flickering bothers me─
Nikla while writing a running line
on the border (in 48K demo), where the symbols are semi─
were too wide and ugly, not─
despite the fact that I shifted some colors─
transitions to 6 clock cycles instead of 12, that is, to
half a typical border "pixel"
(“boxel”? “brothel”? :)).
   It was too late to redo the running line─
but, especially since she, as usual, was
written on paper and hammered into it for a long time
GENS - just like its predecessors 
major projects Font Editor and Sapper'96.
But it was possible to use the method somewhere
more.

   The flickering itself was not open─
I eat, however, it was used only in the area
screen. I didn't see much software back then.
(was there such software at that time?), but the idea
flickering was obvious. In general, I wanted to de─
make flickering sprites in games so that they
looked in color like on Dandy/NES. When
I didn't have a color monitor, but I
I still drew individual phases of this
flickering in notebooks.
   I also used shimmer to make it look higher─
changing the horizontal screen resolution -
my monitor shifted the line by half a pixel,
if there is a lu in front of her at the beginning of the return stroke─
cha (or at the end - I don’t remember) the border was ardent─
cue
   But the colored flickering sprites occupied
me so much that I go to them many times─
rotated, tried to draw in differentreda─
ctors, but never got around to writing the game
with them. I dropped this topic only then
when he collected it at his Pentagon (then already
typical for those times Pentagon 1024+
Turbo ) color-per-dot scheme. 

   On the border the main problem was not with
number of colors (I also made additional
flickering and alternating lines - see plugin 
Raduga for ACEdit, written in 1998─ 
du), but with the fact that the angles looking up 
or down, it is simply impossible to draw.
You can draw something like a rounding (see.
ball in Sinclair Club #5 intro, written by 
in 1997). But the real angle requires 
units of clock cycles on a color transition - this is when
that there are less than 11 bars, that is, 22 peaks─
muddles, between adjacent color transitions
it can't be. (Do you know that on fir─
In Speccy, is it possible to have 16 pixels?) Of course─ 
but, I made a promising chess generator─
fine grid from the pattern on the screen, varying
pauses between color transitions, and experimentation─
tified with other images. But the ogre─
the differences were still cruel - it’s impossible
It was possible to derive even the simplest stars.

   In general, as an example, I took the drawing
arrow pointing left and up (as in
Art Studio) and drew in a notebook what... 
children, if you display the left one in one frame
half of the background under the arrow - let's say, b─
in bright color, and on the other the right half.
The background will flicker, but the black arrow will
this background will be visible.For the arrow to be white, you need to
display the left half of the background in one frame
up to the right border of the arrow, and on
other - the right half of the background to the left
arrow borders. That is, the arrow area─
the glasses will be painted over on both frames.
   On a non-flickering background there is an arrow─
it is impossible, because it would require
solid background on both frames and like a mini─
mum on one of the frames there is a cut out arrow─
ku. With a sharp angle looking up that
impossible.
   If we return to the arrow on the flickering
background, then stars can be realized in this way.
A star with its background - one line like this
arrows (in white version).
   But what happens if the star is
move - will the eye follow it or
Will the image completely fall apart? How
a flickering pattern will appear if
there will be a lot of stars or other elements─
th? How to reduce flicker? Where is this anyway
can I use it? There were many questions─
owls and material for experiments. But in
that moment I entered college, and time─
there was no such experiment, stop it─
There was only time for the mentioned ball.
   Besides, I saw another solution
problems - hardware shutdown of the border,
which, as it turned out, is not required
nothing but wires and a switch (see.
ZX-Guide #1 and #2). 

   By the way, my early experiments under
Pentagon 128 were made with int shifted to 
2familiar places (as on ATM Turbo), then
the board itself, and these programs I adjusted to
one of the most common options─
tov - there are two of them, differing by one measure:
one supported in the first part of PSG-Wins, 
another in the second; I chose the one with─
responded to demo Rage, although she, of course,
was written on the converted Scorpio.  A
what kind of “Pentagons” were supported in the present─
INT swarmer from E2 Soft and in the Condommed demo 
- unknown.

                  * * *

   Years passed, during which the theme of the border
further supported VNN/KCS (light to him
memory! Let that moral one burn in hell
the freak who mocked him last─
ruin of his days, and shame on those who still
fawning over this freak! Du─
guess who you support!)

   And one day, in 2012, on DiHalt announced─
vili border intro competition, just in time for─
chiseled to look like Pentagon.
   This format was perfect for
because I was clearly out of shape that year
to write a full-fledged demo (made mu─
films with students at the RGRTU film studio
Film). Besides, the idea of flickering on the border
still remained unused, so
that there was a point in lighting it up beautifully.

   The general concept of the intro was clear from now on─
zu - stars, inscription, drawing, running line─
chka (we were not talking about full-fledged effects -
we talked about pictures on the border). Questions
stood like this:
 1.What will be in the picture?
 2.How to reduce flicker?
 3.What width will the inscription fit on the bo─
rdere? 
 4.How to play music?
 5.How will the stars move?

                    1.

   The drawing had to be a silhouette. By
at least I have a picture in my head─
I was exactly like that. I looked on the Internet─
those that are on the topic of silhouettes, and I found that one
the cat himself. Of course I couldn't use
pictures as they are, even though they
and anonymous. But the cat could have been animated─
wow! After all, I was just doing cartoons─
mami...
   Candidates for background images from anonymous─
new Internet artists can be found in art─
hivehttp://alonecoder.nedopc.com/zx/
MKBORDER.rar (there is also an inscription on the boron─
dere and code and script generator, about which
below). Compare. I think I did the right thing
choice :)

                    2.

   Flicker is usually reduced by alternating
lines. But for this you need the background color
changed regularly, regardless of location─
there are no stars on it. The reasoning was that─
ki (I quote a historical document. Oh sko─
I'm the only one who has thesehistorical
documents in the folder with materials for Info
Guide #11... ): 

┌────────────────────────── ──────────────┐
 A)
Star - the place where the fill phase changes 
(on one screen 2 pixels further than on 
friend). These stars are not to be missed! 
Then to the right of them in the adjacent frames there will be─ 
children are the same color! 

Impossible stars must be replaced 
phases in the shortest possible time. 

Default line start phase vs. 
phase with the previous screen. The problem is if next 
follow the star with your eyes, the phases there are already different─ 
gee!!! 

It is necessary to assign a phase to each star and 
if necessary, use inversion 
from scratch. But will there then be a common 
Does the screen background fluctuate correctly? 

 1.phase specified by a static screen.
 2.phase set by large stars.
 3.phase set by small stars
(background, different speed). 

It is impossible to comply with all three. 

 B)
Immediately give each star with an inversion of 
end (or beginning): 

frame1: 000001111111111110000 (out (c),r) 
frame2: 111110000000000111111 (out (#fe),a) 

To keep everything from blinking too much, alternatewhat─ 
cut line Divide the layers of stars evenly─ 
num/odd lines. 

Minimum distance between stars = 33 
bars (66 pixels), then 37,38...: 
└────────────────────────── ──────────────┘

   Moreover, you can update the screen (again qi─
I'm typing):

┌────────────────────────── ──────────────┐
 a) lagging behind the beam (the upper border is not
use reverse stroke as continuation 
last frame) 
  b) ahead of the beam (lower curb as the beginning─
lo new frame) 
  c) on another screen (you can use
gigaskrin in the main picture) 
└────────────────────────── ──────────────┘

  I chose option B (see above) with two eq─
wounds, reasoning like this:

┌────────────────────────── ──────────────┐
How to draw pixels on the screen? 
  a) fill in everything, in phase with the border
(large area!) 
  b) two screens flash. For A the boundary is boron─
Dera is visible, but not visible to B. 
  c) switch attributes on one screen.
For A the border of the curb is visible, for B it is not visible─ 
on. 
  d) only for A: depending on color
for most of the line we turn on the desired screen 
on this line. 

Screen time = 24576 ticks 
Return time = 3584 cycles 
(16 lines) 
Bottom curb time = 10752 ticks 
(48lines) 
total max. 38912 cycles 
/11 t = max. 3.5K active area. 

For B there is no need for filling, there is enough time yes─ 
or full screen. 
└────────────────────────── ──────────────┘

   3.5K - this is not counting the time between stars─
a building that can, in principle, be neglected.
It's difficult to use without generating for
stars directly code. And I wanted a gene─
write a script for them. Code I wanted gene─
edited only for the inscription, because in the inscription
I only need the code once, and I move the stars─
tsya.

                    3.

   According to the inscription, the reasoning was as follows:

┌────────────────────────── ──────────────┐
The distance between letters is 12 bars. 

(Because the phase can change in the line, and the battery─ 
there is only one simulator - theoretically you can do it in time 
exa...) 

The line width is 4 bars, because there are 
joints of verticals, and sometimes the vertical of one 
letters, cut off the top of another letter. 

All string types (min 9): 
00000000 
01110000 (A)(C)(G)(J)(O)(Q)(S)(U) 
10001000 
10000000 
00001000 
11111000 
11110000 B D(E)(F)K N P R V 
01111000 (G)(Q)(Y) 
00100000 (T)(Y)(I) 
1000 I(!)(.)(,) 
100010001000 M,W 
?1111111?000 M,W 

Total letter width (except M,W) 32 bars 
(cf. 48 without gigascreen) 
I. ! , 16 bars possible 

Can flash letters (or interlace) 
after one: 

    H(O)W2+11+2+(1+15+1)+2+11+2+12+2
1 1 0  1    1     1 0  1 1  1 0
(+2)11      21      11   16
(+2)
out (c),b ;0 
out (#fe),a ;(11)1 
nop 
ret c 
out (c),b ;(21)0 
out (#fe),a ;(11)1 
nop 
out (c),b ;(16)0 
0 1 1  1    0     1 1  1 0  1 1
   15      17      15   12(+2)
out (c),b ;1 
nop 
out (#fe),a ;(15)0 
ret c 
out (c),b ;(17)1 
nop 
out (#fe),a ;(15)0 
out (c),b ;(12)1 
(+2)

1 1 1  1    1     1 0  1 1  1 0
  (+34)            11   16
out (c),b ;0 
nop 
nop 
nop 
ret c 
ret c 
out (c),b ;(+34)0 
out (#fe),a ;(11)1 
nop 
out (c),b ;(16)0 
0 1 1  1    0     1 1  1 0  1 1
   15      17      15   12(+2)
(как выше) 

1 1 0  1    1     1 1  1 1  1 0
(+2)11          48
(+2)
out (c),b ;0 
out (#fe),a;(11)1 
ds 36/4 
out (c),b ;(48)0 
0 1 1 1 0 1 1 1 1 1 1
 15 17 (+29)
out (c),b ;1 
nop 
out (#fe),a ;(15)0 
ret c 
out (c),b ;(17)1 
(+29)


toes with this method

Minimum letter width (including spaces) 
edges) = 11 = 1+9+1 

H O W I T W O R 
15+1+15+1+29+8?+2+1+14+8?+29+1+15+1+15+1+ 
K S ? 
15+1+15+1+15 = 193 bars 

On average 16 ticks per letter (without gigask─ 
Rina was 48) 

You can interlace (or blink) individual 
columns of letters. 
└────────────────────────── ──────────────┘

   Width 193 bars (more screen) smile─
wasn't enough, so I decided to post it on
different lines are not whole letters, but separate ones
columns of letters. Describe this in a text file─
there was already a problem with zeros and ones─
matic, so I drew the inscription in bmp
three colors: black (background), white and green
(white and green - even and odd lines─
ki screen for different sticks) and wrote
code generator from it.
   The picture and all its intermediate versions
(in final versionthe width turned out to be 160
bars) you can see in the mentioned ar─
hive in the filehowitworks.bmp.

                    4.

   I had my own procedure for the mood─
ki for a specific beat (ZX-Guide #3), but not
had its own decent register player
music. What happened in Sinclair Club #5
not packed at all. And what I wrote for
the TFM Music Maker project never happened from─
well-organized, especially not tailored to a fixed
given number of cycles.

   So I decided not to waste time and
compiled the music in the utility
AY-ZIP-Player-Compiler Ver_1.2 
by TmK/deMarche.
   It has a simple format based on
cutting music into fragments is fixed─
length and trying to find a single-byte
way of encoding certain groups of re─
hystrov.
   There are only a couple of problems - what's out of the box
Compilation into multiples is not supported
pages (I creatively overcame this in
Nedodemo 2) and that compiled music 
must be initialized before use─
vat. But the program is distributed from─
covered source, and there is hope for it─
ruling over all problems in the future.

                    5.

   It was supposed to move the stars along
both axes in the style of the latest Shock part
Megademo, with insidious consequences for 
distances between stars and for the phase of measures─
tsaniya. Therefore the generator had to do
script forasterisks. This script is worth it─
consist of addresses of procedures of typeuse>: out (c),b and/or out (#fe),a:ret and
(for displaying 2-byte records in
page):
 pop hl
 pop de
 exx
 out (c),d ;scrpg
 exx
 ld (hl),e
 inc l
 ld (hl),d
 exx
 out (c),e ;curpg
 exx
 ret
:88 t

   To the page - because you need two screens─
on (the picture changes very much between
screens - it takes a long time to draw changes), and
The script itself should also be on the page,
if we want to take a lot of shots. I ho─
tel domore frames - just for
animation of the picture needed 12, but
these phases do not change every frame. (In the end
it turned out 48 frames, and the adjustment was just right─
memory was measured by the number of stars.)

   At first I intended to make another
set of procedures:

┌────────────────────────── ──────────────┐
 - pause N bars, out 0 (out (c),r),
out 1 (out (#fe),a) 
  - pause N bars, out 1 (out (#fe),a),
out 0 (out (c),r) 
  - move the pointer on the screen to NN(de?)
  - write a specific byte (you can
make a 4 byte record for B immediately according to the definition. 
address) 
  - [fill N bytes with zeros (11 t/b) -
only for A] 
  - [fill N bytes #ff (11 t/b) -
only for A] 
└────────────────────────── ──────────────┘

   But with a universal rendering procedure─
ki, without any shifts of pointers, it was successful─
Hell, especially when it was decided to move
on the stack. Compare:
 a) on the stack, 2 bytes per star
(pause 10 bars).
 b) in hl 1 byte per star
(pause at least 19 bars:
ld a,(de):inc e:ld l,a:jp (hl) ).

   The script generator was written in Delphi using
to the following technical specifications:

┌────────────────────────── ──────────────┐
The star generator must know: 
  1. Coordinates of stars.
  2. Mask of a static picture.

The script generator needs to know: 
  1. A picture to strive for.
  2. Current picture on one screen
(actually received). 
  3. Current picture on the second screen
(actually received). 

Update only what has changed! 
└────────────────────────── ──────────────┘

   The star generator builds a picture for which─
swarm must strive, and the script generator
comes from the difference between it and the current ka─
picture on the current screen.

   Since the stars in option B have for─
day front, then you need to be careful on the le─
howl and the right border of the screen. It turns out
that there are 32 bars of "blind spot" between the lines
- it’s not as much as it seems, and it’s necessary under─
beat to beat:

┌────────────────────────── ──────────────┐
On the reverse move, turn on the desired color as much as possible 
earlier upon entering the blind zone (32 ticks). 

But delay = 11+10(ret)+12(out) = 33[+10 
(ret)] - already leaving the blind spot!!! 

For stars on the border it’s just a color transition 
(we are at the beginning of the blind zone -1..-12) 
For stars near the boundary, pause 10+4+12 
(we are at the beginning of the blind zone +0..25) 

Min. pause until next star 10+4+11 = 25 
(25+25 = real zone without stars, so according to 
25 bars from the sides) 

When generating code, the rear ones are irrelevantfro─ 
nts of stars in the blind spot and color transition me─ 
I'm waiting in lines. The beginnings of stars in the blind spot 
relevant. 

The color transition between lines is encoded then─ 
only in the absence of a star on the boundary. When─ 
what is coded at the beginning of the blind zone +25. 
└────────────────────────── ──────────────┘

   Conflicts between a star at the end of one
lines and a star at the beginning of the next one I exclude─
are expected if, for example, all the stars are located
laid on even lines.

   And now, having debugged all these generators (generously
supplied with logs), I generated a script,
wrote the code, ran it, and saw CREEPY
PORRIDGE ON THE SCREEN. It turns out that if the stars
move along both axes, even if only
on even lines (i.e. in constant phase),
the eye cannot track the flicker correctly─
but... It was a blow.
   I spent a month on this project, so
I couldn’t just give it all up. Therefore, in─
left decision turned off the movement of stars along
Y and assembled as is.

   It didn't turn out that bad, actually─
le...