80-Bus News

  

Spring 1985, Volume 4, Issue 1











Page 4 of 31











default mode. (See page 31 in the manual.) I must say that this has caused no real difficulty at all.

Yours truly, Tom Gibson, Middlesbrough, ___ ___.

Ed. – see my comments following the next letter.

Turbo Pascal – 2

I have installed Borland International Turbo Pascal onto my Gemini/​Nascom system. With the Nascom video (generated using MOVCPMN) the system works perfectly, but when trying to use the IVC (Version 1.0), the system hangs after trying to edit a file. Other commands work perfectly and it appears to be only when cursor addressing is used. Have you come across this problem before or can you suspect a cause?

By varying screen size that the Pascal recognizes (from 10 x 20 thru’ 25 x 48 to 25 x 80) and varying the delays generated after the cursor addressing, I can vary the time between invoking the editor and hanging occurring. By this I mean the number of characters typed. I would appreciate any help.

Yours truly, R T Lea, Sarawak, East Malaysia.

Ed. – Well, Mr Lea, you can either apply the modification suggested by Mr Gibson above, or you may like to get to the source of the problem. Version 1.0 of the IVC-MON (which was not in production for very long) did not support any nested escape sequences. Later releases, as well as including a number of enhancements, have been modified so that certain sequences, including cursor addressing, can accept nesting. The differences between releases of IVC-MON were published in 80-BUS News Volume 3, Issue 2, pages 48 and 49, in an interesting article giving an insight into the hardware and software design philosophy used in the development of the Gemini GM812 IVC, and its successor, the GM832 SVC. You should find, as should Mr Gibson, that replacing your IVC-MON V1.0 with any later release will eradicate your problem.

An IVC Problem?

I have recently come across an intriguing problem with WordStar when used on a system which incorporates IVC-MON 2.0 and the keyboard is attached to the GM812 video card. If the ESC key is pressed (as may be necessary if an error or interruption occurs), a List/​Edit Function key message is produced – not much use if you haven’t got the appropriate keyboard and a ★★★★ nuisance as well since the system may lock-up and often has to be cold booted to clear the problem.

I am currently running SYS and can have the keyboard attached to the CPU card or the IVC. By attaching the keyboard to the CPU card, the ESC key functions normally and WordStar does not become confused. If a version of SYS is not used, link 3 on the IVC will need to be adjusted so that the keyboard can be used on the CPU card.

Yours truly, Dr P D Coker, Orpington, Kent.

Ed. – the clue to your problem lies in the fact that the keyboard works OK on the CPU board, and not on the IVC. Firstly, why use it that way round anyway? I cannot think of any advantage to that approach, and a definite disadvantage is that you lose the type-ahead buffer. Secondly, I bet that you have a GM821 keyboard, and that you don’t get the ‘List/​Edit ....’ message until you have pressed the ‘ESC’ key twice, right? To explain what is happening I’ll just give a little history on Gemini keyboards.

First of all came the GM821 keyboard (very originally known as the G613). This has 59 keys and can, with various permutations of Normal, Shift, Control, and Shift/​Control, produce 128 ASCII codes, thus using 7 bits of the interface. The 8th bit is used as a strobe, and the keyboard can be connected to the keyboard interface on the GM811 CPU, GM812 IVC and GM832 SVC boards. When Gemini decided to produce the GM827 keyboard, with 87 keys, some of the keys were used to obviate the necessity for the Shift/​Control permutations. In addition 30 keys were added to be user-definable separately in Normal and Shifted modes. These obviously require additional codes, but with only 7 bits available the question was ‘How?’. The answer was to make therm all double-byte codes, and to pick one existing code as the first byte ‘key’. The one chosen was the ESC key, code 1BH. This key was therefore redefined as the first in the double-byte sequence, 1B 00, and all of the function keys carried on from there, F0 = 1B 01, F1 = 1B 02, ... and so on. The IVC-MON (Version 2.0 and later) was modified to include support for these codes. One of the user selectable links on the IVC (one of the switches on the SVC) determines whether the keyboard to be used is the GM821 or GM827/​GM852. (The GM852 is a low-profile version of the GM827 with the only differences being that it is also available in a serial version, and that the very latest ones extend the user-defined keys into the Control mode as well.) If GM821 is selected then the code is passed on directly, if GM827/​GM852 is selected then all codes are passed on directly unless a 1BH is received, in which case it waits for the next code and translates it to the user-defined string held in its workspace RAM.

And so back to Dr Coker’s problem. If the IVC-MON (or SVC-MON) believes that the keyboard is a GM827/​GM852, but it is in fact a GM821, then when the ESC key is pressed the keyboard outputs the code 1BH, which tells the IVC-MON that this is a special case, and that another code will be used to select a user-defined string. Consequently nothing will happen until another key is pressed, and depending on what this is will determine what the IVC/SVC actually passes onto the system. If this is the ESC key again (being pressed in the belief that the












Page 4 of 31