On 21 February 2016 at 16:27, Liam Proven <lproven at gmail.com> wrote: It's a 4000/60, I'm afraid it's untested, and Farnborough is just outside London England. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

VAXstation 4000's such as the 60 and 90 are nice compact last generation desktop VAX with modest power requirements, small form factor, good compatibility and relatively good performance. The 60 runs at around 12 VUPS and the 90 at 40 VUPs IIRC. However, I would have thought that a modern Core i7 system running SIMH would be getting close to a VAXstation 4000/60, and there is always VAX MP if you want to go down the multiprocessor route (you can run a 7 core VAX system on a Core i7 for example). For compilation it should be relatively easy to create a build script that makes use of multiple processors (does the DEC CMS build tool cater for this?) Kind regards, Mark. On 21/02/16 15:36, Ben Sinclair wrote:

That sounds like a good idea to use SimH for the VAXstation. However, I suspect that E11 (Ersatz-11) would be a bit difficult to use to emulate a VAXstation since E11 is exclusively for the PDP-11. As for the individual who mentioned the speed of an emulator, I have used both SimH and Ersatz-11 on a 750 MHz Pentium III. SimH probably runs at about the speed of a PDP-11/93, probably even faster. However, Ersatz-11 runs 15 times as fast for CPU speed and about 100 times as fast for hard disk I/O. On a 2.83 GHz Q9550, Ersatz-11 ran about 100 times the speed of a PDP-11/93 for the CPU and hard disk I/O was probably about 200 times as fast. As just one example, on a real DEC PDP-11/93 with ESDI hard drives, it took about 4 minutes to copy about 32 MB from one physical hard drive to a different physical hard drive. On the Q9550, it took less than 1 second. I was using RT-11 in all cases. I would assume that an I7 CPU would be somewhat faster, but maybe someone else has some benchmarks. Jerome Fine

But I suspect that there might be a few individuals who are also interested in emulating the PDP-11, so those "great numbers" might be helpful to them. The other point to emphasize is that SimH does a great job of emulation, but is not the fastest application. If someone was interested in producing code which executes in the manner in which Ersatz-11 does it for the PDP-11, but doing so for a VAX emulation, the results might be spectacular. Jerome Fine

I have a VAXStation 3100 which is similar. I am told they are slow but usable. Thanks, Bryan

On 02/21/2016 07:21 PM, Jay West wrote: Well, VAXes are fairly slow compared to a recent x86 machine. My MicroVAX-II is about 1000 times slower than my desktop machine. I migrated a few programs from the VAX to my desktop Linux machine, so I have some rough comparisons. But, your 3100 might be slower than a 100 MHz Pentium Classic, just to give you a range. You would not want to go web browsing on a MicroVAX, even though the 3100 is quite a bit faster than my MicroVAX-II. Moving files around on the net, email and such things might not be so obviously slow. I wouldn't want to do any real computing on and VAX system, I'm just spoiled by what a typical machine can do now. Jon

Only if your idea of "games" is "slick-looking realtime 3D-rendering games". There are lots of games that work perfectly well on 3100-class (and even slower) machines, such as roguelikes (rogue, larn, hack, etc), text adventures (ADVENT, DUNGEON, etc), phantasia, Seahaven, Klondike...the list is long. It's not? Someone once built a Turing machine in Minecraft.... Depressingly close to accurate in far too many cases. :-/ /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Sun, 21 Feb 2016, Richard Loken wrote: That's not surprising to me at all, because to handle monochrome (1-bit) or greyscale (multi-bit) graphics hardware you actually have to explicitly code support respectively for a monochrome or greyscale visual in your graphics software. And such hardware is virtually inexistent in the x86 world which is I suppose what browser developers predominantly if not exclusively use. I've only ever heard of and saw a single kind of monochrome graphics hardware for x86 PCs and that was the Hercules Graphics Card (HGC) and its clones, and these were already gone by early to mid 1990s. They were ISA cards compatible with IBM's MDA (and likewise with a parallel port included), with a hi-res monochrome (1-bit) graphics mode added. They had a low-res 2-bit greyscale mode as well I'm told, but nobody used that I believe. All the other x86 graphics hardware has been colour, even if used with a monochrome monitor. Of course sane software would at least quit gracefully rather than crash, but given the above I suspect browser developers may not even be aware of the existence of monochrome and greyscale graphics hardware and hence didn't think anything was supposed to be done about that. I suspect even what X11 calls pseudocolor (a small palette of colours out of a choice of many, mapped through a RAMDAC, e.g. 8-bit pixels mapped onto 24-bit colours, such as with the Bt459 RAMDAC chip commonly used by DEC) may not be supported these days. Maciej

On Mon, 22 Feb 2016, Mouse wrote: Huh? Good to know actually as I meant to upgrade X11 sometime across my DECstations to something which is not outrageously obsolete and as you probably realise that means quite an exotic set of graphics adapters. Of these only Bt463-based SFB+ options fall in the as you say "supported" DirectColor category, and these are difficult to work with on some DECstations due to (regrettably unnecessary) firmware limitations, and impossible even on the original 5000/200 due to its addressing constraints. Oh well... Thanks for the warning! Maciej

On Mon, 22 Feb 2016, Mouse wrote: Eventually I will and it's always good to know what to expect (hmm, from experience somehow the worst always happens anyway, but knowing the potential area of breakage does help). X.org has gone modular at some point and that does help -- compared to monolithic X servers as they used to be -- with computers which are not the richest in resources, especially RAM (demand paging combined with overcommitment helps a bit, but still why have that stuff there in the first place?). So upgrading makes sense from my point of view. Honestly I'd expect dumb frame buffer support to just work, as there isn't much there to break or maintain. A pixel array and a RAMDAC handled entirely by the kernel via generic calls isn't rocket science after all. So if they broke some generic parts (DIX) by the lack of due attention, then I'm really concerned. Maciej

On Thu, 25 Feb 2016, Mouse wrote: Agreed in principle, however IIUC X.org only loads what is explicitly called for in xorg.conf rather than everything in sight. So this should be relatively sound. Also traditional SVR4 MIPS ELF binaries do not benefit from static linking performance-wise. The MIPS psABI has been defined such, that code produced for executables is PIC and no different from code for shared libraries. All function calls and static data references are indirect, even these which end up local to the executable. There has been non-PIC ELF support defined and implemented for the MIPS target a few years ago, making executables use PLT and copy relocations for function calls and static data references respectively in 32-bit binaries. I don't think I'm going to switch though, for one to make sure old SVR4 support doesn't bit rot in the tools; besides, 64-bit (n64) binaries continue using the original SVR4 ABI. Running as root is unfortunate, however I think the framebuffer server used with DEC hardware doesn't require it; not at least it should. It uses /dev/fb* devices to access the hardware, so it's up to these devices' permissions to set the access policy. It doesn't have to be the root user to access the device. If I find there's something wrong with this, then I'll see if it can be fixed up on either the kernel or the X server side; naturally for patches to go anywhere running the most recent development version is a must. FWIW what I believe is the cause of X servers requiring `root' access are the inadequate software interfaces (or the lack of them really) for x86 hardware -- where poking at the port I/O space directly from the userland or using system calls such as mmap(2) on /dev/mem (which naturally cannot be made accesible to non-root users or everyone could peek at other processes' memory) is consequently required to get at graphics hardware. Or, worse yet, calling into graphics adapter firmware -- which has been the trend over the years, used as an excuse for not documenting hardware. Now that is a security disaster, isn't it? Well, I've been sort of stuck with XFree86 3.3.6/X11R6.3 with dozens of local patches applied for years with my DEC hardware. And it has crashed recently anyway when I tried it with the PMAG-A aka MX mono framebuffer. So I need to move on, though maybe for the time being I'll just take the path of least resistance and make yet another patch to make it work here. I think these days Linux is booted more often in the frame buffer rather than the text console mode, so I'd expect people at least sometimes to run a dumb frame-buffer X server, in particular with graphics hardware for which native support hasn't been implemented yet. Since the turn of the century it has been always been the case for me that new graphics hardware found in x86 systems was not supported with X natively. There weren't that many pieces actually I dealt with, maybe three -- as I avoid hardware upgrades like a plague -- but still I think this tells something (and is actually one of the reasons why I avoid). Hmm, the only feature of CRTs I'm missing is the greater flexibility in resolution selection. And then even that only a little bit, as it was only monochrome monitors that could truly adapt in an analogue way and display any resolution requested with no loss of quality. Colour ones had the screen mask which made some resolutions look better than other ones, which was no different to LCD's pixel approximation -- about the only issue I have with flat panels. And then there was the moir? effect, colour alignment problems, various geometry defects, all of which could in theory be corrected with higher-end devices, but the process was painful, time consuming and had to be repeated for every resolution selected separately, sometimes hitting the limit of stored individual resolution settings supported by a device. To say nothing about their weight, space and energy consumption and heat produced. And phosphor burnout. And vertical refresh rates causing flicker. And hard X-rays at the back. No, on the second thoughts I'm not missing them at all. I've been running my favourite 80x37 text mode (720x592 pixels) on 4:3 flat panels happily for years now and I had no issues with graphics modes either. As long as analogue signalling was used, that is (DVI-D is another story) -- well, with an unfortunate exception of one panel, whose text-mode pixel approximation was plain horrible, but I take it it was that model which was broken, not the technology -- the same text mode rendered by a graphics card to the 1600x1200 resolution (native to said display) and sent digitally to the same monitor produced excellent output. I've been more disappointed with the demise of IPS panels -- they were (and still are) so much more decent compared to everything else I dealt with. And the disappearence of 4:3 screens -- the wide thingies are only really good for watching movies and not doing work. So what was there routinely in CRTs that you're missing in LCDs? OK, so there might be replacement software algorithms missing from DDX for what is done by some hardware. Oh well, if things are broken beyond the ability to fix within reasonable time and with reasonable effort, then, well, as you say -- there's always old code available out there. I have two ISA graphics cards still used, one each in a pair of x86 systems too BTW. I even upgraded one of them a few years ago, by plugging more DRAM into DIP sockets, to let it use memory interleaving and run at a higher refresh rate. ;) Well, if it indeed does in the first place. ;) Thanks for your insights! Maciej

