For examples see 400x300 (20MP/s) or 800x600 (40MP/s). [thread=135844]This thread[/thread] marks the beginning of it.
Well, that looks original! How the hell does WHOP work? I'm not seeing how any colour data reaches the pins. What bloody good is a compare instruction here?! I see the scan-doubling buffer in action but again it's reused with just a CMP instruction! Do tell.
Well, that looks original! How the hell does WHOP work? I'm not seeing how any colour data reaches the pins. What bloody good is a compare instruction here?! I see the scan-doubling buffer in action but again it's reused with just a CMP instruction! Do tell.
[post=993236]This post[/post] may help, it's not verbose or anything but should give you an idea. Feel free to ask for more details later.
... Just so you know, wativids repeat. They repeat even when there is no waitvid instruction! And what he does is drop the data the waitvid needs right on the bus, right when a waitvid is looking for it and that allows for really tight pixel loops because there isn't a waitvid instruction in there, like you see in almost every driver now. But doing that requires the Prop run at a specific clock (80Mhz is what I saw) and that the driver adhers to specific timings. It's gonna be worth it to go pick through the ones he's done to see what might do the job.
That's just a tad tricky. I see why I was confused now. I feel a little cheated actually.
Comments
Well, that looks original! How the hell does WHOP work? I'm not seeing how any colour data reaches the pins. What bloody good is a compare instruction here?! I see the scan-doubling buffer in action but again it's reused with just a CMP instruction! Do tell.
PS: It does work however.
That's just a tad tricky. I see why I was confused now. I feel a little cheated actually.
Right ... I'm sulking right about now.