On 7/16/06, ABC XYZ <[EMAIL PROTECTED]> wrote:
On Sat, 15 Jul 2006 23:52:46 +0200, Timothy Miller <[EMAIL PROTECTED]> wrote: > This video controller is like a microcontroller of sorts. Each > instruction corresponds to four pixels (or the equivalent time > period). The RAM is read in the video clock domain, because that's > the time domain that program has to run in. The RAM is written in the > PCI domain, because that's how you load it with a program.Thank you for you answer, I kind of suspected the the controller was some kind of MCU, i just didnt knew what it was used for. Reading the latest post my best guess was that it is used to generate sync signals and/or to feed the DACs with pixels. Now, my question about the rams was really about this part of your code: RAMB16_S36_S36 cram0 ( .DOA(cram_bits[0:31]), .DOPA(), .DOB(cram_bits[32:63]), .DOPB(), <-- cram_bits[32:63] read @pci_clock .ADDRA({1'b0, cursor_addr}), .CLKA(vid_clock), .DIA(32'b0), .DIPA(4'b0), .DIB(reg_write_data), .DIPB(4'b0), .ADDRB(reg_write ? reg_write_addr[8:0] : {1'b1, cursor_addr}), <-- cursor_addr sampled @pci_clock .CLKB(pci_clock), <-- pci_clock .ENA(1'b1), .SSRA(1'b0), .ENB(1'b1), .SSRB(1'b0), .WEA(1'b0), .WEB(reg_write && !reg_write_addr[9])); I assume that cram_bits and cursor_addr are in the vid_clock clock doman. Given that the two clocks are unrelated (AFAIK), I cant see how port-B reads work here.
Ah! I thought you were talking about the video controller. This is the cursor block, and you found the critical flaw that I told people to look for when I first posted it. I guess you win the prize! :) That's good work there. It's broken. I hooked it up this way because I wanted to see how much logic area it would require (approximately), and I never got around to fixing it properly.
---------------------------------- on another unrelated subject, here is my list of _other_ things to do with OGD1. some of them have guaranteed high "geek factor". 1. Your own shiny new RSIC CPU. or why not create your own PDP-11? 2. soundcards? forget that, I want a real music synthesizer. how about a really fast and accurate emulation of mini-moog?? 3. password cracker - for those of you with illegal nighttime activities ;) 4. Hardware Distibuted.Net or [EMAIL PROTECTED] clients (so your host CPU is not running 100% and consumes 300W/hour on a totally pointless activity :) 5. retro-computing: how about a complete cycle-accurate C64, Sinclair or even an Amiga?? What about finally being able to afford a Neo Geo system? 6. why not create your own VPN link with 8192-bit RSA or 4387-bit elliptic curve encryption? 7. of course some of above can co-exist with a "lighter" graphic code. for example, at startup you may choose between 3D-accelerated graphics or simple 1024x768 SVGA graphics plus [EMAIL PROTECTED] client :) 8. run your own uc-linux system on the board! 9. real time DivX encoding of your DVD? 10. put a LEON sparc in there and off load your main CPU. Well, hope i didnt steal attention from the project, these are just some crazy ideas I had for getting you slashdotted :)
What we need is a library of modules that contributors, such as your self, have developed for this board. We can do any and all of these things. This will help sell OGD1 boards and thus help pay for the development of OGC cards. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
