Re: [Simh] pdp11 - console input with high bit set

[Paul Koning]

> On Jul 24, 2020, at 5:57 PM, Clem Cole  wrote:
> 
> ...
>>  If you set your UART for 8 bits with parity, it would send 11 bits total: 
>> start, 8 data, parity, stop.
> Yep ...  you are correct that is exactly how the hardware works. mei culpa.   
> Although, if we are going to get specific.   There could also optionally be 2 
> stop bits.  As I said, the Model 33 used 2 but either 5-bit gear used either 
> 1 or 1.5.  I think I remember with 5-bit plus parity the A version generated 
> 1.5 stop bits when the chip was programmed for 2 and the original sent a full 
> 2 bits.
> 
> You are right that I should have been more specific but in all fairness, I 
> don't know of a DEC OS that supported that setup.  But I'm sure it was 
> possible and probably for people running PDP-11's as communications 
> 'front-ends' it was done.  The fact is if you ran 8 bits back in the day, it 
> was usually without parity.  Instead, some other protection was done in a 
> higher level protocol to protect and/or correct for transmission errors.

It's true that parity is a bit silly because it only does error detection on an 
unstructured data stream, which isn't all that helpful.  But it was fairly 
common practice at one time.  For example, the popular Friden Flexowriter 
machines -- somewhat like a TTY model 35 but even more reliable -- use a 7 bit 
character code that is better thought of as 6 bit characters with odd parity.

I don't know about others, but RSTS definitely supports setting parity on 8-bit 
data.  Since the devices (like DH11 and DHU11) support it, that's just a matter 
of the software implementing an API and telling the driver to set the proper 
bits:

$ set ter kb6/perm/parity=even

> 
> If I remember McNamara's book he had a whole chapter on errors and suggested 
> that parity was popular (almost always used) in early devices, like the 5-bit 
> Baudot based equipment like Teletypes model 28 and Friden Flexowriter, and of 
> course as you pointed out the infamous 7-bit Model 33 and 37.

Not 5 bit devices, none of those codes have parity.  Neither do 6 bit devices 
(typesetters).

>  But by the mid to late 70s, i.e. with the glass TTY it started to fall from 
> favor.   I don't know why, but I would suspect this was because dedicated 
> lines started to supplant telephone circuit-based connections and single-bit 
> error detect was not useful.  It did not happen that often.

It could be that glass TTYs were computer peripherals, and typically close to 
the computer or connected by a modem that was pretty clean.  The older devices 
tended to be on current loops, possibly quite long ones with debatable signal 
quality.

>> I've even run into 10-bit UARTs (on PLATO terminals).  But that's not DEC 
>> stuff.
> 
> Not surprised, CDC did some very strange things with characters ;-) 

True, but not this.  CDC had nothing to do with that design, it came from the U 
of Illinois.  7 bit characters, the high order bits were to indentify one of 
several data streams (keyboard, touch panel, echo response, external device).

The amazing thing is that they managed to get standard chips to speak these 
weird signalling schemes, in the later 8080-based PPT (PLATO V terminal).  10 
bit async one way, 21 bit sync the other way, both done with an 8251 USART.

paul

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

Re: [Simh] pdp11 - console input with high bit set

[Paul Koning]

> On Jul 24, 2020, at 3:15 PM, Clem Cole  wrote:
> 
> 
> 
> On Fri, Jul 24, 2020 at 2:37 PM Paul Koning  <mailto:paulkon...@comcast.net>> wrote:
> The right answer would be a tweak to the console emulation in SIMH pdp11.  
> Mumble... Paul - I'm not so sure.  While DEC used MARK a lot, there were 
> places that used EVEN parity a lot also on PDP-11's (Lord how, I hated 20 mA 
> current loop ;-) at least by the time of widespread RS-232C interfaces it was 
> glass ttys and usually a full 8-bit data path.   7-bit with odd/even is 
> defined this way:
> 
>  bits of data
> (count of 1-bits) 8 bits including parity
> even  odd
> 000   0   1000
> 1010001   3   1101000101010001
> 1101001   4   0110100111101001
> 111   7   0111
> FWIW:  I'm on a Mac and I run a program called 'Serial' that can do that; but 
>  I thought most of the programs that simulate a serial connection for the 
> different PC/Windows system have similar options.  Certainly that was true 
> when I did it with DOS.

I use minicom, and yes, it can do all those things.  But that wasn't the case I 
was thinking about.  I thought the issue isn't so much the case where you have 
a terminal emulator program talking to a serial port, but rather the case of 
your command window in which you invoke simh (pdp11) and you're then talking to 
the console terminal.  I would rather not have to change the settings on my 
regular shell to deal with oddball stuff expected by some application, I figure 
that's the application's job.

> Anyway, I think the 'right' answer for simh is to ask the user to use a 
> serial emulation program that can generate any of: 8-bit no parity, 7-bit no 
> parity, or 7-bits of data plus an 8th parity bit with any of the 4 parity 
> options:  odd, even, mark (aways 1) or space (always 0).   Seems to me, simh 
> should bring 8 bits into the simulated serial port and let the SW running on 
> the system decide what it's going to do with it.
> 
> I'm curious to hear what Bob thinks?  

Parity is something that comes in addition to the data.  DEC UARTS (and many 
others, I think) would let you set the data length (5, 6, 7, 8 bits) and the 
parity setting (none, even, odd).  So what you called "8 bits including parity" 
is technically "7 bits with parity".  If you set your UART for 8 bits with 
parity, it would send 11 bits total: start, 8 data, parity, stop.

I've even run into 10-bit UARTs (on PLATO terminals).  But that's not DEC stuff.

paul

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

Re: [Simh] pdp11 - console input with high bit set

[Paul Koning]

> On Jul 24, 2020, at 2:28 PM, David Gesswein  wrote:
> 
> On Fri, Jul 24, 2020 at 06:12:17PM +, Paul Moore wrote:
>> Not helped by not knowing what KSR really means.
>> 
> 
> Keyboard send receive. A model 33 teletype without paper tape.
> ASR was the model with paper tape, Automatic send receive.
> 
> DEC used teletype's that generated mark parity. From the manuals keyboards 
> were
> available to generate other parity. A reasonable amount of old code for
> PDP-8's assumed mark parity. Later code ignores the upper bit.
> 
> I thought the high bit setting would be turned off if you used set tti 7b or
> 8b but never verified.

7b, yes.  But that only helps with software that sets the top bit on output, as 
some old Unices do.  It doesn't help with the problem Paul M raised, which is 
software that insists on mark parity input.

The right answer would be a tweak to the console emulation in SIMH pdp11.  I 
wonder if this was done for PDP8 and not PDP11 because it was known to be 
needed on the one but people hadn't run into it for the other.

paul


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

Re: [Simh] FW: pdp 11 timing --> dectapes

[Paul Koning]

Right.  I was talking about RT-11, where this is clearly covered.  RALL (and 
WALL) are not going to be particularly friendly to multi-tasking either.

Here is the relevant code from FILEX.MAC (from RT V2).  Amazing stuff.  So yes, 
my memory was correct.  Note subrouting TWAIT, which watches for the word count 
register changing, indicating another 16 bits have been transferred to memory 
and the matching upper bits are in TCDT.

paul

.SBTTL  READ BLOCK FROM PDP-10 TAPE
; ROUTINE TO READ A BLOCK FROM A PDP-10 DECTAPE
; INTO AREA POINTED TO BY T.BUFF
; R0 = BLOCK NUMBER.  R0 IS DESTROYED.

T.RDTP: CLR -(SP)   ;GO INTO SYSTEM STATE
CALL1$  ;SO THAT TIMER TICKS ARE VERY FAST
TST DTERR   ;GOT DECTAPE ERRORS?
BNE RTS0;NO
ERR INER;YUP, HOW TERRIBLE
1$: MOVB#340,@#PS   ;UP TO 7
JSR R5,@54  ;TO YE SYSTEM
 .WORD  340 ;AT PRIORITY 0
MOV SP,DTERR;SAVE CURRENT SP, SAY NO ERROR
CALLSEARCH  ;POSITION THE DECTAPE
MOV R1,-(SP)
MOV R2,-(SP)
MOV (PC)+,R2;POINTER TO EXTRA BIT BUCKET
T.BUFF: .WORD   0
MOV R2,-(SP);SAVE BUFFER PTR
MOV #-256.,R1   ;SET UP WORD COUNT
MOV #TCDT,R0;POINT FOR FILLER
MOV R2,-(R0);STUFF BUS ADDRESS
MOV R1,-(R0);STUFF WORD COUNT
TST -(R0)   ;POINT RIGHT FOR BYTE
MOVB#340,@#PS   ;WE MUST NOT BE INTERRUPTED!!!
MOVB#5,@R0  ;SET YE COMMANDE GOING
1$: ADD #2,4(R0);POINT THE CONTROLLER TO GIVE ME ROOM
CLR @R2 ;UNUSED BITS MUST BE 0
CALLTWAIT   ;WAIT FOR READY WORD OR ERROR.
ASL @R2 ;MAKE ROOM WITH LONG LEFT 2
ROL -(R2)
ASL 2(R2)
ROL (R2)+
CALLTWAIT   ;WAIT FOR A WORD
TST (R2)+   ;SKIP OVER THE GOOD WORD
TST R1  ;ARE WE DONE (EVEN COUNT) ?
BGE 3$  ;YES, CEASE THIS STUFF
TST (PC)+   ;DO WE WANT ALL BITS?
FULLIO=.
.WORD   0
BNE 1$  ;YES, GO EAT
CLRB@#PS;DOWN AGAIN
2$: BIT #100200,@R0 ;NO, JUST WAIT FOR COMPLETION
BEQ 2$
BMI HARDER
3$: CLRB@#PS;DOWN TO 0 IF FULLIO ON
MOV T.UNIT,R1   ;A CONVENIENT STOP SEL TRANS
SWABR1  ;FIX IT UP
MOV R1,@R0  ;STOP IT!!
MOV (SP)+,R0;PASS HIM THE BUFFER ADDRESS
RTS2:   MOV (SP)+,R2
RTS1:   MOV (SP)+,R1
RTS0:   RETURN

TWAIT:  TST @R0 ;CHECK FOR ERROR
BMI HARDER  ;STOP IF SO
CMP R1,2(R0);IS A WORD READY?
BEQ TWAIT   ;NO, KEEP LOOPING
MOV @#TCST,-(SP);GET EXTRA BITS
BIC #14,@SP ;REMOVE JUNK
BIS (SP)+,(R2)+ ;ENBUFFER IT
INC R1  ;BUMP WORD COUNT
RETURN


paul


> On Jul 20, 2020, at 6:21 PM,   wrote:
> 
> On a single user machine possibly so, however on a 11/40 with about 14 user 
> working in timesharing mode I don't think it was doable without killing our 
> dear users.
> Some of them had a quickly detonating mindset about them which was best to 
> avoid for system managers who thought to be king in their own realm ...
> 
> 
> Reindert
> 
> -Original Message-
> From: Johnny Billquist [mailto:b...@softjar.se] 
> Sent: Tuesday, 21 July, 2020 00:16
> To: s...@swabhawat.com; simh@trailing-edge.com
> Subject: Re: [Simh] FW: pdp 11 timing --> dectapes
> 
> I think Paul's suggestion was if you actually keep a tight look at timing, 
> the extra two bits actually do appear in the other register as DMA is going 
> on, so you could just blindly read them out at the right times, and it might 
> work...
> 
>   Johnny
> 
> On 2020-07-21 00:12, s...@swabhawat.com wrote:
>> L.S.
>> 
>> When in the past using dectapes, we read/wrote Pdp10/8 dectapes on Rsx11-D.
>> On the Pdp11, you could do that only with READALL in interrupt mode to get 
>> the 2 extra bits, not in the standard dma mode.
>> Other (timesharing) users weren’t that happy because the interrupt 
>> processing locked them out for a while, so to appease them it went a block 
>> at a time and then wait a while.
>> 
>> Reindert
>> 
>> -Original Message-
>> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny 
>> Billquist
>> Sent: Tuesday, 21 July, 2020 00:02
>> To: Paul Koning ; Paul Moore 
>> 
>> Cc: simh@trailing-edge.com
>> Subject

Re: [Simh] pdp 11 timing

[Paul Koning]

> On Jul 20, 2020, at 5:10 PM, Paul Moore  wrote:
> 
> (I am writing my own emulator just because I have never done that before, and 
> the PDP 11 is such a pivotal system in the history of modern computing it 
> seemed worth learning about, and what better way to learn than to emulate it )
>  
> So how important is timing of instruction execution and device response?
>  
> The PDP 11 docs go  to great length giving instruction timing. But the fact 
> that there is a % throttle in simh suggest that’s not important. I assume 
> that turning that throttle up and down makes the emulated CPU go faster and 
> slower. I have seen code using simple counters as delays but I assume that if 
> you want precision you use the Kw11.
>  
> With regards device responses I have found that going ’too fast’ upsets code. 
> If they do something that triggers an interrupt (set ‘go’ for example) and 
> the interrupt arrives too soon (like before the next instruction) they get 
> surprised and can misbehave (you could argue that’s a bug, but that’s 
> irrelevant). So always wait a few beats. But  I assume there is no reason to 
> try to precisely emulate the timing of , say, a disk drive. (The early 
> handbooks state how awesome the async nature of the IO subsystem is cos you 
> can swap out old for new and things just go faster).

For the most part that should work fine.  The one exception I can think of is 
DECtape.  Driving one of those involves doing RNUM (read block number) 
operations to look for the desired block, then switching to the read or write 
data operation to do the actual I/O.  If a block goes by too fast, that won't 
work.  Related: RT-11 has contiguous files, and DECtape I/O should be able to 
see the consecutive blocks without overshooting, i.e., after block completion 
the next action is another RNUM (I believe) which should see the next block.

I don't think any PDP-11 OS does timing based block position prediction 
("overlapped seek") on DECtape, the way TOPS-10 and (reported) VMS do.  For 
that to work the timing has to be rather more accurately emulated.

Lastly, I don't know if anyone expects RT-11 FILEX reading of TOPS-10 tapes to 
work in emulation.  If I remember right, that does a rather strange thing: DMA 
the block to get the bottom 16 bits of each word, while watching the extended 
data register to get the upper 2 bits as the words fly by.  It doesn't use RALL 
which would have been a cleaner solution.  I think Anton said he didn't think 
of that, which seems hard to believe.

paul


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

Re: [Simh] Simh Digest, Vol 198, Issue 16

[Paul Koning]

> On Jul 9, 2020, at 10:40 PM, Johnny Billquist  wrote:
> 
> On 2020-07-10 04:37, Don North wrote:
>> On 7/9/2020 6:25 PM, Bob Supnik wrote:
>>> Yes, the PDP11 Architecture Handbook was a post-facto effort. The J11 was 
>>> finished; DEC did not intend to do another PDP11 processor. (I wrote a spec 
>>> for one, primarily as an exercise in trying to do a different microcode 
>>> structure than the PLA/ROM of the LSI11/F11/J11, but I lost it.) The only 
>>> formal part of the PDP11 architecture was the Commercial Instruction Set 
>>> extension, DEC STD 168, which was only implemented by the F11 and the 11/44.
>> AND the PDP-11/74 CIS option, I might add. Fully implemented, never sold.
> 
> Not to mention that the 11/74 in itself was fully implemented, but never 
> sold... Not even the 11/70MP...

Were there actually two prototypes called 11/74?  I know the MP machine, which 
the RSX-11 development team owned.  And in Merrimack (home of RSTS and some of 
the compiler teams) there was an 11/74 with CIS, for COBOL.  But that one 
wasn't an MP machine.  Perhaps a coincidence, I don't have a real memory either 
way.

paul


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

Re: [Simh] pdp11 fails MAINDEC CPU test 14 D0NA

[Paul Koning]

> On Jul 9, 2020, at 8:29 PM, Johnny Billquist  wrote:
> 
> On 2020-07-10 02:19, Paul Koning wrote:
>> The VAX architecture seems to have been an explicit design effort.  For the 
>> Alpha this was even more obvious, where a monstrously large book (certainly 
>> 500 pages, maybe double that) was written and reviewed in depth before 
>> anything was cast into silicon.  Not so for the PDP11, as you pointed out.
> 
> It definitely was an explicit effort. I seem to remember seeing/reading 
> somewhere at some point that this was because of what had happened on the 
> PDP-11. So a lesson learned kind of thing.

At least DEC learned.  Too many other companies had the same opportunity but 
did not take it.

