A possible software alternative to Vsync?

If you want to ask questions about how the machine works, peculiar details, the differences between models, here it is !
How to program the oric hardware (VIA, FDC, ...) is also welcome.
ThomH
Flying Officer
Posts: 149
Joined: Thu Oct 13, 2016 9:55 pm

Re: A possible software alternative to Vsync?

Post by ThomH » Sat Nov 26, 2016 3:24 am

312 and 264 are even better: the greatest common divisor of the two is 24 so unless I'm having a complete failure of logic you should be able to box yourself in to a 24-line period?

User avatar
Dbug
Site Admin
Posts: 2946
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: A possible software alternative to Vsync?

Post by Dbug » Sat Nov 26, 2016 11:23 am

Nice, so basically now we are in three possible states after auto-syncing, instead of 300+ possibilities.

I was wondering: What actually does define the parameters of the synchronisation of the computer with the screen, and what can impact it?
- On startup, when booting the machine, are we synced to a know value, or is it impacted by the power circuitry, the tv, random parameters, etc...
- Does pressing the reset button change the synchronisation values?

User avatar
Chema
Game master
Posts: 2466
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: A possible software alternative to Vsync?

Post by Chema » Sat Nov 26, 2016 1:01 pm

Great that someone is testing this! If the idea works it would be incredibly useful for making games and demos!

Now a couple of things I don't understand. For the description I understood that after the algorithm, the IRQ would be triggered somewhere between lines 208 and 260, the latter being outside the image area and all of them at the bottom of the screen.

Why the middle screen shows the raster in the middle then? And why the rightmost image shows it so up (I think it is well above line 208)?

And yeah, I know about racing the beam. It means updating the screen top to bottom very carefully to keep behind the raster, and by lines, not by columns. I don't remember why I had some problems when trying it in Oricium, though...

ThomH
Flying Officer
Posts: 149
Joined: Thu Oct 13, 2016 9:55 pm

Re: A possible software alternative to Vsync?

Post by ThomH » Mon Nov 28, 2016 7:47 pm

The numbers originally proposed, even if I hadn't mixed up multiplying by 40 and multiplying by 64, were predicated on a 260-line 60Hz frame. It turns out it's 264 lines. So the original arithmetic is based on false accounting, though the premise is still solid: leave a 60Hz attribute visible in a screen location for n cycles, then change it to a 50Hz attribute and any machines that were in the n cycle region of the display prior to that attribute will skip 312-264=48 lines.

So if you have a particular target zone that you want all Orics to be in, you can repeatedly perform that process to shift those that are in the wrong until all are in the right.

Having thought more about the "what offset does startup inherently leave us at?" question, I've come to the conclusion that it doesn't matter. Neither disk nor tape offers a guaranteed loading speed because both are subject to flutter and wow (and, with a tape you don't know how far the user rewound it; with a disk you don't know which track the disk drive was at when power was first applied, so don't know how long the initial seek to track zero took, or what the initial rotation was). So unless your title is on ROM I don't think you could safely do anything with that knowledge.

EDIT:
based on 312 and 264, the following is possibly correct:

Step 1: eliminate all Orics currently in the period without pixels.
  • write a 60Hz attribute at the start of the first line, leave it up for 88 lines, replace with a 50Hz attribute;
  • wait a 60Hz frame length;
  • do the same thing again.
Step 2: collect all Orics in the final 48 lines of the display.
  • write a 60Hz attribute at the start of line 176, leave it up for 176 lines, replace with a 50Hz attribute;
  • wait a 60Hz frame length;
  • do the same a further three times.
Step 3: bounce those Orics in the top half of the final 48 lines into the bottom.
  • write a 60Hz attribute at the start of the first text line, leave it up for 24 lines, replace with a 50Hz attribute;
  • wait a 60Hz frame length;
  • write a 60Hz attribute to same place, leave it up for 288 lines, replace with a 50Hz attribute;
  • repeat that a further five times.
All Orics should now be in the bottom three lines of the display. Start your VIA interrupt. And you can use ordinary VIA timing methods to move its location if you don't want to be in the lower 24 lines.

As before, typed directly from the top of my thoughts, not checked. Hopefully close to correct. I count 12 instances of "wait a 60Hz frame length", which is 12 waits of 264 lines, plus non-frame waits of (6*288 + 24 + 4*176 + 2*88) = 2632 lines. For a total of 5800 lines. So the whole process should take 371,200 cycles. So it's a blank screen for 40% of a second. I think you'd get away with it.

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: A possible software alternative to Vsync?

Post by NekoNoNiaow » Sat Apr 27, 2019 2:51 am

Reading this after @Chema sent me to this thread, I am driven to ask the inevitable questions:
  • has anyone implemented the last auto-sync scheme proposed by ThomH?
  • if so, has it been used in any game/demo successfully?
  • even more importantly: is the VIA timer precise enough to avoid drifting or is it impossible to stay firmly synced to the actual vblank?
    And consequently:
    • if drifting is inevitable, can it be re-corrected using a similar technique (ideally, while continuing to display the current game/demo)?

User avatar
Chema
Game master
Posts: 2466
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: A possible software alternative to Vsync?

Post by Chema » Sat Apr 27, 2019 11:42 am

I tried an implementation someone (iss?) sent me in Blake's 7, to avoid problems with the cursor. You can check the sources in the repo. I am not at home now, so I can't do it, sorry.

Maybe later...

Done :) check http://miniserve.defence-force.org/view ... iew=markup

Routine sync_auto

:)

User avatar
iss
Squad Leader
Posts: 871
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: A possible software alternative to Vsync?

Post by iss » Sat Apr 27, 2019 12:57 pm

Chema wrote:
Sat Apr 27, 2019 11:42 am
... someone (iss?)
iss(!) ;)

Use the original source code (attached vsync-auto.zip). Please revise it, I think I didn't update it to the last ThomH's post.
I will check it too later, but now I'm in the middle of something ... important ;).

Use the test example (attached testvsync.dsk.zip) - pressing 'space' from-time-to-time you can collect statistics when vsync occurs relative to current VIA T1 timeout. My Oricutron development builds are intended exactly for this task:
vsync1.png
Attachments
testvsync.dsk.zip
(43.74 KiB) Downloaded 23 times
vsync-auto.zip
(1.41 KiB) Downloaded 28 times

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: A possible software alternative to Vsync?

Post by NekoNoNiaow » Tue Apr 30, 2019 4:01 am

Chema wrote:
Sat Apr 27, 2019 11:42 am
I tried an implementation someone (iss?) sent me in Blake's 7, to avoid problems with the cursor.[snip]
Done :) check http://miniserve.defence-force.org/view ... iew=markup
Thanks Chema!
iss wrote:
Sat Apr 27, 2019 12:57 pm
Use the original source code (attached vsync-auto.zip). Please revise it, I think I didn't update it to the last ThomH's post.
Ok, thanks Iss!
iss wrote:
Sat Apr 27, 2019 12:57 pm
Use the test example (attached testvsync.dsk.zip) - pressing 'space' from-time-to-time you can collect statistics when vsync occurs relative to current VIA T1 timeout. My Oricutron development builds are intended exactly for this task:
Nice, Thanks again.
Before I get to try it, have you reached a conclusion regarding VIA drifting compared to VSYNC?

User avatar
iss
Squad Leader
Posts: 871
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: A possible software alternative to Vsync?

Post by iss » Tue Apr 30, 2019 7:51 am

NekoNoNiaow wrote:
Tue Apr 30, 2019 4:01 am
... have you reached a conclusion regarding VIA drifting compared to VSYNC?
IMO, there should be no drifting - at least because both signals are generated from the same source clock 12MHz and yes, VIA clock is stable and precise enough :).

User avatar
Chema
Game master
Posts: 2466
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: A possible software alternative to Vsync?

Post by Chema » Tue Apr 30, 2019 9:36 am

Thanks iss. I knew it was you :) That being said, I had to change something... probably the VIA counter value. In my sources you can check that.

I also had a different value in the status line when I tried to sync with oricutron's sync routine and even with hardware vsync hack. Don't know exactly why. I should have another look.

It would be nice to have a smaller code doing the same thing... I put this in an area which was later overwritten, but anyway...

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: A possible software alternative to Vsync?

Post by NekoNoNiaow » Tue Apr 30, 2019 11:41 pm

iss wrote:
Tue Apr 30, 2019 7:51 am
IMO, there should be no drifting - at least because both signals are generated from the same source clock 12MHz and yes, VIA clock is stable and precise enough :).
Fantastic, that is good to know. Thanks!
Chema wrote:
Tue Apr 30, 2019 9:36 am
Thanks iss. I knew it was you :) That being said, I had to change something... probably the VIA counter value. In my sources you can check that.
Does this mean that your sources are more recent than Iss's and are in sync with the latest ThomH suggestions?
Chema wrote:
Tue Apr 30, 2019 9:36 am
It would be nice to have a smaller code doing the same thing... I put this in an area which was later overwritten, but anyway...
The waiting loops can probably replaced by a waiting function, that would save a lot of space.

User avatar
Dbug
Site Admin
Posts: 2946
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: A possible software alternative to Vsync?

Post by Dbug » Wed May 01, 2019 8:30 am

If somebody can come up with a clean, minimal example, I guess we could add it to the Sample folder of the OSDK.
Basically a reference implementation of the Software VSync

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: A possible software alternative to Vsync?

Post by NekoNoNiaow » Tue Jul 16, 2019 5:28 am

I must admit I am still wrapping my head around this method but I will get to it eventually... :lol:

In the meantime here are a few additional questions about it:
  • has anyone validated that it works on a real Oric?
    And by this I mean: have you been able to place the CIA interrupt anywhere you want during display ? (cf (1))
  • If answering yes to the above, does this require any user intervention such as reacting to something written on screen?
    Or does this happen automatically?
  • Finally, once implemented, have you verified that there was no drift over time (ISS answered that this was stable but maybe there are things on real Orics which may cause a drift of some kind)?
(1) the reason I ask this is that depending on how games draw on the screen they will want to control when the interrupt is received:
  • Games which draw line by line from the top will want to race the beam while staying immediately *behind* it: this way what they draw will only be visible on the next frame and there will be no tearing.
    These games want to receive the interrupt immediately as the first line of the screen is drawn.
  • Games which draw column by column will try to do that while the beam has left the drawing area. This way they can modify the screen while it is not displayed anymore. Of course this means that they have less time than the games which draw line by line but for some games that can be viable.
    These games want to receive the interrupt when the last line starts being drawn (or when it finishes).
Thanks!

User avatar
Chema
Game master
Posts: 2466
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: A possible software alternative to Vsync?

Post by Chema » Tue Jul 16, 2019 12:51 pm

I tested the routine in my real Oric. A very limited test, however. The cursor in Blake's 7 flickered when being moved so I put the routine in my code trying to get a sync with the vertical retrace and avoid it. It worked, but only partially.

I did not modify the routine itself, but I think I had to modify the counter value in the VIA to 19966 because there was a drift and, after some time, the cursor started flickering again. In addition I had made some tests for this value in Oricium (where there was a user calibration for the vertical line, but the number of clock cycles was still there) and the value I came up with was 19966.

Now, I don't know why 19966. There are 33 cycles missing. I know some are lost due to the interrupt handling, but 33?

I did not study the routine itself, so I am not sure how it works, so I never attempted to optimize it. The possibility of stating the vertical line where you want the IRQ to occur, would be indeed fantastic!

User avatar
NekoNoNiaow
Flight Lieutenant
Posts: 272
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: A possible software alternative to Vsync?

Post by NekoNoNiaow » Fri Jul 19, 2019 2:27 am

Chema wrote:
Tue Jul 16, 2019 12:51 pm
I tested the routine in my real Oric. A very limited test, however. The cursor in Blake's 7 flickered when being moved so I put the routine in my code trying to get a sync with the vertical retrace and avoid it. It worked, but only partially.
[...]
Now, I don't know why 19966. There are 33 cycles missing. I know some are lost due to the interrupt handling, but 33?
My knowledge of 6502, 6522 and Oric's interrupts in general is quite limited so a cursory look at Blake's 7's IRQ routine did not allow me to pinpoint whether these 33 cycles would be justified. Moreover, if I understand correctly the mode of operation of the 6522, the timer should restart counting immediately after reaching zero and triggering the interrupt anyway so the timing of the interrupt routine should not really matter.
But I may be completely wrong there.
Chema wrote:
Tue Jul 16, 2019 12:51 pm
I did not study the routine itself, so I am not sure how it works, so I never attempted to optimize it. The possibility of stating the vertical line where you want the IRQ to occur, would be indeed fantastic!
I have the intuition that there might be a few ways to obtain that by cleverly requesting some input from the user. I have not yet figured out how to do that but when (if ?) I (ever ?) understand the principle of the auto vsync, I will give it a try. ;)

Post Reply