Terminal programs and 80-column cards (DATA-20)

Modding and Technical Issues

Moderator: Moderators

User avatar
ral-clan
plays wooden flutes
Posts: 3702
Joined: Thu Jan 26, 2006 2:01 pm
Location: Canada

Re: Terminal programs and 80-column cards (DATA-20)

Post by ral-clan »

Hi Mike!

My Data-20 has 8K RAM installed, so it has 11775KB free after boot.
This can be put in BLK3 or BLK5 with a switch.

Apparently, the Data-20 can also be used with RAM cartridges and a multi-slot expander.

Excited to see what you come up with.
Image Music I've made with 1980s electronics, synths and other retro-instruments: http://theovoids.bandcamp.com
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Terminal programs and 80-column cards (DATA-20)

Post by Mike »

Here we go (download):

Code: Select all

10 POKE55,0:POKE56,61:POKE247,0:POKE248,61:POKE249,0:POKE250,62:CLR
11 FORT=16128TO16351:READA:POKET,A:NEXT:SYS16128
12 :
13 DATA 169,11,141,143,2,169,63,141,144,2,96,173,141,2,10,201,8,144,2,169,6,170,189,86
14 DATA 63,133,245,189,87,63,133,246,164,203,177,245,170,196,197,240,7,160,16,140,140,2
15 DATA 208,32,41,127,44,138,2,48,22,112,26,201,127,240,19,201,20,240,12,201,32,240,8
16 DATA 201,29,240,4,201,17,208,6,76,161,235,76,186,235,76,214,235,94,63,159,63,224,236
17 DATA 163,237,49,51,53,55,57,43,92,20,96,119,114,121,105,112,42,13,4,97,100,103,106
18 DATA 108,59,29,3,1,120,118,110,44,47,17,32,122,99,98,109,46,1,133,2,115,102,104,107
19 DATA 58,61,134,113,101,116,117,111,64,94,135,50,52,54,56,48,45,19,136,255,33,35,37
20 DATA 39,41,43,124,148,126,87,82,89,73,80,125,141,4,65,68,71,74,76,93,157,131,1,88,86
21 DATA 78,60,63,145,32,90,67,66,77,62,1,137,2,83,70,72,75,91,61,138,81,69,84,85,79,123
22 DATA 94,139,34,36,38,40,48,95,147,140,255
I've put this into the *.zip file of the attachment.

