MC6847 parameters

[floooh]

MC6847 parameters

[floooh]

The real chip draws TWO pixels per clock cycle, effectively it is like drawing ONE pixel at twice the clock speed; so I think the MC6847_TICK_HZ constant should be doubled.

I think this part is correct, the data sheet explicitely says that "incoming" frequency at the CLK pin must be 3.57... MHz, the clock frequency often just says how many bytes can fetched at most, not how many pixels are drawn. Looking at the scanline decoding functions it looks like the chips either fetches 16 or 32 bytes per scanline, and (depending on graphics mode) renders between 64 to 256 visible pixels per scanline from those 16 or 32 bytes (with different deocding rules of how those bytes map to pixels).

However, the pixel decoding isn't cycle-correct anyway, since it decodes an entire scanline at once, and the timing when that happens is defined h_count and h_period values (whenether the horizontal counter "hits" h_period, one complete scanline will be decoded in a single cycle, which of course isn't correct at all, but as long as h_count counts up at the right frequency, and h_period has the right value, the timing will be correct per scanline.

The horizontal video frame is 227.5 clock cycles, resulting in 227.5 x 2 = 455 pixels, so the constant MC6847_DISPLAY_WIDTH should be raised from 320 to 455

The DISPLAY_WIDTH constant isn't really relevant for the timing, this only describes how big the frame buffer must be. Instead the h_period value is relevant, and the 227.5 clock cycles value can be found here (rounded to 228 though):

chips/chips/mc6847.h

Line 284 in fdef73e

int64_t tmp = (228LL * desc->tick_hz * MC6847_FIXEDPOINT_SCALE) / MC6847_TICK_HZ;

In the software emulation the border pixels are equally divided:

Yes, this might be an actual error. I simply adjusted the BORDER_PIXELS constant so that the video image appears centered.

Cheers :)