Friday, July 26, 2013

Selecting screen modes, data decoding methods and palettes

ZX Prism lets you select from a number of different screen data decoding methods. Like the ZX Spectrum, many of these modes use an 'attribute' byte to define the ink and paper colours in each 8x8 square. Like the Timex range of Spectrum compatibles, these modes also support 8x1 attributes. Unlike either range of machines, ZX Prism lets you choose how the attributes are decoded into a logical colour number, and then how that logical colour is translated into the colour which displayed on screen.

Screen resolution and 8x8/8x1 attribute selection is made using 4bit register 0010.
Not all resolutions or features are available for all screen data decode methods. Where a resolution is not available, Prism reverts to 256x192, 8x8 attributes and non-gigascreen*.

OUT 8E3B, 0010xxxx  Screen resolution selection where xxxx is:
     0000 – 256x192 8x8 attributes
     0001 – 512x192 (vertically halved display) 8x8 attributes
     0010 – 256x384 (horizontally halved display) 8x8 attributes
     0011 – 512x384 (quartered display) 8x8 attributes
     0100 – 256x192 8x1 attributes (“hicolour”)
     0101 – 512x192 (vertically halved display) 8x1 attributes
     0110 – 256x384 (horizontally halved display) 8x1 attributes
     0111 – 512x384 (quartered display) 8x1 attributes
     1000 – 256x192 Hardware GIGASCREEN 8x8 attributes *
     1001 – 512x192 Hardware GIGASCREEN 8x8 attributes *
     1010 – reserved
     1011 – reserved
     1100 – 256x192 Hardware GIGASCREEN 8x1 attributes *
     1101 – reserved
     1110 – reserved
     1111 – reserved

*Hardware gigascreen is an experimental feature which on even frames interlaces the even lines of screen 0 with odd lines of screen 1 and on odd frames interlaces the odd lines of screen 0 with even lines of screen 1.

Screen data decoding method selection is made using 4bit register 0011:

OUT 8E3B, 0100xxxx  ZX Prism palette selection where xxxx is:
     0000 – DEFAULT
          ATTR: D0-D2 ink, D3-D5, paper, D6 bright, D7 Flash

     0001 – 16+16 Colour
          ATTR: D0-D2 ink, D3-D5, paper, D6 ink bright, D7 paper bright

     0010 - 32 Colour
          ATTR: D0-D2 ink, D3-D5, paper, D6 bright, D7 NOT halfbright

     0011 - 16C (4 bits per pixel chunky mode)

     0100 – 256 Colour mode 1
          ATTR: D0-D7 - ink colour, BORDER – paper colour

     0101 – 256 Colour mode 2 - 2 byte attribute read.
          ATTR: D0-D7 - ink colour, D8-D15 - paper colour

     0110 – 16 colour Planar mode

     0111 – [Reserved]
     1000 – [Reserved]
     1001 – [Reserved]
     1010 – [Reserved]
     1011 – [Reserved]
     1100 – [Reserved]
     1101 – Rasterscan (pixel colour = BORDER colour)
     1110 – [Reserved]
     1111 – 256 colour chunky (8 bits per pixel) mode

