Internet Browser for CP/M
76703...@compuserve.com
I'd like to surf the net using my CP/M computer.
Are there internet tools and especially a web
browser for CP/M? I have Epson QX-10 and
QX-16 running CP/M 2.2
Thanks,
Chris
Lindsay Haisley
In article <4o70rn$1...@arl-news-svc-3.compuserve.com>,
76703...@compuserve.com says...
Since, to the best of my knowledge, no one has written a SLIP or PPP protocol
stack for CP/M, even for modeming, it would be difficult to write utilities
such as a web browser for it. There are, however, a number of good terminal
programs for CP/M which will allow you to connect to an ISP running Unix and
interact with the Unix OS there using a "shell account". Many ISPs that
provide shell accounts also have a web browser called lynx available which is a
fairly able web browser, albeit strictly a text-mode tool (as is CP/M in most
cases). Sorry, no graphics!
--
Lindsay Haisley (______)
FMP Computer Services (oo) "The bull
fmo...@fmp.com /------\/ stops here!"
Austin, Texas, USA / | ||
512-259-1190 * ||---|| * * * * * *
~~ ~~ http://www.fmp.com
Alastair S. Preston
> >Are there internet tools and especially a web
> >browser for CP/M? I have Epson QX-10 and
> Since, to the best of my knowledge, no one has written a SLIP or PPP protocol
> stack for CP/M, even for modeming, it would be difficult to write utilities
> such as a web browser for it. There are, however, a number of good terminal
> programs for CP/M which will allow you to connect to an ISP running Unix and
> interact with the Unix OS there using a "shell account". Many ISPs that
> provide shell accounts also have a web browser called lynx available which is a
> fairly able web browser, albeit strictly a text-mode tool (as is CP/M in most
> cases). Sorry, no graphics!
One caveat on Lynx - which I'm using right now in the manner you suggest -
it expects your system to emulate a VT100 terminal. You'll need a terminal
program that can handle that. I haven't tried connecting with my CP/M
system (due to lack of an extrenal modem), but it does ADM3 emulation, and
I'm not sure it could do the VT100 emulation properly even if I had a term
program that did. Other CP/M machines may be in a similar position.
Richard Slobod
<76703...@compuserve.com> wrote:
>I'd like to surf the net using my CP/M computer.
>Are there internet tools and especially a web
>browser for CP/M? I have Epson QX-10 and
>QX-16 running CP/M 2.2
If you can find a local ISP that provides shell accounts, you can make
do with just a comm program.
bill_h
In order to 'surf the net' you're gonna need MEMORY MAPPED VIDEO.
The only really significant difference between cp/m and the ms/pc-dos
world is in the approach to doing video - cp/m was designed to use
teletype (character oriented) displays. There were displays with
limited memory map capability - the VT100 for example - but cp/m
didn't have any built-in functions for keeping track of the cursor
position. That's why you'd have to run a 'terminal emulation' program
of some sort.
since the 'web' is clearly a graphically enriched environment, and
even embedded sound, you're gonna miss a lot surfing with a teletype.
And while you can handle text with that VT100, it's NOT gonna handle
the sort of graphics found everywhere these days.....it only has a few
crude block shapes and simple attributes. There's simply no way do
display things like .jpg's and .gif's.
If you're using netscape, take a look in the \netscape\cache directory
(I use a dos-based viewer...NV) to look at the graphical remnants that
pile up during a session.....
Richard Steven Walz
In article <4o7t20$3...@outer.net>, Lindsay Haisley <fmo...@fmp.com> wrote:
>In article <4o70rn$1...@arl-news-svc-3.compuserve.com>,
>76703...@compuserve.com says...
>>
>>
>>Are there internet tools and especially a web
>>browser for CP/M? I have Epson QX-10 and
>>QX-16 running CP/M 2.2
>
>stack for CP/M, even for modeming, it would be difficult to write utilities
>such as a web browser for it. There are, however, a number of good terminal
>programs for CP/M which will allow you to connect to an ISP running Unix and
>interact with the Unix OS there using a "shell account". Many ISPs that
>provide shell accounts also have a web browser called lynx available which is a
>fairly able web browser, albeit strictly a text-mode tool (as is CP/M in most
>cases). Sorry, no graphics!
>Lindsay Haisley (______)
>FMP Computer Services (oo) "The bull
>fmo...@fmp.com /------\/ stops here!"
>Austin, Texas, USA / | ||
>512-259-1190 * ||---|| * * * * * *
I still use my XT machine and my Ampro LB Z-80A 64K to do just that!
Lynx works just as well if I can engage an ansi-like emulation. Even
VT-100 or Televideo-like is acceptible. All I have ever used at home
to use the Net or Web is the text-based browser lynx for UNIX on my
ISP host machine.
-Steve
--
-Steve Walz rst...@armory.com ftp://ftp.armory.com/pub/user/rstevew
mirrored: ftp://ieee.cas.uc.edu/pub/electronics/faqs/ftp.armory.com
and Europe: ftp://ftp.cised.unina.it/pub/electronics/ftp.armory.com
and Oz: ftp://ftp.peninsula.apana.org.au/pub/electronics/ftp.armory.com
Allison Parent
fmo...@fmp.com (Lindsay Haisley) wrote:
>Since, to the best of my knowledge, no one has written a SLIP or PPP protocol
>stack for CP/M, even for modeming, it would be difficult to write utilities
>such as a web browser for it. There are, however, a number of good terminal
Actually not quite true. There are many cpm suchas uudecode/encode
and the amature radio operators have used IP and X.25 stacks for years
so the basic code exists. A SLPP driver is possible if not already
around.
The vt100 requirement is easy too as it too would be another driver to
push the specific terminal on hand to what ever level of emulation
possible.
Graphics, theis is more difficult as few terminals can, Vt125 being
one I own that can. Many memory mapped displays can to some level
of can be modified. It's is possible to interface a Hercules or CGA
maybe even VGA board and drive that too.
The real limit is if one expects to make money and speed.
Allison
Peter Kocourek
Alastair S. Preston <aspr...@freenet.calgary.ab.ca> wrote:
> One caveat on Lynx - which I'm using right now in the manner you suggest -
> it expects your system to emulate a VT100 terminal. You'll need a terminal
> program that can handle that. I haven't tried connecting with my CP/M
> system (due to lack of an extrenal modem), but it does ADM3 emulation, and
> I'm not sure it could do the VT100 emulation properly even if I had a term
> program that did. Other CP/M machines may be in a similar position.
Well, not quite. Lynx will work (as most well-behaved terminal programs)
with just about any terminal setting, unless they need special
attributes. Lynx works just fine with TERM set to adm3a on my Sun 3/60,
it's just that it's almost useless. ;-) The problem lies in the fact
that the adm3a does not have reverse video, which means that lynx has no
way of showing hyperlinks. There are a few other problems with cursor
keys too.
It does seem that my Kaypro 10 is able to do reverse video (some Kaypro
utilities use it), but I have no idea what the proper control codes
would be to achieve that. It is possible to create one's own terminal in
the /etc/termcap database if you know more about the terminal
capabilities of your CP/M computer (only if you are root on the Unix
system, of course; ordinary users should not have write permission in
/etc). Then just set the TERM environment variable. (Use "setenv TERM
adm3a").
If someone out there know all the control codes the Kaypro 10 will
accept, I'll create an /etc/termcap entry if anyone's interested. I use
my Kaypro now as a terminal for one of my Suns, and I would not be
averse to have some additional capabilities.
Peter.
Will Rose
Alastair S. Preston (aspr...@freenet.calgary.ab.ca) wrote:
[...]
: One caveat on Lynx - which I'm using right now in the manner you suggest -
: it expects your system to emulate a VT100 terminal. You'll need a terminal
: program that can handle that. I haven't tried connecting with my CP/M
: system (due to lack of an extrenal modem), but it does ADM3 emulation, and
: I'm not sure it could do the VT100 emulation properly even if I had a term
: program that did. Other CP/M machines may be in a similar position.
There are good vt100 emulators for CP/M; oddly enough, tho' kermit
is pretty good at this on all other platforms, the CP/M version
doesn't handle it (as best I recall). I used to use the commercial
version of MEX, but I think QTERM may also have an emulation. There's
no reason why a CP/M terminal program can't do this.
kl...@rand.nidlink.com
>And while you can handle text with that VT100, it's NOT gonna handle
>the sort of graphics found everywhere these days.....it only has a
>few crude block shapes and simple attributes. There's simply no way
>do display things like .jpg's and .gif's.
Yeah, this is pretty much a "given," Bill. If one is gonna "surf the
net" under CP/M, one had best be prepared to live with TTY text mode
only. But it's not so bad. The information is still there...except
for those @#$& occasional web sites that have chosen to make each
"page" a graphics file, rather than an HTML script!
The single exception would be if one were running CP/M-86 on an IBM-
compatible. It's theoretically possible to write a fully graphical
web browser for that O.S., using all of the IBM clone's graphical
capabilities. But I don't suppose that's very likely.
`[1;32;42mNet-Tamer V 1.02.2 - Test Drive
Alastair S. Preston
> attributes. Lynx works just fine with TERM set to adm3a on my Sun 3/60,
> it's just that it's almost useless. ;-) The problem lies in the fact
> that the adm3a does not have reverse video, which means that lynx has no
> way of showing hyperlinks. There are a few other problems with cursor
> keys too.
Hmmmm... The version of Lynx on the local freenet (running under AIX)
insists on VT100 emulation. Perhaps this has been set by the system
administrators?
My JLS BigBoard has no way to turn reverse video on and off, though
it can be hard wired to display reverse video instead of "normal"
(white on black).
Holger Petersen
pe...@duttnxc.tn.tudelft.nl (Peter Kocourek) writes:
>It does seem that my Kaypro 10 is able to do reverse video (some Kaypro
>utilities use it), but I have no idea what the proper control codes
>would be to achieve that. It is possible to create one's own terminal in
>the /etc/termcap database if you know more about the terminal
>capabilities of your CP/M computer
I _think_ it had be done. Perhaps in soem 'microcornucopia' or probably
more in 's-100 microsystem', as Don Libes (son of Sol) was a unix-enthu-
siast at that time.
>If someone out there know all the control codes the Kaypro 10 will
>accept, I'll create an /etc/termcap entry if anyone's interested. I use
>my Kaypro now as a terminal for one of my Suns, and I would not be
>averse to have some additional capabilities.
I once did a (specialiced) terminal-Emulation program for any Kaypro
[Hartmann&Braun CONTRONIC SPS] and I disassembled all relevant diffe-
rent KAYPRO-BIOSses (2, 2/84, 10).
But I don't have any simple access to this info.
Greetings, Holger
PS: Peter, is your 'Organization' - Line real or a joke?
If real, I'd like to visit you :-)
Bill Marcum
If you can find the control codes for your computer, you don't need to
write them in /etc/termcap. You can put the termcap entry in the
environment variable TERMCAP. On a system that uses terminfo, you can
create a terminfo directory, put its name in the variable TERMINFO, and
use tic to compile a terminal definition.
There are also CP/M programs to emulate a VT100, such as Kermit and
Qterm.
There is a library of terminal information at
ftp://cs.utk.edu/pub/shuford/terminal/ but I don't see anything
specifically about Kaypro in there.
--
Bill Marcum bma...@iglou.com
On 22 July, 1996, at 6:00 pm GMT, everyone in the world
just START HUMMING. Those who don't know will freak.
michael butler
76703...@compuserve.com wrote:
: I'd like to surf the net using my CP/M computer.
: Are there internet tools and especially a web
: browser for CP/M? I have Epson QX-10 and
: QX-16 running CP/M 2.2
Not a show .. to put a perspective on it .. to implement the TCP/IP
networking support in Z80 code requires ~16-20kb of code-space to do
properly (i.e. fragment support) and will need at least 8kb of data space to
run. (I know this because I've done it and decided to fall back to a
UDP-only design which is *much* smaller)
This is not counting the space needed for any device-level drivers such as
would be required to run PPP (large because of HDLC framing) or SLIP
(smaller) and we haven't yet accounted for CP/M and some sort of browser ..
You have no choice but to use it as a simple text-mode terminal,
michael
A.R. Duell
i...@asstdc.scgt.oz.au (michael butler) writes:
>76703...@compuserve.com wrote:
Wait a second. The original poster mentioned a QX-10. You're missing a
few things :
1) The QX-10 can have up to 256K of memory - it's bank-switched, of
course, but if you write the program in a suitably modular way you might
get away with it.
2) There's a nice 7220 graphics chip with its own display memory (up to
128K).
3) The QX-10 uses a 7201 serial chip. I'm not sure if the extra features
of this chip are useful here ( I guess not - I think you can only use
them in synchronous mode), but they might be.
Now, I don't know of an web browsing software for the QX-10, but it might
not be totally impossible
The QX-10 was one of the nicest CP/M machines IMHO. They got a lot of
things right in it - a nice serial chip, a nice graphics controller,
expansion slots, very nice floppy drives (they use linear actuators to
position the heads, not a stepper motor), etc.
> michael
--
-tony
ar...@eng.cam.ac.uk
The gates in my computer are AND,OR and NOT, not Bill
bill_h
keyboard remapping....
My old friend Daryl Coulthart had his keyboard remapping program
published in MicroCornucopia many years ago. Should be an easy mod
for a Kaypro, or anything else.
About the time he was doing that, I wanted to use a really nice Cherry
keyboard (scrounged from Control Data) whose only 'problem' was that
EVERYTHING was screwed up......I had to patch in a translation program
in the system area, after it relocated itself. If you want to get really
sneaky I could look for this thing....it's nowhere near as clean as
Daryl's, but I didn't want to waste any space....I didn't even know
he was working on such a thing until the magazine came out.
I'll see if I can find the right issue.
Peter Kocourek
Bill Marcum <bma...@iglou.iglou.com> wrote:
> If you can find the control codes for your computer, you don't need to
> write them in /etc/termcap. You can put the termcap entry in the
> environment variable TERMCAP. On a system that uses terminfo, you can
> create a terminfo directory, put its name in the variable TERMINFO, and
> use tic to compile a terminal definition.
Yes, that is much simpler than my earlier suggestion of modifying
/etc/termcap. In fact, I played around with lynx a little, and it
appears it prefers terminfo to termcap anyway.
Spurred on by the turn this thread has taken, I started poking around
looking for information on the terminal capabilities of my Kaypro, and
found them (shock, horror) hidden in the user's guide. ;-) Anyway, I
have now managed to get my Kaypro to display reverse video, underlined
text, and even blinking characters.
Now the display in lynx looks right, but it is sadly unusable; it's the
cursor keys that are the problem. In the adm3a terminal the codes these
keys send are ASCII 8, 10, 11 and 12 (for right, down, up and left
respectively). Therein lies the rub...
So I've tried to use the WSKP program that came with WordStar to remap
the keypad to send more easily distinguishable keycodes, but when I run
WSKP, my terminal program (Fastterm) refuses to work. And Fastterm is
the only one that was fast enough not to drop any characters when
connected at a sensible speed (i.e. more than 600 bps).
I think I would have an almost perfect terminal emulation for my Kaypro
if only I could map the cursor keys to send more interesting codes back.
I don't know much about programming CP/M systems, but I suppose it
should be doable. Any ideas? I used to be fluent in Z80 assembler, so I
suppose I could pick it up again fairly quickly. How does one patch CP/M
console I/O?
Anyway... if anyone's interested in my termcap and terminfo entries for
a Kaypro 10 terminal, let me know. Except for the cursor key problem, it
works quite nicely now.
> There are also CP/M programs to emulate a VT100, such as Kermit and
> Qterm.
I'll try to see if they are somewhere on the disks I got with my
machine. Thanks for the tip.
Elsewhere in this thread, Holger Petersen <h...@kbbs.org> wrote:
> PS: Peter, is your 'Organization' - Line real or a joke?
> If real, I'd like to visit you :-)
Oh, it's real. We're trying to build a CP/M computer entirely out of
chocolate, but we suffered a real setback when the cleaning ladies ate
our prototype chocolate Z80's. :-) And somehow our supply of 8"
chocolate floppy disks seems to run out very quickly. A sad state of
affairs, to be sure.
Peter.
Jeff Wieland
In article <1996052618...@kocourek.tn.tudelft.nl> pe...@duttnxc.tn.tudelft.nl (Peter Kocourek) writes:
>
>It does seem that my Kaypro 10 is able to do reverse video (some Kaypro
>utilities use it), but I have no idea what the proper control codes
>would be to achieve that. It is possible to create one's own terminal in
>the /etc/termcap database if you know more about the terminal
>system, of course; ordinary users should not have write permission in
>/etc). Then just set the TERM environment variable. (Use "setenv TERM
>adm3a").
>
>accept, I'll create an /etc/termcap entry if anyone's interested. I use
>my Kaypro now as a terminal for one of my Suns, and I would not be
>averse to have some additional capabilities.
>
Seek, and ye shall find:
I wrote these for my Kaypro 2X. The non-TurboROM entries haven't
been used for a long time, but they shoule be a good starting
point, at the very least. They graphics Kaypro's can display
underlining, half-intensity & reverse video. They can also
turn the cursor on and off, and save and restore the cursor
position.
#
# These additional entries are for CP/M Kaypros using the Advent TurboROM
# replacement monitor ROM chip. This provides an insert char and delete char
# sequence, allows a 25 line scrolling screen (has faster scrolling than the
# 24 line mode), and has hardware tab expansion. They also assume use of an
# interrupt driven telcom program such as Mite or Micro-C's public-domain fast
# terminal emulator IntTerm. Alternate character set restored for '84's-
# displays thin-line graphics.
#
# Edited by Jeff Wieland 1/21/87
#
kg|k83tr|kiitr|kivtr|kaypro '83 w/ turborom:\
:ic=^A:dc=^B:ta=^I:tc=k83-t:
kh|k84tr-s|kaypro '84 w/ turborom and status line:\
:li#24:is=\EC4^J^K\EB7\EB4:\
:rs=^^^W\EC0\EC1\EC2\EC3\EB4\EC5\EB7\EA:\
:hs:es:i2=\EB7\EB6\EC4\E=8 ^X\EC6\EB4:\
:ts=\EB6\EB4\E=8%+ \EB1:\
:fs=\EC1\EC6\EB4:\
:ds=\EB6\EC4\E=8 ^X\EC6\EB4:\
:ws#80:tc=k84tr:
ki|k84tr|kaypro '84 w/ turborom:\
:am:bs:pt:mi:co#80:li#25:is=\EB6\EC4\E=8 ^X\EC6\EB4\EC7:\
:cr=^M:up=^K:do=^J:nd=^L:le=^H:nl=^J:bl=^G:ho=^^:ta=^I:cm=\E=%+ %+ :\
:rs=\EC0\EC1\EC2\EC3\EB4\EC5\EC7\EA^^^W:\
:cl=^^^W:cd=^W:ce=^X:\
:kl=^H:kd=^J:ku=^K:kr=^L:kh=^^:ma=^Hh^Jj^Kk^Ll^^H:\
:al=\EE:dl=\ER:ic=^A:ei=:dc=^B:sf=^J:sr=\EE:\
:so=\EB0\EB1:se=\EC0\EC1:us=\EB3:ue=\EC3:as=\EG:ae=\EA:\
:mb=\EB2:mh=\EB1:mr=\EB0:ms:me=\EC0\EC1\EC2\EC3:\
:sc=\EB6:rc=\EC6:ve=\EB4:vi=\EC4:md=\EB1:mh=\EB1
#
# These entries are for the CP/M Kaypros. These fit into two catagories:
# 1. Kaypro II and IV ('83 or eariler- includes Kaycomp, if any of these
# still exist). Have no video attributes. At 300 baud you probably should
# turn off ce, because it really slows things down in vi. The '83 entries
# have not been tested on an '83 series Kaypro: I don't have access to one.
# I set cl to ^^^W (home cursor, clear to end of screen) so that if you are
# downloading from the screen, you will not receive the CP/M eof character
# (^Z- the Kaypro's normal clear screen command). Greek alternate character
# set is turned on by as.
# 2. Kaypro 1, 2, New 2, 2X, 4, 8?, 10 and Robie ('84 series). Can display
# inverse, half-intensity, blinking, and underlined video. No alternate
# character set. Have a status line. Sysline works!
# Note: If you are using Kermit, Superterm, or any other terminal program
# that does not buffer input, you will need to use the the kkerm entry,
# which has been tested to 1200 baud.
# If you are using Mite, which is interrupt-driven and expands tabs, then
# use the k84 entry. If you are using Mite with an '83, then use k83-t.
# If you are using Micro-Cornucopia's Fast Terminal program, which is
# interrupt-driven but does not expand tabs, use the k84-nt entry. If you
# have an '83, use k83.
# Edited by Jeff Wieland 9/23/86
ka|k83|kii|kiv|kaypro ii|kaypro iv:\
:am:bs:cr=^M:up=^K:do=^J:nd=^L:le=^H:nl=^J:bl=^G:cm=\E=%+ %+ :\
:co#80:li#24:ma=^Hh^Jj^Kk^Ll^^H:cl=^^^W:cd=^W:ce=^X:ho=^^:\
:kl=^H:kd=^J:ku=^K:kr=^L:kh=^^:al=\EE:dl=\ER:as=\EG:ae=\EA:
kb|kk83|kkerm83|kaypro '83 running kermit with vt52 emulation off:\
:kl=\ED:kr=\EC:ku=\EA:kd=\EB:\
:cl=340^Z:ce=5*^X:al=18*\EE:dl=15*\ER:tc=k83:
kc|k83-t|kaypro '83 w/ tabs:\
:pt:ta=45^I:tc=k83:
ke|k84|k1|k2|k2x|k10|robie|kaypro 1|kaypro 2|kaypro 2x|kaypro 10:\
:as@:ae@:pt:ta=25^I:so=\EB0:se=\EC0:us=\EB3:ue=\EC3:\
:hs:es:i2=\EB7\EB6\E=8 ^X\EC6:ts=\EB6\E=8%+ \EB1:\
:fs=\EC1\EC6:ds=\EB6\E=8 ^X\EC6:tc=kii:
kd|k84-nt|kaypro '84 w/o tabs:\
:pt@:ta@:tc=k84:
kf|kk84|kkerm84|kaypro '84 running kermit with vt52 emulation off:\
:cl=340^^^W:ce=5*^X:al=18*\EE:dl=15*\ER:tc=k84-nt:
--
Jeff Wieland
Jeff_W...@acn.purdue.edu
Dietmar Gibietz
pe...@duttnxc.tn.tudelft.nl (Peter Kocourek) wrote:
>Now the display in lynx looks right, but it is sadly unusable; it's the
>cursor keys that are the problem. In the adm3a terminal the codes these
>keys send are ASCII 8, 10, 11 and 12 (for right, down, up and left
>respectively). Therein lies the rub...
>So I've tried to use the WSKP program that came with WordStar to remap
>the keypad to send more easily distinguishable keycodes, but when I run
>WSKP, my terminal program (Fastterm) refuses to work. And Fastterm is
>the only one that was fast enough not to drop any characters when
>connected at a sensible speed (i.e. more than 600 bps).
>I think I would have an almost perfect terminal emulation for my Kaypro
>if only I could map the cursor keys to send more interesting codes back.
>I don't know much about programming CP/M systems, but I suppose it
>should be doable. Any ideas? I used to be fluent in Z80 assembler, so I
>suppose I could pick it up again fairly quickly. How does one patch CP/M
>console I/O?
Hi Peter,
my Kaypro 10 (german modell) was shipped with a CONFIG program, which
allowed for a free assignment (up to four characters) of the number keys
in the number-block . I used it (e.g.) for ^KSQP (save and return to
last position) in WordStar and it worked for other progs, too. I've been
writing my own editor with TurboPascal, and this editor used WS-keys.
The same CONFIG-program was used for I/O-assignment, serial interface
and some other things. Didn't it come with your machine?
Dietmar
Dietmar Gibietz-Rheinbay
Potsdam Institute for Climate Impact Research
Dept. Data & Computation
Tel: +49 (0)331 288 2536 Fax: +49 (0)331 288 2600
di...@pik-potsdam.de http://www.pik-potsdam.de
arog on BIX
Chris,
UKansas has a 'dos' port of Lynx. This is a Text web browser.
That is is 'dos' means that it has had all of it's names
changed to 8.3 format. It also appears that it may be fully
ANSI C code. The good of this is that one of the major hacking
aspects of the project is getting all of the names converted over.
The bad is that I don't know of any ANSI C compilers for CP/m.
Aztec and BDSD are both K&R as is my 2500AD cross compiler.
The second part of the project is to create a sockets enviornment
for Lynx to work under. I'm still in the process of digging for
sources and the needed RFC's on this.
The third element is a PPP or SliP driver to talk to the serial
port. Part of this can start with the Cyrnware(?) or KA9Q driver
collections. These also are avaiable in source, mostly C or "dos"
assembler.
Implicit in this effort is building a set of libraries for the C
compilers to use, if they don't exist.
At this point, it looks this way:
A hard disk is going to be Required for use as paged memory.
Overlays are going to be Required.
Graphics are probably going to be very limited or excluded.
The last item, re: Graphics, is simply a fact of life. Most CP/m
systems can not deal with bitmapped images. It may be possible to
do something for certain machines in terms of a GhostScript interperperter,
but that is something to be left until the other.stuff is done.
My 'home-base' for this is the 'nos' Conference on BIX. Anyone that
is interested can send me a note at 'ar...@BIX.com' and I'll find
out what the best 'offer' we have is and let you know. There is
normally a decent "Try-Us" offer in the BIX ad in Byte. I'll
also offer to anyone that comes aboard to send me a note with
simply 'mail to arog' and I'll answer any questions that you've got
about BIX and how to drive our Cosy Conferencing System.
Alan Ogden,
ar...@BIX.com
Moderator of "NOS" which includes all DR products.
arog on BIX
Alastair,
Lynx is available in Source from one of the U_Kansas FTP sites.
As I noted in my last note, there is also a 'dos' version of it,
again with sources.
This translates to any of us being able to hack the terminal emulation
to what we need.
Alan Ogden
arog on BIX
Lindsay,
The bits and pieces of code are available. *WE* can create
the needed hunks.
I CAN provide a home, for those that need it, on BIX. I suspect
that U Kansas would be (see Spock raise his eyebrow) find such
an effort Interesting.
8)
Alan Ogden
arog on BIX
Michael,
Given a CP/m 2.2 system, the TPA is going to be about 48K.
Further, if the BIOS was provided in Source, the code related
to the comms port could be hacked to provide for a request for
a SliP or PPP connection. This incudes a full replacement.
One scheme for 'full replacement' would be, knowing the addresses
used in the BIOS, to have an overlay for that area that is loaded
as part of the 'setup' for such a session. Even if those addresses
are not known, ie. one of the machines that did NOT have a source
for it's BIOS, a fair amount of the needed data can be found with
either DDT or SID. These areas can be overlayed, and assuming a smart
utility that first copies them to disk, restored after the session ends.
Me, I'd do a cold.boot anyway.
Further, the CCP area can be used for code. A warm.boot serves to
restore it anyway. So, we are looking at the space from CPM_BASE
(100h) to BDOS_BASE as avaialbe for this application to run in.
In addition to the space needed for the actual code (Lynx?) to run
in, we need some space for buffers so that disk access is kept to
a reasonable level.
Can IT be done? My rough estimates so far indicate that it can be,
provided that there is a hard disk and that overlays are used.
kl...@rand.nidlink.com
>At this point, it looks this way:
>A hard disk is going to be Required for use as paged memory.
>Overlays are going to be Required.
>Graphics are probably going to be very limited or excluded.
>The last item, re: Graphics, is simply a fact of life. Most CP/m
>systems can not deal with bitmapped images. It may be possible to
>do something for certain machines in terms of a GhostScript
>interp[re]ter, but that is something to be left until the other.
>stuff is done.
My suggestion would be to totally dispense with any kind of
pseudo-"graphics" for the CP/M-80 'Net software. It simply
isn't necessary, or very productive. Text-mode browsing is
just fine...and if someone just HAS to have a graphic from a
web page, they can always download it and view it off-line.
You might take a look at some DOS-based, non-graphical 'Net
software for ideas on what you might/might not want to include
in your program. Probably the two best such DOS programs are
MINUET and NET TAMER (I'm currently using the "XT" version of
NET TAMER on my turbo XT, with a PPP account). MINUET requires
a separate packet driver; NET TAMER doesn't. Both are shareware.
Good luck!
7 6
Ismael Cordeiro
arog on BIX (ar...@BIX.com) wrote:
> The bad is that I don't know of any ANSI C compilers for CP/m.
Hi-Tech C is an ANSI C compiler for CP/M. You can find it at
oak.oakland.edu.
Ismael
--
+---------------------------------------------------------+
| ISMAEL CORDEIRO | ism...@cam.org |
| Montreal - Quebec - Canada | http://www.cam.org/~ismael |
+---------------------------------------------------------+
Allison Parent
ar...@BIX.com (arog on BIX) wrote:
>The last item, re: Graphics, is simply a fact of life. Most CP/m
>systems can not deal with bitmapped images. It may be possible to
>do something for certain machines in terms of a GhostScript interperperter,
>but that is something to be left until the other.stuff is done.
Hi Alan,
Cp/m handling graphics is possible but for a second pass effort.
First pass might be to grab the graphic and "file it" to disk. As to
presenting it, low res 480x240 mono and some 4plane color are
available. Most DEC terminals vt125, vt240, vt340 and others
do a binary protocal for mono and color graphics called SIXEL.
So presenting a file is a conversion process. Other have a 6845 or
7220gdc and also could do something.
Generally it's access to information more than graphics that is
important.
As to ansi C compiler, it's handy but likely not needed as the sources
will have to be trimmed and re-ordered for overlays. I'd personally
suggest writing as much as possible in assembler once C code is
functional as most compilers produce BIG code and z80 code space is
limited. The use of a virtual disk or swapping file is good sense as
well. Especially useful is ramdisk for speed. Banked/mapped memory
would help this kind of application as well.
Allison
Shawn Sijnstra
Alan,
The Hitech-C compiler is almost ANSI. From what I remember if the documentation
it copmlies to some of the preliminary ANSI specs. It may not be current ANSI
but it should be close. Their cross compilers probably come a lot closer (I
don't know.... I don't own anything that can run MSDOS).
I don't see why this can't be done as you said... with a hard drive (or a RAM
drive). I also run UZI280 which may be able to run the SLIP or PPP as a daemon
or something. Surely it could run it as a separate process and have a full
browser and other things running (such as mail). There are UUCP and MAIL written
for the original UZI but I haven't played with them. I know that UZI is cheating
because it isn't CP/M but perhaps it provides a simpler platform for
development.
Shawn
Joel Lichtenwalner
alli...@WORLD.STD.COM (Allison Parent) wrote:
> Suggest writing as much as possible in assembler once C code is
functional as most [C] compilers produce BIG code and z80 code space is
limited.
You must be mistaken. Most of the respondents to my comments on C have
assured me that C is as good as assembly language and portable, too.
Joel in Ogden Utah
Peter Disdale
In article <96060602531...@emout07.mail.aol.com>
JWill...@AOL.COM writes:
No, Joel - most of the respondents to your ramblings have been
comparisons between C and (Turbo) Pascal. I have yet to come
across any high-level language compiler that will produce object
code close to well-written assembler.
Any compiler must produce fail-safe, "clockwork-type" code and
hand-crafting can nearly always improve on this.
Keep taking the pills...
--
Pete
Peter Kocourek
Joel Lichtenwalner <JWill...@AOL.COM> wrote:
> alli...@WORLD.STD.COM (Allison Parent) wrote:
> > Suggest writing as much as possible in assembler once C code is
> functional as most [C] compilers produce BIG code and z80 code space is
> limited.
>
> You must be mistaken. Most of the respondents to my comments on C have
> assured me that C is as good as assembly language and portable, too.
Really? I have just been browsing through the postings to this
newsgroup, grepping for "assembl," and I have not seen a single
"respondent" of yours make the claim that "C is as good as assembly,"
whatever that is supposed to mean; from the context I guess you are
trying to say that the claim was that "C compilers produce code that is
as small and fast as hand-coded assembly." Even then, I can't find any
postings of your respondents claiming this.
In fact, most of them have stated the exact opposite.
This can mean any of the following:
1) I missed all those comments you are referring to. If so, please post
message-ID's, so I can look them up.
2) You have the attention span of a goldfish, and have already forgotten
what was written.
3) You can't read.
4) You are so immersed in your bigoted world-view, that you are now
inventing things you think your respondents should have said, had they
conformed to your caricature of those who don't think Turbo Pascal is
the best language ever.
5) You're a pathetic liar.
Please elucidate.
Peter.
john r pierce
Joel Lichtenwalner <JWill...@AOL.COM> wrote:
>alli...@WORLD.STD.COM (Allison Parent) wrote:
>> Suggest writing as much as possible in assembler once C code is
>functional as most [C] compilers produce BIG code and z80 code space is
>limited.
>You must be mistaken. Most of the respondents to my comments on C have
>assured me that C is as good as assembly language and portable, too.
This might be true on late model RISC engines, and even to some extent
on pentium class processors, at least in 32bit 'flatland', but in no
way could possibly be true on a limited resource processor such as the
Z80 family...
-jrp
ric...@warwick.net
Joel Lichtenwalner (JWill...@AOL.COM) wrote:
: alli...@WORLD.STD.COM (Allison Parent) wrote:
: > Suggest writing as much as possible in assembler once C code is
: functional as most [C] compilers produce BIG code and z80 code space is
: limited.
: You must be mistaken. Most of the respondents to my comments on C have
: assured me that C is as good as assembly language and portable, too.
When you're talking about modern chips with pipelined architecture and
good optimising compilers, C will be very nearly as fast as
hand-optimised assembly language. It will still be bigger, because of
library and start-up overhead. When you're talking about a Z80 or
other 8-bit CPU's, and compilers that run on them, assembly language
is much superior to C in both speed and size... and size is critical.
My DEZIP zip decompressor for the TRSDOS compatible operating systems
is written in 100% Z80 and is about 9k in executable size, but uses
nearly the entire user area on a Model 4 (because of a 32k history
table, and various other data structures required by the various
decompression algorithms). If I'd written it in C, the code would have
been at LEAST twice as big, requiring either overlays (which might not
free up enough memory) or swapping a large portion of the history
table to disk for deflated files, seriously degrading performance.
I also wouldn't be able to use the same /CMD file to run under both
the Model I/III DOS's and the Model 4's TRSDOS 6, which has a
considerably different memory map and system call interface, as I do
with the unregistered version of DEZIP and with all my other archive
extraction utilities, without completely re-writing the C libraries,
or at least those portions interacting with the operating system.
When size is all important, assembly language wins over anything
except an indirect-threaded interpretive language (like most
implementations of Forth).
Allison Parent
ar...@BIX.com (arog on BIX) wrote:
>Michael,
>Given a CP/m 2.2 system, the TPA is going to be about 48K.
>Further, if the BIOS was provided in Source, the code related
Alan,
Most CP/M 2.2 systems without hard disk are easily 56k and 60k is
possible. My amproLB running 2 floppies has a 60k TPA. I've done
a banked 2.2 system that has a 63k TPA so there may be more space
than origionally thought.
Also the SLIP/PPP stack could be layered into the bios as a device
for the com port. That would hide a fair amount of the low level
stuff. Of course that requires a copy of the bios to do that overlay.
Allison
Allison Parent
Joel Lichtenwalner <JWill...@AOL.COM> wrote:
>alli...@WORLD.STD.COM (Allison Parent) wrote:
>> Suggest writing as much as possible in assembler once C code is
>functional as most [C] compilers produce BIG code and z80 code space is
>limited.
>You must be mistaken. Most of the respondents to my comments on C have
>assured me that C is as good as assembly language and portable, too.
> Joel in Ogden Utah
Joel,
For small code I've never had a C compiler produce less than 1.3
assembler. Some compilers carry a runtime package that is obtrusive
to the max. The most compact C code I've done is using the SMALLc
compiler and had optimizing. HLL all carry a size penelty that is
generally made up for by ease of development of complex code.
I base this on producing code for micros for the last 20+ years.
Allison
Richard Plinston
In message <<96060602531...@emout07.mail.aol.com>> Joel Lichtenwalner <JWill...@AOL.COM> writes:
> > Suggest writing as much as possible in assembler once C code is
> functional as most [C] compilers produce BIG code and z80 code space is
> limited.
>
> You must be mistaken. Most of the respondents to my comments on C have
> assured me that C is as good as assembly language and portable, too.
> Joel in Ogden Utah
That depends on what is meant by 'as good as'. It also depends on
the compiler. There are C compilers which will produce code that
is significantly slower and bulkier than the best handcoded assembler,
and other compilers that can produce code that is faster than 'average'
assembler.
I don't think that any Z80 C compiler had significant optimization.
Certainly not anywhere near how well Zortech or Watcom can do. In
this case hand optimising on Z80 is probably worth while for both
speed and bulk in commonly used libraries.
You shouldn't apply generalisations to specific cases.
Bill Leary
> You must be mistaken. Most of the respondents to my comments
> on C have assured me that C is as good as assembly language
> and portable, too.
1. I'd never question Allison's competence, but then I've had an
exchange or two more with her than you probably have.
2. My experience with C compilers (Z80 or otherwise) is that it
depends (like most things in life). The first one I used on
my Z80 did a fair job. The best one's I've seen (and I've
delt with code generation on a lot, Z80, 68K, Sparc, VAX)
were all a far cry from Assembler in efficiency from the
machine perspective. That is, code space or speed.
3. People who express the opinion that C is as good as assembler
have either (a) never looked at the code generated or had to
deal with a time critical interrupt handler or used a machine
with memory or clock cycle limits or (b) are using a machine
and compiler package I've never seen or heard of.
The thing is, if your machine is fast enough and has enough
memory, then you'll never notice the performance difference.
- Bill
--
+----------------------------------------------------------------
| William J. Leary Jr.
| Paralyn Associates
Allison Parent
rip...@kcbbs.gen.nz (Richard Plinston) wrote:
>the compiler. There are C compilers which will produce code that
>is significantly slower and bulkier than the best handcoded assembler,
>and other compilers that can produce code that is faster than 'average'
>assembler.
Depends on the CPU and the compiler. As to faster, also very
dependent on the CPU.
>I don't think that any Z80 C compiler had significant optimization.
>Certainly not anywhere near how well Zortech or Watcom can do. In
>this case hand optimising on Z80 is probably worth while for both
>speed and bulk in commonly used libraries.
Wrong for the z80 case! BDS, Smallc V2 and Hitech are all optimized.
For some that would compile for the 8080 that was not true however.
That is due to the 8080 having half the z80 instructions with the
missing ones being significant.
Do either of those compilers produce z80 code or run on z80 or under
CP/M?
>You shouldn't apply generalisations to specific cases.
Z80 and the above compilers are not generalizations. C is very
compact and does produce what I'd consider good code on a z80.
I'd even say of all the HLLs it is the most compact. It will never
displace assember where rom or ram space is premium.
Also I've written enough code in both and tried to do fast I/O or
interrupt handlers in C and it does not work for the Z80 case.
If you don't believe me try this, Floppy disk read without DMA
on a z80 at 4 mhz (250ns cycle, minimum instruction time 1us), For
double density 8" you have 13 microseconds worst case to:
Read main status for transfer request.
Transfer byte from FDC
Store byte in buffer
increment the buffer pointer
decrement byte count
determine if last byte (count is zero)
In assembler this is easy. In C it reads clearly however,
the z80 must run at something like 10 mhz for the C code
to keep up as it is bulkier. FYI the bulk of that routine can be
handled in one z80 instruction <INI, 16 t states or 4us at 4 mhz>.
For small cases assembler is the winner. If I were doing a GUI
then C would be the choice but not for speed or size but for
programming clarity and development speed. In most cases
assember wins the speed and space war, it fails in the development and
debug time war. for many applications C wins and even then I've put
critical sections into assember for speed or compactness. I may add
that for library functions that is even more true as many of the stock
ones are for generalized use and for some apps you can concoct
something smaller or faster even in C if your cases are specific
enough.
Then again I've spent most of my time writing code for single chip
CPUs with limited ram and rom space or other 8 bit cpus where
response time was important. There were days when I'd have killed
for a C cross compiler that ouput 8048 code to fit in 1k of rom and 64
bytes of ram. Now on my Vax I'd never consider assember and use C
exclusively, but then again I have unlimited virtual memory under VMS
and no shortage of speed.
Allison
Richard Plinston
In message <<Dsonu...@world.std.com>> alli...@world.std.com writes:
>
> >I don't think that any Z80 C compiler had significant optimization.
> >Certainly not anywhere near how well Zortech or Watcom can do. In
> >this case hand optimising on Z80 is probably worth while for both
> >speed and bulk in commonly used libraries.
>
> Wrong for the z80 case! BDS, Smallc V2 and Hitech are all optimized.
Yes, these have some optimisations. The Small-C that is described
in Hendrix's book has peephole optimisation. But do any of these
have 'significant' optimisation, which is what is required for you
to call out 'Wrong'. Many of the optimisations performed by Watcom
or Zortech require large numbers of CPU cycles and memory that would
not be affordable on a CP/M machine.
Later in your message you even agree that hand optimising on Z80 is
worthwhile.
Douglas Beattie Jr.
Bill Leary <74271...@CompuServe.COM> wrote:
>
>2. My experience with C compilers (Z80 or otherwise) is that it
> depends (like most things in life). The first one I used on
> my Z80 did a fair job. The best one's I've seen (and I've
> delt with code generation on a lot, Z80, 68K, Sparc, VAX)
> were all a far cry from Assembler in efficiency from the
> machine perspective. That is, code space or speed.
>
>3. People who express the opinion that C is as good as assembler
> have either (a) never looked at the code generated or had to
> deal with a time critical interrupt handler or used a machine
> with memory or clock cycle limits or (b) are using a machine
> and compiler package I've never seen or heard of.
>
>The thing is, if your machine is fast enough and has enough
>memory, then you'll never notice the performance difference.
>
> - Bill
>
There is no way to produce compiled C code as tight or as fast
as assembler. The hallmark of C seems to be its portability.
Some high-level language (HLL) packages can optionally produce
assembler source output, which can be "hand optimized" by an
assembly-language programmer. Unfortunately, most C programmers
are not also effective assembly-language programmers. That is
probably why, particularly with commercial software products
under CP/M, the best programs (combining good execution speed
with memory efficiency) were written in assembler code.
One question is -- can C be a tool for producing a skeleton
program in CP/M, which can serve as the basis for an application
which is "written" entirely in assembler? Consider: design
the program in C (which technically is not a HLL), and use
the assembler output as the basis for your continued program
development. Then throw the C compiler away! You'll be glad
you did.
Bear in mind that if you are not an 8080 or Z80 programmer, the
C-compiled code is probably a good compromise. There is also
one language in particluar which is comparable to assembler in
speed, and sometimes more code-efficient than assembler itself!
That language is FORTH.
-- { tear here } -------
Douglas Beattie Jr. http://www.whidbey.net/~beattidp
Allison Parent
"Douglas Beattie Jr." <beat...@svc.ctc.edu> wrote:
>One question is -- can C be a tool for producing a skeleton
>program in CP/M, which can serve as the basis for an application
>which is "written" entirely in assembler? Consider: design
You bet and faster too.
>the program in C (which technically is not a HLL), and use
>the assembler output as the basis for your continued program
>development. Then throw the C compiler away! You'll be glad
>you did.
Never! I've found a hybrid approach using inline assembly code was
the best for getting there fast and functional. In some cases there
was a lot of inline assembler, others less so. In each case the
critical areas were known.
>Bear in mind that if you are not an 8080 or Z80 programmer, the
>C-compiled code is probably a good compromise. There is also
True enough. Also for some things I find pascal very efficient or
PL/M. I use what seems best for the task and cosistant with my
experience using that language. Example I use pascal where data
structures are critical or complex.
>one language in particluar which is comparable to assembler in
>speed, and sometimes more code-efficient than assembler itself!
>That language is FORTH.
Forth is definately an odd one int he language world. It is far
faster than interpretive languages and near as fast as most
good compiled code. As to being faster than asm there are
good cases on both sides of that one. It's versitility and
compactness certainly work for it. It's liability is I find code
others written in it hard to read.
programming languages are like religion and politics...never one
answer that is correct.
Allison
Dave Baldwin
Allison Parent (alli...@world.std.com) wrote:
A lot of Good stuff!
: programming languages are like religion and politics...never one
: answer that is correct.
And furthermore, the basis for most comparisons is questionable. Assembly
output from 'C' and Pascal compilers is compared with trivial ASM programs
and the 'C' and Pascal compilers are declared to have too much overhead.
If you start writing large ASM programs, you're going to have to include
some of your own overhead just to be able to manage the project. You will
have to break your program into modules and subroutines and handle
parameter passing and calling conventions, those things you call
'overhead' in compiled languages.
As for Forth, the comparison is also misleading. Look at the ASM source
for some of the Forth versions. You can write in ASM as you would in
Forth and get that marvelous small code. You'll just have to build all
the structures yourself and discipline yourself to the method you've
chosen.
--
-=-=-=-=-=-=-=-=-=-=-=- Check out DIBs and TCJ -=-=-=-=-=-=-=-=-=-=-=-=-
Dave Baldwin: dib...@netcom.com | The Computer Journal 1(800)424-8825
DIBs Electronic Design | Home page "http://www.psyber.com/~tcj/"
Voice : (916) 722-3877 | Hands-on hardware and software
TCJ/DIBs BBS: (916) 722-5799 | TCJ/DIBs FAX: (916) 722-7480
-=-=-=-=-=-=- @#$%^&* I can't even quote myself! Oh,well. -=-=-=-=-=-=-
Peter Kocourek
Douglas Beattie Jr. <beat...@svc.ctc.edu> wrote:
> One question is -- can C be a tool for producing a skeleton
> program in CP/M, which can serve as the basis for an application
> which is "written" entirely in assembler?
Certainly, but... :-)
> Consider: design
> the program in C (which technically is not a HLL), and use
> the assembler output as the basis for your continued program
> development. Then throw the C compiler away! You'll be glad
> you did.
I would not go quite that far. You'd be much better off, in terms of
development time, to profile the code and see where it spends most of
its time. Even when you have identified the bottlenecks, I would not
start fine-tuning in assembler yet. First look for algorithmic
improvements; to take an extreme example, if you're doing a linear
search on a huge set of ordered data, it does not matter how good the
assembler code you produce is, as you're using an inefficient algorithm.
In the real world cases this obvious are harder to come by, and
bottlenecks can pop up in unexpected places, sometimes necessitating a
redesign of data structures in the program. You will definitely want to
do this in C, rather than assembler. Once you have exhausted this
approach, the time has come to contemplate recoding in assembler.
I would also note that it is futile to spend much time on rewriting code
that gets called very infrequently (or maybe just once during startup,
or cleanup). Unless, of course, you're very short of RAM and really need
every single byte.
Basically, I'd keep as much of my source code in C, and only recode
those parts of the code in assembler where the benefit would be
greatest.
Peter.
Roy J. Tellason
Mathias Niemz wrote:
>
> There are 'C'-compilers producing realy huge code. A simply 'Hello world'
> may cause a 20k program or more (Mix C)....If you don't need mathematic
> routines, a simply assembler program will do all you need.
Mix C only had that problem because of the lack of granularity of their runtime
library, which you _could_ include inside the executable, or have it as a separate
file on disk, making your actual com file significantly smaller.
The wonder of it was that you did have a complete K&R compiler and at that price!
Compare this to the brain-dead $79, I think it was, that was being asked for the
last version of BDS C I saw advertised in FOGHORN before I stopped getting those. Or
the lack of many features in Small-C (no structs? No fun!)...
Mathias Niemz
There are 'C'-compilers producing realy huge code. A simply 'Hello world'
may cause a 20k program or more (Mix C)....If you don't need mathematic
routines, a simply assembler program will do all you need.
---
Snailmail: Mathias Niemz - Lisztstrasse 11 - 31141 Hildesheim - Germany
Phone: (privat): +49-5121-876 932 or (business): 15921 Fax: 15405 (G2/G3)
Visit my homepage at http://ourworld.compuserve.com/homepages/Mathias_Niemz
Some software seals should be labeled "ABANDON HOPE ALL YE WHO ENTER HERE".
Dave Baldwin
Mathias Niemz (m...@huckup.winnet.de) wrote:
: There are 'C'-compilers producing realy huge code. A simply 'Hello world'
: may cause a 20k program or more (Mix C)....If you don't need mathematic
: routines, a simply assembler program will do all you need.
While 20k for 'Hello world' does seem excessive, this is still a
pointless comparison. The things that compilers in general are useful
for are not one-line displays. 'Hello world' is better done with a
pencil and paper.
john r pierce
m...@huckup.winnet.de (Mathias Niemz) wrote:
>There are 'C'-compilers producing realy huge code. A simply 'Hello world'
>may cause a 20k program or more (Mix C)....If you don't need mathematic
>routines, a simply assembler program will do all you need.
Sure, but printf("Hello World"); has to bring the entire printf
formatting library with it, usually including floating point (no way
the compiler can determine whether or not you've got a %f in the
string arg, it could have equally been a pointer to a variable
string... Not to mention stdio...
-jrp