HGFX Intro, part 6 Let's conclude beginner lessons about the HGFX. For the skilled part of the ZX community they were unconventional and lengthy as it went by a tortuous method from general to difficult. Now we end with two things in terms of HGFX very substantial that you will usually find in a technical documentation at leading places. Write and read methods can be very creative in the ZX-planar. We already understand how to clear an entire byte or change only pixels whose value is set to 1. Now let us look at something more complicated: how to keep loaded content in an internal buffer in order to return it later, to another location. For this, we have different modes and working methods. HGFX operating mode - Ink Mode Previous descriptions considered this mode. Ink Mode means: where a logical one is in the written value, the bit from selected index colour will be written to the active videobuffer. Where there are logical zeros, there is nothing to change. HGFX operating mode - Copy Mode Copy Mode, more complicated than Ink Mode, can operate via two methods: The first method is write-only. Where a bit 1 is written (set) to the video memory, the pixel is coloured as in the Ink Mode. Where is 0, everything is reset to zero. In other words, a writing puts (in combination with the PlanarMask) the colour with the index-number 0 to places where no colour is written. The second method occurs automatically whenever a reading from videoram was previously done. In this case, a writing will handle a content which was used in the last reading. Watch out: The "read" value must match the subsequently written value. If both values do not match, only the first writing method of the Copy Mode is performed. The following applies in the Copy Mode: 1. If a reading from videoram precedes a writing and "write" and "read" values are the same, colours are copied in the full range of 8 pixels. 2. If the value is read from the videoram first, the subject of a next "write" operation will be the content of the previous videoram "read" position. It doesn't matter if 0 or 1 are written, 8 pixels are copied. An example of the simplicity of this seemingly complex Copy Mode is a screen scrolling, as we know it from ZX Spectrum BASIC editor. When the ROM scrolls up, it reads a byte from the videoram - now, watch out, this is where the Copy Mode switches to the second method! - and writes it by 8 pixels higher. And round and round, if we comply with a read/write order. Offsets are also applicable in the Copy mode, readings and writings have their own custom offsets. Each write or read operation can be done at another place, even from another buffer. It is possible to set from which and to which LowRes buffer we want to copy (note: in the case of HiRes, 512*192 resolution, we only have one buffer). Chunky graphics -------------- We can think of chunks as a format (arrangement) of data or as a display mode. It's a megablock of memory, arranged so that each pixel can be coloured with one of 256 colours and occupies the entire one byte. Chunky brings a problem of a huge video memory of 48 KB (by a resolution of 256*192 pixels). Older, Z80-type processor, without specialized DMAs or other logic chips has a lot of work to do in order to smoothly execute something in such a memory, e.g. scrolling spends all its machine time for byte transfers. 256 coloured pixel chunky graphics 256*192 = 49152 pixels (48 KBytes) 1st 2nd 3rd 49152. pixel pixel pixel pixel |--------|--------|--------|... ... ...|-------| byte 0 byte 1 byte 2 byte 49151 HGFX can expose its graphics data in addition to planar graphics also in this chunky format. Honestly: internal HGFX buffers are managed in chunky format and we can access them via planar or via chunky mode. The planar is undoubtedly suitable for more modest computers (especially in eight-bit proportions), chunky graphics for more powerful hardware. Due to different accesses to video memory, some chunky effects are difficult to implement in planar (and vice versa). In the HGFX, chunks can help with one basic thing, namely with a direct reading from buffers (that is not possible in planar). In the Ultimate memory mode (of the eLeMeNt ZX/MB hardware) we can view chunky areas through 8 KB or 16 KB windows. However, chunky memory is not paged! Fast eight-bit paging the registers of eLeMeNts or MB03s have no meaning for HGFX. We have to manage it in a special way: We have to set the offset Y for the beginning of the area we want to make available. For example, it is possible to have pixel data from line 120 at address 0. Example of printing in Chunky mode: drawing a pixel at coordinates 128,96 in colour 158 RAM chunks set to eight KB space from 8192 to 16383 OffsetY = 96 POKE 8192+128,158 To make the chunky mode more usable, the system respects some HGFX planar settings. In addition to offsets, we will use the PlanarMask and HGFX adjustment bits of the register No. 0 (video parameters). The PlanarMask behaves, surprisingly, just like in planar :-) when you write a byte, it is processed through the PlanarMask, so even in the case of a chunky memory, only active bits are overwritten, other data (in place of zeros in PlanarMask) does not change, they will retain previous values. Simply put: in planar, the bits are stacked on top of each other, in chunks they are lying next each other, but the mask always does the same when writing to the memory. However, the difference is there anyway, in favor of the planar: By writing one byte, in the planar we serve 8 (whole "chunky") pixels at the same time, but only one pixel in the chunky mode. Another good thing that will make our work with the chunky graphics easier is an option to switch buffers and set different buffers for different ones operation. We can thus read and write from different buffers without any additional switchings. Final part? The basic series about HGFX ends. The next and last one will be about HAM, FILL, SuperHires modes. I wish you a lot of fun whether you run the HGFX on real machines like eLeMeNt ZX (and the MB03+ Ultimate in the future) or you test the HGFX on the LnxSpectrum (which has a lot of support for the HGFX programming, eg it can import graphics into the HGFX bitplane format). Thanks go to: Lanex, LMN128 and Hood, for a big help with this series. And also for the brotherhood, thanks to whom we could tune the ZX Spectrum for the 21st century. At the same time, it was possible to merge different approaches (clones, peripherals), western and eastern spectrist styles: do not exclude proven old things and combine more new and good things. You can find an overview of all developments of the past few years at www.128land.com I also thank everyone who contributed with their hands and heads, for their support, they simply gave the new hardware of the eLeMeNt ZX/MB family a chance: pvym, Zoom, Busy, lordcoxis, nihirash, NEO SPECTRUMAN, Tchunass, Velesoft, Martin8bity, dakidski and others + applause goes to the esxDOS community, without them our attempt wouldn't be successful!