> I used to have an Alpha Architecture manual, but I lost it somewhere along 
> the way. :-(

That's pretty amazing.  I had one, but I had to give it back.  It was a 
restricted access numbered copy.

> ...
>> My suspicion is that the PDP-11 architecture handbook was an after the fact 
>> effort.  The date (1983) supports that notion.  Also, it's a handbook, a fat 
>> paperback like the processor and peripheral handbooks.  I don't know of any 
>> internal analog, like DEC Std 032 for VAX.
> 
> Yeah, I would expect that it would an after the fact thing. But it would 
> still be interesting to see any effort made by DEC to put it all in one book. 
> As mentioned, the list (maybe in different revisions) do exist in multiple 
> other handbooks and manuals. But then it's just an appendix without much 
> further analysis.
> 
> I think I also saw/read somewhere that different new PDP-11 implementations 
> basically tried to look at what had previously been done, and tried to just 
> match that, as there was no official definition of a PDP-11. But then they 
> always did some deviation or other for the sake of efficiency, cost or just 
> clean up.

I think at least one or two differences were deliberate and planned -- between 
11/20 and the rest.  That's what the existence of the "Z" error code in the 
assembler implies.  (I think that pops up if you do one of those R0,(R0)+ 
instructions or cases like that, where the whole thread started.)  And the 
change of RTI along with the introduction of RTT is clearly an intentional 
change for optimization.

paul


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

Re: [Simh] pdp11 fails MAINDEC CPU test 14 D0NA

[Paul Koning]

> On Jul 9, 2020, at 8:13 PM, Johnny Billquist  wrote:
> 
> I know that CPU differences are documented in multiple different handbooks 
> and documents. But I am not aware of any definitive documentation of the 
> PDP-11 architecture like what you seem to refer to Paul (similar to the VARM 
> for VAX). If that handbook could be scanned in (or located anywhere on the 
> net already), it would be a good addition.
> 
> All documentation I know of is addressing various specific models, and the 
> later documentation sometimes contains a table with differences in different 
> implementations. The MicroPDP-11 Handbook for example, do have a list with 52 
> separate items for different PDP-11 models.
> 
> A slightly different list, in some ways more comprehensive, but lacking 
> information in other dimensions, are available in the PDP-11 Systems Handbook 
> (http://www.bitsavers.org/pdf/dec/pdp11/handbooks/PDP-11_Systems_Handbook_1987.pdf,
>  Appendix A).
> 
>  Johnny


The VAX architecture seems to have been an explicit design effort.  For the 
Alpha this was even more obvious, where a monstrously large book (certainly 500 
pages, maybe double that) was written and reviewed in depth before anything was 
cast into silicon.  Not so for the PDP11, as you pointed out.

My suspicion is that the PDP-11 architecture handbook was an after the fact 
effort.  The date (1983) supports that notion.  Also, it's a handbook, a fat 
paperback like the processor and peripheral handbooks.  I don't know of any 
internal analog, like DEC Std 032 for VAX.

The document number is EB-23657-18.  They seem to be around for sale, I see 
some in the $20-25 range which is not bad.  I'm hesitant to let mine out of my 
sights though I might at some point.

paul

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

Re: [Simh] pdp11 fails MAINDEC CPU test 14 D0NA

[Paul Koning]

The best reference for implementation dependencies is the PDP11 architecture 
handbook.  It covers the topic in Appendix B, 13 pages, 52 separate items.  I 
don't see it on Bitsavers, unfortunately.

paul

> On Jul 9, 2020, at 7:33 PM, Johnny Billquist  wrote:
> 
> Yes, if the test says that, it must be wrong, since the 11/05 and 11/20 do 
> not do the same thing here. This is documented in the MicroPDP-11 Handbook, 
> for example 
> (http://www.bitsavers.org/pdf/dec/pdp11/handbooks/EB-24944-18_Micro_PDP-11_Handbook_1983-84.pdf,
>  page 379 and forward).
> 
>  Johnny
> 
> On 2020-07-10 00:37, Paul Moore wrote:
>> So the test doc is wrong then, it says valid for 11/05, 20 and 10 (this is 
>> the MAINDEC manual dated oct 73)
>> I was running with SET CPU 11/05
>> Maybe the engineers knew to just ignore that failure, 'don’t worry they all 
>> halt there, just hit run, trust me'
>> Ran the same test on 11/20 and it passes
>> TBC - none of this is my code, either the test or the emulator, running DEC 
>> diagnostics on simh v4. This was just an FYI for you
>> I am stilling trying to get past the test of executing an IOT with the T bit 
>> set, that’s a tough one to get right . SO I have not reached this test yet
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] DLI losing upper bit

[Paul Koning]

> On Jun 25, 2020, at 11:07 AM, Mark Pizzolato  wrote:
> 
> On Thursday, June 25, 2020 at 7:28 AM, Paul Koning wrote:
>> I'm trying to use a SIMH PDP11 "DLI" device for DDCMP.  That requires 8 bit
>> transparent data, of course.  It's not working.
>> 
>> A trace shows that the simulator is stripping the upper bit on received 
>> bytes.
>> The console has a command to tell it not to do that (set tti 8b).  But while 
>> there
>> is "set dlo 8b" there is no "set dli 8b".
>> 
>> Is there a way to get DLI not to corrupt data?
> 
>  sim> SET DLOn 8B
> 
> Affects BOTH input and output traffic mode for line 'n' on the MUX.
> 
>  sim> SET DLO 8B
> 
> is ONLY equivalent to:
> 
>  sim> SET DLO0 8B
> 
> This is illustrated by HELP DLO SET
> 
> - Mark

Thanks, I see it does.  The help doesn't actually say that it affects both 
sides, and since for TT there are separate commands it would be nice to say it 
explicitly.

paul

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

[Simh] DLI losing upper bit

[Paul Koning]

I'm trying to use a SIMH PDP11 "DLI" device for DDCMP.  That requires 8 bit 
transparent data, of course.  It's not working.

A trace shows that the simulator is stripping the upper bit on received bytes.  
The console has a command to tell it not to do that (set tti 8b).  But while 
there is "set dlo 8b" there is no "set dli 8b".

Is there a way to get DLI not to corrupt data?

paul

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

Re: [Simh] New simulator for RCA 1802

[Paul Koning]

> On Jun 13, 2020, at 2:01 AM, Stephen Buck  wrote:
> 
> Hi, I’m interested in having a go at writing a simulator for the RCA CDP1802 
> processor. There is quite a bit of renewed interest in this unique processor 
> and the systems that made use of it, like the Cosmac Elf and a variety of 
> different spacecraft. It had some very unique features, such as the ability 
> to use any register as the program counter. The 1802 had a few successors 
> that added features and a family of peripheral processors. It was used as the 
> basis of commercial products as well as home-brew systems. 
> 
> I’m looking for a good place to start. If you were starting a new simulator 
> for a simple but unique chip which other simulator would you use as a SIMH 
> learning tool? Which simulator structure would best match the variety of 
> systems is was used in?

SIMH is a framework for writing system simulators.  Its particular strength is 
that it helps write not just the CPU but also the I/O device emulations, and 
lets you connect them in flexible ways.

If all you want is to simulate a microprocessor, SIMH is probably more than you 
need (though it should certainly work).  But if you want to recreate some 1802 
based systems, especially if more than one, it's probably a good choice.  The 
documentation is decent and there are a number of existing machine emulations 
you can use as references.  If there's anything in SIMH you're already familiar 
with, that's a good starting point.  For example, in my case I looked a lot at 
the PDP11 emulation.

paul

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

Re: [Simh] Lost PDP-11 OSes?

[Paul Koning]

> On May 20, 2020, at 11:38 PM, Ray Jewhurst  wrote:
> 
> I am trying to collect all the OSes that I can for the PDP-11 on Simh and I 
> have noticed that there are a few missing.  

Along those lines: is there MUMPS-11 anywhere?  That's nicely obscure.  Another 
obscure one is CAPS-11, though that's probably far less interesting.

MUMPS was a database system, apparently a very good one.  It was used as the 
core for ASSIST-11, a telephone directory assistance database.  In other words, 
the database that 411 operators would consult to answer your request for a 
phone number in a second or two.  Database lookup in a million-record or so 
database, in around a second, on a PDP-11 in 1978.  Nice.

paul


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

Re: [Simh] xterm and simh

[Paul Koning]

> On May 16, 2020, at 11:06 AM, Johnny Billquist  wrote:
> 
> Sounds like your problem is that TPU thinks your terminal understands 8-bit 
> control characters, while it actually doesn't.

If VMS is like RSTS, there is an "8 bit characters" setting but no separate 
8-bit controls setting, and presumably programs assume the former implies the 
latter.  After all, it does with DEC's terminals.

> Ctrl+Left click should show a menu entry "8-bit controls", which is the 
> corresponding thing on the xterm side.
> 
> However, to properly answer your question, we'd need to know a lot more about 
> your environment. And it's a bit hard to even ask the right questions here, 
> because xterm is so flexible that you can accomplish a lot of stuff in 
> multiple ways, and you might not even know what you are doing... And VMS 
> tries to figure out what your terminal is, and depending on various details, 
> xterm will identify in different ways, which is what VMS then base its 
> settings on...

As Johnny also pointed out, be sure not to have xterm set for UTF-8.  Not just 
because of 8-bit controls, but also because DEC applications are unlikely to 
know about it; they normally assume DEC MCS (a.k.a., DEC Std 169).  Latin-1 is 
a good approximation though not identical.

paul


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

Re: [Simh] vmb.exe - info - source code ? / vax (no O.S.) disk programming

[Paul Koning]

> On May 12, 2020, at 10:23 AM, Mike Stramba  wrote:
> 
> ...
> Is it "abandon ware" ?

Under copyright law, there is no such thing as "abandonware".

paul

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

Re: [Simh] Compile fail, linux 64 bit vax780 target

[Paul Koning]

> On May 8, 2020, at 7:38 AM, Mark Wickens  wrote:
> 
> I'm getting an error  - undeclared type off64_t when I try and compile the 
> vax780 emulator from a clone of the git repository made today. If I edit 
> sim_fio.c and change off64_t to __off64_t I then get implicit declaration 
> warnings for fopen64, fseeko64 and ftello64 and the Hardware Core Test EVKAA 
> core dumps.

Strange.  What gcc version?  64 bit support has been a core part of gcc for 
ages.

paul


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

Re: [Simh] Is it possible to simulate the first Vaxen I ever used?

[Paul Koning]

> On Mar 23, 2020, at 5:49 PM, Ray Jewhurst  wrote:
> 
> Slightly off topic, could someone explain more about what microcode is and 
> how it works? The fact that the CPU instructions are they themselves 
> programmed in seems unfathomable. 
> 
> Ray 

It's about a cost vs. performance tradeoff.  Many computers have quite complex 
instructions.  While it's always possible to implement them as big hunks of 
logic circuitry, that isn't necessarily the economically best answer.  The 
PDP-11/20 was done that way.  Supercomputers are often done that way because 
performance trumps cost.  And machines with simple instruction sets (RISC) are 
hardwired because the instruction set is specifically designed to make that 
efficient.

But a PDP-11, never mind a VAX or x86 PC CPU, has a very hairy instruction set 
with many variations.  If you think of executing these as a programming 
problem, you can decompose each instruction into a sequence of simpler 
operations.  SIMH does this, of course.  But you can also construct a simple 
computer that contains a well-chosen set of simple primitives, and construct 
complex instruction sets from those.

You can also do what van der Poel did in Holland ca. 1948, which is to expose a 
"horizontal microprogramming" instruction set directly to the application 
programmer.  But that makes the programmer's job rather hard, which is why it 
didn't catch on.

paul

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

Re: [Simh] Is it possible to simulate the first Vaxen I ever used?

[Paul Koning]

> On Mar 23, 2020, at 1:29 PM, Timothe Litt  wrote:
> 
> ...
>> Since the KL10 was DEC's biggest, most expensive machine at the time, it 
>> wasn't nearly as cost sensitive as their other CPUs, so there probably 
>> wasn't even any consideration given to using PROM for the control store.
> I don't think you could have found fast enough PROMs.  The KL is an ECL 
> machine.  The RAMs are ECL, and the timing is hairy enough that the modules 
> are only populated 1/2 way back - to fill the board would break timing.  The 
> boards also have loops of etch that serve as delay lines.  Manufacturing 
> would short the loops at the right place for each board - depending on how 
> the board (and RAMs) turned out.  Today we take for granted process controls 
> and tolerances that were, if not unattainable, unaffordable at that time.

Was there such a thing as ECL ROM?  I don't remember.

It's interesting to watch the evolution of high speed computers.  There's a 
continuous back and forth between memory and logic, depending on where the 
limitations are in the year or two when the design was frozen.  RAM and ROM 
have generally been different.

One example that comes to mind is the character stroke generator for the CDC 
6000 series mainframes.  That has a 10 MHz waveform step clock, so it needs a 
ROM with an access time comfortably below 100 ns (unless you want to use 
multiple banks).  In 1964 that was problematic, and the 6000 series display 
controller instead uses a massive logic chain to produce all the waveform data 
for all the character codes.  5-ish years later, in the Cyber 170 series, all 
that was replaced by a ROM.  Same data, but one chip instead of 100 or so 
plug-in logic modules.

Another example, also from that machine: the memory access and scheduling 
machinery is quite complex, with 32 memory banks operating concurrently.  
That's because many of the instructions complete in far less than a memory 
cycle time: 300 or 400 ns for the simpler instructions, and even a multiply 
takes only 1000 ns, while memory cycles in 1000 ns.  By 1964 standards, 1000 ns 
was amazingly fast, I don't think anyone else came close, and the core memory 
wiring and circuitry is quite exotic to make it go so fast.

On the VAX 730: as far as I'm aware it's the only VAX built out of standard LSI 
CPU components.  The guts of the CPU is AMD 2901 bit-slice chips.  All other 
DEC microprogrammed machines I can think of had their own purpose-designed 
logic.

2901 bitslices do appear in other DEC products, the UDA comes to mind.  And 
that has, for running on-board diagnostic tools, a small PDP11-like instruction 
set implemented in a little bit of 2901 microcode.  By Richie Lary, wizard of 
compact software...

paul

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

Re: [Simh] Is it possible to simulate the first Vaxen I ever used?

[Paul Koning]

> On Mar 23, 2020, at 10:34 AM, Dan Gahlinger  wrote:
> 
> ...
> I remember they opened the chassis a number of times to show off that bar, 
> the part was indeed labelled "FUBAR", it was the source of some laughs.

FUBAR is the name of a 780 CSR (in the UBA: failed unibus address register); 
perhaps it was used in the 730 as well.  I'm sure the engineers got a kick out 
of being able to sneak that acronym past the writers and managers.

> ...
> there was what I'd call a bug in the vms on that system.  you could rename a 
> .dir that had files within it to say .dat then delete the .dat if you set it 
> /nodirectory, and all the files within the dir would still use up disk space, 
> even though there was now no longer any way to work with them. so you'd have 
> this missing disk space basically forever, still counting against the users 
> quota.
> I know because I did that at least twice.

VMS is like Unix: directories are name to inode number maps (not called 
"inode"; I forgot the correct name).  A file doesn't need a name.  I remember 
RSX had an explicit way to reference a file by its number, don't remember what 
VMS did.

paul

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

Re: [Simh] Is it possible to simulate the first Vaxen I ever used?

[Paul Koning]

> On Mar 23, 2020, at 9:33 AM, Robert Armstrong  wrote:
> 
>> Ethan Dicks  wrote:
>> Using a PDP-8 as an FEP on any VAX definitely sounds odd.
> 
>  The console front end for the 730 was an 8085 (just like the KS10, FWIW).
> 
>  The 730 was interesting in that ALL of the CPU microcode was in RAM and was 
> loaded by the CFE at boot time.  It was possible to locally modify the 730 
> microcode, and DEC even had a set of microcode development tools for the 730. 
>  I've never seen them except in references.
> 
>  This is relevant because for years I've heard a persistent rumor that the 
> PDP-8/WPS-8 group at DEC had a 730 with microcode that had been hacked to 
> include a PDP-8 compatibility mode, which they used for development.  It was 
> faster than real -8 and supported timesharing to boot.
> 
>  I wonder if this is the source of the original poster's memory?  Can anybody 
> confirm or deny this rumor?

I can refute that.  The WPS group sat right next to my first DEC group 
(Typeset-11).  Yes, they had a machine with extended microcode to run PDP-8 
code faster.  But it was an 11/60 running RSTS/E.  That was in 1978; the 730 
didn't exist yet back then.

paul

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

Re: [Simh] VAX PSI

[Paul Koning]

I thought 2780 uses BISYNC, which is a different protocol.  X.25 is HDLC.  Yes, 
both need modem eliminators -- like an async null modem but an active device 
that also supplies the synchronous bit clock.

X.25 (and I think HDLC) is indeed asymmetrical.  Whether that can be gotten 
around is not entirely clear to me.  I do know X.25 has the concept of "call 
collision", a protocol failure caused by a protocol design error.  It uses a 
two-way connection handshake, which was well known at the time to be wrong, and 
both DDCMP and NSP as well as other protocols such as TCP have always used a 
three-way handshake for that rason.

paul

> On Mar 19, 2020, at 7:48 PM, John Welsh  wrote:
> 
> Hi Dave,
> I have been involved in a project using VAX-2780-3780PE and have been able to 
> connect two VAX’s together using a Black Box Synchronous Modem Eliminator ( 
> SME ).
> Product code: ME204A-F. 
> No VAX PSI involved.
> Needed Decnet Plus and Wan drivers.
> 
> Was able to test using a utility that comes with the Protocol Emulator - 
> XJTEST which can use either VAX as a loopback.
> In my case it was a DSV11 to a DSW42 using the SME and the V.24 cables that 
> come with the adapters.
> There is also another utility called REMOTE that can transfer simple files 
> from VAX to VAX.
> I don’t think there is a driver for SIMH that can emulate a sync device. ( 
> yet ).
> 
> Regards,
> John Welsh.
> 
> Sent from my  iPhone
> 
>> On 20 Mar 2020, at 03:38, dave porter  wrote:
>> 
>> I know almost nothing about VAX PSI, but I have a vague idea
>> that even though X.25 is asymmetric and intended for DTE to DCE 
>> communication (i.e., your computer to the phone company's premises), it may 
>> be possible to coerce it
>> into talking from one VAX to another (via null modem
>> cable connecting two devices such as DUP-11s).
>> 
>> I worked on RSX-11M PSI and that's how we tested in
>> the lab.  I can no longer remember how that was done.
>> Undocumented option somewhere, no doubt.
>> 
>> 
>> ___
>> 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] HPE has started emailing the final hobbyist licenses

[Paul Koning]

> On Mar 13, 2020, at 11:24 AM, Arthur Krewat  wrote:
> 
> I think I have some early VMS sources on microfiche somewhere...
> 
> 
> 
> On 3/12/2020 11:46 PM, Dan Gahlinger wrote:
>> Nice!
>> 
>> You wouldn't happen to have v4.2 or v5.2 ? 
>> 
>> I have v1.0 somewhere heh
>> 
>> Dan.

There is a VMS 1.5 tape on Bitsavers.  I haven't tried to do anything with it.  
No DECnet that I can see, though.

paul


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

Re: [Simh] Message order

[Paul Koning]

> On Mar 11, 2020, at 11:38 PM, John H. Reinhardt 
>  wrote:
> 
> Anyone else here get their messages out of order?  For example, I just now 
> got Richard Cromwell's announcement of the KL10 even though it's dated 
> 3/10/2020 at 8:16AM.  But I got Zane's reply YESTERDAY evening and Lars' 
> reply this morning.  Other times they all come in the proper order, but quite 
> often, they don't.  Is it my email service - Fastmail?

My ISP from time to time randomly delays some messages by hours if not a day or 
two.  It may be load dependent and it may also relate to which internal mail 
forwarder happens to be chosen for that particular message in the ISP's network.

You can see if the ISP is at fault by examining the timestamps on the 
forwarding headers of the email.

paul


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

Re: [Simh] New release of PDP10 simulators.

[Paul Koning]

> On Mar 10, 2020, at 9:16 AM, Richard Cornwell  wrote:
> 
> Hello,
> 
> I am pleased to announce the addition of the KL10 to the DEC PDP10
> simulators. With this addition all of the DEC PDP10 computers are now
> supported. Including the KA10, KI10, KL10A and KL10B and Bob's KS10.
> KL10 has support for ITS and will run TOPS 10 7 series monitors or TOPS
> 20 monitors. The KL10 will also run TOPS 10 6.03, along with the KA and
> KI. 

