Re: CRTC timing for VSYNC, 4032 vs 8032

On Tue 23 Jan 2024 at 12:24:22 +0100, A. Fachat wrote:
> Hi Olaf,
> 
> Am 16.10.23 um 21:25 schrieb Rhialto:
> > It seems the PET is getting more popular! There are now several demos
> > (and games) that depend on a cycle-exact timing of writing data to
> > screen memory, so it can swap characters before their next scan line is
> > displayed.
> > 
> > VICE got pretty good at emulating this. First I did it for the pre-CRTC
> > models, so the Cursor HI-RES program works great.
> Cool, that's great to hear! I was only able to do a basic emulation back
> then, even though I added some of the effects e.g. from varying the
> HSYNC. Do these still work?
> http://www.6502.org/users/andre/hwinfo/crtc/pet/index.html

Last time I tried them they still worked as well as before (I think
there were one or two that didn't work?). There may be slight
differences in positioning in the window though. In an earlier round of
changes I made some adjustments in that area. I think it was to make
various 40-column programs on the 8032 work.

> > Can somebody think of any reason why the VSYNC would start a cycle
> > earlier on the 8032 compared to the 4032?
> 
> As Commodore used the "universal" board for 4032 and 8032 at some point,
> and that was derived from the 8032 CRTC board, the hardware is basically
> the same.
> 
> HSYNC/VSYNC signals directly go from the CRTC to the output. DE (Display
> Enable) is delayed by at least one cycle (and if I read /SR correctly)
> even a second one. Those are needed by the hardware to have the time to
> a) read byte from video memory, b) pass that through the character ROM
> to create the bitmap.
> 
> So, HSYNC/VSYNC are - I think - two cycles off (early) the actual screen
> display, as the data needs to be processed.

Ah, that could possibly explain one thing I slightly wondered about.

Context: the way I implement the beam-racing, is that at the start of a
raster line, the screen memory for one text line is copied to a prefetch
buffer. If nothing interesting happens, then the code that runs at the
end of the raster line renders the prefetch buffer to the emulator's
bitmap.  (Before this, it was rendered directly from screen memory at
that time)

If there is a store to screen memory, this gets routed to
crtc_update_prefetch() in crtc/crtc.c, and then it is calculated where
the video beam is. If the beam is on one of the scan lines corresponding
to the memory location, and it is deemed that the beam has not reached
that location yet, then the value is also written to the prefetch
buffer. So the new character (or at least one scan line of it) gets
rendered to the bitmap.

In the other case, the prefetch buffer is left unchanged, and only the
regular screen memory location is affected. The old character is
rendered.

So the thing I was slightly wondering about was that it seemed that the
beam could be rather far advanced and still the change would get
displayed. It felt like it allowed for a cycle too long. An extra delay
of 1 cycles somewhere could explain such a thing. I had already taken 1
cycle of delay into account for look-up in the character ROM.

> Indeed there are differences in that area. Hm but looking them up I am
> not sure they are in the correct area. SOME(!) CRTC can skew Display
> Enable and Cursor (not used on the PET) by one or two cycles. 
> http://6502.org/users/andre/hwinfo/crtc/diffs.html
> 
> But as the hardware does the delay itself, there is no need to set it,
> and adding a delay would actually put display enable and character data
> "out of phase".

I did some research into other computers using the CRTC (such as the BBC
micro, Amstrad CPC) and people there really use weird tricks with the
CRTC. And they discovered too that different brands work slightly
differently for various edge cases... (for example,
https://www.cpcwiki.eu/forum/programming/crtc-detailed-operation/ )
currently we could not emulate a lot of that, I fear, even if we stick
to the Commodore/MOS version.

One thing we certainly can't emulate right now is this:
https://www.youtube.com/watch?v=w9DfLcCqpnU
I saw it live at the Vintage Computer Festival Berlin... it displays
text (backwards) during horizontal retrace, which is something we're
definitely not prepared for.

> André
-Olaf.
-- 
___ Olaf 'Rhialto' Seibert                            <rhialto/at/falu.nl>
\X/ There is no AI. There is just someone else's work.           --I. Rose