wayneck@tekig5.TEK.COM (Wayne Knapp) (03/10/88)
I found out that I computed the movm timing incorrectly. Now it looks like to
me that the fastest way to move memory to memory is the mov.l (An)+,(Am)+
instruction. Does anyone know a faster way? If not, using this instruction
will allow for 48 color changes a scan line. I believe that is the same as
Spectrum 512. Maybe they couldn't find a faster way either. Anyway the code
would look like:
Some in beginning:
mov.l color.information.table,A0 # picture color information
mov.l start.color.registers,A1 # ST's color registers
mov.q 199,D0 # 199 lines
sync code # posted earlier
Maybe some code for changing top line colors 16 times 32 colors
newline: mov.l A1,A2 # 4
mov.l A1,A3 # 4 8
mov.l A1,A4 # 4 12
clr.l D1 # 6 18 need to waste 6 cycles
mov.l (A0)+,(A2)+ # 20 38
mov.l (A0)+,(A2)+ # 20 58
mov.l (A0)+,(A2)+ # 20 78
mov.l (A0)+,(A2)+ # 20 98
mov.l (A0)+,(A2)+ # 20 118
mov.l (A0)+,(A2)+ # 20 138
mov.l (A0)+,(A2)+ # 20 158
mov.l (A0)+,(A2)+ # 20 178
mov.l (A0)+,(A3)+ # 20 198
mov.l (A0)+,(A3)+ # 20 218
mov.l (A0)+,(A3)+ # 20 238
mov.l (A0)+,(A3)+ # 20 258
mov.l (A0)+,(A3)+ # 20 278
mov.l (A0)+,(A3)+ # 20 298
mov.l (A0)+,(A3)+ # 20 318
mov.l (A0)+,(A3)+ # 20 338
mov.l (A0)+,(A4)+ # 20 358
mov.l (A0)+,(A4)+ # 20 378
mov.l (A0)+,(A4)+ # 20 398
mov.l (A0)+,(A4)+ # 20 418
mov.l (A0)+,(A4)+ # 20 438
mov.l (A0)+,(A4)+ # 20 458
mov.l (A0)+,(A4)+ # 20 478
mov.l (A0)+,(A4)+ # 20 498
dbne D0,newline # 10 508 remember 508 cycles per scan line
This would give 14 colors per 20 pixels with two new colors every 20 pixels.
I can't think of anything better, but I still open to new ideas.
Another interesting mode any be to use word moves and make a new high res mode.
it not allow as many color changes since one runs out of address registers, but
it may be nice. The inner loop could be made of the following segments.
mov.w (A0)+,(A2)+ # 13 13
mov.w (A0)+,(A2)+ # 13 26
mov.w (A0)+,(A2)+ # 13 39
mov.w (A0)+,(A2)+ # 13 42
mov.l A1,A2 # 4 46
This would allow for 32 colors per scan line. Only 32 since only part of the
188 cycles during horizontal retrace could be use. Does anyone want this mode,
640 x 200 x 512 colors?
What is a good name for these, any ideas?
Thank you,
Wayne Knapp
rokicki@polya.STANFORD.EDU (Tomas G. Rokicki) (03/11/88)
Try movem. As in: movem.l (a0)+,a2-a5/d0-d7 movem.l a2-a5/d0-d7,(a1) add.w #48,a1 Much faster than move.l (a0)+,(a1)+ repeated 12 times. -tom
wayneck@tekig5.TEK.COM (Wayne Knapp) (03/15/88)
In article <2137@polya.STANFORD.EDU>, rokicki@polya.STANFORD.EDU (Tomas G. Rokicki) writes: > Try movem. As in: > > movem.l (a0)+,a2-a5/d0-d7 > movem.l a2-a5/d0-d7,(a1) > add.w #48,a1 > > Much faster than > > move.l (a0)+,(a1)+ > > repeated 12 times. > > -tom Maybe I'm confused and not counting cycles correctly, if so show me where I going wrong. But it looks like the move multiple sequence is only 6 cycles faster than the 12 move.1 (a0)+,(a1)+. The advantange of the move.l is that you get a more even color change than the movem gives. That is every color change is exactly 20 cycles apart. Here is what I believe the timings are. movem.l (a0)+,a2-a5/d0-d7 # 8 + 8 * 12 = 104 movem.l a2-a5/d0-d7,(a1) #12 + 8 * 12 = 108 add.w #48,a1 # 22 ---- 234 Where as 12 move.l (a0)+,(a1)+ gives 12 * 20 or 240 cycles. Is this correct or am I goofed up. Thanks for your help. Wayne Knapp
johnm@trsvax.UUCP (03/16/88)
I for one would very much like to see a 640 x 200 x 512 mode even if only 32 colors are available per scan line. The doubled resolution would be more than noticable in what it would do for pictures.
unpowell@csvax.liv.ac.uk (03/18/88)
In article <2531@tekig5.TEK.COM>, wayneck@tekig5.TEK.COM (Wayne Knapp) writes: > In article <2137@polya.STANFORD.EDU>, rokicki@polya.STANFORD.EDU (Tomas G. Rokicki) writes: >> Try movem. As in: >> >> movem.l (a0)+,a2-a5/d0-d7 >> movem.l a2-a5/d0-d7,(a1) >> add.w #48,a1 >> >> Much faster than >> >> move.l (a0)+,(a1)+ >> >> repeated 12 times. >> >> -tom > > Maybe I'm confused and not counting cycles correctly, if so show me where > I going wrong. But it looks like the move multiple sequence is only 6 cycles > faster than the 12 move.1 (a0)+,(a1)+. The advantange of the move.l is that > you get a more even color change than the movem gives. That is every color > change is exactly 20 cycles apart. Here is what I believe the timings are. > > movem.l (a0)+,a2-a5/d0-d7 # 8 + 8 * 12 = 104 > movem.l a2-a5/d0-d7,(a1) #12 + 8 * 12 = 108 > add.w #48,a1 # 22 > ---- > 234 > > Where as 12 move.l (a0)+,(a1)+ gives 12 * 20 or 240 cycles. Is this correct > or am I goofed up. Thanks for your help. > > Wayne Knapp > For the purpose of moving colours into the pallette registers, surely, both of the above routines aren't much use. The pallette registers occupy 16 words starting at address $ff8240. So therefore you should be moving these "new" colours in 16 word blocks? And not 12*2=24 words as you seem to be doing. To move colours in 16 word blocks, move multiple could be the best bet, because the "move.l (a0)+,(a1)+" has the added problem of restoring a1 to point back to pallette 0. eg lea colorlist,a0 lea $8240.w,a1 movem.l (a0)+,d0-d7 * get 16 words movem.l d0-d7,(a1) * put 16 words into pallette registers ... etc ... As you can see this doesn't affect a1, and so it always points to pallette 0 ($ff8240). The equivalent with "move.l (a0)+,(a1)+" needs a1 resetting back to pallette 0 when it has gone through 16 words. lea colorlist,a0 lea $8240.w,a2 move.l a2,a1 move.l (a0)+,(a1)+ * move 16 words move.l (a0)+,(a1)+ * from "colorlist" to pallette's move.l (a0)+,(a1)+ move.l (a0)+,(a1)+ move.l (a0)+,(a1)+ move.l (a0)+,(a1)+ move.l (a0)+,(a1)+ move.l (a0)+,(a1)+ move.l a2,a1 move.l (a0)+,(a1)+ ... etc ... Of course when a1 gets to the end of the pallette's you could then go backwards (change to "move.l (a0)+,-(a1)") for then next 16 words and then change back to "move.l (a0)+,(a1)+", and so on. This would produce a move even pallette change than the above, where there is a "gap" between pallette's 15 and 0. Mark Powell, Liverpool University, Merseyside, England. ******************************************************************************** "...there's no success JANET unpowell@uk.ac.lis.csvax like failure and UUCP {backbone}!mcvax!ukc!mupsy!lis-cs!unpowell failure's no success ARPA unpowell%csvax.lis.ac.uk@nss.cs.ucl.ac.uk at all..." B.Dylan ********************************************************************************
long@sask.UUCP (Warren Long) (03/19/88)
While 512 colours is indeed a marvelous improvement over 16, what I really need is some way to show digitized images with more than eight grey levels. (8 is pretty crude). Has anybody given any thought to producing 256 grey levels?? Any hints on how to do it?? Is it possible?? Warren (long@sask) -- =-=-=-=-=-Warren Long at University of Saskatchewan, Canada-=-=-=-=- Home: 78 Carleton Dr.,Saskatoon, Sasakatchewan, S7H 3N6 Phone: (306)-955-1237 =-=-=-=-=-U-Email: ...!ihnp4!alberta!sask!long -=-=-=-=-=-=-=-=-