Saturday, July 19, 2014

16 Colour Planar Mode Revisited

So the toesocks in last post's 'planar mode' screenshots looked a little different to those in the gigascreen screenshot... I initially thought it was because I'd gotten the planes muddled up, but it turned out that my test data was inverted! (Thanks again to Guesser for swiftly providing me with corrected test data) OK, so I did also get the plane data muddled - but only once! Anyway, here's a couple of planar mode screenshots to give a rough idea of what can be done. I'm not an artist, so just used an automated tool to convert the prism+planets image... it didn't turn out great ;)



Thursday, July 17, 2014

16 Colour "colour-clash free" planar mode and Hardware Gigascreen

I put a plea out on the World of Spectrum forums for somebody to help me by producing some test screens in different formats. Guesser very quickly produced some files which enabled me to implement and test the 16 colour planar mode. This worked great first time, except that I forgot that the Spectrum's colours are in order of intensity, not in RGB binary order so I loaded the colour planes into the wrong VRAM pages. Oops. Well, you live and learn... What's more, when I tried to fix the order I got it wrong again. D'oh.
256x192 16 colour planar... with the bitplanes loaded into the wrong VRAM pages so the colours are muddled. Oops.


Take 2... still not right, but it proves the mode works - the colours being wrong are 50% me being distracted by baby and 50% me not having eaten dinner (since remedied)

Hardware Gigascreen - it appears to work without too much shimmer. I'll do more tuning once 4 bit per channel VGA is connected up - I suspect we lose something by having no "BRIGHT" colours at the moment (shortfall of the dev board, not ZX Prism)



Wednesday, July 16, 2014

Development moves to Cyclone IV

Back again after a bit of a break - apologies for the radio silence once again, but real life has a habit of getting in the way of things like blogs!

Much has happened with ZX Prism since my last post. The most major thing is that development moved from an Altera Cyclone II based dev board onto my shiny new Cyclone IV dev board. This has the major advantage that the Cylclone IV EP4CE15 FPGA used on this board has enough internal memory cells to implement the majority of the planned ZX Prism screen modes. Some of the more "out there" modes I had planned may fall by the wayside but there will still be plenty to choose from.

Since moving to the new dev board, progress has been swift. I got the basic video driver ported across in just a couple of hours and then set about building a Spectrum-like computer. In just under 2 days, I had ZX Prism initialising and displaying the hallowed "(c) 1982 Sinclair Research Ltd" message. In the top left of a 512x384 resolution screen :)  I tried alternative ROMS too, just to prove it wasn't a fluke and all worked happily - SE Basic and the ROM versions of JetPac and Pssst all booted fine.

Since then I've been battling getting a PS/2 keyboard working. It worked for about an hour and then stopped working entirely without me changing anything. Some poking and prodding about the dev board with a multimeter showed that the data signal wasn't making it to the FPGA anymore.  Routing the signal myself doesn't seem to have fixed things. I'll leave this for now - it's just led to several days of frustration and no further progress on Prism. I can come back to PS/2 later when I wire up the SD Card slots and replacement VGA connector. Yes, despite boasting a shiny new Cyclone IV, this dev board only has 1 bit VGA - that's right, at the moment ZX Prism only has 8 colours!

Anyway it's been ages since my last post so here's some pictures of ZX Prism showing off it's 4 different screen resolutions:

Standard 256x192 resolution, standard palette, standard attribute decoding
 512x192 resolution, standard palette, standard attribute decoding
(I will also add the monochrome Timex 512x192 mode later) 

 256x384 resolution, standard palette, standard attribute decoding


512x384 resolution, standard palette, standard attribute decoding

Booting the original Spectrum ROM in 512x384 resolution :)


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






Thursday, July 18, 2013

ZX Prism 1024K mode Memory Map


This may go some way to explaining why ZX Prism's codename was "Project Overkill" for a while.

Some further explanation/clarification:

In 1024K mode, the memory page at 0xC000 is chosen using port 0x7FFD in the same way as the 1024K Pentagon (as documented in the ZX Profi documentation by Velesoft):
  • 7FFD bit 0 = Page # bit 0
  • 7FFD bit 1 = Page # bit 1
  • 7FFD bit 2 = Page # bit 2
  • 7FFD bit 6 = Page # bit 3
  • 7FFD bit 7 = Page # bit 4
  • 7FFD bit 5 = Page # bit 5
It should be noted that outside of 1024K mode, port 7FFD bit 5 when true works as expected (ie it locks the current memory configuration and prevents any further memory paging - known as "48K mode" in some circles).

Due to the way this locking works in ZX Prism, enabling 1024K mode from "48K mode" has the effect of re-enabling memory paging.


Wednesday, July 10, 2013

Formal specifications

During the FPGA debugging process, a number of things struck me. First was that I'd made the video RAM interface overly complicated - or at least more complicated than it needed to be - and secondly I realised that whilst I had a lot of notes about how the colour palettes, screen modes and CPU control were going to work, I hadn't sat down and formally produced a full specification.

So I took a couple of steps back and also a small break to brainstorm a feature wishlist. I then thought about how all the different proposed features would work, which I considered "essential" and which were not essential but could be produced easily using the technology required to realise the "essential" features.

As anyone following this blog will be all too aware, this process has taken some time, not least because a number of other areas of my life have been vying for my time as well. It's all for the best though, and the specification boasts a strong and usable feature list.

