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
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 » Fri Jul 19, 2019 9:43 am

NekoNoNiaow wrote:
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.
I explained myself horribly, Let me try again :)

To get a timer at 50Hz you would start by loading the latch in Timer 1 whit 20000 cycles. In free-run mode, this will create an IRQ each time the counter reaches zero, while the counter re-loads with the latch value automatically. However, if you have a look at the specs (http://archive.worldofdragon.org/images/f/f0/6522.pdf page 8 ) you'll notice that the IRQ signal needs up to 2 extra cycles. So you'd load it with 19998. Great, that's the theory.

Now you run in Oricutron any manual calibration routine (those that use raster bars, such as the one iss posted, Fabrice's original or the one in Oricium). By pressing some keys the timer counters change their value (incrementing or decrementing from 19998). If you try to get a static raster bar anywhere in the screen which does not drift at all with time and then peek in the debugger, you'll notice the timer has the value 19966!. Put 19967 and the bar will start drifting.

You may ask if this occurs too in real hardware. Well, it does. In Oricium the calibration works this way: you press, for instance, the down arrow and the bar starts moving. Press again and the timer decrements and it moves faster. Press up and it will stop at its position (instead of decrementing speed). It does this to ease the manual calibration process, and it does it by setting the timer to 19966. You can do it in a real Oric and you'll see no drift.

Why this value? I just cannot explain.

All the other considerations about the ISR are just important if you want your code to be synchronized with the raster precisely. There is a latency from the moment the IRQ is produced and your ISR code starts running which is something between 7 and 14-15 cycles (http://www.6502.org/tutorials/interrupts.html), and then you may want to count the cycles you lose for acknowledging the IRQ, storing registers, etc.

By the way ISS. I tested your programs and pressing SPACE does not seem to be able to sync correctly with the VSync signal. The bar appears at different places... am I misunderstanding something?

User avatar
Xeron
Emulation expert
Posts: 389
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Re: A possible software alternative to Vsync?

Post by Xeron » Fri Jul 19, 2019 2:09 pm

1 frame isn't 20000 cycles.

Its 64 cycles per scanline x 312 lines = 19968 cycles.

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 » Fri Jul 19, 2019 2:45 pm

Then that explains it all, 19968-2=19966.

Now, I wonder why it is not exactly 20k cycles, that is 50Hz for PAL.

Sorry if it is a stupid question, my knowledge about this is null :)

User avatar
Xeron
Emulation expert
Posts: 389
Joined: Sat Mar 07, 2009 5:18 pm
Contact:

Re: A possible software alternative to Vsync?

Post by Xeron » Fri Jul 19, 2019 4:13 pm

Simple. Real PAL television sends a 312 line field followed by a 313 line field (interlacing). The oric (and other old computers) send a progressive scan image (continuous 312 line frames) which isn't really to PAL spec but TVs would generally sync OK anyway.

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 » Fri Jul 19, 2019 5:42 pm

Ah, okay. Thanks indeed Xeron. There you are. Everything is explained :)

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 23, 2019 1:12 am

Chema wrote:
Fri Jul 19, 2019 9:43 am
To get a timer at 50Hz you would start by loading the latch in Timer 1 whit 20000 cycles. In free-run mode, this will create an IRQ each time the counter reaches zero, while the counter re-loads with the latch value automatically. However, if you have a look at the specs (http://archive.worldofdragon.org/images/f/f0/6522.pdf page 8 ) you'll notice that the IRQ signal needs up to 2 extra cycles. So you'd load it with 19998. Great, that's the theory.
[...]
You may ask if this occurs too in real hardware. Well, it does. In Oricium the calibration works this way: you press, for instance, the down arrow and the bar starts moving. Press again and the timer decrements and it moves faster. Press up and it will stop at its position (instead of decrementing speed). It does this to ease the manual calibration process, and it does it by setting the timer to 19966. You can do it in a real Oric and you'll see no drift.
Gotcha! That makes perfect sense, thank you for the explanation.
Chema wrote:
Fri Jul 19, 2019 9:43 am
By the way ISS. I tested your programs and pressing SPACE does not seem to be able to sync correctly with the VSync signal. The bar appears at different places... am I misunderstanding something?
I noticed the same behavior when running ISS's calibration program.
I assume that this is due to the fact that the calibration routine does not eliminate all possibilities : there are several possible regions of the screen where the beam can be present after it is run.

At least if I understand ThomH's explanation. :lol:

User avatar
Symoon
Archivist
Posts: 1643
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: A possible software alternative to Vsync?

Post by Symoon » Tue Jul 23, 2019 5:35 am

Just for the record, in 2013 I tried to produce orange colour by displaying alternatively red and yellow. I seem to recall we had a topic discussing the amount of cycles for a VBL then.
I first tried with a loop doing 20000 cycles but I ended up with several TAP files, the last one doing a loop of 19968 cycles.
I just loaded it again and it does a flashing orange with wisible flashing and moving red and yellow lines on my LCD screen.

I'm off topic but I suspect I should go down to 19966 to hope for a better result? Wonder if I'll get some orange, or just an area split between yellow lines and red lines.

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 23, 2019 8:42 am

NekoNoNiaow wrote:
Tue Jul 23, 2019 1:12 am
Chema wrote:
Fri Jul 19, 2019 9:43 am
By the way ISS. I tested your programs and pressing SPACE does not seem to be able to sync correctly with the VSync signal. The bar appears at different places... am I misunderstanding something?
I noticed the same behavior when running ISS's calibration program.
I assume that this is due to the fact that the calibration routine does not eliminate all possibilities : there are several possible regions of the screen where the beam can be present after it is run.

At least if I understand ThomH's explanation. :lol:
Yeah, but I was quite sure that they ended up getting the region right after some iterations. I assumed the routine iss sent me for Blake's 7 was doing that... In fact I just tried and every time I run the game I get the value of VSYNC that is shown at the bottom of Oricutron at 143. That is somewhere mid-screen, apparently, which is ok to avoid the flickering of the cursor.

It would be great if someone who understood the routine could clean it up and also fix it so you could get the raster at the line you wish.
Symoon wrote:
Tue Jul 23, 2019 5:35 am
Just for the record, in 2013 I tried to produce orange colour by displaying alternatively red and yellow. I seem to recall we had a topic discussing the amount of cycles for a VBL then.
I first tried with a loop doing 20000 cycles but I ended up with several TAP files, the last one doing a loop of 19968 cycles.
I just loaded it again and it does a flashing orange with wisible flashing and moving red and yellow lines on my LCD screen.

I'm off topic but I suspect I should go down to 19966 to hope for a better result? Wonder if I'll get some orange, or just an area split between yellow lines and red lines.
I also did some experiments by mixing colors and I got some mid tints and also some combinations flashed horribly. I abandoned the experiment as it seemed too cumbersome to be used in a game. The loop should go down to 19966 indeed, Symoon.

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

Re: A possible software alternative to Vsync?

Post by Dbug » Tue Jul 23, 2019 9:43 am

color flickering only works on crt screens with a lot of screen persistance... and by interleaving pixels in a dithered pattern... tldr: don't try on the oric, been there, done that :)

User avatar
mikeb
Pilot Officer
Posts: 96
Joined: Wed Sep 05, 2018 8:03 pm
Location: West Midlands, UK
Contact:

Re: A possible software alternative to Vsync?

Post by mikeb » Tue Jul 23, 2019 5:48 pm

Xeron wrote:
Fri Jul 19, 2019 4:13 pm
Simple. Real PAL television sends a 312 line field followed by a 313 line field (interlacing).
Neither 312 nor 313: Split the difference and it'll be fine: For real PAL it's actually 312 and a HALF lines in each field, which is why the second lot of 312.5 land "between" the first set (to interlace). Total lines per frame should be 625.

As mentioned, Oric takes a short cut to produce a non-interlaced picture (312 x 2 = 624 lines!), that's not quite standard, but near enough.

User avatar
Symoon
Archivist
Posts: 1643
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: A possible software alternative to Vsync?

Post by Symoon » Tue Jul 23, 2019 6:07 pm

Found back the old thread:
viewtopic.php?f=4&t=944

I took a look too quickly this morning: I had already found the speed that was giving perfect result on Oricutron and real Oric/CRT screen, it was 19992 according to my multiple tries and calculations. Tried it again on a LCD and the visible result is the same.
And BTW, the result is indeed a TEXT line split in two parts horizontally: one yellow, the other red.

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 » Wed Jul 24, 2019 11:16 am

Can't be, Symoon... it should be 19966. With 19992 the bar should start drifting up or down after some time. As I told you, with Fabrice's program you can stop the bar manually and, once it is stabilized (and I mean not moving for long -say 1 minute- periods) you get to the debugger and the timer latch value is 19966.

Hummm, can you share the program here so I can test both in Oricutron and on my CRT TV??

EDIT:
I just made some tests on your blink19992-OK tap file with Oricutron's debugger and using F9 to reset the CPU cycle count. Your external loop, starting at $1001 with the code to put red paper on the screen, is called every 768 cycles. Guess what number is multiple of 768? Yes, 19968, the exact time of a frame (I use 19966 as launching an IRQ takes 2 cycles, as we have stated before).

I am not sure if you have any bug in your code or not. I can tell you that you start by setting the red paper and set the yellow paper 388 cycles after. I think it is partially due to this code:

Code: Select all

ldy #9E
DEY     
BPL #FD 
which is not working, as $9d is a negative number and the branch is never taken. Also beware that if you load Y with, say, 3, the branch won't be taken until it reaches -1, so the DEY will be executed 4 times. What I would do (to execute the loop 158 times) is:

Code: Select all

ldy #9E
DEY     
BNE #FD 
Does this make sense?

User avatar
Symoon
Archivist
Posts: 1643
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: A possible software alternative to Vsync?

Post by Symoon » Wed Jul 24, 2019 12:38 pm

Chema wrote:
Wed Jul 24, 2019 11:16 am
Does this make sense?
You're probably right, it's likely that there's a bug somewhere as, at the time, I was very incomfortable with machine code. And the code you just showed here is bugged indeed.
I'd have to take a look again.

And BTW, maybe I'm wrong but I think I was displaying red for 19996 cycles, then yellow for 19996 cycles, couldn't that be the reason why it doesn't display "orange" (or any approaching flashing thing), but a perfectly still half red / half yellow text line? Mmmmh, not so sure about that actually, if I change something before 19996 it won't be displayed.

PS: the program I tried is indeed the one that was in the old thread.

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 » Sun Jul 28, 2019 12:25 pm

The problem, I think, is the you need to change the color at the TV frame rate, that is 19968 cycles,but also you have to do it once the current color has been displayed. Something such as:

1 put red paper
2 wait until you are sure it has been displayed, for instance the VBlank signal.
3 put yellow paper
4 again wait until it has been displayed, for instance the VBlank signal.
5 go to 1

The VBlank signal is something we don't have in the Oric (unless you use then sync cable back) so you have to emulate it by setting a 19968 wait loop, but it must be calibrated so it does not finish before the color has been displayed. Else you may see just one color, or half the band could be yellow and half red or something like that.

Not sure if explained it correctly...

Can anybody help with the questions about the routines? Iss?

User avatar
Symoon
Archivist
Posts: 1643
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: A possible software alternative to Vsync?

Post by Symoon » Sun Jul 28, 2019 3:24 pm

That's exactly what happens, I get this result, perfectly still:
_vbl.png
_vbl.png (1.69 KiB) Viewed 584 times
I don't have time to take a look right now, other Oric things are in a hurry ;)
BTW I realised one of the 1st trying to achieve orange colour for the Oric is probably John S. Sinclair with Xenon-1 (meteors, explosions, ship engine in refuel screen) and Zorgon (spider lever).

Post Reply