256 Colour Mode

[Trebmint]

Having a while ago seen that there is a Spectrum Emulator that runs games in 256 colours. Obviously every game needs painstaking work to upgrade them into this status, and therefore only a dozen games or so have eve been converted.
However it did get me wondering given that the CPC isnt a horrible 2 colour attribute mess, how this would be done on tne CPC and the most likely answer is that its a relatively easy process to upgrade our classic games to 256 colour emulated loveliness (Okay that is putting aside the argument of whether you should or not)
To my mind how this would work is to effectively have two identical memories 64k/128k and process them as if they are different z80's. If the data was the same it would produce an identical memory map. However if the graphics data only was altered (and yeah I know some games have compression) you'd have 2 sets of 4 bits data thats 16 colours*16 =256 colour palette in Mode 0, and 4*4=16 colour palette in Mode 1. Doesn't that make you drool???
Surely this would be fairly easily achievable in one of the emulators, and games could be converted with relative ease?? Far far easier than the spectrum 256 emulator anyway.
Okay thats all. Now please tell me its impossible and stupid 

[ivarf]

Do we need it? The machine we have is far more capable graphically than the Spectrum and we have the CPC+ as well.  Or are you considering it for SymbOS? Maybe I am thinking inside the box, my first thought is 160x200 only.


But 320x200 in 64 000 onscreen colours and 640x200 in onscreen 65536 colours would be very nice, especially if emulated version isn't slowed down due to the extra colour. 16-bit palette with 65536 colours. I don't know anything about how easy this would be to do.

[rexbeng]

Uhm, I really do prefer the CPC's current graphics capabilities, thank you very much 


Seriously now, a fake 256 colors palette running only on emulators wouldn't be "CPC" anymore.


rb

[andycadley]

To my mind how this would work is to effectively have two identical memories 64k/128k and process them as if they are different z80's. If the data was the same it would produce an identical memory map. However if the graphics data only was altered (and yeah I know some games have compression) you'd have 2 sets of 4 bits data thats 16 colours*16 =256 colour palette in Mode 0, and 4*4=16 colour palette in Mode 1. Doesn't that make you drool???
Surely this would be fairly easily achievable in one of the emulators, and games could be converted with relative ease?? Far far easier than the spectrum 256 emulator anyway.
Okay thats all. Now please tell me its impossible and stupid 

That's almost exactly how those "256 colour" spectrum emulators work. So yes, it's possible. And no, it doesn't actually get an awful lot easier than doing the same on the Speccy, so I can't believe it'd be easier to work with. In fact the dynamic nature of the CPC's palette probably makes it a lot harder to do effectively that on the Spectrum where the pixel<->colour mapping is more direct.

[TotO]

I only regret to get a 16/27 colors palette instead of the "original" 16/64 colors that the Gate Array can handle through the unused bit5.
Probably for a cost reduction after it's design, by using low impedence instead of a 2R2G2B palette. (look like bright and dark CPC palette)

With a 16/512 or 16/4096 or 16/65536 colors on screen, you will look like a Amiga/ST/CPC+ and no more like a CPC.
With  a 256/512 or 256/4096 or 256/65536 colors on screen, you will look like a very very very slow arcade system...
You lose the CPC identity... Better to use another existing computer ?

[Sykobee (Briggsy)]

In the end it wouldn't be a CPC.


However I can see how you can use an emulator and a hacked game image to re-create a game with the original game logic but better graphics to run on a PC. In effect it would be a "Z80 runtime" for the software, with altered graphics and virtual graphics hardware.


Might as well create a Z80->C decompiler and then adapt the code to run with SDL and new graphics and audio.


As for the original CPC, we got 27 colours and we liked it. 64 would have been neat. 256 (3R,3G,2B) would have been sweet. However for a 256 colour mode you would have been limited to 80 pixels across the screen due to memory bandwidth limitations - and hacking some form of attributes on top of the display would not have been CPC-like at all.

[Bryce]

