Adding Audio

(updated 15/7/2017) I've recently started working on Prism again after a few months off. This last week I've finally gotten round to working on Prism's audio output. Up until now, Prism only had beeper and tape (SAVE) outputs, but now:

• In addition to being able to save to tape, Prism's tape-out and beeper output form a 2 bit channel audio output (the spectrum's audio circuit has similar behaviour)
• Added 3x (modelled) YM2149 - used to implement Turbosound and the 128K Spectrum's AY-3-8912
• Added 3 Covox (basically just an 8 bit latch on ports 0xFB, 0xF3 and 0xB3 which connect to  DACs to give 3 channels of 8 bit digital sound).
• Added Specdrum (like Covox, but on port 0xDF)
• Added SounDrive 1.05 mode 1 (basically Covox on ports 0x0F,0x1F,0x4F and 0x5F). These are panned: 0x0F and 0x1F are "left" channels and 0x4F and 0x5F are "right" channels.
• Added SAA1099 (the sound chip used in the Sam Coupe) with thanks to Miguel Angel Rodriguez Jodar for allowing me to use his implementation from the ZX Uno Sam core. At boot time, the SAA1099 is available on ports 0x02FF (data) and 0x01FF (register). However when Prism has been set to disable the Timex screen mode selection port (0xFF), then the SAA1099 is available at the same ports as on the Sam Coupe and SAA1099 add-ons (so: port 0x00FF(data) and 0x01FF(register)).
• Added two sigma-delta DACs and a pair of resistor-capacitor filters to create the audio output (thanks again to Miguel for pointing me at the Xilinx document on sigma-delta DACs)
• Added a mux to act as an audio output mixer.

It's sounding pretty good (though I have to disable a fixed-frequency buzzer on my FPGA dev board before I can hook up one of the audio outputs, so I've implemented it in mono for now)

Another 256 colour 256x128 Demo Image

Just a tiny update to show off another demo image showing off the linear 256x128 256 colour "clashless" mode.

Yes, I DO seem to use Satan for demos quite often don't I.

Solid progress...

So much progress since the last update! First up, I finally found why esxDOS wasn't working properly on Prism. Turns out that the divMMC automapper was working perfectly. The problem was actually with the SPI port. +3eMMC was working fine because it uses the SPI port slightly differently to esxDOS. A couple of tweaks to the SPI port implementation's sorted everything out - now both esxDOS and +3eMMC work perfectly.

FINALLY!

I was just about to give up on ever seeing this....

Getting esxDOS working means that I can use emulated TRDOS to try out some of the Russian software, some of which works best with no memory contention, or needs more than 128K of memory.

Fire And Ice running from TRD file. A fun and pretty platform puzzle game, similar to Solomon's Key

Mortal Kombat, running from TRD

Graphics modes, graphics modes... What would a Prism update be without more graphics modes? Firstly, I revisited Gigablend mode - this is a mode which blends the main and shadow screen together to give more colours - basically a hardware implementaiton of the software "Gigascreen" effect found in many Russion demos.

Gigablend mode
I'm afraid I don't know the artist to credit them

Probably one of my favourite gigascreen pictures, displayed using Gigablend mode.
I'm really sorry I don't know the artist to credit them.

Looking back through the blog, I noted that I'd not said much about the 4 plane (16 colour) 256x192 mode. This works in a similar way to the Amiga - 4 bitplanes of pixel data which mean each pixel can be one of 16 colours (ie there is no colour clash). Of course, being Prism, this isn't restricted to the 16 default colours, they can be user defined. Here's a few examples

But what about brand new modes?

How about a completely bonkers 4096 colour mode? Brainbow mode is a 3 plane 256x192 resolution mode with a twist. Each pixel can be one of 8 colours (black, blue, red, magenta, green, cyan, yellow or white/grey) the twist is that each 8x8 "attribute" square has a defined red, green and blue element intensity level. Probably of limited usefulness, but hey - it's up to 4096 colours on screen at once.

It really is quite bonkers... 

What else? Well definitely more useful are the new linear modes. In addition to the Radastan and Zesarux linear modes, Prism's ULA2 also has its own linear modes - two of which have been implemented to date.

Firstly, the 128x128 resolution 256 colour mode which uses 16K of VRAM

256 colour linear (clashless) 128x128 mode

...and secondly, the 256x128 resolution 256 colour mode which uses all 32K of VRAM

256 colour linear (clashless) 256x128 mode

Hand-converted from a 256 colour BMP... ignore the couple of alignment errors ;)

Due to the data needed to be moved around, these modes are probably more useful for splash screens or perhaps static pictures in adventure type games than they would be for actual arcade games (happy to be proven wrong though!)

