Hi Guy,

This is going to be a long answer..........


I have three different VZ - 101 keyboards each progressing as it were in
terms of both ease of connectivity and also programmability.

First to the hardware:

The first project is the one which I have documented in the Hunter Valley
Journal (use Dave's index to find out which issues - it is in three of them
I think, in the last 30's or early 40's I'm not sure). This keyboard was
basically rewired to directly replace the standard VZ keyboard (hooked up to
a 200 not a 300). The VZ keyboard was removed, the ribbon cable replaced
with header pins and a new cable created with a plug on the end. The draw
back is that the length of the cable cannot be too long as it suffers signal
degradation. Additional keys were initially hardwired similar to the way you
currently are emulating the keyboard, eg a 1 on the keypad is the same as
the 1 above the Q key. I did not like this because hitting shift - 1 on the
keypad produced a ! character. I consider this to be a poor solution.

The second keyboard project consists of two Keyboard Matrixes, the standard
VZ matrix (with the three unused places used by the ALT key, / key and = key
as per a previous post) and the extended matrix also as per my last post. At
this stage I started to rethink the whole hardware aspect of the VZ. What I
did was create an Expansion Board which plugs into the VZ expansion port
which in turn allows 8 cards to be plugged in (36 pin connecters I think).
This keyboard connects to the VZ in two places, directly replacing the VZ
keyboard connecting to the header pins, plus an additional connection to a
Keyboard Card that I built which contains the 74LS138 and 74LS147 plus some
other chips.

The third keyboard project, consists of two Extended matrixes, each catering
for 72 Keys, thus allowing for 144 keys in total. This keyboard only
connects to the VZ via a Keyboard Card but does not suffer the same
type of signal loss that you get with the standard matrix. The problem with
this approach and why it cannot be emulated is that without a VZ keyboard
plugged in how do you type in a command, well without a BOOT RAM to load the
keyboard driver on power up, you cannot and so we arrive at the moment in
time when NOS 'The Concept' was born - there were other software issues to
consider as well.


To the Software:

KSCAN is the software - or to be more specific it is a Keyboard driver with
some additional bells and whistles (ie additional commands available from
BASIC).

KSCAN itself has evolved very minimally in that time because 1) it works and
2) my attention turned to NOS - where a much smaller Keyboard Device Driver
is a fundamental component (and can be loaded from the config file - sound
familiar ??).

But to answer finally your question, *yes* it works with the BASIC
interpreter. Again this was documented in the Hunter Valley Journal, but to
summarize:

The TRS80 ROM's were written in such a way as to allow for expansion -
however Video Technology and all of the early Assembly Language Programmers
tried to cripple as best as they could. Video Technology is at fault for two
reasons, firstly the additional ROM routines containing the Color BASIC
commands do not obey the LEVEL II rules and scan the matrix directly for
the break key in a few places - I have a list of BASIC commands that do the
wrong thing. Also VZ DOS scans the matrix directly for some commands as
well.

The programmers got it wrong because someone published the location of
the default keyboard scanning routine (2EF4h) which it appears that just
about everyone then used (WRONG WRONG WRONG !!!!!!).

A very important location (7816H) exists in communications RAM called the
KDCB - Keyboard Device Control Block. This contains the
location of the matrix scanning routine (by default it is set to 2EF4H) and
is updated when KSCAN is installed. If the programmers had done the right
thing then they would have called 002BH which would lookup the current
keyboard scanning routine and perform the scan (so on a standard VZ it would
eventually get to 2EF4H). With KSCAN installed, the program would have used
the new keyboard driver and its lookup tables.

Finally, the VZ scans the keyboard every interrupt in its default Interrupt
Service Routine. KSCAN bypasses this by installing itsa own Service Routine
which does all the default noe does, plus extras.

Thats the pluses, now for the negatives:

1. Any program that scans the keyboard itself by reading the memory mapped
matrix bypasses the KSCAN lookup tables and of course the extended matrix.
So to give an example, if the "Q" key is remapped to return the "T"
character, that program cannot know this outcome. As we all know today, only
device drivers can make any assumption about hardware - it is wrong to read
the 6800H addresses to scan the keyboard.

2. Any program that calls 2EF4H directly again bypasses KSCAN because it has
totally ignored the KDCB. The correct way to scan the keyboard is CALL
002BH. In terms of the emulator, the way to fix this is to intercept the
direct calls to 2EF4H and replace them with the correct call. The tricky
part is to know when this should be done.

3. Any program which installs its own interrupt service routine will
interfere with KSCAN. INKEY$ will continue to work with KSCAN, but the
direct input routines such as INPUT$ and the BASIC interpreter itself will
no longer understand any remapped keys as per (1) and will also no longer
respond to the Extended Matrix. Eg. the versions of KSCAN and the VZ BUS
Mouse driver I have previously released into the public domain cannot
currently be loaded at the same time. Again, this is one of the fundamental
issues that NOS is designed to resolve.

Leslie.

----- Original Message -----
From: Guy Thomason
To: vzemu@yahoogroups.com
Sent: Tuesday, November 04, 2008 9:20 AM
Subject: RE: [vzemu] VZ Extended Keyboard Matrix Definition


Leslie,

Can you plug this keyboard into a normal vz and have it work with the basic
interpreter? If so how does this work - using an interrupt routine?
Do you connect it to the VZ via the expansion port?




From: vzemu@yahoogroups.com [mailto:vzemu@yahoogroups.com] On Behalf Of
Leslie Milburn
Sent: Monday, 3 November 2008 9:00 PM
To: vzemu@yahoogroups.com
Subject: [vzemu] VZ Extended Keyboard Matrix Definition

Hi Guy,

I have finally found the KSCAN 3 documentation. Basically, after I wrote the
article for the Hunter Valley Journal, I was not happy with my initial
solution and so I rewired the 101 keyboard again, this time to have an
additional keyboard matrix catering for an additional 72 Keys, of which 50
have been used and so we should probably also implement the New Windows Keys
whilst we are at it.

I have attached a scan of the Extended keyboard Matrix which shows you what
additional keys are supported. This matrix is read as follows:

Port 60H - Read Column 0
Port 61H - Read Column 1
Port 62H - Read Column 2
Port 63H - Read Column 3
Port 64H - Read Column 4
Port 65H - Read Column 5
Port 66H - Read Column 6
Port 67H - Read Column 7

Also writing to Port 60H is suppoed to do the following but I cannot
remember if I actually completed the job.

D0 - Caps Lock Toggle.
D1 - Num Lock Toggle.
D2 - Scroll Lock Toggle.

For those interested in the hardware side of things, its a very simple
circuit combining a 74LS138 with a 74LS147 to create the matrix. Its a shame
the original VZ keyboard matrix was not done this way rather than it being
memory mapped because for a low memory machine retaining every byte counts,
IMO, alothugh not an issue with the 4Mb Extended Memory.

If I get some time in the next few days, I'll dig out that particular
machine and set it up to check everything was done as documented, but it is
a starting point in terms of emulation.
Leslie.