DEFAULT decode mode is just like a ZX Spectrum - Ink and Paper are effectively chosen from two CLUTs of 8 colours each (if the default palette is used, this is identical to choosing colours 0-7 with bright set to either 0 or 1)
16+16 Mode is similar to DEFAULT decode mode, except that ink and paper can be selected from a single group of 16 colours (if the default palette is used, this effectively gives you a separate bright bit each for paper and ink)
32 Colour mode is similar to DEFAULT decode mode except that ink and paper are both selected from one of four different CLUTs of 8 colours each. If the default palette is used, this effectively gives you 4 levels of bright - the flash bit is an inverse "half-bright" bit (it's "on" when unset, off when set) to prevent the DEFAULT palette being too dark when used in 16 colour modes
256(i) colour mode uses the entire attribute byte to dictate the ink colour. Paper colour is dictated by the BORDER colour stored at IO address 0x9E3B.
256(ii) colour mode uses two attribute bytes. The first to dictate the ink colour, the second to dictate the paper colour.
16 colour planar mode uses 4 256x192 pixel bitplanes to dictate pixel colour. In DEFAULT palette mode this equates to plane 1 (stored in page 5a) being a blue plane, plane 2 (page 7a) being a red plane, plane 3 (page Da) being a green plane and plane 4 (page Fa) being a "bright" plane.
256 colour chunky mode uses a byte per pixel. A single screen takes up 48K of VRAM. This mode is only really of use for title (or otherwise static) screens due to the amount of data that needs to be shifted around.

There are 3 methods of decoding the "logical colour" into a physical colour:
  • Default palette. This is a hard-coded palette. The first 16 colours are identical to the ZX Spectrum's colours, the next 16 are dimmer versions of the first 16. Colours 0-7 – intensity 1 colours; Colours 8-15 = intensity 3 versions of colours 0-7; Colours 16-23 = intensity 0 versions of colours 0-7; Colours 24-31 = intensity 2 versions of colours 0-7. [The remainder of the default palette are awaiting definition] 
  • Prism palette. This is a user-defined palette. Each colour can be assigned 8 bit red, green and blue elements. Whilst the Prism specification allows 24bit definitions for each colour, some implementations may transcode these into 9bit colour (3 bits per element), 12 bit colour (4 bits per element) etc. My implementation currently uses 12 bit colour (4 bits per element) as shown in the diagrams above
  • GggRrrBb (aka G3R3D2 encoding) is a hard-coded palette as used by ULAplus, MSX etc. Bits 0 and 1 define the blue element; 2,3 and 4 define the red element and 5,6 and 6 define the green element.
Palette selection is made using 4bit register 0100:

OUT 8E3B, 0011xxxx  ZX Prism palette selection where xxxx is:

     0000 – DEFAULT

          Colour 0 – Black, Colour 1 – Blue, Colour 2 – Red, Colour 3 – Magenta
          Colour 4 – Green, Colour 5 – Cyan, Colour 6 – Yellow, Colour 7 – White

            Colours 0-7 – intensity 1 colours (as numbered above)
            Colours 8-15 = intensity 3 versions of colours 0-7
            Colours 16-23 = intensity 0 versions of colours 0-7
            Colours 24-31 = intensity 2 versions of colours 0-7

      0001 – GGGRRRBB

          bit (0) – blue(0)
          bit (1) – blue(1)
          bit (2) – red(0)
          bit (3) – red(1)
          bit (4) – red(2)
          bit (5) – green(0)
          bit (6) – green(1)
          bit(7) – green(2)

     0010 – ZX Prism PALETTE

          Colour 0-255 looked up vs the user-defined ZXPrism Palette


  1. not even one teeny weeny comment?

  2. still no sign of anyone using the border port to diable the main pixel area - border port is uncontentioned yes? how much data can a DMA fart thru it and what variable clock /pixel sizes /colour depths could be supported ?

  3. You're replying to the post where I "reveal" that there's a mode which uses the border port to control pixel colour ;)
    I've nicknamed this mode Roger mode.

    ZX Prism no longer has DMA as part of its design so I can't comment on the speed of its data-sharts. Instead, the full FPGA SOAC implementation has a potentially very fast on-chip Z80 (I've not tested this fact, but I've read somewhere that it can successfully be clocked up to around 200MHz depending on the speed of the memory used).

    The hybrid FPGA/Z80 ZX Prism implementation has a 20MHz Z80 which clocks between 3.5, 7, 14 and 21 MHz

  4. when you get to 1mb of video ram arent you seriously thinking about 1080p?
    the reason i kept banging on about the sam coupe was that the hi rez mode can in theory display the same 16 colours that the lowrez
    256x192 mode can( though still higher than the 160x200 of the 16 colour cpc commodore atari bbc etc)

    it is a bit of a fiddle and i was trying to ask a couple of other 8bit forums about how the 16 colours are stored for their machines - saw some lovely enterprise interlaced images that nearly looked better than amiga/st though no idea if they were genuine or how fast the data could be read from an IDE adapted compactflash/twin sd

    that should have been
    the border port on the sam coupe in modes 2,3,4 can be used to disable the screen speeding the processor as it reduces video ram contention - bit like zx 81 fast mode maybe - though no idea how the 81 made screen stuff appear if it doesn't have the same ula as the speccy

    was only mentioning the DMA as the MB-02+ hi density disk interface for the speccy uses it for a nice version of the timex 8 pixel attribute mode - sam uses ram for this like the timex only sam doesnt have a monochrome hi rez mode which could have used a similar system to mode two and then only taken up 12kb
    our 6mhz80b is fighting with 24kb of video ram - slowing her to half speed like the electron! - even the beeb with her 20kb video ram page had 6502mhz~8mhz80? - what a pity none of the coprocessors were receiving the video output signals to play with!

  5. you cannot be serious about 200MHz80?
    if the MIP was calculated by dividing by 8tstates
    so 8MHz is a MIP
    then at 200MHz is almost 30MIPS - only its more than that as most of the interrupt routines that do things regularly suddenly take up much less time?
    is there any way to figure out how many KB of video ram a MIP of processing power can manage?
    everyone complained the sam just didnt cut the mustard - i'm still not sure...

  6. we only just worked out that if a zx spectrum emulator on the sam coupe- you just load the spectrum rom into ram paged into the bottom of ram and set video mode to spectrum compatible mode 1
    well if this machine had been shipped with external ram - even as little as 128k of it
    when paged in - unfortunately only above 32,768 she runs zx spectrum stuff at 6mhz - she was already running stuff at 20% faster than zx without even begining to fiddle with line interrupts - a built in port on the sam asic - and the border ports screen off control ability
    not only that but does anyone know why setting the stack pointer to point to a video ram address and then pushing to it - wouldnt that get you two bytes in video ram much faster than LD(HL),n does? 11tstates(maybe sam asic have something to say about that!) i think the only thing that might be faster is the DMA? but how does that know the screen resolution or bits per pixel? mode 3 hi rez on sam is 2 bits per pixel - there isnt a z80 nemonic to shift or rotate two bits left or right is there?

  7. think we got off on the wrong foot?

  8. as there is absolutely no zx spectrum internet website directory of every single zx spectrum and z80 based 8bit machine - i kind of assume that when i comment on something or try to communicate with someone that they have seen every single other site that im trying to refer to - although half the time the links posted are not even validated and seem to be being hacked before they even reach the intended person to whom im trying to communicate...

    well all the best with your hardware i really hope you make something of it - you couldnt do any worse than i managed to for the sam coupe...

  9. you will never communicate with the ula+ or Paul Farrows' spectra interface designers?

  10. i can give you links to their sites provded the comment box doesnt crash when you enter a html link
    do i need to delete the http:\\
    bit that sometimes gets around the bullshit we cant be bothered to tell you what you can or cannot put in a text box before you have typed it that seems to occur so regularly...

  11. i think the spectra has 32k of ram
    i think it claims to add 4 pixel attributes but clear that would mean 18kb of video ram - 128kb attributes and 6kb pixels - this is more than there is in the 16kb ula video ram area
    64 colours too
    no hi rez
    dunno if it can be interlaced as the pc program Paul posted on his site to allow us to convert to his new video modes is pretty restrictive and wont let us create images that flip between two screens at 50Hz - which lets not forget has absolutely nothing to do with the 60Hz that most ibm wonderful pc compatible computer monitors work at...
    go figa?

  12. have you checked out the hungarian tarjan site with its clones and interfaces?
    what a shame there isnt a lit of hardware interfaces that lets us know a bit more information
    like which ones are or are not compatible with which other ones
    im desperately trying to persuade youtube to adopt the rzx file archive as the default for all 8bit videos on the internet
    even my own super massive 30MB 39 second sam coupe animation is only 3mb of zipped data and sim coupe comes in under 2mb so to my mind when it takes six months to transfer the video on youtube there is a much easier way

  13. The utility allows an image file (in either .BMP, .GIF, .PNG, .JPG or .TIFF format) to be loaded (using the toolbar, menu, via drag and drop, or right click and Paste) and automatically converts it into the selected SPECTRA attribute mode (as specified by the Attribute Size, Colours and Encoding Size options). Dithering may be applied, which aims to produce a more accurate colour representation of the original image. Images are automatically scaled to 256 by 192 pixels upon loading.

    The converted image can be saved (using the toolbar or menu) in the following formats:

    Binary generates a file containing the bytes from the display and attribute files, with any regions between them filled with bytes of $FF to form a contiguous block. The format supports a sub-option to include a Display Program. This is a small machine code routine that loads the data into the display and attribute files and switches the SPECTRA interface into the appropriate attribute mode. If the Display Program is included then sub-option Target ROM is available to configure the program to run from ROM space (address $0000) instead of RAM (address $8000). This allows the program to be run from a ZXC2 or ZXC3 ROM cartridge, created using the Cartridge Creator utility. When targetting the ROM space, the attribute file data is stored immediately after the display file data, and hence there are no regions of $FF bytes inserted. The Display Program allows the flash bits of every attribute file byte to be exercised. When displaying an image using a single byte attribute mode, pressing key F will toggle the flash bits. When displaying an image using a double byte attribute mode, pressing key I or P will toggle the ink and paper flash bits respectively.

    Tape generates a virtual cassette file which, via a Spectrum emulator, can be saved to a real cassette and then loaded into a Spectrum (which has a SPECTRA interface attached). The sub-option to include the Display Program is available and functions as described above. The virtual cassette file can be created in either .TAP or .TZX format.

    Assembler generates an assembly language version of the Binary output. Sub-options to include the Display Program and Target ROM are available and function as per the Binary output format. Two other sub-options are also available. The sub-option Tab Indent selects whether to indent each assembly language instruction with a single tab character or with 8 spaces. The sub-option Lower Case specifies whether the assembly language instructions and labels are output in lower case or upper case.

    Image allows the converted image to be saved as either a .BMP, .GIF, .PNG, .JPG or .TIFF file. The image can also be copied to the Windows clipboard by right clicking on it and selecting Copy.

    The SPECTRA Image Converter utility also allows the number of colours used in the original or converted image to be determined by right clicking on the images and selecting Properties. A description of the output file format options can be displayed by clicking on the 'i' symbol located on the toolbar.

  14. can you see any mention at all of interlaced there?
    which you'd think someone might bother with seeing as they went to all the trouble of adding 8 pixel attributes like the timex and samode2 but couldnt be bothered to add a 12kb hi rez mode

    1mb of video ram is going to need more than 200mhz isnt it? even with parallel DMA?
    200MHz80? are you sure about that?
    it isnt a z800 - like the r800 in the msx turboR!vdp9978?

  15. everything im typing is being read
    raspberry pie
    gpu details?
    no video encoder included
    tv encoder or digital tv tuner
    certainly no 1080p video input and encoding
    they didnt even bother to include a zx spectrum emulator scren shot in the £20 raspie book
    those acorn folk really have a chip on their shoulder from sinclair days

  16. 512x384
    in just four colours on sam coupe mode 3
    we only needed a bit of extra hardware juice like a DMA and this would have been 16 colours per scan line easy and full 128 colours onscreen - interlaced and blended
    that is DIRECTX
    right there
    you do not beleive me?
    dxdiag into xp run box
    doesnt work anymore on vista or win7 as they realised after five million emails that dropping the screen rez to 640x480 for the display settings test is illegal - but there software and tons of others does it anyway...

  17. The requested site could not be loaded.
    400 Invalid syntax

    An error has occurred while trying to open the page .

    Suggested actions:
    Try to reload page:
    Press the Back button or try to open another link


  18. if you are going to offer an invite friends that crashes every time isnt it a bit like offering a user name and password login where the five day transfer of a stupid and utterly irrelevant image puts the cursor from the hidden password line back to the revealing username line while someone is typing
    this is online crap and there is mountains of it
    like paying for a service and getting less than 3% of what you pay for and having your computer hacked everytime you complain till two hardrives are fire hazards

  19. OK Roger, where to start.

    Firstly, Prism does 512x384 in 255 colours with 8x8 or 8x1 attributes. It also does 16 colour 256x192 without attribute clash. That's why I'm not bothering with Sam screen modes ;)

    Secondly the "invite friends" link is nothing to do with me. It's provided by Blogger, the website that I use to post this blog.

    Thirdly, I repeat again - ZX Prism doesn't have 1MB of video RAM, no idea where you got that from. It has 64K video RAM.

    Fourthly, I talk to the people that came up with ULA+, especially Andrew - I was one of the people that bounced ideas around with him when he was first thinking about how it could work. ZX Prism supports ULA+ including the 512x192 "Timex" screen mode.

    Fifth, if you cant read the words on the images... click on the images to see them full size. The images explain how the screen data is stored for different screen modes.

    Sixth, no I'm not bothering with interlacing. Nor am I looking at anything like 1080i. Prism outputs a 640x480 @ 60Hz 12 bit colour signal, which is a mode that almost all monitors since the VGA days supports.

    Seventh, The CPU in the "SOAC" (System-on-a-chip) ZX Prism is hosted on the FPGA along with the Prism equivalent of a ULA - it can be clocked pretty fast. 200Mhz is a speed I've heard touted around but I've not tested it at that sort of speed yet. I'll be happy if it'll do 28Mhz or 56Mhz!

    Hope that answers some of your questions at least :)

    Thanks for your interest in my project, I'm happy that there are other people who are interested.

  20. the bit i really do not get is that if you are honestly trying to hack our online experience arent you making a complete hash of it i mean what the hell is this?
    i know it might not have nothing to do with you personally seeing as it is the wonderful design of the site that desperasetly wants to encourage folk to setup usernames and passwords and then pretend that they can
    ADD friends?
    what the hell is going on in internet land this isnt just shit its so crap its criminal
    you want me to invite folk to view your blog - well theres 3,000 folk in my address book you cant even send 30 invites successfully what the hell is the site playing at?
    here comes the subject line:some great characters here!
    ▓│┤ÁÂÀ©╣║╗¢网页 图片 地图 资讯 视频 博客 更多 ▼ 生活 热榜 网站导航 日历 照片 文档 更多 » ½¼« invites you to...
    I'm following ZX Prism and think you'll be interested in it as well. To check it out, follow the link below:

    "christ this is crud how the hell do they get away with it"

    Google Friend Connect helps people with common interests discover interesting sites and interesting people. To learn more, visit


  21. 0000 – 256x192 8x8 attributes
    0001 – 512x192 (vertically halved display) 8x8 attributes
    0010 – 256x384 (horizontally halved display) 8x8 attributes
    0011 – 512x384 (quartered display) 8x8 attributes
    0100 – 256x192 8x1 attributes (“hicolour”)
    0101 – 512x192 (vertically halved display) 8x1 attributes
    0110 – 256x384 (horizontally halved display) 8x1 attributes
    0111 – 512x384 (quartered display) 8x1 attributes
    1000 – 256x192 Hardware GIGASCREEN 8x8 attributes
    1001 – 512x192 Hardware GIGASCREEN 8x8 attributes
    1010 – reserved
    1011 – reserved
    1100 – 256x192 Hardware GIGASCREEN 8x1 attributes
    1101 – 512x192 Hardware GIGASCREEN 8x1 attributes
    1110 – reserved
    1111 – reserved

  22. 0000
    i was trying to ask paul farrow if his spectra interface included a 32byt buffer so that the attributes once read once can be re read 7 times a piece - wouldn't this reduce the amount of ula ram contention that occurs?
    his interface offers 4 pixels attributes so i actually asked him if a 32/64 byte buffer was possible - but he makes no mention of interlaced modes and the pc program to convert images doesnt offer any interlaced modes

  23. 0001
    12kb pixels
    1.5kb attributes
    nice one again that is 64 attributes on a scan line - so the previous comment would need a larger buffer if such a thing were possible or worked
    sam runs stuff at 20% faster but external ram is running at 6MHz so code above 32,768 is full tilt - no one has tried it though

  24. 0010
    this would be a world class resolution
    is there any way for your hardware to rotate this thru 90 degrees
    384x256 is pretty close to some of the marvellous BBC model B micro computer - of the lets design something so expensive they cant afford it school of computing

  25. speaking of which that raspie book didnt have one screen shot of a zx spectrum emulator running on it
    think someone has a big sinclair chip on their shoulder -
    all that about 25% fault rate when their own asic/ula was only one in ten - ub40 wrote a song about that...

  26. 0011
    this is it
    if we can do this and do it well...
    still no news on the border port front
    sams asic turns the screen off in modes 2,3,4 when one bit of the border port is set - utterly pointless except that processor is full tilt 6MHz - luckily no one has used it - not mod players no sid chiptune,without hardware interface - art package midi networking or demos or sprites
    when the screen is switched off if the border port colour - one of 16 possible unlike the speccy could be blead into the main pixel area then how long before some bright spark fgures out how to keep the border port colour bled into the main pixel area as a paper colour - DMA could be used to change this colour - nice to have a variable clock speed for various resolutions or even some kind of alternative text only modes especially if they can handle proportional fonts and user defined character sets

  27. 512x384
    have you ever typed into windows xp
    RUN box
    did you try the directx9 tests?
    this drops screen rez to 640x480
    even if your laptop doesnt support this screen mode!

  28. we hit 16 colours per scan line with this and we'd finally give the 16bit and the rest a run for their money!

  29. you have never seen a scan doubler for the amiga? i think it is something to do with a reduction in the flicker for 50/60Hz amigas - you dont understand that at all?

  30. giga screen have to go and look that up
    impossible to add
    320x200 - very common with the 6502machines
    even the enterprise had a 256 colour screen mode - though very low rez it was - what a shame that the other modes could access the 256 colour palette from the low rez mode in the less bits per pixel modes i guess the 16 colour ones colours are not accessible from the four colour mode - though i have seen some demos screen shots claiming to be enterprise that look like 16 bit stuff - what a shame there isnt a bmp2scr type program that handles screens and video avi file conversion though not much of an idea about how many screens in ram or where pretty sure she had 4mb max ram though
    saw an intersting 128k zx spectrum emulator in hardware on ebay recently no idea if it works though no screen shots or youtube videos of programs...

  31. i see you are sticking with attributes
    is there a hardware limitation reason for this?
    be nice to add bits per pixel modes or even just use border port if there had been room for a DMA or dozen!

  32. DMA stops the processor just like on the 7.1MHz amiga - unless it only transfered a single byte - seems a bit much for single byte transfers? still no sign of anything that has even the remotest clue as to what the screen resolution is or the bits per pixel or the font size - clearly its illegal to put the internet bandwidth we are paying for onscreen right next to the 1-10% of it that we actually get...

  33. desperate to get in touch with ingo the only person with a DMA connected to a zx spectrum - even if it doesn't do full screen 8 pixel attributes on the 48 or the +2ab3

  34. well the dma gets 8 pixel attributes with a 128k machine
    dont think i have seen a single interlaced 8 pixel attribute or multitech or timex hi colour or sam mode 2 screen though

  35. Sorry for the very late comment. I am loving this project.

    Would it be possible to have a bit on out port 8E3B select whether screen memory arranged in the Spectrum's mixed up screen memory model, or in a simple linear model? It would be good to have that choice for all modes.