A difficult video extension for Speck

Hello, All Without much preamble: here is a brief specification of the Sprites&Shifts mode. 1. Main screen (from offset 0 on page RAM5 or from offset 0 on page RAM7 - as usual) is used as a background and can be moved with accurate to 1 pixel at 0..255 bits horizontally and 0..191 bits horizontally verticals. 2. The additional "screen" area at offset 0 on page RAM1 contains 32x24 = 768 = 300h bytes. If the byte is 0, then the corresponding familiarity in mostly does not contain a sprite (but may contain a partial continuation of what was started to the left or above the sprite), and draws in its free area (correctly shifted along the cycle) main screen. If this is sprite number n=1..255, then offset 300h + n * 8 is an 8-byte description of the sprite: cm length value _0_ _2_ d0..d13 - offset (in the same memory block) to the bit image sprite (followed immediately by the sprite mask), 2 most significant bits d14..d15 are not used. For example: if the sprite size is 3 bytes x 11 pixels, then First there are 33 bytes of the image, then 33 bytes of the mask. _2_ _1_ sprite width in bytes d0..d4 (maximum 32 bytes). _3_ _1_ sprite height in pixels d0..d7 (maximum 192 pixel lines). _4_ _1_ sprite attribute (as usual, d0..d2 - color of bit "1", d3..d5 - color of bit "0", d7 - blinking, d6 - brightness. _5_ _1_ sprite offset in bits: d0..d5 - horizontally (to the right) by 0..63pixel; d6 - shift not to the right, but to the left; d7 - invert the sprite horizontally (i.e. it is depicted as mirrored horizontally). _6_ _1_ sprite offset in bits: d0..d5 - vertical (down) by 0..63 pixel lines; d6 - shift up, not down; d7 - inversion of sprite by vertical (i.e. it is depicted upside down if d7=1). _7_ _1_ priority (or Z-order) of the sprite 0..255. If there are several sprites intersect at any point, then the sprite with the larger priority. Option2: this byte is not used, but as a priority The sprite number is used. Option3: You can use this byte as alpha channel, for fans. Option 4 (it’s best to leave it): d0..d1 - number of output limitation area 1..3, see descriptions of areas in paragraph 3. An important point: sprite shifts are not cyclic, i.e. if as a result of a shift the sprite goes beyond the left/right or top/bottom border of the screen, it does not appears on the opposite side of the screen. To model this behavior, you need to place the same sprite on the opposite side of the screen, by setting the appropriate shift in the desired direction. But it's still faster than draw a picture yourself. 3. The first sprite starts at offset 308h in RAM1. Two bytes in the same memory block at addresses 300h and 301h are set respectivelyvertical and horizontal (cyclic) displacements of the main screen. Region sprite display can be set by byte 7 in the sprite description (1..3). Area descriptors are located at addresses 302h..307h (2 bytes per area) in form: d0..d4 = x0 (0..31 bytes) d5..d7 = w (1..7, 0=8 1 byte) d8..d12 = y0 (0..23 familiar places) d13..d15 = h (1..7 + 1 acquaintance) That is you can define up to 3 (possibly intersecting) rectangular areas - output windows, and assign each sprite on the screen to its own area. Those parts sprites that fall outside their area are automatically clipped to their boundaries acquaintance If all 255 sprites are used, the descriptions end at offset AFF, and from offset B00h to 3FFFh the rest of the memory block can be occupied by themselves images and sprite masks. 4. Control (port). Register 14 of the FFFD port controls the activation of the mode: you need to write 81h into it, for the mode to turn on, and 80h for it to turn off. If you wish, you can use any port, the main control still goes through memory.

Hello, Vladimir Kladov continuation: 5. Algorithm for operating a video decoder in S&S mode. - the main video memory scanning unit works almost as usual. The main thing here it is taking into account the cyclic shift. The result of this block can be any moment is covered by the result of the sprite scanner (with an accuracy of pixel). - sprite scanning block. When the beam reaches the next familiar place, the corresponding byte in the sprite matrix is checked. If the sprite takes place, it will be drawn on top of the main ray, completely with its combination front and back color attribute, taking into account its vertical and horizontal shift, your mask. And taking into account the overlay of several sprites. If there are difficulties in implementing the equipment or algorithm that generates the video beam is completely “on the fly”, this can be circumvented by generating an image in the buffer in mode 256x192x (16 colors per pixel), and displaying it on the screen. (In the emulator, by at least that's the best way to do it). A sprite scanner may even have its copy of the sprite memory, which it fills as it appears on the bus data intended for writing to RAM1. 6. Advantages of this approach: - no attribute clashing; - very easy control from the program up to 255 moving 2-color objects up to 256x192 pixels in size, on a moving 2-color background; manycontrol options: you can change the sprite image (where it points pointer) or a pointer to a sprite in its descriptor (if all options prepared in advance), or change the sprite number in the sprite scanning matrix, if the sprite numbers are enough to allocate a certain amount descriptors for several frames of movement of the same character; - if desired, the color of the sprite can be easily increased by setting several adjacent positions of several sprites (for example, the color of a hat/pants/mittens may differ from the colors of the hero's jacket, but you will need to specify separate sprites); - high graphics speed. Most of the time the processor is free for execution of the program: you can work on the logic of the game, sounds... a lot of drawing takes no time. For example, to move a sprite 1 pixel X to the right, if it is offset by 7 in X: set the offset to 0, and in the matrix place its number in adjacent byte, and write 0 to the byte where it was before. But if the adjacent Since a byte in the matrix is occupied, you can simply increase the offset so that it becomes 8. To shift the entire background by n pixels, you just need to increase or decrease by n bytes with offset 300h or 308h. 7. Disadvantages of this approach: - no compatibility with the previous mode (i.e. there will be no remake of games trivial). Is it necessary? We've already seen enough...- a very complex scanning algorithm, it’s generally difficult to come up with “on the fly” acceptable algorithm. But you can work through a buffer. - less useful for vector graphics. But at least it's free move the background without the slightest clashing, but rather small vector objects without clashing (with their own colors) move across the screen as as you please, considering them sprites (just change the contents of the sprite for performing their rotations, scaling, etc.) But if such a mode was in the Spectrum... I would also create something for it myself done.

Hello, Vladimir Kladov Vla> But if such a mode was in the Spectrum... I would still use it myself Vla> did something. I also propose to implement support for 32-bit mode in the Z80 compatible with i386 and Win32 API right away, and in hardware. In the meantime hardware people I think this can all be implemented in the emulator and written a lot of software.

Hello fk0 in hardware - yes. Zhelezyachnikov - few. And everyone is busy with their own affairs. What, in the dock? it says that v9990 has sprites? Prots can't handle anything big is in the Spectrum, Clive was right when he designed only the mode that is in the basic one. The only thing that can beat the brakes is sprites.

Hello fk0 fk0> I also propose to implement support for 32-bit mode in the Z80 fk0> compatible with i386 and Win32 API right away, and in hardware. In the meantime fk0> hardware people I think all this can be implemented in the emulator and written fk0> a lot of software. Kirill is on fire as usual! I’ll probably send everyone to read the v9990 doc. Apparently this is the only thing that will be realized!

Hello jdigreze Perhaps the highly specific task of moving sprites can be solved by a smart DMA? There will be more opportunities and applications. It seems there was a DMA Sound Card project, at what speed did it throw memory? A Can the z80 transfer anything there in parallel?

Hello, Vladimir Kladov It doesn’t have to be sprite, but vector can also be used... Give it to the peripheral processor coordinates of two points, and he draws a straight line between them on a standard screen. I I think it would be very cool for Elite style games ;) And not necessarily to make a polygonal model, just quickly drawing points would be enough and straight. To implement this controller, you really need to make it all-wheel drive capture of address and data buses (BREQ, BUSAK). But the processor can be used at least AVR...

