ant@cmr.ncsl.nist.gov (John Antonishek) (10/14/89)
lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >In <13370@nsc.nsc.com>, chaim@nsc.nsc.com (Chaim Bendelac) writes: >>I recently downloaded a game from a local bbs. It uses what I think >>is a sprite in the form of a volleyball. However, instead of showing >>itself in its round form, the ball is displayed as a ghostly white >>stripe all over the length of my screen. I have tried "nofastmem" >>but cannot get it right. I have seen this effect with other PD programs, >>and I am starting to worry. Is there something wrong with my A500? >Try moving your screen to the right with the Preferences program. >-larry This fixed my ghost problems, but will someone please tell me why it works? Thank you in advance. -john ant@cmr.ncsl.nist.gov
rap@peck.ardent.com (Rob Peck) (10/17/89)
In article <1648@nigel.udel.EDU> ant@cmr.ncsl.nist.gov (John Antonishek) writes: >lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>In <13370@nsc.nsc.com>, chaim@nsc.nsc.com (Chaim Bendelac) writes: ... >>>is a sprite in the form of a volleyball. However, instead of showing >>>itself in its round form, the ball is displayed as a ghostly white >>>stripe all over the length of my screen. I have tried "nofastmem" >>>but cannot get it right. I have seen this effect with other PD programs, >>>and I am starting to worry. Is there something wrong with my A500? > >>Try moving your screen to the right with the Preferences program. >>-larry >This fixed my ghost problems, but will someone please tell me why it works? >Thank you in advance. Amiga displays sprites by doing direct memory access during explicitly reserved memory clock cycles near the start of the time that the leftmost edge of the screen can be displayed. The designers of the Amiga allowed the screen to by dynamically moved left or right by adjusting the position at which the screen DMA begins. The Amiga Hardware manual shows a chart that defines the DMA time slots, showing that the first time slots are assigned to memory refresh, and audio, the disk, serial, the sprite come next and finally the display DMA. (Every item that needs memory access is basically assigned to alternate time slots, where the CPU gets the unassigned slots since it needs only every other memoryy slot to run at full speed.) Display DMA, when adjusted "to the left", overtakes the DMA time slots that would otherwise be available to the sprites. Evidently it was decided way back then that to make sure the display could be adjusted over a wide range of monitor centering, the small sacrifice of losing the higher numbered sprites would be acceptable. I created a PD program, "SpriteAdjust" that will display the top 6 sprite over the center of the Preferences centering gadget. When all 6 sprites display as gray squares instead of a mess all the way up and/or down the screen, then the screen is positioned acceptably for most games that use sprites. That is, the DMA slot for all of the sprites is available to the sprite and it does not receive an all-1's signal, causing the mess. SpriteAdjust is on People Link's Amiga forum. I'll be including it in the archive for my BADGE 89 Killer Demo entry also because I need all of the sprites to work. The entry is called OnlyAmiga. Rob Peck
esker@abaa.uucp (Lawrence Esker) (10/21/89)
In article <8722@ardent.UUCP> rap@peck.ardent.com (Rob Peck) writes: >In article <1648@nigel.udel.EDU> ant@cmr.ncsl.nist.gov (John Antonishek) writes: >>lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>>Try moving your screen to the right with the Preferences program. >>This fixed my ghost problems, but will someone please tell me why it works? > >Amiga displays sprites by doing direct memory access during explicitly >reserved memory clock cycles near the start of the time that the leftmost >edge of the screen can be displayed. The designers of the Amiga allowed >the screen to by dynamically moved left or right by adjusting the position >at which the screen DMA begins. The Amiga Hardware manual shows a chart >that defines the DMA time slots, showing that the first time slots >are assigned to memory refresh, and audio, the disk, serial, the >sprite come next and finally the display DMA. > >Rob Peck This brings an interesting question. From the above desription, the Amiga preloads the sprite data and then multiplexes the preload data with the bitmap data being read on the fly. When the time comes to display the sprite, the multiplexer ignores the bitmap data and uses the preloaded sprite data. Assuming the above to be true, why didn't the design multiplex the bitmap current address with a sprite address generator? When the time for the sprite arrives, the chip ram address would just change. This would avoid the use of preload data buffers, indirectly allowing sprites to be any width. Would also free the time slots allocated to the sprites. Too bad Jay Miner does not read this group. I would really like to pick his brain about a lot of Amiga custom chip decisions. -- ---------- Lawrence W. Esker ---------- Modern Amish: Thou shalt not need any \ * * * ******* / computer that is not IBM compatible. \ * * * * * / \ * * * * * ***** / Sr. Hardware/ASIC Design Engineer \ * * * * * * / Allen-Bradley Communications Div. \ ******* * * ******* / Work: (313)668-2500 Home: (313)973-8561 ----------------------------- Compuserve: 76337,2524 UseNet Path: __!mailrus!sharkey!itivax!abaa!esker == esker@abaa.UUCP
addison@pollux.usc.edu (Richard Addison) (10/21/89)
In article <4202@abaa.UUCP> esker@abaa.UUCP (Lawrence Esker) writes: >This brings an interesting question. From the above desription, the Amiga >preloads the sprite data and then multiplexes the preload data with the >bitmap data being read on the fly. When the time comes to display the sprite, >the multiplexer ignores the bitmap data and uses the preloaded sprite data. > >Assuming the above to be true, why didn't the design multiplex the bitmap >current address with a sprite address generator? When the time for the sprite >arrives, the chip ram address would just change. This would avoid the use >of preload data buffers, indirectly allowing sprites to be any width. Would >also free the time slots allocated to the sprites. The multiplexer does not ignore the bitmap data. Look at your mouse pointer, is it a 16 bit wide opaque block aligned on a 16 bit boundary? The flexibility of the sprite engine comes from that fact that it has transparency. The dual-playfield mode is sort of an extension of that. But, as you probably know, all of these accesses need to share the same pool of memory. I understand the decision to have the sync signals fixed while allowing the data fetch and display to be programmable. (Compare this to how the video controller works on the old Color Graphics Adapter on the IBM PC's. Did you ever seen one of those change display modes? It would upset the sync on the monitor! On the Amiga, you can change modes in mid-display! It all stays rock steady.) However, would it not have been possible to design the custom chips to fetch the sprite data for line n after fetching the bitmap data for line n-1 when the Display Fetch Data Start occurs too soon to allow the sprite data to be fetched at the beginning of line n? Yes, I know it's more complicated, but I think these "vertical bar" sprite problems occur quite frequently for typical users who don't know that it doesn't mean their machine is broken. (Parse that!) Oh, by the way, since this is getting somewhat more technical, I've set the "Followup-To:" line appropriately. Richard Addison "But officer, I didn't see that motorcycle 'cause of Preferences!"
swan@jolnet.ORPK.IL.US (Joel Swan) (10/21/89)
In article <4202@abaa.UUCP> esker@abaa.UUCP (Lawrence Esker) writes: :In article <8722@ardent.UUCP> rap@peck.ardent.com (Rob Peck) writes: :>In article <1648@nigel.udel.EDU> ant@cmr.ncsl.nist.gov (John Antonishek) writes: :>>lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: :>>>Try moving your screen to the right with the Preferences program. :>>This fixed my ghost problems, but will someone please tell me why it works? :> :>Amiga displays sprites by doing direct memory access during explicitly :>reserved memory clock cycles near the start of the time that the leftmost [explanation cut] :> :>Rob Peck : :This brings an interesting question. From the above desription, the Amiga :preloads the sprite data and then multiplexes the preload data with the [more talk cut] :Too bad Jay Miner does not read this group. I would really like to pick his :brain about a lot of Amiga custom chip decisions. Jay Miner can now be found roaming the halls of the AmigaZone on American Peoplelink, the best nationwide BBS for Amigophiles (and the least expensive). :-- :---------- Lawrence W. Esker ---------- Modern Amish: Thou shalt not need any :\ * * * ******* / computer that is not IBM compatible. : \ * * * * * / : \ * * * * * ***** / Sr. Hardware/ASIC Design Engineer : \ * * * * * * / Allen-Bradley Communications Div. : \ ******* * * ******* / Work: (313)668-2500 Home: (313)973-8561 : ----------------------------- Compuserve: 76337,2524 :UseNet Path: __!mailrus!sharkey!itivax!abaa!esker == esker@abaa.UUCP Ah. So I see you are on CI$. I used to use CI$$. Now I've descovered PLINK, where lots of great Amiga action takes place. I don't have their 1-800 number handy but you can call Chicago information at 312-555-1212 and get the number for American Peoplelink. (Nope I don't work for or with PLINK. I just think it's the best) Joel Swan PLINK : Amiga*joel CI$ : 74746,3240