TheBackShed.com

Forum Index : Microcontroller and PC projects : Colour Modes

Author

Message

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3194

Posted: 01:50pm 01 Jun 2012

Copy link to clipboard

Print this post

Another new topic from the colour logo discussion (why not, they are easy enough to start)...

Nick said

Geoffg said I thought of colour coding the text for the full screen editor but then I realised that the editor needs as much memory as it can get. As a result the editor now switches to monochrome when it loads (this frees up the memory) and then on exit switches back to whatever colour mode the user had set (there are four modes; monochrome, 2-bit colour, 3-bit and 240x216 3-bit).

I could colour code just straight LISTings on the screen but I am not sure that people use LIST much now that the full screen editor is available. Another factor is that the colour coding would only work if the MM was in a 3-bit colour mode.
Geoff

I'm a bit confused. I thought 2-bit and monochrome are essentially the same (monochrome meaning 1 colour from the Greek words mono=one chrome=colour).

Is there even a need for monochrome/2-bit? Apart from memory usage, MMBasic programs not written for colour should be oblivious to the different mapping. Unless colour commands are used, the default colours should be Black and White anyway.

Also, doesn't the larger 100 pin Pic32 have more memory?

Maybe we only need 2 modes... 480x432x8(colors) and 240x216x8(colours).

240x216 would still be suitable for most applications while consuming half the memory of the 480x432. And I think colour would be the desired mode to work in when you consider that every VGA monitor connected to the Maximite is colour.

I can see that the editor could get in the way though. Shame.

1-bit colour (one bit per pixel) = one colour (monochrome)
2-bit colour (two bits per pixel) = four colours
3-bit colour (three bit per pixel) = eight colours

The more bits use up more memory but eight colours still leaves a lot. Monochrome and 240x216 uses the same amount of memory for the video as the mono Maximite running 3.x does.

> Also, doesn't the larger 100 pin Pic32 have more memory?
Nop, it just has more I/O pins.

This is what the modes look like at this time (this could easily change as development progresses). The colours look beautiful on the screen, it is a pity that they have lost something in this image:

Note that when you change modes the whole screen changes, this demo was fudged with the screen in MODE 3

Geoff

Geoff Graham - http://geoffg.net

Nick

Guru

Joined: 09/06/2011
Location: Australia
Posts: 512

Posted: 01:56pm 01 Jun 2012

Copy link to clipboard

Print this post

So, does that mean...

1 bit colour = 8 displayed pixels per byte
2 bit colour = 4 displayed pixels per byte
3 bit colour = 2 displayed pixels per byte + 1 unused bit

Gizmo

Admin Group

Joined: 05/06/2004
Location: Australia
Posts: 5078

Posted: 01:59pm 01 Jun 2012

Copy link to clipboard

Print this post

Geoffg said Another new topic from the colour logo discussion (why not, they are easy enough to start)...

Yeah start as many as you like Geoff, if its a new topic users can fee free to start a new thread.

The bad image quality, the forum resizes JPG's down to 500 pixels to save bandwidth. If you save as a GIF and it will resize to 1000 pixels wide, but only if the image is bigger than 1000 pixels. GIF's are better suited to images with detail, like circuits, code, etc, and less than 256 colours.

Glenn

The best time to plant a tree was twenty years ago, the second best time is right now.
JAQ

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3194

Posted: 02:13pm 01 Jun 2012

Copy link to clipboard

Print this post

Nick said So, does that mean...
1 bit colour = 8 displayed pixels per byte
2 bit colour = 4 displayed pixels per byte
3 bit colour = 2 displayed pixels per byte + 1 unused bit

No, each colour has its own memory area (25920 bytes each in 480x432 pixel modes) so there is no wasted memory. You can dynamically switch modes as a program is running and as you do that memory will be automatically allocated or freed to accommodate the number of colours dictated by the mode.

Geoff Graham - http://geoffg.net

Nick

Guru

Joined: 09/06/2011
Location: Australia
Posts: 512

Posted: 02:19pm 01 Jun 2012

Copy link to clipboard

Print this post

So 2 maps? One for the pixel information (8 pixels per byte?) and another color map area?
Edited by Nick 2012-06-03

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3194

Posted: 02:30pm 01 Jun 2012

Copy link to clipboard

Print this post

Gizmo said GIF's are better suited to images with detail, like circuits, code, etc, and less than 256 colours

Thanks, hopefully this will look better...

Remember that this is a work in progress, anything can change.

Geoff

Geoff Graham - http://geoffg.net

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3194

Posted: 02:36pm 01 Jun 2012

Copy link to clipboard

Print this post

Nick said So 2 maps? One for the pixel information (8 pixels per byte?) and another color map area?

No, one "map" for each colour (assuming a "map" means the memory for each colour). Each colour has its own memory area and SPI driver and stream of pixels. They are independent of each other but because each stream of pixels is clocked identically they combine on the screen into eight colours.

Geoff

Geoff Graham - http://geoffg.net

Nick

Guru

Joined: 09/06/2011
Location: Australia
Posts: 512

Posted: 03:19pm 01 Jun 2012

Copy link to clipboard

Print this post

Ahhh! Shades of the Lynx Computer from the mid 80's. It too had a seperate map for each RGB color.

I can see how this slows things down a bit.

Reminiscent of the Amiga and its problem with multiple bit planes. The more bit planes (higher colour mode), the slower it got because of the requirement to do multiple write to set a colour.

The lack of a "chunky" graphics mode dogged it.

We are only talking 8 colours and 3 planes and the PIC32 is faster than the 7.xxMhz 68000 that the Amiga had so it should be ok.

So getting back on track... We can't have coloured text in the Editor because of this memory overhead.

Oh well, was a nice feature I thought. I'm just trying to help with suggestions for making the Maximite 2 the most it could be and make it stand out from the crowd.

Nick

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3194

Posted: 04:38pm 01 Jun 2012

Copy link to clipboard

Print this post

Nick said Oh well, was a nice feature I thought. I'm just trying to help with suggestions for making the Maximite 2 the most it could be and make it stand out from the crowd.

Much appreciated.

Geoff

Geoff Graham - http://geoffg.net

JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 3801

Posted: 11:27pm 01 Jun 2012

Copy link to clipboard

Print this post

RAM / video memory in short supply... What's the cheapest way to get more? A video chip? More RAM? A 2nd PIC32? A PIC32MXnnn that Microchip haven't yet released? Any other ideas?

John

Xiongmao

Regular Member

Joined: 25/08/2011
Location: Australia
Posts: 48

Posted: 12:04am 02 Jun 2012

Copy link to clipboard

Print this post

I looked at adding a graphics module that could be driven by the SPI port some time ago, but the forum consensus at the time was that it was getting away from the purpose/intent of the maximite. Microchip *might* come out with a '32 with more memory, but my bet would be a (nearly) RAMless chip with an external bus. A megabyte or more of SRAM should be a straight-forward proposition.

Alternately, go get a Raspberry Pi.

JohnS
Guru

Joined: 18/11/2011
Location: United Kingdom
Posts: 3801

Posted: 09:19pm 03 Jun 2012

Copy link to clipboard

Print this post

Among other snags the RPi has limited I/O, limited documentation (semi-closed), runs Linux (good for some things but rather unlike MMBasic!) and a form factor which is awkwardly small. Unlike a DM it also has fussy/limiting power supply needs.

John

Print this page

To reply to this topic, you need to log in.