Re: GO64 tech stuff?

From: Richard Atkinson (
Date: 2000-08-25 18:17:14

(Long - this is one of my favourite subjects!)

On Fri, 25 Aug 2000, Nicolas Welte wrote:

> Anyway, it would be very interesting to know more about that test bit. I am
> not sure if the RAM refresh is corrupted if the test bit is set, because
> raster lines are skipped completely, so the refresh counter probably also
> gets affected.

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've just realised what this hack can be used for - making 60Hz PAL mode
games! Many games consoles can be hacked to run in 60Hz and I've even seen
ST and Amiga games which give you the option of running in 60Hz because
the gameplay is so much better. I experimented with 60Hz PAL modes on the
plus/4 when I was playing around with expanding the screen matrix, and
came to the conclusion that most PAL displays could cope with a 60Hz 262
line (524) display quite happily. I also experimented with a program for
NTSC mode which stretched the screen out to 312 lines (624) 50Hz, but
without a "normal" NTSC television I couldn't verify its operation. The
nice thing about these psuedo-modes was that they worked in colour, even
though the line scanning circuits of the TV would lock onto the timing of
the 'other' TV standard (ie. PAL colour, NTSC-size display).

However, that was of course the plus/4; useful with its weird 2 badline
FLI routines and expanded screen matrix routines, but not relevant to the
C64. Here is an opportunity to do a similar thing on the C128 (or C128 in
64 mode). At first I thought it would only be useful for PAL users to
steal lines and get a 60Hz NTSC display (as has evidently been done,
although I haven't seen the program myself - anyone know a good C64 warez
site? ;) ). You'd steal a few lines from the top border and a few from the
bottom the same way as on the plus/4 and you'd get a 262 line display. 50
lines altogether, of course. You might have to be careful that each of the
128 DRAM refresh rows (256 on a 41256-expanded machine) get refreshed,
which may or may not be a problem depending on whether TEST resets the
DRAM refresh counter or not.

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 :)

> There's also some difference in behaviour between PAL and NTSC chips, the
> NTSC 8564 somehow shows a ghost picture shifted 20 characters to the right
> if the test bit is activated in the end of the lower border. I think the
> ghost picture is only present in every second frame, but I don't know. I
> tested this on a 8564R4 and a 8564R6, so I don't think it is a problem of
> an old chip revision.

How ghostly is this picture? It's important to distinguish between an
artifact of the TV display, caused by *very* non-standard signals at its
input (which may vary completely between TV sets) and an actual VIC-IIe
effect. This also makes me wonder why the original author stopped at
64Hz; was that an estimate of the greatest out-of-spec signal "most" TVs
would accept?

Finally - about the PAL 2 line thing. I think it's fairly obvious that
this is due to PAL phase alternations being locked to the LSB of the
vertical line counter, so the colour circuit always produces one kind of
line (eg.  U)  on odd lines and the other (-U) on even lines. However, the
colour burst is also generated by that state machine, so I suspect any
attempt to shift the whole screen 1 line to get extra colours won't work
(at least, it will produce odd display-dependent effects such as all out
loss of colour) because the colour subcarrier PLL inside the TV decoder
will simply lock onto the "new" alignment of the PAL lines during the
altered parts of the frame (it will take a few lines to re-synchronise)
and then lock back onto the normal alignment at the end of the altered
parts of the frame. You have to always maintain an even number of lines in
each frame because the VIC always reverts to the same PAL line type (eg.
U) at the top of each frame, if it's anything like the TED.

Finally, we can look upon the VIC-IIe as a truly _usefully_ expanded
version of the VIC-II. Hooray for the C128!


Richard Atkinson
Software Engineer
Tenison Technology EDA Ltd

This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail

Archive generated by hypermail 2.1.1.