Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight panels
Why not go all the way and record video of each type of old hardware in action ? Obviously this makes no sense for blinkenlights, but it might be fun to watch tape drives spinning back and forth (a series of short sequences of video for each operation), or maybe someone opening up a disk pack and installing platters. Of course, this would require yet another interface from SIMH to the video playback system. It would remind me of those old movies where the computer rooms always had rows and rows of lights, and tapes running, together with the sounds of teletype printers spewing data out ... Now, if we could just "skin" our favorite terminal emulator with a VT-220 case around the window area, we'd be all set in our virtual retro-computing world ! Wait, did I mention using 3-D glasses ??? LOL !!! -Original Message- From: simh-boun...@trailing-edge.com [mailto:simh-boun...@trailing-edge.com] On Behalf Of dott.Piergiorgio d' Errico Sent: Thursday, 19 April 2012 12:24 PM To: simh@trailing-edge.com Subject: Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight panels Il 19/04/2012 15:21, Bucher, Andreas (Andreas)** CTR ** ha scritto: > Hi, > >> I just finished another "Blinkenlight" project: An extended SimH runs >> on a BeagleBone (credit card sized Linux platform) and controls real >> console panels of historical computers, or simulations of those >> panels. So the project is named "BlinkenBone". >> >> First implementation is re-animation of a PDP-11/40 console (KY11-D), >> others will follow. See documentation here: >> www.retrocmp.com/projects/blinkenbone >> >> I think there are a few? a lot? other "SimH-blinkenlight" projects >> out there. Perhaps it is time to define the definitive "SimH - >> Blinkenlight" interface, so there's a standard for future work. My >> proposal is >> http://www.retrocmp.com/projects/blinkenbone/169-blinkenbone-a > rchitecture-overview >> >> If you like to build this too, we will support you ... but it won't >> be cheap. And code deployment isn't organized yet, contact me on >> demand. > > > > Hi, > > that's waaay cool ! Not really useful for practical computing, but > absolutely mandatory for the genuine look-and-feel of some ancient > "big iron" :-) > > I like your modular approach - it allows people NOT owning true > hardware blinkenlights to replace them with some software simulated > frontend instead ! Would be cool to have SIMH equipped with all kind > of genuine virtual (or real, for the purists) designs of the systems > it emulates ! Have a look for PINMAME, the pinball emulator software, > and you know what I mean :-) (wll, yes, a pinball machine's main > item IS the hardware you see, and the CPU is only some aid in behind, > while our emulated data processing systems are vice-versa - but anyway > ...) > > And - finally ... that's what I already suggested years ago (and only > got startled looks): Equip SIMH with some standard interface to > optionally drive "real" hardware components of the systems it > emulates, like console panels and stuff. I even went as far as to > suggest incorporating all other kind of events from inside the system > beeing signalled out - this could be used to generate sound events as > well ! Perhaps the startled looks came from people whose main interest is keeping running legacy software, an important thing in se, but driving real (reconstructed) hardware is equally important, if not for the recovering & preservation of software & source codes on DECtapes, tapes, removable platters &c On the blinkenlighten project, I have indeed suggested (ands ends rejected...) that ex and de command accept (and outputs) binary digits and space, (e.g. de 000 100 111 ) whose IMVHO is not only a convenient means when dealing with old big iron software, but also a convenient protocol (being *both* human and machine readable/writable) for a "blinkenlighten" protocol. Seems that there's a consensus in starting working on graphics emulation after 3.9.0 release and the sort of "retirement" (If I have understand well...) of bob from the active development of SIMH. I reckon that my perspective (of Historian of technology and "random hacking when the mood is in") differ from the other member of this fair ML, but it's my perspective (for the record my lack of frequent contribuition is because of the extreme dispersiveness in dealing with project (I suspect that my WIP list is in high 10s or low 100s, but I have never done a census of it...) > Think about your DECbox emitting true 11/750 noises, perhaps with some > TE16 tape in the background, hehe :-) > > So, you better go ahead and digitize not only the Front Panels, but > also the sound of the remaining hardware that is alive, or sythesize > the sound of dead hardware and have it "proof-listened" by the few > people knowing the hardware that still are alive as well ... I'm deaf and not much interested in that "ambient sound emu
Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight panels
I want to suggest simulating the distinctive sound of an LA36 backspacing. But I think I'd turn it off 2 minutes later! ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight panels
I have a real yin to build something like this that uses USB or serial for comms and a software module that can be optionslly compiled into SimH to allow it to work on any system (perhaps via an extra device that can be configured in the SimH terminal) rather than spitting the console commands out. The key point is it should work on any machine with a USB port or better a Serial port (can be adaoted to USB) that can build SimH. Only issue is I have no programming experience outside PHP5, I'm awful at soldering and I'm no genius with making panes and stuff like that either. However my *dad* has offered to build the hardware for me if I can come up with a plan. I don't really know where to go from just the idea. Loads of people seem to have done it in various ways but they seem to be tailor made solutions. I'd like to make something generic and boxed so I can plug, configure in a suitably compiled SimH and go. Any guidance out there? -- Mark Benson http://markbenson.org/blog http://twitter.com/MDBenson ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight panels
Il 20/04/2012 14:39, Armistead, Jason ha scritto: Why not go all the way and record video of each type of old hardware in action ? Obviously this makes no sense for blinkenlights, but it might be fun to watch tape drives spinning back and forth (a series of short sequences of video for each operation), or maybe someone opening up a disk pack and installing platters. Of course, this would require yet another interface from SIMH to the video playback system. I guess that you will surely enjoy this YT link: http://www.youtube.com/watch?v=7WaYYNUCWMY But on your idea, honestly, seems to me that FMV video sequences are a tad overboard; we're discussing simulator design, not console RPGs design ! ;) Now, if we could just "skin" our favorite terminal emulator with a VT-220 case around the window area, we'd be all set in our virtual retro-computing world ! I use Linux and of course the gnome-terminal is rigorously green-on-black ;) and there's at least one proper font (that is, with slashed zero and five-star * char...) albeit I *really* dislike its name (Addolorata, whose in Italian means "doleful/sad (woman)" and I'm Italian) In this context, I guess you need a good window dressing, and I'm sure that there's more than enough tools in X environment for building yourself the window decoration(s) you link ;) Best regards from Italy, dott. Piergiorgio. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight panels
Very off topic, but there is a old HP computer simulator called HP9800E which fully simulates in software the look, feel and sound of the HP98XX range of programmable calculators/computers. If you run it up it makes the fan noises and the printer noises and everything whilst flashing all thr right lights. If you use some of the peripherals, like the plotter or tape drive, it even makes plotter and tape drive noises. Very comprehensive. http://hp9800e.sourceforge.net/ Also, I have simh running on a SheevaPlug plug computer under Debian linux which provides a UART and USB for serial connections (it has no PC type console). I use a serail terminal emulator as the console, but If I had a Decwriter or a teleetype it would work. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Extended SimH on BeagleBone controls real blinkenlight panels
> Also, I have simh running on a SheevaPlug plug computer under Debian linux > which provides a UART and USB for serial connections (it has no PC type > console). I use a serail terminal emulator as the console, but If I had a > Decwriter or a teleetype it would work. If I remember correctly, the SimH serial-port emulation relies on telnet. Awhile back I tried to attach a real VT420 to a SimH/VAX instance running OpenVMS 7.3, and as I found out it's not really the same as running a VT420 attached to a real VAX. To gain access to SimH using the VT420, one first has to get the VT420 connected to the host computer (running Linux in my case, so I used the computer's serial port and a serial console - getty). From there, one must telnet into the VAX, either using OpenVMS TCP/IP Services or using SimH's serial-port emulation. No matter which way I tried it, the Linux telnet code caused various glitches and annoyances. Eventually I did get it to work satisfactorily, but only at 9600 baud. All the gory details (which I no longer recall) are archived for posterity on comp.os.vms. In the end I found that the best results came when I used LAT instead of telnet. Linux supports the LAT protocol via LATCP, and of course OpenVMS supports it natively. Bottom line: avoid telnet. While we're in "wish list" mode, I'd like to see SimH emulate Alpha or Itanium, so I could use it to run newer versions of OpenVMS than 7.3. There are free versions of commercial Alpha emulators available, but they only run on Windows (BLEAH) and their performance is intentionally limited, presumably to get people to buy the full version. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Alpha simulator performance
> While we're in "wish list" mode, I'd like to see SimH emulate Alpha or > Itanium, > >so I could use it to run newer versions of OpenVMS than 7.3. There are free >versions of commercial Alpha emulators available, but they only run on Windows >(BLEAH) and their performance is intentionally limited, presumably to get >people > >to buy the full version. If you are concerned about performance, it is unlikely that SIMH implementation of Alpha (which apparently is in works, but hard to guess when it might become available) will "ever" match the performance of free versions of commercial emulators. The latter do JIT binary compilation, whereas SIMH performs interpretation of instruction stream and is unlikely to have JIT for the foreseeable future if ever at all. FreeAXP performance may be throttled down compared to full Avanti, but it is still very fast -- much, much faster than SIMH VAX alongside it. Also note that FreeAXP is about 3x faster when running on 64-bit version of Windows compared to being executed on 32-bit Windows (just as can be expected for the emulation of 64-bit processor). To give a rough idea, here were the results CHARON/SRI benchmark executed on FreeAXP running on i7 2600, 3.40 GHz on 64-bit Windows: Test started [...] for a AlphaServer 400 4/166 CPU with VMS V8.3 Sequential test results: Whetstones Dhrystones VUPs Run 0 81.7203735 144.5 Run 1 80.3200222 144.5 Run 2 79.0203735 144.0 Run 3 80.3200222 145.0 - Average80.3 201978 144.5 Interleaved test results: Whetstones Dhrystones VUPs Run 0 81.7200222 145.0 Run 1 80.3203735 145.0 Run 2 80.3203735 144.5 Run 3 81.7200222 144.5 - Average81.0 201978 144.8 By the way of comparison, same test executed in native Windows x64 mode on the same machine (with SSE code generation disabled during compilation) produced only 150 000 Dhrystones ;-), albeit was 150 times faster than virtual Alpha on Whetstones. As a side note, I personally was never quite able to understand the reasoning of people who extoll VMS and simultaneously "bleah" about "Windoze", which after all at its foundations is to a significant extent a clean and neat reimplementation of VMS/Mica architecture at a new technological volution. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Alpha simulator performance
NT is not VMS or a reimplementation of it.i wouldnt even say there's vms code in there.there can't be, VMS was never that bad. NT crashed all over the place, it was unstable, it was horrifically bloatedand all sorts of other nasty things.on top of that it's really only a single-user system. you could have hundreds of users simultaneously on a vax750 and it wouldnt seem slow.a pair of clustered vax780s never seemed to break a sweat. maybe it's just perspective, maybe it's the client/server design,maybe it's what we did with it. vms was elegant. thats something NT never had. > Date: Fri, 20 Apr 2012 15:47:29 -0700 > From: obog...@yahoo.com > To: simh@trailing-edge.com > Subject: Re: [Simh] Alpha simulator performance > > > While we're in "wish list" mode, I'd like to see SimH emulate Alpha or > > Itanium, > > > >so I could use it to run newer versions of OpenVMS than 7.3. There are free > >versions of commercial Alpha emulators available, but they only run on > >Windows > >(BLEAH) and their performance is intentionally limited, presumably to get > >people > > > >to buy the full version. > > If you are concerned about performance, it is unlikely that SIMH > implementation > of Alpha (which apparently is in works, but hard to guess when it might > become > available) will "ever" match the performance of free versions of commercial > emulators. The latter do JIT binary compilation, whereas SIMH performs > interpretation of instruction stream and is unlikely to have JIT for the > foreseeable > > future if ever at all. > > FreeAXP performance may be throttled down compared to full Avanti, but it is > still very fast -- much, much faster than SIMH VAX alongside it. > > Also note that FreeAXP is about 3x faster when running on 64-bit version of > Windows compared to being executed on 32-bit Windows (just as can be expected > for the emulation of 64-bit processor). > > To give a rough idea, here were the results CHARON/SRI benchmark executed on > FreeAXP running on i7 2600, 3.40 GHz on 64-bit Windows: > > Test started [...] for a AlphaServer 400 4/166 CPU with VMS V8.3 > > Sequential test results: > > Whetstones Dhrystones VUPs > Run 0 81.7203735 144.5 > Run 1 80.3200222 144.5 > Run 2 79.0203735 144.0 > Run 3 80.3200222 145.0 > - > Average80.3 201978 144.5 > > Interleaved test results: > > Whetstones Dhrystones VUPs > Run 0 81.7200222 145.0 > Run 1 80.3203735 145.0 > Run 2 80.3203735 144.5 > Run 3 81.7200222 144.5 > - > Average81.0 201978 144.8 > > By the way of comparison, same test executed in native Windows x64 mode on > the > same machine (with SSE code generation disabled during compilation) produced > only 150 000 Dhrystones ;-), albeit was 150 times faster than virtual Alpha > on > Whetstones. > > As a side note, I personally was never quite able to understand the reasoning > of > > people who extoll VMS and simultaneously "bleah" about "Windoze", which after > all at its foundations is to a significant extent a clean and neat > reimplementation of > > VMS/Mica architecture at a new technological volution. > ___ > 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] Alpha simulator performance
> NT is not VMS or a reimplementation of it. Let's look at some basics in internals. I'd rather just quote someone here, to save time typing: === quote begin === The scheduler. (process scheduler in VMS, thread scheduler in NT) 32 scheduling priorities, divided into the "real-time" (16-31) and "variable" (0-15) priority ranges. identical preemption at ready by higher-priority threads; identical quantum and priority boost implementations; identical CPU starvation avoidance mechanism to get out of priority inversion situations; a null thread for each CPU; etc., etc. Memory management. 0-7FFF is per-process, mostly user-mode-accessible only; 8000- is systemwide, mostly kernel-accessible only. Functionally identical implementations of paging vs. swapping. I/O. I could write a book, but briefly, IRPs are IRPs, UCBs are "device objects", CRBs are "controller objects", ADPs are "adapter objects", FDT routines are "dispatch routines", EXE$QIODRVPKT is IoStartPacket, StartIO routines are StartIO routines, fork routines are DPC routines, ASTs are APCs... etc., etc., etc., etc., etc. Interrupt handling. 32 levels of interrupts (some simulated but this is nevertheless the way the code is written). IPLs on VMS, IRQLs on NT. In order: Passive level, APC (AST) Level, Dispatch (fork) level, then the IO hardware interrupts, then some "hardware maintenance" functions like the hardware timer, IPI, power fail notification, and HIGH_LEVEL to block all interrupts. === quote end === Could go on, but probably enough to give an initial idea. Native API and subsystems came from Mica, I might just add. In effect you could say Mica turned out to be a dry run for Windows architectural design. As for crashes, after installing XP SP3, my old computer at work stayed up (unrebooted) for about 2 years and was restarted only because IT pushed hotfixes that required restart. I also do not remember having any crashes in XP or later era on my home computer that were not related to 3rd party drivers (and those were largely gone by XP time too). Earlier versions of NT may have been less stable, but they had to deal with diversity of supported hardware and magnitude of functionality far exceeding those early versions of VMS had to. As for single-user system, it is an era of client/server computing and personal computing. The era of timeshared computers is long gone. Nevertheless Windows does provide multiple logon sessions with remote desktops. > vms was elegant. thats something NT never had. Cannot agree. At user level, Windows is certainly more usable than VMS. At API level, likewise there is no even comparison in terms of elegance. This is not to say VMS APIs were bad at their time -- but they are APIs of their era.___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Alpha simulator performance
On Fri, Apr 20, 2012 at 09:01:11PM -0400, Dan Gahlinger wrote: > > NT is not VMS or a reimplementation of it. Well, it isn't straight VMS - but definitely based on VMS. I remember being in university and working my way through a VMS internals book (out of interest) and a short while later going through a lecture about modern OS internals which was based on Windows NT (IIRC 3.51 or so). Woah, that certainly was full of déjà vu moments "wait, this is just like in VMS, but with some of the serial numbers filed off". Given that Cutler was the core architect on both, that isn't exactly surprising. Even though some of the later silly ideas (putting the entire GUI subsystem into kernel mode to speed up graphics) were not his fault. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Alpha simulator performance
I would say Unix (and its derivatives) and VMS are Operating Systems. Windows is an Application. Takes VMware to run it. Eric On Apr 20, 2012, at 9:00 PM, Alexander Schreiber wrote: > On Fri, Apr 20, 2012 at 09:01:11PM -0400, Dan Gahlinger wrote: >> >> NT is not VMS or a reimplementation of it. > > Well, it isn't straight VMS - but definitely based on VMS. I remember > being in university and working my way through a VMS internals book (out > of interest) and a short while later going through a lecture about modern > OS internals which was based on Windows NT (IIRC 3.51 or so). Woah, that > certainly was full of déjà vu moments "wait, this is just like in VMS, > but with some of the serial numbers filed off". > > Given that Cutler was the core architect on both, that isn't exactly > surprising. Even though some of the later silly ideas (putting the entire > GUI subsystem into kernel mode to speed up graphics) were not his fault. > > Kind regards, >Alex. > -- > "Opportunity is missed by most people because it is dressed in overalls and > looks like work." -- Thomas A. Edison > ___ > 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] Alpha simulator performance
> I would say Unix (and its derivatives) and VMS are Operating Systems. > Windows is an Application. Takes VMware to run it. Takes SIMH to run VMS. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Alpha simulator performance
> On Fri, Apr 20, 2012 at 09:01:11PM -0400, Dan Gahlinger wrote: > Given that Cutler was the core architect on both, that isn't exactly >surprising. > As a minor historical correction: whatever Cutler's merits are, he was not "the" core architect of VMS, as common legend has it. As evidenced by the headers in VMS sources, he was just one of the key architects and developers for the kernel, let alone the whole system. Even at early VAX architecture design state there were three key people on the software side (Hustvedt, Lippman and Cutler) and when it came down to the actual VMS design and implementation it naturally became even more diluted, with different people covering different major areas. > Even though some of the later silly ideas (putting the entire GUI subsystem >into kernel mode to speed up graphics) were not his fault. Silly -- from whose prospective? Apparently not from the prospective of paying customers. If GDI server goes down and everything else survives, from average customer's prospective the system is as good as dead (all GUI applications are killed and user session is destroyed, and that's what matters on a PC), and the next step is restart. So what would be the point of sacrificing performance (at the time when it still mattered) for virtually nothing? As Torvalds once colorfully commented on a distinct but somewhat related issue: "message passing as the fundamental operation of the OS is just an exercise in computer science masturbation. It may feel good, but you don't actually get anything DONE. Nobody has ever shown that it made sense in the real world". I might also mention that I had a coworker who previously spent 6 years at OSF working on virtual memory subsystem and similar stuff, and when I inquired him about his experiences, his very second comment was literally: "god, was it slow!". ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
