Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Why live with 24 lines?
440 views
Skip to first unread message
Jon Saxton
Aug 18, 2014, 6:44:00 PM8/18/14
to
In the days when people hooked CRT terminals to CP/M computers one had
to live with the limits of those terminals. Typically, that meant 24 or
25 lines of 80 columns.
Nowadays it is probably cheaper and easier to connect an old laptop to a
real CP/M system or to run CP/M in an emulator. In either case the
24x80 limits no longer apply yet I have the impression that most people
stick with the old screen dimensions. I would be interested in learning
why.
Personally, I find 40 lines a lot more useful. 106 columns is enough to
view an assembly language listing file without line wrap. However I
always use 80 columns because when I write software for CP/M I also do
my editing on CP/M and constraining the source code to fit into 80
columns is fairly normal practice.
I am not suggesting that anyone should change his habits but I find it
very enlightening to learn why people do things in a particular way. It
is too easy to become blind to perfectly valid reasons.
--
Former sysop of Tesseract RCPM+ which operated
in the 1980s from Dural, NSW, Australia.
http://triton.vg/TesseractRCPM+Catalog.html
to live with the limits of those terminals. Typically, that meant 24 or
25 lines of 80 columns.
Nowadays it is probably cheaper and easier to connect an old laptop to a
real CP/M system or to run CP/M in an emulator. In either case the
24x80 limits no longer apply yet I have the impression that most people
stick with the old screen dimensions. I would be interested in learning
why.
Personally, I find 40 lines a lot more useful. 106 columns is enough to
view an assembly language listing file without line wrap. However I
always use 80 columns because when I write software for CP/M I also do
my editing on CP/M and constraining the source code to fit into 80
columns is fairly normal practice.
I am not suggesting that anyone should change his habits but I find it
very enlightening to learn why people do things in a particular way. It
is too easy to become blind to perfectly valid reasons.
--
Former sysop of Tesseract RCPM+ which operated
in the 1980s from Dural, NSW, Australia.
http://triton.vg/TesseractRCPM+Catalog.html
dottor Piergiorgio M. d' Errico
Aug 18, 2014, 7:14:36 PM8/18/14
to
Il 19/08/2014 00:44, Jon Saxton ha scritto:
> In the days when people hooked CRT terminals to CP/M computers one had
> to live with the limits of those terminals. Typically, that meant 24 or
> 25 lines of 80 columns.
>
> Nowadays it is probably cheaper and easier to connect an old laptop to a
> real CP/M system or to run CP/M in an emulator. In either case the
> 24x80 limits no longer apply yet I have the impression that most people
> stick with the old screen dimensions. I would be interested in learning
> why.
>
> Personally, I find 40 lines a lot more useful. 106 columns is enough to
> view an assembly language listing file without line wrap. However I
> always use 80 columns because when I write software for CP/M I also do
> my editing on CP/M and constraining the source code to fit into 80
> columns is fairly normal practice.
>
> I am not suggesting that anyone should change his habits but I find it
> very enlightening to learn why people do things in a particular way. It
> is too easy to become blind to perfectly valid reasons.
because of new monitor (and machine...) sooner I'll try how Altairz80
> In the days when people hooked CRT terminals to CP/M computers one had
> to live with the limits of those terminals. Typically, that meant 24 or
> 25 lines of 80 columns.
>
> Nowadays it is probably cheaper and easier to connect an old laptop to a
> real CP/M system or to run CP/M in an emulator. In either case the
> 24x80 limits no longer apply yet I have the impression that most people
> stick with the old screen dimensions. I would be interested in learning
> why.
>
> Personally, I find 40 lines a lot more useful. 106 columns is enough to
> view an assembly language listing file without line wrap. However I
> always use 80 columns because when I write software for CP/M I also do
> my editing on CP/M and constraining the source code to fit into 80
> columns is fairly normal practice.
>
> I am not suggesting that anyone should change his habits but I find it
> very enlightening to learn why people do things in a particular way. It
> is too easy to become blind to perfectly valid reasons.
and z80emu can deal with a 132x33 X terminal as console.....
Best regards from Italy,
dott. Piergiorgio
Jeff Jonas
Aug 18, 2014, 9:21:09 PM8/18/14
to
>> In the days when people hooked CRT terminals to CP/M computers
^^^^^^^^^^^^^^^^^
CP/M has not the dependency.
The limitation was displaying text on CRTs
originally intended for television.
NTSC tubes were 3:4 aspect ratio, interlaced,
with bandwidth limited electronics.
Some terminal makers made their own tubes
but that was out of most hobbyists budget.
>> one had to live with the limits of those terminals.
>> Typically, that meant 24 or 25 lines of 80 columns.
>> In either case the 24x80 limits no longer apply
>> yet I have the impression that most people
>> stick with the old screen dimensions.
>> I would be interested in learning why.
We're accustomed to doing that
so it still works on vintage equipment.
In many cases the user counts as vintage equipment too :-)
2) If the display & printer are fixed width fonts,
printing on USA "A" paper (8.5 x 11 inches) works fine
without line folding.
>> 106 columns is enough to view an assembly language listing file
Particularly if using full 8 space tabs
with a highly indented portion of code.
>because of new monitor (and machine...) sooner I'll try how Altairz80
>and z80emu can deal with a 132x33 X terminal as console.....
standard USA fanfold paper of the 60s to 80s:
132 print positions
by 60-66 lines at 6 lines per inch
(usually skipping an inch for the perforation)
or 80-88 lines at 8 lines per inch (harder to read).
THAT was the huge canvas programmers enjoyed for
programming & printout for the longest time.
Lotsa paper real-estate for pretty formatting.
I don't remember if there was Euro-fanfold of different size
since printers were not yet metric.
I remember the a-ha! moment when I realized that the
width of the teletype was NOT a limitation to program line size.
Logical line length might NOT equal physical line length.
(IBM mainframes adored fixed record lengths as specified by JCL.
It was sad seeing IBMers go "tilt" when trying to grok
that AIX/Unix did not require or enforce record sizes).
Udo Munk
Aug 19, 2014, 3:11:02 AM8/19/14
to
On Tuesday, August 19, 2014 12:44:00 AM UTC+2, Jon Saxton wrote:
...
...
...
If your source won't fit into 80 columns then something is wrong with it,
because billions of lines of existing code fit ;-)
Nowadays of course one can write more into a single line, but the source
is less readable then, so it is just good and proofed practice to stick
with it.
Then four 24x80 terminals fit on a 14" notebook screen, more on larger
ones, because the window ratio matches the screen ratio. I still is a
practical size to work with many terminal windows at the same time.
...
...
> Personally, I find 40 lines a lot more useful. 106 columns is enough to
> view an assembly language listing file without line wrap. However I
> always use 80 columns because when I write software for CP/M I also do
> my editing on CP/M and constraining the source code to fit into 80
> columns is fairly normal practice.
...
> view an assembly language listing file without line wrap. However I
> always use 80 columns because when I write software for CP/M I also do
> my editing on CP/M and constraining the source code to fit into 80
> columns is fairly normal practice.
...
If your source won't fit into 80 columns then something is wrong with it,
because billions of lines of existing code fit ;-)
Nowadays of course one can write more into a single line, but the source
is less readable then, so it is just good and proofed practice to stick
with it.
Then four 24x80 terminals fit on a 14" notebook screen, more on larger
ones, because the window ratio matches the screen ratio. I still is a
practical size to work with many terminal windows at the same time.
Steve Nickolas
Aug 19, 2014, 6:21:05 AM8/19/14
to
Isn't there a lot of pre-X Window software out there that simply assumes
that the terminal is 80x24, and the setting is hardwired?
-uso.
that the terminal is 80x24, and the setting is hardwired?
-uso.
Axel Berger
Aug 19, 2014, 6:06:00 AM8/19/14
to
Jon Saxton wrote on Tue, 14-08-19 00:44:
window?
Axel
>However I always use 80 columns because when I write software for CP/M
>I also do my editing on CP/M
Can't your editor do that for you without resticting the terminal
>I also do my editing on CP/M
window?
Axel
Udo Munk
Aug 19, 2014, 9:00:32 AM8/19/14
to
On Tuesday, August 19, 2014 12:21:05 PM UTC+2, Steve Nickolas wrote:
> Isn't there a lot of pre-X Window software out there that simply assumes
> that the terminal is 80x24, and the setting is hardwired?
No, because terminals like VT100 and others from Wyse and so on had a wide
> Isn't there a lot of pre-X Window software out there that simply assumes
> that the terminal is 80x24, and the setting is hardwired?
mode with a smaller font, which allowed 126x32 - 132x40, something like
that. With the DEC OS's and UNIX you could use it, because editors and
stuff adjusted appropriate, UNIX anyway because of the curses terminal
support. Also I can't remember about CP/M software hardcoded to 80x24,
that all can be configured or patched.
Bill Leary
Aug 19, 2014, 2:45:28 PM8/19/14
to
"Steve Nickolas" wrote in message
news:alpine.DEB.2.02.1408191020010.2606@localhost...
deal of software did assume 80 X 24. Some of it so deeply that there wasn't
anyway, short of a rewrite, to have it do anything else. But as he points
out, if you were clever enough, and/or the vendor was, a lot of it could be
patched to use other sizes. Word processors and spread sheets were the
ones most likely to be able to be patched. Some made it pretty easy, going
so far as to have a setup program where you'd enter screen sizes, cursor and
attribute sequences and so forth. If I'm recalling correctly New Word (the
WP I most used on CP/M) had such a program. I think Turbo Pascal did too.
- Bill
news:alpine.DEB.2.02.1408191020010.2606@localhost...
> Isn't there a lot of pre-X Window software out there
> that simply assumes that the terminal is 80x24, and
> the setting is hardwired?
I see Udo Munk answered with "No." I have to partially disagree. A great
> that simply assumes that the terminal is 80x24, and
> the setting is hardwired?
deal of software did assume 80 X 24. Some of it so deeply that there wasn't
anyway, short of a rewrite, to have it do anything else. But as he points
out, if you were clever enough, and/or the vendor was, a lot of it could be
patched to use other sizes. Word processors and spread sheets were the
ones most likely to be able to be patched. Some made it pretty easy, going
so far as to have a setup program where you'd enter screen sizes, cursor and
attribute sequences and so forth. If I'm recalling correctly New Word (the
WP I most used on CP/M) had such a program. I think Turbo Pascal did too.
- Bill
Udo Munk
Aug 19, 2014, 3:00:17 PM8/19/14
to
On Tuesday, August 19, 2014 8:45:28 PM UTC+2, Bill Leary wrote:
> "Steve Nickolas" wrote in message
> "Steve Nickolas" wrote in message
> I see Udo Munk answered with "No." I have to partially disagree. A great
> deal of software did assume 80 X 24. Some of it so deeply that there wasn't
> anyway, short of a rewrite, to have it do anything else. But as he points
> out, if you were clever enough, and/or the vendor was, a lot of it could be
> patched to use other sizes. Word processors and spread sheets were the
> ones most likely to be able to be patched. Some made it pretty easy, going
> so far as to have a setup program where you'd enter screen sizes, cursor and
> attribute sequences and so forth. If I'm recalling correctly New Word (the
> WP I most used on CP/M) had such a program. I think Turbo Pascal did too.
Well, I cannot remember any program were it was hardcoded this bad, that
> deal of software did assume 80 X 24. Some of it so deeply that there wasn't
> anyway, short of a rewrite, to have it do anything else. But as he points
> out, if you were clever enough, and/or the vendor was, a lot of it could be
> patched to use other sizes. Word processors and spread sheets were the
> ones most likely to be able to be patched. Some made it pretty easy, going
> so far as to have a setup program where you'd enter screen sizes, cursor and
> attribute sequences and so forth. If I'm recalling correctly New Word (the
> WP I most used on CP/M) had such a program. I think Turbo Pascal did too.
only a rewrite would help. Editor, spread sheets and IDEs like Turbo had a
setup program which made it very easy. Other programs had a terminal patch
area in the first page starting at 0100H, and there you usually found 24 and 80
for the terminal size, so that it was easy to patch. And I had several terminals
which did others sizes with smaller fonts and usually I had a second configuration
for that.
But you are right, of course I used only a fraction of the available CP/M software,
so there might have been such programs that can't be configured/patched.
Steven Hirsch
Aug 19, 2014, 3:39:43 PM8/19/14
to
utilities (and some commercial apps!) made use of to determine screen size and
control codes.
I'm almost positive that WordStar 4 was ZCPR3 aware.
Jeff Jonas
Aug 19, 2014, 9:22:03 PM8/19/14
to
>I see Udo Munk answered with "No." I have to partially disagree.
>A great deal of software did assume 80 X 24.
Code portability was not such an issue back then.
>A great deal of software did assume 80 X 24.
Many programs were written for very specific hardware
and software environments.
Many things considered "production code"
was barely beta by today's standards.
- IBM mainframes kept compatibility
to previous models and software (OS/monitors/libraries)
because of the sheer code base that "had to keep running".
- Back in the S100 days, software made MANY assumptions
about the location of hardware, specific chips,
what video card, etc.
Reconfiguration required the source code
and modifying it yourself. Just like Linux :-)
- CP/M Wordstar had a configuration program
for various terminals, printers and such.
- even terminals had firmware to emulate others
because programs were hard-coded with the escape sequences.
I remember Euligio Dhananjaya Garcia's SOUL program
from Exxon/Zilog Office Systems.
The "Software Organizing Universal Librarian".
It drew flowcharts using ASCII graphics.
But it was hard-coded to a specific terminal
that was bundled with the MCZ2 Zilog system (Z80 running RIO).
He had to add a compatibility layer
when a different terminal was sold with the system.
He never anticipated any such changes.
Such programs MIGHT have been hard coded for 24x80
but it bit him in the ass right away.
Egan Ford
Aug 20, 2014, 9:10:32 AM8/20/14
to
On 8/18/14, 4:44 PM, Jon Saxton wrote:
> Personally, I find 40 lines a lot more useful. 106 columns is enough to
> view an assembly language listing file without line wrap. However I
> always use 80 columns because when I write software for CP/M I also do
> my editing on CP/M and constraining the source code to fit into 80
> columns is fairly normal practice.
I read a study sometime back that showed a correlation between software
> Personally, I find 40 lines a lot more useful. 106 columns is enough to
> view an assembly language listing file without line wrap. However I
> always use 80 columns because when I write software for CP/M I also do
> my editing on CP/M and constraining the source code to fit into 80
> columns is fairly normal practice.
bugs and screen size. Larger (more lines visible) reduced errors.
Heresy, I know... But, I do all of my assembly programming in vi and
cross-assemble; test and debug using emulators and simulators. I tend
to set my xterms at around 130 columns and 100 lines.
Jeff Jonas
Aug 20, 2014, 5:47:17 PM8/20/14
to
>I read a study sometime back that showed a correlation between software
>bugs and screen size. Larger (more lines visible) reduced errors.
So I ought to go back to using line printer greenbar?
>bugs and screen size. Larger (more lines visible) reduced errors.
That allows for
- seeing 2 pages at once: 132 column x 60 lines per page
- unraveling the printout all over the conference room table
Old photos show programmers filling tables with printouts,
working together for debugging. Team debugging, code review.
What a concept.
boboro...@gmail.com
Aug 21, 2014, 6:20:39 AM8/21/14
to
Op dinsdag 19 augustus 2014 00:44:00 UTC+2 schreef Jon Saxton:
Hallo,
I think it has a lot to do with what you are used to.
I am programming Arduino's and LaunchPads in C++.
The output go's to TeraTerm. Using VT100.
Without thinking about it I used 40 x 25.
So today I tried different screen sizes.
Ahhhhhhhhhhhh, horrible.
I guess I am so used to 40 x 25 an 80 x 25 that any other size just give me the chills.
I know, I am a conservative old man. But I am happy with 40 x 25 an 80 x 25.
I love the Russian approach. If it is not broken, leave it alone.
Greetings,
Henk Siewert
I think it has a lot to do with what you are used to.
I am programming Arduino's and LaunchPads in C++.
The output go's to TeraTerm. Using VT100.
Without thinking about it I used 40 x 25.
So today I tried different screen sizes.
Ahhhhhhhhhhhh, horrible.
I guess I am so used to 40 x 25 an 80 x 25 that any other size just give me the chills.
I know, I am a conservative old man. But I am happy with 40 x 25 an 80 x 25.
I love the Russian approach. If it is not broken, leave it alone.
Greetings,
Henk Siewert
Egan Ford
Aug 21, 2014, 2:30:53 PM8/21/14
to
On 8/20/14, 3:47 PM, Jeff Jonas wrote:
> So I ought to go back to using line printer greenbar?
> That allows for
> - seeing 2 pages at once: 132 column x 60 lines per page
> - unraveling the printout all over the conference room table
I used to do the same when I could only fit 24 lines on a screen. Now
> So I ought to go back to using line printer greenbar?
> That allows for
> - seeing 2 pages at once: 132 column x 60 lines per page
> - unraveling the printout all over the conference room table
that I can fit 100+, it's not necessary. Editors are also a lot faster
and tools like tkdiff allow me to look at 100s of lines side-by-side.
That all said, if I had a green bar printer I'd probably still use it
from time to time to look at code or just hang it on my door. Printing
code out on 8.5x11 paper with crisp looking fonts just isn't the same.
I am still looking for a cheap 132 column pin-feed printer.
Udo Munk
Aug 21, 2014, 2:45:25 PM8/21/14
to
which were able to display a xterm of any size. Nowadays of course I
do all work at the machines, I don't own any kind of printer anymore.
With a notebook more powerful than a mainframe from the 70's there
simply is no reason anymore to print out sources, when one can look
at anything in an instant. But I still use 24x80 terminals, lots of them.
glen herrmannsfeldt
Aug 21, 2014, 3:32:57 PM8/21/14
to
Egan Ford <data...@gmail.com> wrote:
(snip)
> That all said, if I had a green bar printer I'd probably still use it
> from time to time to look at code or just hang it on my door. Printing
> code out on 8.5x11 paper with crisp looking fonts just isn't the same.
> I am still looking for a cheap 132 column pin-feed printer.
I still have the MX-100 I bought not long after it came out.
The MX-80 was more popular, which is 80 characters (0.1 in pitch),
but I wanted the wider one. It runs either pin feed, or friction
feed (for single sheet). I don't have a ribbon for it, though,
as I suspect the old one has dried out by now.
-- glen
(snip)
> That all said, if I had a green bar printer I'd probably still use it
> from time to time to look at code or just hang it on my door. Printing
> code out on 8.5x11 paper with crisp looking fonts just isn't the same.
> I am still looking for a cheap 132 column pin-feed printer.
The MX-80 was more popular, which is 80 characters (0.1 in pitch),
but I wanted the wider one. It runs either pin feed, or friction
feed (for single sheet). I don't have a ribbon for it, though,
as I suspect the old one has dried out by now.
-- glen
Jon Saxton
Aug 22, 2014, 9:32:51 PM8/22/14
to
columns I give up the immediate visual impact. If I need to look at an
assembly language listing then I just export it to the linux host and
use a wider window.
Jon Saxton
Aug 23, 2014, 12:57:43 AM8/23/14
to
suspect that the law of diminishing returns exerts some sort of effect
as the visual field increases. At the moment I am doing some Z80
assembly language programming and I am feeling the need to increase my
editor window size from 40 to 50 lines. However I cannot see that going
to 80 or 100 lines would be any more useful. You obviously do. Maybe
if I were to edit on linux rather than CP/M I might change my view but I
need to have the font large enough to pander to my old eyes.
I use Z8E for debugging and in "full screen" mode about 6 lines are used
for purposes other than displaying the code. On a 24-line screen that
leaves 18 lines for code and that seems too little. 40 lines is
certainly a lot better and once again I am thinking of going to 50.
In my working life I spent a lot of time coding in C++. I don't
remember how many lines of code would have been in my editor window but
it was certainly more than 25. Whether or not helped me write better
code, I cannot say but it was definitely easier with more lines.
dottor Piergiorgio M. d' Errico
Aug 23, 2014, 7:58:52 AM8/23/14
to
Il 23/08/2014 06:57, Jon Saxton ha scritto:
> Thanks for that observation. It is certainly an interesting idea but I
> suspect that the law of diminishing returns exerts some sort of effect
> as the visual field increases. At the moment I am doing some Z80
> assembly language programming and I am feeling the need to increase my
> editor window size from 40 to 50 lines. However I cannot see that going
> to 80 or 100 lines would be any more useful. You obviously do. Maybe
> if I were to edit on linux rather than CP/M I might change my view but I
> need to have the font large enough to pander to my old eyes.
>
> I use Z8E for debugging and in "full screen" mode about 6 lines are used
> for purposes other than displaying the code. On a 24-line screen that
> leaves 18 lines for code and that seems too little. 40 lines is
> certainly a lot better and once again I am thinking of going to 50.
>
> In my working life I spent a lot of time coding in C++. I don't
> remember how many lines of code would have been in my editor window but
> it was certainly more than 25. Whether or not helped me write better
> code, I cannot say but it was definitely easier with more lines.
looking on smaller screens (and software with hardcoded term
> Thanks for that observation. It is certainly an interesting idea but I
> suspect that the law of diminishing returns exerts some sort of effect
> as the visual field increases. At the moment I am doing some Z80
> assembly language programming and I am feeling the need to increase my
> editor window size from 40 to 50 lines. However I cannot see that going
> to 80 or 100 lines would be any more useful. You obviously do. Maybe
> if I were to edit on linux rather than CP/M I might change my view but I
> need to have the font large enough to pander to my old eyes.
>
> I use Z8E for debugging and in "full screen" mode about 6 lines are used
> for purposes other than displaying the code. On a 24-line screen that
> leaves 18 lines for code and that seems too little. 40 lines is
> certainly a lot better and once again I am thinking of going to 50.
>
> In my working life I spent a lot of time coding in C++. I don't
> remember how many lines of code would have been in my editor window but
> it was certainly more than 25. Whether or not helped me write better
> code, I cannot say but it was definitely easier with more lines.
commands...), I think that a curses interface can be implemented on both
altairz80 and z80emu, followed of course by implementation of those
small-screen terminals, and even the earlier character based S-100 video
cards; my estimate is that everything can be implemented with curses
minus the extended charset of some early S-100 chr-based video cards.
Best regards from Italy,
dott. Piergiorgio.
Steven Hirsch
Aug 23, 2014, 8:36:24 AM8/23/14
to
On 08/23/2014 07:58 AM, dottor Piergiorgio M. d' Errico wrote:
> looking on smaller screens (and software with hardcoded term commands...), I
> think that a curses interface can be implemented on both altairz80 and z80emu,
> followed of course by implementation of those small-screen terminals, and even
> the earlier character based S-100 video cards; my estimate is that everything
> can be implemented with curses minus the extended charset of some early S-100
> chr-based video cards.
Before re-inventing the wheel, take a look at ZCPR3's tcap and the
> looking on smaller screens (and software with hardcoded term commands...), I
> think that a curses interface can be implemented on both altairz80 and z80emu,
> followed of course by implementation of those small-screen terminals, and even
> the earlier character based S-100 video cards; my estimate is that everything
> can be implemented with curses minus the extended charset of some early S-100
> chr-based video cards.
corresponding z3lib support for same.
Udo Munk
Aug 23, 2014, 9:06:07 AM8/23/14
to
On Saturday, August 23, 2014 1:58:52 PM UTC+2, dottor Piergiorgio M. d' Errico wrote:
> looking on smaller screens (and software with hardcoded term
> commands...), I think that a curses interface can be implemented on both
> altairz80 and z80emu, followed of course by implementation of those
> small-screen terminals, and even the earlier character based S-100 video
> cards; my estimate is that everything can be implemented with curses
> minus the extended charset of some early S-100 chr-based video cards.
There have been termcap and mini-curses implementations for CP/M. Motivation
> looking on smaller screens (and software with hardcoded term
> commands...), I think that a curses interface can be implemented on both
> altairz80 and z80emu, followed of course by implementation of those
> small-screen terminals, and even the earlier character based S-100 video
> cards; my estimate is that everything can be implemented with curses
> minus the extended charset of some early S-100 chr-based video cards.
of course were the UNIX termcap based games we wanted to run on CP/M ;-)
Also the vi clone elvis from Steve Kirkendall once started life on a
CP/M system. I used to work with Steve on that in the early 90th, because
at this time it was the only serious vi alternative for the upcoming UNIX
clones like Minix, 386BSD, Coherent and Linux. Unfortunately Steve haven't
had sources anymore that would build under CP/M at that time, because the
editor got all the UNIX features and more, so it got too large.
Z-Systems like nzcom still include a termcap library, the usual terminal
definitions and programs making use of it.
Implementing alternate characters sets was easy, I did that way back then
for pd-curses, to be able to draw menus with the line drawing alternate
characters. That would still fit into a CP/M implementation, the color
support probably not.
dottor Piergiorgio M. d' Errico
Aug 23, 2014, 9:45:28 AM8/23/14
to
seems that I failed in conveying my thought... I wasn't suggesting of
implementing termcap and/or curses for CP/M, but I was suggesting a mean
for emulating machines and/or cards with smaller than 80x24 screen area.
e.g. 64x16 or 40x20. Because there's a little, if no, need of graphics
emulation, a (n)curses window should suffice for emulating, say, the
52x24 screen of the Osborne 1...
Hope that is now clear, and
Udo Munk
Aug 23, 2014, 10:05:06 AM8/23/14
to
On Saturday, August 23, 2014 3:45:28 PM UTC+2, dottor Piergiorgio M. d' Errico wrote:
> seems that I failed in conveying my thought... I wasn't suggesting of
> implementing termcap and/or curses for CP/M, but I was suggesting a mean
> for emulating machines and/or cards with smaller than 80x24 screen area.
> e.g. 64x16 or 40x20. Because there's a little, if no, need of graphics
> emulation, a (n)curses window should suffice for emulating, say, the
> 52x24 screen of the Osborne 1...
For this there is not much to emulate, because you can size the terminal
> seems that I failed in conveying my thought... I wasn't suggesting of
> implementing termcap and/or curses for CP/M, but I was suggesting a mean
> for emulating machines and/or cards with smaller than 80x24 screen area.
> e.g. 64x16 or 40x20. Because there's a little, if no, need of graphics
> emulation, a (n)curses window should suffice for emulating, say, the
> 52x24 screen of the Osborne 1...
windows on nowadays GUIs to anything you like. Of course you have to
patch all CP/M software then for this different screen size if you
don't have original Osborn software e.g.
And for emulation of the ESC sequences a small curses program that
translates them to curses functions doing the stuff on the GUI terminal
would be trivial to implement.
Alexandre MONTARON
Mar 29, 2015, 9:43:16 AM3/29/15
to
Le 19/08/2014 00:44, Jon Saxton a écrit :
> In the days when people hooked CRT terminals to CP/M computers one had
> to live with the limits of those terminals. Typically, that meant 24 or
> 25 lines of 80 columns.
>
> Nowadays it is probably cheaper and easier to connect an old laptop to a
> real CP/M system or to run CP/M in an emulator. In either case the
> 24x80 limits no longer apply yet I have the impression that most people
> stick with the old screen dimensions. I would be interested in learning
> why.
>
> Personally, I find 40 lines a lot more useful. 106 columns is enough to
> view an assembly language listing file without line wrap. However I
> always use 80 columns because when I write software for CP/M I also do
> my editing on CP/M and constraining the source code to fit into 80
> columns is fairly normal practice.
>
> I am not suggesting that anyone should change his habits but I find it
> very enlightening to learn why people do things in a particular way. It
> is too easy to become blind to perfectly valid reasons.
Hi !
> In the days when people hooked CRT terminals to CP/M computers one had
> to live with the limits of those terminals. Typically, that meant 24 or
> 25 lines of 80 columns.
>
> Nowadays it is probably cheaper and easier to connect an old laptop to a
> real CP/M system or to run CP/M in an emulator. In either case the
> 24x80 limits no longer apply yet I have the impression that most people
> stick with the old screen dimensions. I would be interested in learning
> why.
>
> Personally, I find 40 lines a lot more useful. 106 columns is enough to
> view an assembly language listing file without line wrap. However I
> always use 80 columns because when I write software for CP/M I also do
> my editing on CP/M and constraining the source code to fit into 80
> columns is fairly normal practice.
>
> I am not suggesting that anyone should change his habits but I find it
> very enlightening to learn why people do things in a particular way. It
> is too easy to become blind to perfectly valid reasons.
Like you (I mean everyones in this thread) I used to have differents
24 or 25x80 terminals (was fine in columns but too few lines however).
Since many years, I use 43 or 44x132 with Linux.
But by now, as I'm doing some CP/M again... I effectively notice lots of
software were still made for old standard 24x80 (even prefered to 25x80).
So, I've done a little RSX for CP/M+ which fake Bdos #49 height and
width console size. It's here: http://canal.chez.com/CPM/vt100dyn.htm
(Don't know if it has already be done even on ZCPR3 ??)
The first idea is to use CP/M with larger screen than standard 24x80
without the need of manually entering height and width parameters.
But the second idea is to use it with variable size xterm windows.
Example: I open my xterm in 24x80 but some times after I resize it to
say 50x100 but that could be 49x101 ...
The role of the RSX is to inform A>DEVICE CONSOLE [page] that height and
width have changed ... Of course, it works in the other way and when a
CP/M+ utility ask for Bdos #49 it gets real size of your xterm (this
also works with Linux Console of differents size or windows 8 telnet for
examples) instead of manually entered (or defaults 24x80) height and width.
Also, it works with my patch for WordMaster (which use Bdos #49).
That way, you can use WordMaster, resize xterm (larger or smaller) and
use WordMaster again with dynamical and accurates new sizes.
I forgot to say it works only with compliant VT100 terminals (as Linux
do) but everything is explain (with samples) and download link for
VT100DYN.ZIP ...
Alex. - http://canal.chez.com/CPM/vt100dyn.htm
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com
Alexandre MONTARON
Mar 29, 2015, 4:05:56 PM3/29/15
to
Le 29/03/2015 15:43, Alexandre MONTARON a écrit :
> So, I've done a little RSX for CP/M+ which fake Bdos #49 height and
> width console size. It's here: http://canal.chez.com/CPM/vt100dyn.htm
Sorry, you should reget it as it had 2 big bugs in it ! Now fixed.
> So, I've done a little RSX for CP/M+ which fake Bdos #49 height and
> width console size. It's here: http://canal.chez.com/CPM/vt100dyn.htm
Alexandre MONTARON
Apr 5, 2015, 10:08:18 AM4/5/15
to
Sadly,
- CP/M+ hist rsx is stuck to 24 lines (said 23 in source - can be
modified then recompiled of course).
- z80asm is stuck to 24 lines also - try more than 24 compiling errors
and you'll see !
- MP/M II built-in TYPE command is 24 line by default (can be recompiled
with source I suppose but manually must do: TYPE xxxx.mac [p50] for 50
lines instead of 24). No SCB in MP/M !
- WordMaster was preconfigured for 24x80 and can't do more than 99
columns before I change it for myself for 132 columns :
http://canal.chez.com/CPM/wm3.htm
- MultiPlan preconfigured DEC VT100 terminal definition is stuck to
24x80 and you can't fake it. Eventually, you can patch 25x80 or less
than 24 lines in MP.COM but that's all. For greater screen (big xterm)
you have to make a new terminal installation from scratch.
http://canal.chez.com/CPM/mp-vt100.htm
In fact, who in 2015 is using CP/M-80 with more than 24x80 (or 25x80).
Except for 90x32 PCW native softwares...
Of course MBASIC, M80, L80, DDT, ZSID... don't care of that and WM do
complies with what I want. But...
I think very few people really do that... WordStar 3 seems to be limited
to 120 lines (which is still good for nowadays) and MultiPlan explode
few after 70x180...
I've done some work and RSX to help do all that. Now, I can run WM in a
xterm much like I run vi or emacs under Linux... It use the full screen
window I have opened. http://canal.chez.com/CPM/vt100dyn.htm
Alex. - http://canal.chez.com/CPM/mp-vt100.htm (My colored VT100
terminal definition for Microsoft MultiPlan that can do more than 24x80)
- CP/M+ hist rsx is stuck to 24 lines (said 23 in source - can be
modified then recompiled of course).
- z80asm is stuck to 24 lines also - try more than 24 compiling errors
and you'll see !
- MP/M II built-in TYPE command is 24 line by default (can be recompiled
with source I suppose but manually must do: TYPE xxxx.mac [p50] for 50
lines instead of 24). No SCB in MP/M !
- WordMaster was preconfigured for 24x80 and can't do more than 99
columns before I change it for myself for 132 columns :
http://canal.chez.com/CPM/wm3.htm
- MultiPlan preconfigured DEC VT100 terminal definition is stuck to
24x80 and you can't fake it. Eventually, you can patch 25x80 or less
than 24 lines in MP.COM but that's all. For greater screen (big xterm)
you have to make a new terminal installation from scratch.
http://canal.chez.com/CPM/mp-vt100.htm
In fact, who in 2015 is using CP/M-80 with more than 24x80 (or 25x80).
Except for 90x32 PCW native softwares...
Of course MBASIC, M80, L80, DDT, ZSID... don't care of that and WM do
complies with what I want. But...
I think very few people really do that... WordStar 3 seems to be limited
to 120 lines (which is still good for nowadays) and MultiPlan explode
few after 70x180...
I've done some work and RSX to help do all that. Now, I can run WM in a
xterm much like I run vi or emacs under Linux... It use the full screen
window I have opened. http://canal.chez.com/CPM/vt100dyn.htm
Alex. - http://canal.chez.com/CPM/mp-vt100.htm (My colored VT100
terminal definition for Microsoft MultiPlan that can do more than 24x80)
Udo Munk
Apr 5, 2015, 12:34:40 PM4/5/15
to
On Sunday, April 5, 2015 at 4:08:18 PM UTC+2, Alexandre MONTARON wrote:
...
...
parameters, the structure is described in the manuals. It doesn't have
bytes reserved for terminal dimensions though. However, there are
a few sections reserved for MP/M. Probably not every byte in the reserved
areas is used, as usual. The feature could be added without rewriting
everything. So use the MP/M 2 sources and build MP/M 2Plus ;-)
...
cells than could be filled with something and the more cells you want
to display, the more memory is needed for their contents. So you need
to keep it within the max size of a sheet, else it will run out of memory
and abort, or just explode.
...
...
> - MP/M II built-in TYPE command is 24 line by default (can be recompiled
> with source I suppose but manually must do: TYPE xxxx.mac [p50] for 50
> lines instead of 24). No SCB in MP/M !
MP/M has a System Data Page that includes static as well as dynamic
> with source I suppose but manually must do: TYPE xxxx.mac [p50] for 50
> lines instead of 24). No SCB in MP/M !
parameters, the structure is described in the manuals. It doesn't have
bytes reserved for terminal dimensions though. However, there are
a few sections reserved for MP/M. Probably not every byte in the reserved
areas is used, as usual. The feature could be added without rewriting
everything. So use the MP/M 2 sources and build MP/M 2Plus ;-)
...
...
> I think very few people really do that... WordStar 3 seems to be limited
> to 120 lines (which is still good for nowadays) and MultiPlan explode
> few after 70x180...
The spreadsheets are a bit special. There is no point in displaying more
> I think very few people really do that... WordStar 3 seems to be limited
> to 120 lines (which is still good for nowadays) and MultiPlan explode
> few after 70x180...
cells than could be filled with something and the more cells you want
to display, the more memory is needed for their contents. So you need
to keep it within the max size of a sheet, else it will run out of memory
and abort, or just explode.
Alexandre MONTARON
Apr 9, 2015, 9:29:15 AM4/9/15
to
Le 05/04/2015 18:34, Udo Munk a écrit :
> MP/M has a System Data Page that includes static as well as dynamic
> parameters, the structure is described in the manuals. It doesn't have
> bytes reserved for terminal dimensions though. However, there are
> a few sections reserved for MP/M. Probably not every byte in the reserved
> areas is used, as usual. The feature could be added without rewriting
> everything. So use the MP/M 2 sources and build MP/M 2Plus;-)
Yes, there is also some little things we could add to MP/M like better
> MP/M has a System Data Page that includes static as well as dynamic
> parameters, the structure is described in the manuals. It doesn't have
> bytes reserved for terminal dimensions though. However, there are
> a few sections reserved for MP/M. Probably not every byte in the reserved
> areas is used, as usual. The feature could be added without rewriting
> everything. So use the MP/M 2 sources and build MP/M 2Plus;-)
CLI/TMP (CCP): editing keys, history (^W,^V) ...etc... And height/width
screen size also.
> ...
>> >I think very few people really do that... WordStar 3 seems to be limited
>> >to 120 lines (which is still good for nowadays) and MultiPlan explode
>> >few after 70x180...
> The spreadsheets are a bit special. There is no point in displaying more
> cells than could be filled with something and the more cells you want
> to display, the more memory is needed for their contents. So you need
> to keep it within the max size of a sheet, else it will run out of memory
> and abort, or just explode.
a variable-size xterm or putty : http://canal.chez.com/CPM/mp2vt100.htm
For a lose of only 4KB of TPA (not my patch which take nothing, but 4KB
of Multiplan allocated virtual screen memory) you can run up to 80x80
(80 lines of 80 columns) whatever your sized xterm is.
Example: when running MP.COM in a 24x80 with my patch, you get a normal
24x80 Multiplan screen despite 80 lines was specified at install-time.
But when you run at 80x80 or 80x132 you'll get a large 80x80 (xterm is
then resized by my patch to 80 columns) ...
You can also run it at 50x80 in a fixed Linux Console for example...
All this with only one (patched) MP.COM
Also, my DEC VT-100 description terminal as against standard Multiplan
install.dat has four colors.
And ZCPR3 even if it has fixed height and fixe width size of your screen
was not able to handle a variable-size screen like xterm or putty
(exactly as what we do with Linux when resizing an xterm a lot).
Udo Munk
Apr 9, 2015, 10:09:37 AM4/9/15
to
On Thursday, April 9, 2015 at 3:29:15 PM UTC+2, Alexandre MONTARON wrote:
> Le 05/04/2015 18:34, Udo Munk a écrit :
> > MP/M has a System Data Page that includes static as well as dynamic
> > parameters, the structure is described in the manuals. It doesn't have
> > bytes reserved for terminal dimensions though. However, there are
> > a few sections reserved for MP/M. Probably not every byte in the reserved
> > areas is used, as usual. The feature could be added without rewriting
> > everything. So use the MP/M 2 sources and build MP/M 2Plus;-)
>
> Yes, there is also some little things we could add to MP/M like better
> CLI/TMP (CCP): editing keys, history (^W,^V) ...etc... And height/width
> screen size also.
Can all be done, no problem. In the MP/M 2 sources for z80pack I made
> Le 05/04/2015 18:34, Udo Munk a écrit :
> > MP/M has a System Data Page that includes static as well as dynamic
> > parameters, the structure is described in the manuals. It doesn't have
> > bytes reserved for terminal dimensions though. However, there are
> > a few sections reserved for MP/M. Probably not every byte in the reserved
> > areas is used, as usual. The feature could be added without rewriting
> > everything. So use the MP/M 2 sources and build MP/M 2Plus;-)
>
> Yes, there is also some little things we could add to MP/M like better
> CLI/TMP (CCP): editing keys, history (^W,^V) ...etc... And height/width
> screen size also.
some small changes anyway, to fix Y2K problems and I made BS and DEL
doing the same. The idea behind the source disks for z80pack was to
improve the OS's, which I might do sometime, or maybe not, because
there are thousands of very interesting things one could do with
the old stuff.
> I've done a little patch to run Multiplan spreadsheets (for CP/M-80) in
...
Nice work, there are many ways to improve the old bits and I
always like to see what people are doing with it.
Alexandre MONTARON
Apr 19, 2015, 5:07:01 AM4/19/15
to
[CP/M-80]
Again another VT100 patch for Word-Star now (just after Word-Master
editor and Multiplan spreadsheet).
It's here (but probably not the final version) :
http://canal.chez.com/CPM/ws3.htm (This is Draft Only for the moment)
Again this patch for Word-Star let you use a larger screen than 24x80
and rely on CP/M+ Bdos #49 device console [page] ...
Also, this VT100 patch features a 5 colors install.
But I very doubt lots of people already do that with CP/M nowadays even
if running CP/M in a xterm could normally use for example a 70x160 (70
lines of 160 columns).
This works very well with Word-Master 1.07A and Multiplan fit perfectly
in larger screen especially with nice 3 or 4 colors install.
But Word-Star seems to be limited to 120 lines (WM is not limited) and
worst after 48 or around 60 lines you get a warning message about
(perhaps buggy) big screen behaviors...
Also, WS don't work with smaller screen than 16x64 ... so 40 columns
mode are prohibed !
Alex. - http://canal.chez.com/CPM/ (for CP/M-80 others VT100 patches)
Le 19/08/2014 00:44, Jon Saxton a écrit :
> In the days when people hooked CRT terminals to CP/M computers one had
> to live with the limits of those terminals. Typically, that meant 24 or
> 25 lines of 80 columns.
>
> Nowadays it is probably cheaper and easier to connect an old laptop to a
> real CP/M system or to run CP/M in an emulator. In either case the
> 24x80 limits no longer apply yet I have the impression that most people
> stick with the old screen dimensions. I would be interested in learning
> why.
>
> Personally, I find 40 lines a lot more useful. 106 columns is enough to
> view an assembly language listing file without line wrap. However I
> always use 80 columns because when I write software for CP/M I also do
> my editing on CP/M and constraining the source code to fit into 80
> columns is fairly normal practice.
>
> I am not suggesting that anyone should change his habits but I find it
> very enlightening to learn why people do things in a particular way. It
> is too easy to become blind to perfectly valid reasons.
Again another VT100 patch for Word-Star now (just after Word-Master
editor and Multiplan spreadsheet).
It's here (but probably not the final version) :
http://canal.chez.com/CPM/ws3.htm (This is Draft Only for the moment)
Again this patch for Word-Star let you use a larger screen than 24x80
and rely on CP/M+ Bdos #49 device console [page] ...
Also, this VT100 patch features a 5 colors install.
But I very doubt lots of people already do that with CP/M nowadays even
if running CP/M in a xterm could normally use for example a 70x160 (70
lines of 160 columns).
This works very well with Word-Master 1.07A and Multiplan fit perfectly
in larger screen especially with nice 3 or 4 colors install.
But Word-Star seems to be limited to 120 lines (WM is not limited) and
worst after 48 or around 60 lines you get a warning message about
(perhaps buggy) big screen behaviors...
Also, WS don't work with smaller screen than 16x64 ... so 40 columns
mode are prohibed !
Alex. - http://canal.chez.com/CPM/ (for CP/M-80 others VT100 patches)
Le 19/08/2014 00:44, Jon Saxton a écrit :
> In the days when people hooked CRT terminals to CP/M computers one had
> to live with the limits of those terminals. Typically, that meant 24 or
> 25 lines of 80 columns.
>
> Nowadays it is probably cheaper and easier to connect an old laptop to a
> real CP/M system or to run CP/M in an emulator. In either case the
> 24x80 limits no longer apply yet I have the impression that most people
> stick with the old screen dimensions. I would be interested in learning
> why.
>
> Personally, I find 40 lines a lot more useful. 106 columns is enough to
> view an assembly language listing file without line wrap. However I
> always use 80 columns because when I write software for CP/M I also do
> my editing on CP/M and constraining the source code to fit into 80
> columns is fairly normal practice.
>
> I am not suggesting that anyone should change his habits but I find it
> very enlightening to learn why people do things in a particular way. It
> is too easy to become blind to perfectly valid reasons.
Roger Ivie
Apr 20, 2015, 9:16:58 AM4/20/15
to
On 2015-04-19, Alexandre MONTARON <amonta...@wanadoo.fr> wrote:
> Also, WS don't work with smaller screen than 16x64 ... so 40 columns
> mode are prohibed !
Find an Epson PX-8 Geneva and suck Portable WordStar out of its ROMs.
> Also, WS don't work with smaller screen than 16x64 ... so 40 columns
> mode are prohibed !
IIRC (it's been a long time since I fiddled with it) it could handle
such displays. The PX-8's display was 80 columns by 8 lines.
The patch area for Portable WordStar is similar to WS3.0, but AFAIK
undocumented.
--
roger ivie
roger...@gmail.com
Alexandre MONTARON
Apr 24, 2015, 5:08:30 AM4/24/15
to
status line on top and last for editing current file on a normal screen
(24x80 or more).
8 lines is what I got on my Z88 (Z80 inside but not running CP/M
however). Around 80 columns but can't remember exactly how many ? 72 ?
And there was an editor also on this tiny screen... with shortcuts
marked on the device itself :-D
However, my patch for WS3.3 is now over (reliable) in its first version:
http://canal.chez.com/CPM/ws3.htm (VT100 up to 5 colors)
Also, I discover that WS allocate screen memory much like M$ Multiplan
do and then you can't go to the maximum 120x250 limit (120 lines of 250
caracters) because of memory overflow... as you can, possibly, do with WM.
Alex. - http://canal.chez.com/CPM/ (WM/Multiplan/WS with more than 24x80)
Alexandre MONTARON
May 20, 2015, 4:28:23 AM5/20/15
to
Le 19/04/2015 11:06, Alexandre MONTARON a écrit :
> [CP/M-80]
>
> Again another VT100 patch for Word-Star now (just after Word-Master
> editor and Multiplan spreadsheet).
>
> It's here (but probably not the final version) :
> http://canal.chez.com/CPM/ws3.htm (This is Draft Only for the moment)
>
> Again this patch for Word-Star let you use a larger screen than 24x80
> and rely on CP/M+ Bdos #49 device console [page] ...
>
> Also, this VT100 patch features a 5 colors install.
The version here ( http://canal.chez.com/CPM/ws3.htm ) is now stable ...
> [CP/M-80]
>
> Again another VT100 patch for Word-Star now (just after Word-Master
> editor and Multiplan spreadsheet).
>
> It's here (but probably not the final version) :
> http://canal.chez.com/CPM/ws3.htm (This is Draft Only for the moment)
>
> Again this patch for Word-Star let you use a larger screen than 24x80
> and rely on CP/M+ Bdos #49 device console [page] ...
>
> Also, this VT100 patch features a 5 colors install.
Just overlap a 16 bytes area called "CNVTBL" ... seems to works despite
of that. No documentation about that CNVTBL however.
Alex.
PS: Also works with TurboDOS 1.22P
j...@mdfs.net
Jun 5, 2015, 12:46:46 PM6/5/15
to
I grew up with 80 columns x 32 lines, 24 lines seems really small to me,
I only used 80x25 when memory was really restricted.
I just had to check what my current screen setting is in text mode, it's
112 x 44. Dropping back to 80x32 seems really small now unless I actually
boot up into it.
jgh
I only used 80x25 when memory was really restricted.
I just had to check what my current screen setting is in text mode, it's
112 x 44. Dropping back to 80x32 seems really small now unless I actually
boot up into it.
jgh
0 new messages