HECnet

hecnet@lists.dfupdate.se

4 participants
15583 discussions

11/23 confusion, was Re: [HECnet] RSTS/E is really picky

by mcguire＠neurotica.com

On 05/20/2014 11:40 AM, Johnny Billquist wrote: My memory board is third-party. Looks like it's truncating my memory then. ;) Are you sure. Very few 11/23 systems actually exist. Most people really have 11/23+ systems, even if they are not aware of it. It's a dual-height board. I don't think it /can/ be an 11/23+! Doh! So you actually have a KDF11-AA (M8186). That sucks. I'm not sure if those were ever upgraded to 22-bit addressing, or if you need the KDF11-BA (M8189) for that. Oh well, so you might actually be stuck with 11M then. Ah, no. Nearly all dual-wide 11/23 CPUs (KDF11-AA, M8186) support 22-bit addressing. Etch revs A and B did not, but in practice there are very few of these out in the field. I have had probably a hundred KDF11-AA boards go through my hands over the years, and have easily thirty of them now, and have never seen a Rev A or Rev B board, nor have I ever known anyone who has. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

11 years, 5 months

QBUS sound [Was: Re: [HECnet] Parallel computing using DECnet]

by pontus＠Update.UU.SE

Hmm I've been on the lookout for a DTC01 for years. This is tempting... but I probably should get a PRO first :) /P On Tue, May 20, 2014 at 05:04:39PM +0000, lee.gleason at comcast.net wrote: If anyone out there is hankering to have one, a DEC PRO telephone Voice Unit is on Ebay right now. http://www.ebay.com/itm/NASA-Digital-DEC-DTC11-B-Voice-Unit-Professional-30… -- Lee K. Gleason N5ZMR Control-G Consultants lee.gleason at comcast.net ----- Original Message ----- From: "Billquist, Johnny" <bqt at softjar.se> To: "hecnet" <hecnet at Update.UU.SE> Sent: Tuesday, May 20, 2014 10:52:04 AM Subject: Re: QBUS sound [Was: Re: [HECnet] Parallel computing using DECnet] On 2014-05-20 17:39, Jean-Yves Bernier wrote: At 8:05 AM +0200 2/5/14, Pontus Pihlgren wrote: I've yet to see a PDP-11 with builtin color graphics _and_ sound. This one has both: http://www2.pescadoo.net/pdp/syter/grm2082.jpg The machine is a SMS 1000 OEM 11/73. Here is the mixer screen: http://www2.pescadoo.net/pdp/syter/INSTR2.GRA.png and the edit screen: http://www2.pescadoo.net/pdp/syter/INSTR5.GRA.png 512x512x8 frame buffer manufactured by Arinfo, France. Serial BitPad. Custom 4AD/8DA through DRV11. Discontinued. Of course... :-( Anyway, I just realized/remembered that I'm not sure if the PRO was ever mentioned in the context of PDP-11 with graphics and sound. The PRO obviously always have grahpics. But there was also a sound option to it, which could interface with telephone systems. Not sure exactly how capable it was, but I have some blurb in a handbook somewhere. Johnny

11 years, 5 months

RSX-11 setback

by b4＠gewt.net

Sent from mobile device that advertises itself for no good reason On 20 May 2014, at 13:59, Johnny Billquist <bqt at softjar.se> wrote: On 2014-05-20 19:47, Cory Smelosky wrote: Well, I'm just not having ANY luck with this... VMR @SYSVMR VMR -- *DIAG*-Partition reduced to executive common size INS EXCOM1 VMR -- *DIAG*-Partition reduced to executive common size INS EXCOM2 VMR -- *DIAG*-Loadable driver larger than 4K LOA TT: VMR -- *DIAG*-Installed tasks may no longer fit in partition SET /TOP=DRVPAR:-* POOL=1200:9644.:09644. (That bit is understandable. I must've configured it too big!) They are diagnostic messages, and many times totally expected and normal. Ahhh. The TT: driver is definitely expected. (I would be very worried if you did not get that one.) Same with the DRVPAR shrinking. It's a warning that is not important here, as you do not use DRVPAR for dynamic tasks anyway. Ah. The EXCOMn partitions are an 11M thing, but as far as I can remember they are also totally expected. boo [1,54]rsx11m SYSTEM CRASH AT LOCATION 014402 REGISTERS R0=000002 R1=120550 R2=000000 R3=120546 R4=120744 R5=031610 SP=117772 PS=020010 SYSTEM STACK DUMP LOCATION CONTENTS 117772 000004 001344 That is a very weird and unexpected stack pointer. RSX normally have the stack in rather low addresses. Wonder if it's related to the tape controller that isn't actually technically present. Not sure exactly what you configured, but maybe something wrong in all your answers... :-) I'll grab the log when back at my desk. After reboot: boo [1.54]rsx11m MCR -- Task not in system ins $boo boo [1,54]rsx11,\,\m [no output] I seem to be TERRIBLE and SYSGEN. Well, since the initial boot failed, any subsequent boots of that image I would expect to fail equally bad. It could have been unclean memory at some random address. This system also tends to randomly crash on first-time boots, too sometimes. A couple halts and it usually works then. Johnny

