A possible software alternative to Vsync?
Re: A possible software alternative to Vsync?
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?
Re: A possible software alternative to Vsync?
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?
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?
Re: A possible software alternative to Vsync?
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...
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...
Re: A possible software alternative to Vsync?
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.
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.
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.
- 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.
- 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.
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.
- NekoNoNiaow
- Flight Lieutenant
- Posts: 272
- Joined: Sun Jan 15, 2006 10:08 pm
- Location: Montreal, Canadia
Re: A possible software alternative to Vsync?
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)?
Re: A possible software alternative to Vsync?
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
Maybe later...
Done check http://miniserve.defence-force.org/view ... iew=markup
Routine sync_auto
Re: A possible software alternative to Vsync?
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:
- Attachments
-
- testvsync.dsk.zip
- (43.74 KiB) Downloaded 269 times
-
- vsync-auto.zip
- (1.41 KiB) Downloaded 287 times
- NekoNoNiaow
- Flight Lieutenant
- Posts: 272
- Joined: Sun Jan 15, 2006 10:08 pm
- Location: Montreal, Canadia
Re: A possible software alternative to Vsync?
Thanks Chema!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
Ok, thanks Iss!
Nice, Thanks again.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:
Before I get to try it, have you reached a conclusion regarding VIA drifting compared to VSYNC?
Re: A possible software alternative 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 .NekoNoNiaow wrote: ↑Tue Apr 30, 2019 4:01 am... have you reached a conclusion regarding VIA drifting compared to VSYNC?
Re: A possible software alternative to Vsync?
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...
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...
- NekoNoNiaow
- Flight Lieutenant
- Posts: 272
- Joined: Sun Jan 15, 2006 10:08 pm
- Location: Montreal, Canadia
Re: A possible software alternative to Vsync?
Fantastic, that is good to know. Thanks!
Does this mean that your sources are more recent than Iss's and are in sync with the latest ThomH suggestions?
The waiting loops can probably replaced by a waiting function, that would save a lot of space.
Re: A possible software alternative to Vsync?
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
Basically a reference implementation of the Software VSync
- NekoNoNiaow
- Flight Lieutenant
- Posts: 272
- Joined: Sun Jan 15, 2006 10:08 pm
- Location: Montreal, Canadia
Re: A possible software alternative to Vsync?
I must admit I am still wrapping my head around this method but I will get to it eventually...
In the meantime here are a few additional questions about it:
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)?
-
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).
Re: A possible software alternative to Vsync?
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!
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!
- NekoNoNiaow
- Flight Lieutenant
- Posts: 272
- Joined: Sun Jan 15, 2006 10:08 pm
- Location: Montreal, Canadia
Re: A possible software alternative to Vsync?
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.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?
But I may be completely wrong there.
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.