Hello fan Here you go! Only the last time I proposed something similar to previous ideas V.Kladova with "hardware EmuZWin"? how he offers something reminiscent of my previous ideas (I apologize in advance for getting in here with references to my topic, someone might boring). I mean that the background is again 2 colors per place, and the multi-color sprites only simulated (something similar on the chest of drawers was with hi-res sprites). And you need a computer climb, because The main RAM is in use. Even I have already given up on both pressure public. :D Well, people need the “each point in its own color” mode, even though you crack! I had to adapt my idea to this without losing what I needed. Vladimir Kladov> no compatibility with the previous mode (i.e. remake of games ` will not be trivial). Is it necessary? We've already seen enough... ` But if such a mode was in the Spectrum... I would also create something for it myself done. Have you seen enough for several thousand (okay, even hundreds of the best ones)? :v2_eek: And how many more cannot be considered good precisely because of careless graphics... And here there is no need for rework, and the new software will most likely be created by V. Kladov himself? I partially agree with CHRV that if we do something incompatible, then better take a ready-made video chip - the experiment will cost less. Although there's no point either little it will be, in my opinion.Vladimir Kladov> The percent cannot cope with something larger that is in the Spectrum, Clive was ` is right when he designed only the mode that is in the basic one. The only thing what ` can beat the brakes - these are sprites. And Clive said that the reason for the Spectrum's success is its easy access to memory. Again look at my latest specifications - the layout is even simpler than in the original, and speed comes close to 32 clock cycles per byte for sprites with a mask (respectively, 16 clock cycles per byte for simple tiles). And this byte is eight pixels, and from the depth colors (number of video memory lines) speed is completely independent. Including for vector graphics. In general, everything is almost the same as in EmuZWin - the speed is the same as in ordinary mode (if not faster in my case). All you need to do is store graphics in non-displayable areas video memory and transfer them with the ldi command (from which, in fact, you are required only source and destination addresses). You can also add “video processor” - no important will it be a z80, as in the GS, or even a simple internal transfer scheme to logic (then it is possible to copy faster than with ldi), or something more sophisticated type primitive blitter - also for vector graphics. Generally separate video processor (namely, drawing in video memory, and not forming an image on the fly) - a thing moremore promising than sprites. The experience of computer technology development is convincing showed that hardware sprites are a dead end. Yes, and the brakes in Spec's games were greater parts are related specifically to slow scrolling “manually”, and not to rendering sprites. What’s interesting about sprites is this: is it possible in principle to synchronize ready video chip with a homemade video controller, so that you can mix images - for example, some color in the video memory of the chip is considered transparent, we make it the background, and then sprites are superimposed on the spec screen - again, by choosing one of two pixels along the beam. And if not the entire background in the chip’s memory is transparent, then we’ll get another one the “foremost” plane (or how many layers it has). But this is probably difficult do it because all such video chips immediately output a ready-made video signal - or I Am I wrong? (Failed to download datasheets :( )

Hello madcore Yes, V9990 has sprites. I never found a normal description (but still after all, it will depend on the pairing method, right?) but there is a brief mention. I I came to the conclusion that it seems like sprites can somehow be loaded into V9990 memory (and it has as much as 512K of it), and give the command in the required mode transferring sprites.

Hello, lvd mad> It seems there was a DMA Sound Card project, at what speed is it memory-memory mad> did you throw? Can the z80 transfer anything there in parallel? wcg.fatal.ru - dma_docs.zip

Hello, Vladimir Kladov Vla> Without much preamble: here is a brief specification of the mode Vla> Sprites&Shifts. Vla> [skip] Vla> Well done, you invented a pathetic semblance of Komodura 64. =)

