greg@isrnix.UUCP (Gregory Travis) (02/05/88)
If the system is limited to 8 sprites in any given horizontal
plane and if the CLI cursor is itself a sprite (which I read
somewhere) howcome I can open more than 10 cli windows on my
1000? Note that I make the windows very small and stack them
horizontally:
[][][][][][][][][][]
So that their cursors are all on the same scan lines.
--
Gregory R. Travis
Institute for Social Research - Indiana University - Bloomington, IN 47405
ihnp4!inuxc!isrnix!greg
{pur-ee,kangaro,iuvax}!isrnix!gregsteveb@cbmvax.UUCP (Steve Beats) (02/05/88)
In article <880@isrnix.UUCP> greg@isrnix.UUCP (Gregory Travis) writes: >If the system is limited to 8 sprites in any given horizontal >plane and if the CLI cursor is itself a sprite (which I read >somewhere) howcome I can open more than 10 cli windows on my >1000? Note that I make the windows very small and stack them >horizontally: > > [][][][][][][][][][] > >So that their cursors are all on the same scan lines. > >-- No, the CLI cursors are just bitmap images (if you look when they are over a character, you will see that they are hi-res too). The mouse pointer is the sprite. I have seen this referred to as a cursor which may have caused your confusion. Steve
cmcmanis%pepper@Sun.COM (Chuck McManis) (02/06/88)
In article <880@isrnix.UUCP> greg@isrnix.UUCP (Gregory Travis) writes: > If the system is limited to 8 sprites in any given horizontal > plane and if the CLI cursor is itself a sprite (which I read > somewhere) howcome I can open more than 10 cli windows on my > 1000? This would appear to be a very good proof by negation setup, spoken more formally : Hypothesis : The cursor is a sprite Fact : The hardware will only support 8 sprites on a line Fact : 10 Cli cursors can be lined up on a line Conclusion : Since there can be 10 CLI cursors on a line, and the hardware will only support 8 sprites, then we conclude the hypothesis was wrong. The CLI cursor is *not* a sprite. QED. (This always appears at the end of proofs for some reason :-), Maybe it is the proof End-of-file mark.) As you now know, what you 'read somewhere' was incorrect. So if someone trys to tell you this, ask them to 'prove' it. :-) --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (02/06/88)
In article <880@isrnix.UUCP> greg@isrnix.UUCP (Gregory Travis) writes: >If the system is limited to 8 sprites in any given horizontal >plane and if the CLI cursor is itself a sprite (which I read >somewhere) howcome I can open more than 10 cli windows on my >1000? Note that I make the windows very small and stack them >horizontally: > > [][][][][][][][][][] > >So that their cursors are all on the same scan lines. > You have just accidentally stumbled upon one of the best kept secrets in the Amiga, as well as one of the finest hacks ever perpetrated. I noted the same behavior you did many many moons ago, and decided that I was going to get to the bottom of it once and for all. Thus ensued my three-week-long foray into the innards of the Amiga. I disassembled. I PEEKed. I POKEed. I dereferenced pointers. I disassembled COPPER lists. I fiddled with the Blitter. I had the COPPER stuff the Blitter registers. I had the Blitter write into FAST RAM. I read the DOS manuals over and over and over and over and over and over.... I had the sprite DMA channel connected to the audio DMA channel, and tied it to the memory refresh and disk DMA channels, patched it into LIVE!, and had the video fetch DMA getting its pixel colors from the parallel port. After three long weeks, I was ready to give up.... When SUDDENLY! I figured it out! Intuition, Graphics, Exec, and the console.device are all much more tightly integrated than anyone ever suspected before. You see, the graphics.library has a complete Copper list assembler/editor with AI heuristics, which, by what I can divine, was originally written in SNOBOL. This AI subsystem is closely connected to Intuition's window manager, and the console.device. When the console.device moves its cursor, it tells Intuition about it (using message ports running a variant of the InterNet protocol). Intuition then maps the window's cursor to display coordinates, and then issues a complex stream of string-based requests to the Copper AI software. Using a piece of software I'm beta-testing for ASDG (MetaRomScopeGrandDBWack), I managed to watch this transaction in action. It goes something like this: Intuition: "Yo! Dale! I need a favor..." Copper AI: "Sure, -=RJ=-, whatcha need?" I: "Well, I have this cursor here which needs to be moved." CAI: "No problem. Have a beer and we'll talk about it." [ At this point, an enormous chemical formula flies through which I utterly failed to understand. ] I: "Mmmmm. Very good. Well, about my cursor..." CAI: "Right. Where do you need it?" I: [ Specifies coordinates in hex ] CAI: "Hmmmm. Tricky. You realize that it'll be off by one pixel; does that cause problems?" I: "No, I corrected for that already." CAI: "Ah. Yeah, I can do that. Lemme think about it for a bit and I'll have it ready for you." [ 75 microseconds pass, during which, there's a lot of CPU stomping on undocumented custom chip registers. ] CAI: "Okay, it'll be taken care of during the next vblank." I: "Very cool!" CAI: "No problem. See you." I: "See you. Thanks for the beer." After seeing this transaction, I decided to inspect the copper lists. They looked completely normal and unremarkable. This didn't seem right to me, yet the cursor sprites remained on the screen just fine. So I bit the bullet, and decided to simulate the CPU stomping on the undocumented custom chip registers. Nothing happened. So I fiddled a bit with the data that was being written, and...... ONE OF THE CURSORS MOVED! After some hours of hacking, I discovered how to move any cursor to any position, and how to add and delete them. But, it seemed, there was more here that was meeting the eye. So I went to work studying the data I was writing to the chip registers. "Strange," I thought, "It looks like 68000 object code." So I disassmebled the code by hand, and I got a short little machine program. It appeared to refer to known custom chip registers, as well as memory space at a very high address. So I thought, what the hell, and wrote a small 68000 program that spun in a tight loop for 65536 iterations, and continued. I sent this to the custom chips, and gave the correct protocol to run it. The screen jumped briefly! I knew I was close. I rewrote the program to make the loop iterate 2^32 times so I could see what was going on. I sent the program and had it execute. My jaw dropped as I looked at the screen.... THE VIDEO BEAM HAD STOPPED MOVING! It was just a spot, off to one side, colored blue. Suddenly, it started moving again, and the system behaved normally. I ran the program again, and timed the duration of the video beam halt. I then ran a few calculations (using HaiTex's 3D scientific calculator), and discovered that the delay was exactly as long as it would take a 68000 to count to 2^32 if it were running at eight times the hi-res dot clock rate. After some more exploring, I discovered that the custom chips house a totally seperate 68000 running at a high rate, but with only 8K of RAM, and 1K of ROM. It also doesn't have access to the outside system; it is its own private world. It is this 68000 that manages the custom chip operations, and literally drives the video beam. This is why the program I wrote stopped the video beam. The tight loop I put it in stopped all its operations, and it couldn't drive the beam anymore, so it stopped. Getting back to sprites: As far as outside programs are concerned, there are only eight sprites available per video line. However, the graphics software seems to know about the "other" 68000 inside the custom silicon. It sends a small program which alters the behavior of the main video driving program. Since the "other" 68000 runs blindingly fast, and since its responsible for painting the screen, it briefly re-allocates one of the sprite channels, and paints it in the right place, even in hi-res. So in fact, what you're seeing is not ten sprites, or eight sprites with judicious re-use, it's *ONE* sprite that's being flipped around the screen. The video driver program knows where all the user's sprites are, and if there is a collision, it sorts the priority on a pixel-by-pixel basis, and flips between images as needed. I was going to write an incredibly neat display hack using this technology, but every time I tried to write something, the system would Guru with the code 4E594148.4E594148. So I gave up. After my discovery, I've come to the conclusion that -=RJ=-, Dale, and Jay are Gods. Be nice to them next time you meet them... _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor
cs178abu@sdcc8.ucsd.EDU (John Schultz) (02/07/88)
...because the CLI cursors are not sprites... You must have read that in the National Semiconductor Inquirer... :-) John
cs178abu@sdcc8.ucsd.EDU (John Schultz) (02/07/88)
Do you know inefficient it would be if the cursor was a sprite? Just look at the cursor as it is drawn over a character: You would have to do a whole bunch of copying and then de-interlace the bitplanes before copying the result to a sprite data pointer. Not worth the trouble (and impractical for hardware sprites). QED is a latin acronym for "There it is" or "It is shown". Maybe it expands out to "Quotas Epluribus Donum"... John
cs178abu@sdcc8.ucsd.EDU (John Schultz) (02/07/88)
Uh, Leo, have you been breathing PCB vapor from blown-out capacitors while meditating in a float-tank again? I'll bet quite a few people out there (here) will believe what you wrote. John All this for a silly question...
drz@utcsri.UUCP (Jerry Zarycky) (02/08/88)
In article <5163@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > > I was going to write an incredibly neat display hack using this >technology, but every time I tried to write something, the system would Guru >with the code 4E594148.4E594148. So I gave up. Nice explanation Leo, but shouldn't it have started with Once upon a time,.... ? That NYAH.NYAH really bugs me too! Jerry Zarycky Usenet: {cornell, uw-beaver, linus, ihnp4, allegra, decvax, floyd} !utcsri!drz CSNET: drz@csri.toronto.edu UUCP: drz@utcsri.uucp EAN: drz@csri.toronto.cdn
fiddler%concertina@Sun.COM (Steve Hix) (02/09/88)
In article <788@sdcc8.ucsd.EDU>, cs178abu@sdcc8.ucsd.EDU (John Schultz) writes: > > QED is a latin acronym for "There it is" or "It is shown". Maybe > it expands out to "Quotas Epluribus Donum"... Sigh. Follow the Three-Foot Rule: Never be more than an arm's length from a dictionary when you're writing. QED = (latin) Quod Erat Demonstrandum. Literally "which was to be demonstrated or proved". Commonly used in math (or logic and philosophy, I suppose) to indicate that a proof is being taken as having been previously derived in full, or demonstrated, by someone else. I'll probably be flamed for current usage, but it's all right: My Nomex undies are back from the was, and the heating bill has been sort of high for a while anyway. :} seh
drz@utcsri.UUCP (Jerry Zarycky) (02/10/88)
In article <788@sdcc8.ucsd.EDU> cs178abu@sdcc8.ucsd.edu.UUCP (John Schultz) writes: > > QED is a latin acronym for "There it is" or "It is shown". Maybe >it expands out to "Quotas Epluribus Donum"... > > John Actually, as a former Latin student!... Q.E.D. stands for "Quod erat demonstrandum" or literally, "That which was to be proven" (Gee, I hope I remembered the Latin correctly, it's been so long; in any case, the translation is reasonably accurate) Jerry Zarycky Usenet: {cornell, uw-beaver, linus, ihnp4, allegra, decvax, floyd} !utcsri!drz CSNET: drz@csri.toronto.edu UUCP: drz@utcsri.uucp EAN: drz@csri.toronto.cdn
cs178abu@sdcc8.ucsd.EDU (John Schultz) (02/13/88)
In article <41378@sun.uucp> fiddler%concertina@Sun.COM (Steve Hix) writes: >I'll probably be flamed for current usage, but it's all right: >My Nomex undies are back from the was, and the heating bill has >been sort of high for a while anyway. :} > > seh Hey, if you don't want to be flamed, don't make any negative inferences about the author; just make your point. It can be done... That is, unless you *want* to be flamed. John
shimoda@rmi.UUCP (Markus Schmidt) (02/13/88)
Hi! Just for the case you really didn't know what QED means. Quot erat demostandum - what we liked to proc\ve. Markus
morgan@brambo.UUCP (Morgan W. Jones) (02/18/88)
In article <41378@sun.uucp> fiddler%concertina@Sun.COM (Steve Hix) writes: >QED = (latin) Quod Erat Demonstrandum. Literally "which was to be >demonstrated or proved". Commonly used in math (or logic and >philosophy, I suppose) to indicate that a proof is being taken as >having been previously derived in full, or demonstrated, by someone >else. QED comes from Euclid (Geometry, yuk!), who after the last line of his proofs, which were restatements of the problem, said "which was to be shown". At least that's how I heard it. > seh -- Morgan Jones - Bramalea Software Inc. ...!utgpu!telly \ !brambo!morgan ...!{uunet!mnetor, watmath!utai}!lsuc!ncrcan / "These might not even be my opinions, let alone anyone else's."
cosell@bbn.com (Bernie Cosell) (02/19/88)
In article <280@brambo.UUCP> morgan@brambo.UUCP (Morgan W. Jones) writes: > >QED comes from Euclid (Geometry, yuk!), who after the last line of his >proofs, which were restatements of the problem, said "which was to be >shown". At least that's how I heard it. Not likely that it came from Euclid.. it was *not* all Greek to him. The practice may have started there (I don't have a copy of the Elements handy in my office here...:-(), but surely "QED" didn't. __ / ) Bernie Cosell /--< _ __ __ o _ BBN Labs, Cambridge, MA 02238 /___/_(<_/ (_/) )_(_(<_ cosell@bbn.com