Re: Todd's ELF-ish gets gets a Video Interface System (VIS) #ELF #Homebrew

taf123
 

Now that we're oscillating, and working in both Character Generator and Bit-Map modes, it's time to turn our attention to the keyboard input.

I do have a couple of the CDP1971 Keyboard Encoders that the original VIS design uses, but I don't really feel like building a custom keyboard at this time - although that may be an interesting side project some time.

So I looked over the shoulder of the student next to me, and stole their approach ;-)

In this case, I "borrowed" the AT89C2051 MCU based PS/2 keyboard to byte-parallel ASCII used on their GPIO board.  But instead of using their PLD-based interface circuit, I decided to just go with a CDP1852 byte-I/O in input mode - the built-in CLOCK / !SR action being used for the necessary hand-shaking.

ICAN-7032 shows connecting a parallel encoded keyboard to the VIS using a CDP1852, using the CDP1869 decoded !N=3 line, inverted, as the CDP1852 CS2.  The VIS Demo Board illustrated in the Design Ideas Book also uses this approach.

Sounds likes a good way forward. Note that the signal from the MCU to indicate data ready, what the ELF2k GPIO schematic calls SET_KEY_DATA_RDY_L, and I call !KB_STB, is active LO, but the CDP1852 requires a HI clock pulse, so I just invert this.

Here's the schematic.



Again I included a jumper to select between !EFx polling and interrupt operation.

Here's the completed wiring, with the '2051 as U15 in the upper middle with support components, and the CDP1852 below that as U16, and a 4-pin Molex connector for the PS/2 keyboard connector.



My Wellon VP598 programmer supports the AT89C2051 MCU's, plus a host of others.  It was a good purchase - would recommend one if you need a universal programmer.



Thanks again to the STG people for supplying the Intel HEX dump so I could flash my own.

I also added the 4-pin Molex connector for the '2051 UART debug output, although the supplied HEX dump didn't have debug enabled.



And ready for testing.



Although I forgot to take a pic of connecting the 16-channel logic analyzer to the AT89C2051 MCU, and matching CDP1852 byte-input port, I did save the data.

This shot verifies that I have the PS/2 keyboard connector wired correctly.

No photo description available.

According to the standard, after the keyboard powers on, it does a BAT (Basic Assurance Test).

When it finishes, it signals success by sending 0xAA.

Channel 1 is the clock from the keyboard, channel 2 is the serial data. Reading at each clock low, you have 1 start, 8 data bits, parity, and 1 stop bit.

Result = 0xAA, successful BAT.

This shot shows the MCU actions just as it comes out of RESET.

No photo description available.


Channel 5 looks like the RESET line (active HI).

Channel 4 is the active LO strobe line which the '2051 uses to signal to the input port that data is ready.

Channel 3 is '2051 pin 9, which lights the LED when there is data waiting (active LO)

And channels 8-15 are the data lines.  According to the provided source code, the '2051 outputs three bytes right out of RESET as part of the initialization.

PUBLIC void ConvertKeys (void){
  BYTE bKey;  BOOL fRelease;
  m_bKeyFlags = 0;
  SendHost('K' | 0x80);  SendHost ('B');  SendHost(VERSION);
  DBGOUT(("ConvertKeys() initialized ...\n"));
    ...

The data lines decode to 0xCB, which is ('K' | 0x80), so it's working.  Cool!

Here's a quick and dirty test of the PS/2 keyboard interface, using the UT4 serial interface for output.



After downloading the code (the first 2 lines), the "$P00" runs it.

Of the three bytes the '2051 sent after coming out of reset, only the 'B' is printed - the version is an unprintable character so only a space shows, but what happened to the ('K' | 0x80)?  I would expect that at least a space would have been printed before the 'B'.  Something for further investigation...

After that, the program reads any data from the input port (PS/2 keys mapped to ASCII) and prints to the serial port.

I typed "Hello World!!!!", which was correctly displayed.

Yay.

After further investigation, I found the missing K.

The CDP1852 data sheet warns about using the same N decode for a CDP1852 in input while it is also used with an output device:

"In a CDP1800 series microprocessor-based system where
!MRD is used to distinguish between INP and OUT
instructions, an lNP instruction is assumed to occur at the
beginning of every I/O cycle because !MRD starts high.
Therefore, at the start of an OUT instruction, which uses the
same 3-bit N code as that used for selection of an input port,
the input device is selected for a short time (see Figure 8).



This condition forces SR low and sets the internal SR latch.
In a small system with unique N codes for
inputs and outputs, this situation does not arise. Using the
CDP1853 N-bit decoder or equivalent logic to decode the N
lines after TPA prevents dual selection in larger systems."

This is why I normally use the CDP1853 for my N-line decoding.

The CDP1869 decodes the N-lines internally, and has access to TPA and TPB, so I had assumed they would have taken this into account.  Of course, the CDP1869 and 1870/76 only use OUT instructions, so they must have left this out.

That little code snippet for my PS/2 test also included the basic VIS initialization, including the OUT 3 required to configure the CDP1876.

When the OUT 3 happens, the CDP1852 sees this spurious "read" condition and resets it's SR line.  This signals to the '2051 that the character has been read, so it sends the next one, the 'B', which overwrites the 'K', so my code never sees it.

Just being a little pedantic about the potential for losing a character if the code ever changes the format of the VIS using an OUT 3, plus wanting to match for the '2051 start up characters in my code to verify that it has initialized correctly, I decided to fix this by adding a CDP1853 to decode the N=3 for the CDP1852.

Since I had to do some rewiring anyways, I started a little side project to recompile the '2051 code so the strobe to the CDP1852 would be active HI and I could remove the inverter.  Plus, I wanted to support a UK keyboard layout.

That little side project is detailed in the thread "Recompiling the ELF 2000 PS/2 AT89C2051 SW", https://groups.io/g/cosmacelf/topic/recompiling_the_elf_2000_ps_2/31262983, which was my first posting to this forum.

See that thread for details.

Here's the updated schematic



Fortunately, the board layout has a space open right in the upper middle where I could insert the CDP1853.



And this all worked as planned.  So now I can reliably read the initialization codes from the '2051, I saved an inverter, and my UK keyboard is properly supported.

I just need to modify the VIS demo to use the PS/2 keyboard instead of the UT4 serial interface.

Now we are caught up with the current state of the ELF-ish build.

Further updates as the project progresses.


Hope you have enjoyed it so far.  More to come.

Todd

Join cosmacelf@groups.io to automatically receive all group messages.