(Some prospects for parallel forwarding)

Hello Lethargeek What is the conclusion from this? And such that sprites can now be stored directly in video memory, and display on any background at a speed comparable to the speed of a regular Spekovskaya graphics - and all this in 64 colors! Moreover, the mask can (should!) be stored in a regular RAM that will save space in video memory for the sprites themselves. Even if in APA mode all are used four base pages (two switchable background and two foreground), all equals in each page remains 6*4K, which, taking into account masks in regular RAM, will be equivalent 16-32K ordinary specov graphics. And even in non-displayable (cut off by the border) areas you can store something. Plus less important sprites/tiles can still be print from RAM in multiple passes. The procedure for outputting a “sprite” in APA mode will look something like this: out... ; (setting basic video memory read and write pages) out... ; (output via AND in all planes) ld hl,^mask ; in non-interceptable addresses ld de,^screen ; in video memory (base page for recording) push de CYCLE -ld a,e - call "ldi chain" - ld e,a - inc d REPEAT pop de ld hl,^sprite ; in video memory (base read page) out... ; (output via OR in all planes) CYCLE -ld a,e - call "ldi chain" - ld e,a - inc d REPEAT out... ; (restored basic pages if necessary)You can also try to cram it all into one cycle (with some hardware modifications), but I’m not sure that we will get a significant acceleration.

Hello Lethargeek Reflecting on the topic of implementing “internal” ldirs, I thought: what, in fact, is happening in different situations during such transfers? For example, ldi from RAM to video memory - byte first read from a regular RAM page, then written to the intercepted page - and simultaneously into video memory through a logical operation with latch registers. And on the contrary, for ldi from video memory to RAM, bytes are first read into the latches, then they are summed up some logical operation and the resulting byte is sent through the processor to RAM. And with “internal” ldi (that is, when accessing both addresses source/sink intercepted by the video card) what will happen? Both - bytes are read, are summed up, the received byte is sent by the processor to RAM - and at the same time back to video memory. That is, all layers get the same bytes, which is very bad. It's obvious that from the father only the destination and source addresses are required, and no data is needed - and if the byte data at records are ignored, then the contents will go to the destination address in the video memory latches, received before this when reading, that is, parallel transfer will occur, what are we and achieved! The question is, how do you know when to ignore data when recording and when not to? Not do same as a code analyzer on a video card that catches the necessary commands... ;) You can do it like this:if immediately after a read attempt there is a write attempt (that is, between them there wasn't fetching a new command - the M1 signal did not appear), then ignore it. And if after samples the recording starts immediately, then we definitely write what’s on the bus. It is clear that such ldi is only suitable for parallel copying of data to video memory, that is, primarily for “byte-by-byte” scrolling of the image. Now if only it were possible was to do such transfers taking into account logical operations! And to do this you just need to enter "second set" of registers-latches (that is, now we have separate ones for reading and for records) and parallelize the circuit for executing logical operations. And at the same time give an opportunity separately select base 16K video memory pages for reading and writing. That is, the record is happening like this: the byte received from the processor is distributed among the H-latches, simultaneously are filled data from the video memory of the Z-latch, logical operations are performed and the result from Z-latches written back to video memory. But when executing the “internal” ldi read from video memory bytes will first go to the H-latches and are summed up “to the output” (the result is given process) and remain in the H-latches. Now, when a write request arrives, H-latches bytes received via the bus are not filled, but logical operations with 3-latches filled from the write address and the actual write to video memory.Add to this the ability to record "with shift" and "mirror" recording, like earlier.