A possible software alternative to Vsync?
A possible software alternative to Vsync?
If the ROM was modified to record in RAM the VIA's T1 current value on bootup, would this value be related to the current raster position?
Whilst this may seem a wild notion, if both ULA and VIA start up at same time, then ULA will obviously scan screen memory and the VIA will count down T1.
Any subsequent disc or tape activity should not upset T1 since whilst irq's are disabled, T1 and the via will continue to count and reset to latch values.
However one crucual question has to be, does the via bootup with any value or a random latch value?
Whilst this may seem a wild notion, if both ULA and VIA start up at same time, then ULA will obviously scan screen memory and the VIA will count down T1.
Any subsequent disc or tape activity should not upset T1 since whilst irq's are disabled, T1 and the via will continue to count and reset to latch values.
However one crucual question has to be, does the via bootup with any value or a random latch value?
This is an interesting proposition...
You suggest that since the timer starts at the same time as the ULA, a few instructions at the beginning of the cpu execution should be enough to have the VIA synchronized with the ULA....
I might have a try at this, time to try this 32K flash eprom I bought...
However, in a disc configuration, the microdisc eprom would have to be changed instead of the oric rom...
Nice idea, Jon !
You suggest that since the timer starts at the same time as the ULA, a few instructions at the beginning of the cpu execution should be enough to have the VIA synchronized with the ULA....
I might have a try at this, time to try this 32K flash eprom I bought...
However, in a disc configuration, the microdisc eprom would have to be changed instead of the oric rom...
Nice idea, Jon !
-
- Flight Lieutenant
- Posts: 322
- Joined: Thu Sep 21, 2006 7:45 pm
- Location: 26000 Valence, FRANCE
- Contact:
the VIA timer doesn't "start" on its own, it has to be programmed AFAIK, which is what the ROM does, so you'd have to account the cycles up to the opcode that starts the timer.
On other options, we can't probably check if opcodes take longer to run as the VIA does its own reads when the CPU is idle on the bus and doesn't generate wait cycles.
Another one could be to play with the 60Hz attribute maybe ? I guess it doesn't restart the screen scan... but maybe we can get the ULA to synchronize to us instead of us to it![Smile :)](./images/smilies/icon_smile.gif)
On other options, we can't probably check if opcodes take longer to run as the VIA does its own reads when the CPU is idle on the bus and doesn't generate wait cycles.
Another one could be to play with the 60Hz attribute maybe ? I guess it doesn't restart the screen scan... but maybe we can get the ULA to synchronize to us instead of us to it
![Smile :)](./images/smilies/icon_smile.gif)
Re:
A decade late, but I think there's quite a lot of merit to this idea. Has anybody explored?mmu_man wrote:Another one could be to play with the 60Hz attribute maybe ? I guess it doesn't restart the screen scan... but maybe we can get the ULA to synchronize to us instead of us to it
Here's how I see it:
Per the ULA guide, a 50Hz display has 312 lines, a 60Hz display has 260. So that's a difference of 52.
Assume you're currently in HIRES mode, at 50Hz. Pick a screen location, Q. Suppose you put a switch to 60Hz attribute there, waited N cycles, then write a switch to 50Hz attribute instead, then waited a frame.
If the Oric was within the N cycles before Q then it'll display a single 60Hz frame in its stream. So it'll shorten one frame by 52 lines — it'll skip 52 lines. If the Oric wasn't within the N cycles before Q then it won't do anything. So starting with a frame-length timer of unknown alignment, you can use this method repeatedly to exclude 52-line regions of the screen from the possibility set until you get to one that is definitely outside of the pixel area.
E.g. if the first line with pixels is line 0:
- set the very first cell on screen to be a switch to 60 Hz, wait for 112 lines, set it to 50Hz, wait a frame;
- now if your interrupt was happening outside of the top 200 then it has been pushed forwards 52 lines, so no matter what the original machine state was, you can now be sure your interrupt is *not* in lines 200–252;
- do the same thing again;
- now you know that your interrupt is definitely somewhere in lines 0–200;
- this time, set the 60Hz attribute on the first column of line 52 and wait 52 lines, then the frame;
- now your interrupt is definitely in lines 52–200;
- do the same thing again three times;
- now your interrupt is definitely occurring somewhere between line 208 and line 260;
- ... so now you can use it definitely to get at least 52 lines of retrace painting, and possibly as many as 104.
Does that make sense? Can somebody who has actually written an Oric program before sanity check it? I haven't spent a lot of time considering it, there may be a flaw I'm missing.
Re: A possible software alternative to Vsync?
Okay. This is too technical, but looks plausible to me. I still need to think about it, but I think I grasped idea.
I am not a hardware guy, so maybe someone more experienced than me should answer this. Anyway making a small testing and program should not be difficult.
Interesting idea indeed!
I am not a hardware guy, so maybe someone more experienced than me should answer this. Anyway making a small testing and program should not be difficult.
Interesting idea indeed!
-
- Flight Lieutenant
- Posts: 322
- Joined: Thu Sep 21, 2006 7:45 pm
- Location: 26000 Valence, FRANCE
- Contact:
Re: A possible software alternative to Vsync?
Interestingly, I wrote some python code to play with the idea last june:
http://miniserve.defence-force.org/svn/ ... autovsync/
It shows it's possible to limit the difference to 52 lines.
http://miniserve.defence-force.org/svn/ ... autovsync/
It shows it's possible to limit the difference to 52 lines.
Re: Re:
@mmu_man... What does that picture show? I was not able to understand it..
![Smile :)](./images/smilies/icon_smile.gif)
Could this method work on text mode too? Will this software sync be lost if done in HIRES, then switch to TEXT or viceversa? I guess that it won't as long as you don't play with the 50/60Hz switch...
If I understood correctly, the oric image is from line 0 to 199 for HIRES, then 200-223 for the three lines of text, then 88 lines up to 311 are for lower and upper borders (I guess 44 each or so, so thee VSync should occur halfway, am I right?). If this method works the IRQ will end up triggering at least at line 208, which is outside HIRES area, leaving between 104*64us and 52*64us of free time for updates. That is 3328 cycles in the worst case, but could be many more if you have a score panel on the top part of the screenThomH wrote:[*] now your interrupt is definitely occurring somewhere between line 208 and line 260;
[*] ... so now you can use it definitely to get at least 52 lines of retrace painting, and possibly as many as 104.[/list]
![Smile :)](./images/smilies/icon_smile.gif)
Could this method work on text mode too? Will this software sync be lost if done in HIRES, then switch to TEXT or viceversa? I guess that it won't as long as you don't play with the 50/60Hz switch...
-
- Flight Lieutenant
- Posts: 322
- Joined: Thu Sep 21, 2006 7:45 pm
- Location: 26000 Valence, FRANCE
- Contact:
Re: A possible software alternative to Vsync?
The picture shows the delta between the actual line number and the IRQ if it was in perfect sync, over time (Y), and on each possible start line (X).
Ie., for each possible line the ULA is on when we try to sync, on X, it shows how close we get to syncing it back to the IRQ over time (Y).
That is, if my python model is correct.
Ie., for each possible line the ULA is on when we try to sync, on X, it shows how close we get to syncing it back to the IRQ over time (Y).
That is, if my python model is correct.
Re: Re:
Yes, it should also work in text mode.Chema wrote:Could this method work on text mode too? Will this software sync be lost if done in HIRES, then switch to TEXT or viceversa? I guess that it won't as long as you don't play with the 50/60Hz switch...
Example pseudocode:
- establish 50Hz graphics mode, wait at least a frame;
- write 28 to address 0xa000, wait 7168 cycles;
- write 30 to address 0xa000, wait 16640 cycles;
- write 28 to address 0xa000, wait 7168 cycles;
- write 30 to address 0xa000, wait 16640 cycles;
- (you have now eliminated lines 200–311 as possibilities, pushing anyone that was there into 0–111)
- write 28 to address 0xa820, wait 3328 cycles;
- write 30 to address 0xa820, wait 16640 cycles;
- (you have now also eliminated lines 0–51 as possibilities)
- write 28 to address 0xba00, wait 3328 cycles;
- write 30 to address 0xba00, wait 16640 cycles;
- (you have now also eliminated lines 52–103 as possibilities)
- write 28 to address 0xc700, wait 3328 cycles;
- write 30 to address 0xc700, wait 16640 cycles;
- (you have now also eliminated lines 104–155 as possibilities, put potentially repopulated the range 200–207)
- write 28 to address 0xd1ff, wait 3328 cycles;
- write 30 to address 0xd1ff, wait 16640 cycles;
- (you have now eliminated [pixel parts of] lines 156–199 as possibilities, but repopulated 208–251)
- start a 19968 cycle period interrupt timer.
So I don't have a development kit set up but I imagine it being a simple subroutine of not many bytes that runs for 127,488 cycles then sets up the VIA and returns. It's all over in a bit more than eight 50Hz frames.
If it fails then probably 60Hz mode is not (reliably?) 260 lines long. But if it's something that isn't a multiple of 52 then we might be able to do an even better software sync so that might turn out to be good news, not bad.
Re: Re:
In regard of the number of scan-lines I manually counted and here are the results:ThomH wrote:... probably 60Hz mode is not (reliably?) 260 lines long
- 50Hz mode has 308 scan lines
- 60Hz mode has 260 scan lines
The vertical retrace time is equal for both modes and is 260 microseconds.
Re: A possible software alternative to Vsync?
Looking forward for somebody to make a small tech demo of that ![Smile :)](./images/smilies/icon_smile.gif)
![Smile :)](./images/smilies/icon_smile.gif)
Re: A possible software alternative to Vsync?
@Dbug: I want to be somebody, Be somebody soon... ![Wink ;)](./images/smilies/icon_wink.gif)
But firstly, congrats to ThomH - your idea works!
I used your pseudo-code and made little demo. To check the result I used part of F.Frances great calibration routine -
simply it's proven and can be used as reference.
Here are the results: after auto-vsync only these THREE positions of the color bar are possible! I used Oricutron to print the offset of the timer when it starts new frame, values are respectively:
best result (first picture) >17000 uSec, <3500 uSec and >13000 uSec.
On real hardware results are very close...
Here are DSK and TAP versions for download: @ThomH: The pseudo-code has many errors, some of them are very well hidden
.
@Chema: ...That is 3328 cycles in the worst case... Actually the free time for updates should be lot more - it's known as "chasing (racing) the beam" - you stat drawing immediately after the beam and time for update depend on drawing's speed. I don't know why, but this remind me of Achilles and the tortoise.![Smile :)](./images/smilies/icon_smile.gif)
I'll post the source of the auto-vsync routine, but I want to test it more.
All suggestions, ideas and improvements are greatly appreciated!
![Wink ;)](./images/smilies/icon_wink.gif)
But firstly, congrats to ThomH - your idea works!
I used your pseudo-code and made little demo. To check the result I used part of F.Frances great calibration routine -
simply it's proven and can be used as reference.
Here are the results: after auto-vsync only these THREE positions of the color bar are possible! I used Oricutron to print the offset of the timer when it starts new frame, values are respectively:
best result (first picture) >17000 uSec, <3500 uSec and >13000 uSec.
On real hardware results are very close...
Here are DSK and TAP versions for download: @ThomH: The pseudo-code has many errors, some of them are very well hidden
![Wink ;)](./images/smilies/icon_wink.gif)
- The correct number of scan lines for your algo are: for 50Hz = 312 (i.e 308+4 for v-retrace) and for 60Hz = 264 (i.e 260+4 for v-retrace)
- therefore the correct difference is: 312-264=48, instead of 52
- screen addresses like 0xc700 and 0xd1ff have nothing in common with the screen...I know, you wrote pseudo-code in a hurry mixing 40 and 64 as multipliers
- screen_offset=0xa000+40*line_number
- time_offset=64*line_number
@Chema: ...That is 3328 cycles in the worst case... Actually the free time for updates should be lot more - it's known as "chasing (racing) the beam" - you stat drawing immediately after the beam and time for update depend on drawing's speed. I don't know why, but this remind me of Achilles and the tortoise.
![Smile :)](./images/smilies/icon_smile.gif)
I'll post the source of the auto-vsync routine, but I want to test it more.
All suggestions, ideas and improvements are greatly appreciated!