11 years, 5 months

RSX-11 setback

by bqt＠softjar.se

On 2014-05-20 19:47, Cory Smelosky wrote: Well, I'm just not having ANY luck with this... VMR @SYSVMR VMR -- *DIAG*-Partition reduced to executive common size INS EXCOM1 VMR -- *DIAG*-Partition reduced to executive common size INS EXCOM2 VMR -- *DIAG*-Loadable driver larger than 4K LOA TT: VMR -- *DIAG*-Installed tasks may no longer fit in partition SET /TOP=DRVPAR:-* POOL=1200:9644.:09644. (That bit is understandable. I must've configured it too big!) They are diagnostic messages, and many times totally expected and normal. The TT: driver is definitely expected. (I would be very worried if you did not get that one.) Same with the DRVPAR shrinking. It's a warning that is not important here, as you do not use DRVPAR for dynamic tasks anyway. The EXCOMn partitions are an 11M thing, but as far as I can remember they are also totally expected. boo [1,54]rsx11m SYSTEM CRASH AT LOCATION 014402 REGISTERS R0=000002 R1=120550 R2=000000 R3=120546 R4=120744 R5=031610 SP=117772 PS=020010 SYSTEM STACK DUMP LOCATION CONTENTS 117772 000004 001344 That is a very weird and unexpected stack pointer. RSX normally have the stack in rather low addresses. Not sure exactly what you configured, but maybe something wrong in all your answers... :-) After reboot: boo [1.54]rsx11m MCR -- Task not in system ins $boo boo [1,54]rsx11,\,\m [no output] I seem to be TERRIBLE and SYSGEN. Well, since the initial boot failed, any subsequent boots of that image I would expect to fail equally bad. Johnny

11 years, 5 months

RSTS/E is really picky

by b4＠gewt.net

