cp/m GUI interface???
Damon Vandehey
Does anyone know if Gary Kildall ever wrote a GUI interface for his cp/m
'OS'??? If so, what was it like, and where can I get a copy of it?
Thanks,
Damon Vandehey <dam...@pccaix.sycrci.pcc.edu>
kl...@rand.nidlink.com
On Fri, 28 Jun 1996 damonv said:
>Does anyone know if Gary Kildall ever wrote a GUI interface for his
>cp/m 'OS'??? If so, what was it like, and where can I get a copy
>of it?
Heh! It's tough to write a gooey for an operating system that was
designed for hardware which essentially lacks graphics ability! <grin>
No, he didn't...not that I'm aware of. There were some third-party
shell programs, which allowed users to run programs or select functions
from a "menu," but they were, of course, text-based and mouseless.
Nope, no pointee-clickee gooeys with purty li'l pitchers. If you want
to use CP/M, you have to learn how to use the command line! :)
4 4
john r pierce
>Hello,
>
>Does anyone know if Gary Kildall ever wrote a GUI interface for his cp/m
>'OS'??? If so, what was it like, and where can I get a copy of it?
Gary didn't. Other folks at Digital Research (Gary's company) did
various things, including GSX-80 which was a Graphical runtime library
but not a system user interface or shell, GSX-86 (same thing on
CP/M-86 and PCDOS, and finally GEM which was a full shell, but ran on
PC-DOS.
-jrp
Nitro
> Does anyone know if Gary Kildall ever wrote a GUI interface for his cp/m
> 'OS'??? If so, what was it like, and where can I get a copy of it?
I do not know of any GUI system, but unlike other people saying that it is
impossible, that is NOT true. Valdocs used graphics for its word
processing, painting, drawing, graphs, etc. programs, so it is possible.
Please let me know by email if you do find one!
Jonathan Badger
"Nitro" <ve1drg!nitrog...@glinx.com> writes:
>I do not know of any GUI system, but unlike other people saying that it is
>impossible, that is NOT true. Valdocs used graphics for its word
>processing, painting, drawing, graphs, etc. programs, so it is possible.
The problem is that while a few computers such as the QX-10) had that could
run CP/M had graphics, the majority of CP/M machines did not. This was
not due to CP/M, but rather to the hardware it tended to run on.
But even given a CP/M machine with graphics, I doubt a GUI was ever
created because of memory problems. 8-bit CP/M systems could only
address 64k. A GUI would require more memory for just itself than
that. If you ever saw a 128k Mac you may remember just how little
memory was available to the user.
Allison Parent
There was GSX-80 and several other standards that were emergine at
that time. The diversity of hardware tended to discourage the
writers as there was no single hardware standard.
>But even given a CP/M machine with graphics, I doubt a GUI was ever
>created because of memory problems. 8-bit CP/M systems could only
>address 64k. A GUI would require more memory for just itself than
>that. If you ever saw a 128k Mac you may remember just how little
>memory was available to the user.
Actually the solution was to use a paged memory mapped display <PC do
this> and use the disk as a virtual file device. Most graphics are
not resident in main memory even on PCs from what I can discern.
Actually while researching a web crawler likel lynx I found that
graphics are not as limiting as the the size of the files. A download
of an interesting file could easily exceed the floppy space available
without graphics. ANY system doing graphics would have to have
serious disk space. Serious being
a version of CP/M <or clone> what could build 32mb files and address
logical disks in the 500mb range.
Allison
Billy D'Augustine
Jonathan Badger wrote:
>
> The problem is that while a few computers such as the QX-10) had that could
> run CP/M had graphics, the majority of CP/M machines did not. This was
> not due to CP/M, but rather to the hardware it tended to run on.
Most CP/M machines of the day were terminal based - you purchased a box
that had one or more RS-232 ports on it, and it was up to you to get
a suitable terminal.
Some systems, as the Epson mentioned, had graphical capabilities, but
those came above and beyond CP/M.
>
> But even given a CP/M machine with graphics, I doubt a GUI was ever
> created because of memory problems. 8-bit CP/M systems could only
> address 64k. A GUI would require more memory for just itself than
> that. If you ever saw a 128k Mac you may remember just how little
> memory was available to the user.
You know, I love when people justify the bloatedness of current OS's
with statements like this. Out of context.
Look at the Atari 520ST - that has 512k of RAM, an operating system,
and GUI and a load of system calls. It was and is still a usefull
system. Of course, the OS and everything was in ROM, so it took up
very little in terms of user RAM. But it's also a 16-bit system,
versus the 8-bit.
How about the Commodore 128 and GEOS? It may be slow as a dog,
but that's not due to the GUI, it's mostly due to memory management.
This system has 128k, in two 64k switched banks. Some of you may
remember GEOS, but for those who don't, they grew up to be GeoWorks,
originally Berkley Software (?). The system ran on a single 1571
disk drive (which was DSDD), and could take advantage of the
"RAM expansion unit", which added a forgotten number of kilobytes (
NOT MEGABYTES!) to the system.
My point is that it can be done, it has been done, and it will be
done again. Don't judge past accomplishments on current technology.
--
Billy D'Augustine
az...@worldnet.att.net
All is lost, none have won.
Jonathan Badger
Billy D'Augustine <az...@worldnet.att.net> writes:
>Jonathan Badger wrote:
>> But even given a CP/M machine with graphics, I doubt a GUI was ever
>> created because of memory problems. 8-bit CP/M systems could only
>> address 64k. A GUI would require more memory for just itself than
>> that. If you ever saw a 128k Mac you may remember just how little
>> memory was available to the user.
>You know, I love when people justify the bloatedness of current OS's
>with statements like this. Out of context.
>Look at the Atari 520ST - that has 512k of RAM, an operating system,
>and GUI and a load of system calls. [...]
>How about the Commodore 128 and GEOS? It may be slow as a dog,
>but that's not due to the GUI, it's mostly due to memory management.
>This system has 128k, in two 64k switched banks. [...]
>My point is that it can be done, it has been done, and it will be
>done again. Don't judge past accomplishments on current technology.
No offense, but I fail to see how what you are saying contradicts
anything I said. You point out a 512k and a 128k system as examples of
small GUI systems. CP/M machines didn't have 512k or 128k. They had
64k. I'm not even aware of any CP/M systems that had banked memory
like the C=128 [1] or Apple //e.
[1] Yes, the C=128 could run CP/M. But that was using its secondary
processor, a Z80. And in CP/M mode it couldn't use the upper 64k.
JWillard44
Well, I was going to stay out of this one, but the following comment
woke me up (you should "Let sleeping dogs lie").
> CP/M machines didn't have 512k or 128k. They had 64k.
> I'm not even aware of any CP/M systems that had
> banked memory
Many CP/M machines had banked memory. They ran what was called "Bank
Switched CP/M 3." However, there was little support for using anything
beyond the 64k. What happened was that the extra memory housed the
operating system routines and disk buffers, leaving around 62K TPA.
Morrow made a series of computers, starting with the MD-5 and going as
high as the MD-60. The number was the size in MBytes of the hard disk.
These had 128K memory with bank switched CP/M 3.0. The MD-11 was the most
common, and I had 5 of them at one time. I am now down to just 2.
A CP/M GUI is not practical. It would require a graphics capable
terminal and a very fast serial link between the computer and the
terminal. A possible alternative would be a standardized memory mapped
graphics terminal, such as some Kaypro systems had (have), but this
requires a large chunk of memory for activation. No one has set a
standard that could be used.
Of course, you could always get a $500 PC clones with VGA boards, add
a $200 vga monitor, and make it into a standardized terminal. Might be
real fun, but it would defeat the whole idea.
Will Rose
Jonathan Badger (bad...@phylo.life.uiuc.edu) wrote:
[...]
: No offense, but I fail to see how what you are saying contradicts
: anything I said. You point out a 512k and a 128k system as examples of
: 64k. I'm not even aware of any CP/M systems that had banked memory
There were a lot of of them - I think most CP/M 3.0 machines came
into this category, and so did the (2.2) QX-10. The general rule
seemed to be 4 x 64K banks, but eg. the Amstrads could use 512K.
However, by then MSDOS had become the standard.
Bruce R. McFarling
bad...@phylo.life.uiuc.edu (Jonathan Badger) wrote:
>No offense, but I fail to see how what you are saying contradicts
>anything I said. You point out a 512k and a 128k system as examples of
>small GUI systems. CP/M machines didn't have 512k or 128k. They had
>64k. I'm not even aware of any CP/M systems that had banked memory
>like the C=128 [1] or Apple //e.
I recall that it was becoming standard for CP/M boards
to include extra memory as RAMdisk, which is all that GEOS would
need. And current CP/M boards offer that in bunches, it seems
in my current look for a excuse to make a dedicated C64 IDE
server a CP/M board instead of a PC-DOS board.
Virtually,
Bruce R. McFarling, Newcastle, NSW
ec...@cc.newcastle.edu.au
Bruce R. McFarling
Billy D'Augustine <az...@worldnet.att.net> wrote:
>How about the Commodore 128 and GEOS? It may be slow as a dog,
>but that's not due to the GUI, it's mostly due to memory management.
> ...
And of course before that there was GEOS for the
Commodore 64, a 64K RAM machine. Not very enjoyable without
an REU (memory expansion), but the REU worked mostly like
a fast RamDISK, and C64 with GEOS and a modern hard drive
is OK without memory expansion.
Nope, memory bloat is in no small part commercially
drive logic rather than technological logic. (PhD in economics
hat on) remember that the largest revenues from *either*
operating systems or basic applications come from new machines
and upgraded hardware on old machines. So a software house
that can figure out a way to accelerate the upgrade / buy
new cycle at the same time they dominate the markets for
operating systems and base application on that new hardware
has found a way to make money. And we have a system where
finding a way to make money is its own reward (econ hat
back off).
On an entirely unrelated note, I've heard Gates
quoted as saying that he can bring any new hardware
released 'to its knees' in a year. Is that an accurate
quote?
Bruce R. McFarling
Also, as lynx and pine show, the important part of the
GUI interface in terms of ease of use is the point and
click part (I'm going to treat that bar of control key
commands on the bottom of pine as the equivalent of
GUI buttons). Which, as these programs show, you can get
very easily with just a standard terminal like a VT-100,
or with a standard library of full-screen character grid
functions.
It's only efficiency to go to the essence and
trim out the fluff. Even if efficiency doesn't always
put the most money in a company's pocket. 8-)#
john r pierce
>system. Of course, the OS and everything was in ROM, so it took up
>very little in terms of user RAM. But it's also a 16-bit system,
>versus the 8-bit.
Heh, yeah, look at the Atari ST.
It was running a highly modified version of CP/M-68K and GEM (both
from DRI). But this was a single program system. Most GUI's allow
concurrent operation of multiple applications but not GEM. GEM was
basically just a static graphics runtime library for a single
application.
-jrp
Bruce R. McFarling
pie...@scruznet.com (john r pierce) wrote:
>
>Heh, yeah, look at the Atari ST.
>
>It was running a highly modified version of CP/M-68K and GEM (both
>from DRI). But this was a single program system. Most GUI's allow
>concurrent operation of multiple applications but not GEM. GEM was
>basically just a static graphics runtime library for a single
>application.
What is the connection between whether the user
interface is graphical and allowing concurrent operation
of multiple applications? You could say X-windows "allows"
it, but it's Unix that allows it: you get it whether or
not you use the GUI. Amiga Desktop "allows it", but you
get it in CLI as well. Concurrent CP/M "allows it" but
is not necessarily GUI. 8-)# A windowed user interface
is one way to make a concurrent operation OS accessible,
but it could be a character grid window just as well
(such as the virtual tty terminals a function key
away in Linux).
rst...@iea.com
-In <badger.8...@phylo.life.uiuc.edu>, bad...@phylo.life.uiuc.edu (Jonathan Badger) writes:
->Billy D'Augustine <az...@worldnet.att.net> writes:
->
->>Jonathan Badger wrote:
-> (chop, chop, chop...)
->
->No offense, but I fail to see how what you are saying contradicts
->anything I said. You point out a 512k and a 128k system as examples of
->small GUI systems. CP/M machines didn't have 512k or 128k. They had
->64k. I'm not even aware of any CP/M systems that had banked memory
->like the C=128 [1] or Apple //e.
->
->[1] Yes, the C=128 could run CP/M. But that was using its secondary
->processor, a Z80. And in CP/M mode it couldn't use the upper 64k.
I have a Compupro S-100 CP/M system with a couple 32K cards that have DIP's for
24 bit extended addrssing via bank switching. Though I've never seen any
software that uses this feature.
Alan Cox
In article <4rcr8k$p...@seagoon.newcastle.edu.au>,
Bruce R. McFarling <ec...@cc.newcastle.edu.au> wrote:
>>concurrent operation of multiple applications but not GEM. GEM was
>>basically just a static graphics runtime library for a single
>>application.
> What is the connection between whether the user
>interface is graphical and allowing concurrent operation
>of multiple applications? You could say X-windows "allows"
>it, but it's Unix that allows it: you get it whether or
In the case of GEM , GEM is not re-entrant, I know I tried calling some
Gem routines to plot a graph from an interrupt handler once. Gem is also
very oriented to having a single drawing surface exposed at the front. If
you make sure nobody is re-entering GEM (in effect spinlock GEM and wrap
stuff around blocking input calls to do nonblocking ones) then you can
multitask GEM sort of. GEM also supported "desk accessories" in some
versions which were effectively the equivalent of a DOS TSR given GUI
status.
Alan
--
--------------------------------.----------------------------------------------
UKUU free UUCP Project Swansea | Alan Cox, <alan...@linux.org>
+44 1792 422028 (Cabletel) | Custom Linux Software Projects.
Sonix 28.8K [33.6 soon] 24x7 | Linux Consultancy.
john r pierce
rst...@iea.com wrote:
Um, CP/M-86 with a 8088 or 8086 card (both made by Compupro amlong
others) could use as much ram as you cared to throw at it up to the
1MB limit of those CPU's...
MP/M-80 normally ran in a configuration with typically 2 or more
(often 4) 48K banked ram plus 16K fixed 'system' memory.
-jrp
john r pierce
"Bruce R. McFarling" <ec...@cc.newcastle.edu.au> wrote:
>pie...@scruznet.com (john r pierce) wrote:
>>
>>Heh, yeah, look at the Atari ST.
>>
>>It was running a highly modified version of CP/M-68K and GEM (both
>>from DRI). But this was a single program system. Most GUI's allow
>>concurrent operation of multiple applications but not GEM. GEM was
>>basically just a static graphics runtime library for a single
>>application.
>
> What is the connection between whether the user
>interface is graphical and allowing concurrent operation
>of multiple applications? You could say X-windows "allows"
>it, but it's Unix that allows it: you get it whether or
>not you use the GUI. Amiga Desktop "allows it", but you
>get it in CLI as well. Concurrent CP/M "allows it" but
>is not necessarily GUI. 8-)# A windowed user interface
>is one way to make a concurrent operation OS accessible,
>but it could be a character grid window just as well
>(such as the virtual tty terminals a function key
>away in Linux).
True enuf. Even the MAC OS was basically a single tasking system
until recently... (yes, it allowed some background operations like
spooling but you couldn't run more than one main application at once
until the advent of 'multifinder')
-jrp
kl...@rand.nidlink.com
On Wed, 03 Jul 1996 pierce said:
>Um, CP/M-86 with a 8088 or 8086 card (both made by Compupro along
>others) could use as much ram as you cared to throw at it up to the
>1MB limit of those CPU's...
In all fairness, though, CP/M-86 is a totally different animal from
CP/M-80. Yes, it has a look-and-feel that's similar to CP/M-80, but
that's about where the similarity ends...especially when running the
IBM version of CP/M-86. They're two entirely different platforms.
And, of course, the software is not compatible between the two.
One conceivably =could= write an honest-to-goodness gooey for the IBM
permutation of CP/M-86 -- complete with high-res color VGA graphics,
li'l "purty pitcher" icons, and a pointee-clickee mouse. Question is,
WHY would anybody want to =do= that?! <grin>
0 5
John Elliott
In article <4rg468$i...@faile.nidlink.com>, kl...@rand.nidlink.com wrote:
: On Wed, 03 Jul 1996 pierce said:
: One conceivably =could= write an honest-to-goodness gooey for the IBM
: permutation of CP/M-86 -- complete with high-res color VGA graphics,
: li'l "purty pitcher" icons, and a pointee-clickee mouse. Question is,
: WHY would anybody want to =do= that?! <grin>
GEM runs nicely atop DOSPLUS (CP/M 86 v4.1) :-)
-------------------- http://users.ox.ac.uk/~sjoh0132/ ---------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
Holger Petersen
kl...@rand.nidlink.com writes:
>On Fri, 28 Jun 1996 damonv said:
> >Does anyone know if Gary Kildall ever wrote a GUI interface for his
> >cp/m 'OS'??? If so, what was it like, and where can I get a copy
> >of it?
>Heh! It's tough to write a gooey for an operating system that was
>designed for hardware which essentially lacks graphics ability! <grin>
>No, he didn't...not that I'm aware of.
BUT:
1) There was 'GSX' from Digital Research; a supposedly general
Graphic API. This was for CP/M-80 and CP/M-86.
2) And the GEM was available not only on ATARI's but on IBP PC's
as well. [probably not on CP/M for the 8080/Z80]
Greetings, Holger
Holger Petersen
alli...@world.std.com (Allison Parent) writes:
>ANY system doing graphics would have to have
>serious disk space. Serious being
>a version of CP/M <or clone> what could build 32mb files and address
>logical disks in the 500mb range.
CP/M 2.2 could use _Disk-Space_ up to 512 Megabyte's. This was much
better than MS/DOS up to Version 3.3, but I believe that noone had
that much money to try that large Harddisks...
For _File-Sizes_ above 512 Kilobyte's you had to do some special things.
In one of the CP/M-UG - Disks there was a PIP-patch from Robert Valzah(sp?)
Even knowin this, I ran into the same problems with Wordmaster, WordStar
and Supersort [all from MicroPro] when working on a large ( 1.2 Megabyte)
adress-list.
Greetings, Holger
john r pierce
ell...@teaching.physics.ox.ac.uk (John Elliott) wrote:
>In article <4rg468$i...@faile.nidlink.com>, kl...@rand.nidlink.com wrote:
>
>: On Wed, 03 Jul 1996 pierce said:
>
>: One conceivably =could= write an honest-to-goodness gooey for the IBM
>: permutation of CP/M-86 -- complete with high-res color VGA graphics,
>: li'l "purty pitcher" icons, and a pointee-clickee mouse. Question is,
>: WHY would anybody want to =do= that?! <grin>
>
> GEM runs nicely atop DOSPLUS (CP/M 86 v4.1) :-)
Um, none of those are my comments... someone mis-chopped the
attributions again...
-jrp
Billy D'Augustine
alli...@world.std.com (Allison Parent) writes:
>
>ANY system doing graphics would have to have
>serious disk space. Serious being
>a version of CP/M <or clone> what could build 32mb files and address
>logical disks in the 500mb range.
Again, yet another comparision out of context: current GUI systems are
disk hogs. Again, I bring up Atari ST and GEM: the standard Atari 520ST
ran GEM (Graphical Environment Manager?) on a 512k system, no hard drive
and a single 720k 3.5" floppy.
There were also Atari 260ST's, but these had (guess?) 256k of RAM.
john r pierce
h...@kbbs.org (Holger Petersen) wrote:
>kl...@rand.nidlink.com writes:
>>On Fri, 28 Jun 1996 damonv said:
>> >Does anyone know if Gary Kildall ever wrote a GUI interface for his
>> >cp/m 'OS'??? If so, what was it like, and where can I get a copy
>> >of it?
>>Heh! It's tough to write a gooey for an operating system that was
>>designed for hardware which essentially lacks graphics ability! <grin>
>>No, he didn't...not that I'm aware of.
>BUT:
>1) There was 'GSX' from Digital Research; a supposedly general
> Graphic API. This was for CP/M-80 and CP/M-86.
GSX wasn't a GUI, it was a graphics API. The only apps I can think of
that ran under GSX were things like Graph (bar and pie charting), Draw
(general drawing, rather crude), and Presentation Master (a lame early
attempt at 'presentation' graphics, i.e. slides for business
presentations). But no 'GUI' in the sense of a shell replacement.
>
>2) And the GEM was available not only on ATARI's but on IBP PC's
> as well. [probably not on CP/M for the 8080/Z80]
Yeah, GEM mostly ran on PCDOS (although I guess there were CP/M-86
versions too).
-jrp
john r pierce
h...@kbbs.org (Holger Petersen) wrote:
>alli...@world.std.com (Allison Parent) writes:
>
>>ANY system doing graphics would have to have
>>serious disk space. Serious being
>>a version of CP/M <or clone> what could build 32mb files and address
>>logical disks in the 500mb range.
>
>CP/M 2.2 could use _Disk-Space_ up to 512 Megabyte's. This was much
>better than MS/DOS up to Version 3.3, but I believe that noone had
>that much money to try that large Harddisks...
That would have been pretty brutal since all versions of true CP/M
that I can remember had 8 bit cluster numbers... lets see... 2MB per
allocation unit? hmm. I don't _think_ so.
In fact, if I remember correctly, CP/M 2.2 could deal with up to 32MB
max per drive... dealing with a really large disk required a custom
partitioning scheme in the BIOS...
>For _File-Sizes_ above 512 Kilobyte's you had to do some special things.
>In one of the CP/M-UG - Disks there was a PIP-patch from Robert Valzah(sp?)
>Even knowin this, I ran into the same problems with Wordmaster, WordStar
>and Supersort [all from MicroPro] when working on a large ( 1.2 Megabyte)
>adress-list.
-jrp
Matthew Phillips
On Fri, 5 Jul 1996, john r pierce wrote:
> h...@kbbs.org (Holger Petersen) wrote:
>
> >alli...@world.std.com (Allison Parent) writes:
> >
> >>ANY system doing graphics would have to have
> >>serious disk space. Serious being
> >>a version of CP/M <or clone> what could build 32mb files and address
> >>logical disks in the 500mb range.
> >
> >CP/M 2.2 could use _Disk-Space_ up to 512 Megabyte's. This was much
> >better than MS/DOS up to Version 3.3, but I believe that noone had
> >that much money to try that large Harddisks...
>
> That would have been pretty brutal since all versions of true CP/M
> that I can remember had 8 bit cluster numbers... lets see... 2MB per
> allocation unit? hmm. I don't _think_ so.
If DSM (no. of clusters per disc) is greater than 255, the cluster numbers
go 16 bit. The clusters can go pretty big, but the limiting factor is
that the number of 128-byte records has to be stored. See John Elliott's
WWW pages for the details. I can't remember them offhand.
Matthew Phillips
---------------------------------------------------------
WACCI on WWW - http://users.ox.ac.uk/~chri0264/wowww.html
The UK's only monthly CPC magazine
The UK's biggest CPC user club
---------------------------------------------------------
Holger Petersen
pie...@scruznet.com (john r pierce) writes:
>h...@kbbs.org (Holger Petersen) wrote:
>>CP/M 2.2 could use _Disk-Space_ up to 512 Megabyte's. This was much
^^^^^
My fault!
This was/is true 'only' for CP/M Version 3.
>>better than MS/DOS up to Version 3.3, but I believe that noone had
>>that much money to try that large Harddisks...
>That would have been pretty brutal since all versions of true CP/M
The 'CP/M 3 System Guide' [dated 1982] says on page 11:
"up to sixteen disk drives of up to 512 Megabytes capacity each"
Apologies, Holger
Peter Kocourek
john r pierce <pie...@scruznet.com> wrote:
> True enuf. Even the MAC OS was basically a single tasking system
> until recently... (yes, it allowed some background operations like
> spooling but you couldn't run more than one main application at once
> until the advent of 'multifinder')
It depends on how you definite "recently." ;-) MultiFinder has been
around since, I think, 1989 or possibly 1988.
Peter.
Bruce R. McFarling
Oh, I think on comp.os.cpm we can define 1989 as recently.
8-)#
--
James Alexander
In a previous article, pie...@scruznet.com (john r pierce) says:
>Damon Vandehey <dam...@sycrci.pcc.edu> wrote:
>
>>Hello,
>>
>>Does anyone know if Gary Kildall ever wrote a GUI interface for his cp/m
>>'OS'??? If so, what was it like, and where can I get a copy of it?
>
>Gary didn't. Other folks at Digital Research (Gary's company) did
>various things, including GSX-80 which was a Graphical runtime library
>but not a system user interface or shell, GSX-86 (same thing on
>CP/M-86 and PCDOS, and finally GEM which was a full shell, but ran on
>PC-DOS.
>
>-jrp
>
Gem also made it to the Atari ST computers. It was a bit of an irony as
the back end of the ST OS was referred to as CP/M-68K by some users and
that someone managed to pull off a reasobly stable CPM emulator on these
machines. I never did see GEM on a cpm machine proper but I know the
pc-dos version died too early due to unrelenting pressure from Apple
(during the Scully regime). Oddly Apple never tried pushing Atari around
on the same issue although they easily could have.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
James Alexander: SF, Fantasy, Rpg, Slot Car, & Atari computers Hobbyist
RONIN DESIGN WORKS: An OMEn-UOS Software Developer
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Allison Parent
h...@kbbs.org (Holger Petersen) wrote:
>CP/M 2.2 could use _Disk-Space_ up to 512 Megabyte's. This was much
>that much money to try that large Harddisks...
>For _File-Sizes_ above 512 Kilobyte's you had to do some special things.
>In one of the CP/M-UG - Disks there was a PIP-patch from Robert Valzah(sp?)
>Even knowin this, I ran into the same problems with Wordmaster, WordStar
>and Supersort [all from MicroPro] when working on a large ( 1.2 Megabyte)
>adress-list.
Holger,
CP/M 2.2 was limited to logical disks of 8mb (128<byte
sectors>x65536<largest possible number of sectors>.
Files were more limited as it is possible to have a disk of
8mb but only set for 128 directory entries. If the allocation block
size is 4k you can only have a 1 file <4kx8x128=4mb> as it will
use all of the directory entries and fill the logical disk while using
only half the available space. Many programs got into trouble when
the allocation block sizre was too small and the number of directory
entries were too few.
This stuff is never explained in any docs I've seen save for a criptic
comment.
As to large disks under CP/M 2.2 I found it was easy to describe a
disk over 8m using the formulas given for the disk parameter headers
but to use it was another issue. An example is you could use an
allocation block size of 8k and have 65536 allocation blocks which
is 512m. It is resonable to even use 16k allocation blocks which get
you to a full 1024k. To use that it would also require 32768
directory entries! The largest file would still only be 8mb.
In the case of a resonable CP/M disk say 128mb. I'd use a 8k
allocation block for it which is large. Now here is the bomb...
128m/8k=16384 allocation bits or 2kbytes of allcation bits.
This would not require directory check bits. This is 2k of space
right off the top of the system. Add to this the host buffer for
deblocking 512byte is typical and space is leaving fast. Also
the disk to use it fully would require space 2048 directory entries.
performance will be very slow for any operation that reads or write
the directory.
With all the gryrations you still cannot make a file larger than 8mb.
Added to that many directory tools and pip will not work right.
Now for graphics work a file of 8mb is adaquate most of the time
but the performance as I've pointed out will be poor unless your
runninng a z180 at something faster than 8mhz.
Allison
Allison Parent
Billy D'Augustine <az...@worldnet.att.net> wrote:
>Again, yet another comparision out of context: current GUI systems are
>disk hogs. Again, I bring up Atari ST and GEM: the standard Atari 520ST
>ran GEM (Graphical Environment Manager?) on a 512k system, no hard drive
>and a single 720k 3.5" floppy.
Billy,
First off your out of context as I never said the GUI system itself
was large or small. I stated that downloaded files common to
WWW and FTP transfers can be quite larger and there are disk issues
that CP/M presents.
I find it interesting that an atari running a different cpu and os
would be in context.
Allison
Allison Parent
pie...@scruznet.com (john r pierce) wrote:
>That would have been pretty brutal since all versions of true CP/M
>that I can remember had 8 bit cluster numbers... lets see... 2MB per
>allocation unit? hmm. I don't _think_ so.
I have the book here.. and it's 8bit allocation number for smaller
disks with bsh of 3, and the next higher bsh forces 16bit allocation
vectors. So with an allocation block of 16k and 65536 as the max
block number you can address 1gig. The largest file is still only 8mb
though.
>In fact, if I remember correctly, CP/M 2.2 could deal with up to 32MB
>max per drive... dealing with a really large disk required a custom
>partitioning scheme in the BIOS...
Artificial boundary caused by the host controllers of the time used
for hard drives <xybec, adaptek et al>. The teltek s100 controller
would address some big drives and I did use it with 150mb units with
little troble with the controller. The cavat was the software still
wanted to limit me to 8mb per logical drive!
Allison
>>For _File-Sizes_ above 512 Kilobyte's you had to do some special things.
>>In one of the CP/M-UG - Disks there was a PIP-patch from Robert Valzah(sp?)
>>Even knowin this, I ran into the same problems with Wordmaster, WordStar
>>and Supersort [all from MicroPro] when working on a large ( 1.2 Megabyte)
>>adress-list.
>-jrp
azog
alli...@world.std.com (Allison Parent) wrote:
I am replying to the message that started off:
>ANY system doing graphics would have to have
>serious disk space
Since this is such an absolute ("any"), taking a
different hardware/software system into context is
quite acceptable, since the absolute statement applies
to this as well.
----
john r pierce
alli...@world.std.com (Allison Parent) wrote:
>pie...@scruznet.com (john r pierce) wrote:
>
>>That would have been pretty brutal since all versions of true CP/M
>>that I can remember had 8 bit cluster numbers... lets see... 2MB per
>>allocation unit? hmm. I don't _think_ so.
>
>I have the book here.. and it's 8bit allocation number for smaller
>disks with bsh of 3, and the next higher bsh forces 16bit allocation
>vectors. So with an allocation block of 16k and 65536 as the max
>block number you can address 1gig. The largest file is still only 8mb
>though.
Arghh. I keep forgetting about CP/M 3 (and I DESIGNED the enhanced
'modular' BIOS for it!!!) Sorry. I should keep my mouth shut instead
of inserting my size 11-EE shoes into it.
Still any of these are better than the first CP/M hard disk system I
brought up, a Pertec 5+5MB 14" platter-plopper under CP/M 1.4... Since
1.4 could only deal with 4 logical drives of 1MB max each, I chopped
each platter into 5 logical partions, 0-9 and had a 'MAP' command to
assign 'logical drives' A:, B:, C:, D: to any combination of floppies
A, B, or HD partitions 0-9... It was actually quite workable,
considering the hardware and software limitations in effect circa
1978.
-jrp
Allison Parent
pie...@scruznet.com (john r pierce) wrote:
>Arghh. I keep forgetting about CP/M 3 (and I DESIGNED the enhanced
>'modular' BIOS for it!!!) Sorry. I should keep my mouth shut instead
>of inserting my size 11-EE shoes into it.
Err Uhm John,
That was for CP/M 2.2 right out of the book.
Allison
Allison Parent
az...@worldnet.att.net (azog) wrote:
>I am replying to the message that started off:
Forgive me everyone but the sentence was in the middle of a paragraph
and didn't "start off".
>>ANY system doing graphics would have to have
>>serious disk space
>Since this is such an absolute ("any"), taking a
>different hardware/software system into context is
>quite acceptable, since the absolute statement applies
>to this as well.
This is com.os.cpm so we are inside of double context.
What was posted:
<Actually while researching a web crawler likel lynx I found that
<graphics are not as limiting as the the size of the files. A
<download of an interesting file could easily exceed the floppy
< space available without graphics. ANY system doing graphics
<would have to have serious disk space. Serious being
<a version of CP/M <or clone> what could build 32mb files and
<address logical disks in the 500mb range.
Ok, if you wish to play sematic games I included the full context. If
your going to cut a sentence out of a paragraph you will create your
own context and it may not necessarily be the context I set down. At
that point your assumptions cease to match the ones I set down.
The comment was that resulting files could be more problematic for
size or the quantity then the actual GUI. That implies that they
could be graphic but text or other binaries are as likely. The simple
matter of case is the typical CP/M system without hard disk is hard
put to have even 720k floppies. With 360k of floppies even a GUI
system of say 128k <this is a large number but the point is the same
even at 32k> is not the problem as it could run in overlays. The real
problem is a bunch of JPGS, TXT, GIFs and a FTP or two could easily
fill the disk. To a CP/M system user a system with 10mb of disk is a
very serious system as many did not have or it was an expensive
option. The other half of the comment was that CP/M itself <common
version is 2.2> can only create a file of 8mb max. Physical drives of
greater than that are generally partitioned into 8mb or smaller
logical drives. FYI: that partition limit is not inherent in CP/M
itself but generally done, most controllers of the period <80-86ish>
would limit the physical drive to 32mb. I have the later problem in a
SB180 using a xybec host controller.
Allison
bill_h
Wait a minute, Allison.......
Aren't you assuming images of 8 or more bits? And if so, why?
You COULD do a bit-mapped system of ONE-bits in the 'typical'
space available to old systems.....
I never spent much time with GEM, other than installing it on
a few systems, but wasn't that using one-bit graphics?
kl...@rand.nidlink.com
On Sun, 7 Jul 1996 allisonp said:
>...The real problem is a bunch of JPGS, TXT, GIFs and a FTP
>or two could easily fill the disk. To a CP/M system user a system
>with 10mb of disk is a very serious system as many did not have or
>it was an expensive option...
In reality, though, how likely is a CP/M 2.2 user to download such
stuff from the 'Net, or anywhere else? Pragmatically, I'll bet the
chances are just about nil. I've never seen a GIF or JPEG viewer
for CP/M...and with good reason: such files could never be displayed
on any but the most odd-ball and esoteric CP/M system.
A typical CP/M user's downloads would most likely be restricted to
text and binary files relating to, or runnable on, a CP/M box...and
such files are almost always small enough in size to fit on even
a single-sided floppy disk. Or so it seems to me. :)
1 0
john r pierce
bill_h <bil...@azstarnet.com> wrote:
Um, the gem I remember normally ran in 16 color mode although it could
use monochrome.
-jrp
Ken
Jonathan Badger <bad...@phylo.life.uiuc.edu> writes:
>But even given a CP/M machine with graphics, I doubt a GUI was ever
>created because of memory problems. 8-bit CP/M systems could only
>address 64k. A GUI would require more memory for just itself than
It is possible to run a GUI on a 64K 8-bit computer, for example GEOS on a
C-64. I don't care for it myself, but some people swear by it. GUIs are good
for some things, like looking at an entire file structure tree all at once
instead of having to cd all over the place, but for the most part it's a lot
more fun to operate from the command line, at least for me. As far as CP/M,
I'd rather have a Z-System that was self-booting (not needing to boot CP/M
first) than a GUI. Is there a way to do that?
Ken
glo...@delphi.com
Allison Parent
bill_h <bil...@azstarnet.com> wrote:
>Wait a minute, Allison.......
>Aren't you assuming images of 8 or more bits? And if so, why?
I was assuming the images imported would be the larger bit wise.
There is nothing to stop reducing them to mono.
>You COULD do a bit-mapped system of ONE-bits in the 'typical'
>space available to old systems.....
Some use 4 planes of one bit... fairly common.
>I never spent much time with GEM, other than installing it on
>a few systems, but wasn't that using one-bit graphics?
None at all here.
Allison
Chuck Erickson
I have a GIF viewer for the Epson QX-10. Although, it's pretty
slow; and I probably wouldn't want to use it to view while
online. I believe there are other viewers written for other
machines as well. I also can manipulate graphics with Valdoc's
Paint or Draw modules. So it's not as "odd-ball" as you might
think.
Regards, Chuck
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chuck Erickson | Win-dy City Windows(tm) 1-708-595-1894
Sysop | Chicago's First Excalibur BBS!
8 bits forever | InterNet Address: sy...@wincity.com
Tom Stepleton
kl...@rand.nidlink.com wrote:
>
> On Sun, 7 Jul 1996 allisonp said:
>
> >...The real problem is a bunch of JPGS, TXT, GIFs and a FTP
> >or two could easily fill the disk. To a CP/M system user a system
> >with 10mb of disk is a very serious system as many did not have or
> >it was an expensive option...
>
> for CP/M...and with good reason: such files could never be displayed
> on any but the most odd-ball and esoteric CP/M system.
Epson's FTP site features something called valgif as an addition to
valdocs on a qx-10/16... I know, it's TPM, but... you're right
that gif-capable systems are rare and so is the chance that many
CP/M users would want it, however...
Never tried valgif myself... I read the Readme, though :)
--Tom
+-----------+---------------------------+ ____
| Stepleton | sste...@artsci.wustl.edu |>----|\__\_\__
+-----------+---------------------------+ \_______}
Alan Cox
In article <4rp2hj$s...@faile.nidlink.com>, <kl...@rand.nidlink.com> wrote:
>stuff from the 'Net, or anywhere else? Pragmatically, I'll bet the
>for CP/M...and with good reason: such files could never be displayed
>on any but the most odd-ball and esoteric CP/M system.
I have a (somewhat broken) XPM viewer for the the PX/4. Unfortunately I
can't get it to handle the scrolling region stuff right and the docs appear
wrong in the technical manuals (finding the view screen start address).
Alan
--
Send unsolicited junk mail to this address and maybe win the chance to have
yourself added free to several hundred random mailing lists. ,---------------
------------------------------------------------------------/ Alan Cox
This signature comes with a free redistribution license / al...@cymru.net
kl...@rand.nidlink.com
On Tue, 09 Jul 1996 sysop said:
>I have a GIF viewer for the Epson QX-10. Although, it's pretty
>slow; and I probably wouldn't want to use it to view while
>online. I believe there are other viewers written for other
>machines as well. I also can manipulate graphics with Valdoc's
>Paint or Draw modules. So it's not as "odd-ball" as you might
>think.
Well, yeah, it =is,= Chuck! :)
The Epson QX-10 is precisely one of those "odd-ball" machines I was
referring to in my previous post. Its graphics capabilities are
totally UNtypical of the average CP/M box. The QX-10 never enjoyed
the widespread success of, say, a Kaypro or an Osborne; it was never
a "mainstream" machine...which makes it, relatively speaking, "odd-
ball." I don't mean that in a pejorative sense; only as a descriptive
term.
My point was that the most prevalent "mainstream" CP/M machines -- such
as the Kaypro or the Osborne -- don't =have= graphics-mode capability,
and therefore will never be able to display graphics files.
0 4
Jeff_Wieland
In article <4rulh5$g...@faile.nidlink.com> kl...@rand.nidlink.com writes:
>My point was that the most prevalent "mainstream" CP/M machines -- such
>as the Kaypro or the Osborne -- don't =have= graphics-mode capability,
>and therefore will never be able to display graphics files.
>
> 0 4
Not to labor a point, but many Kaypros did have graphics. All of the
'10's and the '84's could display 160x100 graphics. There are ESC
sequences to plot and erase points and lines. There were even a few
packages that used these graphics, like SCS-Draw. Has anyone out
there ever used SCS-Draw??
Of course, if your Kaypro has a MicroSphere Color Graphics board
(mine does), then you have some greater possibilities...
--
Jeff Wieland
Jeff_W...@acn.purdue.edu
Paul Hunt
c...@cts.com (Will Rose) wrote:
>Jonathan Badger (bad...@phylo.life.uiuc.edu) wrote:
>[...]
>: No offense, but I fail to see how what you are saying contradicts
>: anything I said. You point out a 512k and a 128k system as examples of
>: small GUI systems. CP/M machines didn't have 512k or 128k. They had
>: 64k. I'm not even aware of any CP/M systems that had banked memory
>: like the C=128 [1] or Apple //e.
>There were a lot of of them - I think most CP/M 3.0 machines came
>into this category, and so did the (2.2) QX-10. The general rule
>seemed to be 4 x 64K banks, but eg. the Amstrads could use 512K.
>However, by then MSDOS had become the standard.
My Amstrad PCW has 1.5Mb RAM, mostly used as RAM disk, but could be
used for other purposes with sneaky programming.
Paul.
kl...@rand.nidlink.com
On 9 Jul 1996 Jeff_Wieland(Jeff_Wieland) said:
>Not to labor a point, but many Kaypros did have graphics. All of
>the '10's and the '84's could display 160x100 graphics. There are
>ESC sequences to plot and erase points and lines...
However, they weren't "graphics" in the contemporary IBM-style sense...
and one would be hard-pressed to display even a minimal B&W .GIF file
using such "graphics." In fact, I doubt it would be feasible. Not
totally impossible, perhaps, but certainly not feasible.
>Of course, if your Kaypro has a MicroSphere Color Graphics board
>(mine does), then you have some greater possibilities...
Again, that would have to fall into the category of "odd-ball" hardware.
It wasn't prevalent, and there's almost no freeware out there which
supports it.
All of which is perfectly okay. My original premise was, who in
Sam Hill would =want= a gooey on a CP/M machine anyway?! If one
feels inadequate using the command line, one could certainly use
a text-mode menu program to "launch" applications. But a purty-
li'l-pitchers gooey? Nah! :)
The reason I so intensely dislike the Gill Bates' "vision of the
computing future" as manifested in Micro$loth's WIN-DOZE 95 is
that it represents a fundamental change in the underlying philos-
ophy upon which the micro-computer was built: that of a relatively
easy-to-use, =command line driven= machine.
Once one allows onesself to be locked into a proprietary 'DOZE API,
one loses a =lot= of technical and aesthetic freedoms...both as a
programmer, and as a user. WIN-DOZE 95 is the computer equivalent
of electing Bubba Clinton and his socialist/collectivist minions
to run Duh Guvvermint of the U.S.: they want to change the funda-
mental, underlying philosophy. Personally, I don't want a mile-high
layer of resource-hogging gooey bloatware between me and the machine.
6 7
Alan Cox
In article <4rulh5$g...@faile.nidlink.com>, <kl...@rand.nidlink.com> wrote:
>The Epson QX-10 is precisely one of those "odd-ball" machines I was
>referring to in my previous post. Its graphics capabilities are
>totally UNtypical of the average CP/M box. The QX-10 never enjoyed
The PX-4 that followed it and PX-4 defintiely were not oddball machines
in fact the place is full of them ;)
Peter Kocourek
bill_h <bil...@azstarnet.com> wrote:
> Wait a minute, Allison.......
>
> Aren't you assuming images of 8 or more bits? And if so, why?
>
> You COULD do a bit-mapped system of ONE-bits in the 'typical'
> space available to old systems.....
>
> I never spent much time with GEM, other than installing it on
> a few systems, but wasn't that using one-bit graphics?
I think GEM (or rather VDI, the part of GEM responsible for drawing
graphics) could go up to 256 colors. Although I seem to remember from
the Atari ST implementation that there were some serious problems with
the way 8-bit color was handled. It's been a long, long time ago... ;-)
Peter.
(Trying to find his ST programming books)
Peter Kocourek
<kl...@rand.nidlink.com> wrote:
> My point was that the most prevalent "mainstream" CP/M machines -- such
> as the Kaypro or the Osborne -- don't =have= graphics-mode capability,
> and therefore will never be able to display graphics files.
My Kaypro 10 does have a graphics mode. I suppose it should be possible
to view GIFs with a bit of dithering... although the viewable area of
100 by 160 pixels might be a bit cramped.
I wouldn't know about earlier Kaypro models, though.
Peter.
Peter Kocourek
Jeff_Wieland <Jeff_Wieland> wrote:
> Of course, if your Kaypro has a MicroSphere Color Graphics board
> (mine does), then you have some greater possibilities...
Color graphics? Wow. Were there any programs that made use of this?
Many of them?
Color graphics on CP/M. Wow. :-)
Peter.
Simon Coombs
In article <4rvhuf$3...@faile.nidlink.com>, kl...@rand.nidlink.com writes
<snippage>
>All of which is perfectly okay. My original premise was, who in
>Sam Hill would =want= a gooey on a CP/M machine anyway?! If one
>feels inadequate using the command line, one could certainly use
>a text-mode menu program to "launch" applications. But a purty-
>li'l-pitchers gooey? Nah! :)
Nevertheless, there was one for the Amstrad PCW... It was by Advanced
Memory systems and came bundled with an AMX mouse. It basically gave you
a directory of whichever drive you wanted and attempted to launch
whatever you selected.. It did have a few nice touches, like
automatically loading basic if you clicked on a file with a '.bas'
extension, and a built in address database and memo pad, but little else
to recommend it... It ran ok in 256k, but was happier in 512k... Very
slow.
>The reason I so intensely dislike the Gill Bates' "vision of the
>computing future" as manifested in Micro$loth's WIN-DOZE 95 is
>that it represents a fundamental change in the underlying philos-
>ophy upon which the micro-computer was built: that of a relatively
>easy-to-use, =command line driven= machine.
>
>Once one allows onesself to be locked into a proprietary 'DOZE API,
>one loses a =lot= of technical and aesthetic freedoms...both as a
>programmer, and as a user. WIN-DOZE 95 is the computer equivalent
>of electing Bubba Clinton and his socialist/collectivist minions
>to run Duh Guvvermint of the U.S.: they want to change the funda-
>mental, underlying philosophy. Personally, I don't want a mile-high
>layer of resource-hogging gooey bloatware between me and the machine.
>
> 6 7
>
I feel inclined to agree.. only the other day I was talking to a
colleague at work who never really leaves whinedoze; it did worry me
slightly when he said "Oh yeah, I used to know loads of the dos
commands.. um.. D I R - that was one, wasn't it?".
I suppose we will end up with a generation that thinks that a Dos prompt
is some sort of error message. (Then again, when it comes to Dos there
are some people who are of the opinion that the whole O/S is an error!)
-------------------------------------------------------------
Simon Coombs si...@nenevr.demon.co.uk
15 points to anyone who's heard of a Transdata Cx500!
Alan Cox
In article <1...@wincity.wincity.com>,
Chuck Erickson <sy...@wincity.wincity.com> wrote:
>I have a GIF viewer for the Epson QX-10. Although, it's pretty
>slow; and I probably wouldn't want to use it to view while
>online. I believe there are other viewers written for other
>machines as well. I also can manipulate graphics with Valdoc's
Sorry to turn this into a useful thread but assuming the PX-4 and QX-10 use
the same logic for finding the top of the bitmapped display can you tell
me what the GIF viewer is using.
Alan
--
--------------------------------.----------------------------------------------
UKUU free UUCP Project Swansea | Alan Cox, <alan...@linux.org>
+44 1792 422028 (Cabletel) | Custom Linux Software Projects.
Sonix 33.6K 24x7 | Linux Consultancy.
john r pierce
pe...@duttnxc.tn.tudelft.nl (Peter Kocourek) wrote:
Actually, I remember bringing up a S100 graphics board on a IMSAI 8080
(no, the board wasn't a imsai board) circa 1978 that was capable of
putting out NTSC composite color (which was modulated via 640x240 1
bit-per-pixel data ala apple ][ hires mode...) We mostly played with
this board on monochrome... I believe the board was called a Merlin or
some such... It was DMA based, and VERY flakey (actually used 8 or
16K of main memory as the frame buffer...)
-jrp
Allison Parent
Everyone seems to have forgotten cromemeco dazzler color graphics
display. This was circa, 1976.
Allison
john r pierce
alli...@world.std.com (Allison Parent) wrote:
>Everyone seems to have forgotten cromemeco dazzler color graphics
>display. This was circa, 1976.
Phhewww. I _do_ rememeber those... I remember spending LONG cold
nites in a unheated shed one winter (musta been 76) trying to get one
working in my friends TDL Z80 system... of course, the only offline
storage he had was a ASR33 TTY and a very flakey casette recorder
setup... :) This was pre-CP/M for his machine (and me).
Shawn Sijnstra
Just to keep on the line of CP/M machines with colour capability....
try the IFS800. Came with either b/w, 8 shades greyscale or 8 colours
depending on which cards you had installed.
Shawn
Christoph Vogelsang
In 1983 I had a CP/M machine, a Sharp MZ-3541 (don=B4t know what
its name was outside of Europe). It had 128 KB RAM, 2 Z80A-CPUs (1 for =
I/O) and NEC 7220 graphics chip. It supported graphics up to 640*400
with 8 colors. Nice machine, though not very popular.
Nevertheless I don=B4t think a GUI is desirable for a machine like this. =
Memory and I/O performance were too slow, and handling of large
memory blocks is too complicated on CP/M-machines.
To my mind the problem is similar to the 640K problem on DOS machines.
Of course there are many concepts of dealing with this, such as
XMS, EMS, ... But these solutions are quite complicated in comparison
to a modern OS with a large linear address space.
;-)
Christoph
-- =
+---------------------------------------------------------------+
Dipl.-Kfm. Christoph Vogelsang 21c...@wiwi.uni-muenster.de =
Institut fuer Kreditwesen =
Westfaelische Wilhelms-Universitaet Muenster =
Universitaetsstrasse 14-16 48143 Muenster =
Telefon: 0251/83-9948 Fax: 0251/83-2882
Alastair S. Preston
> Everyone seems to have forgotten cromemeco dazzler color graphics
> display. This was circa, 1976.
And the Compucolor computer from about the same period; made by Intecolor,
I believe. 8080 CPU, CP/M, internal 8" floppy drive.
john r pierce
Actually, the early Intecolors circa 1976 I remember didn't run CP/M,
they had a version of MS basic with limited color 'graphics' (actually
was 16 color text with a 4x2 'graphics' font that gave 160x100
graphics) Instead of floppies they had a 8 track (!!) tape... Later
intecolor machines -were- floppy and cp/m based but that was more like
1979. Incredibly flakey machines, both the CRT and the power supplies
were always blowing up on them.
-jrp
Alastair S. Preston
> >And the Compucolor computer from about the same period; made by Intecolor,
> >I believe. 8080 CPU, CP/M, internal 8" floppy drive.
>
> Actually, the early Intecolors circa 1976 I remember didn't run CP/M,
> they had a version of MS basic with limited color 'graphics' (actually
> was 16 color text with a 4x2 'graphics' font that gave 160x100
> graphics) Instead of floppies they had a 8 track (!!) tape... Later
> intecolor machines -were- floppy and cp/m based but that was more like
> 1979. Incredibly flakey machines, both the CRT and the power supplies
> were always blowing up on them.
>
troubles because the disk drive was mounted close to the CRT with
inadequate sheilding.
john r pierce
"Alastair S. Preston" <aspr...@freenet.calgary.ab.ca> wrote:
Well, the early non-FD systems were flakey too... The HV supply would
blow up... get that fixed, and the CPU power supply would melt down...
etc etc. Also, the physical construction (case, keyboard, etc) was
somewhat less than office/industrial/consumer quality.
-jrp
Frank D. Cringle
I am just catching up with this after being away for a few weeks.
alli...@world.std.com (Allison Parent) writes:
> [ about implicit limitations on file and disk sizes in 2.2 ]
>This stuff is never explained in any docs I've seen save for a criptic
>comment.
For what it's worth, here is an extract from the docs I wrote for
PACK.COM about a decade ago. Not that this is in any way official or
definitive (it may not even be right ;). PACK is a disk packing
utility that is on the CP/M CDROM and on oak.oakland.edu in
pub/cpm/zcpr33/pack10a.lbr.
Disk and directory sizes under CP/M 2.2 (and ZRDOS 1.7):
The contraints on disk and directory size in CP/M 2.2 are as follows.
There can be at most 2**16 (65536) logical sectors (@128 bytes) on the
disk. The BDOS assumes it can use 16 bit arithmetic when calculating
sector numbers, and values in the random record field of the fcb are
limited to 16 bits. This gives us the CP/M 2.2 file and disk size
limit of 8MBytes. CP/M 3 extends this to 32MBytes by using 2 more
bits in sector numbers. There are two separate limits on directory
size. The allocation groups reserved for the directory must be
representable in the 16 bits available in the disk parameter block
(AL0 and AL1 in DRI parlance). This gives a limit of 16 * Group size /
32 entries. But the number of directory entries that can ever be
needed is also limited to one per allocation group when the disk is
full of minimal size files. The number of files is then given by the
total allocation groups less those assigned for the directory.
Allocation Max Disk Max Groups Max Number of Directory Entries
Group size size per Disk 16 Groups 1 entry per Group
1K 256K 256 (512) 248
2K 8M 4096 1024 (4032)
4K 8M 2048 (2048) 2032
8K 8M 1024 (4096) 1020
16K 8M 512 (8192) 511
Therefore the worst case directory size is 65024 Bytes, on a disk with
a group size of 4K containing 2032 small files. Worst case number of
groups is 4096
--
Frank Cringle | f...@cliwe.ping.de
voice + fax | +49 2304 467101
Allison Parent
f...@cliwe.ping.de (Frank D. Cringle) wrote:
>I am just catching up with this after being away for a few weeks.
>alli...@world.std.com (Allison Parent) writes:
>> [ about implicit limitations on file and disk sizes in 2.2 ]
>>This stuff is never explained in any docs I've seen save for a criptic
>>comment.
The limits of the file size were stated as 8mb per single file but the
disk could be 65536xallocation_size or 1 gig max. I've done 32mb
as a single logical drive though the largest file is still 8mb.
The real problems is having enough directory space to contain the
required entries while balancing the allocation block size.
Allison
Allison Parent
Speaking of GUI interfaces...Whatever happened to
Smaltalk-80?
Allison
Will Rose
Allison Parent (alli...@world.std.com) wrote:
: Speaking of GUI interfaces...Whatever happened to
: Smaltalk-80?
Was there ever a version for CP/M? I can't imagine it.
It was slow on 16-bit minis, and modern versions take
up most of a 32-bit processor's power.
Allison Parent
c...@cts.com (Will Rose) wrote:
>Was there ever a version for CP/M? I can't imagine it.
>It was slow on 16-bit minis, and modern versions take
>up most of a 32-bit processor's power.
Slow is a relative term.. At the time I got to see it it was fair in
the speed department on a monocrome z80/7220 box.
I was more interested in know what ever happend to it and if it can
even be could found in some archive?
Allison
Francisco Martín
Gem Desktop (of course) was developed by Digital Research Inc.(The Gary Kildall's company).
Please, read about that, I'm not lying.
dott.Piergiorgio
> There was something called "Gem Desktop" a Graphics Environment Manager intended to provide a GUI for the cp/m running over Intel 8088 processors and also for the Motorola 68000 processors. (Yes, it was used by the TOS of the Atari ST computers, and also by the Amstrad PC1512 and PC1640). I saw it running on an Amstrad PC1512.
> Gem Desktop (of course) was developed by Digital Research Inc.(The Gary Kildall's company).
> Please, read about that, I'm not lying.
descends from CP/M 68k.
I estimate that with a banked CP/M and a late S-100 graphic card (eg.
SCION) IS possible to port GEM on a banked CP/M-80, using one or two
banks for GEM, one for the graphic card, and the remaining bank(s) as TPA.
uhm... thinking on, a 4MHz Z80 S-100 machine with 256K RAM, a 10-20M HD,
MPM and GEM and a graphic terminal and one or two character consoles,
running single-user under GEM and multiuser under character interface
can easily be an interesting early-to-mid 1980s SOHO solution, esp. in
the architectural field
(here in Italy, mid-80s many architects was using Apple ][ for their
works; I gained a pair or so million lire (~ 4000€ today) in trading
used apples II to architects, circa 1986-7)
Best regards from Italy,
dott. Piergiorgio.
KJG KJG
> On 24/03/22 19:30, Francisco Martín wrote:
>
> > There was something called "Gem Desktop" a Graphics Environment Manager intended to provide a GUI for the cp/m running over Intel 8088 processors and also for the Motorola 68000 processors. (Yes, it was used by the TOS of the Atari ST computers, and also by the Amstrad PC1512 and PC1640). I saw it running on an Amstrad PC1512.
> > Gem Desktop (of course) was developed by Digital Research Inc.(The Gary Kildall's company).
> > Please, read about that, I'm not lying.
> IIRC, the Amstrad PC1512 run DR's DOS+, derived from CP/M 86 and TOS
> descends from CP/M 68k.
>