Disillusioned about writing a GUI for CP/M...

[Peter Smith]

I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with my Commodore C128. I didn't fail at the mechanisms or the
implementation of the structures and procedures.
I simply failed because drawing graphs (dots, lines, boxes a.s.o.) is
really slow with that Z80 at 4 MHz. May be it was also related with the
crt controller (a 6845 clone with a bit more functionality), because
there was no chance to read/write the video memory directly (this could
speed up things enormous).
But I was also surprised because there exists already a really working
GUI for my computer in the 6502 mode (the second CPU in the C128), the
GEOS 128 (or later, the Wheels 128). GEOS and Wheels really works fast
enough even with that slower timed 6502 with 2 MHz (aka 8510, which is
also a clone with a build in PIO), and with 640x256 pixels.
So it seems that it depends on the hardware architecture of the
(specific) CP/M machine also.
It should be a much more realistic approach to implement a GUI in
character mode, this should look good enough when special characters in
the character set could be used (line symbols, filled and patterned
block chars a.s.o.). And this will be easier because almost all CP/M
machines are able to position the cursor with an escape sequence and so
on...

Regards
Peter

[Claudio Puviani]

Post by Peter Smith
I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with my Commodore C128. I didn't fail at the mechanisms or the
implementation of the structures and procedures.
I simply failed because drawing graphs (dots, lines, boxes a.s.o.) is
really slow with that Z80 at 4 MHz. May be it was also related with the
crt controller (a 6845 clone with a bit more functionality), because
there was no chance to read/write the video memory directly (this could
speed up things enormous).
But I was also surprised because there exists already a really working
GUI for my computer in the 6502 mode (the second CPU in the C128), the
GEOS 128 (or later, the Wheels 128). GEOS and Wheels really works fast
enough even with that slower timed 6502 with 2 MHz (aka 8510, which is
also a clone with a build in PIO), and with 640x256 pixels.
So it seems that it depends on the hardware architecture of the
(specific) CP/M machine also.
It should be a much more realistic approach to implement a GUI in
character mode, this should look good enough when special characters in
the character set could be used (line symbols, filled and patterned
block chars a.s.o.). And this will be easier because almost all CP/M
machines are able to position the cursor with an escape sequence and so
on...

Did you consider just writing the graphics primitives in 6502 assembler and
writing a cross-CPU invocation mechanism? It's not like this thing is going to
be portable.

Claudio Puviani

[Peter Smith]

Post by Claudio Puviani

Post by Peter Smith
I simply failed because drawing graphs (dots, lines, boxes a.s.o.) is
really slow with that Z80 at 4 MHz. May be it was also related with the
crt controller (a 6845 clone with a bit more functionality), because
there was no chance to read/write the video memory directly (this could
speed up things enormous).
But I was also surprised because there exists already a really working
GUI for my computer in the 6502 mode (the second CPU in the C128), the
GEOS 128 (or later, the Wheels 128). GEOS and Wheels really works fast
enough even with that slower timed 6502 with 2 MHz (aka 8510, which is
also a clone with a build in PIO), and with 640x256 pixels.

[...]
Did you consider just writing the graphics primitives in 6502 assembler and
writing a cross-CPU invocation mechanism? It's not like this thing is going to
be portable.

Claudio,

yes, I considered this also. BUT the C128 does NOT offer in 80 column
mode memory mapped graphics nor the sprites or other "goodies" like the
C64. I agree that I can write most of the code in 6502 assembler, but
then I do not really need my Z80 system with CP/M anymore, or ?
My first idea was to implement a GSX-80 driver for portability. But as I
already stated, this was not the best idea.

Regards
Peter

[Claudio Puviani]

Post by Peter Smith

Post by Claudio Puviani

Post by Peter Smith
I simply failed because drawing graphs (dots, lines, boxes a.s.o.) is
really slow with that Z80 at 4 MHz. May be it was also related with the
crt controller (a 6845 clone with a bit more functionality), because
there was no chance to read/write the video memory directly (this could
speed up things enormous).
But I was also surprised because there exists already a really working
GUI for my computer in the 6502 mode (the second CPU in the C128), the
GEOS 128 (or later, the Wheels 128). GEOS and Wheels really works fast
enough even with that slower timed 6502 with 2 MHz (aka 8510, which is
also a clone with a build in PIO), and with 640x256 pixels.

[...]
Did you consider just writing the graphics primitives in 6502 assembler and
writing a cross-CPU invocation mechanism? It's not like this thing is going to
be portable.

Claudio,
yes, I considered this also. BUT the C128 does NOT offer in 80 column
mode memory mapped graphics nor the sprites or other "goodies" like the
C64. I agree that I can write most of the code in 6502 assembler, but
then I do not really need my Z80 system with CP/M anymore, or ?
My first idea was to implement a GSX-80 driver for portability. But as I
already stated, this was not the best idea.

You don't need to write most of the code in 6502 assembler; just the graphics
primitives. For example, if you implement the basic line, polygon, and
bit-blitting functionality (and maybe pixel and elipse, if you want to get
fancy) in 6502 assembler, everything else can be built on top of it in Z80
code. Most of your code is going to be for window and event management and that
can be done on the Z80 side. Even font management and display can be done on
the Z80 side and built on top of the bit-blitting; same thing for icons,
buttons, and other pictographs. The 6502 graphics core itself shouldn't take
more than a few hundred bytes.

As for the 80-column mode, I'm not sure why you'd worry about that, since you'd
be sending your text output to one or more windows and they can be given any
virtual size you want. In fact, you're more likely to use your GUI API than the
BDOS/BIOS calls to write to a window, but even if you did use BDOS/BIOS
terminal I/O, I'm assuming you'd be intercepting the calls and remapping them
to your GUI.

Claudio Puviani

[Peter Smith]

Post by Claudio Puviani
[...]
As for the 80-column mode, I'm not sure why you'd worry about that, since you'd
be sending your text output to one or more windows and they can be given any
virtual size you want. In fact, you're more likely to use your GUI API than the
BDOS/BIOS calls to write to a window, but even if you did use BDOS/BIOS
terminal I/O, I'm assuming you'd be intercepting the calls and remapping them
to your GUI.

So how can I do this (intercepting the BDOS console I/O), is this done
by changing the proper vector addresses (BDOS jump table) to my own
routine or must I change the BDOS itself ?

Regards
Peter

[Claudio Puviani]

Post by Peter Smith

Post by Claudio Puviani
[...]
As for the 80-column mode, I'm not sure why you'd worry about that, since you'd
be sending your text output to one or more windows and they can be given any
virtual size you want. In fact, you're more likely to use your GUI API than the
BDOS/BIOS calls to write to a window, but even if you did use BDOS/BIOS
terminal I/O, I'm assuming you'd be intercepting the calls and remapping them
to your GUI.

So how can I do this (intercepting the BDOS console I/O), is this done
by changing the proper vector addresses (BDOS jump table) to my own
routine or must I change the BDOS itself ?

Yup, just change the vector to point to your own code, process those functions
you want to override, and pass the ones you don't back to along the saved
vector. The nice thing about this approach is that the filters can be chained,
so if you have many, you don't need to write one monolithic dispatcher, but you
can instead install the filters one at a time and in any combination that you
want. So, for example, you could have one filter that redirects console output
to the current window and another filter that translates control codes to
actions (e.g., you might want to emulate ANSI, VT*, or something else).

Claudio Puviani

[Peter Smith]

[...] The nice thing about this approach is that the filters can be chained,
so if you have many, you don't need to write one monolithic dispatcher, but you
can instead install the filters one at a time and in any combination that you
want. So, for example, you could have one filter that redirects console output
to the current window and another filter that translates control codes to
actions (e.g., you might want to emulate ANSI, VT*, or something else).

Claudio,

do you really think this kind of "redirector" with all stuff of
recalculating screen coordinates, interpreting several esc sequences and
other things like clipping output (because you have not the whole height
and width of the original screen) will be easy to implement, regardless
of the fear that this will also result in too slow output speed ??
I think implementing a thing like "Norton Commander for CP/M" will be
enough, or ?

Regards
Peter

[Claudio Puviani]

Post by Peter Smith

[...] The nice thing about this approach is that the filters can be chained,
so if you have many, you don't need to write one monolithic dispatcher, but you
can instead install the filters one at a time and in any combination that you
want. So, for example, you could have one filter that redirects console output
to the current window and another filter that translates control codes to
actions (e.g., you might want to emulate ANSI, VT*, or something else).

do you really think this kind of "redirector" with all stuff of
recalculating screen coordinates, interpreting several esc sequences and
other things like clipping output (because you have not the whole height
and width of the original screen) will be easy to implement

Each individual aspect of this problem is very simple. It's just a matter of
keeping things separate and tackling them one at a time. For example, say you
have your windowing and graphics functionality in place (which is a
prerequisite), you now have your client area which has coordinates of (0,0) to
(Width-1,Height-1). First, define your font. Just to keep things simple, let's
say it's a plain 8x12 bitmap. The location of the top left corner of a
character, in your client area, is (8*column, 16*line), assuming your column
and line numbers start at zero. With this, you can create a function to write a
character to the client area (I'll use C, just as an example):

void displayChar(Window * w, int column, int row, char c)
{
Bitmap * bmp = fontTable[c]; // select the bitmap

// copy the bitmap to the client area
bitblt(w, column*8, row*16, bmp); // bitblt can do its own clipping
}

Now, to build simple I/O over that (you wouldn't use globals in real life):

static int cursorX = 0, cursorY = 0;
static int cursorMaxX = 79, cursorMaxY = 24;

void advanceCursor()
{
++cursorX; // advance by one column
if (cursorX > cursorMaxX) {
cursorX = 0; // wrap around
// now advance one line and wrap to top if past bottom
cursorY = (cursorY + 1) % cursorMaxY;
}
}

void printChar(Window * w, char c)
{
switch (c) {
case '\n' : cursorX = 0;
cursorY = (cursorY + 1) % cursorMaxY;
break;
// other control codes handled similarly
default: displayChar(w, cursorX, cursorY);
advanceCursor();
}
}

And now, for a string:

void printString(Window * w, const char * s)
{
while (*s) {
printChar(w, *s++);
}
}

Want to change where the output goes?

void gotoXY(int column, int row)
{
if (0 <= column && column <= cursorMaxX && 0 <= row && row <= cursorMaxY) {
cursorX = column;
cursorY = row;
}
}

It doesn't get much more complicated, if you just handle everything piecemeal.

Post by Peter Smith
, regardless of the fear that this will also result in too slow output speed

??

Outputting to a graphics window is necessarily slower than outputting to a text
screen. That comes with the territory in GUI land. On the other hand, if you
don't write text graphically, you don't have a GUI. This is a choice between
having a cake or eating it.

Post by Peter Smith
I think implementing a thing like "Norton Commander for CP/M" will be
enough, or ?

Norton Commander wasn't a GUI. It was just a text-based interface. If that's
what you're trying to implement, it will be a lot easier, but then, you'd have
no need for graphics at all.

Claudio Puviani

[French Luser]

Post by Peter Smith
So how can I do this (intercepting the BDOS console I/O), is this done
by changing the proper vector addresses (BDOS jump table) to my own
routine or must I change the BDOS itself ?

Under CP/M Plus, DRI implemented a very well-defined thing
called RSX (Resident System eXtension). This is exactly what
you need. And you can install and remove it easily.

(The only drawback is that it resides in the TPA. But why would
you use it if you had the source code of your BIOS?)

Yours Sincerely,
"French Luser"

[Amardeep S Chana]

Post by Peter Smith
I simply failed because drawing graphs (dots, lines, boxes a.s.o.) is
really slow with that Z80 at 4 MHz.

Some of the most popular and graphics intensive video arcade systems of
the eighties were Z-80 based including Pacman. It is more likely the
C128 architecture inhibits the Z-80 from full bandwidth access to the
I/O devices.

Amardeep

[Peter Smith]

Post by Amardeep S Chana

Post by Peter Smith
I simply failed because drawing graphs (dots, lines, boxes a.s.o.) is
really slow with that Z80 at 4 MHz.

Some of the most popular and graphics intensive video arcade systems of
the eighties were Z-80 based including Pacman. It is more likely the
C128 architecture inhibits the Z-80 from full bandwidth access to the
I/O devices.
Amardeep

You hit the point, that's indeed my own idea about it.

Regards
Peter

[wild bill]

On Sun, 25 Apr 2004 23:14:52 +0200, Peter Smith

Post by Peter Smith
I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with

...... with virtually *anything* I suspect

CP/M was never designed for the large amount of memory
and the larger processor words/data chunks required for
doing GUI ... let alone voice I/O and recognition, etc

If you really want to play around with your hardware, the
closest you can come to the 'good old days' feel is to
load up one of the free distros of Linux.

At least Linux is properly coded for larger/wider sized
modern processors - 32 bits, 64bits, whatever.

Kildall claimed a person really only has one good operating
system in him, so it's unlikely this is somewhere CP/M would
ever, ever, have gotton to. Sort of like a 'great novel'.

He contributed mightily in the early days, both in his skill
at programming and in his down to earth marketing ideas
but his day has long past.

CP/M is a dead-end operating system, Time to move into
the 21st century. And, really make an effort to stop support
for the evil empire ... Linux isn't that hard, compared to 1978
and getting things to work at all, let alone to do something
actually useful. Just getting running was an accomplishment.

I'm sure Gary would be happy to be able to see folks going
with ANYTHING ELSE to avoid doing business with mr gates.

Bill

[Exegete]

Post by wild bill
On Sun, 25 Apr 2004 23:14:52 +0200, Peter Smith

Post by Peter Smith
I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with

...... with virtually *anything* I suspect
CP/M was never designed for the large amount of memory
and the larger processor words/data chunks required for
doing GUI ...

Strange, the Apple II with a 1 mhz 6502 and ProDOS had not one, but TWO
GUIs. GEOS and MouseDesk(a lookalike of the B/W Mac GUI.)

Roy



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[n***@nouce.bellatlantic.net]

Post by wild bill
On Sun, 25 Apr 2004 23:14:52 +0200, Peter Smith

Post by Peter Smith
I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with

...... with virtually *anything* I suspect

Troll mode I suspect.

Post by wild bill
CP/M was never designed for the large amount of memory
and the larger processor words/data chunks required for
doing GUI ... let alone voice I/O and recognition, etc

Those are not CP/M limits, you know that! The Z80 (8080) is more the
limiting factor not the OS.

As to writing a gui for CP/M I have one, runs fine on a Visual 1050.
the real limit if any was at the time most CP/M systems used text
terminals and the only one of merit that could do graphics was the
VT125 and it's clones. Wasn't a requirement or practical to do that
on {relatively slow, sub 19.2k} serial lines. If anything the lack of
standard grphaic capable IO was commonplace on CP/M machines
and led to less action.

However in 1981 there was the 7220, the first video graphic display
processor and it was paired with a multibus Z80 to make one fine
graphic system using CP/M as the core. It was pushing the edge as we
didn't have the software to exploit it and even hi res color displays
were hard to find at less than a two kilobucks for the tube. It was 4
planesx 8bit of 64k Dram (32 peices at then 22$ each!) for full
600x400 x256 color. And you to in 1982 could have that for a mere
3700$ (display system, tube and cables) CPU, box, ram and OS extra.

As to your linux rant, it's ok beats the Borg. It's not really ready
for the average idiots desktop, yet.

Post by wild bill
At least Linux is properly coded for larger/wider sized
modern processors - 32 bits, 64bits, whatever.

Back then we called it unix and it ran on CDC (60 bits) and
VAX(32 bits) and a few others of minor significance. It was
brand C then as it is now because it's an OS not for the masses.

Post by wild bill
CP/M is a dead-end operating system, Time to move into
the 21st century. And, really make an effort to stop support
for the evil empire ... Linux isn't that hard, compared to 1978
and getting things to work at all, let alone to do something
actually useful. Just getting running was an accomplishment.

No doubt the Borg is a plague and alternatives are needed.
Different issue and project. Besides it's not about supporting the
latest and greatest it's about small, fast and tight.


Allison

[Peter Smith]

Post by wild bill
On Sun, 25 Apr 2004 23:14:52 +0200, Peter Smith

Post by Peter Smith
I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with

...... with virtually *anything* I suspect

He, what's wrong with you ? Never had the idea to implement "anything",
instead, my goal was to do something small and simple as possible.

Post by wild bill
CP/M was never designed for the large amount of memory
and the larger processor words/data chunks required for
doing GUI ... let alone voice I/O and recognition, etc

Think about the size of other CP/M programs and the beauty of Z80
assembler coded programs. With that limited possibilities it was (and is
still) possible to get useful results.
Throw away your megabyte-feeling and go back to the roots.
With CP/M 3.0, you are still able to use a few banks of 64 KB, so it
should be possible to get a character graphics based GUI up and running
without the need for megabytes of code.

Post by wild bill
I'm sure Gary would be happy to be able to see folks going
with ANYTHING ELSE to avoid doing business with mr gates.

So what ? I'm working with Windows and I still dislike BillG.
But spending about one day for the simplest things (under Windows) like
burning a video cd or scanning pictures with my Canon Scanner is not my
thing. One reason for the (yet) missing success of Linux on Desktops is
the missing unified binary base. It is not a "normal" thing to compile
programs and even drivers before getting something to work.
And, beside this, I've worked with UNIX (not LINUX) about 15 years ago
for more than 8 years... I'm still a fan of command line tools.

Regards
Peter

P.S.: I'm not sure there are even UNIX tools on CP/M running (like sed
or awk)...

[Jan Vanden Bossche]

Hallo

Post by Peter Smith
Throw away your megabyte-feeling and go back to the roots.
With CP/M 3.0, you are still able to use a few banks of 64 KB, so it
should be possible to get a character graphics based GUI up and
running without the need for megabytes of code.

There was a windowing system called "Monte's Window" running under Montezuma
Micro CP/M 2.2 on a TRS-80 model 4 with 128 KB of RAM. It was not a unified
GUI, but it was a start.

Problem with writing 'a' GUI for CP/M is, I think, the lack of a unified
hardware base. So many possible permutations of terminals, disks, memory,
... Apple and PC have a much more uniform hardware platform.

A good place to start would be: taking a CP/M that runs on a 80286 (or more)
CPU and programming towards a GUI that uses the basic VGA video. You'd have
a very standard platform, with a lot of impact. Not a lot of people have a
Kaypro II, a TRS-80 model 4, or a C= 128D in their possession. But a lot of
people do have old PC's around.

Post by Peter Smith
So what ? I'm working with Windows and I still dislike BillG.

A lot of people do, I think. BuT I don't see the relevance of this statement
here, in COMP.SYS.CPM. Nor the remark of the previous poster, for that
matter.

Post by Peter Smith
I'm still a fan of command line tools.

So am I: under MS/PC/DR-DOS ;-)

Post by Peter Smith
Regards
Peter

Greetings from the TyRannoSaurus
Jan-80

[Rosso]

"Jan Vanden Bossche" wrote in message...

Post by Jan Vanden Bossche

Post by Peter Smith
Throw away your megabyte-feeling and go back to the roots.
With CP/M 3.0, you are still able to use a few banks of 64 KB, so
it should be possible to get a character graphics based GUI up
and running without the need for megabytes of code.

There was a windowing system called "Monte's Window" running under
Montezuma Micro CP/M 2.2 on a TRS-80 model 4 with 128 KB of RAM. It
was not a unified GUI, but it was a start.

Writing a unified GUI maybe possible, but difficult. Trouble is, many
CP/M systems have different capabilities, some don't even support
graphics. For systems which do, I feel it's better to give that support,
but then that portability problem already exists!

Post by Jan Vanden Bossche
Problem with writing 'a' GUI for CP/M is, I think, the lack of a
unified hardware base. So many possible permutations of terminals,
disks, memory, ... Apple and PC have a much more uniform hardware
platform.

Exactly, IBMs only start getting that problem when you start using older
hardward, same for Macs. And then you've got problems which I mentioned
above, with the issue of graphics.

Post by Jan Vanden Bossche
A good place to start would be: taking a CP/M that runs on a
80286 (or more) CPU and programming towards a GUI that uses the
basic VGA video. You'd have a very standard platform, with a lot
of impact. Not a lot of people have a Kaypro II, a TRS-80 model 4,
or a C= 128D in their possession. But a lot of people do have old
PC's around.

Well there's probably more of those 8bit users than you think, most of
the posts here seem to range more into that frame. Lots of people might
have a PC, but use it for other things.

Regards,
Ross.

[Peter Smith]

Post by Jan Vanden Bossche
Problem with writing 'a' GUI for CP/M is, I think, the lack of a unified
hardware base. So many possible permutations of terminals, disks, memory,
... Apple and PC have a much more uniform hardware platform.

I do not agree with that. Ok, there were many different terminal codes
(if we want to build a character based GUI, that's all what you have to
consider), but think about the way UNIX (or Z-System/ZCPR) is handling
that: Try to divide the program from the data (that is always a good
idea), means use something like a termcap file.
So, if you change the terminal, just exchange the termcap file, but use
the same program. Where is the problem ?

Post by Jan Vanden Bossche
A good place to start would be: taking a CP/M that runs on a 80286 (or more)
CPU and programming towards a GUI that uses the basic VGA video. You'd have
a very standard platform, with a lot of impact. Not a lot of people have a
Kaypro II, a TRS-80 model 4, or a C= 128D in their possession. But a lot of
people do have old PC's around.

I see, you didn't understand ... using a 16-bit machine was not my
intention, even the x86 machines are much more available.
Doing something more with less is my idea.
Btw... you know in what newsgroup you are publishing an article ... ?

Regards
Peter

[Jan Vanden Bossche]

Hallo

Post by Peter Smith

Post by Jan Vanden Bossche
Problem with writing 'a' GUI for CP/M is, I think, the lack of a unified
hardware base. So many possible permutations of terminals, disks,
memory, ... Apple and PC have a much more uniform hardware platform.

I do not agree with that. Ok, there were many different terminal codes
(if we want to build a character based GUI, that's all what you have to
consider), but think about the way UNIX (or Z-System/ZCPR) is handling
that: Try to divide the program from the data (that is always a good
idea), means use something like a termcap file.
So, if you change the terminal, just exchange the termcap file, but use
the same program. Where is the problem ?

OK. That applies to text-based terminals. Probably feasable, though you
would have to know all terminal control codes from all terminals you run
your GUI on. Someone who doesn't know them, won't be able to work with
it/make it work.

If you work with a windowing system, you need a place to store the
information underneath it. Typically, in TPA, extra RAM or (RAM-)disk.
Storing in TPA is very limiting. Slows down the machine. Leaves extra
RAM-banks (direct access) or RAM-disks (in extra RAM banks) A CP/M computer
that doesn't have this, won't be able to do that, and run REAL slow if he
has to swap all to real (floppy-)disk.

If you want to extend that to real graphical use, your problems grow
exponentionally. How are you going to define all those different terminals
and their graphical capabilities ? Speed will probably be an issue too.
Leaving aside the fact that a typical CP/M system is a Z-80A @ 4 MHz (speed
demon ?) the access to the graphical capabilities may be fast, slow or
nonexistant. Eg., I know that the 640x240 mono capabilities of the TRS-80
model 4 are very slow to access, because it all has to channeled through one
8-bit port. I don't know if the C= 128 has any graphical capabilities
accessible under CP/M (I suppose it does) but does the Kaypro II ?

And you do not have any hooks in the OS to hang your GUI onto. So you would
have to (re-)write it for every new terminal. Tough...

Post by Peter Smith

Post by Jan Vanden Bossche
A good place to start would be: taking a CP/M that runs on a 80286
[..] a lot of people do have old PC's around.

I see, you didn't understand ...

I think I did. You only emphasized the graphical part. I'm afraid that you
will have to limit yourself to a text-based windowing system, to have a
chance to succed. Real graphics, forget it. Sorry.

BTW, why do you want to re-invent the wheel ? GEM and GEOS are available.
GEM is even PD.

Post by Peter Smith
Doing something more with less is my idea.

I do it all day. I do understand your idea and I'm ready to support you. But
don't bite more than you can chew.

Post by Peter Smith
Btw... you know in what newsgroup you are publishing an article ... ?

Yes, thank you.

Post by Peter Smith
Regards
Peter

Greetings from the TyRannoSaurus
Jan-80

[Kelli Halliburton]

Post by Peter Smith

Post by Jan Vanden Bossche
Problem with writing 'a' GUI for CP/M is, I think, the lack of a
unified hardware base. So many possible permutations of terminals,
disks, memory, ... Apple and PC have a much more uniform hardware
platform.

I do not agree with that. Ok, there were many different terminal codes
(if we want to build a character based GUI, that's all what you have
to consider), but think about the way UNIX (or Z-System/ZCPR) is
handling that: Try to divide the program from the data (that is
always a good idea), means use something like a termcap file.
So, if you change the terminal, just exchange the termcap file, but
use the same program. Where is the problem ?

Post by Jan Vanden Bossche
A good place to start would be: taking a CP/M that runs on a 80286
(or more) CPU and programming towards a GUI that uses the basic VGA
video. You'd have a very standard platform, with a lot of impact.
Not a lot of people have a Kaypro II, a TRS-80 model 4, or a C= 128D
in their possession. But a lot of people do have old PC's around.

I see, you didn't understand ... using a 16-bit machine was not my
intention, even the x86 machines are much more available.
Doing something more with less is my idea.
Btw... you know in what newsgroup you are publishing an article ... ?

Without graphics, you don't have a GUI. GUI, after all, stands for Graphical
User Interface. It's also going to be difficult to call it a WIMP interface,
because you probably won't be able to draw icons. WMP, maybe.
(Windows/Menus/Pointer)

I think it would be quite useful to build CP/M programs based on... what was
it... CUA? Common User Architecture? Something like that. Back when there
was a movement for DOS applications to standardize their interface. It's
when F1 first became the standard 'help' key, IIRC.

Where you start having problems is in the heterogeneity of CP/M systems. You
can't, for example, count on having an "ALT" key to bring up access to the
menus; you can't count on the terminal to tell you that any modifier key has
been pressed by itself at all. You can't count on even having arrow keys.
You're stuck with the WordStar approach, using Control.

I could see Ctrl+Space activating the menus, then Space to page through the
options and Enter (or Return) to choose. So you'd hit Ctrl+Space, the menus
would appear, you'd hit Space once to move from the already highlighted File
menu to the Edit menu, hit Enter to pull down the menu, Space twice to get
to the Paste command, Enter to execute the pasting operation. Escape should
back you out, and Ctrl+Esc would back you completely out of the menu system
entirely.

All of this is simpler if there's a way to hook up a mouse. Serial mice are
still around, and they should be simple enough to hook to a CP/M machine.
Then the mouse pulses would control the H/V position of the text cursor, and
just clicking on the menu would activate it, just as it already works in
text-mode DOS programs that support the mouse.

Oops. I seem to have diverged into designing the interface. Sorry. I'll stop
now...

[Jack Peacock]

Post by Kelli Halliburton
Without graphics, you don't have a GUI. GUI, after all, stands for Graphical
User Interface. It's also going to be difficult to call it a WIMP interface,
because you probably won't be able to draw icons. WMP, maybe.
(Windows/Menus/Pointer)

You can have a visual interface on terminals. VMS has a facility called SMG
(Screen Management Guidelines) that uses just about every feature in VT type
terminals to deliver a somewhat useful interface similar to the Curses
library in Unix. I can pop up windows, overlay panels, scroll vertical and
horizontal, even use color if it's supported. I used SMG in a casino check
cashing application and got excellent response time (better than Windows
actually, the replacement PC system from another vendor was delayed by
nearly a year due to performance problems).

DEC used SMG for some of their sysadmin utilities, such as the Pathworks
program to support file and print for PCs. While it did deliver something
that was vaguely like the Windows GUI it was very slow and not terribly
useful (I notice the latest version is back to the command line). SCO and
IBM did the same thing for Unix/AIX admin tools, and had the same problems.
Sluggish screen response led to user frustration, tho I suspest the poor
performance was more related to how commands were processed rather than an
inherent flaw in the UI.

Digital Research had a similar product for CP/M, Display Manager DM-80 and
DM-86, for applications using PL/I, C, or CBasic. It was on the buggy side
but did work. I used it for a sports handicapping service that ran 8
terminals off a Concurrent CP/M-86, using DRI's PL/I-86 compiler. Once the
bugs were worked around it ran reliably for several years and the operators
didn't have any difficulty using it.

Ever consider a console shell based on DM? I believe it's available in one
of the CP/M library sites.
Jack Peacock

[Lee Hart]

Post by wild bill
On Sun, 25 Apr 2004 23:14:52 +0200, Peter Smith

Post by Peter Smith
I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with

...... with virtually *anything* I suspect

I think you are overly pessimistic. There have been quite a few
computers with graphical user interfaces that had what would be
considered pitiful amounts of speed and memory by today's bloated
standards.

The original GUI machine, the Xerox Alto, had roughly a 600x800 pixel
display, 128k bytes of memory, and a 16-bit CPU that executed about
400,000 instructions per second.

The first Apple Macintosh had a 512x342 pixel display, 192k bytes of
memory (RAM+ROM), and a 16-bit CPU that executed about 500,000
instructions per second.

CP/M computers can easily match these resources. While the most basic
low-cost "entry level" machines often skimped on the hardware resources,
you could add expansion graphics and memory boards to reach these levels
with essentially every model. And a 4 MHz Z80 is fast enough to execute
500,000 instructions per second.

The only real difficulty was the software. People *could* have written a
GUI operating system, but didn't. I'd say that it was simply a matter
that the sort of people attracted to CP/M systems were less likely to be
interested in GUIs, and so didn't write them. They would rather "spend"
their computer's resources on other tasks besides pretty screens and
easy user interfaces.

[Michael J. Mahon]

Post by Lee Hart

Post by wild bill
On Sun, 25 Apr 2004 23:14:52 +0200, Peter Smith

Post by Peter Smith
I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with

...... with virtually *anything* I suspect

I think you are overly pessimistic. There have been quite a few
computers with graphical user interfaces that had what would be
considered pitiful amounts of speed and memory by today's bloated
standards.
The original GUI machine, the Xerox Alto, had roughly a 600x800 pixel
display, 128k bytes of memory, and a 16-bit CPU that executed about
400,000 instructions per second.
The first Apple Macintosh had a 512x342 pixel display, 192k bytes of
memory (RAM+ROM), and a 16-bit CPU that executed about 500,000
instructions per second.
CP/M computers can easily match these resources. While the most basic
low-cost "entry level" machines often skimped on the hardware resources,
you could add expansion graphics and memory boards to reach these levels
with essentially every model. And a 4 MHz Z80 is fast enough to execute
500,000 instructions per second.
The only real difficulty was the software. People *could* have written a
GUI operating system, but didn't. I'd say that it was simply a matter
that the sort of people attracted to CP/M systems were less likely to be
interested in GUIs, and so didn't write them. They would rather "spend"
their computer's resources on other tasks besides pretty screens and
easy user interfaces.

There is one important thing that all the GUI-based machines you
mention shared: bit-mapped graphics memory in the address space
of the processor.

The importance of this capability for speedy screen updates cannot
be overstated. If every byte of screen update had to be turned into
a couple of I/O operations to set the buffer address and another
I/O operation to set 8 (or so) pixels, then screen update performance
is seriously compromised. If the graphics subsystem requires an
I/O handshake for reliable synchronization, then even worse.

The other 8-bit machines with GUI implementations that have been
mentioned here also have direct-mapped video memory.

The memory architecture of CP/M machines was such that something
quite artificial would have been required to present the video memory
to programs. CP/M 3 could have handled it by reserving one bank
for video memory.

Then the only problem would have been making that hardware
architecture part of the CP/M 3 spec, which would have been
completely out of character as well as unrealistic in the market.

GUIs were developed for machines having standard, memory-mapped
graphics that were replicated enough to make the development of a
GUI justifiable. One-off GUIs are a lot of work for little benefit,
except the education of the writer. ;-)

The only way that I can imagine that such a GUI might have been
economically justified for CP/M would have been as software
bundled with an S-100 graphics board, assuming the memory-
mapping issues could have been solved in a way compatible
with CP/M programs. Then, additionally, for there to be any
real advantage in such a GUI, significant application programs
that exploited it would have had to be developed, too. Given
the economics, at least a starter set would have also had to
be bundled with the GUI/graphics board set.

Too many chicken and egg issues...

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[Steve Dubrovich]

Post by Michael J. Mahon

Post by Lee Hart
The only real difficulty was the software. People *could* have written a
GUI operating system, but didn't. I'd say that it was simply a matter
that the sort of people attracted to CP/M systems were less likely to be
interested in GUIs, and so didn't write them. They would rather "spend"
their computer's resources on other tasks besides pretty screens and
easy user interfaces.

There is one important thing that all the GUI-based machines you
mention shared: bit-mapped graphics memory in the address space
of the processor.

Such as the Amstrad PCW series.

Post by Michael J. Mahon
The importance of this capability for speedy screen updates cannot
be overstated. If every byte of screen update had to be turned into
a couple of I/O operations to set the buffer address and another
I/O operation to set 8 (or so) pixels, then screen update performance
is seriously compromised. If the graphics subsystem requires an
I/O handshake for reliable synchronization, then even worse.
The other 8-bit machines with GUI implementations that have been
mentioned here also have direct-mapped video memory.
The memory architecture of CP/M machines was such that something
quite artificial would have been required to present the video memory
to programs. CP/M 3 could have handled it by reserving one bank
for video memory.
Then the only problem would have been making that hardware
architecture part of the CP/M 3 spec, which would have been
completely out of character as well as unrealistic in the market.

CP/M 3's USERF was made to order for custom extentions for such video
bios extentions.

Post by Michael J. Mahon
GUIs were developed for machines having standard, memory-mapped
graphics that were replicated enough to make the development of a
GUI justifiable. One-off GUIs are a lot of work for little benefit,
except the education of the writer. ;-)
The only way that I can imagine that such a GUI might have been
economically justified for CP/M would have been as software
bundled with an S-100 graphics board, assuming the memory-
mapping issues could have been solved in a way compatible
with CP/M programs. Then, additionally, for there to be any
real advantage in such a GUI, significant application programs
that exploited it would have had to be developed, too. Given
the economics, at least a starter set would have also had to
be bundled with the GUI/graphics board set.

CP/M-3 was tailored for banked memory systems, and the PCW elevated it
to an art. Bank 0 (64k) was the off code bank holding the 'banked'
stuff for the OS.
Bank 1 (64k) was the TPA bank, the normal 64k everyone is accustomed
to. Bank 3 was a partial bank holding the memory mapped video, 16k
IIRC. That left ~112k for a ram drive on the standard 256k system.
However the M.B. was socketed for 512k, and if used this extended the
memory drive to 368k. The memory was organized into 16k segments
under i/o port control, so the ram drive area could also be used as
video data to be paged into the memory mapped video area in bank 3 [or
any other segmenting scheme, say for the TPA]. I've seen sprite
demos, and arcade style games written for it. It is monchrome tho.
The PCW was largely sold as a Word Processor, late in the 8-bit era,
with a dedicated OS for the word processing system, with basic
menuing. But although cp/m-3 was also provided, few owners ventured
there from what I gather. For word processing it was a gem, the
screen char size was 90 columns by 32 lines, quite handy, for cp/m
too. The 90 columns allowed for a typewriter ruler at the top of the
page allowing tab stop settings for horizontal formatting, auto
indenting, etc.

On the hardware side, it did use a FPGA to manage all of that off
processor processing. And some of the software access to that was
thru USERF for the bios extentions.

Post by Michael J. Mahon
Too many chicken and egg issues...
-michael
Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[Lee Hart]

Post by Michael J. Mahon
There is one important thing that all the GUI-based machines you
mention shared: bit-mapped graphics memory in the address space
of the processor.

It happened to be true for the few examples I gave, but it is not
universally true. Another viable architecture is to have a graphics
terminal, with its own CPU that can perform the graphics and display
functions in parallel with the main CPU. Early examples would be the
Tektronix 4010-style terminals; later examples would include terminals
with the NEC 7220 chip as was previously mentioned. Even modern PCs with
graphics accellerator cards use this approach.

With a separate CPU to perform the graphics, the main CPU only need
issue higher-level commands to the terminal. For example, draw a box
from x1,y1 to x2,y2; fill it with this pattern; draw a circle at origin
x3,y3 of radius r3 etc. This mirrors what the graphics software is often
doing anyway on a single-CPU machine with bit-mapped in the address
space anyway; there is a library of drawing primitives that are called
by the main program.

Post by Michael J. Mahon
The memory architecture of CP/M machines was such that something
quite artificial would have been required to present the video memory
to programs.

Perhaps; but no more artificial than the segmented memory architecture
of the 8088/8086, or a Z180 with its internal MMU.

Post by Michael J. Mahon
Then the only problem would have been making that hardware
architecture part of the CP/M 3 spec, which would have been
completely out of character as well as unrealistic in the market.

Hmm... I did a lot of work with the Heath H89 computers. They have a 2
MHz Z80 and 64k of memory for the main CP/M CPU; and a separate 2 MHz
Z80 for its console, which handled all keyboard and screen functions. It
came with character graphics, which could do a fairly good GUI imitation
(it was capable of displaying a screen that looked remarkably like a
Mac). I wrote utilities for Alan Bomberger's Write-Hand-Man, which
created desktop accessories for CP/M (calculator, rolodex,
clock/calendar, file folders, etc.)

Several companies made expansion boards to upgrade the H89's basic VT-52
style terminal to full VT-100 capability (which meant 50 lines of 132
characters text, subwindow scrolling, etc.). With these, the H89 could
actually open, close, and move text windows, scroll text, etc. faster
than the Mac.

These graphics boards also had Tektronix 4010 full pixel graphics
capabilities. I've used a schematic capture and PC board layout program
on an H89 that was actually faster and smoother than equivalent software
on the Mac's or PC's of the day.

With respect to Claudio Puviani's criticism that the 68000 was a much
faster CPU than the Z80: I agree that the 68000 is much faster at
complex math and large memory manipulations. However, most of these
early GUIs weren't doing this; it was mostly very basic bit-level XORs,
shifts and rotates, etc. in a small memory space (under 32k bytes). The
Z80 is actually pretty efficient at this.

Post by Michael J. Mahon
GUIs were developed for machines having standard, memory-mapped
graphics that were replicated enough to make the development of a
GUI justifiable. One-off GUIs are a lot of work for little benefit,
except the education of the writer. ;-)

Yes; exactly! Writing a GUI is a *lot* of work! It is beyond the talents
of a single individual -- it requires the massive, sustained efforts of
a large number of very talented people. None of the early microcomputer
companies could produce such a product. It wasn's so much that the
hardware stopped them; that could be fixed. It was that they couldn't
afford the software development.

However, once a few companies have done it (Xerox, Apple, Microsoft), it
becomes far easier for others to "stand on their shoulders" and produce
a GUI for far less work. So, perhaps a GUI for CP/M has progressed from
"impossible" in 1980 to "merely difficult" in 2004. :-)

If one doubts that a GIU is possible on a Z80, remember that many of the
Palm Pilot organizers are Z80-based.
--
Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net

[Claudio Puviani]

Post by Lee Hart
However, once a few companies have done it (Xerox, Apple, Microsoft), it
becomes far easier for others to "stand on their shoulders" and produce
a GUI for far less work. So, perhaps a GUI for CP/M has progressed from
"impossible" in 1980 to "merely difficult" in 2004. :-)

It's definitely possible. As I've said to the OP, technically, it's not very
complex. What I question is the usability of the end product.

Post by Lee Hart
If one doubts that a GIU is possible on a Z80, remember that many of the
Palm Pilot organizers are Z80-based.

The Palm Pilots I'm familiar with are based on the Dragonball processor, which is
a modern implementation of the 68000 instruction set. I guess you mean other
organizers like the Sharp Wizard. Those are definitely pretty and I'd love to get
my hands on one (now that you reminded me of them, I'm heading to ebay to find
one), but the rudimentary GUI that it supports isn't of the same level of
complexity as the early Xerox, Mac, and GEM variety. It's really more along the
lines of Microsoft Windows 1.x, which wasn't considered so much a GUI at the time
as an application manager. It could also be comparable to the Epson QX-10, which
also was only partially graphically oriented.

Please don't take this as if I were putting down the Z80. It was the first
processor I ever did assembler on and it has a special place in my heart, but
I've also done graphics programming on it and I'm too intimately aware of that
processor's limitations in that regard. You don't even need an actual graphics
display to test that. You can implement Bresenham's algorithm to work in a memory
buffer just to measure the pixels per second, and I guarantee you that you'll be
appalled by how small the number will be. Block moves are reasonably fast under
ideal conditions, but it's not very helpful since graphics rectangles don't
occupy contiguous memory and many operations (like rendering fonts) call for
transparent copies, which operations like LDIR can't do. You can get around some
of these limitations by aligning graphics rectangles to byte boundaries and by
only allowing opaque overwrites, but it still results in some pretty slow
redraws. The C64 solved some of these issues by having "helper" chips, which is
why GEOS was possible. The 7220, which you mentioned, would definitely make a
Z80-based GUI responsive, but I don't remember any Z80 systems that were built
with it. I'd be interested to know of any. My first contact with the 7220 was on
the NEC APC, which was an 8086 (not 8088) system.

The thing is, if we get to design new hardware, we can circumvent almost any
limitation, but using 1970s-1980s hardware, it's just not very practical.

Claudio Puviani

[Lee Hart]

Post by Claudio Puviani
The Palm Pilots I'm familiar with are based on the Dragonball
processor, which is a modern implementation of the 68000
instruction set. I guess you mean other organizers like the
Sharp Wizard.

No; I was thinking of all the early Palm Pilots, which I think ran Z80
derivitives. Does anyone know for sure? I don't think the Dragonball
even existed back then.

Post by Claudio Puviani
Please don't take this as if I were putting down the Z80...You don't
even need an actual graphics display to test that. You can implement
Bresenham's algorithm to work in a memory buffer just to measure the
pixels per second, and I guarantee you that you'll be appalled by
how small the number will be. Block moves are reasonably fast under
ideal conditions, but it's not very helpful since graphics rectangles
don't occupy contiguous memory and many operations (like rendering
fonts) call for transparent copies, which operations like LDIR can't
do.