Hello, CHRV CHR> Kirill is on fire as usual! CHR> He's not on fire, he's on fire =) > I’ll probably send everyone to read the v9990 doc. Apparently this > the only thing that will be implemented! let's send it! -)

Hello Costa There was familiarity-based mixing, not pixel-by-pixel mixing, and that’s exactly what it meant the specov screen could be considered a "foreground", which is useless for using video chip sprites. And even if it is self-sufficient, this means that the software needs to be completely new, there is no flexibility. I am in favor of allowing the coder to decide for himself what percentage of possibilities bloat is used rather than "all or nothing".

Hello Lethargeek Let> so as to mix images - for example Let> some color in the chip's video memory is considered transparent, let's make it Let> background, and then Let> we overlay the sprites on the spec screen - again, by selecting one of Let> two pixels Let> along the ray. And if in the chip’s memory not the entire background is transparent, then we get Let> one more Let> the “foremost” plan (or how many layers it has). Something similar with the combination of a spec screen with a video processor from Dandy in Veremeenko suggested at one time. See ZX-Review. But IMHO it’s not only difficult to do but it’s simply not necessary since the video processor is very self-sufficient. Just when the program will use it, it will automatically switch the output image on it but during operation nothing prevents the video chip from building an image on the Spekov screen as well as vice versa.

Hello Lethargeek Let> And even if it is self-sufficient, it means that software is needed Let> is completely new, no flexibility. I am for the coder to decide for himself Let> what percentage of bloat capabilities are used, not "all or Let> nothing." So, in any case, the software turns out to be new so if there is no video chip, then the program will still work defectively because you simply won’t see what is displayed there. It makes more sense then to make 2 versions for a simple screen and for a video processor.

