I believe this is the patent in question: http://www.google.com/patents?vid=USPAT4555775. Note that the inventor is Rob Pike of AT&T Bell Laboratories, not Microsoft. AFAICT, it goes beyond the basic backing store concept, being a system for drawing on the exposed and the obscured portions of a window. That is, when you draw a line, the visible parts of the line show up on the screen and the hidden parts are written to the backing store.
Patents only matter in almost all cases if you have enough money to pay enough lawyers to win.
Well said. It also only matters if you have enough money to make it worthwhile for the patent holder
And many patents are just for the bluff factor and could never really stand up under testing, although, once again, it is the deepest pockets. Very sad, isn't it!
I think that you are up to V9 schematics (or so) on the Dracblades but I just looked an just saw V5. What pins do you have the mouse on, is the usuals (DemoBoard ish)?
I tried to look in the code listings but it is obscured by the cogjets method (I think).
Over the weekend I will stick a 6 pin socket int the back of "KBD_DracBlade" as there is still a bt of space left where the batteries used to go, and it will be so much simpler than a V3 rebuild, again ...
Sorry, yes my website provider decided to limit uploads to 130k so I haven't been able to upload the newest schematics. But all the versions are essentially the same, the main changes were on additional digital input and output lines. And yes, same pins as the demo board for mouse, keyboard.
The code is in two sections - post#1 is the cogject stuff, and post #2 has the code - the program is now too big for this forum!
It still compiles in about half a second. Download is about 20secs. Fast speeds thanks to Rossh et al.
Addit - Cluso99 mentioned recently a little TV screen for a very good price - mine arrived today so I am looking forward to seeing how this looks on a TV.
Right now the difficult bit is done, all I have to do now is learn C.
The C used in this program is very much a subset of C. Hopefully not too hard to learn.
The mouse was flickering because it was deleting the old mouse and then drawing the new one. This new version contains a quite complicated routine that has a mirror graphics buffer (in external ram) and does all the drawing on this buffer, then just copies the relevant old and new longs over to the visible screen buffer.
It is surprisingly smooth and fast.
Also we now have the beginnings of frames/windows that can be drawn over the main screen, and then deleted as required, eg for dropdown menus or for yes/no input boxes.
On drawing the mouse:
May I recommend for a future version; if the mouse moves downward undraw the bottom line of the cursor and draw the bottom line in the new position, then next up etc. If it moves up or just sideways then same thing though starting at the top instead of the bottom. This is very smooth and fast, and does not require extra writes to external mem.
Mpark: Why do you keep this long dead sub discussion going. It does not matter as he has said that he is not providing a special buffer for the background of a Window. I am thankful it is over, as if it had continued I would have had to do the research to find the exact patent, and that would have meant spending the next week or two getting absolutely nothing else done.
I hadn't posted since 5/19 until you brought it up again yesterday. I'm glad you revived this thread, though, because as far as I'm concerned it does still matter.
Look, you dropped a big bombshell of FUD in this thread with your so-far mythical* patent. The good Dr. may have avoided the issue, but other people are going to waste their time and energy coding around a perfectly obvious technique, just because of what you said. So yes, if you have to spend the next week doing nothing else but finding the patent, you owe it to those people to do so. Either back up what you say or take it back.
* (I am skeptical that it exists but would be happy to be proved wrong.)
GUI looks great Dr.A. I have a very similar thing in mind, but want to do it with 16 colors using SRAM to hold the buffer and Flash to hold the bitmap and fonts...
I think you're doing 320x240 here, which is a nice size because it can work on both TV and VGA.
GUI looks great Dr.A. I have a very similar thing in mind, but want to do it with 16 colors using SRAM to hold the buffer and Flash to hold the bitmap and fonts...
Do you think it would ever be possible to read data from a ram chip fast enough for a display? I've pondered this many times and occasionally see threads that are tantalising eg 10ns static ram chips. I start dreaming of one cog building a line while another cog displays it. Two ram chips. Maybe a third cog pulling data off another ram chip. There must be some solution there!
I've taken the approach that you have a 320x240 boring gray 4 color display for 'work', ie text, a calculator etc, and then there is color for games. The demo program briefly loads in Kye's 64 color 160x120 driver just to show it can be done.
I'm waiting on a TV display to arrive from Hong Kong as I really want to see how this looks on TV. (I have had some bad luck with LCD TV displays - the first one is just out on the timing specs [there is a solution somewhere on the forum for that], and the second one didn't work. I pulled it to bits and two pins on a qfn chip had a solder blob joining them and I just made it worse when I tried to fix it!)
Has anyone got Catalina working using the XMM mode for other ram chip hardware - C3, SPI, other ram?
Has anyone got Catalina working using the XMM mode for other ram chip hardware - C3, SPI, other ram?
Hi Dr_A,
Do you mean Catalina in general, or your GUI application? As far as I am aware, there isn't any commercially available XMM architecture out there that Catalina doesn't support - possibly excepting jazzed's SDRAM board (and he says he's working on that).
I test it on all the XMM enabled boards I have prior to release, inlcuding the C3.
Great to hear that Ross. I was thinking more of who is using catalina - even just as a quick test. I need to study the C3 again - I think the issue there is it can't do a mouse and a keyboard at the same time but maybe there is a hardware hack around that?
The C3 only has a single PS/2 connector and the I/O pins normally used for a mouse are used for other things. There are some uncommitted I/O pins (0-3) brought out to a header that could be used for a mouse if there were an adapter made.
Ah, and that expansion connector has pins 0-3 and Mike says these are uncommitted. So one could think about an adapter board that takes that expansion connector, takes all the pins to another expansion connector, and brings out pin 0,1 Gnd and 5V to a PS2 connector.
I think I need to get a C3 and do some speed tests to compare with the dracblade...
Do you think it would ever be possible to read data from a ram chip fast enough for a display?
I think I'm very close to being able to do 320x240 in 16 colors from either flash or SRAM (or both) and still have time to do some updates on the screen.
16 colors works out nicely with my 4-bit wide external memory...
Comments
Well said. It also only matters if you have enough money to make it worthwhile for the patent holder
And many patents are just for the bluff factor and could never really stand up under testing, although, once again, it is the deepest pockets. Very sad, isn't it!
There are all sorts of other reasons why "patents matter", so I have to disagree with the above statement, based on my experience.
For example, patents look good on resume's and make big company bosses happy.
I think that you are up to V9 schematics (or so) on the Dracblades but I just looked an just saw V5. What pins do you have the mouse on, is the usuals (DemoBoard ish)?
I tried to look in the code listings but it is obscured by the cogjets method (I think).
Over the weekend I will stick a 6 pin socket int the back of "KBD_DracBlade" as there is still a bt of space left where the batteries used to go, and it will be so much simpler than a V3 rebuild, again ...
The code is in two sections - post#1 is the cogject stuff, and post #2 has the code - the program is now too big for this forum!
It still compiles in about half a second. Download is about 20secs. Fast speeds thanks to Rossh et al.
Addit - Cluso99 mentioned recently a little TV screen for a very good price - mine arrived today so I am looking forward to seeing how this looks on a TV.
Right now the difficult bit is done, all I have to do now is learn C.
The C used in this program is very much a subset of C. Hopefully not too hard to learn.
The mouse was flickering because it was deleting the old mouse and then drawing the new one. This new version contains a quite complicated routine that has a mirror graphics buffer (in external ram) and does all the drawing on this buffer, then just copies the relevant old and new longs over to the visible screen buffer.
It is surprisingly smooth and fast.
Also we now have the beginnings of frames/windows that can be drawn over the main screen, and then deleted as required, eg for dropdown menus or for yes/no input boxes.
Pesky job!
On drawing the mouse:
May I recommend for a future version; if the mouse moves downward undraw the bottom line of the cursor and draw the bottom line in the new position, then next up etc. If it moves up or just sideways then same thing though starting at the top instead of the bottom. This is very smooth and fast, and does not require extra writes to external mem.
Then please either provide the correct patent number or stop spreading unsubstantiated rumors.
I hadn't posted since 5/19 until you brought it up again yesterday. I'm glad you revived this thread, though, because as far as I'm concerned it does still matter.
Look, you dropped a big bombshell of FUD in this thread with your so-far mythical* patent. The good Dr. may have avoided the issue, but other people are going to waste their time and energy coding around a perfectly obvious technique, just because of what you said. So yes, if you have to spend the next week doing nothing else but finding the patent, you owe it to those people to do so. Either back up what you say or take it back.
* (I am skeptical that it exists but would be happy to be proved wrong.)
I think you're doing 320x240 here, which is a nice size because it can work on both TV and VGA.
Do you think it would ever be possible to read data from a ram chip fast enough for a display? I've pondered this many times and occasionally see threads that are tantalising eg 10ns static ram chips. I start dreaming of one cog building a line while another cog displays it. Two ram chips. Maybe a third cog pulling data off another ram chip. There must be some solution there!
I've taken the approach that you have a 320x240 boring gray 4 color display for 'work', ie text, a calculator etc, and then there is color for games. The demo program briefly loads in Kye's 64 color 160x120 driver just to show it can be done.
I'm waiting on a TV display to arrive from Hong Kong as I really want to see how this looks on TV. (I have had some bad luck with LCD TV displays - the first one is just out on the timing specs [there is a solution somewhere on the forum for that], and the second one didn't work. I pulled it to bits and two pins on a qfn chip had a solder blob joining them and I just made it worse when I tried to fix it!)
Has anyone got Catalina working using the XMM mode for other ram chip hardware - C3, SPI, other ram?
Hi Dr_A,
Do you mean Catalina in general, or your GUI application? As far as I am aware, there isn't any commercially available XMM architecture out there that Catalina doesn't support - possibly excepting jazzed's SDRAM board (and he says he's working on that).
I test it on all the XMM enabled boards I have prior to release, inlcuding the C3.
Ross.
Andy
I think I need to get a C3 and do some speed tests to compare with the dracblade...
I think I'm very close to being able to do 320x240 in 16 colors from either flash or SRAM (or both) and still have time to do some updates on the screen.
16 colors works out nicely with my 4-bit wide external memory...