I'll grant you, it's harder with a Z80. The Z80 always struck me as
having a tricky instruction set -- my first shot at implementing
something on it is usually rather bad. But the more I think about it (or
am *forced* to think about it to get it to fit or to be fast enough),
the more tricks I discover. Eventually, I often found some obscure
combination of hardware usage and software tricks that produced
excellent results.

For example, I did most of my Z80 programming on the Heath H89. I
re-wrote its terminal software to increase the baud rate from 19.2k to
38.4k without dropping characters. This meant finding ways to do line
inserts, deletes, and block moves twice as fast as the obvious methods
like LDIR (since these operations took most of the time).

Surprisingly, the Z80 can do it! For example, receiving a CR-LF sequence
requires you to scroll the screen and clear a new line. Instead of block
moving 2000 bytes up 80 bytes to scroll, you just change the 6845 CRT
controller's start address by 80 bytes. To blank 80 bytes, put 2020h (2
blanks) in HL and PUSH HL 40 times.

I added a pop-up display window capability. The window was 32 bytes wide
and any height, and could appear anywhere on the screen. It appeared to
overlay whatever text was on the screen in a non-destructive fashion;
i.e. typing CTL-ESC made this window appear "on top" of the existing
display, and another CTL-ESC moved it "behind" the existing display. The
window appeared and disappeared instantly; you could type repeat-CTL-ESC
and they swapped back and forth dozens of times per second. For example,
one demo was to put a "smiley face" drawn with H19 graphics on the
second window, and swap it in/out 30 times a second, in a different
screen location each time. This gave the appearance of a normal screen
display but with a transparent "sprite" bouncing around the screen.

The window was implemented by a trick. The second window was *not* in
screen memory! The Z80 waited for a vertical interrupt from the 6845
(beam being reset from bottom to top of screen), and started a timer. At
the instant the 2nd window is to begin, the Z80 swapped the 2nd window
bytes and main screen bytes; this put the window on the screen. When
enough time passed for the beam to move to the right edge of the window,
the Z80 swapped the bytes back again. Doing it this way meant no
additional screen memory was needed (the H19 only had 2k of screen
memory). During the time it took the beam to do 10 scan lines (the
height of a character cell on the H19), the Z80 could swap 32 bytes in
and back out of screen memory, so the window could be up to 32
characters wide. This with a 3 MHz Z80 and only 2k bytes of RAM.

Post by Claudio Puviani
The 7220, which you mentioned, would definitely make a Z80-based
GUI responsive, but I don't remember any Z80 systems that were built
with it. I'd be interested to know of any.

An example from the Heath world, just because I am most familiar with
it. The Northwest Digital GP29 "Graphics Plus" board replaced the stock
terminal board with one having the 7220, 128k bytes of RAM, and
(strangely enough) an 8051 as its CPU. It did quite well graphically,
but the 8051 couldn't go nearly as fast as the Z80 at handling the CP/M
console interface.

Post by Claudio Puviani
The thing is, if we get to design new hardware, we can circumvent
almost any limitation, but using 1970s-1980s hardware, it's just
not very practical.

Xerox certainly found this true in the 1970's; the Altos was too
expensive to be economically viable. Apple tried again with the Lisa in
1982; still expensive. The Mac became the first affordable GUI in 1984.

Now, the 68000 probably made it easier to design the Mac; but it was
also a very expensive chip in 1984. Apple worked *very* hard to keep the
hardware price down; I suspect they could also have used the cheaper Z80
with more support chips to do the same thing. But they didn't; Apple's
experience was with the 6502, and the 68000 probably looked a lot more
familiar.

[Christopher Browne]

Post by Lee Hart

Post by Claudio Puviani
The Palm Pilots I'm familiar with are based on the Dragonball
processor, which is a modern implementation of the 68000
instruction set. I guess you mean other organizers like the
Sharp Wizard.

No; I was thinking of all the early Palm Pilots, which I think ran Z80
derivitives. Does anyone know for sure? I don't think the Dragonball
even existed back then.

No, they ran 68K hardware. 8MHz CPUs, if memory serves. I had a Palm
1000; the compilers didn't change 'til they started using StrongARM
chips.

[Michael J. Mahon]

Claudio Puviani wrote:

<snip>

Post by Claudio Puviani
The C64 solved some of these issues by having "helper" chips, which is
why GEOS was possible.

GEOS was ported to the Apple II, which had no "helper" chips,
but the interface was still quite usable.

If you are referring to the sprite capabilities of the C64, I doubt
that it was very useful to GEOS, except as a mouse cursor
optimization.

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[Exegete]

<snip>

Post by Lee Hart

Post by Michael J. Mahon
GUIs were developed for machines having standard, memory-mapped
graphics that were replicated enough to make the development of a
GUI justifiable. One-off GUIs are a lot of work for little benefit,
except the education of the writer. ;-)

Yes; exactly! Writing a GUI is a *lot* of work! It is beyond the talents
of a single individual -- it requires the massive, sustained efforts of
a large number of very talented people.

I realize that I am not in your league, but may I humbly point out that
DRI's GEM was created, according to the "about" box, by fewer than five
programmers (three, if I remember correctly.) I believe that the Mac's
OS was also created by a relatively small team - relative to the human
wave that M$ uses that is.

None of the early microcomputer

Post by Lee Hart
companies could produce such a product. It wasn's so much that the
hardware stopped them; that could be fixed. It was that they couldn't
afford the software development.

If you mean the 70s, by "early" I'm not so sure you are correct. I think
that it was, if you'll pardon a Bushism, "the vision thing." And, as
pointed out above, DRI's GEM was on the market in the mid 80s for the
humble 8088 with less than 512K before M$'s abortion ever saw the light
of day. Further, the humble Apple II, with 128K and a 1 mhz 6502 had TWO
GUIs. The TRS CoCo 3 had a GUI, as did the C-64, and these were all 8
bit machines running at 1-3 mhz, with 64-128K of RAM. Also, once GUIs
caught on, there were GUIs created by third parties for the Atari 8 bit
machines and even the Coleco ADAM (a Z-80 based machine - I have to
confess, I've never even see a screen shot of the latter, but I had read
of it.)

Roy

Post by Lee Hart
However, once a few companies have done it (Xerox, Apple, Microsoft), it
becomes far easier for others to "stand on their shoulders" and produce
a GUI for far less work. So, perhaps a GUI for CP/M has progressed from
"impossible" in 1980 to "merely difficult" in 2004. :-)
If one doubts that a GIU is possible on a Z80, remember that many of the
Palm Pilot organizers are Z80-based.
--
Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[John T Maguire]

On Tue, 11 May 2004 07:58:29 -0500, Exegete

Post by Exegete
<snip>

Post by Lee Hart

Post by Michael J. Mahon
GUIs were developed for machines having standard, memory-mapped
graphics that were replicated enough to make the development of a
GUI justifiable. One-off GUIs are a lot of work for little benefit,
except the education of the writer. ;-)

Yes; exactly! Writing a GUI is a *lot* of work! It is beyond the talents
of a single individual -- it requires the massive, sustained efforts of
a large number of very talented people.

I realize that I am not in your league, but may I humbly point out that
DRI's GEM was created, according to the "about" box, by fewer than five
programmers (three, if I remember correctly.) I believe that the Mac's
OS was also created by a relatively small team - relative to the human
wave that M$ uses that is.

Among the developers of the original Mac OS was, of course,
Microsoft.

John

[Exegete]

John T Maguire wrote:

<snip>

Post by John T Maguire

Post by Exegete
I realize that I am not in your league, but may I humbly point out that
DRI's GEM was created, according to the "about" box, by fewer than five
programmers (three, if I remember correctly.) I believe that the Mac's
OS was also created by a relatively small team - relative to the human
wave that M$ uses that is.

Among the developers of the original Mac OS was, of course,
Microsoft.
John

I've never read anything that suggested that John. I'm curious to know
where you obtained that information.

Roy



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[John T Maguire]

On Tue, 11 May 2004 13:09:17 -0500, Exegete

Post by Exegete
<snip>

Post by John T Maguire

Post by Exegete
I realize that I am not in your league, but may I humbly point out that
DRI's GEM was created, according to the "about" box, by fewer than five
programmers (three, if I remember correctly.) I believe that the Mac's
OS was also created by a relatively small team - relative to the human
wave that M$ uses that is.

Among the developers of the original Mac OS was, of course,
Microsoft.
John

I've never read anything that suggested that John. I'm curious to know
where you obtained that information.

I stumbled across a copy of the "Premiere Edition" of
MacWorld years ago. It includes an interview with Bill Gates
where David Bunnell states "...Gates and a team of
programmers were writing software and participating in the
Mac's development."

John

[Michael J. Mahon]

Post by John T Maguire
On Tue, 11 May 2004 13:09:17 -0500, Exegete

Post by Exegete
<snip>

Post by John T Maguire

Post by Exegete
I realize that I am not in your league, but may I humbly point out that
DRI's GEM was created, according to the "about" box, by fewer than five
programmers (three, if I remember correctly.) I believe that the Mac's
OS was also created by a relatively small team - relative to the human
wave that M$ uses that is.

Among the developers of the original Mac OS was, of course,
Microsoft.
John

I've never read anything that suggested that John. I'm curious to know
where you obtained that information.

I stumbled across a copy of the "Premiere Edition" of
MacWorld years ago. It includes an interview with Bill Gates
where David Bunnell states "...Gates and a team of
programmers were writing software and participating in the
Mac's development."

Microsoft had nothing to do with the development of the Mac GUI.

They were evangelized to write applications for the new interface.

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[John T Maguire]

Post by Michael J. Mahon

Post by John T Maguire
On Tue, 11 May 2004 13:09:17 -0500, Exegete

Post by Exegete
<snip>

Post by John T Maguire

Post by Exegete
I realize that I am not in your league, but may I humbly point out that
DRI's GEM was created, according to the "about" box, by fewer than five
programmers (three, if I remember correctly.) I believe that the Mac's
OS was also created by a relatively small team - relative to the human
wave that M$ uses that is.

Among the developers of the original Mac OS was, of course,
Microsoft.
John

I've never read anything that suggested that John. I'm curious to know
where you obtained that information.

I stumbled across a copy of the "Premiere Edition" of
MacWorld years ago. It includes an interview with Bill Gates
where David Bunnell states "...Gates and a team of
programmers were writing software and participating in the
Mac's development."

Microsoft had nothing to do with the development of the Mac GUI.
They were evangelized to write applications for the new interface.

Evangelized? Is that MacSpeak? Now if you'd bothered to read
what I replied to, you'r have known it was about the
development of the OS, not the GUI.

[Michael J. Mahon]

Post by John T Maguire

Post by Michael J. Mahon

Post by John T Maguire
On Tue, 11 May 2004 13:09:17 -0500, Exegete

Post by Exegete
<snip>

Post by John T Maguire

Post by Exegete
I realize that I am not in your league, but may I humbly point out that
DRI's GEM was created, according to the "about" box, by fewer than five
programmers (three, if I remember correctly.) I believe that the Mac's
OS was also created by a relatively small team - relative to the human
wave that M$ uses that is.

Among the developers of the original Mac OS was, of course,
Microsoft.
John

I've never read anything that suggested that John. I'm curious to know
where you obtained that information.

I stumbled across a copy of the "Premiere Edition" of
MacWorld years ago. It includes an interview with Bill Gates
where David Bunnell states "...Gates and a team of
programmers were writing software and participating in the
Mac's development."

Microsoft had nothing to do with the development of the Mac GUI.
They were evangelized to write applications for the new interface.

Evangelized? Is that MacSpeak? Now if you'd bothered to read
what I replied to, you'r have known it was about the
development of the OS, not the GUI.

Yes, "evangelized" is a standard Apple term for recruiting software
developers. It has been around almost as long as the Mac itself. ;-)

Since this thread is about GUIs, I said GUI. The GUI is much more
complex than the OS (the Finder), and Microsoft had nothing to do
with that, either.

"Involved" is PR-speak for "we want the world to know that lots of
important people are interested in what we are doing", and in this
case, the deepest "involvement" conceivable is that Microsoft
reviewed the Mac OS documentation prior to deciding how they
would support it and when Word and Excel might exist.

Be assured that Microsoft did not write any code for the Mac OS,
though they were no doubt very interested in seeing it.

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[John T Maguire]

Post by Michael J. Mahon

Post by John T Maguire

Post by Michael J. Mahon

Post by John T Maguire
On Tue, 11 May 2004 13:09:17 -0500, Exegete

Post by Exegete
<snip>

Post by John T Maguire

Post by Exegete
I realize that I am not in your league, but may I humbly point out that
DRI's GEM was created, according to the "about" box, by fewer than five
programmers (three, if I remember correctly.) I believe that the Mac's
OS was also created by a relatively small team - relative to the human
wave that M$ uses that is.

Among the developers of the original Mac OS was, of course,
Microsoft.
John

I've never read anything that suggested that John. I'm curious to know
where you obtained that information.

I stumbled across a copy of the "Premiere Edition" of
MacWorld years ago. It includes an interview with Bill Gates
where David Bunnell states "...Gates and a team of
programmers were writing software and participating in the
Mac's development."

Microsoft had nothing to do with the development of the Mac GUI.
They were evangelized to write applications for the new interface.

Evangelized? Is that MacSpeak? Now if you'd bothered to read
what I replied to, you'r have known it was about the
development of the OS, not the GUI.

Yes, "evangelized" is a standard Apple term for recruiting software
developers. It has been around almost as long as the Mac itself. ;-)

That figures

Post by Michael J. Mahon
Since this thread is about GUIs, I said GUI. The GUI is much more
complex than the OS (the Finder), and Microsoft had nothing to do
with that, either.

Which makes you what, other than wrong...sounds like a troll
to me.

Post by Michael J. Mahon
"Involved" is PR-speak for "we want the world to know that lots of
important people are interested in what we are doing", and in this
case, the deepest "involvement" conceivable is that Microsoft
reviewed the Mac OS documentation prior to deciding how they
would support it and when Word and Excel might exist.

M$ was on board in late 1981.

Post by Michael J. Mahon
Be assured that Microsoft did not write any code for the Mac OS,
though they were no doubt very interested in seeing it.