You're assuming that the screen area is still 16K. If you had 64K of video RAM, you just need to step the pixel clock and read more data per pixel. It's an emulator on a PC, it shouldn't be that difficult. You'd have to up the Z80s frequency though, to get the same refresh rate.

Bryce.

[MacDeath]

overclockx2 the CPC... CPU and Video... of course oyu need to customise the Video part (and many other stuffs) so it could handle 256colours (8bpp)


Video modes would becomes like on Atari ST (32k for a 320x200x16), the mode0 becomes a 160x200x256.


this would be a bit like the unlocked ASIC, so not compatible with older specification unless you lock the extra features.


The problem...
SamCoupé was also a Z80 based computer, with a 256x200x16 video mode (twice bpp as on CPC, yet less pixels so less pseudo-VRAM to handle) running at 6mhz and it was slowpoke.
Even Software animation based Atari ST could have a few problems to deal with sprites and scrolls (in soft) in 32K video mode 320x200x16... while being an 8mhz 16bit CPU.


So a 8mhz Z80 based CPC with 32K (x2) video would be somewhat  like a mundane CPC... provided the RAM/ROM and the I/O hasten the speed up too.


Then comes the fullscreen/overscan...


The usual 16K screen on CPC can become an actuall 24K screen in overscan mode (somewhat using 32K)...
So this would go for a huge 64K RAM used as videoRAM (while the displayed field being actually 48K.


This leaves quite a few place for the CPU and would need to put a lot of bankswitchings in the process.


To be fair such machine should have 256K RAM at minimum... actually 512K and would need a lot of bankswitchs/RAM management effort (from the coder) because CPC use normal RAM as VRAM.




Another method would be to add a Character attribute system, quite like the one for ZX spectrum...
this would allow to put different palette in each character (8x8 mode1 equivalent, perhaps more based on the Mode2).


The more characters/smaller they are, the heavier it get, and gotta need it big to handle the overscan/full screen...


With this, you say you can choose between 16 different palettes...
So :


Mode0 + attributes = 160x200x16/16palettes so 256 colours on screen
Mode1 + attributes = 320x200x4/16 palettes (16x4 ) 64 colours on screen)
Mode2 + attributes = 640x200x2/16 palettes (16x2) = 32 colours on screen... like a Speccy on steroid concerning resolution.


Even though, the CPC could like being with a 6mhz Z80...


if you say the attributes are like 1byte per character...


a simple mode2 (1byte of pixels per 8 scanlines = 8x8 pixels) is 80x25 characters... 2000 bytes to handle.
Add more is full screen... less if you keep a sqaure ratio as for Mode1 (2 bytes of pixels per 8 scanlines)


the ideal would be to get such attributes to be modified, in size and number (sort of magnified)...




It would actually offer a kustomisable grid of horizontal and vertical "rasters" effect to a CPC/PLUS.
Totally usable graphically IMO.


Even  getting those in mode2... 1 byte of pixels per 4 scanlines, would be great too.


I don't despise Atrributes, juste that on Speccy you have too few colours per attributes to have this usable...
but a Mode1 + attributes would be a bit like the Nintendo Entertainment System tile matrix...


But CPC wasn't designed for this, and it is huge extra weight.
MSX1 or Thomson MO5/TO7 have 8x1 attributes... a 1bpp 320x200x2 + attributes mode like this (Thomson) weight 16k... the same as fore the normal 320x200x4 mode1 on CPC...


40x200 = 8000 attributes.
8K.


As I told, a CPC based attributed mode wouldn't need as many attributes...but still need to get those able to handle overscan zone/border zone.


On the other hand, far less need for traditionnal rater and split raster effects too with such Attribute matrix.
And would not be usable on CPC old palette (only 27 colours...) in mode0... even in mode1 you waste some colour slots.

As for the original CPC, we got 27 colours and we liked it.

