VBLANK / VSYNC PIO QUESTION

[Graham72]

I'm stuck on how vertical blank and vsync reach software.

What I've read so far: the Alpha Plus  and 256TC schematics. On both boards PIO B bit 4 is the serial RXD line, not vsync. PB7 goes through a link (RTC IRQ on both; the Alpha Plus also offers the 6545 LPEN net). On the 256TC, VSYNC is ? an off-sheet signal and I couldn't see it reach the PIO.

Right now the emulator drives port 0x0C bit 5 from one signal, a fixed window at the start of each frame (about 15% in the build I checked). That is an approximation. When I tried a true short VSYNC-width pulse instead, the CF shell's wait ended immediately and its screen never painted.

As Someone notes in an earlier thread I have found disk services have lost data if PB7 is wired.

This is all way above my pay grade so looking for answers. Thanks so much, Graham

[MbeeTech]

I'm stuck on how vertical blank and vsync reach software.

There are 2 methods of getting the 50Hz VSYNC / VBLANK timing into software.
The first one is via polling the 6545 status register to wait for the vertical retrace period. Obviously not interrupt driven.

Second is via interrupt from the PIO only if the link is set (or manual wire link in earlier models that don't have the link).
The link connects VSYNC to the PIO Port B bit 7, as you have mentioned.
This method was only used on the Non-Disk machines (IE: PC85).
On the premium (Alpha Plus) baseboard, there is a 2 x 3 jumper block to connect 1 of 3 sources to the PIO.
RTC, Network Direction (used as an output in this case), and VSYNC. Only 1 of these functions can be selected.
In the PC85 (Rom based machine) VSYNC is connected to provide a Pseudo Real Time Clock.

From the above, only the first method is suitable for properly using the video refresh timing on the Microbee across all models.

As Someone notes in an earlier thread I have found disk services have lost data if PB7 is wired.

Someone is absolutely correct. As the disk interface is non-interrupt driven (Software polled), any serviced interrupt that is not masked
during disk activity will have the potential to have buffer overruns on disk reads (new byte arrives within the disk controller before the last
byte has been read out), or underruns in the case of writes.

[Graham72]

Thanks Ewan, got it. I've created a button to switch between sources. Juggling PC85, CF and FUZIX in one build now. Hopefully Ive got it figured out now, cheers g