It's pretty obvious your belief system won't allow this
MacWorld article to exist. I wasn't there, and in fact I
just found it interesting, and thought others might too.
:
"We didn't realize that we needed to do so much work with
the memory manager, menus, and dialog boxes. Nor did we know
how we were going to make the Finder work..."

Oops!

[Michael J. Mahon]

Post by John T Maguire

Post by Michael J. Mahon

Post by John T Maguire

Post by Michael J. Mahon

Post by John T Maguire
On Tue, 11 May 2004 13:09:17 -0500, Exegete

Post by Exegete
<snip>

Post by John T Maguire

Post by Exegete
I realize that I am not in your league, but may I humbly point out

that

Post by Michael J. Mahon

Post by John T Maguire

Post by Michael J. Mahon

Post by John T Maguire

Post by Exegete

Post by John T Maguire

Post by Exegete
DRI's GEM was created, according to the "about" box, by fewer than

five

Post by Michael J. Mahon

Post by John T Maguire

Post by Michael J. Mahon

Post by John T Maguire

Post by Exegete

Post by John T Maguire

Post by Exegete
programmers (three, if I remember correctly.) I believe that the Mac's
OS was also created by a relatively small team - relative to the human
wave that M$ uses that is.

Among the developers of the original Mac OS was, of course,
Microsoft.
John

I've never read anything that suggested that John. I'm curious to know
where you obtained that information.

I stumbled across a copy of the "Premiere Edition" of
MacWorld years ago. It includes an interview with Bill Gates
where David Bunnell states "...Gates and a team of
programmers were writing software and participating in the
Mac's development."

Microsoft had nothing to do with the development of the Mac GUI.
They were evangelized to write applications for the new interface.

Evangelized? Is that MacSpeak? Now if you'd bothered to read
what I replied to, you'r have known it was about the
development of the OS, not the GUI.

Yes, "evangelized" is a standard Apple term for recruiting software
developers. It has been around almost as long as the Mac itself. ;-)

That figures

I'm not a Mac addict, though I do occasionally use one.

I'm am a bit familiar with the Apple culture, having known and
worked with several Apple employees.

Post by John T Maguire

Post by Michael J. Mahon
Since this thread is about GUIs, I said GUI. The GUI is much more
complex than the OS (the Finder), and Microsoft had nothing to do
with that, either.

Which makes you what, other than wrong...sounds like a troll
to me.

No, I was just answering the allegation that you made: that
Microsoft helped write the Mac OS and GUI (which were, in fact,
inseparable until the quite recent OS X).

Post by John T Maguire

Post by Michael J. Mahon
"Involved" is PR-speak for "we want the world to know that lots of
important people are interested in what we are doing", and in this
case, the deepest "involvement" conceivable is that Microsoft
reviewed the Mac OS documentation prior to deciding how they
would support it and when Word and Excel might exist.

M$ was on board in late 1981.

Post by Michael J. Mahon
Be assured that Microsoft did not write any code for the Mac OS,
though they were no doubt very interested in seeing it.

It's pretty obvious your belief system won't allow this
MacWorld article to exist. I wasn't there, and in fact I
just found it interesting, and thought others might too.

Boy, it's pretty clear that I'm not the only one with a
belief system!

You quoted: "...Gates and a team of programmers were writing
software and participating in the Mac's development."

This does not say _what_ software they were writing.
Doesn't it seem more likely that they were working on
software that Microsoft would sell?

Why would you think that Jobs, surely one of the best
known control freaks in the world, would let _anyone_ not
under his direct control play any critical role in the creation
of the Mac OS? Have you actually read much about how
the Mac and its OS came to be?

Jobs wouldn't even let people from other Apple divisions
work on it!

If you have a reliable reference that states that Microsoft
employees participated directly in the _design and coding_
of the Mac OS, bring it on.

Post by John T Maguire
"We didn't realize that we needed to do so much work with
the memory manager, menus, and dialog boxes. Nor did we know
how we were going to make the Finder work..."
Oops!

Oops, what?

The "we" here refers to the dozen or so Apple employees who
"invented" the Mac OS, inspired by the behavior of the PARC
systems that they had seen.

As has been pointed out several times in this thread, writing
a GUI, and the OS on which it runs, involves some complexities.
But they are not more than a dozen people can handle (and
several of those were not actually programmers, but worked
on asthetics, like icon, window, and menu design).

The GEOS team did it with about a half-dozen.

The first one that you write is always the hardest. ;-)

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[Jan Vanden Bossche]

Hallo

Actually, this is not really about CP/M anymore, is it ?

Post by John T Maguire

Post by John T Maguire

Post by John T Maguire
Among the developers of the original Mac OS was, of course,
Microsoft.

I stumbled across a copy of the "Premiere Edition" of
MacWorld years ago. It includes an interview with Bill Gates
where David Bunnell states "...Gates and a team of
programmers were writing software and participating in the
Mac's development."

That could also be interpreted as: they were writing software for it and
thus aiding the development of the Mac as a platform. And maybe gave
feedback about bugs in the OS.

Post by John T Maguire
M$ was on board in late 1981.

To be honest, never heard of that one either. And I have done my share of
reading on the topic of computer history. AFAIK, not even gates himself
mentiones it.

Post by John T Maguire
It's pretty obvious your belief system won't allow this
MacWorld article to exist.

If it is written as you quote it - any digital copy around ? - then it's
still open for interpretation.

Post by John T Maguire
"We didn't realize that we needed to do so much work with
the memory manager, menus, and dialog boxes. Nor did we know
how we were going to make the Finder work..."

Does that mean they needed MS to solve it ?

Look at this: http://toastdesign.com/apple1984ad/d10gatesEtc.html
L to R, Bill Gates (Microsoft), Mitch Kapor (Lotus), Fred Gibbons (Software
Publishing Corporation), all with a Mac shirt. 3 big software companies in
those days, willing to support the new Mac environment.

Post by John T Maguire
Oops!

...

Post by John T Maguire
John T Maguire, Kennebunkport

Greetings from the TyRannoSaurus
Jan-80

[Jan Vanden Bossche]

Hallo

Post by Jan Vanden Bossche

Post by John T Maguire

Post by John T Maguire
I stumbled across a copy of the "Premiere Edition" of
MacWorld years ago. It includes an interview with Bill Gates
where David Bunnell states "...Gates and a team of
programmers were writing software and participating in the
Mac's development."

That could also be interpreted as: they were writing software for it and
thus aiding the development of the Mac as a platform. And maybe gave
feedback about bugs in the OS.

This interview with Bill Gates confirms my interpretation.
http://americanhistory.si.edu/csr/comphist/gates.htm#tc46

Quote: "So Microsoft worked very closely with the early Macintosh team. We
were their testing group. They had no testers. We helped shaped the features
of the machine."

Post by Jan Vanden Bossche

Post by John T Maguire
M$ was on board in late 1981.

That is confirmed too.

Quote: "When Steve first came to us it was supposed to ship in early '82 at
$995 dollars. Well, it ended up shipping in January of 1984 at $2,495
dollars." If Steve wanted to ship in '82, that must have been '81 when he
came to talk to Gates.

Post by Jan Vanden Bossche
To be honest, never heard of that one either. And I have done my share of
reading on the topic of computer history. AFAIK, not even gates himself
mentiones it.

So, I stand corrected. MS did know in '81 about the Mac.

Post by Jan Vanden Bossche
Look at this: http://toastdesign.com/apple1984ad/d10gatesEtc.html
L to R, Bill Gates (Microsoft), Mitch Kapor (Lotus), Fred Gibbons (Software
Publishing Corporation), all with a Mac shirt. 3 big software companies in
those days, willing to support the new Mac environment.

MS even wrote MS-BASIC for the Mac. Any of those around ?

Greetings from the TyRannoSaurus
Jan-80

[Exegete]

Post by Jan Vanden Bossche
Hallo

Post by Jan Vanden Bossche

Post by John T Maguire

Post by John T Maguire
I stumbled across a copy of the "Premiere Edition" of
MacWorld years ago. It includes an interview with Bill Gates
where David Bunnell states "...Gates and a team of
programmers were writing software and participating in the
Mac's development."

That could also be interpreted as: they were writing software for it and
thus aiding the development of the Mac as a platform. And maybe gave
feedback about bugs in the OS.

This interview with Bill Gates confirms my interpretation.
http://americanhistory.si.edu/csr/comphist/gates.htm#tc46
Quote: "So Microsoft worked very closely with the early Macintosh team. We
were their testing group. They had no testers. We helped shaped the features
of the machine."

Even that isn't quite true. Apple wrote the first two applications for
the Mac, and they (the programmers of the apps) were testers of the OS.
The OS was worked on so Mac Write and Mac Paint would still work.

It doesn't deny that MS was involved in the Mac project, nor that they
wrote the first really powerful apps for the Mac (Word vs Write is no
contest), but, again, it doesn't mean that they wrote or helped write
the OS.

Roy

Post by Jan Vanden Bossche

Post by Jan Vanden Bossche

Post by John T Maguire
M$ was on board in late 1981.

That is confirmed too.
Quote: "When Steve first came to us it was supposed to ship in early '82 at
$995 dollars. Well, it ended up shipping in January of 1984 at $2,495
dollars." If Steve wanted to ship in '82, that must have been '81 when he
came to talk to Gates.

Post by Jan Vanden Bossche
To be honest, never heard of that one either. And I have done my share of
reading on the topic of computer history. AFAIK, not even gates himself
mentiones it.

So, I stand corrected. MS did know in '81 about the Mac.

Post by Jan Vanden Bossche
Look at this: http://toastdesign.com/apple1984ad/d10gatesEtc.html
L to R, Bill Gates (Microsoft), Mitch Kapor (Lotus), Fred Gibbons

(Software

Post by Jan Vanden Bossche
Publishing Corporation), all with a Mac shirt. 3 big software companies in
those days, willing to support the new Mac environment.

MS even wrote MS-BASIC for the Mac. Any of those around ?
Greetings from the TyRannoSaurus
Jan-80

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Anonymous Guy]

Post by Exegete

Post by Jan Vanden Bossche
This interview with Bill Gates confirms my interpretation.
http://americanhistory.si.edu/csr/comphist/gates.htm#tc46
Quote: "So Microsoft worked very closely with the early Macintosh
team. We were their testing group. They had no testers. We helped
shaped the features of the machine."

Even that isn't quite true. Apple wrote the first two applications
for the Mac, and they (the programmers of the apps) were testers of
the OS. The OS was worked on so Mac Write and Mac Paint would still
work.
It doesn't deny that MS was involved in the Mac project, nor that
they wrote the first really powerful apps for the Mac (Word vs
or helped write the OS.

Everything that Sir Bill has ever written about computer
"history" has been full of self-aggrandizing inaccuracies.

Anything he says should always be taken with an extra-large
grain of salt.

[Exegete]

Post by John T Maguire
On Tue, 11 May 2004 13:09:17 -0500, Exegete

Post by Exegete
<snip>

Post by John T Maguire

Post by Exegete
I realize that I am not in your league, but may I humbly point out that
DRI's GEM was created, according to the "about" box, by fewer than five
programmers (three, if I remember correctly.) I believe that the Mac's
OS was also created by a relatively small team - relative to the human
wave that M$ uses that is.

Among the developers of the original Mac OS was, of course,
Microsoft.
John

I've never read anything that suggested that John. I'm curious to know
where you obtained that information.

I stumbled across a copy of the "Premiere Edition" of
MacWorld years ago. It includes an interview with Bill Gates
where David Bunnell states "...Gates and a team of
programmers were writing software and participating in the
Mac's development."

Ummm, that statement, on the surface, doesn't support what you said.
"Participating in the Mac's development" doesn't mean the same thing as
"Developers of the original Mac OS."

I've read several Apple oriented books, including "Insanely Great" by
Steve Levy, and NONE of them said anything about M$ helping to write the
Mac OS. All indicated that the OS was an internal project. That doesn't
mean that Microsoft didn't have anything to do with the "development" of
the Mac, but it also creates a problem for your conclusion.

Roy

Post by John T Maguire
John

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Kelli Halliburton]

Post by John T Maguire
Among the developers of the original Mac OS was, of course,
Microsoft.

Among the developers FOR the original Mac OS was, of course, Microsoft.

Microsoft was in on the ground floor, knew what Apple was doing, was very
much interested in what was going on, was very interested in writing
software for the new System. They used a lot of what they learned from Apple
in writing Windows 1.0 et sequelae.

They had no input into the design of the OS nor the GUI.

Even with all the inside access they had, Word and Multiplan still took a
long time to be released for the Mac (Multiplan being the predecessor to
Excel).

[Lee Hart]

Writing a GUI is a *lot* of work! It is beyond the talents of
a single individual -- it requires the massive, sustained efforts
of a large number of very talented people.

may I humbly point out that DRI's GEM was created, according to
the "about" box, by fewer than five programmers (three, if I
remember correctly.) I believe that the Mac's OS was also created
by a relatively small team

I think we agree, though we might differ on the meaning of 'many'. We'll
never know the real cost, but I would not be surprised if Xerox spent
100's of man-years to create the GUI for the Altos. Apple, having a
working example to copy, probably needed 10's man-years of software
development for the Lisa and Mac. And this is just the direct
programmer's time; it wouldn't include all the support staff and
overhead needed.

This sort of time commitment was out of reach of the early microcomputer
companies. (It probably was out of reach for Apple, too -- but they did
it anyway! :-)

If you mean the 70s, by "early" I'm not so sure you are correct.
I think that it was, if you'll pardon a Bushism, "the vision thing."

In the 1970's Xerox invented the GUI. PARC certainly had the vision, and
Xerox had the resources. No one else had that combination; so no one
else did it.

DRI's GEM was on the market in the mid 80s

Yes, but they were the 3rd implementer, after Xerox and Apple. As I
said, it kept getting easier for each subsequent implementer, because
they could build on what went before.

Further, the humble Apple II, with 128K and a 1 mhz 6502 had TWO
GUIs. The TRS CoCo 3 had a GUI, as did the C-64, and these were
all 8 bit machines running at 1-3 mhz, with 64-128K of RAM. Also,
once GUIs caught on, there were GUIs created by third parties
for the Atari 8 bit machines and even the Coleco ADAM (a Z-80
based machine - I have to confess, I've never even see a screen
shot of the latter, but I had read of it.)

