CRTC Question

[endangermice]

The info on the 14bit counter was spot on, thank you. It's now working better than before - games like Xenophobe with an unusual screen width now display correctly for the first time .

I'm now figuring out how to handle particularly unusual scenarios. I'm currently looking at the Horizontal sync widths. Sometimes, they are set in such a way that they extend beyond the maximum column count for a row. What happens in this scenario since it technically means that HSync is never deactivated as we can't reach the column number. How should this be handled. Should HSync be automatically reactivated at the start of the next row, or does something else happen?

Right now I'm encountering a scenario with the Batman Forever demo, the setup screen where the end of Horizontal Sync is beyond the 64 characters in a row. Therefore HSync never ends and the display goes blank.

Thanks again for all the help, I hope all my questions aren't too annoying.

[andycadley]

Cool, good to hear you're making progress. I think I'll defer to the real experts like @arnoldemu on what happens in the extreme edge cases though!

[PulkoMandy]

You will also start to see differences between the CRTC types when going into such details.


for the HSync, as far as I know it is implemented with a "start" and a "width". This would mean it is implemented as a separate counter:
- When HCC (horizontal char counter) hits HSync start (Reg. 2 value), the HSync starts and the HSync counter (let's call it HSC) is reset.
- HSC is incremented at every new char
- When HSC reaches the hsync width value (from R3), the HSync stops


This leaves one open question: Is HSC reset when the HCC is reset? Or does it run independantly?

[endangermice]

That's interesting, if HSync is driven by a separate counter then you could in theory set much longer widths than the screen size. Such a width would effectively run HSync out of sync with the resetting of the HSync character counter. In theory you might see a skewed screen as Hsync would start later than expected - that's assuming that the CRTC beam does not wait for the start of HSync like it does for VSync....

Hmmm I wonder if this is what's going on with the Batman Forever demo. Do you recall the section where it draws a kind of twisted cylinder. I wonder if that is using some clever real time adjustment of the HSync width in order to skew the image on a per line basis....?

[PulkoMandy]

No, the HSync must always happen exactly every 64us and have the same width.


If you don't have it every 64us, the screen will distort as the monitor will slowly catch up with the sudden and unexpected change. Example of demo doing this: Plasma Pas Cher (going from 63 to 65 us between hsync which is reasonable). There are old demos from the 80s doing much weirder things.


If you shorten the HSync length, the screen will be slightly shifted to the left (not exactly a whole character, you can make it move by about a pixel). Axelay used this in his games to implement smooth scrolling. If you shorten it too much, at some point the blanking will not coverthe PAL color burst anymore. The CTM doesn't care about this, but if you use the CPC with another display (TV, video projector, Commodore 1084s, ...), the display will take the color of whatever is in the color burst area (usually border color). The result is usually a smooth gradient from border color to black over a few lines. There was a picture of a test demonstrating this during one of the ReSeT parties, but I can't locate it at the moment.


Most of Batman Forever distorsion effects are essentially line-to-line screen splitting (CRTC screens 1 line high, changing R12 and R13 value at each line) and clever palette changes.


The counter for the HSync length is probably only 4 bits wide, as is the R3 setting for HSync. So, you can't set a long width, it will count for at most 16 chars and that's the maximum HSync length.

[endangermice]

That makes perfect sense - I can see how Batman Forever would work with a lot of 1 scanline CRTC screens - this will be fun to implement.


It shouldn't be possible to enter more than a 4 bit number for the Horizontal Sync width since the calculation of the value is

VVVVHHHH from register 14, so in theory it can't go any higher than 15. Of course in my debug dump code, it's showing the whole byte, not the individual values as extracted from bits 7-4 and 3-0. I'll amend that to show what's going on more accurately.

[endangermice]

Is anyone able to explain how 32kb screens can be emulated? Due the the lack of an M11 connection, I'm, finding my emulated 32kb screens are wrapping back around to the beginning of the 16kb memory window. I understand that setting M11 can allow the CPC to access the additional memory, I believe this is possible because it can be set via R12 and R13 it just never gets read by the CPC but can be used internally. I'm a little unsure exactly how this works. I've read Kevin's http://www.cpctech.org.uk/docs.html article on this a few times but I not quite getting it.

[andycadley]

As long as you're initialising your 14-bit MA counter correctly from the values provided to R12 and R13, it should "just work". It happens because by setting MA10 and MA11 to 1, they will overflow and change the upper two bits MA12/13 such that subsequent addresses end up coming from a different 16K page of memory.

[PulkoMandy]

Yes, that's it exactly. With MA10 and MA11 in bold:


Last address for a 16K page:
00001111111111
+1
00010000000000

MA12 and MA13 are still 0, we are back at address 0xxx.

BUT, if your initial value for R12 is set with MA10 and MA11=1:

00111111111111
+1
01000000000000

Now MA12 changes, and we are at address 4xxx.

That's all there is to 16K/32K screens. It's just that the value for these two unused bits leads to an overflow, or not.

For this to work, you need to properly take MA10 and MA11 into account when computing your MA address, and only after the processing there is done, convert to CPC RAM space address (which does not use these two bits).

[endangermice]

Guys,

Thanks again for all your help, it's invaluable!

I think I've just figured out what has been confusing me. I don't think the wiring table: http://www.cpcwiki.eu/index.php/CRTC is correct. It says A15 is wired to MA12 and A14 is wired to MA11. Looking at the 6128 schematics again, A15 should be wired to MA13 and A14 should be wired to MA12.

If calculate under that assumption, the startup address of MA - 0x3000 when translated to the Amstrad wiring is 0xC000 which is correct. I was thrown when I was getting 0x8000, but I believe that is due to the incorrect assignment of A15 and A14 in that table.

[andycadley]

Er, yup, that looks like a mistake on the Wiki page all right. Well spotted. :-)

[endangermice]

Yes that's had me going round in circles for more than a few hours! I think I'm very nearly there but I'm a bit stuck on the final piece of the puzzle....

I've now got MA running as a 14bit counter that simply increments by 1 each time I'm called by the clock signal and we draw to the screen i.e. display_enable is true. This will cause the number of bytes to jump by 2 due to the fact that the MA0 - MA9 are assigned to A1 to A10 - essentially a bitshift to the left which means the lowest number it can increase by is 2. MA is also reset to R12 and R13 at the beginning of the next frame.

The CPC addresses are almost correct. However, my memory offset counter is not resetting after a scanline so instead of getting

0xC000 ... 0xC04E ... 0xC800, I'm getting
0xC000 ... 0XC04E ... 0XC850

I figured that would happen automatically when I got the wiring correct but I guess it doesn't so is it not correct to simply increment the MA address by 1 on every clock cycle...?

[andycadley]

You're basically there. The last bit of the puzzle is that, within a character row, each scanline needs to have the same MA values. So you need to store a copy at the start of a line and reset it back when the horizontal character count matches horizontal displayed, unless RA =R9(Max Raster). Or possibly RA >= R9, IIRC it may be CRTC dependent (and gets funkier on Plus machines!)

[endangermice]

That was it! Andy thank you so much for this bit of information, I now finally have the addressing working correctly, the pages are scrolling and 32kb screens now display as eh... 32kb .


So I now have decent memory mapping of the CPC screen - I guess it's time to work on those CRTC registers and the Monitor emulation - that should be fun - I think....