a cleve use of the 5th bit would have been to put an intensity bit, as for those CGA/speccy...
So the CPC palette could have been like 27x2 = 54 colours... perhaps a bit less if black remains black and so on... would need fine tuning of the colours actually.


a slightly extra darker second palette... Black remains black (spectrum style).
like a -25% luma...
a 0 remains 0%, a 1 becomes 25% instead of 50%, a 2 becomes 75% instead of 100%.

we would get like 3 greys+black&White... 
the Greys would be like Black (0%), dark Grey (25%) Grey (50%), dark white (75%) and white (100%).




Also extra darker Blues or Red...
All intermediate colours (Orange, lavander and so on) in a darker tone too.
actually could have been the best palette ever.
Even better than a r2g2b2 EGA palette as it could get 3 greys, but less crossbreed colours (oranges and so on) and less greyish colours too.

[arnoldemu]

The enterprise has a 256 colour mode, where each byte is a colour value. (I think encoded as some bits for each r,g,b).
But then the pixels are even fatter than mode 0.

The plus did it quite well with it's extended palette.

if we wanted higher resolution, or more colours, look towards the aleste.
it clocks the pixels at a different rate (I think it's more overscanned too when it does it).
trouble is the cpu is too slow to write the data. so you need a faster cpu with less video contention.

[Bryce]

Just pondering here, but.... It should be possible to build a device that would connect to the expansion port and the RGB output, with a small page of RAM on it. If clocked in time with the pixel clock, it could switch in resistors to the RGB depending on the values in the RAM, this would increase the colours on a real CPC by at least a factor of 6. Adding further  resistor networks would increase the possible colours even more.

Bryce.

NO! I don't intend building this!

[arnoldemu]

Just pondering here, but.... It should be possible to build a device that would connect to the expansion port and the RGB output, with a small page of RAM on it. If clocked in time with the pixel clock, it could switch in resistors to the RGB depending on the values in the RAM, this would increase the colours on a real CPC by at least a factor of 6. Adding further  resistor networks would increase the possible colours even more.

Bryce.

NO! I don't intend building this!

Seen it done on the BBC micro but it has TTL outputs so the electronics are easier.

See here:
The Micro User - January 1990 - Vol 7 No 11 - Computing History


Possible on the cpc, but you'd need to hook into the r,g,b outputs to do the decode?

Update: Acorn Electron World: Magazine Scans: MICRO USER

[Bryce]

You'd need to connect to each of the RGB signals, but something more like this:

[attach=2]

In this case the bits for each pixel (in the new RAM), would allow 3 new levels of red decided by the values of Rx and Ry.

If G and B had the same setup you'd need 6 bits per pixel to add 3 new levels for each of the primary colours. This would also give you new colours in all the mixed colours too.

Bryce.

[TotO]

a clever use of the 5th bit would have been to put an intensity bit, as for those CGA/speccy [...] like a -25% luma... a 0 remains 0%, a 1 becomes 25% instead of 50%, a 2 becomes 75% instead of 100%.

Sure that is a clever way for doing something like the Amiga ECS does with the half-bright palette... But here, a "quarter-bright".

[MacDeath]

concerning the PLUS there may be a possibility to do it a bit the way the Apple //gs did...


Basically it was a 16 colour mode with some scanline attribute system.
But in a 320x200x16 mode... closer to Atari ST than Mode0... but Mode0 is nice too. Apple//gs was a 16bit computer anyway, the "65xx" like CPU was overclocked yet not as much as it could due to Apple being the jerks they always were.


Attributes being scanlines instead of characters... and enabled to switch between 16 palettes of 16 inks.


This can be done painfully with rasters interruptions routine for each scanline... the vertical resolution used is rarely more than 256 pixels (up to 272max perhaps ?).
Could have been a nice feature if really integrated into the ASIC IMO.
like having an intern RAM (quite like those HardSpriutes integrated RAMs)
So you simply enter/upload all those palette changes (could address each scanline, better if DMA I guess) instead of doing a Raster...


Not sure if really a gain though. But I guess it is as the 16 palettes are pre-set...
on the other hand normal raster could enable even more colours (16x256...) on screen but would also be possible with this Apple//gs styled attributed mode.


It was actually possible on this Apple//gs (a sweet machine IMO) : the CPU could assist the VGC  (Video Graphics Chip) so you could get this
320x200x16*200 palettes.

The problem with this sort of attribute is that it is still not really easy to do "vertical rasters" (split rasters ?) compared to "square" character attributes.

But for many applications/uses, you don't really bother the main CPU to get all those rasters zones.


While PLUS is somewhat helped on the Raster interrupts so it can do it, still it is a bit Software generated (CPU) and use RAM and routines too.

[Trebmint]

I was only suggesting this as an option for an emulator, not as actual hardware. However has anyone looked at the Raspberry Pi. $25 for a pc board fully able to a standalone cpc emulator, and perhaps with further modes so a CPC+++ perhaps??

[Bryce]

Yes, but if it can be done on an emulator, why not try to do it on real hardware too? Some people (like me) don't like emulators and only use real hardware.

A Raspberry Pi solution would never be a CPC+++. It would still be just a Raspberry Pi with an emulator running on it. Without a real Z80, it's not a CPC.

Bryce.

[Phi2x]

.

[Bryce]

Well if it doesn't exist, you're not really emulating are you?

But I agree, it's still pointless though.

Bryce.

[Trebmint]

Yes, but if it can be done on an emulator, why not try to do it on real hardware too? Some people (like me) don't like emulators and only use real hardware.

A Raspberry Pi solution would never be a CPC+++. It would still be just a Raspberry Pi with an emulator running on it. Without a real Z80, it's not a CPC.

Bryce.

I can think of numerous machines that have changed processors several times like the PC and the MAC, so Im not sure thats true totally. If you can find one part that remains from the original MAC to todays MAC I'd be suprised, though I know what you mean. But the likelihood is that within 15-20 years there will be little or no cpc hardware that still works as parts die. Surely a dedicated semi/hardware emulation within its own box and keyboard would be better than software only emulation on a PC or whatever. The PI just offers an extremely affordable way of achieving this IMHO
Call it what you will CPC+++ or something not CPC, it could still be a platform to play CPC games in a dedicated manner as the games were intended. The PI just offers an extremely affordable way of achieving this IMHO

[Bryce]

I can think of numerous machines that have changed processors several times like the PC and the MAC

And that's why the PC and the MAC are just another computer and don't have the following that a CPC has

Bryce.

[TotO]

It's why PC and Mac don't get a soul...

[arnoldemu]

Yes, but if it can be done on an emulator, why not try to do it on real hardware too? Some people (like me) don't like emulators and only use real hardware.

A Raspberry Pi solution would never be a CPC+++. It would still be just a Raspberry Pi with an emulator running on it. Without a real Z80, it's not a CPC.

Bryce.

And when I get my raspberry pi it will have my emu running on it

[Gryzor]

So, seeing as Bryce has already started designing the bit and we can expect a release within 2012, I just wanted to ask, what is meant by "a factor of 6", 6 additional colours (not likely), 6x or ^6?

[arnoldemu]

So, seeing as Bryce has already started designing the bit and we can expect a release within 2012, I just wanted to ask, what is meant by "a factor of 6", 6 additional colours (not likely), 6x or ^6?

yes I like the way Bryce says he's not going to do it, then ends up designing it and talking himself into doing it 

[Bryce]

That''s hardly a finished design! It's just an example of how you can manipulate the colours of an existing video system without having to do any major internal soldering etc.

And NO I'm still not building one. It's not even on my very long To-Do list

Edit: I do have a semi-finished design that uses the CPC to add subtitles / overlay graphics etc to an existing video source such as VHS / DVD (I kind of CPC Genlock of sorts), but that was just for me and has been on paper since the 90's and has still never got built. I doubt many people would actually want one.

Bryce.