Re: GO64 tech stuff?

From: Richard Atkinson (Richard.Atkinson_at_cl.cam.ac.uk)
Date: 2000-08-26 15:52:51

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 cbm-hackers-request@dot.tcm.hut.fi.

Archive generated by hypermail 2.1.1.