Re: [Simh] An idea for graphics support in SIMH

[Leo Broukhis]

Richard  writes:

>> A great showcase for graphics support using VNC could be Terak
>> (http://en.wikipedia.org/wiki/Terak_8510/a) that had a "smart" frame
>> buffer with downloadable fonts, hardware-assisted scrolling, and
>> text/graphics overlay.
>
> I have a Terak in my collection.
>
> I'm not sure why this makes a case for VNC vs. a local client though.

RFB protocol features (CopyRect) that facilitate handling of scrolling and fonts
 will allow for a more efficient implementation.

Using a portable library (e.g. SDL) is also possible but, IMO, it will
be more tedious
to build from source without providing any benefit compared to a VNC client,
unless we get to the point when we need to synchronize video with sound.

Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Sergiusz Jarczyk]

Hi
Sorry for my ignorance in the emulation field - I'm coming form
applications development world. I like the ideas I see in this thread,
and I'd like to share with you some ideas. First, the most valuable
for me would be an emulator for DEC-produced systems' graphics
controllers (PDP-11 and VAX). I understand SimH simulates much more
platforms, and that's why the concept of generic virtual framebuffer
for SimH is IMHO the best starting point. Looking at the sources of
QEMU and VirtualBox OSE, it would be possible to:
1. Rewrite simh_console code to make it looks like VirtualBox/VMWare
console, with all video parameters defined BEFORE running the
simulation (with Qt or GTK, we could still maintain portability). It
can be enabled/disabled by additional switch, added to final
executive, or during compilation.
2. Create additional device driver, which can be enabled with the
'set' command, that opens second window, much like Hercules emulator.
3. Variation of above, where we can issue set command, followed by
parameters needed for connecting to VNC server.
Options 2 and 3 don't touch base SimH, so these would have no impact
on other simulators. I like 2, but 3 is also OK - as someone said,
it's better to have something than nothing... :-)

Sergiusz
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Alan Frisbie]

> One thing that's always bugged me was the fact that SIMH has no
> real support for graphics.

About six years ago, Doug Gwyn  did a complete
implementation of the DEC GT48 (a.k.a. VS60) for SIMH/PDP-11.
The goal was to be able to play the Lunar Lander game.
When I last discussed it with him, it was passing all the
relevant XXDP diagnostics.   I don't know if he ever checked
in his code with SIMH.   You might want to contact him about
it.

Alan

--  Alan E. Frisbie   fris...@flying-disk.com
--  Flying Disk Systems, Inc.
--  4759 Round Top Drive  323-256-2575
--  Los Angeles, CA 90065
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Brian Knittel]

> On 7 Jul 2010 at 19:53, Michael Kerpan wrote:

> ... As to why the graphics would be done through RFB rather than
> through direct display, that's just to keep things cross-platform
> by off-loading the platform-specific work of displaying graphics
> to external programs rather than having code display routines for
> every platform SIMH runs on into the codebase. 

Exactly. The big win here is making TCP/IP the part that has to be 
abstracted for all SIMH host platforms, rather than the graphics 
display. It will still be challenging. 

Second, a (small) bonus is that it lets you run the VNC display client 
on any any computer, on any operating system. You can run SIMH on a 
machine that doesn't have its own graphics display, if necessary, and 
run the VNC client on another machine. I can see that being useful in 
some cases.

(And wansn't this talked about about 6 years ago? Didn't go anywhere?)

Also, re the conversation about some SIMH guests already having X 
support, that's fine, for a small corner of the SIMH universe
where X implementations were available. There is more to SIMH than
the MicroVAX. I'm talking about emulating OLD graphics hardware here, 
with (usually) very peculiar, OS-integrated driver support, from long 
before X existed. 

And the Tektronics stuff is, well, it's cute, but it's just
application software spitting control codes out a simulated serial
port, right? The good stuff all takes place in the add-on terminal.
The fun part here is resurrecting the native display devices 
themselves.

Unless someone is talking about making a SIMH 4014?

Brian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_| _| _|  Brian Knittel
_| _| _|  Quarterbyte Systems, Inc.
_| _| _|  Tel: 1-510-559-7930
_| _| _|  http://www.quarterbyte.com

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Richard]

In article ,
Leo Broukhis   writes:

> A great showcase for graphics support using VNC could be Terak
> (http://en.wikipedia.org/wiki/Terak_8510/a) that had a "smart" frame
> buffer with downloadable fonts, hardware-assisted scrolling, and
> text/graphics overlay.

I have a Terak in my collection.

I'm not sure why this makes a case for VNC vs. a local client though.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 

  Legalize Adulthood! 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Michael Kerpan]

On Wed, Jul 7, 2010 at 7:01 PM, Richard  wrote:
>
> In article ,
>    Michael Kerpan   writes:
>
>> emulation code could write to and that could be viewed by an external
>> client.
>
> I guess I'm confused why an external client is necessary.
>
> It seems like it would be simpler to provide a local client.
>
> When I first saw this thread I thought it was going to be discussing a
> graphical front panel for the machine, augmented with a view of the
> machine architecture (register contents, single step, etc.).  Now I
> realize this is something different, but I think that would be nice to
> have.  You really can understand a CPU architecture better when you
> can single step execution and watch the register contents change.

I think a debugger would be good too, but I think that something that
increases the pool of software that can run is more useful. A to why
the graphics would be done through RFB rather than through direct
display, that's just to keep things cross-platform by off-loading the
platform-specific work of displaying graphics to external programs
rather than having code display routines for every platform SIMH runs
on into the codebase.

Mike
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Leo Broukhis]

A great showcase for graphics support using VNC could be Terak
(http://en.wikipedia.org/wiki/Terak_8510/a) that had a "smart" frame
buffer with downloadable fonts, hardware-assisted scrolling, and
text/graphics overlay.

Leo
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Richard]

In article ,
Michael Kerpan   writes:

> emulation code could write to and that could be viewed by an external
> client.

I guess I'm confused why an external client is necessary.

It seems like it would be simpler to provide a local client.

When I first saw this thread I thought it was going to be discussing a
graphical front panel for the machine, augmented with a view of the
machine architecture (register contents, single step, etc.).  Now I
realize this is something different, but I think that would be nice to
have.  You really can understand a CPU architecture better when you
can single step execution and watch the register contents change.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 

  Legalize Adulthood! 
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Michael Kerpan]

On Wed, Jul 7, 2010 at 1:25 PM, Shoppa, Tim  wrote:
> I suppose some people want to run an archaic windowing system.
>
> I look at this a little differently - I usually want to run an archaic 
> application. And that archaic application usually supports
> Tek 4014 or similar graphics. In fact it usually didn't run under a windowing 
>  or framebuffer system to begin with.

That's fine, but there are still whole bunches of things that don't
support 4014 graphics that would be fun to muck with. The VAX
framebuffer is one example. The built-in vector display system of the
PDP-1 is another. Various graphics cards for systems like the PDP-11
or the S100 bus system are another still. All these things would
benefit from SIMH having a virtual framebuffer that graphical device
emulation code could write to and that could be viewed by an external
client. I'm not saying that good Tektronix emulation won't take care
of a lot of graphics stuff, I'm just saying that a modular system to
allow for guest-specific video hardware to be emulated in a uniform
way would useful.

PS, are there any free terminal emulators with support for
terminal-based graphics? Xterm does a mediocre job with Tek, but other
systems like DEC Regis/Sixel and DG Dasher seem to be completely
unsupported by any free (over even cheap) software in any meaningful
way... Maybe a nice cross-platform retro-oriented terminal emulation
suite would make a nice counterpart to SIMH?
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Jason Stevens]

What if your host doesn't have X11...?

Also I would surmise you could 'borrow' the vnc code from Qemu .They've
managed to work that into all kinds of frame buffers




On Wed, Jul 7, 2010 at 11:37 AM, Michael Kerpan  wrote:

> One thing that's always bugged me was the fact that SIMH has no real
> support for graphics. Some up the supported platforms (such as the
> PDP-1) are widely recognized as important because of there graphical
> display abilities. Others, such as the VAX were often sold with a
> framebuffer installed for use as workstations. The general problem
> with graphics, however, has always been that they make things less
> cross-platform. Having a lot of free time over the summer to think
> about such things, I recently hit upon an idea: why not implement
> graphics systems via the RFB/VNC protocol?  That way, any people could
> simply attach the "framebuffer" or "vector display" to a TCP/IP port
> and connect with any number of free clients. Do people think that
> something like this would be workable? It seems like a crazy idea, but
> then again, it also seems in keeping with other things that SIMH does,
> such as implement terminal multiplexers over TELNET...
>
> Mike
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Sampsa Laine]

Zane,

I've managed to get CDE working with Xnest on OS X, example given for  
a 1680x1050 screen:


Xnest -geometry 1680x1050 -ac -query  :


Sampsa


On 7 Jul 2010, at 18:24, Zane H. Healy wrote:

> I don't believe you get CDE with OpenVMS/VAX.  I've found that with my
> Alpha's I prefer to use a WinXP box with free X-Windows software as my
> "X-Terminal".  Sadly the version of X-Windows that ships with Mac OS  
> X is
> lacking.  Though I can still display apps on Mac OS X, I've never
> successfully gotten CDE running (I did under System 8).
>
> For any X-Windows apps running on VMS, I would think that even with  
> SIMH/VAX
> this would be the preferable solution.
>
> Zane
>
>
>
>
> On Wed, 7 Jul 2010, Sergiusz Jarczyk wrote:
>
>> Hi All
>> I think we should clarify what we're talking about... Xterm/Kermit
>> emulation of Tek is great, I agree, but are we're talking about
>> running X/Motif-based VAX apps on other machines, which is not a
>> problem at all, or do we want to see the CDE login screen in our Simh
>> window? I was referring to the later... ;-)
>>
>> Sergiusz
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Sergiusz Jarczyk]

2010/7/7 Zane H. Healy :
> I don't believe you get CDE with OpenVMS/VAX.  I've found that with my
> Alpha's I prefer to use a WinXP box with free X-Windows software as my
> "X-Terminal".  Sadly the version of X-Windows that ships with Mac OS X is
> lacking.  Though I can still display apps on Mac OS X, I've never
> successfully gotten CDE running (I did under System 8).
>
> For any X-Windows apps running on VMS, I would think that even with SIMH/VAX
> this would be the preferable solution.
>

Actually, it's pretty easy to get CDE session running, at least on
Linux... The only thing you need is to enable TCP listening for X
server (most modern Linux distros have nolisten as default) and
disable access control (X -ac), and you have the login screen within
few minutes... :-)

Sergiusz
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Shoppa, Tim]

I suppose some people want to run an archaic windowing system.

I look at this a little differently - I usually want to run an archaic 
application. And that archaic application usually supports Tek 4014 or similar 
graphics. In fact it usually didn't run under a windowing  or framebuffer 
system to begin with.

Tim.

From: simh-boun...@trailing-edge.com [simh-boun...@trailing-edge.com] On Behalf 
Of Sergiusz Jarczyk [sjarc...@gmail.com]
Sent: Wednesday, July 07, 2010 1:14 PM
To: simh@trailing-edge.com
Subject: Re: [Simh] An idea for graphics support in SIMH

Hi All
I think we should clarify what we're talking about... Xterm/Kermit
emulation of Tek is great, I agree, but are we're talking about
running X/Motif-based VAX apps on other machines, which is not a
problem at all, or do we want to see the CDE login screen in our Simh
window? I was referring to the later... ;-)

Sergiusz
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Zane H. Healy]