On Tue, 20 May 2014, John Wilson wrote: So you're saying the image *did* work under emulation and only broke when you copied it to the first 512 MB of a disk that you then moved to a controller with an unknown private partitioning scheme? Yes. I later did try a copy from high-level VMS. The same issue was present there...but it actually got somewhere almost. ;) If I'm understanding you right then it sounds as if the controller may indeed be storing its own stuff in the first block(s) and the partition for DU1: isn't supposed to start until a few blocks into the drive. I would experiment with that by zeroing the disk, and then partitioning it on the PDP-11 (I assume this is done with the SCSI controller's firmware), move it to the PC and pull off the first few blocks, then repeat the process with different partitioning (assuming that's possible -- or do you mean the firmware is hard-coded to split drives into chunks .LE. 512 MB?), and see what changes in those first few blocks. It might be very obvious... It seems to split the drive in to 2 or 4 partitions. I can't manually define partition size...I am also having the controller identify the drive to the OS as an RA82. That could also be my problem. It's ~2.1G unpartitioned. Another thing to do is generate a bunch of different boot blocks that look like this: .word 240 ;NOP (required by some boot PROMs) .word 0 ;HALT (unless the PROM also requires a BR ...) .word blkno ;block # you'll be writing this one to .blkw 253. ;(junk for the rest of the block) ... and copy them to the first N blocks of the SCSI disk. Then when you move it to the PDP-11 and boot from it, it'll halt, and if you examine the word at 000004, you'll know which actual block was read in as block 0. Then next time write your image starting at that block instead of 0, and it might work. That would be a good debug routine. It boots RT-11 and RSX-11 fine, though. If you wanted to get *really* fancy, maybe you could set up a Linux (etc.) box as a SCSI target, and log the actual block #s accessed by the PDP-11? Seems kind of ridiculous... Yup. Just a bit. ;) John Wilson D Bit -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

11 years, 5 months

RSX-11 setback

by b4＠gewt.net

On Tue, 20 May 2014, Paul_Koning at Dell.com wrote: On May 20, 2014, at 1:47 PM, Cory Smelosky <b4 at gewt.net> wrote: Well, I'm just not having ANY luck with this... ... SYSTEM CRASH AT LOCATION 014402 REGISTERS R0=000002 R1=120550 R2=000000 R3=120546 R4=120744 R5=031610 SP=117772 PS=020010 ... I seem to be TERRIBLE and SYSGEN. Maybe you just have a bad drive, and RSX is unhappy just as RSTS was. That is possible. Although it was after the GEN finished. Also possible the file I should've BOOted was named after the name I gave the system. paul -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

11 years, 5 months

QBUS sound [Was: Re: [HECnet] Parallel computing using DECnet]

by Paul_Koning＠Dell.com

On May 20, 2014, at 1:48 PM, Jean-Yves Bernier <bernier at pescadoo.net> wrote: ... Virtualization had the side effect to move simh from Mac OS X to Linux, and things are much more simpler and up-to-date (Apple don't care BSD besides its own needs). I guess that s true, but it doesn t seem to cause trouble. I do a lot of my personal Unix development on Mac OS with few issues, other than having to put up with Clang. For example, SIMH works just fine. paul

11 years, 5 months

RSTS/E is really picky

by wilson＠dbit.com

From: Cory Smelosky <b4 at gewt.net> The disk is 1048778 blocks. I created a 512M image and copied it bit-for-bit to the disk. So you're saying the image *did* work under emulation and only broke when you copied it to the first 512 MB of a disk that you then moved to a controller with an unknown private partitioning scheme? If I'm understanding you right then it sounds as if the controller may indeed be storing its own stuff in the first block(s) and the partition for DU1: isn't supposed to start until a few blocks into the drive. I would experiment with that by zeroing the disk, and then partitioning it on the PDP-11 (I assume this is done with the SCSI controller's firmware), move it to the PC and pull off the first few blocks, then repeat the process with different partitioning (assuming that's possible -- or do you mean the firmware is hard-coded to split drives into chunks .LE. 512 MB?), and see what changes in those first few blocks. It might be very obvious... Another thing to do is generate a bunch of different boot blocks that look like this: .word 240 ;NOP (required by some boot PROMs) .word 0 ;HALT (unless the PROM also requires a BR ...) .word blkno ;block # you'll be writing this one to .blkw 253. ;(junk for the rest of the block) ... and copy them to the first N blocks of the SCSI disk. Then when you move it to the PDP-11 and boot from it, it'll halt, and if you examine the word at 000004, you'll know which actual block was read in as block 0. Then next time write your image starting at that block instead of 0, and it might work. If you wanted to get *really* fancy, maybe you could set up a Linux (etc.) box as a SCSI target, and log the actual block #s accessed by the PDP-11? Seems kind of ridiculous... John Wilson D Bit

11 years, 5 months

RSX-11 setback

by Paul_Koning＠Dell.com

On May 20, 2014, at 1:47 PM, Cory Smelosky <b4 at gewt.net> wrote: Well, I'm just not having ANY luck with this... ... SYSTEM CRASH AT LOCATION 014402 REGISTERS R0=000002 R1=120550 R2=000000 R3=120546 R4=120744 R5=031610 SP=117772 PS=020010 ... I seem to be TERRIBLE and SYSGEN. Maybe you just have a bad drive, and RSX is unhappy just as RSTS was. paul

11 years, 5 months

QBUS sound [Was: Re: [HECnet] Parallel computing using DECnet]

by bernier＠pescadoo.net

At 5:52 PM +0200 20/5/14, Johnny Billquist wrote: Discontinued. Of course... :-( To new readers, let me introduce me. I was the operator of nodes 10.1 (SHARK) and 10.2 (SNAKE) until I had to reorganize (== shrink) my server facility and flip the HECNET switch off on July 2010. SHARK and SNAKE have resurrected from 4 years in limbo, thanks to VirtualBox. They are PDP's running 11M+. I even discovered a forgotten 10.3 (SQUID), with sysgened PC11 to spool data from/to Unix pipes. That was the opportunity to check HECNET community health, and I am pleased to see it is in great form. This list is one of the more active I subscribe to. I was surprised to see 10.1 and 10.2 in MADAME's nodes table. Is this for real? I thought they had been purged or reassigned for long. Virtualization had the side effect to move simh from Mac OS X to Linux, and things are much more simpler and up-to-date (Apple don't care BSD besides its own needs). I am now trying to install DECNET for Linux. This will allow to move large sound files from the ancient world to the present. -- Jean-Yves Bernier

11 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet