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.
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

A possible software alternative to Vsync?

Post by Twilighte » Sat Mar 04, 2006 1:31 am

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?

User avatar
Euphoric
Game master
Posts: 99
Joined: Mon Jan 09, 2006 11:33 am
Location: France

Post by Euphoric » Thu Mar 09, 2006 6:43 pm

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 !

User avatar
Euphoric
Game master
Posts: 99
Joined: Mon Jan 09, 2006 11:33 am
Location: France

Post by Euphoric » Mon Apr 03, 2006 1:28 pm

I might have a try at this, time to try this 32K flash eprom I bought...
Argh, I've been fooled by the vendor, it's not a 32Kx8 flash eprom that I have received...

Anyway, I've produced a "synchronizing rom" this week-end, I still have to find an eprom programmer, though...

Cheers,

Fabrice

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

Post by Dbug » Tue Apr 04, 2006 10:04 pm

Cool, I wonder if this can really work, that would be nice :)

User avatar
Euphoric
Game master
Posts: 99
Joined: Mon Jan 09, 2006 11:33 am
Location: France

Post by Euphoric » Wed Apr 05, 2006 8:44 am

Cool, I wonder if this can really work, that would be nice
Indeed, but for now there's something rotten in my kingdom, I had tested the synchro rom on Euphoric and when yesterday I tried it on the real thing, it blocked waiting for the timer1 interrupts... So, double bug to fix... :-(

mmu_man
Flying Officer
Posts: 212
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Post by mmu_man » Fri Sep 22, 2006 11:32 am

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 :)

ThomH
Pilot Officer
Posts: 69
Joined: Thu Oct 13, 2016 9:55 pm

Re:

Post by ThomH » Mon Oct 24, 2016 6:41 pm

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 :)
A decade late, but I think there's quite a lot of merit to this idea. Has anybody explored?

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.
What with 52 being a divisor of both 260 and 312 (no doubt why they picked 260, which is a little short), I've yet to come up with a completely reliable way to improve upon having a 52-line window in which the interrupt will occur. Though stochastically if waited a random amount of time and did the same thing several times and averaged the timing you should end up close to line 230.

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.

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

Re: A possible software alternative to Vsync?

Post by Chema » Mon Oct 24, 2016 8:02 pm

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!

mmu_man
Flying Officer
Posts: 212
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Re: A possible software alternative to Vsync?

Post by mmu_man » Mon Oct 24, 2016 9:47 pm

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.
Attachments
out_l.png

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

Re: Re:

Post by Chema » Tue Oct 25, 2016 9:16 am

@mmu_man... What does that picture show? I was not able to understand it..
ThomH 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]
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 screen :)

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...

mmu_man
Flying Officer
Posts: 212
Joined: Thu Sep 21, 2006 7:45 pm
Location: 26000 Valence, FRANCE
Contact:

Re: A possible software alternative to Vsync?

Post by mmu_man » Tue Oct 25, 2016 5:46 pm

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.

ThomH
Pilot Officer
Posts: 69
Joined: Thu Oct 13, 2016 9:55 pm

Re: Re:

Post by ThomH » Tue Oct 25, 2016 6:57 pm

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...
Yes, it should also work in text mode.

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.
Your timer is now guaranteed to be somewhere between the very first cycle after HIRES pixels ended and 3328 cycles later.

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.

User avatar
iss
Flight Lieutenant
Posts: 448
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Re:

Post by iss » Wed Nov 23, 2016 4:21 pm

ThomH wrote:... probably 60Hz mode is not (reliably?) 260 lines long
In regard of the number of scan-lines I manually counted and here are the results:
- 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.

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

Re: A possible software alternative to Vsync?

Post by Dbug » Thu Nov 24, 2016 10:56 am

Looking forward for somebody to make a small tech demo of that :)

User avatar
iss
Flight Lieutenant
Posts: 448
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: A possible software alternative to Vsync?

Post by iss » Sat Nov 26, 2016 1:22 am

@Dbug: I want to be somebody, Be somebody soon... ;)

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!
testvsync.jpg
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:
testvsync.dsk
(131.5 KiB) Downloaded 27 times
testvsync.tap
(4.81 KiB) Downloaded 27 times
@ThomH: The pseudo-code has many errors, some of them are very well hidden ;).
  • 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. :)


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!

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest