Graphic Subsystem Simulators on SIMH
Sergio Pedraja
about this question that appears in the "things to do" list in the
Bob Supnik's site.
Is there some kind of development do it under UNIX ?
Somebody tried to probe it with MINGW (if exists) ?
Is there documentation about the PDP family graphic systems in some place ?
Ever can be translated the work do it with the Java Simulator of Spacewar,
or the work do it under MESS multi-microcomputer simulator, but I'd like
to know if exists some other work about this matter.
Greetings
Sergio
Al Kossow
> Is there documentation about the PDP family graphic systems in some place ?
>
I have some docs on the VT-11 and the VT-48, the PDP-11 Fortran
graphics library, and on the 338/339. I just finished scanning
the FGP docs, so they should be up a a week or so.
The type 30 display is described in the PDP-1 docs. There's also
some info on the PDP-12 point plot display in the PDP12 system
manual.
All of these devices are either caligraphic or point-plot displays.
Would be nice to find the VT-15 docs, too.
I'm sure Lunar Lander will run some day in SIMH, assuming Bob can
decide how he wants to handle graphics I/O. The MAME/MESS folks have
a core set of routines which call target-dependent graphics and I/O
code in their simulations.
swo...@speakeasy.org
> I have some docs on the VT-11 and the VT-48, the PDP-11 Fortran
> graphics library, and on the 338/339. I just finished scanning
> the FGP docs, so they should be up a a week or so.
> The type 30 display is described in the PDP-1 docs. There's also
> some info on the PDP-12 point plot display in the PDP12 system
> manual.
> All of these devices are either caligraphic or point-plot displays.
> Would be nice to find the VT-15 docs, too.
> I'm sure Lunar Lander will run some day in SIMH, assuming Bob can
> decide how he wants to handle graphics I/O. The MAME/MESS folks have
> a core set of routines which call target-dependent graphics and I/O
> code in their simulations.
Very good! :-) Also, I have a copy of VCB02 tech manual for MicroVAX II.
I got it from one of DECUS's web sites. I forget which site. After
I get RQDX3 emulator working, I will implement VCB02 interface with
graphics I/O. Also, I will work on TMS9900 emulator for TI-99/4A and
Geneve. I know TI-99/4A specs so well. VCB01 is monochrome graphics
but VCB02 is 256-color graphics for MicroVAX systems.
Does anyone have plotter specs for PDP-10? I remember that when I wrote a
program on PDP-10 to produce graphics on the plotter printer at
Gallaudet University. Also, I took a computer graphics course
for my major (computer science) by using VAX system with Tek 4207
graphics terminal.
-- Tim Stark
--
Timothy Stark <>< Inet: swo...@speakeasy.org
--------------------------------------------------------------------------
"For God so loved the world, that he gave his only begotten Son, that
whosoever believeth in him should not perish, but have everlasting life.
Amen." -- John 3:16 (King James Version Bible)
Hans B Pufal
> I'm sure Lunar Lander will run some day in SIMH, assuming Bob can
> decide how he wants to handle graphics I/O. The MAME/MESS folks have
> a core set of routines which call target-dependent graphics and I/O
> code in their simulations.
Some time ago I did some work replacing the SIMH SCP with a Tcl/TK
framework which allowed me some limited graphics. I actually got the
PDP-1 simulator to run spacwar after a fashion (rather slowly and the
graphics were not prefect). Tcl/TK would could also provide front
panel emulation.
Contact me if you are interested in progressing this work.
-- hbp
Douglas H. Quebbeman
news:u0fikvg...@corp.supernews.com...
>
> Does anyone have plotter specs for PDP-10? I remember that when I wrote a
> program on PDP-10 to produce graphics on the plotter printer at
> Gallaudet University. Also, I took a computer graphics course
> for my major (computer science) by using VAX system with Tek 4207
> graphics terminal.
Whose plotters was DEC selling under their label? I'd guess it to be
Calcomp... surely DEC didn't get involved in designing and selling
their own plotters.
I'll have to look at the old newsletters to see what kind of plotter IUPUI
had; however, we could use NPRINT (Network PRINT) to send our
Indianapolis-resident plot files to the Versatec plotter in Bloomington
connected to the CDC 6600...
BTW, that was 1974 networking. Except for some character conversion
issues, it was fairly transparent networking from the user perspective.
-dq
Tim Shoppa
>Does anyone have plotter specs for PDP-10? I remember that when I wrote a
>program on PDP-10 to produce graphics on the plotter printer at
>Gallaudet University.
Examples of interfaces to the LIB40 Plotter subroutine can be found in
DECUS library entry 10-228, CALCOMP Plotter Package, Version: 2.
Extensive documentation is included. See
http://pdp-10.trailing-edge.com/www/lib10/0344/
Another very common high-level plotting interface (largely to Tektronix
devices, though other manufacturers provided similar libraries) is the
PLOT10 library. (The 10 comes from Tek4010, not from PDP-10.) Tek4010
emulators have been everywhere for decades now (maybe you don't know it,
but your "xterm" box does 4010 emulation, as does MS-DOS Kermit) so this
is a very attractive industry standard.
Tim.
Phil Budne
Douglas H. Quebbeman <do...@ixnayamspayiglou.com> wrote:
>Whose plotters was DEC selling under their label? I'd guess it to be
>Calcomp... surely DEC didn't get involved in designing and selling
>their own plotters.
home% grep XY10 10periphs
BA10 hard copy control for CR10, LP10, XY10
XY10 plotter (Calcomp 502, 518, 563, 565, 602, 618, 663, 665 or similar)
(the file 10periphs is available from http://www.ultimate.com/phil/pdp10/
this particular information came out of a BA10 manual someone had scanned
and put on line, but I can't remember where I saw it...)
-phil
Douglas H. Quebbeman
news:9u8u4b$4nb$1...@news3.bu.edu...
> In article <3c07e4b5$1...@news.iglou.com>,
> Douglas H. Quebbeman <do...@ixnayamspayiglou.com> wrote:
> >Whose plotters was DEC selling under their label? I'd guess it to be
> >Calcomp... surely DEC didn't get involved in designing and selling
> >their own plotters.
>
> home% grep XY10 10periphs
> BA10 hard copy control for CR10, LP10, XY10
> XY10 plotter (Calcomp 502, 518, 563, 565, 602, 618, 663, 665 or
similar)
Well, tickle my ass with a feather, er, particularly nice weather...
The Calcomps are no surprise, but they did ddo there own, huh?
What technology? Pens? Electrostatic?
-dq
Bob Supnik
portability, short of moving the whole thing into Java (and who knows
how long that would work on Windoze ;).
Seriously, I haven't done graphics because the portability problem
appears to be overwhelming. (There still isn't a port of the sim_sock
library for VMS.) I realize that most of this community runs on Unix
variants, but the SIMH user community includes people running Windows,
MacOS, VMS, OS/2, and even MS DOS.
/Bob
Al Kossow
<bsu...@nauticusnet.com> wrote:
> Hans' approach seems to be the only one that would preserve
> portability
The MAME/MESS approach of an common core with machine dependent
interfaces appears to disprove this theory.
Thinking about it a bit, I think what you're trying to do is
find a set of portable interfaces to talk to across the platforms
you want to run the simulations on, and, I agree, this doesn't
really exist. I don't see what's wrong with having to come up
with a set of platform-specific routines esp if you're having
to deal with graphics devices.
You can always have a 'dumb' set of I/O routines to start,
which could be based on STDIO to get basic tty comms working.
If you're interested in talking to one of the main graphics
core coders on MAME, Bob, I'd be happy to introduce you to
him.
Tim Shoppa
> If you're interested in talking to one of the main graphics
> core coders on MAME, Bob, I'd be happy to introduce you to
> him.
I know that MAME emulators do graphics, sound, and joystick I/O; is
there a "common" MAME core of interfaces for tape, disk, network, and
terminal multiplexer I/O?
Tim.
Sergio Pedraja
> Some time ago I did some work replacing the SIMH SCP with a Tcl/TK
> framework which allowed me some limited graphics. I actually got the
> PDP-1 simulator to run spacwar after a fashion (rather slowly and the
> graphics were not prefect). Tcl/TK would could also provide front
> panel emulation.
>
> Contact me if you are interested in progressing this work.
I should like to put an eye in this work, Hans, if you don't have
inconvenience.
Greetings
Sergio
Sergio Pedraja
> > Hans' approach seems to be the only one that would preserve
> > portability
I think that your appointment about JAVA portability of the SIMH
is the better choice possible. The C development will be more
complex in the future, I think.
I don't believe that Windoze will kick off the Java Technology
from itself (other thing would be what Sun could have in mind,
of course...) in a future.
> The MAME/MESS approach of an common core with machine dependent
> interfaces appears to disprove this theory.
This appointment of Al is very interesting too. It goes in the same
direction that my MESS appointment. I use MAME, MESS, SIMH, KLH10, TS10
and HERCULES simulators every week, and I should like to have one
more close relation between all of them (saving the distances of
one PDP10 and VAX from one IBM 370 with MVS, and...
one Sinclair ZX Spectrum) mainly in the matter we are speaking
(graphics) and in Virtual Disks and Pehipherals.
> You can always have a 'dumb' set of I/O routines to start,
> which could be based on STDIO to get basic tty comms working.
I think I know the way you signal to take...
> If you're interested in talking to one of the main graphics
> core coders on MAME, Bob, I'd be happy to introduce you to
> him.
Well, this is a Bob's decision, but one experienced person in graphics
simulation like this appears to have winned at least an interchange
of opinions :-)
Finally, we can begin to do some practical things.
Suppose I want to reproduce the graphics management of, by example,
one PDP1. Questions are:
* What was the graphics terminal(s) used in this machine ?
* What was the graphics controller (if applicable) used with it ?
* What new machine code instructions and/or registers was added
to the computer equipped with one graphics system ?
* The other usual questions related with the previous.
Second stage: If I can obtain all this info...
* Must I treat the graphics terminal like one additional device
or must I only like one TTY with special settings ?
Third stage: The graphics management...
* Is there exists some kind of graphics library that works over
diverse platforms with C language ? I think there is one in GCC
and GNU environments but I don't remember what.
* If this exists, can be do it one thing I do usually with Clipper
Compiler: to define a group of functions that involve the access
to the functions supported in every library selected. This suppose
portability in a future in the graphics library is changed, and
even support for diverse platforms if it haven't the main graphics
library supported in its environment.
I'd like to read your opinions about these matters.
Thanks and Greetings
Sergio
Douglas H. Quebbeman
>
> The MAME/MESS approach of an common core with machine dependent
> interfaces appears to disprove this theory.
>
> Thinking about it a bit, I think what you're trying to do is
> find a set of portable interfaces to talk to across the platforms
> you want to run the simulations on, and, I agree, this doesn't
> really exist. I don't see what's wrong with having to come up
> with a set of platform-specific routines esp if you're having
> to deal with graphics devices.
>
> You can always have a 'dumb' set of I/O routines to start,
> which could be based on STDIO to get basic tty comms working.
>
> If you're interested in talking to one of the main graphics
> core coders on MAME, Bob, I'd be happy to introduce you to
> him.
I'd love to see a MAME-based generic graphics console mode
for which a given simulator implementor would merely need to
write a few glue routines to use. I was thinking of hacking MAME32
into something to do this for the CDC 6602/6612 Display Console
emulator that I will eventually need...
-dq
Jan van Mastbergen
implementations of old graphics protocols (i.e. tek4010, regis, calcomp...0
on more popular hardware as pc graphics cards or unix workstation
accelerators and integrate these into simh. To support all eligible hardware
emulators this way on the set of platforms that simh supports would indeed
give you a huge porting problem.
With a third party common multi-platform graphics API, that is sufficiently
powerful, all of the specifics of the antique devices could be implemented
in a much more portable way. I know that elsewhere in this thread MAME has
been suggested but have you considered OpenGL? In the rare case that your
favorite OS vendor or graphics card driver do not provide an implementation,
there is always Mesa (www.mesa3d.org).
Jan
Bob Supnik <bsu...@nauticusnet.com> wrote in message
news:g24g0u8kddnmbdfnv...@4ax.com...
jmfb...@aol.com
>portability, short of moving the whole thing into Java (and who knows
>how long that would work on Windoze ;).
>
>Seriously, I haven't done graphics because the portability problem
>appears to be overwhelming.
<snip>
The support problems certainly were. That may be why we didn't
do much with it.
/BAH
Subtract a hundred and four for e-mail.
Wilber Williams
http://chook.cc.uq.edu.au/DEC-10-12AA-D%20BA10%20Hard%20Copy%20Control.pdf
Wilber
--
Wilber
Associate Director, Networks And Design Services
+----------------------------------------------------------------------+
|Wilber WILLIAMS w.wil...@its.uq.edu.au |
| Telephone : +61 7 3365 4232 |
|ITS The University of Queensland Facsimile : +61 7 3365 7539 |
|Brisbane Qld 4072 AUSTRALIA Mobile : +61 412 210 063 |
+----------------------------------------------------------------------+
gerry moersdorf
I think i can answer some of these questions. I went to ohio state
univesity in 1970, and worked on their PDP-10. It was uniquely equiped with
the same display offered on the PDP-6 which was a version of the display on
the PDP-1. It was constructed of PDP-1 style "DEC Building blocks" modules,
and boy did it have a lot of em. The display was called the DEC 340
display. It had a flock of indicators above the round 20" or so "bottle"
which could draw vector graphics. The display was connected to the PDP10
via the bus connectors and a DMA interface. We only ever programed the
display in PDP-10 assembler, i remember my code for a simulation of the game
of life having a zillion XWD descriptors in the code, so trying to emulate
this motha would be a lot of work, you might be best off just trying to code
the game (lunar lander) from scratch with simulated vector graphics. I
wrote at the time a character generator since our 340 display did not have
the optional character generator.
But those were the good old days.
>
> * What was the graphics terminal(s) used in this machine ?
> * What was the graphics controller (if applicable) used with it ?
> * What new machine code instructions and/or registers was added
> to the computer equipped with one graphics system ?
> * The other usual questions related with the previous.
>
Douglas H. Quebbeman
news:eCRO7.11$6u3.803@client...
> Greetings to the group.
>
> I think i can answer some of these questions. I went to ohio state
> univesity in 1970, and worked on their PDP-10. It was uniquely equiped
with
> the same display offered on the PDP-6 which was a version of the display
on
> the PDP-1. It was constructed of PDP-1 style "DEC Building blocks"
modules,
> and boy did it have a lot of em. The display was called the DEC 340
> display. It had a flock of indicators above the round 20" or so "bottle"
> which could draw vector graphics. The display was connected to the PDP10
> via the bus connectors and a DMA interface. We only ever programed the
> display in PDP-10 assembler, i remember my code for a simulation of the
game
> of life having a zillion XWD descriptors in the code, so trying to
emulate
> this motha would be a lot of work, you might be best off just trying to
code
> the game (lunar lander) from scratch with simulated vector graphics. I
> wrote at the time a character generator since our 340 display did not have
> the optional character generator.
The code should run as-on on the existing simulators, once an
emulator for the display is coded. The only vector display I'm
intimate with has a whopping three commands- set X coord,
set Y coord, draw dot- that would have to be emulated. The
display's persistence does all the rest.
And persistence is not difficult to emulate. You send a series of
commands to the emulated display controller. The emulated con-
troller builds a display list from the commands, adding a timestamp
to each list node. The redisplay routine traverses the list, checking
the timestamps of each node, discarding those that have expired,
and dispatching those that are still in the list.
Since MAME32 would appear to already do this, it's a great
candidate for basing such an emulator.
-dq
Rich Alderson
> I think i can answer some of these questions. I went to ohio state
> univesity in 1970, and worked on their PDP-10. It was uniquely equiped with
> the same display offered on the PDP-6 which was a version of the display on
> the PDP-1.
WTF????
You mean I could have learned the PDP-10 years before I did? (OSU BA 1975.)
Where was it located on campus (departmentally speaking)? The CIS department
used the main 370/165 for the assembly language programming class (and the prof
was very proud of his new Nova, which he showed off to those in the class who
were interested).
--
Rich Alderson alders...@panix.com
"You get what anybody gets. You get a lifetime." --Death, of the Endless
gerry moersdorf
for grad students only, but i got a job as the operator, i learned a lot
more there than i did sliding my card deck in the window at IRCC. The IBM
computer was for dudes who wore white shirts and ties to class, and took no
joy in taking apart their computer. The pdp10 was crippled at OSU it only
had 64k memory and no disk for the first 2 years, so we did everything in
memory and on dectapes, all i/o was via 8 teletype 33's in the terminal room
adjacent in caldwell lab, but it beat queueing up for a keypunch at IRCC.
it was revolutionary at the time and it changed my life. god am i glad i am
wearing jeans and not a suit. the 10 was also far from reliable, we had two
light bulbs in the window at the top floor of caldwell lab ( it was a long
hike up the stairs ) one lamp was green (system up) and one red (broke
again)!!!!!
"Rich Alderson" <alders...@panix.com> wrote in message
news:mddpu5v...@panix3.panix.com...