> to aid me in my continuing attempts to write some code that does >something interesting, please feel free to answer the following >questions : > > - is LDIR the fastest way to draw sprites to random >positions on the >screen (random in the same way as random access memory is anyway) > > - is LDIR the 'best' way to move sprites (bearing in mind >they have a >black border to rub themselves out - this is only my first z80 anything, >and I don't want to aim too high),
No. There are various ways to do sprites, and of course the fastest are the most complicated. I'd rather you got more confident in m/c before I try to teach you the *real* tricks of the trade[1] but there is one very simple tip which will immediately speed-bump your sprite routines by 17%: Unroll your loops. You know exactly how big your sprites are, so you know how many bytes you'll need to copy. Instead of setting BC to the correct number and doing an LDIR, which takes 24 "sam-adjusted" t-states for every byte except the last one; use the correct number of LDI instructions, which take 20 each. >or should I be looking into RLD and >RRD for incrementally moves? If you're desperate to have pixel-smooth movement horizontally, you should probably store two copies of your sprite data - the second one is shifted right by one pixel. It will be very much faster that way. Don't think about shifting the data along as you're printing it. > - what sort of numbers of 16x8 sprites could one be expected to >achieve in this sort of system? Am I likely to be able to manage 8 or so >even with my limited experience? (Assuming you mean 8 bytes wide, = 16x16 pixels) For that size sprite you'll spend 2560 t-states in LDIs, with let's say about 384 t-states total for changing the registers at the start of each line[2]. You should get 95,120 t-states per 50Hz frame, so you should manage 32 sprites that way, if you were doing nothing else. > - I seem to remember that the BASIC 'pallette at line' or >whatever the >command was was referred to in the manual as an on-chip capability . . . >can it really be done 'automatically'? Semi-automatic. There's a neat bit of hardware on the ASIC called the LINE INTerrupt register (249 Dec). The trick is to remember that, all the time while your code is running, the TV is drawing the picture in raster lines - left to right, top to bottom. Screen lines are numbered 0 to 191, down from the top of the screen. If you OUTput a screen line number to port 249, then the CPU will get an interrupt just before the raster reaches that line number. If you're quick off the mark, you can change a palette colour or two before the start of the next line gets displayed. To stop getting these interrupts, output an invalid number (ie. 192 to 255) to port 249. Maybe this would be a good time to explain the STATUS port too. As soon as you get an interrupt, you can find out what sort of interrupt is was by reading from port 259 (Dec). Bits 0-4 are normally high, but go low depending on the interrupt type: 0 Line int 1 "mouse" int - used in the COMMS interface 2 MIDI IN int 3 FRAME int (50 Hz vertical blank) 4 MIDI OUT int. Bits 5-7 are actually the top half of the keyboard matrix, for all those extra keys which the Spectrum hasn't got... HTH Andrew [1] i.e. the way I would draw a sprite myself... [2] Actually, I'd take it down to about 70, but achieving that is quite complicated again. -- | Andrew Collier | email [EMAIL PROTECTED] | Talk sense to a | Part 2 NatSci | http://mnemotech.ucam.org/ | fool and he +----------------+----------------ICQ:38645805-+ calls you foolish | Selwyn College Student Computer Support Team | -- Euripides
