Video logic accelerator.

If we’re going to make an extended screen for the Spectrum, then why not put it in the ROM address space? This same 16 KB of blank screen and even with the release of the address space, which is quite decent! The arguments are as follows - the screen is rarely readable and you can get by without this, there is no need to write to the ROM, so you can separate reading and writing: reading from ROM and writing to screen at the same addresses. The video controller can read directly. There are no problems with compatibility, because the recording does not affect the reading in any way, and I don’t care what The ROM is slipped in, the main thing is that it is a ROM, and there is no need for banks click. > How to add one bit to a byte (draw a line)? For this >should it be read or not? And if necessary, a copy of this >bytes should be done somewhere else in advance? Maybe >make it possible in hardware to write not all bits into a byte for >saving those that do not need to be written (then it will become possible >set to remove one bit without reading)? How then to deal with >compatibility and performance? Think about it, I came to this conclusion - everything will be fine, if in order to put an end to it you don’t need anything read, which means a byte (or several) per point orplace only color attributes there. For 16Kb we have somewhere around 128*128 or 160*102 with 256 colors (just watch the video clips :-)). Or just attributes (byte per byte) for a resolution of 512*240 - we’ll just fit it in (15360). By and large, video memory is required only for records, if we consider it from the point of view of programs. Of course, we are talking only about quantitative assessment, and not about absolute statement, but nevertheless it may turn out to be useful. So an idea was given on how to use the benefits one-way reading, but.. - it does not take into account SPECIAL structure of the screen on the Spectrum, thanks to which, what would you should put a regular point, make a logical operation with a value in video memory, which is inconceivable without reading. However, the principles of working with the screen themselves do not change and if such logical operations could be carried out without reading, then everything would fit very well into the proposed idea. But the solution lies on the surface - after all, logical operations There are very few of them elementary and they are very easily implemented in gland, and the direct meaning of video memory cells programs are not needed, that is, you can make them switchable modes of operation with video memory that will implement logical operations with data copied there. It may significantly increase the speed of working with graphics bySpectrum and makes it possible to apply the main idea stated at the very beginning. Question for experienced programmers: how much faster? (approximately.. so - off the top of my head) would be working with video possessing such regimes? Or is the game not worth the candle? KIA

Hello, _/Ivan/_! 03 June 2005 11:43, Ivan Kuvshinov wrote to All: IK> If we are going to make an extended screen for the Spectrum, then IK> why not put it in the ROM address space? This IK> 16 KB of blank screen, and even with the address free IK> space, which is quite decent! I would agree to this if it was possible to switch the bank to reading, bit in any port. Or does this complicate the scheme too much? And it still needs to be good think about the screen format, or also switch through the same port, if several (video modes, so to speak). But in total with the standard screen we get 23296 bytes! But another thing is that it’s unlikely that anyone will get into the old Specs... That’s only if add to the scheme of those currently produced. PS: One more thing - what does the SET n,(HL) command do? _Read_, set bit, and recording, but all this at once and without the participation of registers? See you again! Best regards, Thann.

Hello, Aleksey...! 04 Jun 05 13:51, Aleksey Senilov -> Ivan Kuvshinov: AS> what does the SET n,(HL) command do? _Read_, set bit, AS> and recording, but all this at once and without the participation of registers? Sets the specified bit at address (HL) to 1. Does not affect flags. Other bits in the byte do not change. Performed in 15 bars. Command binary code: 11001011 11xxx110 xxx is the number of the bit to be set. With the best - Wlodek # wlblack(@)newmail.ru # http://wlodeks.narod.ru [ZX] [500:95/462@ZXNet] [2:5016 Forever] [Golyanovo] [Old Russians]

IK>> If we’re going to make an extended screen for the Spectrum, then IK>> why not put it in the ROM address space? This IK>> 16 KB of blank screen, and even with the address free IK>> space, which is quite decent! AS> I would agree to this if it was possible to switch banks AS> for reading, bit in some port. Or does this complicate the scheme too much? No question, it’s just that the ROM will not be available at this time, so that it can be used only in special cases. AS> But another thing is that hardly anyone will get into the old Specs... This is only AS> if we add those currently produced to the diagram. Well, that's what I'm saying - if you make an extended screen. :-) AS> PS: One more thing - what does the SET n,(HL) command do? _Reading_, installation AS> bit, and recording, but all this at once and without the participation of registers? I think you can’t do without reading, just “n” - hard, by the way, I used this command in my first program, only then I looked at it for the first time made machine commands and was inspired by a book about graphics self-modifying code that remade the command intovariable "n" by mask. :-))) Naturally it was all terribly loud and slow, but my game "Life" It worked, it’s probably still lying around on cassette tapes somewhere! KIA

WB> Sets the specified bit at address (HL) to 1. Does not affect flags. No - I meant “how”, not “what”... KIA

Hello, _/Wladimir/_! 05 June 2005 09:39, Wladimir Bulchukey wrote to Aleksey Senilov: AS>> what does the SET n,(HL) command do? _Read_, set bit, AS>> and recording, but all this at once and without the participation of registers? WB> Sets the specified bit at address (HL) to 1. Does not affect flags. WB> Other bits in the byte do not change. Performed in 15 bars. Thank you, I know all this myself. :) I asked a little wrong... See you again! Best regards, Thann.

Hello, _/Ivan/_! 05 June 2005 16:29, Ivan Kuvshinov wrote to Aleksey Senilov: AS>> I would agree to this if it was possible to switch AS>> bank for reading, bit in some port. Or is it too much AS>> complicates the circuit? IK> No question, it’s just that the ROM will not be available at this time, so IK> that this can be used only in special cases. Naturally. And why do you need a ROM when working with such a screen? In ROM it is still only work with standard screen at #4000. Or does it mean that the ROM is different, working with an extended screen? In text mode, screen reading is not possible. you need... But for the same PLOT and DRAW in extended you can’t do without reading... AS>> But another thing is that hardly anyone will get into the old Specs... This AS>> only if you add those currently produced to the scheme. IK> Well, that’s what I’m saying - if you make an extended screen. :-) So then it needs support, preferably at the OS level. But this impossible... No abstraction of video memory is possible on Spec IMHO. Or am I not right? See you again! Best regards, Thann.

Hello, Ivan! Fri, 03 Jun 05 at 11:43, Ivan Kuvshinov -> All: IK> If we are going to make an extended screen for the Spectrum, then IK> why not put it in the ROM address space? This IK> 16 KB of blank screen, and even with the address free IK> space, which is quite decent! This has already been done. We stuck an EGA video card into SMUC and soldered a couple of microchips on signals MEMWR and MEMRD of the slot, resulting in writing to the ROM area led to recording in the video memory. Memory in EGA video card with 16 kb pages, they are leafed through the ports. And everything worked. I don’t remember who exactly did it, years ago it was five ago. WBR, Jason. _/(ZX)/_ /*e-mail: jason2000(not a cat)yandex.ru ICQ: 62235830*/ /np:/ *silence*