Uzebox Emulator!

[uze6666]

The current code watches for a "1" going to PORTB and uses that to trigger a new scanline (ie detect calls to hsync_pulse).
Or would it be simpler to just lock the frame traversal to the timer interrupt?

That's a tricky one, but I'd say we should use the way TVs does it, that is, detect the 6 serration pulses (at double the normal HDRIVE). That should not be too tough. Just detect when PB0 "negative" time is around 500-780 cycles for 6 cycles. After that you know you're at line 7. Don't forget the sync in the first 9 lines of the frame runs at double the normal rate (909 cycles).

-- looks like the timer interrupt is every ~1820 cycles, same as the scanline interval. But the main render loop runs for a lot longer than that, so I assume a bunch of timer interrupts are getting ignored every frame since it does the counting internally?
Does the interrupt handler basically count scanlines during vblank (around 29 lines from the looks of it, or 52,780 cycles) and then let the video display run after that?

Yes that's the way it works. A line count is maintained before, during and after the rendering. During the rendering the count is maintained per scanline or added in the end depending if its mode 1 or 2. But the result is naturally the same.

Again, in the mean time we can always use the reserved port approach to get a steady picture and reference for your vsync code.

Alec

[DavidEtherton]

...and is the first "visible" scanline 20 or 21? (ie the first scanline the emulator will show, but it's likely to get cropped off the top of a real TV)

-Dave

[DavidEtherton]

Added some debug spew:

Code: Select all

PORTB becomes 1 at cycle 499936 (68 since last write)
PORTB becomes 0 at cycle 500783 (847 since last write)   ; 2?
PORTB becomes 1 at cycle 500851 (68 since last write)
PORTB becomes 0 at cycle 501696 (845 since last write)   ; 3?
PORTB becomes 1 at cycle 501764 (68 since last write)
PORTB becomes 0 at cycle 502610 (846 since last write)   ; 4?
PORTB becomes 1 at cycle 502678 (68 since last write)
PORTB becomes 0 at cycle 503524 (846 since last write)   ; 5?
PORTB becomes 1 at cycle 503592 (68 since last write)
PORTB becomes 0 at cycle 504439 (847 since last write)   ; 6?
PORTB becomes 1 at cycle 504507 (68 since last write)
PORTB becomes 0 at cycle 505353 (846 since last write)    ; line 7?
PORTB becomes 1 at cycle 506127 (774 since last write)
PORTB becomes 0 at cycle 506267 (140 since last write)   ; 8?
PORTB becomes 1 at cycle 507041 (774 since last write)
PORTB becomes 0 at cycle 507181 (140 since last write)   ; 9?
PORTB becomes 1 at cycle 507955 (774 since last write)
PORTB becomes 0 at cycle 508096 (141 since last write)   ; 10?
PORTB becomes 1 at cycle 508870 (774 since last write)
PORTB becomes 0 at cycle 509008 (138 since last write)   ; 11?
PORTB becomes 1 at cycle 509782 (774 since last write)
PORTB becomes 0 at cycle 509922 (140 since last write)   ; 12?
PORTB becomes 1 at cycle 510696 (774 since last write)
PORTB becomes 0 at cycle 510837 (141 since last write)   ; 13?
PORTB becomes 1 at cycle 510905 (68 since last write)
PORTB becomes 0 at cycle 511750 (845 since last write)   ; 14?
PORTB becomes 1 at cycle 511818 (68 since last write)
PORTB becomes 0 at cycle 512664 (846 since last write)   ; 15?
PORTB becomes 1 at cycle 512732 (68 since last write)
PORTB becomes 0 at cycle 513579 (847 since last write)    ; 16?
PORTB becomes 1 at cycle 513647 (68 since last write)
PORTB becomes 0 at cycle 514492 (845 since last write)    ; 17?
PORTB becomes 1 at cycle 514560 (68 since last write)
PORTB becomes 0 at cycle 515408 (848 since last write)    ; 18?
PORTB becomes 1 at cycle 515476 (68 since last write)
PORTB becomes 0 at cycle 516320 (844 since last write)     ; 19?
PORTB becomes 1 at cycle 516457 (137 since last write)     ; end of last invisible scanline?
PORTB becomes 0 at cycle 518145 (1688 since last write)    ; end of first visible scanline? (20?)
PORTB becomes 1 at cycle 518282 (137 since last write)
PORTB becomes 0 at cycle 519969 (1687 since last write)
PORTB becomes 1 at cycle 520106 (137 since last write)
PORTB becomes 0 at cycle 521793 (1687 since last write)

[uze6666]

..and is the first "visible" scanline 20 or 21? (ie the first scanline the emulator will show, but it's likely to get cropped off the top of a real TV)

That's a #define that can change depending on the video mode. It's 20 for mode1 and 24 for mode2.

Looking at your timings I notice strange differences between pulse. I will have a look on the real thing to see if that happens too.

Btw, what code/version were you running?

[havok1919]

(dammit... my reply seems to have been eaten!)

Ok, Cliffnotes version. This is what I do on other hardware to lock to vsync from composite sync:

1) Watch the csync line. Whenever it goes low, start a counter.
2) If the counter ever stays low longer than an hsync pulse (~5-6us tops) then that's the first vsync pulse.
3) Turn off the detector and wait for that condition again.

Similar technique will spot hsync-- wait for the vsync as above, then wait 19 or so scanline times (~63.5us) and start looking for the low level pulse again. The leading edge will be the hsync pulse (since you've waited past all the serration pulses and whatnot).

And an Alec question-- have you tried running without the serration pulses at all? (Might be a good experiment-- arcade game hardware doesn't output those and yet looks fine running through the AD725 or CXA2075... provided the sync timing is OK)

-Clay

[uze6666]

Hey Dave, could you add the current value of TCNT1 for each of those debug lines? That would help.

[uze6666]

And an Alec question-- have you tried running without the serration pulses at all? (Might be a good experiment-- arcade game hardware doesn't output those and yet looks fine running through the AD725 or CXA2075... provided the sync timing is OK)

Nope, when I started the project I wanted the sync to be as close as the official standard to eliminate at least this as the source of future problems! So basically what you are saying is no serration pulses or no double rate pulses? Do you have a drawing of what it should look like?

[havok1919]

Nope, when I started the project I wanted the sync to be as close as the official standard to eliminate at least this as the source of future problems! So basically what you are saying is no serration pulses or no double rate pulses? Do you have a drawing of what it should look like?

Yeah, exactly. Take a look at page 19 of the AD723 datasheet:

http://www.analog.com/static/imported-f ... /AD723.pdf

(In my arcade hardware I don't have the inverted hsync pulses present in vsync simply because I'm not combining sync with an external 74x86 and it works fine there... YMMV.)

-Clay

[uze6666]

Well, if that works it would greatly simplify the sync code. I'll give it a try, stay tuned.

[DavidEtherton]

- vblank is driven by looking for the serration pulse now; removed old gamepad-related hack.
- emulated image is rock-solid and reasonably centered on all demos now. it's "perfect" on NET5.
- EDIT: trap invalid program counter and abort emulation if detected (otherwise it would crash)

-Dave