Some much-needed corrections and further thoughts On Fri, 25 Aug 2000, Richard Atkinson wrote: > I guess there are two situations; setting TEST during the 5 cycle period > where the raster line state machine is refreshing RAM and setting it at > all other times. It's possible that the state machine continues > refreshing; maybe incrementing the counter, maybe not. However, I strongly > suspect that it just reverts to cycle 0 (out of the 63) and does that > access each time. In which case we have to assume DRAM does not get > refreshed. Does setting TEST cause the machine to crash in BASIC? If so, > that might be your explanation. I wrote a short program just now to take 8 lines out of a standard hires screen. The first time I think I caught it in the middle of a badline as it duplicated the current character row on the next row, then I tried a line 4 pixels lower and apart from a flickery artifact on the character where TEST gets set (I think), it worked perfectly. The first time was line 040 and the second 044. Possibly 044 was the badline not 040. Both versions did indeed produce a screen 8 lines shorter, and the standard mode characters were displayed during the 8 cycles TEST was set (as far as I can tell, with the exception of the artifact which seems to affect the whole character, not just one line). So I think the raster line state machine continues to operate as normal during TEST high. Evidently most of the function of the chip (as currently understood in Christian Bauer's document) has to be tested under TEST high, but I think the raster line state machine (ie. not just the horizontal line counter) continues to operate as normal, suggesting that refresh cycles are still made. > Then I realised it might be possible to cause the line counter to reset > mid-frame (as you do directly on the plus/4 to change the screen size), > but without generating frame sync pulses as there is no raster line state > machine operation during TEST bit set. Thus you could perhaps create > "extra" bits of border in an NTSC machine, emulating a 312 line 50 Hz PAL > display. Bingo - 50Hz NTSC for the NTSC games people to try :) I should clarify this; frame sync pulses ought not to be produced in the middle of a line while TEST is high, because there just isn't enough time. *However*, the vertical line state machine may well produce a blanking pulse during the line-cycles where a frame sync pulse would be produced in normal operation, and this may be the problem Nicolas encountered. This is probably a function of both line number and cycle number, so what we need is a complete map of the VIC-II(e) display period; blank, black level, video, border, everything. Richard -- Richard Atkinson Software Engineer Tenison Technology EDA Ltd http://www.tenisontech.com/ - This message was sent through the cbm-hackers mailing list. To unsubscribe: echo unsubscribe | mail email@example.com.
Archive generated by hypermail 2.1.1.