[Simh] Data General - MV

[Dell Setzer]

The earlier DG systems (RDOS, 16-bit AOS, and some others) also had 
realtime, preemptive, priority-driven multi-tasking, going back to the 
'70s. I cut my teeth on those systems early in my programming career, and 
never quite understood why everyone made such a big deal about "threads" 
and concurrency when NT came out. We'd been doing that stuff for decades 
in the DG world!

However, DG "tasks" were a bit primitive - there was only one intertask 
synchronization mechanism: you could send a (16-bit) "message" to a 
"mailbox", and receiver tasks could block themselves on a mailbox to await 
a message. But, that's all you really need.

With 16-bit AOS (which supported multiple processes as well as multiple 
tasks within a process), you had to use "IPC" (Interprocess Communication) 
messages to talk across process boundries. The 16-bit AOS kernel didn't 
really know about tasks - it just scheduled processes, while the task 
scheduler actually ran as part of its enclosing process.

32-bit AOS/VS (and the later AOS/VS II) introduced fast(-ish) kernel 
inner-ring calls which allowed you to "signal" a particular task in a 
particular process, or wait for a signal, so you could avoid the rather 
slow and clunky IPC mechanism to synchronize across processes.

I will leave emulation of the MV hardware, and/or re-writing AOS/VS to 
others. What I would dearly love would be to find a 16-bit AOS systape 
image somewhere and try to bring it up on the SIMH 16-bit Eclipse 
emulator. I think Bruce Ray once mentioned that SIMH's Eclipse emulation 
may not be quite complete enough to run AOS (though it runs RDOS just 
fine), but that's a project I'd love to work on.

Fond memories!
...dell

On Fri, 11 May 2012, Robert G. Schaffrath wrote:

> AOS/VS!  That brings back memories.  I used it in college back in the 1980's 
> on an MV/8000.  Later at a reseller I worked for I had an MV/4000 in-house 
> and various other MV's that were in various stages of being sent to 
> customers.  My last contact with AOS/VS would have been with release 6.0.0.0 
> or 7.0.0.0 in late 1987.  Sadly I have forgotten a lot about it though I 
> still have reams of code I wrote back in the day as well as some internals 
> tools written in macro.  I did have some fun patching the kernel to add "Load 
> System Ring" privilege to PID 2 as well as add an IO privilege to my profile 
> that PREDITOR did not offer but EXEC was more than happy to pass on to its 
> children.
>
> One thing that was quite advanced for its days was support of "Tasks" which 
> we now call "Threads".  The ability to have a program run several sections of 
> code simultaneously was an incredible concept though necessary in order to 
> implement Control-C/Control-A handlers.  Cross-task synchronization and 
> deadlocking were all issues I learned about before they again became issues 
> for the "multi-threading" community.
>
> If there ever was such an emulator I would not mind trying it out.  Currently 
> I play with the PDP11 and VAX emulators as I would up spending much more time 
> working with DEC equipment than DG.  As such, I have retained a lot more 
> knowledge about RSTS/E and VMS than I have about AOS/VS
>
> Robert
>
>
> On 5/11/2012 4:27 AM, Steve Merrony wrote:
>> I have heard it said that most successful OS efforts begin with with 
>> someone who 'has an itch to scratch'.  My persistent itch is a curious 
>> desire to have AOS/VS running in some form.
>> 
>> Over the years there has been a small amount of discussion on this forum 
>> about 32-bit DG, but it always peters out with someone saying they are in 
>> touch with ex-DG IP holders and then "nothing continues to happen"... 
>> Given the historical interest in the creation of the Eagle this seems to me 
>> to be a crying shame.
>> 
>> I have been pondering a way forward; as I see it there are two options:
>> 
>> 1. We go ahead with an MV simulator in SimH.  There is a lot of intact 
>> hardware documentation freely available on the net so I would have thought 
>> this is technically feasible.  The problem is software, but there are a few 
>> MVs around the world now run by enthusiasts  - maybe they could be 
>> persuaded to share privately until an official solution is worked out?
>> 
>> 2. A non-SimH route: we re-implement AOS/VS on modern hardware!  The whole 
>> OS, not just the CLI.  This is clearly a wildly different option, and at 
>> least as much work as option 1, but I think it could be a fascinating 
>> project in its own right.
>> 
>> Anyone interested?
>> 
>> 
>> -- 
>> /Stephen Merrony
>> /
>> 
>> 
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>