New VI clone with 40x24 char terminal

[pixel]

Very small thing tho. This time written in C mostly (see development branch of INGLE for sources and as usual you're welcome to join). Wants +32K RAM. Continued in small steps.
BEWARE: File encryption is just the passphrase XORed over the text, so it's probably crackable by juveniles who paid attention to math lessons.

[Mike]

In insert mode, Shift + "," should yield "<" I suppose, but I get "." instead.

[pixel]

In insert mode, Shift + "," should yield "<" I suppose, but I get "." instead.

Fixed.

[elderling]

I'm still having the shift-, problem with the newer .zip file ...

Love this!

[Mike]

I'm still having the shift-, problem with the newer .zip file ...

I'm testing this with WinVICE 3.1 r34289 and positional keyboard mapping, and at least here Shift+"," now gives "<".

However, I found yet another key map issue: Shift+"6" results in "(" instead of "&" - this was also already wrong in the 2022-05-23 version (I just did not stumble upon that at that time).

IMO, the whole key mapping and character encoding in this implementation of vi should be seriously checked. This is one of the basics which shouldn't go wrong with a text editor.

For MG Text Edit, I once implemented an alternative keyboard mapping routine, which actually returns ASCII instead of PETSCII, and where glyphs are missing from the VIC-20 keyboard, I mapped them like thus:

Code: Select all

          backslash  \   92  Pound
              caret  ^   94  Arrow Up
         underscore  _   95  Shift Minus
       grave accent  `   96  Arrow Left
 curly bracket open  {  123  Shift @
       vertical bar  |  124  Shift Pound
curly bracket close  }  125  Shift *
              tilde  ~  126  Shift Arrow Left

Here's the routine, which is supposed to be called via the ($028F) vector:

Code: Select all

REM>KeyboardSrc
:
DIM code 256
:
FOR pass=4 TO 7 STEP 3
P%=&3F00-2:O%=code
[OPT pass
 EQUW P%+2

 LDA #Keyboard MOD 256:STA &028F
 LDA #Keyboard DIV 256:STA &0290
 RTS

.Keyboard
 LDA &028D:ASL A:CMP #&08:BCC Keyboard_00:LDA #&06
.Keyboard_00
 TAX
 LDA Keyboard_01,X  :STA &F5
 LDA Keyboard_01+1,X:STA &F6
 JMP &EB74
.Keyboard_01
 EQUW Keyboard_02
 EQUW Keyboard_03
 EQUW &ECE0
 EQUW &EDA3
.Keyboard_02
 EQUB &31:EQUB &33:EQUB &35:EQUB &37:EQUB &39:EQUB &2B:EQUB &5C:EQUB &14
 EQUB &60:EQUB &77:EQUB &72:EQUB &79:EQUB &69:EQUB &70:EQUB &2A:EQUB &0D
 EQUB &04:EQUB &61:EQUB &64:EQUB &67:EQUB &6A:EQUB &6C:EQUB &3B:EQUB &1D
 EQUB &03:EQUB &01:EQUB &78:EQUB &76:EQUB &6E:EQUB &2C:EQUB &2F:EQUB &11
 EQUB &20:EQUB &7A:EQUB &63:EQUB &62:EQUB &6D:EQUB &2E:EQUB &01:EQUB &85
 EQUB &02:EQUB &73:EQUB &66:EQUB &68:EQUB &6B:EQUB &3A:EQUB &3D:EQUB &86
 EQUB &71:EQUB &65:EQUB &74:EQUB &75:EQUB &6F:EQUB &40:EQUB &5E:EQUB &87
 EQUB &32:EQUB &34:EQUB &36:EQUB &38:EQUB &30:EQUB &2D:EQUB &13:EQUB &88
 EQUB &FF
.Keyboard_03
 EQUB &21:EQUB &23:EQUB &25:EQUB &27:EQUB &29:EQUB &2B:EQUB &7C:EQUB &94
 EQUB &7E:EQUB &57:EQUB &52:EQUB &59:EQUB &49:EQUB &50:EQUB &7D:EQUB &8D
 EQUB &04:EQUB &41:EQUB &44:EQUB &47:EQUB &4A:EQUB &4C:EQUB &5D:EQUB &9D
 EQUB &83:EQUB &01:EQUB &58:EQUB &56:EQUB &4E:EQUB &3C:EQUB &3F:EQUB &91
 EQUB &20:EQUB &5A:EQUB &43:EQUB &42:EQUB &4D:EQUB &3E:EQUB &01:EQUB &89
 EQUB &02:EQUB &53:EQUB &46:EQUB &48:EQUB &4B:EQUB &5B:EQUB &3D:EQUB &8A
 EQUB &51:EQUB &45:EQUB &54:EQUB &55:EQUB &4F:EQUB &7B:EQUB &5E:EQUB &8B
 EQUB &22:EQUB &24:EQUB &26:EQUB &28:EQUB &30:EQUB &5F:EQUB &93:EQUB &8C
 EQUB &FF
]
NEXT
:
OSCLI "Save driver &"+STR$~code+" &"+STR$~O%

(Please excuse the boilerplate and the use of "&" to denote hex. This is the BBC BASIC inline assembler.)

The tables cover the printable 7-bit ASCII set with unshifted and shifted keys, no further translation is necessary. The mappings of Ctrl and C= keys are preserved by using the original ROM tables.

pixel, is it possible you include this keyboard mapping with your vi?

[pixel]

First of all thanks a million, guys, for your help. Sure as hell I'd go for something that's working better – mine is reading from the keyboard buffer too. Gotta compare the maps. Actually I'd love to go for various shift/ctrl/c= combinations if that's even possible (didn't figure out the wiring yet). Keyboard repetition is also missing. Am relying on the latter heavily.

Am guessing that libterm will end up with maps which can be changed/loaded at run-time.

BTW: Here's the current code of the terminal emulation: https://github.com/SvenMichaelKlose/ing ... c/lib/term – VI is also there, two levels up. As well as Ultifs which seems to make a little progress as well.

[Mike]

[...] mine is reading from the keyboard buffer too.

Sorry, but no: the routine I gave above partially replaces the original matrix decoding routine before the decoded characters are put in the keyboard buffer. In doing so, it calls the tail of the original routine that then handles key repeat, and so gets that right.

The routine in your repository in contrast aims to replace GETIN completely. It checks whether at least one key has been put into the keyboard buffer, purges that buffer and thus loses the buffering functionality. At the end it does double work as it decodes $C5 plus the Shift-Flags a second time.

IMO, putting literal character glyphs into the encoding tables is a rather unlucky choice. For anything beyond 7-bit ASCII you just can't be sure the assembler translates them to exactly the values you want, within the assembler an own PETSCII <-> ASCII conversion step might be at work, or even worse, the strings may get translated to screen codes. Those are the reasons I refrained from literals for this application and instead built the tables from hex constants.

Sure as hell I'd go for something that's working better [...]

When you put my routine into the ($028F) vector, you can use GETIN for buffered keyboard input with key repeats as usual. Only the control characters will need extra remapping, as I kept those of PETSCII.

[chysn]

This is a great project! I've always been Team Vi.

There are several things I miss, but the most important one might be the p (place) command.

[Mike]

I found the version of the keyboard driver I first posted was slightly outdated. It had retained 'cruft' from a version that had been adapted specifically for MINIPAINT. The current version has the same tables but now continues in ROM at a much earlier place, which shortens the routine quite a bit.

I have updated the post above with the current version. This one also includes the vector init for ($028F).

[pixel]

Thanks, guys. Here's a version with the SHIFT+7 issue fixed. ca65 doesn't translate strings, so human-readable keymaps are fine.
Since libterm is heading for vt?? terminal compatibility I'd actually like to replace the KERNAL routines for real.
My keymaps didn't work at all with SCNKEY. Doesn't it modify KEYTAB anyhow?

[pixel]

This one can be run with +32K but it detects additional RAM on RAM1,2,3, IO2,3 and BLK5. That's ~19K for text left but there's a lot of overhead (12bytes for each line).

[Mike]

[...] it detects additional RAM on [...] IO2,3 [...]

Unfortunately, it also detects the I/O area of Mega-Cart as "RAM", which it actually isn't.

Even though I did not notice any overt issues right at start - vi unpacked itself and I could execute a few editor commands -, some of the addresses in I/O act otherwise than RAM, changing the banking config or causing a reset. These effects supposedly manifest later, when vi reaches that area during text editing work, where it then will also thrash the MC settings and the menu music.

There is really no reliable method to detect RAM in I/Ox. Even read accesses can trigger side effects not foreseeable by 3rd party software. As I've already stated elsewhere here in Denial, IMO the only legit user of the cartridge I/O area is the cartridge firmware. My RAM check explicitly prompts the user whether it should check for RAM in I/Ox, and makes "N" the default choice for that test.

[pixel]

Right. Here's another one. Not touching the IO area and with somewhat working 'w' and 'b' command.