When I switched to a flat screen (after the CRT monitor died), the adjustment time was also the biggest disappointment. As you mention, it usually takes 1, often even 2, seconds to recover after the blanking interval. What I can't understand is what causes the blanking interval. It can't be the software which is controlling the display. I describe below what happens. I almost always run in FULL SCREEN mode with either 80 column lines or 132 columns lines. When I shift from one job to the next, it does seem like the software produces a blanking interval as the old screen is discarded and the selected screen is displayed. BUT, NOT ALWAYS!!!! It actually seems almost random. Before I switched to a flatscreen, I was always able to visually inspect the screen output of the two jobs and actually determine where there was a change from the screen output between the two jobs. It often took up to a dozen times before I was able to pinpoint the few specific characters which had changed, but the adjustment time was so short that my eyes were easily able to retain the old image and watch for any changes. What is very frustrating is that about 10% of the time, the adjustment time is very close to just a few milliseconds and it is still possible to note the few (if any) differences between the screen output for the two jobs. But because it happens so rarely, I no longer find it to be useful to visually compare the two screen outputs. What I can't figure out is why the adjustment time is so long most of the time - often up to 1 or even 2 seconds. But on rare occasions (10% of the time or less), the new screen output for the new job displays with an adjustment time in the range of a few milliseconds. Of course, that is when both screens are using the same number of columns. If the number of columns differ, then the adjustment time is always 1 or 2 seconds, as is the adjustment time within any given job when I switch the number of columns. This is especially noticeable in KED since the HELP screens always use an 80 column display. I almost always use a 132 column display for the regular screen output since MACRO-11 listings require that output for efficient viewing. Whenever I request HELP screen output, I must always wait that extra 1 or 2 seconds before the display output appears after the adjustment time. Since it is not a major part of any editing session, it is reasonable to accept the delay. But it is disappointing. Note that these delays only occur when I use displays with FULL SCREEN mode. If I am using regular screens under Windows, as I do when I send and receive e-mail, then there is never any adjustment delay. But the adjustment delays also occur when I switch between FULL SCREEN mode and how Windows usually displays screen output - and back again, of course. It is rare that I need to switch from Ersatz-11 to other activity under Windows, but there are a few occasions when that is required. One of the VERY difficult problems which I have never been able to find a solution for is if I make a mistake and attempt to switch 132 column output TO standard Windows output displays. In that case under Windows 98SE, the operating system freezes and the ONLY solution is to turn off the power bar since even the power-off button no longer works. This also happens by accident about one a month when I accidentally hit the WINDOWS key (between the CTRL and ALT keys) while I am using a screen with 132 columns. Over the years, I have become mush more careful and rarely touch the WINDOWS key by accident any more. And even if I could disable the WINDOWS key, on the few occasions I need to use it, that would be even more of an inconvenience. So disabling the WINDOWS key is not an option. Jerome Fine

