CRTC and R2

[Lone]

Hello there,


I'm currently a bit stucked with strange behaviour of the CRTC with the Hsync.... And what I found on the web is not really helpfull in this particular case, so I'm juste asking the greatest source of knowledge on the web, which is juste here.


The problem is  : Where is really placed the HSync.


I explain : When running the "Camembert 4" demo ( http://www.cpc-power.com/index.php?page=detail&num=7737 ) on my emu, I note that the 4 first mode0 pixel of the logo is not displayed correctly. Running this demo on winape show correctly, as in other various emulator (JavaCPC desktop (great experience by the way)).


So, I just use debugging ressources, and it show the following :
R0 = 1f
R2 = 00
R3 = 04
R12& R13 = random value


Which I understand as : "This particular part of screen is &1f long, the hsync occur on the very begining of the line, and is 4 us long"
Which means, that the 4 * 2 = 8 first bytes of the screen,



Take MA_beg = memory value computed from R12&R13


MA_beg and MA_beg+1 will be in hsync (not shown)
MA_beg +2 and MA_beg+3 will be in hsync (not shown)
MA_beg +4 and MA_beg+5 will be in hsync (not shown)
MA_beg +6 and MA_beg+7 will be in hsync (not shown)
End of hsync
MA_beg +8 and MA_beg+9 will be displayed.


This is false. The first displayed bytes are MA_beg +6 and MA_beg+7.

After lots of investigations and braind damage, my best guess about that is that Hsync begin at R2-1. (which can be understood by : Hsync begin after "R2" character).
Having R2=0 has no real meaning, exept that Hsync will begin when HCC=R0....

When I do this implementation, I have the correct behaviour on a little demo...
Other possibility would be a delayed address computation (which would shift the addres computation the following way :
HCC = 0, MA = ?
HCC = 1, MA = MA_beg
HCC = 2, MA = MA_beg + 1
etc.

But I can manage to have any explanation about this...;

Is it telling something to someone ? Do we have a true god of CRTC reading this forum ? Am I totally wrong about everything from the begining ?

[arnoldemu]

There is a difference between the HSYNC the monitor sees and the HSYNC the CRTC generates.
HSYNC goes through the gate-array.

If HSYNC is longer than 6us, Gate-Array cuts it short and monitor only sees a length of 6.
If HSYNC is shorter than 6us, monitor sees this short HSYNC (e.g. if HSYNC width is 5, it sees 5).
This explains *why* the CRTC R3 smooth scroll works by switching between 6 and 5. It could be F and 5, I don't think it really matters.

Another thing, mode is changed by Gate-Array 2 cycles after HSYNC starts. So if HSYNC is too short, I think the mode is not changed.

Now the interrupt position is based off HSYNC. I *think* it comes at the actual end of the HSYNC.

So if CRTC hsync width is 14 cycles.

mode change happens 2 cycles after HSYNC begins.
Monitor sees a HSYNC of length 6.
Interrupt is triggered at end of HSYNC (14 cycles).

Enjoy !

[arnoldemu]

In addition to these, if you change the colour, there is a delay, it doesn't happen exactly at the start of a us. I think the same happens with the mode, but I can't give you more details at the moment.

[arnoldemu]

BTW, when coding CRTC, Gate-Array and monitor emulation I run many tests on real CPCs to see the real result.

I don't go on the results from other emulators, only what a true CPC shows.

[Lone]

Well, thanks for your replies. I forget, but my investigations where all on the Type 1 CRTC.




I have the chance to get my own real Amstrad CPC 6128 since yesterday (but now, I'll have to negociate for some space for it as the Wife Agrement Factor for it is on a really low level...). I've already planed to do some test, as soon as I can plug it.

[Munchausen]

[ot]Currently moving house, and the fiance agreement factor has taken me almost a year of hard work, but it looks like we've finally agreed on a room just for computers and tools, provided my bed settee goes in there so we can still sleep guests [/ot]


Good luck getting your emu working better!