🚀 go-pugleaf

rosenqui@ncs.dnd.ca (E. Rosenquist) writes:

> In article <09BViB1w164w@ersys.edmonton.ab.ca> mforget@ersys.edmonton.ab.ca (
> 
> > There is a GOOD reason not to use a GEM Window.  The first reason,
> > which you mentioned, is that the speed is VERY slow.  Even with
> > accellerators, the output can't keep up with more than 2400 baud in
> > Stalker.  Without an accellerator it would be hideously slow.
> 
> I beg to differ.  Based on my own experience, an unadorned 8MHz TOS
> 1.0 can keep up with 2400 baud in STalker.  Adding a software screen
> accelerator and/or a CPU enhancement can increase this to the point
> where 9600 baud screen output is achievable.  I should add however
> that the main limitation under VDI is not the text output speed but
> the scrolling speed.  You'll fall a bit behind if you get a blast of
> LF's in a row, but under more typical situations STalker can keep up.
> On a T16-equipped Mega4, according to a small test program I wrote,
> the best I could do was around 50 scrolls/second for an average-sized
> window.

I should have mentioned in my first post that my modem is not a standard 
2400 baud modem.  It is a Supra 2400 Plus.  It it uses a compression 
protocol when it can, so the text was coming across at around 4500-5000 
baud isntead of 2400.  This was with a screen accelerator installed.  It 
didn't fall far behind, of course, but enough so that the wait was 
disturbing.

> 
> The one very good reason TO use a GEM window is compatibility.
> Sticking to a VDI-only implementation may cost you a little in terms
> of speed, but in my humble opinion, you gain much more than that back
> in terms of compatibility and ease of use.

This is true, I suppose.  It is more compatible and a great deal easier 
to use for the novice.  The down side is that it is slower and an agany 
to implement...:)

> 
> > Also, a GEM window takes up space.  Instead of 25 lines (24 with a
> > status bar) you would have 23 lines and be forced to put the status
> > bar at the top of the screen.
> 
> In TT medium-res, Overscan, or any of the 3rd party high-res video
> cards there is plenty of room for everything.
> 
> > There is also the added joy of having to handle more complex
> > redraws.
> 
> True, but as they say "no pain, no gain".
> 
> > No, a window is not the way to go for me.
> 
> Evidently not.  If your main concern is to get something that does the
> job on specific systems, then do whatever you like.  I think the
> original question though was how to reserve a screen line in a "safe"
> manner, and as the ongoing discussion has shown, there are varying
> degrees of "safety", the ultimate being a GEM/VDI-based
> implementation.

Yes, the safest is through using the VDI.  The Line-A calls do work for 
all Atari computers in production, I'm told, but they may not work on 
future computers.  There is also the problem of working with MiNT.  If I 
shorten the screen and a user starts an editor in the background, 
unpleasent things would happen.  The way around this is to have the 
status bar as an option (which I elected to do).  Then there is the 
problem of screen modifications like Overscan or the others.  This is a 
fairly sticky problem, but not fatal.  If the status bar works on your 
particular setup, use it.  If not, turn it off and press Alt-S when you 
want to know what is going on (a dialog of information will appear if the 
user does that).

This is fairly frustrating...:)

> 
> > Subtract 1 from the value contained at $2AB2 and you have a shorter
> > screen.  Add 1 when you want to update the status bar.  It was as
> > simple as that.  At least for monochrome.  I'll have to try it with
> > color as well, since I am not sure if the address applies to all ST
> > machines.
> 
> Hmmmm, you're already in dangerous territory - the address you mention
> is almost certainly not the same across TOS revisions, and could
> conceivably change within a TOS version due to a screen accelerator.

Yes, you are right about that.  I should not have mentioned the $2AB2 
address, since I knew it was only really valid for my own system or other 
systems like it (TOS 1.4).  A more proper way to do it was mentioned to 
me, which is to do a "dc.w $a000" and then check "-42(a0).w".  This would 
tell me the height of the screen.  I am using Personal Pascal (with 
Tackle Box ST) though, so assembly language doesn't help me out a lot.  I 
wish it did.  Even so, I know next to nothing about assembly anyway.

Thanks for your comments.

> 
> Good luck,
> Eric Rosenquist


<<  ------------------------------------------  >>
<<        mforget@ersys.edmonton.ab.ca          >>
<<     ersys!mforget@nro.cs.athabascau.ca       >>
<<               Michel Forget                  >>
<<  "This offer is valid on absolutely ANY day  >>
<<           of the year, except...."           >>
<<  ------------------------------------------  >>