Welcome, Guest. Please login or register.


Author Topic: What is the number of clock cycles per rasterline? (Read 527 times)

Offline Sdw

  • User
  • *
  • Posts: 50
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 53.0 Firefox 53.0
    • View Profile
What is the number of clock cycles per rasterline?
« on: 2017.May.07. 23:20:54 »
...and does it get affected by anything so that it isn't always the same?
I guess memory wait states could be one such thing, but assume we are running with:
Code: [Select]
ld a,0x0c ;disable
out (0xbf),a ;memory wait states


Offline lgb

  • EP addict
  • *
  • Posts: 3494
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 53.0 Firefox 53.0
    • View Profile
    • http://lgb.hu/
Re: What is the number of clock cycles per rasterline?
« Reply #1 on: 2017.May.08. 00:48:28 »
...and does it get affected by anything so that it isn't always the same?
I guess memory wait states could be one such thing, but assume we are running with:
Code: [Select]
ld a,0x0c ;disable
out (0xbf),a ;memory wait states

Do you mean about CPU clock cycles per a raster line? It depends on what you're doing ... If you assume 4MHz Z80, still it can't be constant, if you access video RAM, the situation is kinda complex, as Nick has the priority to have the VRAM, thus is "deforms" the clock signal of the CPU to overcome collusion on VRAM access. As far as I remember it's true for I/O operation as well, if Nick is targeted with an IN/OUT. In these cases, the actual very exact "effective CPU speed" is not so easy to tell, but it can be say in average at last, or something like that :)

If you don't access VRAM or VIO (it's not possible on an unexpanded EP64, since there every RAM is VRAM ...), it should be kind of constant value in my opinion, but I can't tell how well it is, since, I guess, CPU clock and Nick's clock is generated separately, so there can be some drift even at the frequency of used quartz crystal oscillators and such. In general, as far as I can remember, it's about 65 usec for a raster line, so you can tell the number of CPU clock cycles (I assume you mean T-states) for that amount of time for a given CPU clock (4MHz on a 'stock' machine).

Offline IstvanV

  • EP addict
  • *
  • Posts: 4756
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 52.0 Firefox 52.0
    • View Profile
Re: What is the number of clock cycles per rasterline?
« Reply #2 on: 2017.May.08. 10:20:23 »
It is not a simple integer constant because the Z80 and NICK are clocked by separate crystals. For the NICK chip, the clock frequency is derived from the PAL chroma sub-carrier (17734475 / 4 Hz), such that one line is exactly 284 cycles of that, which is slightly different from the PAL standard. Thus, the horizontal refresh rate is 17734475 / 4 / 284 = 15611.3336 Hz in theory, instead of the standard 15625 Hz. Although the circuit that generates the clock can be broken in some of the machines, resulting in an inaccurate frequency and "waving" picture or other artifacts.

One line is then divided into 57 "slots" or characters, at a frequency of 889846.02 Hz. In each of these, the NICK chip can read 2 bytes from video RAM, while one byte access is allowed for the Z80. In the first 8 slots, the current LPB is read (16 bytes), then 46 slots are available for displaying graphics, and the last 3 slots are reserved for refreshing the VRAM (6 bytes). If a "refresh" slot is not border, then display is generated from the last valid byte read. The NICK input clock frequency is 16 times higher (14237536.27 Hz), this is the dot clock in the highest resolution mode.

So, on a standard 4 MHz machine, the number of Z80 cycles per line is 256.224, not an exact integer, and it may vary randomly by a small amount. I think the 8 MHz crystal for DAVE/Z80 has an accuracy of 0.1% (Zozosoft may correct this information), the NICK frequency derived from the PAL crystal is better, at least if the clock generator circuit works correctly.

Any access from the Z80 to VRAM or NICK I/O ports (80h-8Fh) is subject to clock stretching, the Z80 clock is halted until the phase within a slot reserved for the Z80 is reached, and there is some additional wait as well, so a VRAM access can be delayed (at 4 MHz) by 1 to 5.5 Z80 cycles in half cycle steps. If accurate synchronization with NICK is needed, then this can also be useful, like in the fbscroll.com demo.

Offline Sdw

  • User
  • *
  • Posts: 50
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 53.0 Firefox 53.0
    • View Profile
Re: What is the number of clock cycles per rasterline?
« Reply #3 on: 2017.May.08. 11:30:52 »
Aha! Thank you both, turns out things aren't as easy as I thought!

I have an LPT which triggers an IRQ on the first line of display, and then I try to have my code on the CPU stay in sync with each drawing of a rasterline on the screen. For now I have timed it by hand by simply setting the background color each line so I can visually see if I am in sync or not, and it works OK. But then I guess it's not as simple as removing that out and replacing with dummy code taking the same number of cycles, since as you say Nick-outs can stretch. Maybe the best option is to time until it looks right, and then simply replace so that the background out (0x81) is zero all the time, that way I keep the timing exactly as it is when it "looks" OK.

Offline lgb

  • EP addict
  • *
  • Posts: 3494
  • Country: hu
  • æðsta yfirmaður
  • OS:
  • Linux (Ubuntu) Linux (Ubuntu)
  • Browser:
  • Firefox 53.0 Firefox 53.0
    • View Profile
    • http://lgb.hu/
Re: What is the number of clock cycles per rasterline?
« Reply #4 on: 2017.May.08. 12:12:32 »
I'm just thinking that in _theory_ you can set up a single interrupt on a single LPB let's say for the first scanline. Then from there you set up even more interrupts for other LPBs as well. You may need this set-up, as - AFAIK - it's not possible to tell which LPB causes the interrupt ... But if you had only one, and you set the others up from the IRQ handler, then you know you were in the first, and you can then do a simple counting on each interrupts, so you probably know where are you then. Still, this theory - IMHO - is not so nice or not even possible because:

* it's interrupt based, many CPU clocks wasted on interrupt handling, etc
* it's still not so precise, since accepting interrupt takes time, and it's not constant (depends on the actual opcode should be finished first by Z80 ...)
* as far as I can remember, it's not possible to cause interrupts in two continuous LPBs, because there is no edge on the level of INT status on the LPBs (but it can be okey, if you don't need for every LPBs, now it's another question if an LPB is a single raster line or means more, the theory is similar).

But if you're still interested about a solution like this, IstvanV surely knows much more on these - too :) - than me.