(as of 31-10-2005)

Hello Lethargeek SMT> you can close your eyes to the clashing between sprites, it’s still smaller than SMT> was ' in regular games with colored backgrounds. or make sprites one color. what about printing, 'I'm afraid there won't be any acceleration. If you draw sprites, then draw everything all over again ideology ' (on separate sprite and valve screens). since the output can be duplicated it was ' save only on the fact that the output comes without reading from the screen (for addition with mask). ' but this won’t work if you suddenly need to draw 2 sprites in one place. then it is necessary ' on the sprite screen prepare common pixels in familiarity, and on the gate screen - fold ' masks by OR. that is, deceleration instead of acceleration. needs to be reconsidered specifications Well look. This is what is often found in toys for displaying a sprite on filled with background (including other sprites) (to make the example less cumbersome, CYCLE means "loop through the entire sprite", changing the screen address in bc as per horizontal, and vertically): ld bc,^screen ld hl,^mask ld de,^sprite CYCLE - ld a,[bc] - and a,[hl] -ex de,hl - or a,[hl] -ex de,hl - ld [bc],a - inc de, hl - (change bc) REPEAT And for SCF-mode it will be: out... ; (output via AND to gate and sprite screens) ld bc,^screen ld hl,^mask CYCLE -ld a,[hl] - ld [bc],a ; equivalent to "and [gate],a" + "and [sprites],a"-inc hl; that is, they printed a mask and at the same time erased the pieces of sprites that came across - (change bc) REPEAT out... ; (output via OR to sprite screen) ld bc,^screen ld de,^sprite CYCLE - ld a,[de] - ld [bc],a ; equivalent to "or [sprites],a" -inc de - (change bc) REPEAT For single-color sprites, only the first loop is needed, since the mask and sprite match (only the PAPER color of the sprite screen is used, not INK). For two-color colors, at first glance, SCF-mode is somewhat slower (if in the original sprite and the mask were printed in one pass). HO! We forgot one little thing, namely: memorization and background restoration. That is, for a standard screen you must first erase old sprites (and not just “erase”, but fill with a picture), then remember the background in new place and after that display the sprite there. And in SCF sprites are simply “erased” and there is no need to remember the background. That is, the entire "work cycle" in SCF is performed faster. In fact, in toys it is rare that a piece of the background is clearly remembered (unless sprites small), most often everything is drawn in the buffer and then transferred to the screen, even in 128's versions. In SCF-mode you don’t need to transfer anything from the buffer, just switch couples sprite and gate screens separate from the background (and background screens separately, if background animated or scrolling) - and the old screen buffer can be used for newprocedures. And if the second screen of the 128 was used somewhere, it doesn’t matter - everything Likewise, on the inactive screen, everything was actually drawn anew. In addition, there is a way to simply display sprites in SCF-mode faster, true, To do this, you need to change the format of their storage in memory to “vertical”, that is similar to the native “vertical” screen layout without address recalculation (easy write a special utility to transpose sprites). (Again simplified): out... ; (temporarily disabled automatic address recalculation) out... ; (output via AND to gate and sprite screens) ld de,^screen call "address conversion to native format" ; quickly, with a table ld bc,de ld hl,^mask CYCLE -ld a,e - call "ldi chain" - ld e,a - inc d REPEAT ld de,bc ld hl,^sprite out... ; (output via OR to sprite screen) CYCLE -ld a,e - call "ldi chain" - ld e,a - inc d REPEAT out... ; (turned on automatic address recalculation back) It is clear that there may be nuances, and all this can be done a little differently, but is the idea clear? ldi chains can be any size up to 256 with ret at the end, and call addressed to arbitrary place in the chain. For direct addressing of the video card this is the best way output graphs in both modes - SCF and APA (just vertically in the “middle” piece screen there are much more bytes than horizontally). I’m still silent about the perverted options with a stack... ;)Note: do not confuse ldi from computer RAM to displayed video memory with ldi exclusively inside the video memory itself! (Issues related to this are still being clarified.)

