Denial

Hey everyone,

After trying out the existing Vic 20 terminal software it became very clear to me that a new terminal program was needed which supports colour CG mode. So I set about writing one in basic for the unexpanded Vic 20 called ViuTerm (Vic Unexpanded Terminal). It supports baud rates on the userport up to 1200 as well as the Commodore Flyer modem (which doesn't yet work very well), as well as a buffer which can be used to view text which scrolls off the screen. This is useful for visiting C64 BBSes made for a 40 column display. Text will sometimes scroll off the screen before you can read it. In the future the program will also support saving the buffer to disk, a phone book, and file transfers.

The one thing that needs improvment is the actual terminal read-write routine. Its pure basic now, but when using the buffer at 1200 it sometimes can't keep up and overloads. I'd like to write that bit in ML to speed it up, and also support 2400, or even 9600 like on the C64 (not sure if thats possible though). Could anyone help me out with this?


The current program can found here:

http://centronian.servebeer.com/files/viuterm0.20.prg

And the "user manual" can be found here:

http://centronian.servebeer.com/files/v ... .2-dox.txt

Neat!

I wonder if it's possible (but somehow sense it isn't) to combine some of the software 40-column emulators with a colour terminal program. We already have Term-40, but it's monochrome.

I'm sure its possible to get a 40 column colour CG term if you created a custom char set and bitmapped the screen. But the whole point of ViuTerm is that it works on an unexpanded VIC 20. There is no way you'll get a 40 column custom char set plus term code in without a RAM expansion.

ral-clan wrote:I wonder if it's possible (but somehow sense it isn't) to combine some of the software 40-column emulators with a colour terminal program.

See the thread 'MG Text Edit', and, to quote from the OP:

Mike wrote:The graphics mode limits the colour resolution to 2x2 characters, as the glyphs are 4x8 pixels and the attribute cells are 8x16 pixels.

In short: you can't give characters individual colours. Case closed.

Well, with some raster-tricks you could do a 160x200 screen with 8 pixel-width char-height and only have 2 characters with overlapping colors.
If you want to go crazy, with a 4x4 font you could shift the screen 4 pixels to the right after every displayed frame and back left 4 pixels the next frame. Then you can use the odd-lines in the first frame and the even lines in the second frame. This would provide full color-flexibility for each char in a 40x25 screen, however this would be far from being useable

For me having 40 column CG text isn't necessary. In fact, I've also been making some 22 column PETSCII screens for Centronian BBS. The goal is to eventually start up a VIC20 specific BBS that is all 22 column screens. This ViuTerm is the first step No point making the VIC20 do something its not going to do well... Better to make it shine in all its 22 column CG glory!

@tokra: the KERNAL RS-232 routines make extensive use of NMIs, and that will make any use of an 'active' display mode (i.e. using raster interrupts, etc.) a rather interesting feat. If we go as low as utilitizing some interlace mode, noone's going to use the program for more than 1 minute.

@alterus: before you begin to translate significant parts of ViuTerm into machine code, the program should advance in functionality beyond a simple bi-directional copy program. There's no character set conversion at all (a restriction to PETSCII locks you out of 99% of all still existing BBSs). There are also some bland errors: the memory management doesn't take into account the automatic allocation of two RS-232 256 byte buffers by the OS (with an automatic CLR, unless the buffer pointers had been set in advance), your own buffering happily thrashes these buffers; then there's the defunct file storage just because you added "S,W" instead of the correct ",S,W" (note the extra ","!) to the file name, etc.

IMO, the program should first get the basics right - adding funky menus at this stage merely amounts to boilerplate code.

Mike wrote:@alterus: before you begin to translate significant parts of ViuTerm into machine code, the program should advance in functionality beyond a simple bi-directional copy program. There's no character set conversion at all (a restriction to PETSCII locks you out of 99% of all still existing BBSs). There are also some bland errors: the memory management doesn't take into account the automatic allocation of two RS-232 256 byte buffers by the OS (with an automatic CLR, unless the buffer pointers had been set in advance), your own buffering happily thrashes these buffers; then there's the defunct file storage just because you added "S,W" instead of the correct ",S,W" (note the extra ","!) to the file name, etc.

IMO, the program should first get the basics right - adding funky menus at this stage merely amounts to boilerplate code.

I agree, I need to improve the code majorly before it can be considered "done". I'll add in the ascii conversion code, as well as take into account those RS-232 buffers. Thanks for pointing out the error in file save bit... OOPS.

Personally I don't plan on using this term for anything other that visiting PETSCII BBSes, and it already does that fine. But I guess others might want to head to ASCII/ANSI BBSes so good to have that in there. With all the extra code that will need, maybe I should disable the buffer for the unexpanded VIC, and only let it be enabled when a RAM expansion is added.

Mike wrote:(a restriction to PETSCII locks you out of 99% of all still existing BBSs).

There are currently 36 PETSCII BBSes listed on http://cbbsoutpost.servebbs.com/ so that's plenty for me. But ya.. you're right.

What about a 40 column PETSCII terminal program without colour (monochrome), or with a reduced colour palette. Would that be possible?

I do like the idea that it could go into full colour 22-column mode for VIC-20 compatible colour PETSCII BBS's.

MightyTerm does PETSCII or ASCII in monochrome 40 columns. You can find it in the Zimmers repository.