Precisely! It kept getting easier and easier, as both the hardware and
software development tools improved.
--
"Never doubt that a small group of committed people can change the
world. Indeed, it's the only thing that ever has!" -- Margaret Meade
--
Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net

[Exegete]

Lee Hart wrote:

<snip>

Post by Lee Hart

Post by Exegete
DRI's GEM was on the market in the mid 80s

Yes, but they were the 3rd implementer, after Xerox and Apple.

Small quibble - it's my understanding that GEM was under development
before the Mac saw the light of day, though the Mac was finished first.
Perhaps DRI was inspired by the Lisa?

Roy



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Michael J. Mahon]

Post by Lee Hart

Writing a GUI is a *lot* of work! It is beyond the talents of
a single individual -- it requires the massive, sustained efforts
of a large number of very talented people.

may I humbly point out that DRI's GEM was created, according to
the "about" box, by fewer than five programmers (three, if I
remember correctly.) I believe that the Mac's OS was also created
by a relatively small team

I think we agree, though we might differ on the meaning of 'many'. We'll
never know the real cost, but I would not be surprised if Xerox spent
100's of man-years to create the GUI for the Altos. Apple, having a
working example to copy, probably needed 10's man-years of software
development for the Lisa and Mac. And this is just the direct
programmer's time; it wouldn't include all the support staff and
overhead needed.
This sort of time commitment was out of reach of the early microcomputer
companies. (It probably was out of reach for Apple, too -- but they did
it anyway! :-)

Wrong. The core of the Mac GUI was written entirely in assembly
language by at most two people (the optimal number, in my
experience ;-).

The upper level functions, which are much less performance-critical
were written in Pascal, if memory serves, by perhaps a half-dozen
people.

Post by Lee Hart

If you mean the 70s, by "early" I'm not so sure you are correct.
I think that it was, if you'll pardon a Bushism, "the vision thing."

In the 1970's Xerox invented the GUI. PARC certainly had the vision, and
Xerox had the resources. No one else had that combination; so no one
else did it.

DRI's GEM was on the market in the mid 80s

Yes, but they were the 3rd implementer, after Xerox and Apple. As I
said, it kept getting easier for each subsequent implementer, because
they could build on what went before.

They were at least the fourth implementor.

VisiCorp had VisiOn in 1984, and it had many of the elements that
were polished in the Mac. Many were amazed that such a thing
could be accomplished on an 8088--and its sluggishness was a major
issue.

Post by Lee Hart

Further, the humble Apple II, with 128K and a 1 mhz 6502 had TWO
GUIs. The TRS CoCo 3 had a GUI, as did the C-64, and these were
all 8 bit machines running at 1-3 mhz, with 64-128K of RAM. Also,
once GUIs caught on, there were GUIs created by third parties
for the Atari 8 bit machines and even the Coleco ADAM (a Z-80
based machine - I have to confess, I've never even see a screen
shot of the latter, but I had read of it.)

Precisely! It kept getting easier and easier, as both the hardware and
software development tools improved.

Whoa! The hardware of the 8-bit Apple II _never_ improved, and the
only software development tool that could be used for a GUI on that
machine was assembler.

The only thing that "improved" was the knowledge about what
elements made a usable graphical interface, and what tricks
could be used to implement them--no tools and no hardware.

GEOS was an act of software genius from a small outfit
staffed by Berkeley students. A "human wave" is an obstacle
to producing tight, lean software, not an enabler.

What the Apple II and the C64 share, in addition to a 1MHz 6502,
is direct-mapped video memory and a pixel update rate of a few
cycles per pixel in BITBLT loops.

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[Jan Vanden Bossche]

Hallo

Post by Michael J. Mahon
The core of the Mac GUI was written entirely in assembly
language by at most two people

[..]

Post by Michael J. Mahon

Post by Exegete
DRI's GEM was on the market in the mid 80s

[..]

Post by Michael J. Mahon
They were at least the fourth implementor.
VisiCorp had VisiOn in 1984, and it had many of the elements that
were polished in the Mac. Many were amazed that such a thing
could be accomplished on an 8088--and its sluggishness was a major
issue.

FYI: http://www.fortunecity.com/marina/reach/435/vision.htm

And this site has other examples of (graphical) user interfaces.

Post by Michael J. Mahon
Whoa! The hardware of the 8-bit Apple II _never_ improved,

Didn't CPU speed improve, display cards, bus speed, ... ? In all those years
that the II was on the market, did they never improve it ?

Post by Michael J. Mahon
GEOS was an act of software genius from a small outfit
staffed by Berkeley students.

Didn't know that.

Post by Michael J. Mahon
What the Apple II and the C64 share, in addition to a 1MHz 6502,
is direct-mapped video memory and a pixel update rate of a few
cycles per pixel in BITBLT loops.

I'm afraid that most CP/M systems don't have that. So the idea of GUI,
implemented on all those systems, is a futile one. A text-based UI, a
program starter/file manager is doable. See the above site for examples of
early UI. Like the DOS-SHELL from DOS 5.0, I liked that one. (not the one
from DOS 4.0)

Is there such a thing already for CP/M ?

Post by Michael J. Mahon
-michael

Greetings from the TyRannoSaurus
Jan-80

[Steve "Usotsuki" Nickolas]

Post by Jan Vanden Bossche
Didn't CPU speed improve, display cards, bus speed, ... ? In all those years
that the II was on the market, did they never improve it ?

Display went from 280x192 to 560x192, or in text mode from 40x24 to
80x24. Basically that's it.

-uso.

[Michael J. Mahon]

Post by Jan Vanden Bossche
Hallo

Post by Michael J. Mahon
The core of the Mac GUI was written entirely in assembly
language by at most two people

[..]

Post by Michael J. Mahon

Post by Exegete
DRI's GEM was on the market in the mid 80s

[..]

Post by Michael J. Mahon
They were at least the fourth implementor.
VisiCorp had VisiOn in 1984, and it had many of the elements that
were polished in the Mac. Many were amazed that such a thing
could be accomplished on an 8088--and its sluggishness was a major
issue.

FYI: http://www.fortunecity.com/marina/reach/435/vision.htm
And this site has other examples of (graphical) user interfaces.

Thanks--that is a great reference. I thought I remembered seeing
it first at a computer show in the fall of 1983, but I didn't trust
my memory of if coming out _before_ the Mac. ;-)

Post by Jan Vanden Bossche

Post by Michael J. Mahon
Whoa! The hardware of the 8-bit Apple II _never_ improved,

Didn't CPU speed improve, display cards, bus speed, ... ? In all those years
that the II was on the market, did they never improve it ?

The only improvement to CPU speed on 8-bit Apple II's was in
the very-low-volume Apple IIc+. All other Apple II machines had
a 1.02Mhz 6502 or 65C02.

There were no improvements in the video capabilities until the
Apple //e, which doubled horizontal resolution to 560 pixels.
This actually increases the load on the processor making
screen updates.

Bus speed is fixed by the machine's design, because of a
lockstep relationship with video refresh.

(Bus speed and processor speed were the same thing until
caches and phase-locked loops.)

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[Roger Ivie]

Post by Michael J. Mahon
The only improvement to CPU speed on 8-bit Apple II's was in
the very-low-volume Apple IIc+. All other Apple II machines had
a 1.02Mhz 6502 or 65C02.

Don't forget about the IIgs, which used the 65816...

[Bettykate]

Post by Roger Ivie

Post by Michael J. Mahon
The only improvement to CPU speed on 8-bit Apple II's was in
the very-low-volume Apple IIc+. All other Apple II machines had
a 1.02Mhz 6502 or 65C02.

Don't forget about the IIgs, which used the 65816...

He said 8-bit Apple ][s. ;) That precludes the IIgs, which was a 16-bit
machine.

-uso.

[Exegete]

Post by Roger Ivie

Post by Michael J. Mahon
The only improvement to CPU speed on 8-bit Apple II's was in
the very-low-volume Apple IIc+. All other Apple II machines had
a 1.02Mhz 6502 or 65C02.

Don't forget about the IIgs, which used the 65816...

Which was a 16 bit processor. Michael wrote about the 8 bit Apple IIs.
In an earlier post he explicitly excluded the IIgs.

Roy



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Michael J. Mahon]

Post by Roger Ivie

Post by Michael J. Mahon
The only improvement to CPU speed on 8-bit Apple II's was in
the very-low-volume Apple IIc+. All other Apple II machines had
a 1.02Mhz 6502 or 65C02.

Don't forget about the IIgs, which used the 65816...

I didn't forget, Roger--I explicitly referred to "8-bit Apple II's"
to exclude the IIgs, for which no 16-bit version of GEOS was
ever produced.

I guess I should repeat "8-bit Apple II's" every time I refer to
them in a post...

Of course, the IIgs has a very sophistocated GUI-based OS
in GSOS.

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page: http://members.aol.com/MJMahon/

[Roger Ivie]

Post by Michael J. Mahon

Post by Roger Ivie

Post by Michael J. Mahon
The only improvement to CPU speed on 8-bit Apple II's was in
the very-low-volume Apple IIc+. All other Apple II machines had
a 1.02Mhz 6502 or 65C02.

Don't forget about the IIgs, which used the 65816...

I didn't forget, Roger--I explicitly referred to "8-bit Apple II's"
to exclude the IIgs, for which no 16-bit version of GEOS was
ever produced.

Guess that's what I get for jumping into the middle of a conversation...

[Kelli Halliburton]

Post by Roger Ivie

Post by Michael J. Mahon
The only improvement to CPU speed on 8-bit Apple II's was in

^^^^^

Post by Roger Ivie

Post by Michael J. Mahon
the very-low-volume Apple IIc+. All other Apple II machines had
a 1.02Mhz 6502 or 65C02.

Don't forget about the IIgs, which used the 65816...

...which was 16-bit. Note the part marked by ^^^^^ in the earlier post,
which establishes the discussion as not including 16-bit Apple II designs.

[Kelli Halliburton]

Post by Lee Hart
If one doubts that a GIU is possible on a Z80, remember that many of
the Palm Pilot organizers are Z80-based.

For certain values of "Z80" that include "68000," that is.

The DragonBall processor that drives early Palm models is very much Motorola
68000-based, not at all Z80-based.

[Lee Hart]

Post by Kelli Halliburton

Post by Lee Hart
If one doubts that a GIU is possible on a Z80, remember that many
of the Palm Pilot organizers are Z80-based.

For certain values of "Z80" that include "68000," that is.

Ok; my mistake. I could have sworn that I read that the early Palms used
a Z80 derivitive. Must have been some other palm-like device (someone
mentioned the Sharp Wizards?)

[Richard]

Post by Lee Hart
Ok; my mistake. I could have sworn that I read that the early Palms used
a Z80 derivitive. Must have been some other palm-like device (someone
mentioned the Sharp Wizards?)

Not thinking of the original GameBoy were you ? That was a Z80
derivitive. There is a GameBoy emulator that runs on Palm Pilot.

[Brian Vacha]

Post by Richard

Post by Lee Hart
Ok; my mistake. I could have sworn that I read that the early Palms used
a Z80 derivitive. Must have been some other palm-like device (someone
mentioned the Sharp Wizards?)

Not thinking of the original GameBoy were you ? That was a Z80
derivitive. There is a GameBoy emulator that runs on Palm Pilot.

Try this Ti Avego
http://www.ti.com/avigo/


Brian Vacha

[bud]

Post by Brian Vacha
Try this Ti Avego
http://www.ti.com/avigo/
Brian Vacha

Yes. Q11 of the FAQ:

"highly customized version of Z80."

salaam,
dowcom

[Claudio Puviani]

Post by Lee Hart

Post by wild bill
On Sun, 25 Apr 2004 23:14:52 +0200, Peter Smith

Post by Peter Smith
I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with

...... with virtually *anything* I suspect

I think you are overly pessimistic. There have been quite a few
computers with graphical user interfaces that had what would be
considered pitiful amounts of speed and memory by today's bloated
standards.
The original GUI machine, the Xerox Alto, had roughly a 600x800 pixel
display, 128k bytes of memory, and a 16-bit CPU that executed about
400,000 instructions per second.
The first Apple Macintosh had a 512x342 pixel display, 192k bytes of
memory (RAM+ROM), and a 16-bit CPU that executed about 500,000
instructions per second.
CP/M computers can easily match these resources. While the most basic
low-cost "entry level" machines often skimped on the hardware resources,
you could add expansion graphics and memory boards to reach these levels
with essentially every model. And a 4 MHz Z80 is fast enough to execute
500,000 instructions per second.

I don't know if you haven't worked with 68000s or if you haven't worked with
Z80s, but you clearly haven't worked with both. A 6 MHz 68000 had roughly 8 times
the performance of a 4 MHz Z80 and an instruction set that made the Z80's look
infantile. The two aren't even in the same ball park. If someone had duplicated
the core functionality of the Mac GUI on a Z80, not only would it have required
hardware upgrades that would have been absurd at the time, but the result would
have been so sluggish as to make it useless. As it was, even the 68000 could
barely function comfortably with all that overhead.

Post by Lee Hart
The only real difficulty was the software. People *could* have written a
GUI operating system, but didn't. I'd say that it was simply a matter
that the sort of people attracted to CP/M systems were less likely to be
interested in GUIs, and so didn't write them. They would rather "spend"
their computer's resources on other tasks besides pretty screens and
easy user interfaces.

The real reason is that the people who had the skill and knowledge to write GUIs
knew enough to not waste their time writing one for a platform that was, by then,
already obsolete only to produce software that would have been unacceptable to
the end users.

Claudio Puviani

[Herb Johnson]

Post by Claudio Puviani

Post by Lee Hart
I think you are overly pessimistic. There have been quite a few
computers with graphical user interfaces that had what would be
considered pitiful amounts of speed and memory by today's bloated
standards....the Xerox Alto...Apple Macintosh...

I don't know if you haven't worked with 68000s or if you haven't worked with
Z80s, but you clearly haven't worked with both....The two aren't

even in the same ball park. If someone had duplicated the core
functionality of the Mac GUI on a Z80, not only would it have required
hardware upgrades that would have been absurd at the time, but the
result would have been so sluggish as to make it useless. As it was,
even the 68000 could barely function comfortably with all that
overhead.

