SVGA High Color HW.
davidsaunders
Posts: 1,559
Here is a block diagram of the High Color Prop SVGA. Drivers will follow in short order (my current drivers would be useless to most as they are directly related to the MuAmi project and weird as a result). This has been thoroughly tested to work.
This works by allowing you to write to a rectangular frame buffer during the blanking periods, and generate incrementing addresses during the active period at a rate of 1 per pixel. You must bring Blank Out high during the blanking period, and you must generate a valid HSync and VSync. I have modified this a little (and tested), in that there is not a sprite memory in this, and there is not a small buffer for a color LUT.
Some notes:
1) The Prop2Prop lines are used for simple inter Prop communication and data transfer.
2) The 2 bit Prop select bus can be reduced to 1 bit as we do not need 4 props for this (that is needed in MuAmi).
3) for anything higher than 512x480 with 640x480 timing, the lower bits of the address must be provided by the video generator during output, in order to provide the needed speed.
4) The Blank Out line is also used to control the R/W on the SRAM (wired so that it is set to read while /OE on the 74HCT244s is low, and write otherwise).
5) It is possible to get 20MB/s transfers on the Prop2Prop bus, using multiple cogs (actually possible to reach 40MB/s but that is difficult), the same is true with writing to SRAM (and this is useful if you want to redraw the frame buffer completely for every frame).
6) This is usually interfaced to a Primary control Prop, in the MuAmi.
This works by allowing you to write to a rectangular frame buffer during the blanking periods, and generate incrementing addresses during the active period at a rate of 1 per pixel. You must bring Blank Out high during the blanking period, and you must generate a valid HSync and VSync. I have modified this a little (and tested), in that there is not a sprite memory in this, and there is not a small buffer for a color LUT.
Some notes:
1) The Prop2Prop lines are used for simple inter Prop communication and data transfer.
2) The 2 bit Prop select bus can be reduced to 1 bit as we do not need 4 props for this (that is needed in MuAmi).
3) for anything higher than 512x480 with 640x480 timing, the lower bits of the address must be provided by the video generator during output, in order to provide the needed speed.
4) The Blank Out line is also used to control the R/W on the SRAM (wired so that it is set to read while /OE on the 74HCT244s is low, and write otherwise).
5) It is possible to get 20MB/s transfers on the Prop2Prop bus, using multiple cogs (actually possible to reach 40MB/s but that is difficult), the same is true with writing to SRAM (and this is useful if you want to redraw the frame buffer completely for every frame).
6) This is usually interfaced to a Primary control Prop, in the MuAmi.
800 x 600 - 12K
Comments
Does Propeller read SRAM too?
Why do you need 2 Propellers/SRAM?
Two props are only needed because the SRAM has to be parallel, and there just are not enough pins on one Prop (unless you do not need the Prop2Prop bus and can live with 8BPP color, though I figure that most will use this as part of a larger design with more Props).
Being able to read the SRAM would be key for several Propeller applications such as XOR image manipulation.
I'm thinking a Propeller Platform footprint board might be a good starting point.
So multiplex Address low and address high, multiplex Data low and data high, add the needed control lines for this (I think 3 lines), add a separate line for SRAM R/W and drop the Prop2Prop bus.
Here is a single prop version using latches. To simplify drawing I only drew the latches once for both in and out, in practice you will need 4 latchs (Data in, Data out, Address in, Address out) and to use some logic to select the correct one against read/write line.
I should note I have not tested this one.
Also it would take a bit longer to redraw the entire screen this way.
I've been trying to think of the answer, but couldn't think of one.
What phone do you have?
A Waitvid can drive 8 addresses at a time with CTRA.
I suppose the other bits would be driven with "add outa, #$100".
Baggers what do you think of all this?
Sorry the problem is not the phone per se, it is that its camera is somehow broken (not sure what happened to cause it to behave as it does).
Thank you you have me thinking on some possible improvements to the MuAmi video. Probably still not single prop, though maybe easier coding for.
I think if it's doable it's going to be fantastic, but I can't see prop1 being fast enough to do it, the problem with the external sram display drivers is fill speed.
Not only that, using two props, you're going to need to let the second prop know what the first prop is telling the sram to do, to keep in sync, plus which one is running the 68K emulator, and does it have access to both sets of sram, if it doesn't how will it read the upper/lower bytes, cos if it's going through the second prop for comms it's gonna be way too slow.
That's my personal thinking on it.
I'd love to be proven wrong, and see this working though!
OT I'm beginning to think this whole external sram development for a display is the wrong approach, you remove all what is great about the prop. parallelism, it then comes down to one cog running the show, you might as well opt for an arm then!
HUB-RAM is your friend!
Yes, there are some difficulties in synchronization between the two props.
No I am not emulating a 68000 on the Prop 1 (ok I am playing with it in preparation for the prop II), I am using real 680x0 CPUs in the MuAmi, hence the need for a Prop2Prop bus.
This is only part of the peripheral HW for the MuAmi. MuAmi uses 5 Props to produce an AGA compatible though better chipset.
ok, now you're really confusing me, you've got a 68K, which would be using the ram, as you would expect, but you have the props wired up to the ram, which is wired to the dac?
And you have 5 props? can you elaborate a little more as you've lost me with what is doing what? cheers
why did you feel the need to modify my name in the Quote section from Baggers to Beggers?
Now because the the data originates from a frame buffer in system RAM that is separate, any bitwize operation can be doen befor it is written to the buffer shown. In order to have the entire thing work in a way that is faster than the original, it only actually updates half of the lines in one frame, making the effective real refresh rate 30fps (for a 60Hz display refresh).
Sorry about that I had miss typed it. I always type out the [qu0te="person"] and [/qu0te]
Ok, no worries about the typo
as for the prop between the 68k and sram props, how are you getting the address pins ( minimum 19 ) and data pins ( 32 pins ) from the 68K, sent to a second prop, then address the sram, read/write 32bit access, and get it back to the 68k's prop in time for the 68k to see it at full speed? let alone 3x full speed aga performance?
btw, I'm sorry for all the tech questions, it's that I'm really curious, and I'm finding it hard to see it working, which is why I as wanting to see it running, this kind of stuff really interests me!
As for how it is done the Prop that reads system mem is using Latches for the upper address bits, and I am limiting the 680x0 to a 68040 or lower so I can keep up with it and still sneak in between 680x0 bus cycles to read/write main mem.
As to questions directly regarding the MuAmi I finally decided to start a thread on the MuAmi (as this thread is for better Prop video output).
http://forums.parallax.com/showthread.php?131239-MuAmi-and-AGA-ECS-implemented-in-Props
I wish I would have that suggestion back when I was working with AVRs. Amazing thought though.
A secondary note, how do you successfully program these, both programmer HW and software??? I have tried many supposedly working methods without success. The programmers that worked for the equivalent from the 1980s do NOT work at all. I would like to use these as I have 50 of them sitting in the tube that they came from Arrow in.
I just figured out a ridiculously simple single Prop version that will work just as well. I will be posting a block diagram in a bit (drawing it now). I will be testing it this evening and if it works I will be updating the top post of this thread to reflect such, as well as the top post of the MuAmi thread (because this will also change the MuAmi video HW [it is less expensive]).