I don't believe you get CDE with OpenVMS/VAX.  I've found that with my
Alpha's I prefer to use a WinXP box with free X-Windows software as my
"X-Terminal".  Sadly the version of X-Windows that ships with Mac OS X is
lacking.  Though I can still display apps on Mac OS X, I've never
successfully gotten CDE running (I did under System 8).

For any X-Windows apps running on VMS, I would think that even with SIMH/VAX
this would be the preferable solution.

Zane




On Wed, 7 Jul 2010, Sergiusz Jarczyk wrote:

> Hi All
> I think we should clarify what we're talking about... Xterm/Kermit
> emulation of Tek is great, I agree, but are we're talking about
> running X/Motif-based VAX apps on other machines, which is not a
> problem at all, or do we want to see the CDE login screen in our Simh
> window? I was referring to the later... ;-)
>
> Sergiusz
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Zane H. Healy]

On Wed, 7 Jul 2010, Brian Knittel wrote:

> This seems like a good approach. Besides the PDP-1, the PDP-11 had the
> VT-11 and the IBM 1130 had the 2250. These are very similar devices --
> asynchronous display-list vector display processors. Who knows -- maybe
> someone can rig up an Evans and Sutherland PS2 for the PDP-11/70. (I
> think Tom Ferrin's UNIX V6 drivers are available?).

There were quite a few DEC and non-DEC graphics boards for the PDP-11.  I
have a 3rd party q-bus board, but have never gotten around to trying to find
software, or a monitor (and cables) to hook up to it.

Zane


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Sergiusz Jarczyk]

Hi All
I think we should clarify what we're talking about... Xterm/Kermit
emulation of Tek is great, I agree, but are we're talking about
running X/Motif-based VAX apps on other machines, which is not a
problem at all, or do we want to see the CDE login screen in our Simh
window? I was referring to the later... ;-)

Sergiusz
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Shoppa, Tim]

I most frequently used X11 or XWS on the VAX, to emulate a Tek 4014, to run the 
Tek 4014 application

My favorite Tek 4014 emulator, is MS-DOS Kermit.

In the Unix/X-windows world, XTERM has emulated Tek 4014 from day one.

I betcha you've got a Tek 4014 emulator on your desktop already and you just 
never knew it.

Tim.

-Original Message-
From: madcrow.maxw...@gmail.com [mailto:madcrow.maxw...@gmail.com] On Behalf Of 
Michael Kerpan
Sent: Wednesday, July 07, 2010 12:46 PM
To: Shoppa, Tim
Cc: simh@trailing-edge.com
Subject: Re: [Simh] An idea for graphics support in SIMH

That's true, but 4014 emulation still can't help with systems like the
PDP-1 which had a built-in vector display or the VAX which often WAS
equipped with an FB. Just because programs that used Tek 401x vector
tubes work in Xterm doesn't mean that a solution to simulate other
sorts of displays isn't a good idea.

Mike

Also, aprt from Xterm, are there even any free Tek emulations around?
Just like REGIS/Sixel support, Tek emulation seems to be a feature
found only in expensive commercial programs.
On Wed, Jul 7, 2010 at 11:41 AM, Shoppa, Tim  wrote:
> Most graphical applications on minicomputers were accessed not with
> A framebuffer, but with a graphics-enabled terminal. (There
> Are exceptions and you point these out.) Tek 4014 emulation
> Goes a long way for most of my classic minicomputer graphical apps.
>
> Tim.
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Michael Kerpan]

On Wed, Jul 7, 2010 at 12:10 PM, Brian Knittel  wrote:
> This seems like a good approach. Besides the PDP-1, the PDP-11 had the
> VT-11 and the IBM 1130 had the 2250. These are very similar devices --
> asynchronous display-list vector display processors. Who knows -- maybe
> someone can rig up an Evans and Sutherland PS2 for the PDP-11/70. (I
> think Tom Ferrin's UNIX V6 drivers are available?).
>
> The approach would also work well for machines with pixel- and
> character-based graphics like the IBM 5100 and 5110. (I have a SIMH
> emulator working, but it's Windows-only at this point due to the
> graphics issue). Then there are the e.g. Cromemco-type boards for the
> Altair, and so on.
>
> It does sort of open a Pandora's Box though, as it invites the
> proliferation of GUI control panels and other fluff. (Says the author
> of a fluffy, hacked-up GUI control panel for SIMH IBM 1130). One thing
> I like about SIMH is that the experience is all about the software,
> rather than on reproducing the physical appearance of the hardware.
>
> The tricky part would be the asynchronous nature of these display
> beasts. Could it be done without using a separate thread? Maybe. Or
> could we work up an abstraction of a display thread that was cross-
> platform and not too ugly? Maybe. It seems to me that this is where the
> difficulty and elegance will lie.
>
> Brian

I kind of figured that the elegance would lie in the fact that all
graphics could be simply written to a "virtual monitor" which would
then be shown to the world by means of RFB/VNC. The outside world
would never talk directly to the display hardware so any asynchronous
aspects could be handled internally. Also, I don't see how emulating
graphical hardware would open the gateway to GUI control panels.
Viewing the output of the virtual Cromemco Dazzler or VT-11 would be
no different in theory than connecting to a virtual serial port over
TELNET is, it's just the remote client program would be one that shows
pictures rather than just text.

Mike
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Michael Kerpan]

That's true, but 4014 emulation still can't help with systems like the
PDP-1 which had a built-in vector display or the VAX which often WAS
equipped with an FB. Just because programs that used Tek 401x vector
tubes work in Xterm doesn't mean that a solution to simulate other
sorts of displays isn't a good idea.

Mike

Also, aprt from Xterm, are there even any free Tek emulations around?
Just like REGIS/Sixel support, Tek emulation seems to be a feature
found only in expensive commercial programs.
On Wed, Jul 7, 2010 at 11:41 AM, Shoppa, Tim  wrote:
> Most graphical applications on minicomputers were accessed not with
> A framebuffer, but with a graphics-enabled terminal. (There
> Are exceptions and you point these out.) Tek 4014 emulation
> Goes a long way for most of my classic minicomputer graphical apps.
>
> Tim.
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Timothe Litt]

Before getting TOO excited - yes, it would be nice - have a look at the June
issue of CACM (http://mags.acm.org/communications/201006/?pg=57#pg57) for a
good description of what's really involved in graphics emulation for old
machines.

It's a really, really hard problem.  At least if you want a 100% solution.
Or one that looks right with classic software...

For VAX, note that remote X-windows does work - and there was a VWS emulator
(by DEC on VAX) that allowed VWS applications to work under X pretty well.
Of course on an LCD display you'll get the pixel artifacts.

I'm actually of the school that something is better than nothing - but
knowing the full scope of the problem is important too.

-
This communication may not represent my employer's views,
if any, on the matters discussed.

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Sampsa Laine]

I agree, I would absolutely LOVE it if SIMH had graphics support, esp  
for VAX and maybe something to run graphical CP/M stuff (GSX etc) on...

I also agree with Michael that RFB/VNC is probably the best way to go  
for something simple and cross-platform (could even integrate a small  
web server/VNC java applet with the server)..

Sampsa


On 7 Jul 2010, at 16:49, Sergiusz Jarczyk wrote:

> 2010/7/7 Michael Kerpan :
>> One thing that's always bugged me was the fact that SIMH has no real
>> support for graphics. Some up the supported platforms (such as the
>> PDP-1) are widely recognized as important because of there graphical
>> display abilities. Others, such as the VAX were often sold with a
>> framebuffer installed for use as workstations. The general problem
>> with graphics, however, has always been that they make things less
>> cross-platform. Having a lot of free time over the summer to think
>> about such things, I recently hit upon an idea: why not implement
>> graphics systems via the RFB/VNC protocol?  That way, any people  
>> could
>> simply attach the "framebuffer" or "vector display" to a TCP/IP port
>> and connect with any number of free clients. Do people think that
>> something like this would be workable? It seems like a crazy idea,  
>> but
>> then again, it also seems in keeping with other things that SIMH  
>> does,
>> such as implement terminal multiplexers over TELNET...
>>
>
> Working with emulated VAX, with which many has replaced systems
> running both OVMS old and new desktops, and considering the problems
> with remote X servers, and, more annoying, problems with X-Window MIT
> ACLs, I was wondered about this too... As I'm Linux user, I'd opted
> for a clean Xt-based emulator, but for a sake of portability, RDB can
> be considered too. The problem is, we'd need to access FB
> software/firmware, which is not as trivial as graphics controllers for
> Alpha systems...
>
> Sergiusz
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Sergiusz Jarczyk]

