Welcome, Guest. Please login or register.


Author Topic: Once more on timing (Read 3317 times)

Offline TomH

  • Newbie
  • Posts: 23
Once more on timing
« on: 2018.July.17. 15:48:10 »
Hi, sorry — I've collected notes from miscellaneous sources and am curious as to whether I've understood what I'm reading. Is the below an accurate summary of the timing behaviour of an Enterprise 64?

In PAL there are 283.7516 colour cycles per line. An Enterprise outputs slightly longer lines than spec, each one being exactly 284 colour cycles long. So it outputs 283.7516/284 * 15625 = 15611.3336268 lines per second.

In each of those lines there are 171 RAM access windows. Two out of every three are occupied by Nick. So only one out of three is available for the Z80.

The Z80 is ordinarily clocked by a separate crystal at 4Mhz. If it wants to access RAM, or a Nick IO port, it has to be aligned to the next available access window. This is performed by stopping the clock. The clock will always be stopped for an exact number of 4Mhz clock transitions, i.e. half cycles.

So, as awkward as it turns out to be, I make that 121303809/363520000 RAM access windows per Z80 clock transition. So it is very nearly true that three clock transitions, or 1.5 cycles, is the length of an access window, but not quite. It's actually slightly less — more like 1.498.

In addition to this there is a WAIT generator, which can be disabled, enabled only for M1 cycles, or enabled for all memory access cycles. When enabled it will pad the relevant cycles out by holding WAIT for a single 4Mhz cycle.

Dave accesses don't require alignment to an access window, ROM accesses don't require alignment. On an Enterprise 128, accesses to the additional 64kb don't require alignment, and neither does access to the contents of any RAM expansions. It's only the 64kb of RAM that Nick can access that require arbitration.

So then Nick has bandwidth for two-thirds of 171 bytes per line = 114 bytes, which break down as LPB fetch for 16 bytes, graphics fetching as defined, then six bytes to effect RAM refresh.

I have to admit to not yet knowing whether the mode line is fetched afresh every scan line or whether Nick just does busy work in the more common case when a mode line is longer than a single scan, but either way the slots don't become available for the Z80 or for anything else.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14721
  • Country: hu
    • http://enterprise.iko.hu/
Re: Once more on timing
« Reply #1 on: 2018.July.17. 16:54:05 »
The Z80 is ordinarily clocked by a separate crystal at 4Mhz.
No, the crystal is a 8Mhz, this is the System Clock, also used by the Dave chip, and WD177x chip on the EXDOS card.
The Nick made the clock division for the Z80, including the clock stretching.

Quote
In addition to this there is a WAIT generator, which can be disabled, enabled only for M1 cycles, or enabled for all memory access cycles. When enabled it will pad the relevant cycles out by holding WAIT for a single 4Mhz cycle.
It is in the Dave chip. And it is only valid when non video memory accessed.

I putted here some scope results.
First is the Nick RAS/CAS signals. You can see the two Nick access and one free.

On the second at Z80 executing NOPs in the video memory, this is the fastest Z80 access: continously read ony byte instructions.
You can see: every second Z80 windows missed.
On the third picture you can see what happen, if CPU running on 6MHz: every Z80 windows used.

There is the RAS/Z80 clock for these, 4MHz:
[ Guests cannot view attachments ]
6MHz:
[ Guests cannot view attachments ]

Offline TomH

  • Newbie
  • Posts: 23
Re: Once more on timing
« Reply #2 on: 2018.July.17. 17:15:46 »
No, the crystal is a 8Mhz, this is the System Clock, also used by the Dave chip, and WD177x chip on the EXDOS card.
The Nick made the clock division for the Z80, including the clock stretching.
Oh, well that was just poor phrasing. I should more correctly have written "The Z80 is ordinarily clocked at 4Mhz, by a separate crystal"; I just meant that the timing of VRAM access slots and the Z80 clock are not derived from a common source. So there's no clean integer relationship between the two. Unlike other machines of the same era where most things are divisions of the same clock.

It is in the Dave chip. And it is only valid when non video memory accessed.
That I didn't know. But presumably it's RAM-only? Not ROM?

...
You can see: every second Z80 windows missed.
On the third picture you can see what happen, if CPU running on 6MHz: every Z80 windows used.
Cool. I had also assumed a full RAS for every Nick access — no attempt at paged mode — based on the video modes. Hence the assumption that it's 171 equal-sized access slots per line, rather than e.g. [RAS, CAS, CAS], [RAS, CAS]. It looks like that was a correct guess.

Follow-up query: are Z80 refresh cycles are completely ignored? Even if I have a refresh address that prima facie points to VRAM, that won't cause a false positive on clock stretching? Is the Z80's refresh cycle the one that keeps non-VRAM stable?

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14721
  • Country: hu
    • http://enterprise.iko.hu/
Re: Once more on timing
« Reply #3 on: 2018.July.17. 20:52:49 »
So there's no clean integer relationship between the two. Unlike other machines of the same era where most things are divisions of the same clock.
Yes.
Two main clock source, Video Clock for Nick, and System Clock. CPU clock divided from the System Clock by the Nick, and also sterched when needed. On the extension bus also exist a 1MHz signal, which is divided by the Dave chip from the System clock.

The independent clock sources made easy task to build different CPU speed machines. The released EP64/128 are running on the well know 4MHz CPU, 8MHz System clock. The next model, which is in a prototype stage when the company crashed, runs on 6MHz (12MHz system).

Todays we reached 10MHz CPU (20MHz system) speed.

Quote
That I didn't know. But presumably it's RAM-only? Not ROM?
The first 64K of the 4096K address space decoded to the onboard ROM socket (00-03h segments), and the last 64K to the video memory (FC-FFh segments).
To the remaining 3968K you can put RAM or ROM to anywhere.
Wait generator of the Dave are valid for the first 4032K of memory, 00-FBh segments. Don't depend about ROM or RAM.

Quote
Cool. I had also assumed a full RAS for every Nick access — no attempt at paged mode — based on the video modes. Hence the assumption that it's 171 equal-sized access slots per line, rather than e.g. [RAS, CAS, CAS], [RAS, CAS]. It looks like that was a correct guess.
Yes, full RAS/CAS cycle at all access. And all controled by the Nick fixed timings. This means, when using faster CPU, even on 10MHz don't need touch the video memory. Ok, then the access not fast as possible, but because the faster Z80 can use more and more access windows then video memory are also accelerated.

Quote
Follow-up query: are Z80 refresh cycles are completely ignored? Even if I have a refresh address that prima facie points to VRAM, that won't cause a false positive on clock stretching? Is the Z80's refresh cycle the one that keeps non-VRAM stable?
Yes, the refresh only valid at non video memory. Video memory refreshed by the Nick (using 3 slot of 57).