You first run this program (with the standard +8K RAM setting in BLK1, i.e. 11775 bytes free), then enter the OPEN statement (you'll already have to use Shift to write OPEN ;)) and then press F8. STOP/RESTORE returns to the standard keyboard driver. Please give a feedback how you fare with this.
User avatar
ral-clan
plays wooden flutes
Posts: 3702
Joined: Thu Jan 26, 2006 2:01 pm
Location: Canada

Re: Terminal programs and 80-column cards (DATA-20)

Post by ral-clan »

Hi Mike!

Your program worked well! Thanks. I activate it and it throws everything into upper case, then I use the OPEN statement and then enter the terminal mode of the Data-20.

Everything works perfectly!

So what is your program doing? I have a vague idea but it would be interesting to know the details.

Also, I've already written a BASIC program that lets me choose the baud rate and opens the channel to the user port. Would you forsee any problem if I added your code to this BASIC program to execute your Lower case / Upper Case code swith? You mentioned your code must be executed before the open statement, why is that important?

If I did that I would have an all-in-one setup utility for the Data-20's terminal mode.

Thanks very much for taking the time to do this. I think this program should be archived so that other Data-20 and Protecto-80 users can use it. Would it be okay if I sent your program to R. Melick's Data-20 website and Bo Zimmer's Data-20 files archive?

Thanks.
Image Music I've made with 1980s electronics, synths and other retro-instruments: http://theovoids.bandcamp.com
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Terminal programs and 80-column cards (DATA-20)

Post by Mike »

ral-clan wrote:So what is your program doing?
In short: It converts the VIC-20 keyboard into a true 7-bit ASCII keyboard.


A slightly longer description follows, together with my motivation why I thought that this was the easiest way to go:

The keyboard handler in the KERNAL scans the keyboard matrix, and for all non-modifier keys (Shift, CBM and Ctrl) it returns a unique number. Another routine uses 4 tables (for unmodified, shift, C= and Ctrl) to turn this number into a character code. This then is normally interpreted as PETSCII, then routed for output and in some way printed to screen, so you get on screen what you typed in.

Now, the terminal program has to do something extra: the (7-bit) ASCII character set in the outside world does not feature graphic characters, rather lower and upper case letters, digits, symbols and control characters. To this, for display, the lower/upper case version of PETSCII is the best approximation, albeit not perfect: lower and upper case are swapped between ASCII and PETSCII, and some other characters display entirely different: for example, there's no left arrow symbol in ASCII, the left arrow in PETSCII has the character code 95, that however displays as underscore in ASCII - conversely, there's no true underscore in PETSCII; CHR$(164) doesn't count (curly brackets, backslash, tilde, etc. are other problematic codes).

At least for the common subset of displayable characters, the terminal program now has to:

1. Convert what you typed in from PETSCII to ASCII,
2. Send this to the modem, in the expectation, that modem and BBS expect ASCII,
3. Receive data from the BBS and, ultimately, the modem, which it has to handle as incoming ASCII,
4. Finally convert the incoming ASCII data stream to PETSCII to display it on screen.

From your description, you got the data from the BBSs without any hassles, which indicated to me, that steps 3 und 4 were working as expected. Also, step 2 seemed to work, otherwise you wouldn't have been able to send any commands to the modem and type into the BBSs.

However, step 1 seemed to be lacking - as if the terminal program was just sending the data it got from the keyboard in a binary transparent way, and relying upon the echo facility of the BBS to return the typed-in character back to you, the sender. So, what you sent to the BBSs, still as PETSCII - but was returned via echo, handled as if it was ASCII and - correctly! - translated to PETSCII once again.

From this it followed for me, that the best thing one could do was to change the keyboard of the VIC-20 into a true ASCII keyboard. That means the unshifted and shifted keys produce ASCII character codes, so no translation needs to be done anymore in step 1. Of course outside the terminal program, those codes are still interpreted as if they were PETSCII, and this is why you need to hold Shift now while typing in the OPEN command.

I had developed this routine quite some time ago, for MG Text Edit. There, the whole internal processing is done in ASCII, and the glyphs for display are also done as 7-bit ASCII. This eliminated any extra conversion processes. It was no big deal to extract the routine and provide it here. :) Ideally, the Data-20 should also provide a correct ASCII character ROM so all BBSs would display correct *all* 7-bit ASCII characters, but that's not that easy to modify as you'd surely guess.
Also, I've already written a BASIC program that lets me choose the baud rate and opens the channel to the user port. Would you forsee any problem if I added your code to this BASIC program to execute your Lower case / Upper Case code swith?
That shouldn't pose any problems at all. I'd rather think this is what programming also is about - taking other's code, analyse it, understand *) it and improve upon it. A quality that's sometimes missing here in Denial. :(

I just didn't incorporate this extra already, because I didn't want to 'fixate' you on one certain baud rate with a given OPEN statement. Rather I simply suppose you know what you're doing. ;)
You mentioned your code must be executed before the open statement, why is that important?
Two reasons: 1. the RUN command for the driver would close the before-OPENed RS232 channel, and 2., the program places the transmit and receive buffers at a defined place so it's guaranteed those two buffers won't collide with the machine code of the new keyboard handler.
Would it be okay if I sent your program to R. Melick's Data-20 website and Bo Zimmer's Data-20 files archive?
I'm fine with that. If you did that with a thoroughly tested version of the combined program (i.e. your baud rate selection included), all the better.

Greetings,

Michael


*) the new keyboard handler is a wedge into the vector at $028F/$0290. The original routine in the KERNAL at $EBDC is partly replaced, and the new handler uses two changed tables for the unshifted and shifted keys, which now return ASCII codes instead of PETSCII.
Post Reply