Hello Lethargeek madcore> Will it be possible to copy points through latched registers? In contrast madcore> from EGA, ' I want logical operations (including shift) to work in this mode Already loaded a person with a similar question - so that at least all sorts of ldirs inside video memory worked in parallel for all allowed planes. And about the rest - why "including" shift? On the z80 there seem to be no commands like "xor [hl],reg", only single "rlc/rrc/rl/rr/sla/sra/sli/srl/bit/set/res [hl]" - almost all of which are shifts. :) For most, parallel work (at least partially) is meaningless. Okay still set/res, but by the command "rr [hl]" into video memory with several enabled planes that should it get into the carry flag? For such commands (and there are also rrd/rld!) need to study sequence of bus states, then it will become clear what is possible. Okay else if they it will be possible to force it to work with one selected plane, but if not, no matter what, it's not fatal (in APA graphics we can get by, but when adapting to SCF-mode there is a copy of the screen in RAM). It is much more important to make the byte writing mode “shifted” into two “neighboring” (on screen) addresses (and also taking into account OR/AND/XOR), even with an extra write cycle (otherwise in APA memory you won’t get enough of the pre-calculated horizontal shear phases of multilayer sprites).And then let the rest be buggy as it wants. ;) madcore> They are prohibited for this reason, so that there is nothing in them madcore> was written. ' And it is necessary that all bit planes are installed in accordance with the selected color. Why an extra register if there is a bit list of allowed and forbidden planes actually and there is color. I was thinking - well, you can enter a special recording mode, even with variations OR/AND/XOR (that is, OR simply prints the color, AND only leaves this color in pixels that coincide with the units in the byte (the rest are black), by XOR all matching - in black, and paint those that do not match in this color). Well, or something like that. Question in how complicated this will make the scheme. Maybe it’s not worth it to fence the garden, especially considering that the same thing can be achieved in the usual way in two passes (albeit slower). madcore> It’s too early to talk about the number of modes. ' EGA, of course, is not worth copying one-to-one. Two (maybe three) modes are planned, and in one resolution (color depth just different). Because, firstly, the TV, secondly, addressing, and third - again, the complexity of the circuit. Of course, I'm not an electronics engineer, but the main idea is is that in order to use the maximum number of parts in all modes, and according to opportunitiesin the same way. And not create a monster that has a lot of inactive time (in given moment) bells and whistles hang like dead weight. madcore> I suggested using the attribute area to select a palette for madcore> familiar places... ' ... We cut down color only when emulating (by adjusting the palette) background plans. ' But we can have as many of these plans as we want, and of any depth of color, as long as planes ' was enough. And if we don’t need it, we use all the planes for one full color screen, ' and no extra background screens will be hanging as a dead weight. In my version new ' the expansion is not something foreign to the spec, caught somewhere on the side. ZX screen ' is a special case of the new regime, i.e. no separate modes for compatibility ' no. Perhaps my explanations are somewhat confusing and chaotic, I’ll try later issue ' my idea more consistently... Just try, otherwise the impression is completely delusional. What does "plans" mean? you can have as many as we want, and any depth of color, as long as there are enough planes"? Depth colors are the number of bits per dot, and not the total size of the palette! There are layers here distribute, anyway, the end result is a reduction in color. And what are “extra” background screens? I, by the way, I'm thinking about combining two 64-color screens into one 4096-color screen, and this is the solutionLogically sound and won’t require a bunch of new hardware in my scheme. True, and are suitable Such “full-color screens without background” are only for viewing pictures. And ZX screen, by the way, is a special case of SCF-mode, it is not so “separate”. You’d better write something like how I explained the idea of a valve screen: what is recorded in each plane, and what we will see on the screen as a result. And about everything else - about the screen layout, about the resolution, and the device layout approximate though at the level of functional nodes, and how they (nodes) work in different modes/conditions.

Hello SMT Vladimir Kladov> markers are sold in stationery stores :) By the way, it’s more convenient to use a pen paper ' mark. There is also a notepad, it’s also a good thing... Yeah, you can still use Notepad... Jokes aside, we're talking about the fact that in Sprite Finder not visible overall picture, you have to keep adjusting the width all the time. Otherwise I would have found it once sprite - and then you can always see him. Vladimir Kladov> You have to scroll through the pause (however). And if you need to see how the program mocks its sprites in RAM? This is not This is such a rare occurrence (you’ll try to catch such moments by pausing). Or shadow video buffer can be tracked. In general, it would be nice to make Sprite Finder dynamic (if specific PC will pull). Regarding the off-topic (well, not really, but there is still some relation), just to the word had to but there was no time to go looking for another topic... I won’t do any more (others). :)