Shop OBEX P1 Docs P2 Docs Learn Events
Spin code help required for a hardware type (S-100 Computers) — Parallax Forums

Spin code help required for a hardware type (S-100 Computers)

monahanzmonahanz Posts: 3
edited 2011-10-18 09:47 in Propeller 1
Hi everybody, I am new to this forum. By way of background I am one of a small (but growing) group of people that work with S-100 Computers. These were the early hobby computers of late 70’s early 80’s. We utilize old boards but also design and utilize new S-100 boards for the S-100 Bus. If you want to find out more see my web site

www.S100Computers.com.

Anyway to the point. There has always been a frustration in the group with the lack of a good console IO video board to work with modern LCD displays. After reviewing various CRT controller chips etc. I decided to utilize the Propeller chip for keyboard input and its onboard VGA display for data output. A few of us designed and built and now supply such a board. See here for a description of this board.

http://s100computers.com/My%20System%20Pages/Console%20IO%20Board/Console%20IO%20Board.htm

The hardware worked out great and is very reliable.
Here is the problem. The software to interpret the IBM-PC style keyboard input was spliced together from some entries on this site. It’s contained in a spin program called Keyboard.spin . I wrote a very basic program called ConsoleIO.spin to interact with this program to obtain the “translated” keyboard key and send it to the S100 bus. Again things work great and are very reliable.

Unfortunately however I cannot understand (nor can anybody else in the group) the ASM code in keyboard.spin that takes care of the CTRL and ALT keys. We cannot understand how to let the ConsleIO.spin module know if either of these keys are pressed.

Is there anybody in this knowledgeable group that could take a few moments to look at the code and help us out? The two modules are at the very bottom of this page.

http://s100computers.com/My%20System%20Pages/Console%20IO%20Board/Console%20IO%20Board.htm

Any help would be deeply appreciated as it will allow us to have a very functional board.

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2011-10-17 23:17
    The returned (key) code is actually a word (16bit). Unfortunately your program uses a byte variable which means the relevant info is discarded. At the bottom of keyboard.spin you'll find this comment: 
    ''      C8      Backspace
''      C9      Delete
''      CA      Insert
''      CB      Esc
''      CC      Apps
''      CD      Power
''      CE      Sleep
''      CF      Wakeup
''
''      ...
''
''      FD      Scroll Lock State
''      FE      Caps Lock State
''      FF      Num Lock State
''
''      +100    if Shift
''      [COLOR="orange"]+200[/COLOR]    if Ctrl
''      [COLOR="orange"]+400[/COLOR]    if Alt
''      +800    if Win
''
''      eg. Ctrl-Alt-Delete = $[COLOR="orange"]6[/COLOR]C9
    Meaning the modifier state is held in the MSB of the returned word. HTH

    So let's say the result is returned in keycode (being a word). Then the actual character is in keycode.byte[0] and the modifier in keycode.byte[1].
  • Cluso99Cluso99 Posts: 18,069
    edited 2011-10-18 00:39
    monahanz: Welcome to this fabulous forum. Obviously you are already well acquainted with the propeller.

    Are you aware that we have CPM running on the propeller under emulation? The program is called ZiCog and there are a number of pcbs that run this code usually with a 512KB SRAM. The N8VEM group have also been playing with the prop and interfacing it to the bus they use.

    Very nice website! I see you already know Andrew Lynch (N8VEM).
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-10-18 06:15
    Hi Monahanz - yes you will find familiar faces here too.

    As Kuroneko points out, you may need two bytes to specify all the keyboard codes. I don't think there are enough values in 1 byte to express all the keyboard combinations (eg ctrl, or alt, or ctrl and alt and a key). I wonder if you can alter things at the CP/M end so a keyboard input is two bytes rather than one?

    As Cluso points out we have the Z80 emulated on the prop. One day I am going to build the perfect prop/Z80 combo board with a real Z80, ram, load up the ram from the prop so no eprom, prop does the I/O, keyboard, sd card, serial, display. I have got to use those Z80 chips in the shed somehow!
  • monahanzmonahanz Posts: 3
    edited 2011-10-18 09:41
    kuroneko wrote: »
    The returned (key) code is actually a word (16bit). Unfortunately your program uses a byte variable which means the relevant info is discarded. At the bottom of keyboard.spin you'll find this comment: 
    ''      C8      Backspace
''      C9      Delete
''      CA      Insert
''      CB      Esc
''      CC      Apps
''      CD      Power
''      CE      Sleep
''      CF      Wakeup
''
''      ...
''
''      FD      Scroll Lock State
''      FE      Caps Lock State
''      FF      Num Lock State
''
''      +100    if Shift
''      [COLOR="orange"]+200[/COLOR]    if Ctrl
''      [COLOR="orange"]+400[/COLOR]    if Alt
''      +800    if Win
''
''      eg. Ctrl-Alt-Delete = $[COLOR="orange"]6[/COLOR]C9
    Meaning the modifier state is held in the MSB of the returned word. HTH

    So let's say the result is returned in keycode (being a word). Then the actual character is in keycode.byte[0] and the modifier in keycode.byte[1].

    Thanks Kuroneko. makes complete sense, will try that
  • monahanzmonahanz Posts: 3
    edited 2011-10-18 09:47
    I was actually thinking of that a while back. Looks like I have a lot of catching up to do! An S-100 based Propeller system with the Propeller as a slave CPU (IEEE-696 style) would be real neat in hardware.
    Currently we are doing 80286/386 and Cirrus Logic GP-5420 VGA S-100 boards so would be some distance off.
Sign In or Register to comment.