Mike

2010/7/7 Michael Kerpan :
> It's good to see that folks don't think I'm barking up the wrong tree
> here. Anyways, while I can't code this myself (my C-fu is weak), I'd
> be more than happy to troll the web to dig up documentation in order
> to help anyone who might be interested in implementing this.
> Persoanlly, I would think that the thing to do would be to first set
> up the basic server architecture and then implement a fairly simple
> display like the PDP-1 vector tube to test the architecture. Then,
> assuming we're not all too busy playing Spacewar to go any farther,
> someone could go and code up something hard like a VAX framebuffer.
>

Writing own server/server module (I assume you're talking about
something like VNC server for X) isn't a good idea... How I look at
it, it'd be more feasible to rewrite SCP  to emulate both text and
graphics display, much like VirtualBox, VMWare etc. We can borrow some
code from QEMU, for example, to make things easier.

Sergiusz
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Brian Knittel]

This seems like a good approach. Besides the PDP-1, the PDP-11 had the 
VT-11 and the IBM 1130 had the 2250. These are very similar devices -- 
asynchronous display-list vector display processors. Who knows -- maybe 
someone can rig up an Evans and Sutherland PS2 for the PDP-11/70. (I 
think Tom Ferrin's UNIX V6 drivers are available?).  

The approach would also work well for machines with pixel- and 
character-based graphics like the IBM 5100 and 5110. (I have a SIMH 
emulator working, but it's Windows-only at this point due to the 
graphics issue). Then there are the e.g. Cromemco-type boards for the 
Altair, and so on.   

It does sort of open a Pandora's Box though, as it invites the 
proliferation of GUI control panels and other fluff. (Says the author 
of a fluffy, hacked-up GUI control panel for SIMH IBM 1130). One thing 
I like about SIMH is that the experience is all about the software, 
rather than on reproducing the physical appearance of the hardware.  

The tricky part would be the asynchronous nature of these display 
beasts. Could it be done without using a separate thread? Maybe. Or 
could we work up an abstraction of a display thread that was cross-
platform and not too ugly? Maybe. It seems to me that this is where the 
difficulty and elegance will lie.  

Brian

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Michael Kerpan]

It's good to see that folks don't think I'm barking up the wrong tree
here. Anyways, while I can't code this myself (my C-fu is weak), I'd
be more than happy to troll the web to dig up documentation in order
to help anyone who might be interested in implementing this.
Persoanlly, I would think that the thing to do would be to first set
up the basic server architecture and then implement a fairly simple
display like the PDP-1 vector tube to test the architecture. Then,
assuming we're not all too busy playing Spacewar to go any farther,
someone could go and code up something hard like a VAX framebuffer.

Mike
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Sergiusz Jarczyk]

2010/7/7 Michael Richter :
> This idea is utterly insane (pretty much like the whole concept of SIMH
> itself).  I like it.
>

+1 :-D
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Sergiusz Jarczyk]

