I read Mr Willmott’s letter in INMC80 issue 3 (page 42) with interest
and I thought you might be interested in my own ideas on the subject.
The reason Mr Willmott’s attempt to use WAIT failed is that he has
misunderstood the effect of WAIT. It is described for various cycles (Memory
read, Memory write, etc) on pages 15-18 of the Z80 Technical Manual. Whenever
/WAIT is asserted the cycle is stretched by inserting wait states until /WAIT
goes high again. During this time all the bus signals are maintained. Thus
while waiting for a blanking period the VRAM signal will be active, preventing
the VDU circuitry from accessing the RAM.
For this technique to work the VRAM select line must be interrupted
sufficiently early in its path to prevent the VDU circuitry from being locked
out. However this could itself raise problems. The VRAM select would probably
have to be restored before releasing the wait, to give the RAM time to pick up
the CPU access. Also if dynamic memory is in use, long periods spent waiting
for RAM access could prevent refresh from cycling fast enough.
I have been considering a different, though related, solution to the
same problem. The blanking signal can be connected to an input port bit
allowing the CPU to monitor its state (the PIO can be used for this, so that
no extra hardware is required). Then, before accessing the VDU memory, this
input is tested, and the CPU waits in a short loop until the next blanking
period starts. I have not so far experimented with this enough to be sure it
works, but the technique is promising.
/BLANKING is a composite of two blanking signals: blanking between
scan lines, and blanking between frames. The former lasts for quite a short
period – I think less than the time required to access one byte. Therefore I
have been using only the interframe blanking period, identified by the VBLANK
signal which is brought out to TP22. By my calculations the blanking period
lasts around 5.38 msecs., which would allow quite major alterations to the VDU
RAM before the next frame starts. In addition after VBLANK ends there is still
a short blanking period at the start of the first displayed line, which allows
for some overrun.
One way of handling moving graphics displays would be to keep a copy
of the display in non-displayed RAM. This copy can then be updated as
required, and copied to the VDU RAM during one or two blanking periods. (At
4MHz without wait states, LDIR could just about move 1K bytes in a single
I hope this helps Mr. Willmott and others. I would be interested in
hearing about other members’ efforts in this area.
Stephen Prince, Winchester
Further to my review of the Hisoft Pascal, I have now been informed by
Hisoft that all copies of the NAS-PAS 3 supplied after 1st May 1981 include
the following additions to the predefined functions:
EXP(x), LN(x), COS(x), SIN(x), ARCTAN(x), TAN(x)
where x is a REAL or INTEGER argument (in radians for trig functions),
returning a REAL result.
I omitted to mention that the benchmark timings as suggested by PCW
show a very creditable performance from the code produced by this compiler.
The manual comes with suggestions on how to improve the runtime speed even
more, but quite frankly I don’t think this will be necessary.
Nas Pas 3 purchased before 1.5.81 will be updated with trig. routines
Rory O’Farrell, Co. Wicklow