And yet it happened. The Heath H89 WAS a Z80 system with simple
graphics.
Companies DID make expensive hardware upgrades to provide bit
graphics.
They WERE bought and people used them for various purposes. As for the
Macintosh 128K, I don't see it as particularly sluggish. I should
know,
I sell them and their successors (512K, Plus, SE, etc) every day. For
the applications they run, they run as fast by HUMAN standards as
similar
applications today.

It's a common
error these days, to use modern standards and prices and then to look
backward
and say "how absurd that people payed so much for so little, such slow
machines, tsk tsk..." It's another error, but one of ignorance, to not
know
what was available for those systems at that time. If you are not
familiar
with the history of H89 third-party products, I'm sure Mr. Hart (who
is) or others can fill you in. For that
matter there were bit-graphic products for the ADM-3 terminal, the DEC
VT-100 terminal, and of course many bit-graphic S-100 cards. I'm sorry
to say that people back then did not have the good sense to wait for
or use
faster processors and cheaper hardware as you suggest. We were too
busy
getting things done.

Post by Claudio Puviani
The real reason is that the people who had the skill and knowledge to
write GUIs knew enough to not waste their time writing one for a
platform that was,
by then, already obsolete only to produce software that would have been
unacceptable to the end users.
Claudio Puviani

I've been debating on whether this thread is just a draw for some kind
of fight or a legitimate discussion of graphics under CP/M. I find
remarks
like the above paragraph to be evidence for the former. But the gist
of the non-grumpy discussion is that any retroactive graphic
developments
for CP/M are limited today, as they were then, by the lack of
resources
in older systems. That includes a lack of standards for graphics
hardware
and limitations in memory and speed. I see no shame in all of that,
such
limits existed in the post-CP/M computer world for some years; today
such
limits only apply to extreme applications like 3D rendering and
simulation.

The other difficulty with this thread is that no applications are
specified,
so there is no performance criterion. So one can always be sour grapes
about
the situation simply by setting goals too high. Or, one can look back
and say what WAS accomplished within the so-called limits of the
times,
which of course were leading edge relative to times even more remote.
I prefer
the latter approach, as even today there are applications which are
resourse limited and which can benefit from knowledge and experience
acquired from predecessor applications in a similarly limited
environment.

It seems to me the challenge of working in a resource-limited but
FAMILIAR
and STABLE programming environment has drawn more interest in the last
few
years, not less. I see more "tribute" Web sites to CP/M, Atari, and
other classic computers every month, and new developments in hardware
and software. So
I find remarks about "wasting time" with such systems to be as ironic
today
as they were a few decades ago when CP/M was new.

Herb Johnson

Herbert R. Johnson voice 609-771-1503, New Jersey USA
<a href="http://njcc.com/~hjohnson"> link to my web site</a>
<a href="http://retrotechnology.com/herbs_stuff"> mirror of web
site</a>
email address: hjohnson AAT njcc DOTT com
(if mail bounces, try herbjohnson ATT comcast DOTT net)
good used Mac, SGI, 8-inch floppy drives
S-100 IMSAI Altair computers, , docs, by "Dr. S-100"

[Claudio Puviani]

Post by Herb Johnson

Post by Claudio Puviani

Post by Lee Hart
I think you are overly pessimistic. There have been quite a few
computers with graphical user interfaces that had what would be
considered pitiful amounts of speed and memory by today's bloated
standards....the Xerox Alto...Apple Macintosh...

I don't know if you haven't worked with 68000s or if you haven't worked with
Z80s, but you clearly haven't worked with both....The two aren't

even in the same ball park. If someone had duplicated the core
functionality of the Mac GUI on a Z80, not only would it have required
hardware upgrades that would have been absurd at the time, but the
result would have been so sluggish as to make it useless. As it was,
even the 68000 could barely function comfortably with all that
overhead.
And yet it happened. The Heath H89 WAS a Z80 system with simple
graphics.

As were many others. None of them offered a GUI on the order of the Mac. Graphics
were custom-programmed for each application.

Post by Herb Johnson
Companies DID make expensive hardware upgrades to provide bit
graphics. They WERE bought and people used them for various
purposes.

No one ever disputed that. What's in dispute is the practicality (and sanity) of
developing a Mac-scale GUI for these systems.

Post by Herb Johnson
As for the Macintosh 128K, I don't see it as particularly sluggish.

Scroll through a spreadsheet for a while and you'll see how sluggish it can be.

Post by Herb Johnson
I should know, I sell them and their successors (512K, Plus, SE, etc)
every day.

I'm sure you do. I don't see how that makes you a better authority than people
who had used and programmed the originals when they first came out.

Post by Herb Johnson
For the applications they run, they run as fast by HUMAN standards as
similar applications today.

I disagree. Taking the same example of scrolling through a speadsheet, it was
much less sluggish to navigate through Supercalc or Visicalc than it was to
navigate an Excel page on the early Macs. It was comfortable enough for someone
who ONLY knew the Mac, but for anyone used to earlier spreadsheets, the Mac
seemed slow. This doesn't negate the other advantages that Excel on the Mac
offered, but the topic here is about the performance of graphics, and the
performance of early Mac graphics was definitely just a hair over the threshold
of acceptability.

Post by Herb Johnson
It's a common error these days, to use modern standards and prices and
then to look backward and say "how absurd that people payed so much
for so little, such slow machines, tsk tsk..."

Maybe, but that's completely irrelevant to this conversation since the
comparisons we're making are between early Z80-based systems and early
68000-based systems. Neither I nor anyone else ever brought up modern systems or
standards.

Post by Herb Johnson
It's another error, but one of ignorance, to not know what was available for
those systems at that time.

If you're directing that at me, you're shooting yourself in the foot. I was
familiar with the microcomputer markets since 1976.

Post by Herb Johnson
If you are not familiar with the history of H89 third-party products, I'm sure
Mr. Hart (who is) or others can fill you in.

I'm quite familiar with the Heath/Zenith prducts. How they're in any way relevant
to the conversation is beyond me.

Post by Herb Johnson
For that matter there were bit-graphic products for the ADM-3
terminal, the DEC VT-100 terminal, and of course many
bit-graphic S-100 cards.

Big deal. Bitmap graphics were available for dozens of systems. Availability
isn't at issue, it's PERFORMANCE that was the problem.

Post by Herb Johnson
I'm sorry to say that people back then did not have the good sense to
wait for or use faster processors and cheaper hardware as you suggest.

I suggested no such thing. Either you're making things up to support a flimsy
argument, or you have problems reading what's actually written. What I said was
that no one was stupid enough to waste time writing a Mac-scale GUI for Z80
systems. Of course people used raw graphics for a variety of applications. For
someone who allegedly sells Macs every day, it's amazing that you can't make a
distinction between a full-fledged GUI and low-level graphics.

Post by Herb Johnson
We were too busy getting things done.

I was part of that "we". It's precisely because we were too busy getting things
done that we weren't engaging in idiocy like trying to implement a Mac-like GUI
on inadequate hardware.

Post by Herb Johnson

Post by Claudio Puviani
The real reason is that the people who had the skill and knowledge to
write GUIs knew enough to not waste their time writing one for a
platform that was, by then, already obsolete only to produce software
that would have been unacceptable to the end users.

I've been debating on whether this thread is just a draw for some kind
of fight or a legitimate discussion of graphics under CP/M.

This from a salesperson who's blindly spitting out accusations of ignorance to a
20-year software engineer.

Post by Herb Johnson
I find remarks like the above paragraph to be evidence for the former.

The remark that you're criticizing explains the rationale of software developers
at the time. There's nothing beligerent about it. People who program for a living
don't waste time writing software that won't sell and there's nothing wrong or
antagonistic about recognizing, in 1983, that the CP/M-80 platform was becoming
obsolete.

Post by Herb Johnson
But the gist of the non-grumpy discussion is that any retroactive graphic
developments for CP/M are limited today, as they were then, by the lack of
resources in older systems.

That was my point. Mr. Hart argued that a 4MHz Z80 system had the same
capabilities as a 6MHz 68000 system and I refuted the claim.

Post by Herb Johnson
That includes a lack of standards for graphics hardware

That's really not a big limitation. If the graphics software is written
correctly, the hardware differences can be encapsulated in a very small set of
functions. Most graphical programming is platform independent.

Post by Herb Johnson
and limitations in memory and speed.

There, we totally agree.

Post by Herb Johnson
I see no shame in all of that, such limits existed in the post-CP/M
computer world for some years;

Who said anything about shame? That early CP/M-80 systems were inadequate to the
development of full GUIs is a simple statement of fact, not an indictment.

Post by Herb Johnson
today such limits only apply to extreme applications like 3D rendering and
simulation.

And maybe tomorrow's restrictions will apply to holograms and later, maybe to
something more complicated. The point is that every technology has its limits and
Z80 systems definitely had a low ceiling when it came to graphics.

Post by Herb Johnson
The other difficulty with this thread is that no applications are
specified, so there is no performance criterion.

The application was specified from the start and in the thread's subject: a GUI.
Performance criteria are evident to anyone who's done graphics programming:
opaque and transparent blitting, line/curve plotting, fills. These are the basic
building blocks of any 2D graphical system and their performance is easily
quantifyable.

Post by Herb Johnson
So one can always be sour grapes about the situation simply by setting
goals too high.

The goal was set too high the moment a Mac-style GUI was proposed for CP/M-80
systems. It's certainly interesting as an experiment, and I encouraged the OP to
try it, but by no means is this a practical idea.

Post by Herb Johnson
Or, one can look back and say what WAS accomplished within
the so-called limits of the times,

Except this thread isn't about what WAS accomblished but rather about what COULD
BE accomplished. There have been many threads about reminiscing. This just isn't
one of them. Feel free to start one if that's your personal preference.

Post by Herb Johnson
which of course were leading edge relative to times even more remote.
I prefer the latter approach, as even today there are applications which
are resourse limited and which can benefit from knowledge and
experience acquired from predecessor applications in a similarly limited
environment.

Unfortunately, the experience gained in software development for early 8-bit
systems is mostly inapplicable to today's large-scale software development. The
techniques are still in use in small-scale embedded systems, but that's an
entirely different world.

Post by Herb Johnson
It seems to me the challenge of working in a resource-limited but
FAMILIAR and STABLE programming environment has drawn
more interest in the last few years, not less.

If you're talking about HOBBYIST programming, then I agree. Professionals -- for
better or for worse -- have a different set of challenges today.

Post by Herb Johnson
I see more "tribute" Web sites to CP/M, Atari, and other classic
computers every month, and new developments in hardware
and software.

Which is a good thing for those of us who are keeping old memories fresh.

Post by Herb Johnson
So I find remarks about "wasting time" with such systems to be as ironic
today as they were a few decades ago when CP/M was new.

Again with the misinterpretation. Read what I actually wrote. If you're going to
make up both ends of the dialog, I don't see why you bother interacting with
others. The "wasted time", as I explained more than once, refers to the idea that
early 1980's programmers would try duplicate the work that was done on Macs. It's
amazing to me that anyone could extrapolate that to apply to any work done on
early systems or to apply it to what hobbyists are doing today.

Claudio Puviani

[Herb Johnson]

Post by Claudio Puviani

Post by Herb Johnson

[Herb Johnson wrote:]

So I find remarks about "wasting time" with such systems to be as ironic
today as they were a few decades ago when CP/M was new.

Again with the misinterpretation. Read what I actually wrote. If you're going to
make up both ends of the dialog, I don't see why you bother interacting with
others. The "wasted time", as I explained more than once, refers to the idea that
early 1980's programmers would try duplicate the work that was done on Macs. It's
amazing to me that anyone could extrapolate that to apply to any work done on
early systems or to apply it to what hobbyists are doing today.
Claudio Puviani

I don't see any point to responding to each point of Mr. Puviani's
point-by-point refutation of my remarks. In general I will say that
the tone of his responses encouraged some bitter replies which of
course is a good excuse to reply in kind. I've already said I don't
support that kind of discussion, and at other times I've said the best
way to stop such discussions is to ignore them. My error was to
respond in kind: I apologize to my colleages for "taking the bait".
I'm reluctant to run from a fight but I avoid pointless battles when I
can. As for the relevance and value of of my less personal comments,
I'll let my colleagues decide that for themselves: mostly what I wrote
was on their behalf. If Mr. Puviani finds my remarks "amazing" at
best, he is now left with a mystery I will not resolve for him.

Herb Johnson

Herbert R. Johnson voice 609-771-1503, New Jersey USA
<a href="http://njcc.com/~hjohnson"> link to my web site</a>
<a href="http://retrotechnology.com/herbs_stuff"> mirror of web
site</a>
email address: hjohnson AAT njcc DOTT com
(if mail bounces, try herbjohnson ATT comcast DOTT net)
good used Mac, SGI, 8-inch floppy drives
S-100 IMSAI Altair computers, , docs, by "Dr. S-100"

[wild bill]

Post by Lee Hart

Post by wild bill
On Sun, 25 Apr 2004 23:14:52 +0200, Peter Smith

Post by Peter Smith
I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with

...... with virtually *anything* I suspect

I think you are overly pessimistic. There have been quite a few
computers with graphical user interfaces that had what would be
considered pitiful amounts of speed and memory by today's bloated
standards.

That reminds me .... just take another look at the Timex Sinclair!
Accomplished a lot with very little, resources-wise. Used a Z-80.

One thing I liked about the Z-80 is the bank switching. Gives you
48k for a bit-mapped memory. You can use a 6845, just as IBM
originally did, and get some graphical functionality. You could
even use more than one bank, maybe for interleaving your
display. Interesting possibilities. Or, 3x 16k planes, for color?
Or even 3x 48k planes for better/bigger color?

But as you can see, you very quickly become totally hardware
dependant. Producing what would, at the time, have amounted
to a dedicated video game machine. Not very general purpose.

BigBoard II (Z-80 machine) used a 6845, but with limited memory
had block graphics available (I think it was a 2k ROM for generation,
and maybe 16k RAM for video memory). Not bit-mapped.

Okay, so, with Z-80 and bank switching, would also probably
want to use a second CPU, some sort of graphics engine, to
off-load all but the most primitive stuff from CPU.

Beginning to sound more and more like the IBM PC.