Wow!

> ...
> Software kits for Tops 10 and Tops 20 can be found at:
> 
>   http://sky-visions.com/dec

I looked there for a bit.  For those not fluent in PDP-10, would it be possible 
to add some instructions?  Or pointers to manuals (say, on Bitsavers) that 
would help?

One of the TOPS-20 releases is marked as being DECnet Phase II.  Do you know 
which flavor of DECnet the others are?  I'd like to find a Phase III to keep 
around for interoperability testing.

paul

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

Re: [Simh] macro11

[Paul Koning]

> On Mar 6, 2020, at 5:53 PM, Robert Armstrong  wrote:
> 
> 
>  Another macro11 question - do the apostrophes in the listing indicate
> relocatable references, as they do in the DEC version?
> 
>  If so, then I don't think it's assembling this code correctly -
> 
> 
>   1.TITLE  TEST RELOCATABLE
> REFERENCES
>   2 00 .ASECT
>   3001000  .=1000
>   4
>   5001234  X == 1234
>   6
>   7 001000 005067  001234' CLR X
>   8
> 
>  X should be an absolute address, not relocatable.
> 
> Bob

Well, X is absolute, as is the section, so the assembler can resolve the offset 
at assembly time.  If it did, the second word would be 000230.  But it looks 
like here it didn't do so, leaving the arithmetic up to the linker.

paul

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

Re: [Simh] macro11

[Paul Koning]

> On Mar 6, 2020, at 4:16 PM, Rhialto  wrote:
> 
> On Fri 06 Mar 2020 at 08:18:07 -0800, Robert Armstrong wrote:
>>  macro11 will assemble this once (or try to, without much success)
>>  anyway, despite the ?0?.  Is there a reason for this, or is this
>>  just a bug?
> 
> I guess it's a bug. The code in rept_irpc.c line 44 seems to decrement
> and check the count only at the end of producing the body of the REPT
> block. That is easily fixed. Several of the regression tests pick up a
> change now and I think it looks correct.
> 
> I am listing the repeat count as a computed value. I'm not sure if the
> original MACRO11 did this but it seems practical.

It does:

.MAIN.  MACRO V05.05  Monday 07-Mar-88 09:40  Page 1


  1 42  a=42
  2 01  .rept   a-41
  3 .word   44
  4 .endr
00  44  .word   44
  5 00  .rept   0
  6 .word   frob
  7 .endr
  8 01  .end

  paul

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

Re: [Simh] Various

[Paul Koning]

Apart from "no because it's not open source" there is also "no, because DEC 
didn't use source control like that".  Late in the RSTS development there was a 
very primitive source control system that understood the notion of checking out 
a file in the sense of reserving it.  But that tool (known as "MOM") was not a 
revision control system that tracked deltas.

I wonder if XX2477 LLC could be talked into opening up the sources of the 
software they own.

paul

> On Feb 14, 2020, at 5:26 PM, Stigall, BJ - Junk Mail 
>  wrote:
> 
> Is there an archive of source code for RT11, RSTS and other PDP operating 
> software (with comments, hopefully)?

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

Re: [Simh] Various

[Paul Koning]

> On Feb 14, 2020, at 3:03 AM, Lars Brinkhoff  wrote:
> 
> Paul Koning wrote:
>> It was pretty weird in that it ran a PDP-11 simulator (on the PDP-11)
>> so students could write something approximating bare-metal software
>> but get some debugging help if things go wrong.
>> 
>> They moved that course to CDC, and I helped write the analogous thing
>> for our Cyber (a Cyber emulator on Cyber).
> 
> Those sound marvellous.  I don't suppose either of them has survived?

No, unfortunately not.

paul


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

Re: [Simh] Various

[Paul Koning]

> On Feb 13, 2020, at 1:09 PM, Lars Brinkhoff  wrote:
> 
> Paul Koning wrote:
>> At U of Illinois, the computer science department had a PDP-11 used
>> for teaching assembly language programming.
> 
> I hope it wasn't the same they attached to Arpanet.

No, the ARPAnet one was a Unix system in the advanced computer center, the 
building that was originally built to house Illiac-IV.  The one I'm talking 
about was standalone, a DOS system in the computer science building.

It was pretty weird in that it ran a PDP-11 simulator (on the PDP-11) so 
students could write something approximating bare-metal software but get some 
debugging help if things go wrong.

They moved that course to CDC, and I helped write the analogous thing for our 
Cyber (a Cyber emulator on Cyber).

paul


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

Re: [Simh] Various

[Paul Koning]

