Article 59542 of comp.sys.cbm: Path: news.acns.nwu.edu!newsfeed.acns.nwu.edu!math.ohio-state.edu!howland.erols.net!www.nntp.primenet.com!nntp.primenet.com!mr.net!news.netins.net!usenet From: phdss@netins.net (Brett Tabke) Newsgroups: comp.sys.cbm Subject: Re: 2 VDC questions Date: Fri, 06 Dec 1996 16:50:10 -0500 Organization: Professional Hybrid Development Software Systems Lines: 139 Message-ID: References: <32A8709D.7148@fab.net> Reply-To: phdss@netins.net NNTP-Posting-Host: worf.netins.net Eric Christopherson wrote: EC> 1. Is it possible to get a smaller color cell size than 8x2 with EC> the 128's VDC? If so, how? EC> 2. Is it possible to use raster interrupts with the VDC? If so, how? EC> Eric Christopherson Sorry Eric, AFAIK, it is a big *no* to both questions (a real bummer). However you can test the vertical blanking period (VBP) and make some screen adjustments while the VDC is not actively displaying. With a fair to good routine you can sync the VBP and time out screen changes based on the previous VBP. By using a block copy routine to copy predefined shapes within VDC memory to the screen, you can perform fairly good looking sprite imitations. Certainly not as smooth, but block copy is quite fast and can move more data than a simple sprite size chuck. I don't mean to spew a long reply at you, but here is part of an idea outline for a C=Hacking article I started but never quite got finished. ; ------------------------------------------------------------- Tricks to speeding up overall VDC display speed: - Reduce the hb of the dram refresh rate (reg 36) to zero (there is still a hard coded low byte of the refresh rate). It results in a 20% overall speed increase. This increase can be seen in ready mode. List a long basic program and time it - then set the HB of the vdc refresh rate to zero and list the program again - instant bolt on speed improvement. - Reduce the number of visible columns to around 60. Another 20%. - Reduce the number of visible rows. (major increase). The above 3 suggestions hold true for both text and graphics modes. With the high byte dram refresh rate reduced to zero, it has been my experience that you can write or read 8 consecutive bytes to or from the VDC without checking the update status register! After 8 bytes the next byte written is lost. Block Copying: The usage of the block copy feature is incredibly fast and not to be under estimated. You can recopy the entire visible screen at near 10-11 frames a second. If you reduce the size of the screen and reduce the size of data segments to be copied (say 10cols by 10 rows or 80x80 pixels) you can approach 30 updates a second (very suitable for animation) Granted, if you restrict yourself to a 16k VDC setup, obviously there is going to be some updating from the 128 side, that would bring everything to a screeching halt. Using block copy for speed, takes some experimenting. Here are some of the things I've learned through trial and error: - Try to block copy data in multiples of 8. It takes just as long to copy 9 bytes as it does 15 bytes; but 8 bytes is much faster than 9 bytes. Evidently there is an internal bit mask operation where the VDC must calc the remainder off a multiple of 8. - It takes longer to setup and copy non-consecutive columns that it does to copy the whole set of rows. For example, suppose you want to copy columns 5 through 10 on rows 15 to 20. The destination is the screen and the source is elsewhere in VDC memory. To copy the 5 rows by 5 columns would take 5 separate block copy commands, but if you were to copy the entire set of rows it would be quicker. This is because all the overhead involved in setting up each of the 5 block copies. To copy all the rows all that is required is to keep resetting the number of bytes to copy. To use this fact to your advantage, you can copy the screen ram out to a separate vdc location, update the ram there, and then block copy the whole chunk back to the screen in one fell swoop. - When working with large numbers of rows to be scrolled via block copy routines, be careful not to copy to many at a time without updating the accompanying attribute ram. The screen will flicker with the text moving with out the colors. (watch pocket writer 2) - If speed is not critical, block copying during the vertical blanking period is much smoother and seamless; however you don't have long to work with. - Block copying is close to 1 byte per cycle (+- 5% overhead). - You don't have to wait for an operation to be completed before doing other things. Such as, you initiate a block copy or fill, and then immediately go do something else on the 128 side - no need to set around and wait for the update status register to get ready. If you copy 255 bytes max, (my guess) is that it takes between 300-400 cycles to complete depending on the state of the vertical blanking period. 400 cycles of code at an average of 3-4 cycles per instruction is over 100+ instructions of code you can execute elsewhere while the VDC does the block copy thing. - Don't get caught in the WRITEREG lie. With 2 exceptions: you do not have to wait for update status to become ready while writing to a register. The first exception is that you can not be in the middle of a block fill or a block copy (must wait till it finishes), and two is you can't do consecutive writes to vdc ram. If you are say, updating the current VDC ram address (reg18/19), then don't worry, write to reg 18 and rock out on 19 without checking the status reg. The exception to the exception: With the dram refresh high byte at zero, IRQ's off, and the VDC status register ready, you can write 8 consecutive bytes to vdc ram without checking the update status! Additionally; if you are doing other things inbetween the writes to ram (such as loading a cpu register with the byte to write) you can usually ignore the update status register entirely! - Don't need more than one color? Switch the VDC into monocolor mode and watch all screen activity speed up easily 50%. It is breath taking, spectacular, most awesome. If you need color, but it is static on the screen, then don't update attribute ram - just update text or gfx ram [In a word? ZED!]. ; ---------------------------------------------------------------- Brett -- Brett Tabke | phdss@netins.net