Saturday, August 9, 2014

Small update

Just a small update for today as it's been a fairly busy week so I've not had much time to spend working on ZX Prism lately.

Firstly, ZXPrism now has 512K available to it (in addition to the 32K video RAM). Up until this week, ZX Prism was running as a 32K machine, with its video RAM paged into the memory space 0x4000 - 0xBFFF. This arrangement was merely for testing. Prism's memory arrangement is now much more like you'd expect on a Spectrum 128, with video RAM at 0x4000 - 0x7FFF and 'ordinary' RAM between 0x8000 and 0xFFFF.

Like on the Spectrum 128 etc, the extra RAM is split into 16K banks which get paged into the area 0xC000 - 0xFFFF; as ZX Prism has 512K, this equals 32 x 16K pages of RAM which I'll refer to as pages 0 - 31. Page 2 is always paged into memory area 0x8000 - 0xBFFF (currently; this page may be changed to be selectable in future). The memory which is paged into 0xC000 - 0xFFFF is selected using IO port 7FFD - the same as on the Spectrum 128 - but of course ZX Prism has more pages available than on the 128 so ZX Prism uses bits 6 and 7 of port 7FFD in addition to bits 0 to 2. This matches the way that the Russian Pentagon 512 does it:

PORT 7FFD -

D0 - page[0]
D1 - page[1]
D2 - page[2]
D3 - display screen[bit 1] (msb - ZX Prism has 3 shadow screens, not 1)
D4 - ROM bank select[bit 0] (Prism will eventually have 512K flash ROM)
D5 - Prevent further memory paging (also known as "48K mode")
D6 - page[3]
D7 - page[4]

ZX Prism's SRAM is actually 256K of 16 bit RAM. Bit 4 of the page number determines if the upper or lower byte of the 16 bit data bus are to be used, effectively splitting the SRAM into two lots of 256K which is how 512K is achieved.

Currently ZX Prism's ROM is stored on the FPGA and is the original Sinclair ROM from the 16/48K Spectrum. As such, the ROM bank select currently does nothing. The "lock" to 48K mode also isn't yet implemented (though it would be trivial to do so), so ZX Prism currently perpetually runs in "USR 0" mode.

The additional memory was tested a number of ways - firstly RAMTOP was set to below 0xC000 and then unique test data was written to each page; then the data from each page was read back and verified. Of course there's not much 512K software (at least not that's available as a TAP/TZX file) to test, but I've tested several 128K games.

Speaking of tapes, I'd been finding loading to be a little unreliable. Everything would be OK for 3 or so minutes but then it would fail. It didn't matter if this was a turbo loader or standard loader. Eventually I found that one of the resistors in the tape-in circuit was getting very warm - when I swapped that out for a resistor of the same value but higher current rating, things got a lot more reliable. I still seem to have to use a higher volume level than on a normal Spectrum - I suspect that's due to the Spectrum's ULA working at 5v, and the Max3232 RS232 UART that I'm using to buffer input between tape and FPGA is expecting a higher voltage.

Finally, I've started hooking up the MMC slots so I can start implementing DivMMC and getting ESXDOS working. I'll have to do some more research on when exactly ESXDOS needs to be paged in and out of the ROM area (it reacts to an NMI switch, pages in as a shadow ROM on RST8, and has tape traps at least... and I have no idea of what triggers them - or what triggers a page out). I also need to know how the DivMMC does its ROM/RAM paging. If anyone can help, leave me a comment or seek me out on WoSF.

I've already done a bunch of Googling and searching threads on the World of Spectrum forums... Looks like I'll have to ask the designers/coders (or an emulator author perhaps) directly. Andrew Owen's already managed to give me a certain amount of insight, but I'm far from clear on all points!

Finally, a picture of ZX Prism as it currently looks. Please ignore any dodgy soldering you might notice. I've just got a new soldering iron, and it's a huge upgrade from my last one!


The dev board is a Black Gold Cyclone IV kit, which is very nice but you have to translate all the documentation from Chinese! This dev board comes with 256K of 16 bit SRAM, a similar sized FLASH, about 4MB of SDRAM, RS232, VGA, USB, PS/2 (which was broken on my board), and a LAN socket as well as the 7 segment displays and LCD screen. The veroboard contains the analogue circuitry for tape-in and (untested as yet) tape-out, the dual MMC sockets, and also the break-out connector for the PS/2 and VGA daughterboard (not pictured) which replace the implementation of each on the main dev board (the PS/2 socket was broken on delivery, and the on-board VGA was 8 colour only)

Sunday, August 3, 2014

ULAplus support

Spent the weekend tying up some loose ends and working on the user-definable palettes. ULAplus support is pretty much working now (it's currenlty missing the ability to read the palette back, and the ULAplus specification includes the Timex screen modes which aren't implemented yet).


I've also hooked the SRAM up, so Prism now has 48K. There's 512K SRAM on the dev board and Prism will have access to all that once I've implemented bank switching.

Wednesday, July 30, 2014

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.

Sunday, July 27, 2014

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


Thursday, July 24, 2014

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...

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)