2010/7/7 Michael Kerpan :
> One thing that's always bugged me was the fact that SIMH has no real
> support for graphics. Some up the supported platforms (such as the
> PDP-1) are widely recognized as important because of there graphical
> display abilities. Others, such as the VAX were often sold with a
> framebuffer installed for use as workstations. The general problem
> with graphics, however, has always been that they make things less
> cross-platform. Having a lot of free time over the summer to think
> about such things, I recently hit upon an idea: why not implement
> graphics systems via the RFB/VNC protocol?  That way, any people could
> simply attach the "framebuffer" or "vector display" to a TCP/IP port
> and connect with any number of free clients. Do people think that
> something like this would be workable? It seems like a crazy idea, but
> then again, it also seems in keeping with other things that SIMH does,
> such as implement terminal multiplexers over TELNET...
>

Working with emulated VAX, with which many has replaced systems
running both OVMS old and new desktops, and considering the problems
with remote X servers, and, more annoying, problems with X-Window MIT
ACLs, I was wondered about this too... As I'm Linux user, I'd opted
for a clean Xt-based emulator, but for a sake of portability, RDB can
be considered too. The problem is, we'd need to access FB
software/firmware, which is not as trivial as graphics controllers for
Alpha systems...

Sergiusz
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Michael Richter]

This idea is utterly insane (pretty much like the whole concept of SIMH
itself).  I like it.

On 7 July 2010 23:37, Michael Kerpan  wrote:

> One thing that's always bugged me was the fact that SIMH has no real
> support for graphics. Some up the supported platforms (such as the
> PDP-1) are widely recognized as important because of there graphical
> display abilities. Others, such as the VAX were often sold with a
> framebuffer installed for use as workstations. The general problem
> with graphics, however, has always been that they make things less
> cross-platform. Having a lot of free time over the summer to think
> about such things, I recently hit upon an idea: why not implement
> graphics systems via the RFB/VNC protocol?  That way, any people could
> simply attach the "framebuffer" or "vector display" to a TCP/IP port
> and connect with any number of free clients. Do people think that
> something like this would be workable? It seems like a crazy idea, but
> then again, it also seems in keeping with other things that SIMH does,
> such as implement terminal multiplexers over TELNET...
>
> Mike
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>



-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Shoppa, Tim]

Most graphical applications on minicomputers were accessed not with
A framebuffer, but with a graphics-enabled terminal. (There
Are exceptions and you point these out.) Tek 4014 emulation
Goes a long way for most of my classic minicomputer graphical apps.

Tim.

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] An idea for graphics support in SIMH

[Toby Thain]

On 7-Jul-10, at 11:37 AM, Michael Kerpan wrote:

> One thing that's always bugged me was the fact that SIMH has no real
> support for graphics. Some up the supported platforms (such as the
> PDP-1) are widely recognized as important because of there graphical
> display abilities. Others, such as the VAX were often sold with a
> framebuffer installed for use as workstations. The general problem
> with graphics, however, has always been that they make things less
> cross-platform. Having a lot of free time over the summer to think
> about such things, I recently hit upon an idea: why not implement
> graphics systems via the RFB/VNC protocol?

This is how VirtualBox does it, and imho seems like a good approach.

--Toby

> That way, any people could
> simply attach the "framebuffer" or "vector display" to a TCP/IP port
> and connect with any number of free clients. Do people think that
> something like this would be workable? It seems like a crazy idea, but
> then again, it also seems in keeping with other things that SIMH does,
> such as implement terminal multiplexers over TELNET...
>
> Mike
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] An idea for graphics support in SIMH

[Michael Kerpan]

One thing that's always bugged me was the fact that SIMH has no real
support for graphics. Some up the supported platforms (such as the
PDP-1) are widely recognized as important because of there graphical
display abilities. Others, such as the VAX were often sold with a
framebuffer installed for use as workstations. The general problem
with graphics, however, has always been that they make things less
cross-platform. Having a lot of free time over the summer to think
about such things, I recently hit upon an idea: why not implement
graphics systems via the RFB/VNC protocol?  That way, any people could
simply attach the "framebuffer" or "vector display" to a TCP/IP port
and connect with any number of free clients. Do people think that
something like this would be workable? It seems like a crazy idea, but
then again, it also seems in keeping with other things that SIMH does,
such as implement terminal multiplexers over TELNET...

Mike
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh