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: 2879
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: 2410
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
Flying Officer
Posts: 246
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: 2410
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: 824
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 5 times
vsync-auto.zip
(1.41 KiB) Downloaded 5 times

User avatar
NekoNoNiaow
Flying Officer
Posts: 246
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: 824
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: 2410
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
Flying Officer
Posts: 246
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: 2879
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

Post Reply