Cluso and I were brainstorming how to do 8 bit VGA using 8 pins using a few additional logic chips. Are you thinking along the same lines? Or are you leapfrogging ahead using two props to do even more clever things?
Hmm - using two props synchronised and using existing color drivers, could you increase the color depth from 2 bits per color to 4 bits?
So I'm close, and I've got a few ideas for re-syncing once they're both up and running. the issue is the hub-ram round robin needs re-syncing.
There must be some cunning ways to synch two props together. That has my brain ticking away...
Baggers has almost been bursting wanting to show this off
Basically each Prop renders alternate scanlines so in effect you have 64K of video memory.
This particular example is 256x192 resolution at 6 bit colour depth (soon to be increased to 8 bit)
I basically used two protoboards with a 100MHz Oscillator and a clock buffer to drive both Propellers.
Here is another example of what is possible, this picture is 320x200 6 bit.
Ok, so I'm used to thinking of color in terms of 160x120 which is 19200. What you are doing is going to 320x200 which is 64000. 2^16 is 65536 so this still leaves a little bit at the top of hub ram if you need it for other things?
So where is this heading - a dual prop dedicated graphics driver?
Can I think outside the square even more? If you can synch propellers for video, let's say you had 200 propellers, each devoted to a line? That means each propeller has plenty of time in between each line to read from external ram. Say the external ram had a read time of 55ns and you unrolled the read code in a cog so it is as fast as possible. Now decrease the number of props to 100. Still easily enough time for each prop. I wonder where the crossover point occurs where there is not enough time to read a line? Could it be 8 props? Or even 4?
Way cool. And using only hub mem. I am impressed, I do not use hub mem at all in my multi Prop video, because I can not get the hub access to synchronize between multiple Props. I am quite impressed.
Cheers davidsaunders it's thanks to the prop being deterministic that it's possible in the first place
Dr_Acula yeah, it's very possible to add more props, because of the nature of how I'm doing it, you could if you wanted you could have 480 props, each doing their own scanline!
Also, don't forget, you wouldn't need to add the expense of add sram to each prop as each would need less
For example 4 props would be 128KB each doing a scan line every 4, would also give you twice the draw time this Duo has, and as you can see it can draw a LOT!
Re/ hub sync - I had the same issue with my single cog hirez VGA text drivers, and kuroneko found a way to force hub/waitvid issue and sent me a patch - check any of the drivers for the code.
Hi guys,
Thought I'd give you an update, on what I've been working on.
I was looking at how everyone has been trying to increase the 8bit resolutions for prop, and all solutions have been trying with either SRAM or SDRAM.
And decided there needs to be another way, as filling the vram seems to be an issue that people are having.
So wanted to try and come up with a solution.
My thinking behind this method is the fact that the Prop's main power, is the fact it has 8 cogs, and all can access hub-ram.
So I started wondering if two props could do it.
The answer, well yes, they can!
But there are a few issues along the way, yes, they are deterministic, and both running off the same clock, so should be perfectly in sync, but no.
the Bootup is internal RC timing, so not as stable as I'd like it to be.
So I'm close, and I've got a few ideas for re-syncing once they're both up and running. the issue is the hub-ram round robin needs re-syncing.
Anyway, here's a quick demo of where it's at
the Rainbow Islands image Coley posted is the 320x200 bitmap image, the problem with this is it's 64000 bytes, so fills most of the 2 props, but means the renderers can be used for poly drawing etc, so could perform some amazing fill rates!
Re/ hub sync - I had the same issue with my single cog hirez VGA text drivers, and kuroneko found a way to force hub/waitvid issue and sent me a patch - check any of the drivers for the code.
For syncing the video...
I am wondering if the HS timing could be used to sync the cogs. By this I mean, for a scanline, a cog will be ending the current scanline and starts the HS, but it is only held for 2/3 of the time. The next scanline cog (maybe on another prop) is waiting in a "waitpxx" for the HS as a cue to begin it's scanline. It sees this and asserts the HS so that it effectively controls the end of the HS and begins the scan. At the end of its scanline, it starts HS and holds for 2/3 of the time, waiting effectively for the next cog to take over.
This would mean that the HS may vary by a couple of clock widths. This should not matter as it is a syncing signal, and the timing "should" begin in the monitor at the end of the HS.
I am not certain this would work, but it seems reasonable and maybe simpler than trying to sync the cogs between props.
We are already doing something similar with await instruction, the problem seems to be that hub timing is at differing positions relative to each propeller.
So we need to sync the cog that has the corresponding hub access position, at least that's what Baggers tells me
Comments
:thumb:
Is that a TV or VGA?
And what is the color depth?
it's VGA at the mo! and 6bit, bit will be 8bit once the tech is fully working ;D
Hmm - using two props synchronised and using existing color drivers, could you increase the color depth from 2 bits per color to 4 bits?
There must be some cunning ways to synch two props together. That has my brain ticking away...
Basically each Prop renders alternate scanlines so in effect you have 64K of video memory.
This particular example is 256x192 resolution at 6 bit colour depth (soon to be increased to 8 bit)
I basically used two protoboards with a 100MHz Oscillator and a clock buffer to drive both Propellers.
Here is another example of what is possible, this picture is 320x200 6 bit.
Regards,
Coley
we are looking at using 10 pins for VGA, we've got plenty of i/o for what we are planning......
Ok, so I'm used to thinking of color in terms of 160x120 which is 19200. What you are doing is going to 320x200 which is 64000. 2^16 is 65536 so this still leaves a little bit at the top of hub ram if you need it for other things?
So where is this heading - a dual prop dedicated graphics driver?
Can I think outside the square even more? If you can synch propellers for video, let's say you had 200 propellers, each devoted to a line? That means each propeller has plenty of time in between each line to read from external ram. Say the external ram had a read time of 55ns and you unrolled the read code in a cog so it is as fast as possible. Now decrease the number of props to 100. Still easily enough time for each prop. I wonder where the crossover point occurs where there is not enough time to read a line? Could it be 8 props? Or even 4?
Dr_Acula
Also, don't forget, you wouldn't need to add the expense of add sram to each prop as each would need less
For example 4 props would be 128KB each doing a scan line every 4, would also give you twice the draw time this Duo has, and as you can see it can draw a LOT!
VERY VERY VERY cool!
Re/ hub sync - I had the same issue with my single cog hirez VGA text drivers, and kuroneko found a way to force hub/waitvid issue and sent me a patch - check any of the drivers for the code.
80 column driver thread
Cheers Bill
Yeah I'll have a look at his sync code, as I regard him as the man in the know when it comes to the timers etc.
I knew mutli-propellers was the correct answer here. This is starting to look like a three-propeller system.
OBC
It will hopefully be part of a new console Coley is designing
We'll keep you posted!
Cheers jazzed!
I am wondering if the HS timing could be used to sync the cogs. By this I mean, for a scanline, a cog will be ending the current scanline and starts the HS, but it is only held for 2/3 of the time. The next scanline cog (maybe on another prop) is waiting in a "waitpxx" for the HS as a cue to begin it's scanline. It sees this and asserts the HS so that it effectively controls the end of the HS and begins the scan. At the end of its scanline, it starts HS and holds for 2/3 of the time, waiting effectively for the next cog to take over.
This would mean that the HS may vary by a couple of clock widths. This should not matter as it is a syncing signal, and the timing "should" begin in the monitor at the end of the HS.
I am not certain this would work, but it seems reasonable and maybe simpler than trying to sync the cogs between props.
So we need to sync the cog that has the corresponding hub access position, at least that's what Baggers tells me