INMC 80 News

Transparent Video

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 blanking period.)

I hope this helps Mr. Willmott and others. I would be interested in hearing about other members’ efforts in this area.

Stephen Prince, Winchester

Pascal Changes

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 for 3.50.

Rory O’Farrell, Co. Wicklow