Welcome, Guest. Please login or register.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - TomH

Pages: [1]
Programming / 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.

Pages: [1]