> On Feb 13, 2020, at 11:38 AM, Clem Cole  wrote:
> 
> 
> 
> On Thu, Feb 13, 2020 at 10:50 AM Timothe Litt  wrote:
> Among others, DEC OEM'd Documation card readers.
> 
> https://www.youtube.com/watch?v=se0F1bLfFKY
> 
> Mark - sorry to go a little direct (simh) topic here [this sort of belongs on 
> Warren's COFF mailing list), but since the Card discussion started here as 
> I'm kinda curious and will ask it.
> 
> Did DEC actually sell that many?   In my years of working around DEC gear 
> starting in the late 1960s, I think I saw a card read/punch only once on a 
> PDP-6 IIRC, but it might have been a KA10.   I don't think I ever saw one on 
> a PDP-8/11 or Vaxen.

At U of Illinois, the computer science department had a PDP-11 used for 
teaching assembly language programming.  It had a CR11 which was the input 
device for student programs.

Note that these are just readers.  DEC did not sell a card punch for the PDP-11.

> I certainly saw and used them on IBM 1401/360 systems, the Univac 1100s and 
> CDC's.  I have not so fond memories of the IBM 1442, much less a 26 and 29 
> keypunch (and a couple of great stories too). 

CDC had its own card readers and punches, and those were also sold to some 
other manufacturers.  For example, the EL-X8 reader and punch are the CDC 415 
and 405.  On those machines paper tape was more common, but some installations 
did have punched card I/O.

One interesting aspect of the 405 is that it punches a row at a time.  Usually 
the program interface is with data in columns, so the controller had to do an 
80x12 matrix transpose.  Occasionally the job would be left to software (the X8 
did this).

paul

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

Re: [Simh] Initializing disks (triggered by the "Something Strange with RK05" chain

[Paul Koning]

> On Feb 12, 2020, at 5:37 PM, Mark Pizzolato  wrote:
> 
> Recent versions of the simh PDP11 will correctly auto size (RL01 vs RL02) 
> disk containers that have or don’t have the DEC STD 144 bad block table at 
> the end of the drive as long as the disk image has an RT11 file system on it. 
>  If it has an RT11 file system that fact will be reported.
>  
> The prompt “Overwrite last track? [N]” is actually asking a question about 
> whether the DEC STD 144 bad block table should be written.  The default of 
> “[N]” will create a 0 sized container file on simh v3.x and before.  On simh 
> 4.x, the container file will be created to the full size of the respective 
> drive without regard to the answer to the “Overwrite last track? [N]” 
> question.
>  
> Maybe the message:
>  
> ?DUP-F-Size function failed
>  
> Happens when an empty container is provided (without a DEC STD 144 bad block 
> info)…
>  
> -  Mark

That could be, but shouldn't the device type, if supplied, control what is 
reported?  And presumably that has a default, so if the container isn't 
pre-extended the default type would apply.

The file system based auto-sizing lets SIMH figure out what the type is given 
an undersized container and a file system it knows that allows it to deduce the 
size.  But without that you should still be able to force the size, right?

paul


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

Re: [Simh] Initializing disks (triggered by the "Something Strange with RK05" chain

[Paul Koning]

> On Feb 12, 2020, at 12:30 PM, Ken Hall  wrote:
> 
> I’ve played with RT11 on and off over the years, but the one thing I’ve never 
> been able to do is properly initialize an empty disk.  If I create a DL2: for 
> example, and try to run initialize on it, I get back:
>  
> .dir dl2:
> ?DIR-F-Error reading directory
>  
> .init dl2:
> DL2:/Initialize; Are you sure? YES
> ?DUP-F-Size function failed
>  
> This seems similar to the issues Henk Gooijen has been having with RK05’s, 
> and it’s been so long since I’ve dealt with the real hardware I don’t recall 
> exactly how this is supposed to work, but it seems to me it should just 
> “work”.
>  
> Has anyone found a solution to this?

I don't see that, at least not with RK05:

RT-11FBV02C-02

.
Simulation stopped, PC: 155450 (JSR PC,142336)
sim> att rk1 newrk.dsk
RK: creating new file
sim> c
R PIP
*RK1:/Z
RK1:/Z   ARE YOU SURE ?Y
*^C

.

paul

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

Re: [Simh] Subject: Re: something strange with simulated RK05 drive ?

[Paul Koning]

> On Feb 12, 2020, at 11:33 AM, Henk Gooijen  wrote:
> 
> Thanks for responses, I learned a few things!
> (I can only respond when I am at home, sorry for the delay)
>  
> The first (big) eye opener for me was that RK11 registers in SIMH are
> of course *not* the same as the RK05, duh!  Good to know for future
> projects!

The same goes for most other disks and tapes, basically anything with multiple 
units per controller would make this distinction in one way or another.

> I knew about the error conditions on the RK05 drive that turn on
> the FAULT indicator, but in SIMH_PiDP-11/70_simulated-RK05 it is
> difficult to break the positioner glass or have a burned-out lamp 
> So maybe the FAULT indicator lights up for a few reason that could be
> plausible, but are in fact not correct as they are RK11 errors and not
> RK05 drive errors!  Maybe I can get away with saying that the simulated
> "RK05 drive" is a drive plus controller …

It should be limited to problems that are not programming issues.  For example, 
loss of signal on the USB connection would be a possible reason.  Bad disk 
address should not be.
 
> What I also learned is that (at least in SIMH) you do not need to
> FORMAT a new RK05 disk (container file)!  Just an .INIT RK0: will do!
> However, initially I could not get the RK05 simulation working, so
> I got stuck on FORMAT (the reason was a stupid mistake on my side).
> When I enter the .FORMAT RK0:  command, I see the ONCYL, RD and WT
> LEDs flash and flicker for quite some time. When I enter .INIT RK0:
> ONCYL flashes once, and RD and WT flash briefly.

That fits: it is writing a blank directory, so it only writes the directory 
blocks.

> I tried in a "virgin" SIMH environment and Bob is (of course) correct.
> You do not need to FORMAT an RK05 in SIMH!  But it does actually format.
> However, it does so until it goes outside the range of valid cylinders.
> I guess that can be fixed, but as Bob says: don't do that 
> On my (long) "to do" list: "why format tries to write cylinder 203"?

I don't have the code so this is just a wild guess: perhaps it wants to be able 
to deal with drives of varying cylinder counts by stepping until it gets an 
error, then say "I guess that must be the end of this drive".
 
> I understand that the behavior of the lamps on my "simulated RK05"
> completely depends on how I added code for that in pdp11_rk.c.  But it
> seems OK to me, because when I boot RT-11 from that simulated RK05 drive
> ONCYL and RD flash most of the time, but WT also flashes a few times.
> Long ago I booted a (real) 11/34 using Don North's tu58em with diagnostic
> printout and (to my surprise) during the boot a few writes occurred.

Curious, because I'm pretty sure you can boot RT11 (at least V2) on a 
write-locked system disk.  Other operating systems might complain, though; for 
example, you can't boot a RSTS OS if the disk is write locked.  (But in late 
versions, a write locked disk is treated as a distribution device, which is 
only read by the initialization code.)
 
> At the moment I cannot verify with a real RK05, because the temperature
> in my "museum" is a bit low to run a real RK05 (just 10 degrees Celcius).
> My current implementation turns on the FAULT lamp for several reasons.
> - for the RK11 errors (so I need to check and somewhat improve that),
>   although the errors are not likely to occur in SIMH, unless you are
>   programming access to the registers directly and make a mistake ...
> - if the drive (or software!) sets the drive to "read-only" (thus the
>   WT-PROT lamp goes on), and you do some write action, for example, try
>   to delete a file, the FAULT lamp goes on.
>   Toggling the WT-PROT switch or (RT11 command) .SET RK0 LOCKED will
>   turn on the WT-PROT lamp. Toggling again or .SET RK0 WRITEENABLE will
>   turn off the WT-PROT lamp.

I don't understand what .SET RK0 WRITEENABLE can be.  The manual says that 
there is a write protect command, but that's a set, not a toggle.  In my 
experience, the only way to enable write after a write lock is with the switch.

paul

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

Re: [Simh] something strange with simulated RK05 drive ?

[Paul Koning]

> On Feb 11, 2020, at 8:02 PM, Johnny Billquist  wrote:
> 
> On 2020-02-12 01:49, Paul Koning wrote:
>>> ...
>> There is no fault light handling that I can see in SIMH.  The way I read 
>> Henk's comment is that he observed from debug messages added to pdp11_rk.c 
>> that RT11 FORMAT was passing an out of bounds cylinder number.  FWIW, I see 
>> RSTS-11 DSKINT format code stopping at cylinder 202, as expected.
> 
> Ok. You obviously looked deeper into it than I did. I have not actually 
> checked the simh code here.
> 
> But I did now... And I don't agree with you. simh is setting an error state 
> if you ask for a too high cylinder. And the error is exactly what Henk 
> described. RKER_NXC is set.

Yes, in the status register.  What I said is that there is no "FAULT" in SIMH.

> You are misunderstanding what Henk wrote.
> 
> However, with that said, Henk have misunderstood the system. It is important 
> to understand that the disk drive and the controller are two separate 
> entities. The fault light is only about error conditions on the disk drive, 
> not the controller.
> Out of cylinder errors are caught by the controller and never even gets to 
> the disk drive, so there is nothing that the disk drive will indicate for 
> this.
> 
> Henk, you need to understand how these systems work a little better. :-)
> 
>> I'm not sure why one would format an emulated RK05, assuming that it only 
>> simulates the data portion of the sectors and not the header word.
> 
> Oh, I agree that it's pretty much a NOP really.
> But if you have the system, and a command in there, you can bet that someone 
> is going to run it. And at least the system should pretend it did the "right" 
> thing...

It gets a bit tricky if you actually want to emulate the FORMAT bit.  While for 
writes it can just be ignored, there is the read operation with format set, 
which is documented as returning one word per sector, the header word.  I 
haven't seen that in use, perhaps it is found in diagnostics.  Does anyone know?

paul


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

Re: [Simh] something strange with simulated RK05 drive ?

[Paul Koning]

> On Feb 11, 2020, at 7:37 PM, Johnny Billquist  wrote:
> 
> On 2020-02-12 01:24, Paul Koning wrote:
>>> On Feb 11, 2020, at 6:00 PM, Johnny Billquist  wrote:
>>> 
>>> On 2020-02-11 23:25, Paul Koning wrote:
>>>>> On Feb 11, 2020, at 3:15 PM, Henk Gooijen  
>>>>> wrote:
>>>>> ...
>>>>>  As you can see from the printed debug statements, in the function rk_go()
>>>>> the cylinder number goes higher than the maximum number of cylinders
>>>>> possible on an RK05. Then, the function rk_set_done() is called with the
>>>>> variable "error" holding RKER_NXC (64 decimal == 000100, octal == 
>>>>> RKER_NXC)
>>>>> ==> turns on the FAULT indicator.
>>>>> SIMH does not generate an error, all is OK, as is on the real PDP-11 / 
>>>>> RK05.
>>>>> For now, I "solved" this by adding "if (error != RKER_NXC)", but that
>>>>> will exclude all "non-existing cylinder" errors, not only the error that
>>>>> is generated at the end of the FORMAT RK0:  command.
>>>>>  Is this incorrect behavior in SIMH, simulating the RK05?  I don't believe
>>>>> that, so is the RKER_NXC handled in the RK.SYS driver or in RT11 in case 
>>>>> of
>>>>> the execution of the FORMAT command?
>>>> I only have some V2 sources.  The zero directory operation, which I think 
>>>> is what "format" uses, just grabs the device size and writes an empty 
>>>> directory. So I'm puzzled by the reference to an invalid sector.
>>> 
>>> I would expect the INIT to write the empty directory. I would expect FORMAT 
>>> to actually format the disk pack, meaning writing the sector header for 
>>> each sector on the whole packet.
>>> A little surprised, though, that the formatting wouldn't know how many 
>>> tracks there are, and continue until it hits an error.
>> There is no such thing as "format", in the sense of writing sector headers, 
>> on an RK05.
> 
> Uh... Yes there is. I happen to have written a formatting program myself on a 
> PDP-8 for the RK05. It can definitely write the sector headers.

Oops.  You're right, I misremembered.  

>>>> The driver calls that a hard error (no retrying).
>>>> But why would you turn on the FAULT light on your RK05 for that?  Fault, 
>>>> on the RK05, means servo failure, in particular it means the servo grid 
>>>> light bulb has burned out.  References to invalid disk addresses don't 
>>>> light FAULT in an RK05.  The Peripherals handbook describes it as (a) that 
>>>> light bulb failed, or (b) write current is present without a write 
>>>> command, meaning your disk probably has been wiped by an electronic 
>>>> failure.
>>> 
>>> Sounds like simh does it wrong, then.
>> I don't think Henk was talking about SIMH having a problem, though I got a 
>> bit confused.  The question was about the fact that the fault light was 
>> coming on. My answer is: don't implement that light, there is no condition 
>> in the emulated drive that matches what that light does in the real drive.
> 
> I think Henk was also reflecting on that the error condition in simh was 
> triggered by the cylinder address error, and this is what he was using as the 
> source for his error light.
> 
> If I understood it right, Henk didn't implement the logic to trigger the 
> error state. He's merely extracting the information in order to display it on 
> the RK05 panel. And the light went on, and that led us here...
> But I might have missed the whole point...

There is no fault light handling that I can see in SIMH.  The way I read Henk's 
comment is that he observed from debug messages added to pdp11_rk.c that RT11 
FORMAT was passing an out of bounds cylinder number.  FWIW, I see RSTS-11 
DSKINT format code stopping at cylinder 202, as expected.

I'm not sure why one would format an emulated RK05, assuming that it only 
simulates the data portion of the sectors and not the header word.

paul


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

Re: [Simh] load

[Paul Koning]

> On Feb 11, 2020, at 6:04 PM, Kevin Handy  wrote:
> 
> Ok, I have looked at the link11 code, and after a lot of fuzzing around, got 
> it to compile under Linux. Attached is that code. It compiles without errors 
> using 'make', and I haven't tried -Wall yet.
> 
> I left it as mostly K, but I needed to stuff in a lot of prototypes to 
> quieten warnings, nor did I remove 'register' or 'auto' from definitions. 
> There was a lot of 'auto x' instead of 'auto int x' also.
> 
> However, it does not like the object files I threw at it, from the macro11 
> package on simtools, nor from object files from a RSTS/E system. It just says 
> 'not an object file'.

Which flavor of object files?  On RSTS/E, your choices are the RSX and RT11 
assemblers.  Their outputs are different.  RSX MAC puts out RMS variable length 
record files, so there are record headers.  It looks like the payload is 
classic formatted-binary data, though.  RT11 object files appears to be 
classic. 

paul

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

Re: [Simh] something strange with simulated RK05 drive ?

[Paul Koning]

> On Feb 11, 2020, at 6:00 PM, Johnny Billquist  wrote:
> 
> On 2020-02-11 23:25, Paul Koning wrote:
>>> On Feb 11, 2020, at 3:15 PM, Henk Gooijen  wrote:
>>> ...
>>>  As you can see from the printed debug statements, in the function rk_go()
>>> the cylinder number goes higher than the maximum number of cylinders
>>> possible on an RK05. Then, the function rk_set_done() is called with the
>>> variable "error" holding RKER_NXC (64 decimal == 000100, octal == RKER_NXC)
>>> ==> turns on the FAULT indicator.
>>> SIMH does not generate an error, all is OK, as is on the real PDP-11 / RK05.
>>> For now, I "solved" this by adding "if (error != RKER_NXC)", but that
>>> will exclude all "non-existing cylinder" errors, not only the error that
>>> is generated at the end of the FORMAT RK0:  command.
>>>  Is this incorrect behavior in SIMH, simulating the RK05?  I don't believe
>>> that, so is the RKER_NXC handled in the RK.SYS driver or in RT11 in case of
>>> the execution of the FORMAT command?
>> I only have some V2 sources.  The zero directory operation, which I think is 
>> what "format" uses, just grabs the device size and writes an empty 
>> directory.  So I'm puzzled by the reference to an invalid sector.
> 
> I would expect the INIT to write the empty directory. I would expect FORMAT 
> to actually format the disk pack, meaning writing the sector header for each 
> sector on the whole packet.
> A little surprised, though, that the formatting wouldn't know how many tracks 
> there are, and continue until it hits an error.

There is no such thing as "format", in the sense of writing sector headers, on 
an RK05.

>> The driver calls that a hard error (no retrying).
>> But why would you turn on the FAULT light on your RK05 for that?  Fault, on 
>> the RK05, means servo failure, in particular it means the servo grid light 
>> bulb has burned out.  References to invalid disk addresses don't light FAULT 
>> in an RK05.  The Peripherals handbook describes it as (a) that light bulb 
>> failed, or (b) write current is present without a write command, meaning 
>> your disk probably has been wiped by an electronic failure.
> 
> Sounds like simh does it wrong, then.

I don't think Henk was talking about SIMH having a problem, though I got a bit 
confused.  The question was about the fact that the fault light was coming on.  
My answer is: don't implement that light, there is no condition in the emulated 
drive that matches what that light does in the real drive.

paul

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

Re: [Simh] something strange with simulated RK05 drive ?

[Paul Koning]

> On Feb 11, 2020, at 3:15 PM, Henk Gooijen  wrote:
> 
> I am building a replica RK05 disk drive with working switches and panel lamps.
> This will be an add-on to the PiDP-11/70, giving the user even more the look
> and feel of operating a PDP-11 system   The RK05 drive is constructed at the
> same scale dimensions as Oscar's PiDP-11/70 and has a front door with lock
> mechanism just like the real RK05. A real RK05 disk cartridge is 3D scanned
> and will be (scaled) 3D printed. Inside that disk cartridge is a USB stick on
> which 7 virtual RK05 "disk" container files can be stored. Jumper setting in
> the cartridge selects which container file is actually "mounted" when the
> cartrdige is mounted in the drive.

Neat.

> So far for the introduction 
> To make this setup work I have made changes to scp.c, scp.h, pdp11_cpu.c,
> pdp11_rk.c and the makefile, and added a few files (drive "behavior" and USB
> stick handling).
> All indicator lamps seem to behave as on the real RK05 drive ... however,
> when I do .FORMAT RK0:  (I am using RT-11)  this command always ends with
> turning on the FAULT indicator. I have added print statements to the original
> SIMH distribution in pdp11_rk.c to show the problem (so no "rubbish of mine
> interference").
> This is what I see:
>  
> PDP-11 simulator V4.0-0 Currentgit commit id: 0de9b628
> sim> set rl rl02
> sim> att rl0 rt-work.dsk
> RL0: 'rt-work.dsk' Contains RT11 partitions
> 1 valid partition, Type: V05, Sectors On Disk: 10210
> sim> att rk0 rk.dsk
> RK: creating new file
> sim> boot rl0
>  
> RT-11FB  V5.03
>  
> .dir rk0:
>  
> ?DIR-F-Invalid directory
>  
> .format rk0:
> RK0:/FORMAT-Are you sure? Y
>  
> pdp11_rk.c :: in rk_go() cyl >= RK_NUMCY
> pdp11_rk.c :: rk_set_done() called with error 64
>  
> ?FORMAT-I-Formatting complete
>  
> .init rk0:
> RK0:/Initialzie; Are you sure? Y
>  
> .dir rk0:
>  
>  
> 0 Files, 0 Blocks
> 4762 Free blocks
>  
> .
>  
> As you can see from the printed debug statements, in the function rk_go()
> the cylinder number goes higher than the maximum number of cylinders
> possible on an RK05. Then, the function rk_set_done() is called with the
> variable "error" holding RKER_NXC (64 decimal == 000100, octal == RKER_NXC)
> ==> turns on the FAULT indicator.
> SIMH does not generate an error, all is OK, as is on the real PDP-11 / RK05.
> For now, I "solved" this by adding "if (error != RKER_NXC)", but that
> will exclude all "non-existing cylinder" errors, not only the error that
> is generated at the end of the FORMAT RK0:  command.
>  
> Is this incorrect behavior in SIMH, simulating the RK05?  I don't believe
> that, so is the RKER_NXC handled in the RK.SYS driver or in RT11 in case of
> the execution of the FORMAT command?

I only have some V2 sources.  The zero directory operation, which I think is 
what "format" uses, just grabs the device size and writes an empty directory.  
So I'm puzzled by the reference to an invalid sector.

The driver calls that a hard error (no retrying).

But why would you turn on the FAULT light on your RK05 for that?  Fault, on the 
RK05, means servo failure, in particular it means the servo grid light bulb has 
burned out.  References to invalid disk addresses don't light FAULT in an RK05. 
 The Peripherals handbook describes it as (a) that light bulb failed, or (b) 
write current is present without a write command, meaning your disk probably 
has been wiped by an electronic failure.

paul

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

Re: [Simh] load

[Paul Koning]

> On Jan 24, 2020, at 6:26 PM, Kevin Handy  wrote:
> 
> I was watching some youtube videos about the PiDP-11, and they all seemed to 
> end up typing in a hand-assembled program into the emulator.
> 
> It got me  to thinking about the macro11 assembler in simtools, however that 
> program only appears to output object files, not binary ones. simh appears to 
> only accept binary filesm not object files.
> 
> Is there some way to bridge the gap? Is there some method to bridge he gap? 
> marco11 to output binary files, a linker to convert object files to binary 
> ones, or simh to accept object files.
> 
> For the PiDP-11 users, they could prooblbly work from a listing where a 
> hard-coded base address is given, but others might want to try something that 
> is too long to want to key it in.
> 
> If this is already possible, some documentation on the process would be 
> useful. This would also make simtools more useful.
> 
> This applies to all the other emulations that have assemblers available also.

This probably isn't quite what you're looking for, but if not it could be 
tweaked.

For running parts of the GCC test suite for the PDP11 target, I wanted to be 
able to run its output on SIMH.  Here is a simple Python program that turns 
Unix style a.out files (the archaic PDP11 flavor rather than the later flavor 
used in some other platforms) into DEC standard paper tape binary loader files 
that SIMH will accept.

paul

#!/usr/bin/env python

"""Convert a PDP11 a.out file to papertape loader format
(a.k.a. "formatted binary").
"""

DEBUG = 0

import sys
import struct

DEFBASE = 01000   # program first word address
TSTART = 020  # start of text in input file

def csum (data):
cs = 0
for c in data:
cs += ord (c)
return chr ((256 - cs) & 0xff)

inf = open (sys.argv[1], "rb")

data = inf.read ()
inf.close ()
m, tlen, dlen, bsslen, stlen, xfer = struct.unpack (" len (data):
print "text or data section beyond end of input"
sys.exit (1)

if TSTART + tlen + dlen > 016:
print "Program is too large: %o" % (TSTART + tlen + dlen)
sys.exit (1)

if xfer < base or xfer > base + tlen:
print "transfer address %06o is out of range" % xfer
sys.exit (1)

# Data starts on an even address.  Note: this is a function of the
# link script used.  Without a script, the linker apparently pads to a
# multiple of 0400, but pdp11-simh.ld just does alignment to even.
dbase = base + tlen
dbase = (dbase + 1) & -2

if DEBUG:
print "text base %06o data base %06o" % (base, dbase)

outf = open (sys.argv[2], "wb")

text = data[TSTART:tlen + TSTART]
data = data[TSTART + tlen:TSTART + tlen + dlen]

l = len (text) + 6
text = struct.pack ("___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Display using GPU shaders

[Paul Koning]

> On Jan 3, 2020, at 2:13 AM, Lars Brinkhoff  wrote:
> 
>> As far as I understand, SDL2 has some kind of support for using
>> shaders, so I believe there are no technical obstacles against adding
>> my code to SIMH.
> 
> Looking closer, I was wrong about this.  SDL only handles some basics.
> To use shaders, it's necessary to add direct calls to OpenGL (or on
> Windows maybe some other library?).

For a portable windowing library that includes OpenGL support, check out 
wxWidgets.  It's quite a lot heavier than SDL but it is quite friendly.

paul

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

Re: [Simh] MIT MTC Docs

[Paul Koning]

> On Dec 31, 2019, at 7:39 PM, Phil Budne  wrote:
> 
> ...
> Ken Olsen is supposed to have been the MTC designer,
> his signature appears in
> 
> http://www.bitsavers.org/pdf/mit/lincolnLaboratory/mtc/M-2134_MTC_Tests_on_Magnetic_Memory_May1953.pdf

KO has an interesting history with ferrite devices.  The one you mentioned is 
one.  He did work on ferrite core logic devices, which is interesting stuff.  
And it appears he's the inventor of the core rope ROM memory used in the Apollo 
spacecraft.  (At least the name "Olsen" appears in the documentation, so that 
would be him unless there was another Olsen at Lincoln Labs.)

paul

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

Re: [Simh] Some beginner questions about RSX11 and/or RSTS on simh...

[Paul Koning]

> On Dec 24, 2019, at 12:06 PM, Dave Shevett  wrote:
> 
> Hi everyone - happily getting into simh now, reliving my happy
> upbringing on DEC hardware :) . I used to run RSTS on my own 11/34a,
> and did a bunch of other work on RSX-11m on DEC Pro/350's, so very
> much looking forward to reliving some of those times.

You mean real RSX, not POS?

One of these days I should make my RSTS/E for Pro available.

> A couple basic questions
> 
> 1) I'm assuming RSX-11m is where I should be focusing my work - even
> though my personal systems were RSTS based, (with an occasional boot
> of RT11 to test stuff)  i feel RSX-11m is the more 'complete' and
> modern OS (contextually speaking).  Does this make sense?

Not necessarily.  It depends a bit on what you want to do.  As Johnny points 
out, if you want TCP/IP, the only RSX will do thanks to his work.  (Or Unix I 
suppose, but I assume we're talking DEC operating systems.)  If you want to 
write device drivers, RSX or RT are options, RSTS is not.  (At least not in the 
sense of something you can do from documentation -- it *can* be done and has 
been but unless you were part of the RSTS/E engineering team it's quite tough 
to pull off.)  If you want something really fast and skinny, RT-11 is the 
obvious answer.  RSTS/E of course is the place for traditional timesharing. 

If you are looking for places to run application programs you might have lying 
around, RSTS/E is probably a very good answer.  It has both RT11 and RSX 
emulation that's quite solid.  Some real time features may not be great, though 
they should be faked adequately.  For example, RSTS doesn't have ASTs or 
asynchronous I/O (except some disk and tape I/O in V9.0 and later) but the 
emulation will fake it.  Similarly, you can run user interfaces that feel like 
RT11 or RSX, at least superficially.  And DCL in V9 or V10 is very good.

paul

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

Re: [Simh] simh and RSTS/E - problems with getting additional terminal interfaces to work

[Paul Koning]

I didn't say it clearly, but... around V9, the terminal driver was reorganized 
to have "port drivers" which are separately loadable.  And those are always 
included with the monitor.  So in those versions, there is no longer a terminal 
configuration section in the Sysgen dialog, and instead you get the terminals 
that are in the hardware.  To get more, just add some controllers and restart.

paul

> On Dec 9, 2019, at 10:12 AM, Trevor Warwick  wrote:
> 
> Thanks Paul. Now you mention it, I do have a vague recollection of doing 
> Sysgens when adding new hardware back in V6/V7 days. I'll look around for a 
> later version to run and see if that fixes things, and/or try generating my 
> own system.
> 
> On Mon, 9 Dec 2019 at 15:04, Paul Koning  <mailto:paulkon...@comcast.net>> wrote:
> RSTS/E (starting with V6B, that is) recognizes devices based on their CSR 
> address, fixed or float.  It doesn't care about vector rules (except for the 
> card reader); instead, it probes the device to find out.  So you need to make 
> sure a device is assigned the proper CSR address by the rules and then RSTS 
> will know it.  You can confirm by doing "hardware list".
> 
> In the example shown, you can see that indeed RSTS recognized the additional 
> DL lines.
> 
> However Prior to V9 or thereabouts (I'd have to search a bit to be more 
> precise), RSTS/E device support including terminal interface support was set 
> at Sysgen.  You could omit controllers that aren't in the build and those 
> would be disabled, but if you include devices not mentioned in the Sysgen 
> they would be silently ignored by RSTS.  Note that INIT (which is what does 
> the hardware display) knows about all supported devices; the fact that a 
> particular RSTS monitor doesn't include the support doesn't bother it.
> 
> So the fact that added terminal lines don't work suggests that they weren't 
> in the sysgen.  If there is a config.mac somewhere on the system that might 
> be the one from the sysgen and would tell you what's supported.  Also, 
> sufficiently new RSTS systems have a DCL command "show device" which says 
> what devices the monitor knows about.
> 
>   paul
> 
>> On Dec 9, 2019, at 5:29 AM, Johnny Billquist > <mailto:b...@softjar.se>> wrote:
>> 
>> In RSTS/E, you have DZ11 lines, but they are configured for a CSR of 160100 
>> and 160110, and vectors are 400 and 410. I bet that does not match what simh 
>> thinks...
>> 
>>  Johnny
>> 
>> On 2019-12-09 11:25, Trevor Warwick wrote:
>>> I'm using "PDP-11 simulator V4.0-0 Current", and getting the same results 
>>> on Win10 and Linux.
>>> I'm booting the full RSTS V7.0-07 disk, built by by Chuck Cranor. This 
>>> boots fine, and I can log in on the simulated console. However, I can't 
>>> persuade it to recognise any additional terminals. If I use:
>>> set dli enable
>>> set dli lines=8
>>> attach dli 10001
>>> Then I get a telnet server appearing on port 10001, which prints "Connected 
>>> to the PDP-11 simulator DLI device, line 0" when I boot the RSTS system 
>>> disk. However, there's no response to any input once RSTS is up and 
>>> running.  I've also tried using a DZ11
>>> set dz lines=8
>>> attach dz 10002
>>> and in that case I don't even get the "Connected" line from simh. RSTS 
>>> can apparently see the hardware though:
>>> RSTS V7.0-07 llama (DL0)
>>> Option: HA
>>>   HARDWR suboption? LI
>>>   Name  Address Vector  Comments
>>>   TT:177560   060
>>>   RK:177400   220   RK05F units: none
>>>   RL:174400   160   Units: 0(RL01) 1(RL01) 2(RL01) 3(RL01)
>>>   RM:177440   210   Units: 0(RK06) 1(RK06) 2(RK06) 3(RK06) 4(RK06)
>>>5(RK06) 6(RK06) 7(RK06)
>>>   RR:176700   254   BAE=+050, Units: 0(RM03) 1(RM03) 2(RM03)
>>>3(RM03) 4(RM03) 5(RM03) 6(RM03) 7(RM03)
>>>   TM:172520   224
>>>   PR0:   177550   070
>>>   PP0:   177554   074
>>>   LP0:   177514   200
>>>   RX0:   177170   264
>>>   KL0:   176500   300
>>>   KL1:   176510   310
>>>   KL2:   176520   320
>>>   KL3:   176530   330
>>>   KL4:   176540   340
>>>   KL5:   176550   350
>>>   KL6:   176560   360
>>>   KL7:   176570   370
>>>   DZ0:   160100   400
>>>   DZ1:   160110   410
>>>   KW11L  177546   100
>>>   SR 177570
>>>   DR 177570
>>>   Hertz = 60.
>>>   

Re: [Simh] simh and RSTS/E - problems with getting additional terminal interfaces to work

[Paul Koning]

RSTS/E (starting with V6B, that is) recognizes devices based on their CSR 
address, fixed or float.  It doesn't care about vector rules (except for the 
card reader); instead, it probes the device to find out.  So you need to make 
sure a device is assigned the proper CSR address by the rules and then RSTS 
will know it.  You can confirm by doing "hardware list".

In the example shown, you can see that indeed RSTS recognized the additional DL 
lines.

However Prior to V9 or thereabouts (I'd have to search a bit to be more 
precise), RSTS/E device support including terminal interface support was set at 
Sysgen.  You could omit controllers that aren't in the build and those would be 
disabled, but if you include devices not mentioned in the Sysgen they would be 
silently ignored by RSTS.  Note that INIT (which is what does the hardware 
display) knows about all supported devices; the fact that a particular RSTS 
monitor doesn't include the support doesn't bother it.

So the fact that added terminal lines don't work suggests that they weren't in 
the sysgen.  If there is a config.mac somewhere on the system that might be the 
one from the sysgen and would tell you what's supported.  Also, sufficiently 
new RSTS systems have a DCL command "show device" which says what devices the 
monitor knows about.

