 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : 16 colour CMM?
Page 1 of 3   |
|||||
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9307 |
First off, please don't get me wrong - I am really happy with the 8 colour MM, so this thread is more theoretical then it is practical. In the event that Microchip were to release a PC32 with more RAM, would it be possible to have a CMM with 16 colours? It is my understanding, that the video memory is what is gobbling up a good chunk of the RAM on the current PIC32 and CMM model. I don't know exactly the in's and out's of the video processing, although I understand the basics of how it is done, based on the SC articles. Am I correct in my understanding, that the more colours you add, the more RAM is needed to keep track of said colours? I am pretty sure that resolution is a big thing with RAM use. Essentially, the higher the screen resolution, the more RAM is needed for video memory and especially to refresh the current video frame in RAM. Also, the greater the resolution in something like the MM, the faster I would expect the MCU would have to be clocked to keep up with being able to refresh the higher resolution screen in the same time period. Normally in PC's etc, this is done using VRAM - Video RAM, which is special RAM which is very fast and used to refresh the screen etc. But this is more in the lines of GPU's in PC's, so lets get back to that MM!!! 
Assuming more RAM - normally the next release of any chip or controller like this, the RAM doubles, so I would expect the next release of the PIC32 to have 1MB of RAM, so would that make 16 colours possible? AGain, please let me be very clear and state that I have no problems at all with the 8 colours we have now, and I am really happy with that. This thread is really just to toss the idea about, rather then to ask for a new feature or to ask "When can we have 16-colour", as I know that is impractical with the current hardware. Smoke makes things work. When the smoke gets out, it stops! |
||||
| JohnS Guru  Joined: 18/11/2011 Location: United KingdomPosts: 3802 |
Current PIC32 has 128KB RAM. Little chance for 1MB. All RAM is on-chip and the chips do NOT bring out an external memory bus. Mind you, they ARE very cheap and capable. Yes more colours means more RAM. Twice colours, twice RAM. Screen is drawn straight from RAM via DMA and it's about flat out so double is no chance I think. You'd need (say) a 160MHz PIC32 as well as lots more RAM. Don't hold your breath! (But I'd love Microchip to surprise me.) Clearly a whole pile of extra circuitry could be used: separate video RAM, separate video refresh etc but board area and cost would go up and so would MMBasic complexity. Bigger RAM also means slower MMBasic (doing more). You could look at MMBasic code and Lucio Di Jasio's book "Exploring the PIC32" to see what's possible. There are alternatives such as A13 Olinuxino, RPi or the like but they don't have MMBasic. John |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9307 |
Interesting - thanks for posting. Yep, pretty much jives with what I thought. I think we are pushing the PIC32 as hard as you can in the MM environment!!!
Still, love to hear other discussion on this. As I mentioned in the original post, not expecting anything like 16 colour anytime soon - just a thread for the purpose of food for thought. 
EDIT: Raspberry Pi has Python by default... Smoke makes things work. When the smoke gets out, it stops! |
||||
Juri74 Senior Member  Joined: 06/02/2012 Location: ItalyPosts: 162 |
ehm sir.. theoretically not, to double colors only 1 bit plane is needed.. of course the other 16 colors are a copy of the first 16 but half brightness and 1 signal pin is needed. maximite color computer use 1N4148 diodes to generate a 0,7v analog signal for RGB.. using 1N5819 schottky diodes will drop the signal to about 0,35v. theese diodes should be placed in parallel to the others and controlled with a signal from the maximite.. with this trick 16 colors are not so impossible to obitain (however real colors are 15 because black and dark black are the same color LOL) with this trick and doubling the video ram usage will bring here theoretically 64 colours... Juri |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9307 |
Wow. Very interesting. Keep the "Food-for-thought" posts coming, guys. 
Again - not suggesting this can actually be done ON THE CURRENT HARDWARE PLATFORM, but this makes for some very interesting reading... Smoke makes things work. When the smoke gets out, it stops! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3194 |
This is a great subject so please don't stop just because I have chimed in... It would be absolutely brilliant if Microchip came out with a PIC32 with just double the speed, flash and RAM. If they did I for one would be on to it in seconds. But (despite rumours that have been circulating) I am not sure that they will do so any time soon. One reason is that, in most applications to effectively use all that extra capacity you would need to use an operating system (Linux ?) and the PIC32 does not have the memory management and other features for that (although they could be added). Another reason is that the PIC32 already easily beats the competition in the market for a cheap and easy to use chip with huge resources in a package that can be soldered by humans. With little competition there is little incentive to push the boundaries. I did consider using this chip in a Maximite MK III (link) but, by the time you added a second high density SMD chip and the complex software required to support it, it became very expensive, especially as a kit. Another option is the DuinoMite eMega from Olimex and I have it on my ToDo list for a port of MMBasic but it is even more complex with Ethernet, flash memory, etc so it would take a monster effort to support. Both of these options move away from the small, simple, single chip computer that the Maximite started with. The answer would be for Microchip to come out with the next generation of the PIC32 and I hope that it will not be too long. Geoff Geoff Graham - http://geoffg.net |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9307 |
Excellent - thanks very much for your comments, Geoff.
I feel it necessary to keep hammering home here, that I am not unhappy with the 8 colour MM - I think it is a great little unit - I am just throwing ideas around.
You do qualify your remarks, Geoff. If we needed to start building an OS to run the system, that is indeed getting away from the concept by just a tad.
The Raspberry Pi already has gone down this road(and I have one of these too to play with), but it is a Linux based toy, which is fine for those that need the power, so perhaps if you need more then 8 colours, then you need to be looking at the RP - perhaps... Anyhoo, keep the comments coming. Interesting, interesting, interesting. Smoke makes things work. When the smoke gets out, it stops! |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 3802 |
Juri74 - you're right, sorry. Geoff - The PIC32 does have virtual memory/etc features - which retrobsd uses :) (Have another read of the Microchip docs lol) Doesn't get us any more RAM until Microchip make an 895 or 995 or whatever. (Seems likely they will. But when...) John |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
I don't see Microchip adding video capabilities, they might add more ram, like 256k or even a 512k. Using that ram for programming is a better use then for graphics. You want fancy graphics, use a extra chip. The pic32 has a 16 bits parallel port that is used to control LCD's directly. Memory problem is solved with external memory chips. They have a whole graphics library for it too and although not used myself i have seen it work and it looks great. It is also in line with being 'embedded'. Their market is not 'all purpose'. Another way of producing more colors with not too much memory is using text mode and a character generator or 'tiles'. In text mode 24 lines with 80 needs 1920 bytes for the whole screen. Add another 1920 bytes and you have 16 foreground and 16 background colors or if using the available bits different you can have 256 colors. With tiles you could layout your screen to mix text and graphics. Each tile could be a 16x16 matrix with individual pixels. Anther tile could hold 2x2 characters. Memory usage would depend on how many tiles are used for graphics. This is all based on old tricks in the past, i luckily did not have to program that as it is certainly not an easy task. You could use 2 pic32 chips and use one for only generating video, you would then use commands send over I2C to control the screen. You would have a bunch of extra pins available too. :) There are a few videos on youtube that show 15 or more colours even with a pic18. Like this or this or the best this or use a gameduino it is open source. Microblocks. Build with logic. |
||||
Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
16 colours would be nice. The current CMM uses 3 "monochrome" bitplanes, each one assigned to Red, Green and Blue (RGB). Basically, a 1 value means pixel on and a 0 value means pixel off. These 3 bit planes are output simulteneouisly and you get the 8 colours (digital 8). The only thing I can think of, and I'm not sure if this is possible or if there is the capacity is to add another bit plane that represents intensity. This would mean that a 1 is full intensity and a 0 would be half. This would control the intensity of all the other 3 RGB bitplanes and you would get 16 colours. As I said, I'm not sure if we have an SPI (?) channel spare or one that can be re-assigned for this bitplane. An extra bitplane eats up more memory so this could be used in the 240x216 mode where the bitplanes are half the size. Nick |
||||
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
I seem to recall that SPI channels are all used up. However there are possibly other ways of doing it. We have a surplus of "genius" in this forum and someone is bound to come up with a good idea. As Juri noted, the total colours is 15 not 16 as half black is the same as full black when black is all other colours switched off. The meaning of the extra bit you refer to would be better inverted so that an absence of the bit gives you full colour and not get stuck in a half colour world. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
The only one that might be available is the one used for an SD card. If i put on my hacker hat. :) The SD card has a CARD ENABLE on pin 38 (A1). If Pin 50 (F5) was connected to some simple circuitry (a diode or two) it can be used for the 4th bit plane. This circuitry would have to be enabled by the inverted level of pin 38 (NOT Card enable). In software you could then use this extra SPI channel, exactly the same as the others. Maybe one more pin is needed to sync it with the Horizontal sync for the VGA. Geoff is the one who really knows. Possible? Microblocks. Build with logic. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3194 |
It would be possible to use the 4th SPI to control an intensity plane (giving 16 colours) but that would have two negatives: - The video would flicker everytime you accessed the SD card (not too serious). - The extra RAM required would leave very little for BASIC programs (about 12K) meaning that you could not write a usefull progran on it. Geoff Geoff Graham - http://geoffg.net |
||||
| cosmic frog Senior Member Joined: 09/02/2012 Location: United KingdomPosts: 284 |
Because of the way the colour is produced through 3 pins (RGB) would it be possible to connect these to the Scart/Péritel/Euroconector socket on a TV or is the timing different. I know there are seperate red,green,blue and sync inputs, has anyone tried this? |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9307 |
I've not tried that myself, but my understanding is that the RGB inputs on a SCART, are composite video signals - component video. Same thing as the RGB three-core RCA leads used to connect DVD players to TV sets with RCA inputs. Each one is a analog composite signal, not a digital one. I may well be wrong. Smoke makes things work. When the smoke gets out, it stops! |
||||
djuqa Guru Joined: 23/11/2011 Location: AustraliaPosts: 447 |
Talk about a Rare (and OLD) standard. The SCART RGB pins are indeed Composite signals Rather than VGA style signals SCART Pinout below Pin 1 Audio output (right) Pin 2 Audio input (right) Pin 3 Audio output (left/mono) Pin 4 Audio ground Pin 5 RGB Blue ground (pin 7 ground) Pin 6 Audio input (left/mono) Pin 7 RGB Blue up S-Video C down[a] Component PB up {B} Pin 8 Status & Aspect Ratio up[c] 0–2 V → off 5–8 V → on/16:9 9.5–12 V → on/4:3 Pin 9 RGB Green ground (pin 11 ground) Pin 10 Clock / Data 2[d] Control bus (AV.link) Pin 11 RGB Green up Component Y up Pin 12 Reserved / Data 1[d] Pin 13 RGB Red ground (pin 15 ground) Pin 14 Usually Data signal ground (pins 8, 10 & 12 ground) Pin 15 RGB Red up S-Video C up Component PR up Pin 16 Blanking signal up RGB-selection voltage up 0–0.4 V → composite 1–3 V → RGB Pin 17 Composite video ground (pin 19 & 20 ground) Pin 18 Blanking signal ground (pin 16 ground) Pin 19 Composite video output S-Video Y output Pin 20 Composite video input S-Video Y input Pin 21 Shell/Chassis[e] ^ a rarely supported. ^ b non-standard extension. ^ c from STB to VCR when used for unattended recording ^ d protocol not standardised, e.g. D²B. ^ e This pin is part of the shell/surround of the male connector. It is often connected to the overall screen in a cheap cable. In equipment, Pin 21 should be connected separately to the chassis, but often it is merely connected to all the other ground pins. output/input denotes symmetrical links up/down denotes links to/from the TV set VK4MU MicroController Units |
||||
| Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
Is it 12K for another 480x432 plane? If so, is that 6K for a 240x216 plane? This would be another mode for games, 16 colours but less 6K RAM. Nick |
||||
| Juri74 Senior Member Joined: 06/02/2012 Location: ItalyPosts: 162 |
hello Geoff, as you says the flickering it's not so serious about the ram required, i agree with Nick that the 16 colours mode should be available only in 240x216 graphic mode (let's say a mode 5).. the fourth plane should occupy about 6k of ram with a total of about 76k available for programs... that modification would be great! |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
With 4 bits used for video would using the pmp peripheral not become possible (Maximite Mark III?), it supports dma also, but i am not sure if the required speed is within the range. That would be incredible because it would free up all the serial peripherals. Microblocks. Build with logic. |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1109 |
The calculations for RAM memory/graphics requirements are quite simple. Memory (bytes) = horizontal res * vertical res * bits per pixel / 8 For a colour Maximite in mode 3, that gives 480*432*3/8 = 77760 bytes. Mode 4 is half the resolution, needing one quarter the RAM. 640*400*8 colours would need 96000 bytes The Maximite uses SPI channels to generate the pixel streams for the three colour channels. The characteristics of the SPI channels limit the available resolutions and result in some odd quirks such as Geoff's constant fight to keep the SPI channels synchronized. But there are some other possible ways to generate the video signals. One nice simple way is to chuck a single byte out an 8 bit port - an easy job for DMA and possibly much easier to give flexible timing for arbitrary resolution. 8 bit colour means 256 (or more likely 255) colours per pixel with some odd RGB mapping. Of course memory requirements rise dramatically. 320*200 resolution needs 64000 bytes. I was pondering whether an STM32F4Discovery board (quite low cost at Mouser, for example) would make a good platform to run MMBasic on. I can't imagine that Maximite users really care exactly what microcontroller the device is based on. Visit Vegipete's *Mite Library for cool programs. |
||||
| Page 1 of 3 |
|||||
 Print this page |
