1
0
mirror of https://github.com/TomHarte/CLK.git synced 2024-07-06 01:28:57 +00:00

Introduced blackout period solution to vertical sync confusing horizontal sync. Need to find out whether it's accurate.

This commit is contained in:
Thomas Harte 2016-04-14 20:30:45 -04:00
parent 6a17c2992d
commit 323f1a24db
2 changed files with 15 additions and 2 deletions

View File

@ -281,8 +281,11 @@ void CRT::output_scan(const Scan *const scan)
const bool is_leading_edge = (!_is_receiving_sync && this_is_sync);
_is_receiving_sync = this_is_sync;
const bool hsync_requested = is_leading_edge;
// const bool hsync_requested = is_trailing_edge && (_sync_period < (_horizontal_flywheel->get_scan_period() >> 2));
// This introduces a blackout period close to the expected vertical sync point in which horizontal syncs are not
// recognised, effectively causing the horizontal flywheel to freewheel during that period. This attempts to seek
// the problem that vertical sync otherwise often starts halfway through a scanline, which confuses the horizontal
// flywheel. I'm currently unclear whether this is an accurate solution to this problem.
const bool hsync_requested = is_leading_edge && !_vertical_flywheel->is_near_expected_sync();
const bool vsync_requested = is_trailing_edge && (_sync_capacitor_charge_level >= _sync_capacitor_charge_threshold);
// simplified colour burst logic: if it's within the back porch we'll take it

View File

@ -9,6 +9,8 @@
#ifndef Flywheel_hpp
#define Flywheel_hpp
#include <stdlib.h>
namespace Outputs {
namespace CRT {
@ -187,6 +189,14 @@ struct Flywheel
return result;
}
/*!
@returns `true` if a sync is expected soon or the time at which it was expected was recent.
*/
inline bool is_near_expected_sync()
{
return abs((int)_counter - (int)_expected_next_sync) < (int)_standard_period / 50;
}
private:
unsigned int _standard_period; // the normal length of time between syncs
const unsigned int _retrace_time; // a constant indicating the amount of time it takes to perform a retrace