paul

> On Dec 9, 2019, at 5:29 AM, Johnny Billquist  wrote:
> 
> In RSTS/E, you have DZ11 lines, but they are configured for a CSR of 160100 
> and 160110, and vectors are 400 and 410. I bet that does not match what simh 
> thinks...
> 
>  Johnny
> 
> On 2019-12-09 11:25, Trevor Warwick wrote:
>> I'm using "PDP-11 simulator V4.0-0 Current", and getting the same results on 
>> Win10 and Linux.
>> I'm booting the full RSTS V7.0-07 disk, built by by Chuck Cranor. This boots 
>> fine, and I can log in on the simulated console. However, I can't persuade 
>> it to recognise any additional terminals. If I use:
>> set dli enable
>> set dli lines=8
>> attach dli 10001
>> Then I get a telnet server appearing on port 10001, which prints "Connected 
>> to the PDP-11 simulator DLI device, line 0" when I boot the RSTS system 
>> disk. However, there's no response to any input once RSTS is up and running. 
>>  I've also tried using a DZ11
>> set dz lines=8
>> attach dz 10002
>> and in that case I don't even get the "Connected" line from simh. RSTS 
>> can apparently see the hardware though:
>> RSTS V7.0-07 llama (DL0)
>> Option: HA
>>   HARDWR suboption? LI
>>   Name  Address Vector  Comments
>>   TT:177560   060
>>   RK:177400   220   RK05F units: none
>>   RL:174400   160   Units: 0(RL01) 1(RL01) 2(RL01) 3(RL01)
>>   RM:177440   210   Units: 0(RK06) 1(RK06) 2(RK06) 3(RK06) 4(RK06)
>>5(RK06) 6(RK06) 7(RK06)
>>   RR:176700   254   BAE=+050, Units: 0(RM03) 1(RM03) 2(RM03)
>>3(RM03) 4(RM03) 5(RM03) 6(RM03) 7(RM03)
>>   TM:172520   224
>>   PR0:   177550   070
>>   PP0:   177554   074
>>   LP0:   177514   200
>>   RX0:   177170   264
>>   KL0:   176500   300
>>   KL1:   176510   310
>>   KL2:   176520   320
>>   KL3:   176530   330
>>   KL4:   176540   340
>>   KL5:   176550   350
>>   KL6:   176560   360
>>   KL7:   176570   370
>>   DZ0:   160100   400
>>   DZ1:   160110   410
>>   KW11L  177546   100
>>   SR 177570
>>   DR 177570
>>   Hertz = 60.
>>   Other: FPU, SL, 22-Bit Addressing, Cache w/address, System ID = 4660
>> If I boot an RSX-11M disk, then additional terminal interfaces seem to work 
>> fine, so the problem seems specific to RSTS.   I saw references in the list 
>> archive to other pre-built systems on www.rsts.org  
>> > but that doesn't seem to be 
>> available at the moment, so I can't try another build right now.
>> Any clues on what I'm missing ?
>> Thanks,
>> Trevor
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com 
>> http://mailman.trailing-edge.com/mailman/listinfo/simh 
>> 
> 
> -- 
> Johnny Billquist  || "I'm on a bus
>  ||  on a psychedelic trip
> email: b...@softjar.se  ||  Reading 
> murder books
> pdp is alive! ||  tryin' to stay hip" - B. Idol
> ___
> 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] EXT :Re: Unattended background SIMH process

[Paul Koning]

> On Dec 5, 2019, at 10:37 AM, Hittner, David T [US] (MS) 
>  wrote:
> 
> Mark can correct me if I'm wrong, but I believe that most of the SIMH 
> simulators can already save the state (from the ^E prompt) and restore using 
> the SAVE and RESTORE commands. I think this capability was added to 
> facilitate very long debugging sessions over a multi-day period.
> 
> It's possible that the only thing that might need to be added to SIMH to 
> support an automatic save on a hardware power fail is the ability for the 
> master thread to detect the power fail event and initiate an auto-save, and 
> of course enough time to actually perform the save before the power fails. 
> Potentially this power fail detection and auto-save from the master thread 
> could be enabled by something like a "POWERFAIL AUTOSAVE " command.

I think the other change needed is delivery of power fail interrupts.  It could 
be made part of SAVE and RESTORE, or separate.  If separate, you'd do one 
before SAVE, and after RESTORE.

That's not an exact match, though.  In the real machine, with persistent memory 
such as core, the memory is preserved across power cycles but the system is 
otherwise reset.  So I think what you actually need is powerfail interrupt, 
save, then later on restore, reset, powerfail interrupt. 

paul

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

Re: [Simh] Unattended background SIMH process

[Paul Koning]

> On Dec 4, 2019, at 8:05 PM, Johnny Billquist  wrote:
> 
> On 2019-12-05 01:34, Paul Koning wrote:
>>> On Dec 4, 2019, at 6:15 PM, Kevin Handy  wrote:
>>> 
>>> What it sounds like you need, is  for simh to detect the shutdown interrupt 
>>> itself, and then save the current state of everything in the machine to a 
>>> file. Upon power-up, it then needs to restore back to that state.
>>> You;d have to save the current configuration settings,  state of memory, 
>>> cpu registers, device structures, etc., and then be able to read it all 
>>> back in and restore everything back to a working state. Could get 
>>> complicated, for example the disk drive have a timer in them so that they 
>>> don't respond instantly to read requests, so this type of thing would need 
>>> to be saved.
>>> Is it possible to manually do this right now? Store the state of a machine, 
>>> them restore it back using simh commands to individually reset all the 
>>> devices?
>> On a PDP11, this could be handled via a power fail interrupt, assuming the 
>> OS you have supports power fail and recovery. RSTS-11, with core memory (so 
>> you'd want to persist the memory across restarts) does. I'm not sure if 
>> others do.  (RSTS/E does not.)
> 
> Right. And all members of RSX do handle power fail and recovery. Individual 
> programs can also be notified if a power fail even happened while they were 
> running, in case there is something they need to do under such circumstances.

I should have remembered that.  In fact, on IAS (and RSX-11/D if I remember 
right), the system boot takes advantage of this: the SAV command saves a system 
image on disk, the boot loader reads that back in, and then power fail ASTs are 
delivered to all the relevant parts to restore them to operating state.  Neat 
trick.

In RSTS-11, a power fail and recovery simply leaves the system state as it was, 
with all the logged in terminals still logged in.  For a long power outage 
that's not really a good feature.  I saw it work once while in college.  RSTS/E 
dropped this because of the switch to semiconductor memory; instead it offers 
automatic restart (a clean startup, so everything is logged out and back to 
idle).

paul


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

Re: [Simh] Unattended background SIMH process

[Paul Koning]

> On Dec 4, 2019, at 6:15 PM, Kevin Handy  wrote:
> 
> What it sounds like you need, is  for simh to detect the shutdown interrupt 
> itself, and then save the current state of everything in the machine to a 
> file. Upon power-up, it then needs to restore back to that state.
> You;d have to save the current configuration settings,  state of memory, cpu 
> registers, device structures, etc., and then be able to read it all back in 
> and restore everything back to a working state. Could get complicated, for 
> example the disk drive have a timer in them so that they don't respond 
> instantly to read requests, so this type of thing would need to be saved.
> Is it possible to manually do this right now? Store the state of a machine, 
> them restore it back using simh commands to individually reset all the 
> devices?

On a PDP11, this could be handled via a power fail interrupt, assuming the OS 
you have supports power fail and recovery. RSTS-11, with core memory (so you'd 
want to persist the memory across restarts) does. I'm not sure if others do.  
(RSTS/E does not.)

paul

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

Re: [Simh] Simh Digest, Vol 189, Issue 7

[Paul Koning]

> On Oct 10, 2019, at 2:50 PM, Peter Allan  wrote:
> 
> I tried 1,2 SYSTEM and it doesn't work. I conclude that my system is no 
> longer a virgin.
> 
> Not sure what that makes it.
> 
> Peter 

:-)

Try the procedure I mentioned (saying "no" to "proceed with startup").

paul

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

Re: [Simh] Getting started with RSTS - unknown password

[Paul Koning]

> On Oct 9, 2019, at 4:38 PM, Wilm Boerhout  wrote:
> 
> I believe the 1,2 password is “system” on a virgin system. 

No, it's supplied during system build.  At least since V4 -- I think V3 and 
earlier may have had fixed default passwords.

paul

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

Re: [Simh] Getting started with RSTS - unknown password

[Paul Koning]

> On Oct 9, 2019, at 4:24 PM, Peter Allan  wrote:
> 
> While I have been playing with running VMS on simulated VAXen, and RT-11 and 
> RSX-11M(+) on simulated PDP11s for many years, I have never tried RSTS on a 
> PDP11 - until now.
> 
> I have found installation tapes on rsts.org, but I also have a pre-built 
> system that I downloaded in January 2018 that I was hoping to start with. I 
> can't recall where I got it from.
> 
> The file name that I downloaded is RSTS_V10.1.zip and the contents of the zip 
> file are:
>   RQDiskV10_1.DSK
>   rsts_1193.ini
> 
> ...
> 
> Also, does anyone know how to get into a RSTS system when you have forgotten 
> the system password? Is this even possible? I know how to do it on VMS, but 
> RSTS is completely new to me.

Boot the system and start the OS.  Sufficiently recent versions will prompt 
"Proceed with system startup?".  Answer NO.  You'll be dropped into the DCL 
prompt, and you're logged in as user [1,2] with all privileges.  You can now 
change the passwords to be whatever you want.  Use the "set password" command 
to change the [1,2] password, or supply the account id -- like [42,17] as the 
argument on that command to set some other account's password.

No, you can't read the passwords, they are hashed.

For older versions (V8 and before) the story is different.  There the passwords 
ARE readable.  Older versions don't have a "Proceed" prompt, they typically go 
right into the startup sequence without asking, after you do the "START" 
operation in INIT.  But it works by simulating keyboard input to the console 
terminal, and you can disrupt that by leaning on the control-C key during the 
process.  It may take a few tries.

Once you're in, RUN $MONEY and in the dialog, tell it you want passwords 
printed.

Curiously, those old systems don't have a password change utility, though there 
does exist a syscall to perform that operation.

I should add support for these things to my "FLX" utility (a tool for 
manipulating RSTS disk images) but right now that isn't provided.

paul



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

Re: [Simh] Semi-OT: Terminal Recommendations for use with SIMH

[Paul Koning]

> On Sep 28, 2019, at 4:45 AM, Johnny Billquist  wrote:
> 
> xterm also on Mac for me.
> 
>  Johnny

I probably don't push things as much as some others, but I find that the stock 
terminal window on Mac works fine.

paul


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

[Simh] Fwd: VAX + Spectre

[Paul Koning]

"Spectre" is one of two notorious bugs of modern CPUs involving speculative 
execution.  I rather doubt that VAX is affected by this but I suspect others 
here have a lot more knowledge.

paul

> Begin forwarded message:
> 
> From: co...@sdf.org
> Subject: VAX + Spectre
> Date: September 17, 2019 at 5:32:42 AM EDT
> To: port-...@netbsd.org
> 
> So, this is a bug report:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86811
> 
> GCC would like to know if VAX needs Spectre-related work.
> Are any of the VAXes ever made capable of speculative execution? the
> first tech for doing it was in 1967, so not entirely far-fetched.

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

Re: [Simh] [simh] IBM open sources PowerPC

[Paul Koning]