Here's a taster.

Memory
  • The all-RAM "Special" memory mode available in the Spectrum +2A/B and +3 will be replicated meaning ZX Prism will be able to run the various software that requires it.
  • Outside of the "Special" memory mode, the ROM area (0x0000 - 0x3FFF) is selected from 32 pages of FLASH (512K) or 32 pages of non-volatile RAM. This arrangement is controlled in the same way as the memory in the ZXMMC+ interface, including the fact that the page number selected is affected by the 128K ROM selection bit of port 7FFD. Unlike ZXMMC+, ZXPrism also watches the ROM selection bit of port 1FFD so that 64K rom sets (eg +3 or +3e) can be used. 
  • The memory between 0xC000 and 0xFFFF, is 16K selected from a set of 64 pages, for a total memory of 1MB. The page number is selected in the same way as on the Pentagon, using port 7FFD bits 0-2, 5, 6 and 7.  1MB mode can be disabled for compatibility, re-enabling it can be used to re-enable paging if locked in 48K mode.
  • ZX Prism has 64K of video memory split into 8 x 8K segments. Which segment(s) the video circuitry used depends on which screen data decode method and which screen resolution is selected. As on the Spectrum, the CPU sees video memory between 0x4000 and 0x7FFFx, but unlike the Spectrum, it is possible to choose which 8K segment the CPU sees at 0x4000 and which 8K segment it sees at 0x6000. Of course in BASIC crashes will occur if the segment at 0x6000 is changed, so this is discouraged....
  • To reduce CPU overhead when using one of the "Planar" screen modes, it is possible to tell the hardware that writes to 0x4000 - 0x7FFF write to one, two, three or four planes (segments of video memory) at once.  
Hardware control

ZXPrism hardware control is done via 16 x 4 bit registers. These are modified by writing to IO port 8E3B. The most significant nibble of the data writen to the port selects which register you are writing to, the least significant nibble is the data to be written to the register.

    OUT 8E3B, 0000xxxx - CPU speed control, where xxxx is:

        0000 – Slow (3.5MHz) DEFAULT
        0001 – Double (7MHz) if supported, else 3.5MHz
        0010 – Triple (10.5MHz) if supported, else 7MHz
        0011 – Quadruple speed (14MHz) if supported, else 10.5MHz
        0100 – 6x speed (21MHz) if supported, else 14MHz
        0101 – 8x speed (28 Mhz) if supported, else 21MHz
                                               .  .  .
        1111 – Fastest supported speed (currently 21MHz)


   OUT 8E3B, 0001xxxx - Misc options

        0000 -
        xxx1 - Enable Spectrum 48K style video memory contention
        xx1x - Allow read/write to port xxFF (enable Timex mode)
        x1xx - Enable "Bright Black"
        1xxx - Disable 1024K mode/Enable 48K mode lock

Other hardware control registers will be covered in more detail in future posts:

   OUT 8E3B, 0010xxxx - Screen resolution, attribute size, enable hardware "gigascreen" mode
   OUT 8E3B, 0011xxxx - Screen/Attribute data decode method
   OUT 8E3B, 0100xxxx - Colour decode method (hardcoded, ULAplus palette, PRISM palette)
   OUT 8E3B, 0101xxxx - CPUside Video Memory Control: Planar mode write options
   OUT 8E3B, 01100xxx - CPUside Video Memory Control: segment at 0x4000
   OUT 8E3B, 01101xxx - CPUside Video Memory Control: segment at 0x6000


Hope that wets your whistle - more to come at a later date.

Thursday, September 20, 2012

Prism progress update

Just a quick update for now. LOTS has happened since I last posted though. LOTS more wiring has happened, mainly between the FPGA and the bus transceivers that I'm using to convert between the FPGA's 3.3v logic and the Z80's 5v logic.  I've also put prism into a case, wired in the twin SD Card slots, and wired up a power switch, power status LED and a reset button.

On the left are the two SD Card slots with their related activity LEDs. Next, there's two red "NMI" buttons. Following that are 3 switches - the first will control if FLASH or NVRAM is to be used on startup. The third is the FLASH ROM write protect and the middle switch will likely switch between ABC and ACB stereo for the AY, though I've not decided for sure yet. Finally on the right is the power switch, power LED and reset switch.

On the bottom left is the PCB with the SD Card sockets mounted. Above that is the PCB with the joystick, keyboard and mouse sockets on it (not currently wired in). Above that's the VGA socket. The rest of the PCB is as described previously (though with a lot more wiring completed and the battery socket added)
 
The four empty sockets on the right are for the main memory, Flash ROM and NVRAM. These have been temporarily removed during testing to avoid damaging them if anything goes awry... I've got quite a lot of the 32K SRAM chips I'm using as video RAM, which is probably just as well as the interface and interplay between the FPGA, Z80 and video RAM is the first thing I'm testing. I've sourced and ordered a small number of 20MHz Z80s too but will be testing with a spare 4MHz version.
 
Yes the wiring looks a little messy, but it was hard to come up with a tidy way of doing it! Each parcel of 8 wires from the bus transceivers are taped together to make it a little more managable.
 
As of last weekend, ZX Prism is outputting a test pattern to its monitor. The pattern is generated using simple logic and counters in the FPGA, but it proves that the video circuitry is working, the syncs are being correctly generated and the 12 bit colour is working courtesy of the resistor-DAC.
 
Simple test pattern..