Jay West wrote: Jerome already published that numbers in the past, I remeber his 750Mhz CPU emulating the PDP11.. Nevertheless, it has nothing todo with the question about a VAX for doing databse development. Besides of this, the 750Mhz CPU ist not that fast, you can almost emulate in on an actual PC :-) You can always play around with it, I've suggesting an older VMS for it since those machines tend to be small and slow for VMS7.3. You can check NetBSD too but I had some ugly problems with VS3100s in the past (M38, M76). I do have a VS4000/90 to, that's a faster one and I've enjoyed DEC Windows with it. Have an VAX4000/300 repaired too.. It's definitivly more fun to playa with real hardware, but for Software development or testing I would suggest simh today. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Peter wrote... ------------------ It is supposed to be 5 VUPS so it should be about 5 times as fast as an 11/780. I guess whether this is fast enough depends on what you are going to be doing. ------------------ I was looking just for something to get me exposed to VMS :) And... ---------- If you haven't already removed the battery, I'd suggest doing that as soon as possible. ---------- Wasn't aware it had that potential issue, I've never opened it up. "Note to self" made, will check tonight. Thanks!! J

On 2016-02-21 16:36, Ben Sinclair wrote: Some people noticed, that there is still software and applications running on them, and few years ago, people just started to buy top of the line (/90+) to have spares. I think, it cooled down, but the prices are still up.

s?n 2016-02-21 klockan 09:36 -0600 skrev Ben Sinclair: It exists a number of applications there the customer has old VAX-programs. An 4000 is the smallest,cheapest and fastest way to in an method which is proven and tested run binary-code only VAX-programs. The problem could then be : expansion cards ? Any particular ones which needs to be supported.

On 21 February 2016 at 17:37, tony duell <ard at p850ug1.demon.co.uk> wrote: I confess I didn't know that there was more than one Farnborough. However, I did specify that the VAXstation was in Red Hat's UK HQ. There's only one Red Hat and it only has one UK HQ. It is in the business estate adjacent to Farnborough Airport in Hants. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

Bryan C. Everly wrote: ...you would'nt have much fun. Even an 3100/M76 ist dog slow.. Build a "world" on such a machine takes alsmost a week, not hours. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

David Brownlee wrote: Yes, it depends.. I at least have a card cage with an uVAXII (KA630, UC07 etc ) and had run Quasijarus a while before. Yes it's fun to play with old machines, but I don't think that it is funny to build and test Software like PostgreSQL on them. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

On 2016-02-22 9:31 AM, Mouse wrote: Absolutely! This is a neglected concept. It applies equally to front end development, which is awash with bloat and resource wastage (hi Chrome!) So has Minix 3 - last I checked, x86 & ARM only - what's the point of that. --Toby

On 22 February 2016 at 15:39, Toby Thain <toby at telegraphics.com.au> wrote: Oh, come on. Be fair. First, it's a student project without a huge amount of visibility in the outside world. Secondly, those are *the* two main computing platforms in the world today, amounting to sales of *billions* of processors every year. I suspect that every other general-purpose processor arch put together amounts to a rounding error compared to ARM+x86. It's not NetBSD. They're comparing it to NetBSD for what you could call marketing purposes, but it's not a fork or derivative or anything else. It's a whole new kernel to which they are porting the NetBSD userland, as it's a good, clean, solid, FOSS offering. If you want a simple low-end very portable Unix, there is still NetBSD itself. Minix 3 is not just another FOSS Unix. It is trying to become something very very different, something that has never been successfully done in the FOSS world: a true microkernel Unix-like OS. Not like the Xnu kernel of MacOS X: that is based on Mach 3.0, but it is a large monolithic kernel containing a single huge in-kernel "Unix server" derived from FreeBSD. Unlike the GNU HURD, Minix 3 is relatively complete and functional -- and it's got there in under a decade. It's not a new version of Minix 1 or 2 -- it's a totally new kernel. The *only* OS in the world remotely comparable to Minix 3 is QNX, which is not FOSS. Minix 3 is built from a number of cooperating user-space processes -- servers -- which can die and be respawned while the OS is running. Yes, including the filesystem, network stack etc. They even have tech demos of this allowing for in-place complete version upgrades of the running OS, *without reboots.* Minix 3 is the single most technically impressive new Unix-like OS that I have seen or heard of in the entire FOSS world in this century. It deserves more respect than "what's the point of that". -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

