16 colors - roxxx!
ZXNet echo conference «code.zx»
Hello, All
I read about the 16 colors mode in IG8, looked at the toy (PANG) - interested
:rolleyes: I wanted to figure it out and... :mad:
hmm... AlCo of course rules :rolleyes: but does anyone have a normal one?
example of how to display a simple sprite (converted from the same damn bmp
?) and no matter how hard I tried :D I figured out its types, but I couldn’t master it... :sleep:
Hello, captain cobalt
cap> It would be better if the memory had a more linear structure.
What does "more linear structure" mean?
Hello, breeze
bre> mdyyyyyy................ :o memory is wasted in a way that is not childish :( if
bre> I understood correctly that I is intensity? that is, brightness? from here and
bre> 16 colors. and our attributes are now not 768 bytes, but 768 * 8 = 6144
bre> (#1800) ?
bre> #4000 - 5800 - 1st part
bre> #5800 - #7000 - attributes ? or what? What's the problem here?
bre> since #6000 is already the 2nd screen... :rolleyes:
There is no smell of attributes there. For each pair of points, their colors are written in a byte. That is
if you have (#4000)=%10111111, then at the very top left you will have lights
two pixels - one white, the other bright white.
(damn, the representation of color in a byte is crooked - you can’t immediately tell which byte is
what colors does it answer? #7F is much more convenient - you can immediately see that one color 7 is white,
and the other F is bright white).
It eats up memory - that's okay, but what does this circuit actually take away?
The processor's hard-earned time is a fuck-up. AlCo said that the process is slowing down
by a third.
PS [self-promotion]: if you are disappointed in this mode, switch to mine. Same 16
colors per point, the processor is not slowed down, and the memory is generally external. (who would give it to me?
gland helped to implement)
Hello, lvd
lvd> Well, for example, since in this mode there are 128 bytes per line
lvd> (just the sum of bits), then you could do it like this: first line by
lvd> addresses $4000-$407f, the second - $4100-$417f$ and so on until the 96th, and from the 97th
lvd> - lines at addresses $4080-$40FF, $4180-$41FF and so on. Well this
lvd> of course it’s rough (24 kilos for 1 screen), but the idea is something like this if
lvd> it would be great.
I understand correctly that in this way linearity is achieved in the sense
locations in memory (no division into chunks with "gaps"), but not linearity
pixels (or rows of pixels)? This method is more convenient than the truly linear one.
pixel locations in memory and if so, what?
Hello, lvd
lvd> Why is line linearity not achieved? Each line is 128 bytes
lvd> in a row (and not like AlCo).
Well, at address #4000-#407F there is line number 0, at address #4080-#40FF there is
line number 97 (according to your description). Then comes line number 1 and line
number 98, etc. What kind of linearity is this? Compared to AlCo's proposal - yes,
individual pixels are "next to each other".
lvd> Advantages: move to the next 2 pixels - inc l, to the next one
lvd> line - inc h.
Until a certain point. What will happen if in HL we say #407F and you do
INC L? Where will you end up? I think so on a new line, but not the next one
list".
Hello, SAM style
SAM> Each byte in each of the areas is the color of those points for which it is
SAM> answers. Color is presented in IiRGBrgb format. IRGB - left color
SAM> points in this pair, irgb - right
mdyyyyyyy.............. :o memory is wasted in a way that is not childish :( if I
I understood correctly that I is the intensity? that is, brightness? hence the 16 colors.
and our attributes are now not 768 bytes, but 768 * 8 = 6144 (#1800)?
#4000 - 5800 - 1st part
#5800 - #7000 - attributes ? or what? What's the problem here?
since #6000 is already the 2nd screen... :rolleyes:
Hello icebear
ice> What does “more linear structure” mean?
Well, for example, since in this mode there are 128 bytes per line (just the sum
bits), then you could do it like this: the first line at addresses $4000-$407f,
the second - for $4100-417f$ and so on until the 96th, and from the 97th - lines by address
$4080-$40FF, $4180-$41FF and so on. Well, this is of course rude (24 kilos because for 1
screen), but the idea is something like this: if there was one, it would be great.
Hello icebear
ice> I understand correctly that linearity is achieved in this way
ice> in the sense of location in memory (there is no division into pieces with "gaps"), but
ice> not linearity of pixels (or rows of pixels)? This method is more convenient
ice> really linear arrangement of pixels in memory and if so, then
ice> what?
Why is line linearity not achieved? Each line is 128 bytes in a row (and
not like AlCo). Pixels can be arranged in any way in a byte (IRGB.IRGB), everything
anyway, such a layout will require a complete redo of the spec =))
Advantages: move to the next 2 pixels - inc l, to the next line - inc
h.
Hello, SAM style
SAM> Memory is being consumed - that's okay, but what this circuit actually does
SAM> takes away the processor's precious time - it's a kicker. AlCo said that
SAM> the process is slowed down by a third.
but don’t tell me :mad: the fact that the percentage is gobbled up is of course bad, but there’s no memory
All that remains is, you'll be stuck cracking jars :confused:
SAM> PS [self-promotion]: if you are disappointed in this mode, switch to mine.
SAM> The same 16 colors per pixel, the processor is not slowed down, and the memory in general
SAM> external. (who would help me implement it in hardware)
Well, this is another matter, I also thought that it would be better if there was external (video) memory, but
shredding an already small part of 48k is perverted IMHO :sleep:
ps. so what’s the catch? Are there really no hardware aces here?
Hello, breeze
bre> well, this is another matter, I also thought that it would be better if there was an external one (video)
bre> memory, and shredding an already small part of 48k is a perversion IMHO: sleep:
My mode is in unreal0.32b5 (0.33 needs to be recompiled to have it), if there is one
I'd like to get acquainted - I'll send you the document and the program for the bmp converter. Bye hands
when they get there, I’m making a sprite editor for it.
> ps. so what’s the catch? Are there really no aces here
>hardware construction ?
The aces quickly cooled down. Although, if my memory is not frozen, CHRV seems to have said,
what will he think about its implementation in ATM3 if there is software.
Hello icebear
ice> Well, at address #4000-#407F there is line number 0, at address
ice> #4080-#40FF is line number 97 (according to your description). Then
ice> there is line number 1 and line number 98, etc. What kind of linearity is this?
ice> Compared to the AlCo proposal - yes, individual pixels are located
ice> "nearby".
ice>
Very linear, compare with the native mode.
> Until a certain point. What will happen if in HL we say #407F and
> will you make INC L? Where will you end up? I think so on a new line, only
> this is not the next one “on the list”.
What do you suggest, making lines of 128 bytes one after another? And how are you
will you move to the next line (code)? Only AlCo did worse...
=)
Hello, breeze
> why was it removed in 0.33?
Let's play around and that's enough. no one writes software anyway
Hello, lvd
lvd> Very linear, compare with the native mode.
Determining your linearity in the studio.
lvd> What do you suggest, making lines of 128 bytes one after another? And
lvd> how will you move to the next line (code)? It's only worse
lvd> AlCo turned out... =)
I'm not suggesting anything, I want to understand what type of linearity you found in
the proposed option. Moreover, you will have to check the output every time
line boundaries (LD HL,#407F; INC L). That this is better than AlCo's proposal I
I agreed from the very beginning.
Hello, lvd
lvd> Well, before discussing the structure of the screen, it would be good to yourself
lvd> represent how code is written for the default screen.
I don't discuss, I ask. Question marks don't tell you anything?
lvd> So - WHY check for line breaks?
No need, you're right :)
Hello, lvd
lvd> Here's more =)
Well, that means nonlinear :)
lvd> It’s immediately obvious that you’ve never written anything on spec.
The last time I wrote on Spectrum was 12 years ago :)
lvd> Let it be known to you that no one ever goes beyond line boundaries
lvd> checks! And if it does check, it doesn’t do it with addresses!
This was a simple example so as not to write a lot. How to understand the play on words "nobody"
doesn’t check... and if it does check...". So do they check or not? And what will happen
if you don’t check for line breaks in the mode you described (only about
this is the mode we are talking about).
Hello SMT
SMT> we played around, and that's enough. no one writes software anyway
hmm... :o a compelling argument, good! where can I get the version that supports it?
:confused:
Hello icebear
ice> Determining your linearity in the studio.
ice>
Here's more =)
> I'm not suggesting anything, I want to understand what type of linearity you found
> in the proposed version. Moreover, you will have to check every time
> line overrun (LD HL,#407F; INC L). What is better
> I agreed with AlCo's proposal from the very beginning.
It’s immediately obvious that you’ve never written anything on spec. Let it be known to you
that no one ever checks for line boundaries! And if he checks, then
doesn't do this with addresses!
On the spec, the main problem when rendering to the screen is the step to the next
line, and is executed with the following code:
┌─- code ───
inc h
ld a,h
and 7
ret z
ld a,l
add a,32
ld l,a
ret c
ld a,h
sub 8
ld h,a
ret
└── code ───
In the version I proposed, only inc h will remain, with a check for achievement
the middle of the screen, which will skip much less often. Well or not in the middle
screen, and a third (to check by masks).
PS: I’m done explaining obvious things...
Hello icebear
ice> The last time I wrote on Spectrum was 12 years ago :)
ice>
Well, before discussing the structure of the screen, it would be good to imagine
How to write the code for the default screen.
> This was a simple example so as not to write a lot. How to understand the game
> the words “no one checks... and if they do check...”. So they check or
> no? And what happens if you don’t check for line boundaries in
> the mode you described (only this mode is discussed).
So - WHY check for line breaks?
Hello SMT
SMT> well, or ask Uncle Sam from old stocks ;-)
Why from stocks? It's here on the forum:
http://zx.pk.ru/attachment.php?attachmentid=1852
> currently only works in filter=double, driver=ddraw/gdi
Hello, breeze
bre> good! and where then can I get the version that supports
compile by hand. well, or ask Uncle Sam from old stocks ;-)
Hello, SAM style
SAM> Why from stocks? It's here on the forum:
Well what can I say? looked! Interesting! Cool! HO! I would still like to
have a hard version, since the emulsion is of course good... but... :sleep:
Hello, breeze
bre> I would still like to have a hardware version, since it is an emul
bre> of course good... but...
I can explain all the logic of my circuit on my fingers - which signals go with what
AND-OR-XOR'it and what is needed for. Probably some kind of cooler hardware guy
me and will put it into his computer.
Hello, SAM style
SAM> I can explain all the logic of my circuit on my fingers - which signals go with what
SAM> AND-OR-XOR'it and why what is needed. Probably some kind of thread
SAM> Hardware guy is better than me and will put it in his computer.
hmmm :) but I would prefer to write in real rather than in emul :(
Hello, breeze
But if hardware engineers worked together with programmers, then it would be possible
get something worthwhile! Once upon a time I tried to come up with a graphics mode,
so that the z80 can REALLY master it. The screen was in 3color format - i.e. 6144-RED +
6144-GREEN + 6144-BLUE
Here's an example:
Outputting a byte using a mask to the standard screen
LD A,(DE)
INC DE
AND (HL)
LD A,(DE)
INC DE
OR(HL)
LD(HL),A
INC L
Output to 3color screen
LD A,(DE)
LD(HL),A*
LD A,(DE)
LD(HL),A*
LD A,(DE)
LD(HL),A*
LD A,(DE)
LD(HL),A*
INC E
INC L
And the point here is in the organization of video memory and video devices!!!!!!!!!!!!!!!!!!!
Video pages with a size of 16Kb are located instead of ROM (there are at least 6 of them in total - for
two screens):
RedPage0,GreenPage0,BluePage0
RedPage1,GreenPage1,BluePage1
In the above example, the so-called MaskReg is used, with which
is given
mask!
First, turn on the “additional control” bit in the control video port
z80 commands"
Initially, instead of memory, a mask register is connected at all addresses 0..16384
MaskReg
The video device switches pages after commands marked with an asterisk!
LD A,(DE) - from the same video memory (above 6144 KB) we take first
paged data
LD (HL), A * - Recorded in MaskReg, video controller logic worked,
switched to the RegPage0 page (or RedPage1 - depending on the current
screen 0 or 1 :-)LD A,(DE) - Counted part of the sprite from RegPage0
LD (HL), A * - Recorded in RegPage0, video controller logic worked,
switched to GreenPage0 page
LD A,(DE) and so on...
LD(HL),A*
LD A,(DE)
LD(HL),A*
INC E
INC L
In fact, when you receive only the simplest commands from the Z80, you need to
use them from the iron side in your own way.