was CP/M text only or did it have graphics similiar to, say, CGA ?
*ProteanThread*
shots available somewhere ?
what about other programs that would've used graphics ?
--
Woodzy
http://www.rtdos.com (alt OS for games based on the classics)
http://o.webring.com/hub?ring=phpmychat ( phpMyChat )
John Thompson
> were there any games with graphics available for CP/M ? are there screen
> shots available somewhere ?
The Epson QX-10/QX-16 computers had pretty good graphics capabilities for
that time (640x400 bitmapped monochrome display) and several graphical
games were available. I have a demo disk here with a few, and also CP/M
Logo implementation with graphics.
--
-John (jo...@os2.dhs.org)
*ProteanThread*
news:slrnci765...@starfleet.os2.dhs.org...
>
> The Epson QX-10/QX-16 computers had pretty good graphics capabilities for
> that time (640x400 bitmapped monochrome display) and several graphical
> games were available. I have a demo disk here with a few, and also CP/M
> Logo implementation with graphics.
>
> --
>
> -John (jo...@os2.dhs.org)
Any with color ?
Rosso
> were there any games with graphics available for CP/M ? are there screen
> shots available somewhere ?
Games Portable from various CP/M systems which used GSX? AFAIK I haven't seen
any.
Machine Specific, I've seem some commercial games for the Amstrad PCW which
run under CP/M, the PCW doesn't have colour though. Some games for the Amstrad
CPC were written in CP/M which had colour. But again that's Machine Specific.
> what about other programs that would've used graphics ?
DR Draw & DR Graph both used GSX. Obviously DR Draw would work on the 8bits
which support graphics, there was also DR Draw86 for the 16 bit computers.
Regards,
Ross.
Anonymous Guy
On 2004-08-18 nos...@nouce.bellatlantic.net (Allison P.) said:
> CP/M was text only.. to a point, the OS was text only. It's also
> to say that applications could run and utilize any capability there
> was and an example was the CompuColor and DEC VT185 (scarce version
> of the VT180 board in a VT125 mono/color grpahic terminal) and a
> bunch of others. The key was CP/M didn't set or limit graphics
> only that the hardware was often only text only. I'd add that
> until around the 1982 timeframe when Color diplay controllers
> started showing up graphics meant lots of costly ram and boards.
> Cost as we know is an inhibitor of acceptance.
>
> Allison
All true, Al. And the fact that "...CP/M didn't set or limit
graphics" played a major role in allowing development of the
more recent graphical apps for 'CP/M-86 For The IBM.'
Under CP/M, we're free to bit-bang the hardware to our hearts'
content.
Of course, programming graphics in this manner is a little more
difficult, but it also gives one complete programmatic freedom.
Besides...REAL programmers doan NEED no steeking callable library
routines to program graphics. ;)
John Thompson
> "John Thompson" <jo...@starfleet.os2.dhs.org> wrote in message
> news:slrnci765...@starfleet.os2.dhs.org...
>>
>> The Epson QX-10/QX-16 computers had pretty good graphics capabilities for
>> that time (640x400 bitmapped monochrome display) and several graphical
>> games were available. I have a demo disk here with a few, and also CP/M
>> Logo implementation with graphics.
> Any with color ?
Actually, Epson did make a color option available for the QX-10. I have
the technical specs here:
http://www.os2.dhs.org/~john/8-bit/classic-computing.net/john/qx10opt/QX-10-cms.pdf
--
-John (jo...@os2.dhs.org)
Andy Ball
Hello,
PT> Any with color ?
The Amstrad CPC range springs to mind. I'm not sure whether
the Sam Coupe' had CP/M as an option, but that had nice
graphics as I recall. For the graphics capabilities to be
considered part of CP/M, the machine would probably have to
ship with a GSX (graphics system extension iirc) library,
which I'm told evolved into VDI, the core of the GEM
graphical user interface.
Come to think of it, I remember seeing Logica VTS Kennet
multi-user microcomputers with colour graphical terminals
and I know that GSX was available for those.
- Andy Ball.
F.J. Kraan
disk image site: http://www.xs4all.nl/~fjkraan/comp/qx10/detail.html
(mirror:
http://oldcomputers.dyndns.org/public/pub/rechner/epson/~fjkraan/comp/qx10/detail.html)
Fred Jan
Randy McLaughlin
news:vE5Vc.27837$9Y6....@newsread1.news.pas.earthlink.net...
My earliest color graphics for CP/M is my Dazzler.
Like Linux/UNIX CP/M (including CP/M-86 etc.) allows graphics to run but
does nothing to help or hinder.
Randy
Ventzislav Tzvetkov
> were there any games with graphics available for CP/M ? are there screen
> shots available somewhere ?
Why do you need graphics for games? There are many text adventures for
CPM. Also by using only the console VT52 terminal (and it's direct
screen addressing, err kinda), I was able to port a puzzle game to the
CPM:
http://drhirudo.edula.com/images/Mazezam_CPM.png
http://drhirudo.edula.com/files/MazezaM_CPM.zip
If I can find a *decent* C compiler for CP/M I can easily port other
games, with just replacing the graphics with characters. It's little
abstract this way but works nevertheless.
> what about other programs that would've used graphics ?
Don't know. My Apple 2 CP/M worked only on text display 40*24 :-/
But for printer output you can always use rich text format. No need
for graphics video output, as long as the printer can do the job
right.
Moll
>>what about other programs that would've used graphics ?
>
> Don't know. My Apple 2 CP/M worked only on text display 40*24 :-/
> But for printer output you can always use rich text format. No need
> for graphics video output, as long as the printer can do the job
> right.
I think you could have used graphics on Apple ][ CP/M (GBASIC does).
Also M$ CP/M would use an 80-column card if it detected one, or if
running on a //e.
Moll.
Andy Ball
Hello Randy,
RM> Like Linux/UNIX CP/M (including CP/M-86 etc.) allows
> graphics to run but does nothing to help or hinder.
Are we due for an X11 port? ;-)
- Andy.
Tomas Karlsson
"*ProteanThread*" <rt...@rtdos.com> wrote in message
news:uZLUc.57855$865....@hydra.nntpserver.com...
> shots available somewhere ?
>
> what about other programs that would've used graphics ?
>
Telenova's Compis computer had graphics capabilities in color or monochrome,
640x400 and 1280x800 pixels. The graphics could be accessed through GSX
(Graphics System eXtension).
Autodesk ported AutoCAD:
http://www.compis.nu/history/images/compisacad_tumb.jpg
Technical info about Compis:
http://www.old-computers.com/museum/computer.asp?c=358
/Tomas
Lee Hart
> Were there any games with graphics available for CP/M?
Lots of CP/M computers had graphics of one sort or another. The fact
that they were different between machines meant that any programs using
them were also machine specific.
I happen to like the Heath/Zenith 8-bit computers, the H8 and H89. Both
of these had character-graphics, based on the DEC VT-52. Basically, the
character generator had 128 displayable characters, of which 96 were the
usual ASCII, and the rest were special graphic characters (vertical,
diagonal, and horizontal lines, half-filled boxes, etc.). With them, you
could draw some pretty good graphics displays without lots of speed or
memory. There were hundreds of games written using these graphics.
> Are there screen shots available somewhere?
Ah, now that would be a challenge! I don't know how you'd display H89
character graphics on a PC, short of photographing the H89 screen and
making a bitmap of it. Certainly one could write a program that
translated H89 character graphics into PC graphics, but I don't think it
exists.
And, you'd need a unique version of such a program for every machine,
since CP/M machines all had different graphics.
--
"Never doubt that the work of a small group of thoughtful, committed
citizens can change the world. Indeed, it's the only thing that ever
has!" -- Margaret Mead
--
Lee A. Hart 814 8th Ave N Sartell MN 56377 leeahart_at_earthlink.net
Bill Sudbrink
>> Are there screen shots available somewhere?
>Ah, now that would be a challenge! I don't know how you'd display H89
>character graphics on a PC, short of photographing the H89 screen and
>making a bitmap of it. Certainly one could write a program that
>translated H89 character graphics into PC graphics, but I don't think it
>exists.
I have not looked at the schematics in years... but I would guess that
there are plain old composite video signals in there somewhere. You
could intercept that signal, route it to a PC video capture card and
capture images that way.
Bill
Peter Hill
<rt...@rtdos.com> wrote:
>were there any games with graphics available for CP/M ? are there screen
>shots available somewhere ?
>
>what about other programs that would've used graphics ?
Other than GSX extensions to CP/M the closest the Z80 came to having a
standard graphics system was MSX and MSX2. But support for CP/M was
not part of the MSX standard.
Tatung Einstein had colour graphics 256x192 16 colour, limited to
foreground and background in 32 columns each 8 pixels wide that was
mapped by two bytes, one byte for 8 pixels on/off bit data and one for
two nibbles of colour data. Based on the MSX standard TMS9928 chip
but at a different I/O location. It used XTAL/Dos a CP/M clone to
load games from disk. As the TMS chip only supported 32 or 40 column
text a 80 column card was available to give support for CM/P programs
that needed it. With this card it had dual screens an 80 column text
screen and a graphics screen both which could in use at the same time.
It also had BBC Basic Z80 which had full access to the graphics and
both screens. A Mandelbrot pattern took about 5 hours at a depth of
32. About 2 hours when ported to Turbo Pascal 2.0a with calls direct
to the graphics routines in the MOS rom. An assembly code graphics
dump to fill A4 paper on an Amstrad DMP-2000 Epson compatible printer
in CRT mode using 3x3 dots to get 10 shades of gray took about 15 min.
The later Einstein 256 had 512x384 in 256 colours from 512 colours
using a display based on the later Yamaha MSX2 graphics chip.
--
Peter Hill
Spamtrap reply domain as per NNTP-Posting-Host in header
Can of worms - what every fisherman wants.
Can of worms - what every PC owner gets!
Lee Hart
>> I don't know how you'd display H89 character graphics on a PC,
>> short of photographing the H89 screen and making a bitmap of it.
Bill Sudbrink wrote:
> I have not looked at the schematics in years... but I would
> guess that there are plain old composite video signals in there
> somewhere. You could intercept that signal, route it to a PC
> video capture card and capture images that way.
Not quite; the H19 and H89 (and most other classic CP/M computers and
terminals) used monitors with separate Hsync, Vsync, and Video. Some
aftermarket suppliers made composite video adapters, but they would be
very hard to find nowdays.
Randy McLaughlin
news:412FFA...@earthlink.net...
If someone really wanted authentic type displays all it would really take
are dumps from the char gen ROMs.
That is how most emulators do it, it's really pretty simple.
Randy
Lee Hart
> If someone really wanted authentic type displays all it would
> really take are dumps from the char gen ROMs. That is how most
> emulators do it, it's really pretty simple.
It is straightforward, though not exactly simple. More like tedious.
First, how are you going to get a dump of the character generator ROM?
Terminals don't have a way to dump their character generators. You'd
have to manually type it in to create a .HEX file. Or, take the terminal
apart, pull the character generator ROM, and dump it with an EPROM
programmer. But many character generator ROMs are not standard EPROMs;
they often have odd pinouts, with extra chip selects, etc. You may have
to make an adapter to read it.
Second, what do you do with the .HEX file of the character set to use it
on a PC? I guess you would have to write a custom terminal emulator
program that used that font. You're also going to have to completely
emulate the firmware of the terminal (H19 or whatever). This is harder
than it looks -- witness the *large* number of emulators that leave out
many of the ESC sequences, modes, and functions of the terminals they
emulate. For example; find an H19 emulator that includes H19 graphics.
I suspect that most people who want to post screen shots of old
computers find some other way to do it.
*ProteanThread*
news:1a9ni0lmp3nir6okt...@4ax.com...
>
> Other than GSX extensions to CP/M the closest the Z80 came to having a
> standard graphics system was MSX and MSX2. But support for CP/M was
> not part of the MSX standard.
Where can I find info on GSX extensions ? Google doesn't give me much to go
on.
GARTH
type graphics looks quite good when you shoot something and it explodes into
a lot of dots/dashes and stars
"*ProteanThread*" <rt...@rtdos.com> wrote in message
news:uZLUc.57855$865....@hydra.nntpserver.com...
Barry Watzman
hardware specific. That is, your game would only work on the specific
hardware configuration that it was written for. If you play it on
another CP/M system, the program itself might run (it also might not),
but it won't produce the correct screen display.
In fact, this was even true of text programs, generally you had to
customize programs (such as Wordstar) to both the exact terminal type
being used, and also to the exact printer type being used. You had to
do this for every program separately, there were no higher-level
"drivers" in the operating system. CP/M could deliver ascii text bytes
to the device, but had no understaning of the higher level functioning
of those bytes, e.g. clear screen and cursor positioning commands.
French Luser
> (...) there were no higher-level
> "drivers" in the operating system. CP/M could deliver ascii text bytes
> to the device, but had no understanding of the higher level functioning
> of those bytes, e.g. clear screen and cursor positioning commands.
This is because CP/M started at a time when there was no screen...
If you examine the list of the 40 or so "BDOS calls",
you will see that none is dealing with a screen: just
a serial terminal (like an ASR-33 Teletype).
(This is also why CP/M uses CR/LF pair, since
they are needed on an ASR-33 TTY...) (A "more intelligent"
terminal could do both movements upon receiving
only one "New Line" byte.)
(Of course, Barry, I wrote this elementary stuff for GARTH,
not you!)
Yours Sincerely,
"French Luser"
Anthony K. Akin
was limited by and to each platform. Some platforms were so closed
that no graphics could be added (other than crude graphics of using
the extended ASCII character sets). Some other machines had limited
graphics integrated into their machines, but again most were of the
character variety.
A few machines were open enough in their architecture to permit some
pretty decent graphics. One that comes to mind is the Heathkit H-89.
In its basic form, it was all text. However, a company called
Cleveland Codonics offered an add-in graphics card (twice the size of
a typical PC graphics card today).
What made the Cleveland Codonics card impressive was that it dealt
with pixel level graphics. It could create raster graphics at the
single pixel level. This meant you could create custom fonts
(although WYSISYG printing hadn't arrived yet).
Where it was really useful was for highly accurate plotting of math
funtions and the creation of 3D graphs. Bezzier functions were
particularly impressive. They were also time consuming (20-30 minutes
to create a single plot (what with slow processor speeds and having to
calculate individual points without the benefit of a math
coprocessor).
And, as someone mentioned, cost was a real deterent. That card cost
around $300-400.
Still, it provided solid and high quality graphics in a CP/M
envinronment - something that was very hard to come by at the time.
On Wed, 18 Aug 2004 11:03:20 -0600, "*ProteanThread*"
<rt...@rtdos.com> wrote:
nos...@nouce.bellatlantic.net
Another way to word the question is:
Does PC DOS have graphics? The answer for the most part is no.
Applications did.
In the CP/M realm, as the writer said: CP/M was Text for commands
but had no preference beyond that and if you had one of the many
available cards color graphics were in the 512x256 or better range
with RGB. Around the time the PC hit there were a few cards for the
1024x768 range but their cost (color monitors to do that too) were
very high.
Allison.
Jeff Wieland
I have a Microsphere Color Graphics board in my Kaypro 2X. It's based
on the TI-9918A chip, so it does 256x192 bit mapped graphics. It also
has 32 sprites, and sort of does 16 colors (there are a number of
restrictions on colors -- I don't recall what they are off the top of
my head). It piggy backs under one of the SIO sockets.
It came with some software, including a version of Logo. I played with
Logo a bit when I got the board, but I'm just not that sort of
programmer :-). IIRC, the Logo was produced by a company called The
Learning Company. They had another version that used the builtin
graphics (160x100) on the '84 series Kaypros. There was a Pacman
clone, too.
It comes with programming examples in a number of languages, including
Turbo Pascal. I started writing code for Turbo Modula 2 (which
produces faster code than Turbo Pascal), but I never got very far with
that. If I were to get back to that, I'd use the HiTech C compiler
instead.
BTW, I bought the board from one of the engineers who had helped design
it -- he was given a completed board as part of the pay for his work.
--
Jeff Wieland
Scott Moore
>
> Does PC DOS have graphics? The answer for the most part is no.
> Applications did.
>
> In the CP/M realm, as the writer said: CP/M was Text for commands
> but had no preference beyond that and if you had one of the many
> available cards color graphics were in the 512x256 or better range
> with RGB. Around the time the PC hit there were a few cards for the
> 1024x768 range but their cost (color monitors to do that too) were
> very high.
>
> Allison.
The main problem in CP/M was to get full screen apps to work. Towards the
end of my use of CP/M, I discovered a couple of games that were very
good about letting you enter a few control sequences for the terminal,
and then went on to present full screen "semi-graphical" games.
CP/M probally needed to move on to termcap use, but by then it was kinda
over.
nos...@nouce.bellatlantic.net
Alas you forget ZCPR, with that came termcap capabilities. The onter
detail was many BIOS were written either very narrow (IE: emulate zz
terminal via video board) or poorly. What would occur is improved
BIOS and even improved version of the basic CP/M idea. I had no
problem running graphical stuff on a VT185 (Vt180 with base VT100 and
VT125 terminal). However becuase of the bios trapping some control
sequences WS keys were had to be strangely mapped.
The problem if any was applying generalities of XYZ system to all.
The capabilities and liabilities(read bugs or plain broken) were all
over the map and largely not limited by CP/M but by the BIOS that was
implmented by vendors.
There were two things "CP/M" could not count on as "standards".
What the storage media was (8, 5.25, 3.5 ,3 floppy, or tape or hard
disk and CPU [8080, 8085, nsc800, Z80]) and what the console
devices capabilities for input or output. As a result it was
interfaced to a wide array of "stuff" and often compatability was a
issue. Such is what happens when CPU hardware, IO hardware,
System software and applications collide. The result is your neato
Z80 coded, VT125 compatable graphic game on 5.25" DSQD floppy
and your standing in front of a 8"drive that has an 8080 and ADM1A
terminal.
Come to think of it, still the case. only now it's a 1Ghz/PIII,
oddball sound card and VGAsomething graphics.
Ah foo, 25 years, same problem.
Allison
William J. Leary Jr.
news:dg6u4f$gbp$1...@mailhub227.itcs.purdue.edu...
> I have a Microsphere Color Graphics board in my Kaypro 2X. It's based
> on the TI-9918A chip, so it does 256x192 bit mapped graphics. It also
> has 32 sprites, and sort of does 16 colors (there are a number of
> restrictions on colors -- I don't recall what they are off the top of
> my head). It piggy backs under one of the SIO sockets.
I built an S100 card for my CP/M system based on that same chip. The only
thing I ever really got working with it was a Christmas tree with blinking
lights. At that point I was programming only in assembler and it was a bit
tedious. When I later got C running on the machine I'd gotten too busy to
try the card again.
- Bill
Jeff Wieland
A former colleague of mine built a video card for his Big Board using
a TI-9918A and an Intel 8085. IIRC, he could download programs into
it to control the 9918a, effectively making it a graphics coprocessor
(why else would you have the 8085?). This was his senior project
here at Purdue.
Microsphere made two versions of their board. The other was for the
'83-series Kaypros -- it piggybacked under a Z80 PIO.
--
Jeff Wieland
William J. Leary Jr.
> In article <momdnR-wU4i...@comcast.com> "William J. Leary Jr."
<Bill_...@msn.com> writes:
> >I built an S100 card for my CP/M system based on that same chip. The
only
> >thing I ever really got working with it was a Christmas tree with
blinking
> >lights. At that point I was programming only in assembler and it was a
bit
> >tedious. When I later got C running on the machine I'd gotten too busy
to
> >try the card again.
>
> a TI-9918A and an Intel 8085. IIRC, he could download programs into
> it to control the 9918a, effectively making it a graphics coprocessor
> (why else would you have the 8085?).
Could also be used to replace some amount of support logic, though as I
recall the 9918 was relatively easy to work with. But I'd agree, in
general. If I went to the trouble to put that on the board, that's how I'd
use it. And I seem to also remember that there were some features of the
9918 which could potentially require a lot of CPU time to handle. Something
about moving sprites or checking for collisions or some such. Off loading
that from the primary CPU would have been a Good Thing.
- Bill
Peter Hill
<akakin@hotmail,com> wrote:
CP/M had a RSX available called DRgraph. Only computer I ever saw
with it was a DEC Rainbow 100. A dual cpu Z80/8086 system.
Tatung Einstein. MSX chip set but not at correct I/O locations, CP/M
capable but came with a clone called X-Dos on 3" flippy discs. Used
TMS9129 video chip with dedicated 16K memory (64K Z80 ram + 16K video
+ 16K rom + 16K option rom socket) to display 40x24 text, or 256x200
pixel 16 colour graphics, with hardware sprites. Had an optional 80
col text mono card for CP/M programs that demanded 80 col mode. This
allowed text and colour graphics simultaneously on separate screens,
possibly the cheapest dual screen computer ever. Later Einstein 256
used Yamaha V9938C chip with 192K video ram to display 256 colours
from 512 at up to 512x424 pixels - good enough for 80 col text without
a second card. Due to rom being bank switched with bottom half of
memory and most BIOS calls being near direct to rom routines both
Einstein's had a nice large TPA - 56K.
Memotech was similar to Einstein but I think it had the chips I/O
ports at correct MSX locations.
Amstrad 6128/6256 were CP/M computers (came with 2.2 and 3+ to use the
full 128K/256K memory). I think they used the same graphics chip as
the BBC-B. Bit better than CGA but less colours than EGA.
Cifer 2683/2684 It was dual Z80 cpu as the built in terminal had
it's own dedicated cpu. 168 line scrollable terminal had a high speed
16000 byte/sec serial link, it could "TYPE" a 50Kb text file faster
from 8" disk than an IBM model 70/386-20 could from it's hard drive
(1st MS-DOS computer I had that could beat it was a 486-33 with VESA
bus graphics card - did about 25K char/sec). An add on card was
available that did Tektronix 4010 mono graphics - displayed
independently on terminal screen at 300x1024 pixels.
All CP/M computers can be plugged into a Tektronix 4111 colour
(1024x768 256 colour, needs a 1Mb memory card to do byte mapped
pixels) graphics display list terminal or equivalent. Possibly a
Linux system running a tek term? Also equally happy to plot to HP or
Ioline plotters and any other RS232 vector device. You just have to
program an application that outputs the vectors.
Jeff Wieland
My friend probably still has the board -- I know that he still has the
Big Board and it's 8" drives, etc. I'll have to ask him about some of
this stuff some time.
BTW, I've got the TI data book for the TMS9918A, TMS9928A, and TMS9919A
right in front of me, along with the TLC Logo manual. I should get the
ol' Kaypro out. I did replace the batteries on the Advent clock
earlier this year. I use a pair of alkaline AA's in a holder from
Radio Shack, since the I wasn't too keen on soldering directly on the
small lithium cells that would have been an exact replacement. Advent
had had a couple of "ears" added to the small barrel shaped 3V battery.
--
Jeff Wieland
French Luser
> BTW, I've got the TI data book for the TMS9918A, TMS9928A, and TMS9919A
> right in front of me, along with the TLC Logo manual.
I searched during many years for a "TLC Logo" for
the Epson QX-10... (It used the NEC uPD 7220
Graphics Display Controller.)
Would you mind having a look inside your TLC Logo manual,
searching if they list the computers for which it was available?
(I don't know if you have a rarity that would be valuable to scan.)
Yours Sincerely,
"French Luser"
French Luser
> CP/M had a RSX available called DRgraph. Only computer I ever saw
> with it was a DEC Rainbow 100. A dual cpu Z80/8086 system.
Aaarrrggghhh!!! I am afraid that you are mistaking "RSX"
for "GSX"... DR Graph is, indeed, a GSX program (also
running, in its 8-bit version, on the Amstrad CPC-6128
and PCW-8256). RSX were little-used. They stand for
"Resident System Extensions", while GSX stands for
"Graphics System Extension".
> Tatung Einstein. (snip)
I saw that you listed a bunch of English microcomputers...
> Einstein's had a nice large TPA - 56K.
As explained in an old message, the bigger TPA I ever
used was 63K on the (European) MultiFonts CP/M 2.2
for the Epson QX-10.
> All CP/M computers can be plugged into a Tektronix 4111 colour
> (1024x768 256 colour, needs a 1Mb memory card to do byte mapped
> pixels) graphics display list terminal or equivalent. Possibly a
> Linux system running a tek term? Also equally happy to plot to HP or
> Ioline plotters and any other RS232 vector device. You just have to
> program an application that outputs the vectors.
You are absolutely right. Indeed, in my GSX collection,
I am missing GSS-4010, which enabled CP/M 2.2 to
run programs for the Tektronix 4010 under GSX-80...
For years, I used an Hewlett-Packard HP 7470A graphics
plotter under GSX-80 on an Epson QX-10, and nobody
ever complained about the quality of the "business
graphics" produced with it (using DR Graph). (The
resolution of the plotter is about 3,000 x 10,000 pixels...)
Yours Sincerely,
"French Luser"
John Elliott
: RSX were little-used.
Apart from every time anyone ran a SUB file under CP/M Plus. CP/M 2 users
may recall XSUB; this was built in to CP/M Plus Submit, and was implemented
as an RSX.
--
------------- http://www.seasip.demon.co.uk/index.html --------------------
John Elliott |BLOODNOK: "But why have you got such a long face?"
|SEAGOON: "Heavy dentures, Sir!" - The Goon Show
:-------------------------------------------------------------------------)
French Luser
> CP/M had a RSX available called DRgraph. Only computer I ever saw
> with it was a DEC Rainbow 100. A dual cpu Z80/8086 system.
By the way, if you have seen DR Graph running on a
DEC Rainbow-100, that means that there was a
GSX-80 implementation made for it, and at least
one 8-bit screen driver made for the DEC Rainbow-100...
DEC had a good reputation.. Anybody out there has it?
Yours Sincerely,
"French Luser"
French Luser
> Apart from every time anyone ran a SUB file under CP/M Plus. CP/M 2
users
> may recall XSUB; this was built in to CP/M Plus Submit, and was
implemented
> as an RSX.
Normal CP/M programs load at 0100H.
Sometimes, there is a need for a program to load
(and run!) at another place in memory (99% of the
time at the top of the TPA). So, Digital Research
finally decided to do it in a standard way, and
made the RSX.
GSX was first written for CP/M 2.2: this explains
why, while it could, obviously, be implemented as
an RSX under CP/M Plus (with the added benefit
of "banking" the driver), it uses about 1/4 of the TPA
of a 8-bit system...
That's why I am so enthusiast about the 8086 version:
it is a few KiloBytes bigger, but the TPA is now
638 KB, versus 60 KB (Epson) or 61 KB (Amstrad)...
Now, the driver is less than 10% of the TPA!
Must leave: the cybercafe is closing.
Yours Sincerely,
"French Luser"
wild bill
<Bill....@microsoft.com> wrote:
>> Einstein's had a nice large TPA - 56K.
>
>As explained in an old message, the bigger TPA I ever
>used was 63K on the (European) MultiFonts CP/M 2.2
>for the Epson QX-10.
Since most (many? some?) manufacturers made their
BIOS source available, all you had to do was take out
anything you really didn't need, re-assemble, and
viola', you had a bigger TPA. So I'm not sure what
significance the available space number might have.
Smaller TPA equals (more or less) more 'stuff' in BIOS.
And anyway, when it really mattered, you could re-work
the loader and initialization routines to re-load over
each other, saving even more space, at least for the
code you only used during a re-boot. No reason to
leave useless strings in memory, that you'd never
run except while booting. Been there, done that.
Be careful to differentiate 'warm boot' routines from
'cold', or you might get a crash if you ''^+C'' instead
of hitting the reset button. Assuming you have one.
I think I had one running in 1/2k of ram, leaving a
roughly 63.5k available TPA. Ran most stuff out
of the disk buffer, not high RAM. If you wanted to
get space crazy, you could probably take less
than ten bytes, and bank switch to get to the BIOS.
Love that Z-80 block move command! Also the
indexed jumps, so I could re-map a non-standard,
but otherwise very nice, CDC Cherry keyboard .....
Bill
nos...@nouce.bellatlantic.net
I've had a few. Used to work for DEC being in their back yard.
It was an ok machine for a non-clone. However, it was not exclusively
8bit as the CPUs were Z80 and 8088. It was a hybrid in the full sense
as were a few of the S100 mixed cpu systems.
What sets it apart is the execution cpu and bios cpu could be
different. for example the 7220GDC driver was 8088 execution
but disk IO was Z80. Not to say it could not be the other way around
but the implmentation in rom and system software was done that way.
Allison
nos...@nouce.bellatlantic.net
<Bill....@microsoft.com> wrote:
I may add I have DRgraph for the Visual1050, a z80 cpm+
system with a 6502 to do the Screen and graphics. Nicely done.
The Visual1050 is monochrome 80x25 text and 640x300
graphics with no gray scale but did have two brightness levels.
The display tube supplied was Green (P1 long) phosphor.
It also has a complete library of docs, schematics, code and
the apparently rare DRI GSX manual set. Seems they shipped
with all that. When you combine DR Graph, DR Display
Manager with DR Cbasic you could develop applications with
very nice displays.
Allison
glen herrmannsfeldt
(snip about text only or graphics)
At the time CP/M was being used the popular way to do
graphics was with Tektronix graphics terminals.
The computer was text only, they terminal would supply
the graphic ability (with a storage CRT).
-- glen
nos...@nouce.bellatlantic.net
You also forget the DEC VT125, as base tube it was mono mid res
and with RGB tube plugged in it was same res but color.
Allison
French Luser
-------
The "Resident System Extension" (RSX) headers of CP/M Plus
by Emmanuel ROCHE
A few days ago, I did a remark about RSX that prompted a comment by
John
Elliott. This night, I cannot sleep. I remembered that I had done
something
about RSX headers. I tried at random to find a lost copy of what I did...
so
many years ago, in one of my stack of floppies (I don't trust Hard
Disks).
Incredibly enough, after less than 10 floppies, I found what I was
looking
for!
Since I am a programmer, I always prefer to talk about any technical
matter
using a program. As for what the general idea of what an RSX is, read
the
several articles about CP/M Plus that I published on the
comp.os.cpm
Newsgroup. Or, read the comment lines at the beginning of the display,
which
explain quite clearly what an RSX is.
Now, let the program do the talking...
10 REM RSX.BAS by Emmanuel ROCHE
20 '
30 hc$ = "N" ' Default = no HardCopy (hc$)
40 PRINT
50 INPUT "RSX: Do you want a hardcopy (Y/N) : " ; hc$
60 hc$ = UPPER$ (hc$)
70 '
80 IF CHR$ (PEEK (&H151) ) = "2" THEN mallard = 2 : GOTO 160 ' Version 1.29
90 IF CHR$ (PEEK (&H151) ) = "3" THEN mallard = 3 : GOTO 160 ' Version 1.39
100 '
110 PRINT
120 PRINT CHR$ (7) ; "Bad version of Mallard-80 BASIC"
130 PRINT
140 END
150 '
160 IF hc$ = "Y" AND mallard = 2 THEN POKE 8792,205
170 IF hc$ = "Y" AND mallard = 3 THEN POKE 29161,205
180 '
190 '-----------------------------------
200 '
210 GOTO 270 ' Print address
220 '
230 IF x > &H9FFF THEN PRINT "0" ;
240 PRINT HEX$ (x, 4) ; "H: " ;
250 RETURN
260 '
270 GOTO 350 ' Address, then address (inverted)
280 '
290 GOSUB 230
300 IF PEEK (x + 1) > &H9F THEN PRINT "0" ;
310 PRINT RIGHT$ ("0" + HEX$ (PEEK (x + 1) ), 2) ;
320 PRINT RIGHT$ ("0" + HEX$ (PEEK (x) ), 2) ; "H " ;
330 RETURN
340 '
350 GOTO 420 ' Address, then byte
360 '
370 GOSUB 230
380 IF PEEK (x) > &H9F THEN PRINT "0" ;
390 PRINT RIGHT$ ("0" + HEX$ (PEEK (x) ), 2) ; "H " ;
400 RETURN
410 '
420 GOTO 500 ' Address, then 3 bytes
430 '
440 GOSUB 230
450 PRINT RIGHT$ ("0" + HEX$ (PEEK (x) ), 2) ; " " ;
460 PRINT RIGHT$ ("0" + HEX$ (PEEK (x + 1) ), 2) ; " " ;
470 PRINT RIGHT$ ("0" + HEX$ (PEEK (x + 2) ), 2) ; " " ;
480 RETURN
490 '
500 GOTO 810 ' DUMPASC subroutine
510 '
520 IF ad > af THEN PRINT "dumpasc error: start > end." : END
530 alpha$ = ""
540 FOR n = 1 TO 8
550 a = PEEK (ad)
560 a$ = CHR$ (a)
570 IF (a < &H20) OR (a > &H7E) THEN a$ = "."
580 alpha$ = alpha$ + a$
590 ad = ad + 1
600 IF ad - 1 = af THEN RETURN
610 NEXT n
620 IF ad < af THEN GOTO 530 ELSE RETURN
630 '
640 GOTO 810 ' DUMP subroutine
650 '
660 IF ad > af THEN PRINT "dump error: start > end." : END
670 alpha$ = ""
680 x = ad : GOSUB 230 ' Print address
690 FOR n = 1 TO 16
700 a = PEEK (ad)
710 a$ = CHR$ (a)
720 PRINT RIGHT$ ("0" + HEX$ (a), 2) ; " " ;
730 IF (a < &H20) OR (a > &H7E) THEN a$ = "."
740 alpha$ = alpha$ + a$
750 ad = ad + 1
760 IF ad > af THEN PRINT alpha$ : RETURN
770 NEXT n
780 PRINT alpha$
790 IF ad <= af THEN GOTO 670 ELSE RETURN
800 '
810 '----------------------------------
820 '
830 PRINT
840 PRINT "Resident System Extension"
850 PRINT "-------------------------"
860 PRINT
870 PRINT "A Resident System Extension (RSX) is a special type of program
that can be"
880 PRINT "attached to the operating system to modify or extend the
functionality of"
890 PRINT "the BDOS. RSX modules intercept BDOS functions and either
perform them,"
900 PRINT "translate then into other BDOS functions, or pass them through
untouched."
910 PRINT "The BDOS execute non-intercepted functions in the standard
manner."
920 PRINT
930 '
940 DEF FN deek (x) = (PEEK (x) ) + (256 * PEEK (x + 1) )
950 '
960 addr1 = FN deek (1) - 5 ' Address of current top of User TPA
970 addr1$ = HEX$ (FN deek (addr1) )
980 ' addr1$ = "EE06" ' Debug, use with: A>BASIC /M:&HED80 (Amstrad PCW)
990 '
1000 addr2 = FN deek (1) - 107 ' Address of BDOS entry
1010 addr2$ = HEX$ (FN deek (addr2) )
1020 '
1030 IF addr1$ = addr2$ THEN PRINT CHR$ (7) ; "No RSX(s) in TPA." : GOTO
1350
1040 '
1050 x = VAL ("&H" + addr1$)
1060 x = x + 0 : GOSUB 440 : PRINT TAB (19) "Start: JMP " ;
1070 x = x + 1 : GOSUB 300 : PRINT TAB (46) "; Jump to start of this RSX"
1080 x = x + 2 : GOSUB 440 : PRINT TAB (19) "Next: JMP " ;
1090 x = x + 1 : GOSUB 300 : PRINT TAB (46) "; Jump to next RSX"
1100 nextrsx = FN deek (x)
1110 x = x + 1 : GOSUB 230
1120 GOSUB 460 : PRINT TAB (19) "Prev: DW " ; : x = x + 1
1130 GOSUB 300 : PRINT TAB (46) "; Previous module"
1140 x = x + 2 : GOSUB 230 : PRINT HEX$ (PEEK (x), 2) ;
1150 PRINT TAB (19) "Remove: DB " ;
1160 GOSUB 380 : PRINT TAB (46) "; Remove flag " ;
1170 IF PEEK (x) = &HFF THEN PRINT "(yes)" ELSE PRINT "(no)"
1180 x = x + 1 : GOSUB 230 : PRINT HEX$ (PEEK (x), 2) ;
1190 PRINT TAB (19) "Nonbnk: DB " ;
1200 GOSUB 380 : PRINT TAB (46) "; Nonbank flag " ;
1210 IF PEEK (x) = &HFF THEN PRINT "(yes)" ELSE PRINT "(no)"
1220 x = x + 1
1230 ad = x + 0 : af = x + 7 : GOSUB 520 : GOSUB 440
1240 PRINT TAB (19) "Name: DB '" ; alpha$ ; "' ; Any 8-character
name"
1250 x = x + 8 : GOSUB 230 : PRINT HEX$ (PEEK (x), 2) ;
1260 PRINT TAB (19) "Loader: DB " ;
1270 GOSUB 380 : PRINT TAB (46) "; Loader flag " ;
1280 IF PEEK (x) = &HFF THEN PRINT "(yes)" ELSE PRINT "(no)"
1290 x = x + 1 : GOSUB 230 : PRINT HEX$ (PEEK (x), 2) ;
1300 PRINT TAB (27) "DB " ;
1310 GOSUB 380 : PRINT TAB (46) "; (Reserved)"
1320 x = x + 1 : GOSUB 230 : PRINT HEX$ (PEEK (x), 2) ;
1330 PRINT TAB (27) "DB " ;
1340 GOSUB 380 : PRINT TAB (46) "; (Reserved)"
1350 PRINT
1360 'PRINT "+++ Dump of this RSX +++"
1370 'PRINT
1380 'ad = x + 1 : af = nextrsx - 1 : GOSUB 660 ' Dump
1390 '
1400 IF x < VAL ("&H" + addr2$) THEN x = nextrsx : GOTO 1060
1410 '
1420 IF hc$ = "Y" AND mallard = 2 THEN POKE 8792,195
1430 IF hc$ = "Y" AND mallard = 3 THEN POKE 29161,195
1440 '
1450 END
The above program generates the following display, when run on an
Amstrad
PCW8256:
A>basic
Mallard-80 BASIC with Jetsam Version 1.29
(c) Copyright 1984 Locomotive Software Ltd
All rights reserved
29549 free bytes
Ok
run"rsx
RSX: Do you want a hardcopy (Y/N) : ? n
Resident System Extension
-------------------------
A Resident System Extension (RSX) is a special type of program that can be
attached to the operating system to modify or extend the functionality of
the BDOS. RSX modules intercept BDOS functions and either perform them,
translate then into other BDOS functions, or pass them through untouched.
The BDOS execute non-intercepted functions in the standard manner.
0EE06H: C3 34 EE Start: JMP 0EE34H ; Jump to start of this RSX
0EE09H: C3 06 F3 Next: JMP 0F306H ; Jump to next RSX
0EE0BH: 07 00 Prev: DW 0007H ; Previous module
0EE0EH: 00 Remove: DB 00H ; Remove flag (no)
0EE0FH: 00 Nonbnk: DB 00H ; Nonbank flag (no)
0EE10H: 50 55 54 Name: DB 'PUT ' ; Any 8-character name
0EE18H: 00 Loader: DB 00H ; Loader flag (no)
0EE19H: 00 DB 00H ; (Reserved)
0EE1AH: 00 DB 00H ; (Reserved)
0F306H: C3 1B F3 Start: JMP 0F31BH ; Jump to start of this RSX
0F309H: C3 06 F6 Next: JMP 0F606H ; Jump to next RSX
0F30BH: 0B EE Prev: DW 0EE0BH ; Previous module
0F30EH: 00 Remove: DB 00H ; Remove flag (no)
0F30FH: 00 Nonbnk: DB 00H ; Nonbank flag (no)
0F310H: 4C 4F 41 Name: DB 'LOADER ' ; Any 8-character name
0F318H: FF Loader: DB 0FFH ; Loader flag (yes)
0F319H: 00 DB 00H ; (Reserved)
0F31AH: 00 DB 00H ; (Reserved)
Ok
system
A>That's all, folks!
Yours Sincerely,
"French Luser"
EOF
French Luser
Gasp! I wanted to say: about 4%...
Yours Sincerely,
"French Luser"
Lee Hart
> At the time CP/M was being used, the popular way to do graphics was
> with Tektronix graphics terminals.
...or systems that emulated a Tektronix terminal.
> The computer was text only, the terminal would supply the graphic
> ability (with a storage CRT).
...or a standard raster-scanned CRT, with a digital logic board and some
memory.
I had a Cleveland Codonics graphics board in my H89, and still have a
Northwest Digital board. Both emulated a Tektronix 4010. The neat thing
about the 4010 was that you just had to send it a brief command, like
draw a line from X1,Y1 to X2,Y2. The terminal took care of all the
details to plot all the points between. It was a good way to simplify
the processing that the CP/M computer had to do, and eliminated
dependency on knowing the exact resolution of the display device.
Thus, there were some graphics programs and games on the H89 using the
Tektronix 4010 command set. I had "Plotware Z", which specialized in
graphs, charts, and wire-frame drawings. I've also seen games like
Asteroids and Y-wing which drew wire-frame spaceships and terrain that
ran at several frames per second even on a 2 MHz Z80.
--
Ring the bells that still can ring
Forget the perfect offering
There is a crack in everything
That's how the light gets in -- Leonard Cohen
--
Lee A. Hart, 814 8th Ave N, Sartell MN 56377, leeahart_at_earthlink.net
glen herrmannsfeldt
(snip)
> I had a Cleveland Codonics graphics board in my H89, and still have a
> Northwest Digital board. Both emulated a Tektronix 4010. The neat thing
> about the 4010 was that you just had to send it a brief command, like
> draw a line from X1,Y1 to X2,Y2. The terminal took care of all the
> details to plot all the points between. It was a good way to simplify
> the processing that the CP/M computer had to do, and eliminated
> dependency on knowing the exact resolution of the display device.
Note that on a real 4010 there are no points in between. The display
is a storage CRT, and a continuous line is drawn between two points,
as far as I remember using mostly analog circuitry. Probably one or two
DACs to convert the coordinates to voltages, and then analog circuits to
do the rest. Once drawn, the image is stored as charge on the inside of
the CRT.
> Thus, there were some graphics programs and games on the H89 using the
> Tektronix 4010 command set. I had "Plotware Z", which specialized in
> graphs, charts, and wire-frame drawings. I've also seen games like
> Asteroids and Y-wing which drew wire-frame spaceships and terrain that
> ran at several frames per second even on a 2 MHz Z80.
By that time memory was affordable. In the early CP/M days 64K was
a lot of memory, leaving none left for a bitmap display. I did
know a group in 1977 working on a custom display terminal that could
either store scrollable text (with a big scroll wheel on the side) or
one screen of bitmap emulated 4010. They had donated intel memory with
no markings on it.
http://www.slac.stanford.edu/cgi-wrap/getdoc/slac-pub-1715.pdf
-- glen