As a case in point, look at apple switching from 68k to PowerPC for their desktop systems, then again from PowerPC to x86. With overlapping emulation in both cases, even. Both of those transitions were critical for their survival and growth. -- Mark J. Blair, NF6X <nf6x at nf6x.net> http://www.nf6x.net/

Iirc ditching Power in favor of x86 had a lot less to do with the computing power but more to do with: A. The mobile versions of Intel processors being available in both more powerful and also lower power for laptops, and B. Being able to leverage off of the x86 desktop/laptop chipset available to drive down costs. Clearly Power is doing quite well in embedded and portable solutions today.

On 22 February 2016 at 17:36, Mazzini Alessandro <mazzinia at tin.it> wrote: The problem is that the mainstream PC market is increasingly going to portables. Laptops outsell desktops 2 times over now. POWER chips are still going strong but they're big and run hot taking lots of power. Apple needed a CPU line that could offer good notebook chips as well as desktop chips, and POWER (and PowerPC) was only addressing desktop devices. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

On 23 February 2016 at 23:41, Maciej W. Rozycki <macro at linux-mips.org> wrote: AFAIK, not remotely competitive with the Core 2 Duo line, which is what Apple had in mind when it switched the Mac line's CPUs the second time. And whereas PowerPC Macs could run Classic MacOS in a VM, Macintels can run Windows in a VM, which is far, far more useful. I personally didn't like the move, but it was a smart one for the company. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

On 2016-02-22 11:17 AM, Liam Proven wrote: There were more than a few experimental operating systems on SPARC. Where are they now? :-) *Today's* "modern computer market." Are they doing _that_ or are they going after QNX? Or both? #confused --Toby

On 2016-02-23 9:45 AM, Liam Proven wrote: So where does QNX come in? Isn't that embedded rather than desktop/laptop/tablet? --Toby

Is. Was, perhaps, even, in the non-OS space. But in the OS space, I think every open-source OS was originally done on some very small number of architectures. Unix was done on the PDP-11 (something else before that, I think, but I forget what, and I think it was with the move to the -11 that it became portable enough to be ported instead of rewritten). BSD was done on the VAX and Tahoe. The Jolitzs' work, Linus's work, i386. All of them moved beyond those initial machines, yes, and that was essential to their success. But they had to start somewhere. Seeing Minix 3 on x86 and ARM is good. Unless it wants to wither when the world moves beyond x86 and ARM, it will need to be done with enough portability in mind to make porting it easy, yes, but it is hardly a failing that it isn't ported yet. (Unless it's been around a lot longer than this thread makes it sound.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Mon, Feb 22, 2016 at 10:19 AM, Toby Thain <toby at telegraphics.com.au> wrote: The C compiler used by Minix 3 is Clang and at the moment Clang only supports x86 and ARM. Clang was used for licensing reasons rather than GCC. Other than the compiler issues the code to support a particular processor is pretty small. Switch compilers to one that supports your processor, write the few modules needed to support the particular features (memory management, I/O protection features) and you are done. Of course if your particular architecture doesn't have some necessary feature it would leave a security hole that cannot be worked around other than trust. When the world moves on from x86 and ARM I am sure Clang will get a backend for it and if still around Minix 3 will get ported. -- Doug Ingraham PDP-8 SN 1175

On Mon, Feb 22, 2016, ben wrote: Hey, we all know a raccoon makes a great mascot. Better than a penguin, daemon, or puffer fish :) -- Eric Christopherson

On Tue, Feb 23, 2016 at 10:57 AM, ben <bfranchuk at jetnet.ab.ca> wrote: And let us not forget the wombat, beloved of the VMS RDBMS. "PLOT WOMBAT" -- Charles