Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MC6847 parameters #36

Open
nippur72 opened this issue Jul 8, 2020 · 1 comment
Open

MC6847 parameters #36

nippur72 opened this issue Jul 8, 2020 · 1 comment

Comments

@nippur72
Copy link
Contributor

nippur72 commented Jul 8, 2020

I checked the datasheet of the MC6847 video chip, and it seems to me that some numbers do not reflect the real hardware.

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.

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.

In the software emulation the border pixels are equally divided:

#define MC6847_BORDER_PIXELS ((MC6847_DISPLAY_WIDTH-MC6847_IMAGE_WIDTH)/2)

but according to the datasheet the left border is slightly greater than the right one, as per the following numbers:

blank area: 84 pixels
left border: 59 pixels
visible area: 256 pixels
right border: 56 pixels
@floooh
Copy link
Owner

floooh commented Jul 9, 2020

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants