Date : Thu, 13 May 1993 14:36:07 +1200
From : David Andrew Sainty <David.Sainty@...>
Subject: screens and modems and stuff
Double vertical res:
The interlace is first forced on accessing 6845 register 8. What I've done is
first switced interlace off for a frame, then on, in the hope that this
will consistantly switch between primary and secondary frames on alternate
Vsync interrupts. This seems to work, but I haven't tested it too much.
From then, it is simply a matter of switching back and forth between the two
screens by flipping bit 0 of ACCCON.
I haven't done anything with it apart from the initial test program to see
if it worked. Martin is right, this will only work on a master as it stands.
Perhaps a reduced screen height could work, eg two frames of 20 lines height
for 40 lines total and 24k memory. Hmm... hardly worth it, is it!
To use it properly requires new video drivers, which I have not done. It needs
to write alternate lines on alternate screen banks, quite messy!
Horizontal resolution increase I too don't think can be done. If my A User
Guide is correct, there is no way to increase the video clock rate further.
You can squeeze a few extra characters on the edges tho! :-) (I think I got
mode 0 up to 86 characters before it gave up).
I like your colour idea Mark! With two mode 0 screens flipped between, one
red, one green, that at least gives 4 colours for the same res. I'm not sure
whether this would look better with interlace on or off, off I guess?
Richard said:
>Oh yummy....let me at it! Yes, I've noticed that the existing version
>doesn't cope with most ZIP files on PC boards...but it has still been
>useful! Various folk were VERY keen on it when I told them about it - I take
>it its alright if I put a copy up for download on my BBS?
Yes, treat it as fully public domain. Err, tho now I think about it, perhaps
it'd be better to wait for the new version. Or, just put it up, but warn
people that a new version with a number of fixes will be released very soon.
When you say it dosen't cope with most zips, I assume you mean ones using the
new algorithm, not that it fails to correctly unzip imploded files?
The new version still does not handle shrunk or reduced files, but as these
will now be even RARER with deflation on the rise, I have even less inclination
to implement them now! :-)
>MNP2 is pretty sad tho'...although I suppose its the only level before its
>'non-PD'...V42bis would be nice, although I take it it would have to be some
>form of asynchronous version? Like the bodged MNP5 on some PC software?
V42bis has to sit on top of an error correcting protocol. MNP2 is the only
asynchronous protocol that is common (as it is part of the V.42 definition).
I don't know how MNP5 is done on PC software though, I thought that was
synchronous by definition....?
People.... Should I even bother with MNP2? Or should I go straight to
V.42 with additional hardware? It is true that MNP2 is not a patch on V.42,
and it is ALSO true that it may not even work with V.42bis on most modems.
I'm inclined to just go for the big one! :-)
>We should be launching a PD viewdata terminal of a very advanced nature soon,
>no doubt Martin Ebourne will tell you all about it...MARTIN!...
>Basically, should cope with baud rates up to AT LEAST 38400, mouse controlled
>windows, scrolling (continously updated) information bar, xmodem(-1k), Ymodem
Very nice indeed! Viewdata is all but forgotten in NZ unfortunately. I take
it it is still a common communication form in UK?
How about making the V.42 support hardware a standard and support it both in
your program and in tequilacomm?
>It really is good the amount of stuff thats now being done for the beeb in
>the comms scene...
It is indeed! Especially because it can handle it very well! It makes an
excellent terminal (And with custom software, you always have the features you
want! :-)
Dave.