On Wed, Aug 27, 2014 at 3:38 AM, Andriy Romanenko <bigral at hotmail.com> wrote: If you have a fast hard-drive you can run MINI-UNIX [1]: http://bitsavers.trailing-edge.com/bits/ATT/mini-unix_120679.zip We had this running circa 1980 with two (or maybe three) terminals and 10MB Pertec fixed+cartridge disk system, LSI-11/03 with 56KB memory. Before that we ran RT-11 [2] with foreground/background tasks and at various times MU-BASIC (multi-user BASIC) [3]. [1] http://www.60bits.net/msu/mycomp/terak/termubel.htm [2] http://en.wikipedia.org/wiki/RT-11#Multitasking [3] http://bitsavers.trailing-edge.com/www.computer.museum.uq.edu.au/RT-11/DEC-…

On Sep 3, 2014, at 11:36 AM, John Wilson <wilson at dbit.com> wrote: Not so impractical, actually. Forth was originally designed to do real time control, and if multitasking (multithreading) wasn?t there from the start, it certainly appeared soon after. And there is a Forth standard (Forth-83; there may be other revisions for all I know). For that matter, it was implemented in a number of different systems as the implementation language for the boot ROM. paul

On Sep 8, 2014, at 3:42 PM, Andriy Romanenko <bigral at hotmail.com> wrote: RSTS/11 runs on 16 bit (no MMU) PDP-11 Unibus machines. For example, it works on an 11/20. I suppose it could be ported to an 11/03 if you had the source code (and a DOS system on which to build it). But I don?t believe it would run as-is. There?s also the issue of terminal interfaces: RSTS/11 only supports DL interfaces (single line interfaces). And only old small disk drives (RC, RF, RK, RP02/03). And it?s Basic-Plus only, no other languages. (There was a variation that was created at the University of Illinois from an even earlier RSTS. It looks like it was meant to run some other languages, but I have no details at all, apart from a single assembly listing I found somewhere and saved. It does look like a fairly complete OS listing, so if someone wanted to scan a couple of hundred pages worth of line printer listing, it could perhaps be reverse engineered. It?s from around 1971, if I remember right. The banner page calls it ?BTSS?.) paul

On Sep 8, 2014, at 7:19 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote: I?d have to look to be sure, but if it has the KL/DL style 4 CSR interface with ready and IE, you?re probably just about there. The terminal driver is on the V4 binary kit (since it is assembled at installation time to customize for the actual hardware in use). Look for tt.mac. There?s a copy on Bitsavers: http://bitsavers.trailing-edge.com/bits/DEC/pdp11/dectape/rsts/v4a-12/ The same goes for the disk drivers, those are in dk.mac. I don?t remember the RKV11 but if its CSRs are basically like those of the RK11 it is likely to work. And since the sources for those critical drivers are available, even if tweaking is required that should be doable. SIMH would be a way to test it. paul

So, basically multitasking/timesharing on the machine without MMU would require some kind of soft-interpreter (forth, basic, etc.) to prevent processes from direct access to memory locations (hence prevent system crashes).

On Mon, Sep 22, 2014 at 01:34:42PM +0300, Andriy Romanenko wrote: Or else just don't claim it's crash-proof in the first place. RT-11FB works beautifully with cooperative multithreading, and preemptive multithreading can work just as nicely with no protection. Having the OS survive application crashes may seem like a noble goal, but in real life (especially doing some kind of control), how useful is a computer that's stopped doing the one thing you asked it to do? You may well end up rebooting anyway just to get a clean restart of all the application's bits and pieces. FORTH is *traditionally* threaded (and I think multithreading was usually done by executing some fixed number of words and then switching threads), but it need not be (mine isn't, and uses the KW11L clock to preempt). And as Paul said, either way, FORTH gives you enough power to kill yourself. John Wilson D Bit

On Sep 23, 2014, at 11:29 AM, David Riley <fraveydank at gmail.com> wrote: That sounds right. Thanks to some pointers from B.M. I got closer to a valid V4A build. I?ll poke a bit further. If the build is successful, the next step will be trying to boot it on a SIMH 11/03. paul

On 8/27/14 2:17 AM, Christian Corti wrote: Wow, that was an interesting experiment. I had 15 belts, fired up the tea kettle and poured the water into the bands in a coffee cup. As you say, the process throws off a sticky residue, wiped it off and let them dry at room temperature. I was able to save 5 of the 15. About half just snapped when I tried tensioning them (these are out of carts About to try one on a Tandberg drive We'll see how it does combined with baking and attempting to clean the back side of the tape by putting tyvec over the pin next to the head. If the tape sheds off the dull side, it sheds on the two bollards at the edges, which stalls the tape when it reverses. I've had better luck with the Tandberg than Wangtek or Archive drives because the motor is direct drive instead of using a belt, which just slips when the bollards get sticky.

On 08/27/2014 09:13 AM, Al Kossow wrote: Hmm, most of what I get as bad carts has the belt already in pieces inside the cart. Boiling won't fix that. --Chuck

On 8/27/14 12:10 PM, Al Kossow wrote: The Tyvek did the trick. It picked up the shed, squeeked a bit, but the tape didn't stick. The problem children were copies of Sun Common Lisp 1.1 and 2.1, (QIC-11 format) circa. 1987 I'm a happy camper. 1.1 Sun(TM) Common Lisp-E SUNBIN 1/4" Tape (tar format), 1 of 1 Part Number: 700-1630-10 Rev. A 2.1 SCLisp-D SUNBIN 68020 1/4" Tape (tar format), 1 of 1 Part Number: 700-1520-10 Rev. A