Re: CRTC timing for VSYNC, 4032 vs 8032

Hi Olaf,

Am 23.01.24 um 20:18 schrieb Rhialto:
> 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.


I have to check them out at some point :-)

>
>>> 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.

Very nice approach! I like it.

> 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.

I guess you've seen my deductions here:
http://www.6502.org/users/andre/hwinfo/crtc/internals/index.html ?

Did you also see the "internals" picture of the 68B45 I have there too?
http://www.6502.org/users/andre/hwinfo/crtc/internals/68B45-10.png

But yes, I've read about what they do with cycle-exact timing on the CPC
and I think this is very crazy...

> 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.

Yeah that was cool. I quickly got what is happening when I saw that the
text was displayed backwards mirrored.

However, that should even be easy to implement in your approach. Just
make the pre-fetch buffer 128 chars long (IIRC the longest possible char
line), and do all the other calculations as they are, just with a longer
buffer (IFF R1 horizontally displayed is set that large)

Then render the "out-of-screen" part of that buffer on this (or maybe
the next?) scanline in reverse direction and stretched IIRC, adapting
the colours appropriately.

>> André
> -Olaf.


Best  regards,

André