> On Aug 29, 2019, at 11:27 AM, Nelson H. F. Beebe  wrote:
> 
> Two days ago, this posting appeared on the Electronic Engineering
> Journal Web site:
> 
>   IBM Gives Away PowerPC; Goes Open Source
>   Want to Design Your Own 64-bit RISC Processor on the Cheap?
>   
> https://www.eejournal.com/article/ibm-gives-away-powerpc-goes-open-source/
> 
> That may be of interest to any list reader who works with software
> simulation of that architecture.
> 
> It adds PowerPC to OpenSPARC and RISC-V as `user-implementable' CPU
> architectures. 

Neat.  Is MIPS also in this category or am I remembering wrong?

paul


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

Re: [Simh] The Missing PDP-8s

[Paul Koning]

> On Aug 13, 2019, at 12:25 PM, Richard Cornwell  wrote:
> 
> Hi Bob,
> 
> 
>> ...
>> I looked at a PDP-12 implementation. It's not hard, but I really
>> didn't want to do Yet Another DECtape Simulator for Linctape. With
>> Rich Cornwell's recent work, it's clear that the DECtape controllers
>> should have been abstracted to a library ten years ago, but doing so
>> would be a major PITA, now that there are six (at least) distinct
>> implementations (PDP1, PDP18b, PDP11, PDP8 TC, PDP8 TD, KA10).
> 
>   I am more then willing to switch to a generic library. What would be
>   nice to see is something that just gave you the actual tape frames.
>   This would also allow you to format the tape. If you write it I will
>   gladly switch to it. Most of KA10 code is from your other simulators.

That would be neat.  The formatter program would be one good testcase.  Another 
one, a rather tricky one, would be RT11 FILEX reading PDP-10 DECtapes.  That 
one is strange because it doesn't used read-all as you would expect; instead it 
does a regular read and picks up the upper 2 bits from one of the CSRs as the 
words fly by.  So for that to work you'd actually have to emulate the behavior 
of the word by word data transfer during DMA.

paul

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

Re: [Simh] The missing PDPs

[Paul Koning]

> On Aug 12, 2019, at 10:17 PM, Johnny Billquist  wrote:
> 
> ...
> The PDP-12 poses a more interesting problem, as it is a dual CPU thingy with 
> shared memory and two totally different instruction sets, but some 
> interaction between them...

I've never programmed one but I have a handbook somewhere, so from that memory: 
it's not a "dual CPU" in the usual sense of two separate engines running in 
parallel, interconnected by memory or by I/O channels.  Instead, it's more like 
compatibility mode in early VAXen, where you can flip between two instruction 
sets through a mode control.  So the basic structure of a SIMH cpu simulation 
is unaffected; what changes is that there are two sets of opcode interpreters.

The I/O devices are also different; LINCtape is physically very similar to 
DECtape but the programming interface is rather different (significantly more 
advanced -- if I remember right, it will search for the requested block for you 
rather than putting that job in the driver software).

paul

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

Re: [Simh] EXT :Re: Issue #731 - simh PDP11 RSX11M-PLUS Unibus 11/94 system with 2 DEUNA ethernet device XUB not working

[Paul Koning]

> On Jul 31, 2019, at 1:34 PM, Geoff Conway  wrote:
> 
>> ...
> 
> There is a reason for mentioning the OS side of things and while in the real 
> world the majority of PDP11 peripherals are set by switchpacks on the cards 
> (been there done that) - the device code for that peripheral (if it's 
> intelligent?) would (presumably) read those register values and load them 
> into itself so it knows what addresses to respond to. In sysgen/netgen 
> (whichever being relevant) the CSR/vector values for every peripheral are 
> then manually entered by a human and the system/DECNet built.

That depends on the OS.

I think most OS know the floating CSR rules and use that to identify the 
devices; you specify CSRs manually only if your address settings don't conform.

Similarly with vectors: the OS may implement the float vector rules to compute 
the vector addresses for the devices.  Or it may do what RSTS does, which is to 
"poke" each device at boot time to make it interrupt, then remember what the 
vector address was.  So RSTS requires float CSRs in order to autoconfigure 
devices but doesn't mind what the vectors are so long as they are all unique.

> ...
> The 3 exceptions are all the 3 devices I included in my simh qbus 
> configuration and when I entered the "show dev" command prior to booting the 
> OS disk all of those simh devices had CSR values but no vectors - devices 
> DEQNA=XQ/XQB; KDA50=RQ/RQB and finally TK50=TQ.
> Prior to entering the OS they had  against them and after the OS 
> was booted into a fully configured system and then finally shutdown those 
> same 5 simh device then had their vectors assigned.
> 
> Why ?

After reset, the vector address is not set.  Once the OS programs the vector 
address by appropriate commands to the device, it remains in effect until 
cleared.  Shutdown (on the OS you are using) apparently doesn't do a reset so 
the vector remains set to what the OS assigned.

> ...
> Other cards I have experience of (ACC X.25 card) I believe also had 
> programmable vectors (yet to be confirmed) so while that mechanism certainly 
> won't be in an older card like the DEUNA it is in the newer 

For SIMH purposes the discussion is about DEC peripherals: for those the three 
mentioned are the only ones with programmable vectors.  Sure, the idea makes a 
lot of sense in newer devices and it's not surprising that some non-DEC boards 
would have adopted the same feature.

paul

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

Re: [Simh] Issue #731 - simh PDP11 RSX11M-PLUS Unibus 11/94 system with 2 DEUNA ethernet device XUB not working

[Paul Koning]

I haven't tried 2 UNA at all, and don't know RSX, but one thing to watch out 
for: don't put two Ethernet interfaces on the same LAN if you're running DECnet 
(Phase IV).  The reason is that they will both set the same Ethernet address, 
from the DECnet node address, so you have a duplicate address condition.  If 
both are connected to the same LAN segment this will make for a mess; if they 
are connected to different segments of a switched Ethernet then many packets 
will be lost as the switches keep changing their mind about where that address 
is located.

paul

> On Jul 26, 2019, at 11:26 PM, Geoff Conway  wrote:
> 
> Hi All,
>  
> I have just raised an Issue in simh #731 where when recent testing with a 
> simh PDP11/94 Unibus system with 2 DEUNA interfaces it was found that device 
> XUB did not initialize. Device XU worked normally. I have not yet been able 
> have XUB start fully – no matter what CSR/VEC combination I have tried. I 
> believe the current CSR & VEC are correct as they have been assigned – just 
> that there appears some internal disconnect within the XU driver where XUB 
> channel just does not do anything.
>  
> In the equivalent simh PDP11/93 Qbus system with 2 DEQNA both XQ, XQB worked 
> normally.
>  
> The details of the actual system configuration is in the Issues log. With the 
> absence of any messages from XUB it appears to be dead in the water – 
> although when running the simh environment with DEBUG enabled in both XU, XUB 
> I found that XUB stayed in xu_process_local() while the XU device had a lot 
> of activity – which was expected since XU was working normally whereas XUB 
> was not.
> Unfortunately as I am not familiar with the XU driver code I have not been 
> able to determine why the xub interface is not initializing correctly.
>  
> Regards
>  
> Geoff
> ___
> 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] PDP11 microstore

[Paul Koning]

> On Jul 1, 2019, at 8:11 PM, Bob Supnik  wrote:
> 
> The PLA scheme (another invention from the fertile mind of Bill Roberts, 
> architect of the LSI11 and UDA50 proto and founder of Emulex) was basically a 
> microcode and gate conservation scheme. It provided enormous compression for 
> the decode phase of the PDP11 and then got exploited to a fare-thee-well by 
> clever microcoders like Burt Hashizume (F11) and Keith Henry (J11).

Using logic to represent what you might think of as a table of values (a ROM) 
appears in other places too.  The CDC 6000 series console display, from 1964, 
has tables of stroke data.  Those are documented as lists of 5 bit data, up to 
23 rows for each character, 45 character codes total.

In the later 170 series controller this is indeed done in a ROM, but the 6000 
series controller used discrete transistor logic and a ROM wasn't a possible 
option then (not when a new value was needed every 100 ns).  So instead it uses 
a rather large tree of gate logic to produce the data.  Large as in roughly 130 
"cordwood" plug-in modules, each with 30 or so transistors on them.

paul

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

Re: [Simh] Which PDP-11 to choose

[Paul Koning]

> On Jul 1, 2019, at 5:09 PM, Seth J. Morabito  wrote:
> 
> 
> Lars Brinkhoff writes:
> 
>> Bob Supnik wrote:
>>> The J-11 based simulators (11/73 and up) are the only ones that were
>>> verified against actual machine microcode.
>> 
>> Speaking of which.  Someone claimed SIMH wouldn't be well suited for a
>> microcode level simulation.  Is there any truth to this?  If so why?
> 
> An interesting question! It's true that none of the simulators currently
> do microcode simulation, but I don't see why they couldn't. Certain
> assumptions about clock calibration may be in question, but I'm not
> sure. Even if they were, I think it's a surmountable problem and not
> fundamentally impossible given SIMH's architecture.

I can see no theoretical issues, but a number of practical ones.

("In theory, there is no difference between theory and practice. But, in 
practice, there is." -- Jan L.A. van de Snepscheut)

The programmer ISA is usually well documented, minimally in programmer's 
manuals and sometimes in formal standards.  The micro-architecture is 
documented in internal design specs that often have not survived and may not 
have been updated to reflect the actual design as shipped.  

Schematics and ROM contents, if accurate, may help but are not sufficient if 
parts of the micro-architecture are buried inside chips whose internals are not 
exposed in those documents.

Micro-architectures typically are done separately for each product, so a given 
family (like PDP-11 or VAX) might have a dozen vastly different ones.

Micro-programs are often very wide and directly manipulate many low level 
controls.  So a micro-architecture simulator would be a whole lot more 
complicated than the ISA simulator (and as a consequence much slower).

If the micro-architecture simulation is accurate, it would give an accurate ISA 
simulation.  But then again, if it's possible to build an accurate simulation 
one might as well put the effort into making the ISA simulation accurate.

---
An analogous case comes to mind.  It's possible (and has been done) to build a 
VHDL model of a PDP-11.  That's a separate design, just as SIMH is, and both 
may have discrepancies from the original hardware.  If you have enough detail 
you could build a VHDL model of the original design, which might be interesting 
-- for example, it would allow you to explore undocumented aspects of the 
machine operation.

I've actually done this (in part, the work is not nearly complete) for the CDC 
6600.  For that machine, full transistor-level schematics exist, so a gate 
level accurate VHDL model would seem to be possible.  It's actually 
surprisingly hard mostly because in that machine timing is on the hairy edge of 
not working -- you must simulate the gate delays to come even close, and some 
of the wire delays.  If you do so then easy parts like the peripheral 
processors work, but harder parts like the instruction scheduling machinery are 
so "on the edge" that they stubbornly refuse to work.

I suppose translating, say, PDP-11/20 or EL-X8 schematics to gate level VHDL 
models would be possible.  Whether anyone would find it worth the trouble is 
another question.

paul



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

Re: [Simh] RP/RM differences in header commands (for ITS, salvager)

[Paul Koning]

> On Jun 28, 2019, at 3:07 AM, Johnny Billquist  wrote:
> 
>> From a hardware point of view, sector header "Word 3" and "Word 4" have
>> no particular meaning.  Just for completeness, can you point me to a
>> reference where "pack number" is defined or used by the software?
> 
> Search for DEC standard 144. If nothing else, I think there is a description 
> in the RL11 documentation. (Me trusting my memory once more...)

That's different, though.  It describes the bad block table, which includes a 
pack serial number in its header.  Some device types use 144, some do not (in 
particular, on RP/RM there is a mix -- RP04/5/6 do not, RP07 and RM02/3/5/80 
do).  The 144 table is purely a software construct, a bit of data placed by 
convention in the last few sectors of the drive and interpreted by the OS.  For 
example, in RSTS the bad block table is read to mark those blocks as 
unavailable, and the serial number is read and displayed during formatting but 
not otherwise used for anything.

paul


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

Re: [Simh] The Interconnect Task Force

[Paul Koning]

> On Jun 25, 2019, at 7:42 PM, Bob Supnik  wrote:
> 
> The RC25 (code named Aztec) got started as I was leaving Storage Engineering. 
> ...
> 
> The RC25 was pretty much a disaster, technically and financially, and the end 
> of the line for DEC's removable disk program. 

It was quite ugly, because you had two drives on one spindle.  RSTS was told to 
support an RC25-only config, apparently for use in Royal Navy submarines (space 
constrained, obviously).  The trouble is that removing the removable pack meant 
spinning down the system unit (boot drive).  RSTS was never designed for that 
and would get very unhappy.  We hacked this by basically putting a system 
freeze feature in that would let you freeze everything while the drive was off.

paul


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

Re: [Simh] Origins of MSCP

[Paul Koning]

> On Jun 25, 2019, at 11:43 AM, Bob Supnik  wrote:
> 
> True. My first assignment at DEC was managing the "New Disk Subsystem" (NDS) 
> advanced development project, which led eventually to both the HSC50 and the 
> UDA50. Among the goals of the project were
> 
> 1. To move ECC correction off the host and into the disk subsystem, so that 
> much more powerful and complex ECC codes could be used.
> 2. To move bad block replacement off the host and into the disk subsystem.
> 3. To provide a uniform software interface for radically different disk 
> drives.
> 4. To abstract away all device geometry information.
> 5. To implement command queuing and to perform all performance optimization, 
> particularly seek optimization, in the disk subsystem.

#2 was only partially true in the UDA50 -- I remember an amazingly large body 
of code in RSTS for bad block replacement for the RA80 that's about 2000 lines 
of code -- roughly the same size as the rest of the MSCP driver.

I remember MSCP as part of the larger "Interconnect Architecture" effort, which 
produced a range of "interconnects" some of which seemed to become real and 
some less so.  There was the new peripheral bus (BI), the cluter interconnect 
(CI, computer interconnect) and one or two others.  I vaguely remember II 
(Interchip Interconnect) -- did that become I2C, or something else, or nothing? 
 And DI (device interconnect) ???  Also NI, which became Ethernet.  And XI?  I 
think we used that term in the networking group for the next generation high 
speed network.  Gigaswitch?  FDDI?  Not sure.  Part of the impression I had was 
that there was some overall concept unifying all this, but whether that was 
actually realistic is not clear.

One place it showed up was in the Jupiter mainframe (which didn't happen), 
supposedly built around CI and NI as its connections to the outside world.

There's also XMI, but that was a generation later as I recall.
paul


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

Re: [Simh] Limits on MSCP controllers

[Paul Koning]

> On Jun 24, 2019, at 5:27 PM, Timothe Litt  wrote:
>> 
> As is often the case, things turn out to be complicated.  Here's a more 
> detailed version.  In an off-list note, Bob pointed out that MSCP originated 
> in a project he managed that was to develop the "next generation" disk 
> controller - a forerunner of the UDA.   ...

> However the similarities came to pass, I found viewing DSA as an evolved 
> Massbus to be a useful model, with a lot of support for that perspective in 
> the specifications.  MSCP contains the high-level protocol of Massbus drivers 
> (and much more) through the drive control logic/formatter.  SI replaces the 
> DCL/formatter to drive "bus" of Massbus -- SI is serial, ruggedized and 
> capable of quite long runs.  But it carries much the same low level drive 
> commands.  (Note that there's a long history of serializing parallel buses as 
> technology evolves, e.g. PCI -> PCIe -> CSI, a.k.a. quickPath). The host 
> ports (UQSSP,KLIPA,etc) replace the registers and DMA channels.  Command and 
> function names from Massbus spec & drivers often appear in the MSCP spec 
> versions that I used... 

Very interesting.  I never thought of MSCP as a descendant of earlier DEC 
storage architectures.  Perhaps because all I really saw was what the UDA50 
exposes, which from the programmer's point of view is radically different from, 
say, the RP04 or RK05.

On the host ports and message based I/O, that same approach appears earlier in 
the KMC11 and its derivatives such as the DMC11 network controller.  Were those 
an influence on the message based host port design?

paul

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

Re: [Simh] VAX emulator slow to configure extra disks

[Paul Koning]

> On Jun 23, 2019, at 4:44 PM, Mark Pizzolato  wrote:
> 
> ...
> As Tim mentioned, some of the hardware that is modeled did indeed 
> allow arbitrary unit numbers (via plugs on the drive).  
> 
> Some 14 months ago support was added to provide per drive Unit plug 
> values to be set.   This is set via:
> 
>sim> SET RQn UNIT=plug
> 
> plug can be any value from 0 thru 65534.  Default unit plug for each 
> RQn is n.

I know of 8 bit unit number plugs, in the RA series drives.  I haven't run into 
16 bit unit numbers.

Some operating systems may limit the supported numbers.  For example, RSTS 
allows unit numbers 0 to 15 for MSCP disks.  And it supports multiple MSCP 
controllers, but the unit numbers must be unique -- unlike VMS which allows 
DUA0 and DUB0.

paul


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

Re: [Simh] Vax.exe emulator and Multinet network configuring

[Paul Koning]

> On May 9, 2019, at 7:55 PM, Johnny Billquist  wrote:
> 
> On 2019-05-10 01:46, Paul Koning wrote:
>>> On May 9, 2019, at 3:20 PM, Hittner, David T [US] (MS) 
>>>  wrote:
>>> 
>>> (It's been a long time since I've played with SMAC on wireless. I did get 
>>> it to work, but it wasn't worth the pain to me, so I upgraded to DECNET/OSI 
>>> non-compatibility mode.)
>>> 
>>> IIRC, when you start DECNET IV, it sends a broadcast packet to see if there 
>>> is an address collision with the hard-coded DECNET IV address before it 
>>> changes the MAC to the DECNET IV MAC.
>> That's not in any DECnet standard.  It may be someone did that, and it 
>> wouldn't be a bad idea to do so.
>> BTW, some NICs allow enabling multiple individual addresses and choosing 
>> which one you want.  DEC made that standard fairly early on, once it became 
>> clear that combining LAT and DECnet on a single interface was a pain.  DEUNA 
>> doesn't do this, DEQNA does, and all the DEC single-chip Ethernet interfaces 
>> support it.  On such interfaces you'd use the aa-04 address for DECnet and 
>> the "hardware address" for other things.
> 
> Hum? My understanding is that the DEUNA and DELUA works exactly the same in 
> this aspect. And combining DECnet and LAT is not a problem on of those 
> interfaces, so now I'm curious what you are thinking of?
> 
> Also, at least under RSX, all software is definitely using the same MAC 
> address for any and all network protocols you might be running, which 
> includes DECnet, LAT, MOP, IP, ARP, and anything else you might want to throw 
> at it.

That's certainly allowed, but as I said, most DEC NICs allow you to avoid the 
DECnet address for other protocols.

The difficulty was with VMS, which would start LAT before DECnet and use the 
hardware address for LAT if the individual address hadn't been overridden.  So 
your sessions would fail because the address would change.  The solution, with 
the DEUNA, was either to start LAT after DECnet, or to teach VMS the DECnet 
address via some other system parameter so it would be set at boot time, not 
wait until DECnet startup.  The multiple individual address feature was made a 
standard part of the DEC Ethernet architecture so you wouldn't need to do any 
of this; if a protocol needed a specific format address it could just use it, 
without bothering other protocols on the same machine.

paul

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

Re: [Simh] Vax.exe emulator and Multinet network configuring

[Paul Koning]

> On May 9, 2019, at 3:20 PM, Hittner, David T [US] (MS) 
>  wrote:
> 
> (It's been a long time since I've played with SMAC on wireless. I did get it 
> to work, but it wasn't worth the pain to me, so I upgraded to DECNET/OSI 
> non-compatibility mode.)
> 
> IIRC, when you start DECNET IV, it sends a broadcast packet to see if there 
> is an address collision with the hard-coded DECNET IV address before it 
> changes the MAC to the DECNET IV MAC. 

That's not in any DECnet standard.  It may be someone did that, and it wouldn't 
be a bad idea to do so.

BTW, some NICs allow enabling multiple individual addresses and choosing which 
one you want.  DEC made that standard fairly early on, once it became clear 
that combining LAT and DECnet on a single interface was a pain.  DEUNA doesn't 
do this, DEQNA does, and all the DEC single-chip Ethernet interfaces support 
it.  On such interfaces you'd use the aa-04 address for DECnet and the 
"hardware address" for other things.

SIMH can do this just fine given that the Ethernet libraries it uses can do it.

paul


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

Re: [Simh] Vax.exe emulator and Multinet network configuring

[Paul Koning]

> On May 9, 2019, at 3:15 PM, Henry Bent  wrote:
> 
> There is such a thing as promiscuous mode for 802.11, though its usage is 
> generally considered to be for harmful purposes and I don't think a 
> discussion of it here is appropriate.

It's no more inappropriate for Wifi than it is for 802.3, in my view.

paul


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

Re: [Simh] More VAX Simulators

[Paul Koning]

> On May 3, 2019, at 3:52 PM, Johnny Billquist  wrote:
> 
> That came across wrong...
> 
> Flow control would most certainly help, however, when running in a simulator, 
> with a terminal window, connected to the system, there is actually no flow 
> control available, so you will loose data.

Why would there be no flow control available?

Flow control is part of the protocol, no different from escape sequence 
parsing.  If a terminal emulation receives a control/S from the host, it should 
stop sending characters to the host.  For that to be meaningful, the "off" 
action has to happen close enough to where the characters are picked up by the 
driver that you don't get the simulator equivalent of "Fifo overrun" but that 
is not hard to arrange.

If the emulation currently doesn't do this, forcing the character rate down to 
"really slow" should be an adequate workaround.

paul

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

[Simh] RSTS V10.1 doesn't like QNA

[Paul Koning]

I never realized that the SIMH xq device defaults to LQA-T, so I just booted a 
RSTS 10.1 system with xq set to DEQNA mode.

RSTS is unhappy:

Device XH0: internal micro-diagnostic failure, code 001004 - device disabled.

I'll dig into that, but does this ring any bells with anyone?

paul

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

Re: [Simh] Help with loading vax82b zip file into simh/vms

[Paul Koning]

> On Apr 4, 2019, at 6:57 PM, Johnny Billquist  wrote:
> 
> On 2019-04-04 22:21, Paul Koning wrote:
>> That looks like standard RMS:VAR records, implied carriage control.  That 
>> means: each line is preceded by a 2 byte little endian length, and line ends 
>> are not actually in the file but implicit between each line.
> 
> No. It looks a little more complicated than that.
> It's certainly variable length records as you say. However, after the size is 
> the record number, and after that comes the data.
> 
> Relative file with variable length records maybe?
> 
>  Johnny

You're right, I misread words as bytes.  I don't believe relative files have 
record numbers.  VFC file?  I don't have much exposure to those, they are a VMS 
invention not seen on PDP11s that I can recall.  I seem to remember a 
particular VFC type used for listing files, where the fixed prefix is a line 
number.

paul

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

Re: [Simh] Help with loading vax82b zip file into simh/vms

[Paul Koning]

That looks like standard RMS:VAR records, implied carriage control.  That 
means: each line is preceded by a 2 byte little endian length, and line ends 
are not actually in the file but implicit between each line.

paul

> On Mar 26, 2019, at 5:54 PM, Ron Young  wrote:
> 
> Hi All:
> 
>   I want to load some programs from the vax82b decus "tape" into my
>   simh/vax/vms 7.3 system. VMS is installed and running.
> 
>   I normally would download the tape image and mount it in simh/vms and
>   copy/restore. Unfortunately, I can't find any tape images for vax82b.
>   There are zip files located on
>   https://eisner.decus.org/repository/master/vms/library/.
> 
>   However when I ftp the files over to vms, the record type is messed up
>   (displays 2 bytes of "garbage" and doesn't see the end of line). Looking
>   at a linux dump of the first couple of lines (shown below).
> 
>   Any ideas on how I can fix this, or where tapes images are located?
> 
>   thanks
>   -ron
> 
> 
> $ od -ao --endian=little apl.v30 | more
> 000   , nul soh nul  ht   P   R   O   G   R   A   M  sp  sp  sp  sp
> 54  01  050011  047522  051107  046501  020040  020040
> 020   a   p   l  sp   !   !   V   e   r  sp   3   .   0   ,  sp   F
>070141  020154  020441  062526  020162  027063  026060  043040
> 040   a   l   l  sp   1   9   8   2  sp   D   E   C   U   S  gs nul
> 066141  020154  034461  031070  042040  041505  051525  35
> 060 stx nul   c   +  ht  ht   M   a   i   n  sp   A   P   L  sp   d
> 02  025543  004411  060515  067151  040440  046120  062040
> 100   r   i   v   e   r  sp   p   r   o   g   r   a   m nul eot nul
> 064562  062566  020162  071160  063557  060562  000155  04
> 120 etx nul   c   ;   , nul eot nul   c   ;  ht   I   n   i   t   a
> 03  035543  54  04  035543  044411  064556  060564
> 
> ===
> Ron Young r...@embarqmail.com
> ___
> 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] Multiple sim_video windows?

[Paul Koning]

> On Mar 15, 2019, at 2:03 PM, Lars Brinkhoff  wrote:
> 
> ...
> 
>> It certainly is beyond the scope of the current sim_video which covers
>> display graphics and Human Interface details (mouse, keyboard, tablet,
>> etc..).
> 
> Oh, there's support for tablets?  I'll look into that!

In all the systems I've used in the past, from VWS onward, a tablet has always 
been treated exactly like a mouse.  The interface is absolute rather than 
delta, but by the time the inputs make it to the program they are expressed as 
absolute coordinates for either device.  Is there something unusual about 
tablets on this system that make this mouse-like model not work?

paul

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

Re: [Simh] Multiple sim_video windows?

[Paul Koning]

> On Mar 15, 2019, at 12:52 PM, Mark Pizzolato  wrote:
> 
> On Wednesday, March 13, 2019 at 1:40 AM, Lars Brinkhoff wrote:
>> I'm using the upcoming SIMH KA10 simulator to restore MIT's Incompatible
>> Timesharing System.  This is a multiuser system.  As such, there is a need 
>> for
>> multiple user interfaces.  The AI lab PDP-10 had many display and input
>> devices:
>> ...
>> I would like to be able to open up more windows: one for the color scope, and
>> perhaps another one for the tablet.  As far as I understand, sim_video is 
>> limited
>> to just one window.
> 
> Well, if there really were configurations which had software support that can 
> still be found today that actually drove multiple display devices 
> simultaneously then the current sim_video is certainly insufficient.  Adding 
> multiple video display window support is a project unto itself and dragging 
> the display layer along with it is added complexity.  If you want to do that, 
> feel free and I'll help when needed, but since your project is driving the 
> need I'm not sure we'll be getting a long list of folks willing to jump in as 
> well...

I thought that libSDL (which is what's underneath) is limited to one window.  
The documentation says that's not so.  That said, I found libSDL to be quite 
limited when I tried to use it to display emulated plotter output.  The problem 
there was that it's much bigger (pixel wise) than the screen and handling that 
was problematic.

I've used wxWidgets a lot for portable windowing applications.  I wonder if it 
might make an attractive alternate base for sim_video.

paul


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

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Paul Koning]

> On Jan 23, 2019, at 1:54 AM, Mattis Lind  wrote:
> 
> 
> 
> onsdag 23 januari 2019 skrev Brett Bump :
> 
> 
> On Tue, 22 Jan 2019, Paul Koning wrote:
> 
> On Jan 22, 2019, at 6:00 PM, Richard  wrote:
> 
> In article 
> ,
>Mattis Lind  writes:
> 
> I have some DEC EDU material which I can scan if there are interest (and if
> it isn't scanned already by someone else):
> 
> https://i.imgur.com/tqmcieK.jpg
> 
> I'd like to see this one about MINI-RSTS!
> 
> I remember seeing that before, quite possibly the same data sheet.  I never 
> heard of it while at DEC (in RSTS development).  Perhaps it was a short lived 
> early (V4 vintage) RSTS marketing exercise.
> 
> 
> paul
> 
> 
> Yes. I forgot that I already scanned that one. Here is the mini RSTS flyer in 
> full pdf. 
> 
> http://storage.datormuseum.se/u/96935524/Datormusuem/mini-rsts.pdf
> 
> Since the other documents are printed around 1972/1973 I guess that this one 
> is the same vintage. 
> 
> /Mattis
>  
> 
> Paul and I had this discussion before about 12 years ago on Wikipedia:
> 
> https://en.wikipedia.org/w/index.php?title=RSTS-11=history
> 
> I believe RSTS-11 V4A-12 was probably given the name Mini-Rsts-11
> by the marketing department (somewhat the same as MicroRSTS later).
> MicroRSTS was a pregenned distribution with exactly the same code
> that came on the distribution tapes, starting with RSTS/E V8.0-06.
> There are many references to MicroRSTS, but I have only seen 2 for
> Mini-Rsts (below is a link for our colleges RSTS-11 receipt).
> 
> http://www.rsts.org/images/minirsts.jpg
> 
> I know that this original distribution was V4A-12 so the name was
> probably dropped by the time RSTS/E V5A-21 was released eight (8)
> months later.
> 
> Brett

Interesting that there is no date on that document.  The term "RSTS-11" makes 
it clear we're talking about RSTS V4 or earlier.  For that matter, so does the 
hardware configuration: a boatload of DL11s for the user terminals rather than 
a DH11 or DZ11 mux, because V4 only supported single line interfaces.

It's not clear if this is V4 or an older version. 24kW memory is a minimal V4 
configuration, pretty marginal actually but possibly ok for 8 users max.  (In 
college I used V4A on a 28kW machine, 16 terminal lines, 16 users max though it 
tended to crash at around 12.)  The feature list doesn't mention some V4 
(optional) features like "record I/O" so it's possible this was actually V3.

I also found the term "PDP-11/21" interesting.  Has that been used anywhere 
else?  It's pretty clearly an 11/20 configuration.

paul


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

Re: [Simh] 101 Basic Games for RSTS/E (was Re: PDP11 on Simh for public access)

[Paul Koning]

> On Jan 22, 2019, at 6:00 PM, Richard  wrote:
> 
> In article 
> ,
>Mattis Lind  writes:
> 
>> I have some DEC EDU material which I can scan if there are interest (and if
>> it isn't scanned already by someone else):
>> 
>> https://i.imgur.com/tqmcieK.jpg
> 
> I'd like to see this one about MINI-RSTS!

I remember seeing that before, quite possibly the same data sheet.  I never 
heard of it while at DEC (in RSTS development).  Perhaps it was a short lived 
early (V4 vintage) RSTS marketing exercise.

paul

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

Re: [Simh] Enhancement Request: Additional Built-In Variable

[Paul Koning]

On Jan 10, 2019, at 1:56 PM, Robert W.Mills  wrote:
> 
> I don't know about the operating systems used by the other simulators
> but MPE V (used by the HP3000 simulator) is not Y2K compliant.
> 
> Is it possible to have a built-in variable, possibly called something
> like %DATE_YY_DIF%, that holds the difference between %DATE_19XX_YY% and
> the actual year as held by the host operating system? For example,
> %DATE_19XX_YY% is returning the value 91 for this year. In this case
> %DATE_YY_DIF% would hold 28 which is the difference.
> 
> %DATE_YY_DIF% could then be used to translate dates from internal
> (simulator) to external (user) by adding the value to the internal year.
> Translation from external to internal is just a matter of subtracting
> the value from the external year.
> 
> The need for this request would disappear if the HP3000 simulator could
> not use it.
> 
> David, is it possible to set a JCW with this value when a session starts?

There are plenty of operating systems we could run on SIMH that aren't Y2K 
compliant.  Some even have date issues earlier than 2000 (DOS-11 for example).

But I don't see how SIMH can help that.  Y2K is a software issue; SIMH is 
simulating the hardware.  How would SIMH know that some particular bit of 
output from the sofware is a date?

The one place where offsets might work is if the emulated hardware includes a 
calendar clock, for example as seen in some late PDP-11 models.  If so, one 
might imagine a SIMH variable that tells it to pretend the year is earlier than 
the real one.

paul


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

Re: [Simh] Quest from 1979 on RSTS/E V06C-03 in Simh (Brett Bump)

[Paul Koning]

> On Dec 30, 2018, at 4:07 PM, Brett Bump  wrote:
> 
> 
> (Reply excluding photos)
> 
> On Sun, 30 Dec 2018, Brett Bump wrote:
> 
>> 
>> Sorry Bob, that kit is a modified version which includes Paul's FORTH run
>> time system ...

With V6C?  Interesting.  I did that work around V9.0, though I don't remember 
if it was shipped with the kit at that time or only somewhat later.  It doesn't 
do any real magic so it seems that it should work.

It would be fascinating to find a copy of RSTS V5A and reconstruct the 
machinery (then totally undocumented and unsupported) for using additional 
runtime systems.  It was pretty ugly but it worked well enough to enable us to 
run TECO in 1975 at my college.

paul

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

Re: [Simh] Quest from 1979 on RSTS/E V06C-03 in Simh (Brett Bump)

[Paul Koning]

> On Dec 29, 2018, at 3:29 PM, Robert G. Schaffrath  
> wrote:
> 
> > Or you could grab the pre-genned V6C kit from:
> >
> > http://www.rsts.org/autoindex.php?dir=distros/RSTS_kits/=RSTS_V6C_Kit.zip
> 
> I tried booting that, and it does boot, but the startup does not run. No 
> system initialization is performed and I login as job 1 with no CCL's 
> defined. The version at https://skn.noip.me/pdp11/rk2.dsk does boot and has 
> all commands installed.
> 
> Looking at both environments there are two things I noticed as different from 
> the V06C-03 I was using in high school back in 1978. On our system we had 
> control-T available that was enabled and disabled along with control-R. ...
> 
> I have to wonder if we were running a version of V06C-03 with those 
> additional enhancements. It definitely was not 7.0. I graduated in June 1980 
> and I was told they upgraded to 7.0 that summer.

Control/T support was an optional feature, enabled during SYSGEN, for some 
time.  I'm fairly sure it was never an undocumented feature, but it wasn't 
standard originally.

paul

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

Re: [Simh] Reading PDP-15 and PDP-9 tapes

[Paul Koning]

> On Dec 20, 2018, at 7:40 PM, David Gesswein  wrote:
> 
> On Wed, Dec 19, 2018 at 02:31:47PM +0100, Pontus Pihlgren wrote:
>> Hi
>> 
>> But it just seems to loop over DECtape I/O-instructions.
>> 
>> Any suggestions to what I should be doing?
>> 
> Reading the OS/8 handbook I think it is only intended to transfer files
> and doesn't support copying entire devices.

Doing that on PDP-11 would be straightforward, using the RALL (read all) 
DECtape controller command.  That's programmed I/O, not DMA.  The DECtape 
formatter uses that (or WALL, which uses the same programming approach).  I 
haven't seen any standard utilities that do this, though.  The only thing that 
comes close is RT-11 FILEX, but while that handles TOPS-10 tapes (file 
structured, not raw) it doesn't do the 18-bit systems.  It doesn't actually 
matter much, but 16, 18, and 36 bit all use the same block size and block count 
(256 16/18 bit words, 578 blocks) while 12 bit layout has an entirely different 
block size and count.  But with SMOP you can handle any of these, as indicated 
by a compatibility table in the DECtape manual.

paul

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

Re: [Simh] Systems Engineering Labs (SEL) simh simulator available

[Paul Koning]

> On Dec 20, 2018, at 1:51 PM, Tom Morris  wrote:
> 
> On Wed, Dec 19, 2018 at 9:48 PM Paul Koning  wrote:
> 
> I may be missing something, but... why would you ask for a 32 bit compile?  
> If you want to create a kit that can run on old PCs, sure.  But for a local 
> build, the default makes more sense, whatever that is on the machine in 
> question.
> 
> In other words, it's hard to see why you'd have -m32 in the compiler switches.
> 
> One reason might be for code that's not 64-bit clean.
> 
> Tom

True.  But it's better and easy to fix such code.  Especially in SIMH which in 
some places actually requires 64 bit support, so making the whole thing 64-bit 
clean is a good thing.

paul

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

Re: [Simh] Systems Engineering Labs (SEL) simh simulator available

[Paul Koning]

> On Dec 19, 2018, at 7:54 PM, Mike Stramba  wrote:
> 
> I am running an old 14.04 Ubuntu system.
> 
> And I don't *think* I have the 32 bit "build libraries" installed (not
> sure, *nix  novice)
> 
> Anyway Jim sent me these instructions, which has me up and running :
> 
> In the Makefile for SEL32, there is an option line SEL32_OPT (line
> 1103) that has the -m option.  That is the option for 32 bit
> compile/build to GCC.
> 
> Mike

I may be missing something, but... why would you ask for a 32 bit compile?  If 
you want to create a kit that can run on old PCs, sure.  But for a local build, 
the default makes more sense, whatever that is on the machine in question.

In other words, it's hard to see why you'd have -m32 in the compiler switches.

paul

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

Re: [Simh] Transferring the licence file to the VAX emulator

[Paul Koning]

> On Dec 18, 2018, at 9:20 PM, Larry Baker  wrote:
> 
> My 2¢ from the Way Back Machine:
> 
> I don't know what programmer's used before Fortran.  But, all these OS/360 
> features (and, likely earlier IBM OS's) were accessible from Fortran, the 
> first commercially available high-level computer language.  Human input, 
> including source code, was typically typed onto an 80-column card with a 
> keypunch.  Such text "files" were read using 80 character "fixed-length" I/O. 
>  Also, in those days, disk sectors were not fixed lengths.  Think of them as 
> tiny strips of magnetic tape.  Just like tape, there is a physical record 
> written and read by the hardware—what is now called a sector for fixed-length 
> geometries—packed with embedded logical record(s) with a structure defined by 
> software. ...
> 
> I don't recall when or why fixed-sector disks began to be required, and by 
> which O/S's.  There would certainly have been a cost savings motive, both in 
> the device electronics, and in the attachments, which could be much simpler 
> than channel attachments.

"little strips of tape" is a good way to look at it.  I have the impression 
that this approach is specific to IBM.  Not that I know all the computer makers 
from that era.  But at least CDC had fixed size data-only sectors in the 6000 
series, that would be around the same time as the IBM 360.  Those sectors 
didn't contain 8 bit bytes and weren't a power of two in length, but they were 
fixed.  In theory the disk controllers could create other formats (the 
controller had something like channel programs to parse the sector layout) but 
that wasn't used in practice.

Come to think of it, the IBM 1620 also had fixed length sectors (200 digits in 
the model 1311, if memory serves).

There are some other variants around: the EL-X8 had disks with per-track 
selectable sector size, from a list of 6 or so choices (non-power of two 
multiples of 27 words).

paul

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

Re: [Simh] Transferring the licence file to the VAX emulator

[Paul Koning]

> On Dec 17, 2018, at 3:04 PM, Johnny Billquist  wrote:
> 
> Actually, VMS don't natively have any record terminators for text files.
> So lines terminated by CR, LF, CR+LF or whatever, are all wrong.

Huh?  For VMS, "native" is any file format that RMS32 supports.  In VMS V1, 
that means either fixed or variable length records, but sometime later 
stream-CR, stream-LF, and stream-CRLF record format support was added both to 
RMS32 and RMS11.

paul

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

Re: [Simh] Improved CRT simulation

[Paul Koning]

> On Dec 17, 2018, at 8:44 AM, Phil Budne  wrote:
> 
>> On 14 Dec 2018 at 09:24:42 -0500, Paul Koning wrote:
>>> On Dec 14, 2018, at 1:17 AM, Lars Brinkhoff  wrote:
>>> I'm entertaining the idea of improving the CRT display simulation in
>>> SIMH..
>>> 
>> .
>>> If you read the fine print in the 340 documentation, you'll find that an
>>> a point is .03"-.015" depending on the intensity, compared with the grid
>>> spacing .0091".
> 
> I created the XY display code that SIMH for the PDP-1 and Type 340
> displays (and is also used for TX-0).

Yes, I remember that -- your work inspired my analogous machinery for DtCyber.

> It's been my suspicion for a
> long time that a REALLY good simulation of the user experience would
> require MANY more pixels than I've ever had available to me (I don't
> yet own a 4K resolution display, and it looks like even that wouldn't
> be enough, see below).
> 
> xdpyinfo describes the laptop I'm writing this on as 96 DPI or
> 0.01042" which isn't very different from the 0.0091 grid spacing
> above, BUT simulating the 0.03 (low intensity) point size above with
> square pixels would require greater resolution to draw circular points.
> 
> A 204PPI 3840 x 2400 "4K" display only has enough resolution to draw a
> 1024x1024 area with "points" that are two pixels wide, and 2x2 points
> which just halves your resolution!  Unless someone who understands
> graphics (and visual trickery) better than I (which is hardly at all)
> can figure something out.
> 
> An "8K UHD" 7680 x 4320 resolution device could draw a 1024x1024
> raster with 4x4 "points" which I imagine with anti-aliasing might make
> it possible to draw "points" which look circular.

If you insist on round looking points, probably so.  But I find that a 1k wide 
emulated device on a "4k" display works fine.  My Mac laptop has a "retina" 
display, which is similar in pixel count if you go down to the physical pixels. 
 So I get 2 pixels per display position.  That plus the anti-aliasing I get 
from drawing dots as gaussian distributions, and position calculation in 
sub-pixel increments, makes for a pretty convincing looking display.

> I've also suspected that "high intensity" on the radar display tube
> that the Type 30 (PDP-1) and Type 340 displays used was more eye
> searingly bright than anything that "modern" 24-bit color can manage
> (which is only 256 levels of intensity for a given color).

I'm not so sure about that.  Displays tended to be pretty dim to preserve the 
screen, and the basic look was roughly bitonal.  Sometimes you'd see 
"intensified" display; the CDC console would do this for urgent messages or the 
like.  That simply involved plotting the text in question a couple of times, 4 
times I think.  My emulation shows that; the basic display is about level 120, 
so "intensified" saturates, and given the gaussian pixels it also spreads the 
outline a little exactly as on the original.

>> Not SIMH, but I wrote a CDC DD60 simulation for use with DtCyber that 
>> attempts to model the CRT and spot behavior.  It does that by computing a 
>> 2-D Gaussian intensity distribution around the spot center, then sums that 
>> into the saved screen pixel value (with saturation).  And then that value is 
>> decayed exponentially.
> 
> Paul,
> 
> What is the resolution of the DD60 display?  I seem to recall the CDC display
> used analog circuitry for letter forums, as opposed to drawing them with 
> discrete dots, as the DEC Type 340 does.

Pretty much.  The display controller sends the character origin as a 9-bit 
digital value (the D/A is in the display).  The character shapes are generated 
as digital sequences in the display controller, ending at a 3 bit D/A, whose 
output goes to the display.  The display takes those character shapes, applies 
a scale factor for the selected size, adds in the origin from the origin D/As 
in the display, and sends that to the deflection circuit.  The nominal 
character shapes are staircase waveforms, but the clock is 100 ns and the rise 
times of the circuits involved aren't a whole lot less than that, so the actual 
deflection voltages are smoothed a lot.  Exactly how remains a bit of a 
mystery; I've been trying to create a SPICE model of the DD60 that reproduces 
the letter shapes I can see in photos, so far without success.

paul

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

Re: [Simh] Transferring the licence file to the VAX emulator

[Paul Koning]

> On Dec 17, 2018, at 2:44 PM, Phil Budne  wrote:
> 
> Clem Cole wrote:
>>  In the old days, the idea of 'access
>> methods' was the natural ways OS's did I/O and RMS was VMS's answer.
> 
> Using RMS as the primary way to do file access was dain bramage unique
> (at DEC) to VMS, no? 

Not unique to VMS nor even to DEC.  There was RMS-11 in PDP-11 operating 
systems.  I have the impression that predated VMS, though I may be off a bit.  
RMS-11 always felt like an extension of FCS-11, the RSX file structure library 
that introduced such things as file attributes and variable length records.

But this stuff is much older.  RMS feels a lot like the various "access 
methods" IBM created in OS/360.  Fixed length records, variable length records, 
the notion of "spanned" records (records that cross block boundaries) and 
indexed files all appear in OS/360 well before VMS appeared.

I think similar stuff existed elsewhere.  CDC had record stuff in the 6000 
series mainframes, though that felt more like an add-on, one I never used.  But 
apart from that, they did have files with internal structure, called "records" 
and "files", rather different from what OS/360 did.  So the notion of a file 
being a lot more than just a vector of bytes is quite old.

One odd thing about IBM is that some of the access method mechanisms relied on 
hardware capabilities.  For ISAM files, you'd write the file data with key 
fields in each sector, and use the search for key match feature in the disk 
drives (to find the matching sector so long as you knew on which track to 
look).  That seems to be pretty unusual, though I've also seen it done by 
Electrologica in Holland in the mid 1960s.

paul


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

Re: [Simh] Transferring the licence file to the VAX emulator

[Paul Koning]

> On Dec 17, 2018, at 12:29 PM, Clem Cole  wrote:
> 
> The problem is the license manager code you are running into is expecting an 
> RMS file, not a Stream I/O.  In the old days, the idea of 'access methods' 
> was the natural ways OS's did I/O and RMS was VMS's answer.   Since today's 
> programmers tend to have grown up with C/C++/Java and stream I/O, you need to 
> think in terms of a programming 'Framework' that is inflicting some level 
> structure on the file.  FWIW: Stream style I/O and the STREAM-LF file format 
> was added to VMS to support VAX11/C, and normal programmers (correctly) 
> started to avoid RMS (it was funny how quickly the compiler runtime teams 
> abandoned RMS, but I digress).  But if the code was written assuming RMS 
> (which was all VMS had for many years), the files need RMS.

That's odd, I thought that (on VMS) you didn't have any choice about using RMS. 
 Well, not unless doing raw block I/O.

Stream is one of the formats supported by RMS, exactly as fixed and variable 
records (with prefix length) are.  Actually, stream comes in three flavors, 
depending on whether the record delimiter is LF, CR, or CR/LF.  RMS-11 also 
supports these, FWIW.

So unless license manager goes out of its way to enforce a particular record 
format for its input files, I would think it "should just work", RMS should 
read the on-disk format and deliver the records (lines) according to the 
encoding described by the file attributes.

Finally, one suggestion was to transfer the file by cut & paste into a VMS 
editor; in that case the record format is chosen by the editor when creating 
the file, and the fact you're pasting from a Unix system is not a factor.

paul


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

Re: [Simh] Improved CRT simulation

[Paul Koning]

> On Dec 14, 2018, at 1:17 AM, Lars Brinkhoff  wrote:
> 
> Hello,
> 
> I'm entertaining the idea of improving the CRT display simulation in
> SIMH.  As an example of what I'd like to see, consider these pictures.
> The first is from the Type 340 simulation, and the second is a frame
> from a film shot at the MIT AI Lab.
> 
> https://github.com/larsbrinkhoff/simh/issues/5#issuecomment-446859516
> 
> If you read the fine print in the 340 documentation, you'll find that an
> a point is .03"-.015" depending on the intensity, compared with the grid
> spacing .0091".
> 
> Does the SIMH video framwork support using shaders written in e.g. GLSL?

Not SIMH, but I wrote a CDC DD60 simulation for use with DtCyber that attempts 
to model the CRT and spot behavior.  It does that by computing a 2-D Gaussian 
intensity distribution around the spot center, then sums that into the saved 
screen pixel value (with saturation).  And then that value is decayed 
exponentially.

It works pretty nicely but it's expensive.  To make it acceptable, the letter 
shapes are precomputed, so they just have to be summed in at the correct 
offsets.  And the decay factor is 0.5 so it can be done as a 64 bit shift and 
mask on the pixmap.

All this was done with wxWidgets and its direct bitmap access.  It may be that 
video shaders or GL machinery would be more efficient but I haven't studied how 
to do that.

In this model, I use the "focus" control to set the width of the Gaussian 
distribution.  And there are X and Y factors to adjust the character height and 
width, just as on the original display.  It looks pretty good.  The only 
significant missing part is a good model of the X/Y display AC characteristics; 
currently the letter shapes are not as distorted as they were in the original.

paul


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

Re: [Simh] vax idle for NetBSD

[Paul Koning]

> On Dec 11, 2018, at 1:40 PM, Mark Pizzolato  wrote:
> 
> The simple test with the VAX simulator is to enable any OS form of idling and 
> boot the simulator.  While sitting at the ROM >>> prompt idle kicks in 
> precisely 
> as expected.  Similarly, when booting VMS, idling also occurs as expected.

I see it now on NetBSD, takes about 20 seconds from the time the OS goes idle 
(the login prompt).

Interesting that the boot prompt would idle, since that's not NetBSD...

Tried it on ELX8, I see roughly the same.  Tried "show -d idle" and it reports 
something plausible sounding:

idle enabled, stability wait = 20s, minimum sleep resolution = 1ms

I then continued, and noticed that the simulation goes CPU bound for 30 
seconds, then returns to idling.  Tried it again, same result.  Is that caused 
by the clock catching up?  Come to think of it, clock catchup is not all that 
useful for this system, is there a way to have the timekeeping be real 
simulation time only, so time at the SIMH prompt does not count?  The clock is 
used for scheduling etc. but not for timekeeping (not in any OS I have seen for 
that machine, anyway).

paul

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

Re: [Simh] vax idle for NetBSD

[Paul Koning]

> On Dec 11, 2018, at 12:01 PM, Mark Pizzolato  wrote:
> 
> ...
> Meanwhile, something else has changed relatively recently that doesn't 
> seem to actually execute this code when the system starts.  Specifically, 
> I just observed:
>  1) Boot NetBSD 8.0
>  2) Boot took 100 seconds to get to a "login: " prompt.
>  3) I would normally expect that the system was pretty much idle at this 
> point and the 100 seconds would have exceeded the 20 second calibration 
> window the idle code needs to have elapsed before the system actually idles.
>  4) The system ran for another 80 seconds before idling actually kicked in.
> 
> I have no idea what the system was doing during this 80 second period, but 
> that is not how things worked when the code above was initially added to the 
> NetBSD kernel.
> 
> It is good that eventually the above code is engaged, so we don't really need 
> to change anything else, but it would be interesting to understand what the 
> system is actually doing...
> 
> - Mark

I remember seeing unexpectedly long delays to idle in other simulators too.  
PDP11 quite reliably kicks into idle quickly, but on a simulator I'm working on 
(ELX8) which also has an explicit idle instruction it would take a minute or 
so.  The one difference I can think of is the clock period, 16 ms for PDP11 
(given simulated line clock) but 10 ms on ELX8.

paul

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

Re: [Simh] vax idle for NetBSD

[Paul Koning]

> On Dec 11, 2018, at 10:47 AM, Anders Magnusson  wrote:
> 
> Den 2018-12-11 kl. 11:11, skrev David Brownlee:
>> On Sun, 9 Dec 2018 at 09:42, Mark Pizzolato  wrote:
>>> Well, when I followed the directions you pointed out, I did see what you
>>> had reported.  A little deeper observation strongly suggested that the
>>> OS execution flow that happens on NetBSD/VAX during idling had changed
>>> from how things were working when I had worked through how to get things
>>> well behaved idling under simh.
>>> 
>>> I haven't yet had the time to look closely at the OS code to determine
>>> what exactly was happening.  If you're seeing things OK now, maybe, there
>>> is some sort of garbage collection activity going on, which runs for a while
>>> and then somehow eventually stabilizes to the known idle execution
>>> pattern.
>>> 
>>> NetBSD is the fundamental exception for operating systems running under
>>> simh due to the fact that it is still an actively developed and evolving
>>> operating system.  As a result, the idle detection pattern will always have
>>> to evolve along with the evolving OS.
>> That also cuts both ways (but in a good way :) - because it is still
>> under active development it is reasonable to tweak the code to work
>> better under simh (other ports like amd64, aarch64 and mips are
>> adjusted all the time to work better under qemu), so if there is a
>> better way for NetBSD to tag the idle loop, lets make it so :)
>> 
>> For anyone interested the current logic has:
>> 
>> int ipl = mfpr(PR_IPL);
>> mtpr(1, PR_IPL);
>> mtpr(ipl, PR_IPL);
>> 
>> Which looks to have been there since 2012 - see
>> https://nxr.netbsd.org/xref/src/sys/arch/vax/include/cpu.h?r=1.102#162
>> 
> Hm, the vax actually got a WAIT instruction in later versions of the hardware.
> It could be an idea to use it (and add code to catch it if not implemented).

The VAX architecture standard (DEC Std 032, from Bitsavers) mentions that as a 
virtual machine instruction that's trapped and handled by the hypervisor.  It 
doesn't sound like a real instruction, the way it is on a PDP-11.

paul


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

Re: [Simh] vax idle for NetBSD

[Paul Koning]

> On Nov 15, 2018, at 9:32 AM, Paul Koning  wrote:
> 
> I just installed NetBSD/VAX V8 on SIMH.  The documentation mentions "set cpu 
> idle=netbsd", but it doesn't work -- I'm stuck at 100% CPU.  
> 
> I'm running it on the microvax3900 simulator, if that makes a difference.  
> Any ideas?

Update: it's working now.  I had some configuration issues before with 
networking etc. but I don't see how that explains idle failure.  I know 
sometimes, in some simulators, it takes a while to get to idle, but I thought I 
had waited long enough.

In any case, this appears to be a false alarm and it does work correctly.

paul

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

Re: [Simh] vax idle for NetBSD

[Paul Koning]

> On Nov 15, 2018, at 10:21 AM, Mark Pizzolato  wrote:
> 
> Hi Paul,
> 
> On Thursday, November 15, 2018 at 6:32 AM, Paul Koning wrote:
>> I just installed NetBSD/VAX V8 on SIMH.  The documentation mentions "set
>> cpu idle=netbsd", but it doesn't work -- I'm stuck at 100% CPU.
>> 
>> I'm running it on the microvax3900 simulator, if that makes a difference.  
>> Any
>> ideas?
> 
> I thought this had gotten settled a long time ago.  
> 
> At one point, the BSD code that implemented what the OS does when there is 
> nothing else to do got changed from how things were done in earlier BSD 
> kernels.  The big change seemed to align with when SMP support was added to 
> the kernel to support other (non VAX) architectures.  This restructuring 
> created some platform specific routine which existed to do what was good on 
> that platform while idling.  As it turned out, what was initially implemented 
> in the VAX specific code that did that was operationally indistinguishable 
> from other code running elsewhere in the OS, and given that on those kernel 
> versions idling wasn't possible under simh.  Someone (I don't recall who) had 
> come along and complained about this and after explaining the issue, I 
> suggested that if the VAX specific routine were changed to do something that 
> wasn't done anywhere else in the OS simh idling support could once again 
> work.  When I was poking around, I observed that nothing in any BSD kernel 
> used IPL 1 for anything, so I suggested that the kernel idle routine could 
> set IPL to 1 could be an indicator that simh could detect and properly idle.  
> The party who had complained passed this suggestion back as a VAX platform 
> specific patch and it ultimately was included in the kernel and it worked for 
> subsequent versions.
> 
> Maybe this change has gotten removed from the VAX specific BSD code in recent 
> versions, or maybe something else is going on with your simh configuration 
> that is interfering with idling.
> 
> I can't find a VAX platform NetBSD 8.0 ISO image, or I'd have checked out 
> what is happening before writing this.  If you can make the disk image and 
> your configuration file available for me.  I'll explore the details and let 
> you know what is happening.

I just followed these instructions: 
http://www.netbsd.org/ports/vax/emulator-howto.html using the 8.0 image found 
via the link on that page.

paul


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

[Simh] vax idle for NetBSD

[Paul Koning]

I just installed NetBSD/VAX V8 on SIMH.  The documentation mentions "set cpu 
idle=netbsd", but it doesn't work -- I'm stuck at 100% CPU.  

I'm running it on the microvax3900 simulator, if that makes a difference.  Any 
ideas?

paul

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

Re: [Simh] Fixing the FP11's use of MMR1

[Paul Koning]

> On Nov 13, 2018, at 3:45 PM, Ethan Dicks  wrote:
> 
> On Tue, Mar 24, 2015 at 5:07 PM Bob Supnik  wrote:
>> This issue, pointed out by Johnny Billquist, has been hanging fire for
>> years.
>> 
>> Fixing the FP11's use of MMR1 - implementation proposal
>> 
>> As has been noted, the FP11 does not update MMR1, ever
> 
> This was very interesting and educational to read, but when does it
> matter?  Diagnostics?  Are there any live programs that depend on this
> behavior?

Interesting question.  FWIW, RSTS does not use MMR1.  It saves it in crash 
dumps but never touches it anywhere else.

paul

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

Re: [Simh] TINTE is not TECO either

[Paul Koning]

> On Nov 12, 2018, at 9:55 AM, Clem Cole  wrote:
> 
> BTW: My old friend and college, Paul Cantrell's Video Teco is still one the 
> best and most portable:  Video Teco ManualVideo Teco Sources

Speaking of portable -- as a language learning exercise I did an implementation 
of TECO in Python.  It includes screen handling as if running on a GT40.  One 
fun aspect is that the Python 3 version, naturally, treats text as Unicode 
rather than 8 bit text.

Maybe I should post it somewhere for others to play with.  It's not the best 
Python code, but it gets the job done.  I wish I could find the GT40 editing 
macros, though.

paul


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

Re: [Simh] TINTE is not TECO either

[Paul Koning]

> On Nov 10, 2018, at 8:12 AM, Lars Brinkhoff  wrote:
> 
> TECO for RT-11 and SITS.  (SITS was a timesharing system for the MIT
> Logo PDP-11/45.)

Regular TECO also exists for RT-11.  Is this one better?  Or just different?

paul

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

Re: [Simh] PDP-11 Spacewar?

[Paul Koning]

> On Nov 9, 2018, at 5:24 AM, Johnny Billquist  wrote:
> 
> On 2018-11-09 10:18, Lars Brinkhoff wrote:
>> Hello,
>> This seems to be a Spacewar for PDP-11.  Written using the PALX cross
>> assembler.  But what kind of display is it using?
>> https://github.com/PDP-10/its-vault/blob/master/files/rjl/war11.3
> 
> Suspect it might be this: 
> http://www.computerhistory.org/visiblestorage/1970s-1990s/games-and-robots/arcade/
> 
> CHM have one. Not sure exactly what display it used, but it's obviously a 
> vector display.

I don't think so.  Look at function LINE, it's a typical "step through the dots 
that make up a vector" algorithm.  Not Bresenham I think but something along 
those lines.

> Pretty fun to see something written for an 11/20 with EAE. That was a pretty 
> short lived option...

Does SIMH support EAE?

paul

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

Re: [Simh] disk file format (rk05)

[Paul Koning]

Disks are just sectors.  I think that's true generally; if SIMH supported any 
systems with variable length disk blocks something else would be needed, but 
the only system I can think of that does so is the IBM 360.  (Actually, that 
one is much stranger, with its keyed sector feature.)

Note that sector sizes may be 512, as for RK05, or something else.  RC11 has 64 
byte sectors, RF11 is word addressable.  And IBM 1620 has 200 digit sectors if 
I remember right.

paul


> On Sep 25, 2018, at 9:38 AM, Folkert van Heusden  wrote:
> 
> Hi,
> 
> Quick question: what is the file format (on the host system) of a PDP-11 RK05 
> disk? Just disk-sectors as-they-are? Or do they have headers like the magtap 
> file format? ( http://simh.trailing-edge.com/docs/simh_magtape.pdf )
> 
> 
> regards
> 
> -- 
> ___
> 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] PDP-11 MUL / DIV Bug

[Paul Koning]

> On Sep 18, 2018, at 10:35 AM, Ludwig TAUER  wrote:
> 
> Hi folks!
> 
> Seems I have found a bug in the PDP-11 emulating the
> MUL instruction.
> 
> The current code takes the specified register as source
> instead of the register pair R and R+1 if the register is even.

The current code is correct: mul takes 16 bit inputs, and delivers a 32 bit 
result if the register is even, the low 16 bits if it is odd.

> The DIV instruction is also invalid, but the other way around:
> if R is odd, R is duplicated into the high half of the 32 bit int.

Odd R for div is a strange thing to do.  I'm not sure what it is supposed to 
do, the manuals are not at all clear.  What do you believe is correct, and what 
document says so?

paul

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

Re: [Simh] Simulating power fail

[Paul Koning]

> On Sep 7, 2018, at 1:24 PM, Mark Pizzolato  wrote:
> 
> On Friday, September 7, 2018 at 10:12 AM, Paul Koning wrote:
>>> On Sep 7, 2018, at 12:37 PM, Mark Pizzolato  wrote:
>>> 
>>> On Friday, September 7, 2018 at 1:18 AM, Lars Brinkhoff wrote:
>>>> Timothe Litt wrote:
>>>>> Adding an API in the CPU of the form assert_powerfail( vector) - where
>>>>> the default is the usual 24/26, but a ROM can specify an alternate
>>>>> (usually its base address + 24/26). This is common to all initiators.
>>>> 
>>>> This touches on something else I have been thinking about.
>>>> 
>>>> Would it be appropriate to have a SIGTERM (and/or similar signals) trigger 
>>>> a
>>>> power fail in the PDP-11 and other simulators with corresponding
>>>> mechanisms?  SIGINT goes into the SCP console, and of course SIGKILL
>> instantly
>>>> switches off the simulated machine.
>>>> ...
>>> 
>>> Alternatively, I've got a simulator that's been running via a script in a
>>> background process for 10+ years.  The script it is running under receives
>>> one of these signals and that immediately drops out of sim_instr() and the
>>> script is configured to SAVE the simulator state to a file.
>> 
>> That's a fairly simple scripting exercise wrapped around SIMH.  You can catch
>> the signal, send control/E to get the sim> prompt, then suitable examine and
>> deposit commands to simulate a trap to 24.
> 
> SIGTERM and SIGINT already are caught in simh and when delivered they
> cause exit from simulator instruction execution and return to sim> prompt.
> No need for an extra wrapper or for sending control/E.

What I meant is that a wrapper can provide the controlled software shutdown, by 
talking to the software running in SIMH, and SIMH itself.  That way you can run 
the OS of your choice on the simulated machine of your choice, all nicely 
controlled from the host startup and shutdown machinery.

paul

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