Hello Lethargeek It's just that you don't know. There is no more software on the spec than on other machines, it even less, if you don’t count utilities specific to Spec’s platforms. Games - everything is on all other platforms, and all the same, and even more (and many appeared for the first time without any spec), and the graphics and music in them are better than decent platforms. More, for example, games with frame scrolling, on a pit or atari. Because hardware scrolling, sprites and no flash. Study - why? there to study something. Spec also had to be studied, just tricky addressing What is video memory worth? When remaking branded games for their spec programmers sometimes I had to work hard due to clashing, laggy graphics, small memory capacity. It would have been easier to do it first on something more decent, and only then they looked at the spec simply because of its mass popularity due to its cheapness (so it would and they didn’t look at all, but the thirst for profit, that’s it).

Hello, Vladimir Kladov Vla> And in our union, the success of a spec was also determined by the fact that it existed Vla> is simple and easy to "copy". Just look at Vla> MSX specification - how many devices, ports, memory there are, it’s fig Vla> you'll rip it off. That's why there was such an MSX (supposedly popular in the CIS Vla> in those years - nonsense!) I only found out recently. It simply didn’t exist Vla> did not exist in our market. And its graphics are much cooler Vla> than the spec, if it were available, I would of course make it unambiguous Vla> choice, even if it were 10 times more expensive. Well, for example, look at the specification of Turbo2+ or Scorpien with Smuk, then MSK probably even resting :). The Ministry of Agriculture was and was called KUVT Yamaha. It was established in the form of classrooms throughout the country. So I don’t agree about its non-existence. There are actually only a few devices: - same sound processor - separate memory manager (in the form of a chip) - disk drive (and not on all models) - video chip (perhaps the main difference).

*Hello, Alexander!* Catch my ideas about the subject "Difficult video extension for Speck", oh which your footcloth to comrade cracked on 30 Nov 2005. All. Let>> we overlay the sprites on the spec screen - again, by choice Let>> one of two pixels along the ray. And if there is no chip memory Let>> the entire background is transparent, then we get another “foremost” plan Let>> (or how many layers it has). AY> Something similar with combining a speck screen with a video processor AY> from Dandy at one time suggested Veremeenko.cm ZX-Review. Please don’t mention this name in the presence of spectromists! He's in his time in one magazine ("Radio Amateur", it seems) urged everyone to sell Speck (namely - sell!) and go to hell. (Goat face!) ;E As far as I remember, such operations with the computer had to be checked (essentially things - it turned out to be a hybrid of Speck and Dandy, with all the consequences - such as intelligence, frequencies, etc.), that it would be easier to just buy a device. And what else is there for? salt was reduced - everything was controlled through attributes. We need, for example, to some familiar place showed a dandy screen, set bit 7 of this to 1 acquaintances. It seems like (I haven’t read reviews for a long time, and I’ve only had enough of them read it, but didn’t give it away...)/That’s all, Alexander, you can scroll further.../

Hello, CHRV Vladimir Kladov> it’s just that you don’t know. There is no more software on the spec than on on other machines, there is even less of it, if you don’t count utilities specific to specov platforms. The games - all of them - are available on all other platforms, and they're all the same. and even more... We go to WoS, then to Komodur, Atarivo, Amstrad, etc. sites and we count. Moreover, we must take into account that on WoS there are text adventure games, porn and BASIC ones are kept separately, while others usually have everything in one pile. IMHO, only the chest of drawers comes close to Spec in terms of the number of toys, especially minus outright screw up.

Hello, All Vladimir Kladov> the answer is simple - Varez! Amstard gave away all distribution rights Roma and other things for the purpose of spec emulation, the rule applies to companies: if the company has not banned the distribution of the game, the game is distributed for free. Neither atari nor Amiga, and no other platform gave such permissions to anyone. So from There’s a lot of everything there and you won’t see it, and never. Bourgeoisie. Yes, everything there has been gone through for a long time. There are legal sites where games are not even are just descriptions. And there are also links to a bunch of ftp (regularly changing place of residence), where all the software is located. Moreover, interestingly, for Atari there is a lot images of uncracked disks, and for the chest of drawers, 99% of everything is pirated, like domestic releases on V-TRDos. And with permissions there are such problems as there No one is really sure what can be distributed and what cannot. In the end, one can judge by the number of those very “legal” descriptions, and there are simply lists that include all the famous game titles, as per platforms and by company. The (un)official websites of companies are also interesting look at Code Masters, for example, and see how much they did for Speck, and how much for other computers. They steal everywhere.

Hello Lethargeek A lame question for the hardware people - is it possible to theoretically implement adjustable pixel-by-pixel offset for familiarity coordinates? IMHO, that solved it would solve the problem of smooth color scrolling once and for all.