Page 1 of 1
New VI clone with 40x24 char terminal
Posted: Mon May 23, 2022 8:55 am
by 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.
Re: New VI clone with 40x24 char terminal
Posted: Mon May 23, 2022 6:43 pm
by Mike
In insert mode, Shift + "," should yield "<" I suppose, but I get "." instead.
Re: New VI clone with 40x24 char terminal
Posted: Tue May 24, 2022 1:52 am
by pixel
Mike wrote: ↑Mon May 23, 2022 6:43 pm
In insert mode, Shift + "," should yield "<" I suppose, but I get "." instead.
Fixed.
Re: New VI clone with 40x24 char terminal
Posted: Mon May 30, 2022 9:11 am
by elderling
I'm still having the shift-, problem with the newer .zip file ...
Love this!
Re: New VI clone with 40x24 char terminal
Posted: Thu Jun 02, 2022 2:25 am
by Mike
elderling wrote: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%
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?
Re: New VI clone with 40x24 char terminal
Posted: Fri Jun 03, 2022 2:19 am
by 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.
Re: New VI clone with 40x24 char terminal
Posted: Fri Jun 03, 2022 5:41 am
by Mike
pixel wrote:[...] 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.
Re: New VI clone with 40x24 char terminal
Posted: Fri Jun 03, 2022 11:31 am
by 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.
Re: New VI clone with 40x24 char terminal
Posted: Fri Jun 03, 2022 10:41 pm
by 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).
Re: New VI clone with 40x24 char terminal
Posted: Sat Jun 04, 2022 8:36 am
by 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?
Re: New VI clone with 40x24 char terminal
Posted: Sat Jun 04, 2022 10:40 pm
by 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).
Re: New VI clone with 40x24 char terminal
Posted: Sun Jun 05, 2022 3:36 am
by Mike
pixel wrote:[...] 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.
Re: New VI clone with 40x24 char terminal
Posted: Sun Jun 05, 2022 5:31 am
by pixel
Right. Here's another one. Not touching the IO area and with somewhat working 'w' and 'b' command.