Happy New Year

Hi folks, Happy New Year.

There's been quite a few developments with Prism in the past few months, though again a lot of them are "under the hood" and not particularly visual. A lot's been done to improve stability at higher CPU speeds, and there's also been a large amount of refactoring of Prism's microcode to make it easier to work on and add new features.

Over Christmas, I did a lot of compatibility testing (also known as just playing games), as well as some playing around with palettes...



Gauntlet II with a modified palette

Of course it wasn't ALL playing games and refactoring... I did do some work on adding new features, including Radstian mode (a 128x192 16 colour "chunky" mode with no colour clash). I also started adding César Hernández Bañó's additional screen modes (similar to Radstian mode but with different resolutions)

SpongeBob Radastanpants gazing lovingly at a ZX Uno prototype

Another Radastan mode demo pic (though personally I think Robot Chicken did it better)

I've also been working on a boot rom, based on a test ROM that César Hernández Bañó created. I'm re-learning Z80 after a break of several years, so César has been increadibly helpful, thanks mate! The boot ROM lets you chose which ROM you want to boot to, and lets you set a couple of options. It also displays the Prism logo which is based on a mock-up which Andrew Owen created for me a while ago. You can probably guess where I got the idea from ;)

Shine on, you crazy ROM selector.

The boot rom utilises Prism's 16 colour (4 plane) clashless mode and as you can see it also departs from the Spectrum's standard colours - for example non-bright yellow's orange.

New graphics modes

Today I did a little bit of poggling around with the VGA driver and started adding some new functionality to it. There's still some tweaking to be done, but here's a taster.

Last year, I did some experimentation around a hardware GigaScreen mode which did some tricky work interpolating pixels from the main and shadow screens depending on if it was an odd or even frame. This was an interesting experiment but the results left a lot to be desired on most monitors. Today I tried a different method - looking up the physical colour for the corresponding pixels on the main and shadow display, then blending the two. This seems to work quite nicely.

Some blended colours, yesterday.

A couple of days ago I was reading up on the various graphics modes on other computers and came across documentation on the Commodore 64's low-res multicolour mode which halves the number of pixels per colour cell (from 8x8 to 4x8) but increases the number of colours per colour cell from 2 to 4. I decided that this sort of thing would be easy to add to Prism.

I toyed with two different ideas - the first maintained the usual 256x192 resolution, and the second halved it, like the C64 mode. In both cases, a pixel is defined by two bits instead of the usual 1 bit - but in the first case pixel data bits are read 'progressively' and in the second they're read in pairs:

256x192 res: (Bit 7 + Bit 6)   (Bit 6+Bit 5)   (Bit 5 + Bit 4)   (Bit 4 + Bit 3)  (Bit 3 + Bit 2) etc
128x192 res: (Bit 7 + Bit 6)   (Bit 5+Bit 4)   (Bit 3 + Bit 2)   (Bit 1 + Bit 0)

Normally, this pixel data would be 1 or 0 indicating ink or paper, the colours of which are defined in the associated attribute byte. In both these modes, the pixel data has 4 states: paper, ink 1, ink2 and ink 3. Paper is defined by the attribute byte in the usual way - bits 3 to 5 of the byte give the paper colour 0-7 and bit 6 indicates bright or not.  The ink colours ignore the bright bit (bit 6) and instead, inks 1, 2 and 3 are all the colour 0 to 7 as defined by bits 0 to 2 of the attribute byte but their intensity differs:

00 - Paper (colour 0-7, bright 0 or 1)

01 - Ink (colour 0-7, brightness intensity 1)

10 - Ink (colour 0-7, brightness intensity 2)

11 - Ink (colour 0-7, brightness intensity 3)

This isn't quite how the C64 chooses the colours, but it's sufficient for this experiment.

In short, the first method produces a sort of "anti-alias" effect, and the second is similar to the Commodore's "rectangular pixel" mode. Whilst some spectrum owners laughed at the blockiness of the Commodore mode, there's no denying that in the right application and with a little bit of thought, it can produce some great results.

The following pictures show these modes in action on Prism. The images were basically chosen at random to show the effect, rather than being selected to showcase it....

"Antialias" or "progressive" 256x192 4 colour-per cell mode

Glorious Chunk-o-vision! 128x192 4 colour-per-cell mode

X-Out in Chunk-o-vision

Mr Heli's scoreboard in chunk-o-vision.
More or less readable even though the resolution's halved 

X-Out in-game Chunk-o-vision. Not too bad if you squint.
(apologies for the bad picture but you get the idea)

