2 days solid progress

The PS/2 woes bug me no more! After a LOT (and I mean a LOT) of head-scratching, troubleshooting and trying new sockets, USB keyboard adapters, alternative keyboards etc I discovered that the 2 pins on the FPGA which were linked to the PS/2 socket were permanently shorted to ground. This wasn't down to wiring or anything on the board - the inputs themselves were buggered. A bit of testing later found that my original PS/2 keyboard was dead as a Norwegian Blue and appeared to be the original source of my woes.

Wiring the PS/2 clock and data inputs to two spare FPGA pins, and using a newly acquired PS/2 keyboard finally got ZX Prism responding to key presses. Hurrah! Some changes to interrupt generation which I'd made whilst troubleshooting the original problem got reverted and tuned over a nice game of Pssst.

Pssst was "loaded" by way of using an image of the Psst IF1 cartridge in place of the Spectrum ROM. This was all well and fine, but I decided tonight that I'd try my hand at a tape interface. I started out by using the RXD input of the RS232 UART as the source of the "tape in" bit of the ULA port (IN 0xFE). The UART is tolerant of (relatively) high voltages and thus protects the FPGA from the crappy old 80s cassette players. Between the RXD pin of the UART and the tape socket is the usual circuitry found on an issue 3B spectrum between the tape socket and the ULA. I expected to have to do some tweaking, but no. Horace and the Spiders loaded first time.

So in the last couple of days, there's been some good solid progress! Next, I'll try to get an MMC slot wired up and ESXDOS working. The MMC slot on ZX Prism was initially going to mirror the way ZXMMC works (same ports etc), which is the same way Mike Stirling implemented MMC on FPGA Spectrum, however DivMMC has recently been released and is very popular, so I'll use DivMMC's ports - this has a number of advantages, not least that the DivMMC version of ESXDOS will be able to be used.

Screen decoding

As you may have noted from previous posts, ZX Prism goes through a number of different stages to convert values in memory into what's displayed on the screen.

Firstly, the addresses in VRAM to be read are calculated; this takes into consideration a number of things: the type of mode being displayed - (standard (pixel+attribute), 16bit attribute (pixel+2 attribute), planar, text, tiled), the size of attribute (8x8, 8x1) etc. The appropriate parts of memory are then read.

If a planar screen mode is selected, the pixel data from each plane is combined to produce a "logical colour" number. If a pixel+attribute screen mode is selected data is then decoded using a selectable attribute decode method, producing a "logical colour" number.

Finally, the logical colour number is decoded into a physical colour - There are three selectable palettes to do this.

The Default palette's first 16 colours are mapped to be the same as the colours on the ZX Spectrum (including colour 8 - "bright black" being identical to colour 0). The next 16 colours are the same again except duller.

There is also a fully redefinable 256 colour palette. Finally, there's a palette which is directly mapped to the 256 colours available to choose from in ULAplus (this palette is automatically selected when ULAplus is used)

These different parts of the screen data decoding process are all controlled using ZX Prism's 4-bit control registers. The registers are manipulated with an OUT to port 0x8E3B (36411).

The value to be sent to port 0x8E3B is constructed as follows: The most significant 4 bits of the value choose the register to be written to (in the case of the attribute decode method, this is register 3 - "0011" in binary). The least significant 4 bits of the value is the data to be sent to the register. Again, using attribute decode method as an example:

0000 selects Spectrum attribute decode (3 bits ink colour, 3 bits paper colour, 1 bit bright, 1 bit flash)
0001 selects 16+16 attribute decode (3 bits ink, 3 bits paper, 1 bit bright for ink, 1 bit bright for paper)
0010 selectes 32 colour mode (3 bits ink, 3 bits paper, 2 bits bright)
0100 selectes 256 colour mode 1 (8 bits ink colour, paper colour is same as the border colour)
0110 selects 16 colour planar mode (which doesn't use an attribute byte at all!)

So:
    OUT 36411,48 selects spectrum attribute decode
    OUT 36411,49 selects 16+16 mode
    OUT 36411,50 selects 32 colour mode
    OUT 36411,52 selects 256 colour mode 1

256 colour mode 1, default palette

16+16 mode - you can see instances of bright ink over non-bright paper and vice-versa)

32 colour mode - 4 levels of bright

256 colour mode 1, but with the ggggrrrrbb palette

Getting intense...

Yesterday I wired up the remaining lines on the video DACs. ZX Prism now has more than 8 colours - in fact it has a total of 4096 colours available (though currently you can only choose up to 256 of them for use at one time).

I again tested the 4-plane planar mode with RGBI attribute decoding. When doing so, I initially forgot to put the appropriate test data back into the VRAM pages - instead four loading screens were loaded (from an earlier 512x384 test). What resulted was both a complete mess and also a great demo of planar mode, so I decided to take a picture and put it up here.

Can you work out which game was loaded into which bitplane?

For fun, I did another one too...

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 ;)

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)

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 :)