Also, you would probably not want to try to get bank switching
working on most S-100 systems ... they were pretty pitiful. If
you could get 50khz bandwidth through one I'd be surprised.
You could probably get 10-20 times that with a BB II. And the
BB II included DMA via a Z-80 DMA chip. Don't think I ever saw
both bank switching AND DMA actually working on any S-100.
Well, maybe Compupro. Been a while. Wasn't cheap.

Bill

[Exegete]

Post by wild bill

Post by Lee Hart

Post by wild bill
On Sun, 25 Apr 2004 23:14:52 +0200, Peter Smith

Post by Peter Smith
I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with

...... with virtually *anything* I suspect

I think you are overly pessimistic. There have been quite a few
computers with graphical user interfaces that had what would be
considered pitiful amounts of speed and memory by today's bloated
standards.

That reminds me .... just take another look at the Timex Sinclair!
Accomplished a lot with very little, resources-wise. Used a Z-80.
One thing I liked about the Z-80 is the bank switching. Gives you
48k for a bit-mapped memory. You can use a 6845, just as IBM
originally did, and get some graphical functionality. You could
even use more than one bank, maybe for interleaving your
display. Interesting possibilities. Or, 3x 16k planes, for color?
Or even 3x 48k planes for better/bigger color?
But as you can see, you very quickly become totally hardware
dependant. Producing what would, at the time, have amounted
to a dedicated video game machine. Not very general purpose.
BigBoard II (Z-80 machine) used a 6845, but with limited memory
had block graphics available (I think it was a 2k ROM for generation,
and maybe 16k RAM for video memory). Not bit-mapped.
Okay, so, with Z-80 and bank switching, would also probably
want to use a second CPU, some sort of graphics engine, to
off-load all but the most primitive stuff from CPU.
Beginning to sound more and more like the IBM PC.

Actually, sounds more like the Coleco ADAM and the MSX machines.

Roy

Post by wild bill
Also, you would probably not want to try to get bank switching
working on most S-100 systems ... they were pretty pitiful. If
you could get 50khz bandwidth through one I'd be surprised.
You could probably get 10-20 times that with a BB II. And the
BB II included DMA via a Z-80 DMA chip. Don't think I ever saw
both bank switching AND DMA actually working on any S-100.
Well, maybe Compupro. Been a while. Wasn't cheap.
Bill

-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Peter Smith]

Post by wild bill
That reminds me .... just take another look at the Timex Sinclair!
Accomplished a lot with very little, resources-wise. Used a Z-80.

That's absolutely true. The Timex 1000/Sinclair ZX81 was - for the time
it appears on the market - a computer with a very good price/value
relation. But compared to the maximum possibilities at this time it was
a poor equipped machine.

Post by wild bill
One thing I liked about the Z-80 is the bank switching. Gives you
48k for a bit-mapped memory. You can use a 6845, just as IBM
originally did, and get some graphical functionality. You could
even use more than one bank, maybe for interleaving your
display. Interesting possibilities. Or, 3x 16k planes, for color?
Or even 3x 48k planes for better/bigger color?

You can use memory banks also with a 6502 or a 680x based machine, you
need only a MMU. But you are right, the only commercial offered OS "out
of the box" with bank switching was CP/M 3.0 (Plus).
Apple II users had also a lot of possibilities to use additional RAM,
but their DOS 3.3/ProDOS was not complex enough.
But I think, as I already stated here, that it depends also what graphic
controller you can use... a 6845 (or a 6545, already the same) was not
able to offer memory mapped graphics for high resolutions, which slow
down the whole thing a lot. The same was with the 7220 I think, or ?
I have now started to implement a GUI with block graphic characters,
similar to the MS-DOS 5.0 DOS-Shell. This will still look nice but is
much faster in execution. And I am still able to make it portable to
other CP/M computers (not only my C128).

Regards
Peter

[Jan Vanden Bossche]

Hallo

Post by Peter Smith

Post by wild bill
That reminds me .... just take another look at the Timex Sinclair!
Accomplished a lot with very little, resources-wise. Used a Z-80.

You can use memory banks also with a 6502 or a 680x based machine, you
need only a MMU. But you are right, the only commercial offered OS "out
of the box" with bank switching was CP/M 3.0 (Plus).

Ahum. And TRSDOS 6.x for the TRS-80 model 4/P/D (and LS-DOS 6.3.x after
that.) BTW, the TRS-80 model 4 was also a CP/M computer and it ran DRI CP/M
3.0 (distributed by Tandy) and Montezuma Micro CP/M 2.2.

Post by Peter Smith
I have now started to implement a GUI with block graphic characters,
similar to the MS-DOS 5.0 DOS-Shell. This will still look nice but is
much faster in execution. And I am still able to make it portable to
other CP/M computers (not only my C128).

That's what we need. Make the block characters user-definable. Your
characterset might not (probably will not) match mine.

I might fire up the old Kaypro II again !

Post by Peter Smith
Regards
Peter

Greetings from the TyRannoSaurus
Jan-80

[Kelli Halliburton]

Post by Peter Smith
I have now started to implement a GUI with block graphic characters,
similar to the MS-DOS 5.0 DOS-Shell. This will still look nice but is
much faster in execution. And I am still able to make it portable to
other CP/M computers (not only my C128).

Still requires the presence of those block graphic characters in the target
systems. Remember that the PETSCII character set includes graphics
characters that simply aren't in plain old ASCII. And ASCII is all some CP/M
systems support.

[Peter Smith]

Post by Kelli Halliburton

Post by Peter Smith
I have now started to implement a GUI with block graphic characters,
similar to the MS-DOS 5.0 DOS-Shell. This will still look nice but is
much faster in execution. And I am still able to make it portable to
other CP/M computers (not only my C128).

Still requires the presence of those block graphic characters in the target
systems. Remember that the PETSCII character set includes graphics
characters that simply aren't in plain old ASCII. And ASCII is all some CP/M
systems support.

I will do my best to make it user definable, also you should be able to
use more than one char (= a char string) for each block char, because
there are some terminals which must use ESC chars to reach the block
characters.

Regards
Peter

[CBFalconer]

Post by Kelli Halliburton

Post by Peter Smith
I have now started to implement a GUI with block graphic characters,
similar to the MS-DOS 5.0 DOS-Shell. This will still look nice but
is much faster in execution. And I am still able to make it portable
to other CP/M computers (not only my C128).

Still requires the presence of those block graphic characters in the
target systems. Remember that the PETSCII character set includes
graphics characters that simply aren't in plain old ASCII. And ASCII
is all some CP/M systems support.

This is about all that is really feasible in CPM-80. It requires
that the graphics be built around the characters, which means no
more than 6 bits in a char block. This in turn inplies that (for
graphics) the char block is divided into a 2 * 3 space. Combine
that with the usual 24 x 80 text size, and we have 72 x 160
graphics. To get reasonable drawing properties we want these to
be square. Each graphic pixel will be represented by some
integral number of real pixels on the CRT, which further restricts
the possibilities, especially when combined with feasible scan and
bit rates. We will have a wide and squat CRT screen. Now look at
the HP terminals of the day.

Thus an 8 bit byte can hold: 128 chars including controls, 32
controls mapped to the higher half for convenience, 64 graphic bit
combinations, 31 unassigned codes, and the RUBOUT char.

[Kelli Halliburton]

Post by CBFalconer

Post by Kelli Halliburton
Still requires the presence of those block graphic characters in the
target systems. Remember that the PETSCII character set includes
graphics characters that simply aren't in plain old ASCII. And ASCII
is all some CP/M systems support.

This is about all that is really feasible in CPM-80. It requires
that the graphics be built around the characters, which means no
more than 6 bits in a char block. This in turn inplies that (for
graphics) the char block is divided into a 2 * 3 space. Combine
that with the usual 24 x 80 text size, and we have 72 x 160
graphics. To get reasonable drawing properties we want these to
be square. Each graphic pixel will be represented by some
integral number of real pixels on the CRT, which further restricts
the possibilities, especially when combined with feasible scan and
bit rates. We will have a wide and squat CRT screen. Now look at
the HP terminals of the day.
Thus an 8 bit byte can hold: 128 chars including controls, 32
controls mapped to the higher half for convenience, 64 graphic bit
combinations, 31 unassigned codes, and the RUBOUT char.

The TRS-80 block graphics are 2x3 per character cell...

My proposal is to adopt the Contiki UI toolkit.
http://www.dunkels.com/adam/contiki has the information about it.
Multitasking OS, small IP networking daemon, web browser, character-based or
graphics-based UI system... runs on a stock Commodore 64.

Assuming we want to keep CP/M (this isn't comp.os.contiki, after all), we
can dump the multitasking OS and its ensuing overhead. However, the uIP
system, the web browser technology, and the UI toolkit are all adaptable for
our purposes.

But then, this thread is just about "writing a GUI for CP/M" -- and so we
can drop the uIP and the web browser, too, and focus on the UI toolkit,
called CTK. The thing about CTK is that it can be rendered on a graphics
screen or a cursor-addressable text screen, and the application doesn't know
the difference (well, unless it requires and specifically asks for graphics
output). The current implementation of CTK is to run as a process under the
Contiki OS, but it could be ported to work as a linked library to be
compiled into an application, I would imagine. The application's
configuration utility would let you pick out what display driver you'd use.
You could have one for an ADM-3A, one for a VT-320, or even one for, say,
Hercules monochrome graphics.

The original release of Contiki managed to pack the OS, the CTK, a telnet
client, web browser, uIP networking driver, process viewer, and a
graphics-based display driver all into a C64 with room left over for the
shared-memory bitmapped graphics display and memory-mapped I/O. It should,
therefore, be able to fit in all but the smallest of TPAs if using only the
CTK and display driver.

[Jack Peacock]

Post by wild bill
Also, you would probably not want to try to get bank switching
working on most S-100 systems ... they were pretty pitiful. If
you could get 50khz bandwidth through one I'd be surprised.
You could probably get 10-20 times that with a BB II. And the
BB II included DMA via a Z-80 DMA chip. Don't think I ever saw
both bank switching AND DMA actually working on any S-100.

It depends on how the bank switching was implemented. I/O ports were fairly
tedious, but using the full 24-bit address of the S-100 and some sort of
address translator in front of the Z80 (or the built in MMU on the
64180/Z180) produced good speeds. DMA was a bit tricky becuase the 16 bit
address had to be resolved into the full 24 bit space but it worked well on
systems where CP/M 3 buffers were in high memory. The other limitation was
moving blocks around, since the typical procedure on the MMUs I used was to
map two 4K windows and copy, then slide the window physical bases as needed.
The 64180/Z180 solved that with memory to memory DMA.

The problem with the Z80 DMA controller was its limited speed and 16-bit
addressing. Zilog never produced a version faster than 4Mhz, which made it
useless on 6/8 Mhz systems. And it couldn't support a 24-bit memory space
without a bunch of external logic (to be fair Intel's infamous 8257 DMA had
the same problem).
Jack Peacock

[Randy McLaughlin]

Post by Jack Peacock

Post by wild bill
Also, you would probably not want to try to get bank switching
working on most S-100 systems ... they were pretty pitiful. If
you could get 50khz bandwidth through one I'd be surprised.
You could probably get 10-20 times that with a BB II. And the
BB II included DMA via a Z-80 DMA chip. Don't think I ever saw
both bank switching AND DMA actually working on any S-100.

It depends on how the bank switching was implemented. I/O ports were fairly
tedious, but using the full 24-bit address of the S-100 and some sort of
address translator in front of the Z80 (or the built in MMU on the
64180/Z180) produced good speeds. DMA was a bit tricky becuase the 16 bit
address had to be resolved into the full 24 bit space but it worked well on
systems where CP/M 3 buffers were in high memory. The other limitation was
moving blocks around, since the typical procedure on the MMUs I used was to
map two 4K windows and copy, then slide the window physical bases as needed.
The 64180/Z180 solved that with memory to memory DMA.
The problem with the Z80 DMA controller was its limited speed and 16-bit
addressing. Zilog never produced a version faster than 4Mhz, which made it
useless on 6/8 Mhz systems. And it couldn't support a 24-bit memory space
without a bunch of external logic (to be fair Intel's infamous 8257 DMA had
the same problem).
Jack Peacock

Tarbell had both bank switching and DMA on their S100 systems (I have one).

Randy

[Robert J. Stevens]

Post by Randy McLaughlin

snipped

Tarbell had both bank switching and DMA on their S100 systems (I have one).
Randy

Randy;
I would be very much interested to converse with you about TARBELL. I had
several systems only thing left is my Tarbell Dual CPU board. My other boards
are in NY and Tenna.
Bob ***@hotmail.com legit

[wild bill]

On Sun, 25 Apr 2004 23:14:52 +0200, Peter Smith

Post by Peter Smith
I tried it hard, but it seems it can't be done, building a usable GUI
for CP/M with my Commodore C128.

Just came from a weekend auction. This guy was an Epson
dealer 20 years ago. They couldn't even get 50 cents bid
on a complete Pentium 133 system, let alone any of the
maybe dozen Epson QX-10s he had.(drives, printers,
hard drives, dealer literature, you name it!)

The QX-10 (I later found out) is a Z-80 machine with
256K of ram; most of it apparently bit-mapped video.
One place I found (use google) mentioned 128k.

It runs CP/M 2.2 as well as Epson-branded stuff.

If I had to guess, a QX-10 is exactly the machine you
oughta look for and experiment with.

Since they aren't worth the cost of shipping, you'll
probably want to check locally - maybe thrift stores
or something.

If I get a chance I'll check back at the site and see
if anything's left - they told me whatever didn't sell
was going into a huge dumpster that was sitting there
to receive any 'unwanted' auction items.

Bill

[French Luser]

Post by wild bill
Just came from a weekend auction. This guy was an Epson
dealer 20 years ago. They couldn't even get 50 cents bid
on a complete Pentium 133 system, let alone any of the
maybe dozen Epson QX-10s he had.(drives, printers,
hard drives, dealer literature, you name it!)

The Epson QX-10 is one of the very best non-S-100 Bus
microcomputer ever made.

Using Google -- Groups -- Advanced Search, you will
find all the messages involving it published in the comp.os.cpm
Newsgroup.

Yours Sincerely,
"French Luser"