Mr Heli in-game Chunk-o-vision
It looks a little better when it's all moving

This is all early stuff anyway - future experiments may include centring the screen and making the pixels square again so it's less chunky. I'll also experiment with different ways of deriving the ink colours - currently its 3 intensities of the same base colour... The C64 has registers for selecting the other two inks. I could also try making the new 2 colours being blends of the ink and paper. Hmmm.

Refactoring complete

For the last couple of months I've been doing some major refactoring of Prism's glue logic, data bus mux, MMU and SRAM/flash memory control subsystem. This has been a heck of a lot of work for very little in the way of new features - however it's reduced the delay on a lot of signals which means that hopefully, with a little tweaking, Prism should be able to run stable at faster CPU speeds.


The new features added during this time are minimal but potentially useful:

1. Spectrum +2A/+3 special memory modes added. Not much software that I'm aware of uses this "CP/M" or "all RAM" memory configuration - except CP/M of course and John Elliott's wonderful ZxZvm (which lets you play various Infocom adventures like Zork and Hitchiker's Guide to the Glalaxy on the Spectrum). A number of people, including me, have also written utilities to run ROM images (like the Interface 1 ROM cartridges) using this memory configuration.
2. A selectable "Video RAM Aperture". Select between VRAM being accessible by the CPU at memory addresses 0x4000 - 0x5AFF (default) or VRAM being the entire 16K between 0x4000 and 0x7FFF.  The advantages of the default mode are that the system variables, printer buffer and the beginning of BASIC don't get stored in video memory and so allow the user to use video modes which use more VRAM than the standard Spectrum screen mode from BASIC without crashing (careful use of the "planar write mask" lets you write to other parts of VRAM). The disadvantage of the default mode is that software which uses certain Timex screen modes expect VRAM to be at 0x4000 - 0x5AFF and 0x6000 - 0x7AFF. So both modes have their uses. If using SE Basic in double-width mode for example, you will need to switch to the 16K VRAM aperture. 

So just a quick update despite the fact I've just finished a bucketload of work (and still have a metric shitload of testing and tweaking to do!). I'll leave you with an "actual Prism screenshot!!!" teaser from when I was testing the VRAM aperture - a 16 colour, no colour clash image displayed using the 4-plane planar mode:

Easter Update

So yet again I've managed to go a couple of months without updating the Prism blog. Mister Polo poked me again, so here we go. In my last update I listed a number of things that I'd be working on this year. I'm happy to say that a number of them have already been successfully achieved.

Firstly, the MMU (memory control functionality) has been rewritten to make it easier to modify in future. It also now handles all memory as 8K pages instead of 16K pages which means that I could add the Timex/Spectrum SE/Chloe 280SE memory paging model.  The Spectrum 128/Pentagon memory paging model still works exactly as expected. 

Secondly, I've added in support for the Timex/Spectrum SE/Chloe 280SE screen modes. The shadow screens that the Spectrum SE and Chloe has were already implemented as Prism implements it's screen selection in the same way. Likewise, the Timex "Hi-Color" mode is the same as Prism's. The Timex/SE/Chloe 512x192 mode is different to Prism's however - where Prism's is full colour and is basically screen 0 and screen 1 side-by-side, the Timex/SE/Chloe mode is monochrome and interlaces alternate sets of 8 pixels.  This screen mode is used in SE Basic's 80 column mode, which is the main reason I implemented it (Prism's 512x192 mode is better!)

Here's a video of Prism running Andrew Owen's (Chloe) MMUtest program:

To make my life easier, I wrote a small menu program which auto-loads from SD card when Prism boots. It lets me switch between different configurations - ZX Basic with 512 or 48K, SE Basic, the ZX81 emulator etc. It also shows off 256 colour mode - though as you can see the default palette has a number of blacks and whites at the moment!

I also fixed a bug in the T80 soft CPU core where incorrect flag behaviour was observed following an LD A,R or LD A,I instruction. This fix was based on one done by the Speccy2010 team. This finally fixes Midnight Resistance, Greeen Beret, Hypersports, Gutz, King's Valley and a number of other things. After that, I was on a roll with getting games working so I also updated the floating bus emulation so now Sidewize works too (albeit with flickering sprites due to the timing diferences between Prism and a real Spectrum).

Finally, after all this time I've actually gotten around to adding support for the "flash" attribute in standard attribute decoding mode! The Manic Miner loading screen works properly for the first time!

As a bonus to make up for so long without an update, the following three pictures are a teaser of something I'm working on (and definitely not an April fool - that was over a week ago). What could this be the first stirrings of I wonder?