Re: [Simh] SCSI-Interface for simh-vax?
On 2018-09-01 22:18, Timothe Litt wrote: we might have done at DEC was mess with the block size on a CD DEC does not modify the physical sector format - it is implemented in the drive. VMS packs four 512 B logical sectors into one 2048 B physical sector; the driver handles buffering and provides the illusion of a 512B sector size. Most FILES-11 CDs use unmodified ODS-2. But distribution CDs would do things like omit (or truncate) the bit table to save space. For that reason, ANA/DISK would fail. There are some CDs that use a slightly modified HOM block (FILES-11 B Level 0), but it wasn't widely adopted. When you say "driver", it sounds like you mean the VMS device drive. But in the previous paragraph you said "drive". The correct answer is "drive". VMS requires that the CD drive can handle 512 byte sectors. The drive needs to do the unblocking. Not all CD drives can do this, so one have to be careful which drive to use on a VMS system. This might be different on Alpha and Itanium systems, but for VAX it has to have 512 byte sector size. Also, VMS actually understands ISO 9660 file systems. I don't remember when that came in, but it's definitely the case for OpenVMS V7.3 on a VAX. There are other oddities - drives & drivers tell different lies about the geometry (cyl/track/sector) of a CDROM; multiplying these out frequently will not match the file system's idea of the volume size. (As recorded in the SCB for FILES-11, equivalent for other formats.) The lies vary by OS, version, drive & phase of the moon. The same CD read under different conditions will report alternative facts. These will not trip up a DEC OS on DEC HW - but can create obscure issues with simulation - especially if you try to pass geometry from a physical drive thru SimH. That sounds weird. As far as I know, VMS don't really care about cyl/trk/sector information here. That kind of information is rather old school and was used on devices predating MSCP. MSCP and later instead just deal with total device capacity as reported, and don't try to calculate it. I think there usually is some fake cyl/trk/sector data that can be reported, which just gets you close to capacity, but usually don't really end up with the right number, but which can be used if anyone really insist they want this kind of information. That said, CD is still a bit special, since the actual size in the file system might be different than the capacity of the drive. But I think that there should hardly be any issues in any simulation here. As long as the size is reported right, geometry numbers can be pretty much anything without a problem. Writing a CD is rarely supported by a standard driver - typically, CD writing software issues direct SCSI commands to the drive (encapsulated in whatever the real transport is). This may be by direct IO, or via a class driver. It can be somewhat tricky - note that most drives can not tolerate buffer underruns when writing. I don't think VMS ever supported writing to a CD in a natural way. But of course device drivers might have gotten the capability along the way, so special programs can do it. I think most drives deal well with underruns nowadays. But that used to be a big issue a number of years ago. I wasn’t able to figure out how to make it work in RSTS/E. To be bootable, a CD needs an appropriate boot block (LBN 0). For VMS, it's written by 'writeboot' - not initialize. I don't remember the details for RSTS - look at SAVRES->RESTORE and BACKUP for possibilities. Or wait for Paul K to fill that in. Paul needs to chime in here. But in the back of my head, there is a warning bell about RSTS/E expecting/require the boot device to always be writeable, which could be a serious problem for a CD. Johnny -- 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
Re: [Simh] SCSI-Interface for simh-vax?
Jordi Guillaumes i Pons wrote: > I’ve got two QBUS interface cards installed in my VAX 4000-200 and > uVAX 3300 systems. I think I’ve got no docs though. Would that be of > any help (ie, testing stuff on real hardware)? Hello, I'm sorry to bother you and everyone else on this list, but have been unsuccessfully trying to reach you about Barcelona retro computing. Would you mind sending me an email to l...@nocrew.org? Thanks, Lars Brinkhoff ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SCSI-Interface for simh-vax?
Mark, I’ve got two QBUS interface cards installed in my VAX 4000-200 and uVAX 3300 systems. I think I’ve got no docs though. Would that be of any help (ie, testing stuff on real hardware)? Jordi Guillaumes Pons El 1 set 2018, a les 20:36, Mark Pizzolato va escriure: > On Saturday, September 1, 2018 at 10:45 AM, Eberhard Heuser wrote: >> Are there any plans to add a SCSI-Interface to the VAX-code? >> >> I want to add the CD-R burning capability but there is no interface >> (SCSI or IDE) that allows to communicate on the diagnose level >> with an CD-drive. >> >> I have seen that one can access a physical CD-drive but only through >> the pudriver and not via the pkdriver. > > Well, none of the current VAX simulators had a native SCSI interface > which was interfaced with the pkdriver. Without a simulated system > there is no place for SCSI support. > > Meanwhile, 99%+ of the host systems are natively capable of burning > CD/DVD. I am not aware of any DEC supplied software running on > VAX/VMS which was capable of producing a CD image in the ISO 9660 > file system format. All CDs that I ever encountered on DEC systems > (produced by DEC for use on VMS systems) had ODS2 file systems on > the CD media. All of the existing VAX simulators can easily produce an > ODS2 disk image of arbitrary size which can then be readily written on > the host system to CD or DVD media with host supplied tools. > > Even if a simulator comes along which does have a built in SCSI support, > arbitrarily extending that support to interface with CD/DVD media for > burning activities would be a challenge to achieve in a portable way > to work on most host platforms and as such probably won't get done > unless you're interested in taking on the project. > > After thinking a little more, I vaguely recall that there was indeed a > Qbus board which had a SCSI chip that used the PKDRIVER. This > was called the KZQSA. I tested one once and was fundamentally > unimpressed by its performance primarily due to it not being a > DMA device. In any case, I haven't seen any detailed documentation > on this board which would be necessary to write a simulator of it, > but if you can find documentation, feel free to take a crack at > simulating it, and delving into the host platform complexities (in > a portable way) to burn CD media. > > - Mark > ___ > 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] ANDROID 7.0 .... simh "make vax" error....
On Saturday, September 1, 2018 at 7:31 PM, Mark Abene wrote: > Yes. Depending on context, one would use either of FNDELAY, > O_NDELAY, or O_NONBLOCK, for clarity. > In reality, they all mean the same thing. See > /usr/include/x86_64-linux-gnu/bits/fcntl-linux.h to see why > that is. In the case of android, try O_NONBLOCK, or try using > ioctl instead of fcntl (FNDELAY doesn't exist on android, so use > one of the other names). Thanks for that pointer. Implied there is that the FNDELAY comes from some desire for BSD compatibility which it seems reasonable for Android not to be too worried about. I was surprised that Android's termios sys calls didn't support TCSAFLUSH, so we had to switch to TCSANOW on Android. The recent change (adding FNDELAY) was added to accommodate a different Linux platform which didn't honor the termio setting of VMIN=0 and VTIME=0 settings which define non blocking I/O. > I can't see the surrounding code, so there may be a bit more > work involved. Nope. The name change was all that was needed. -Mark > > On Sat, Sep 1, 2018 at 6:38 PM, vince wrote: > > > > can anybody help here ? . V ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] ANDROID 7.0 .... simh "make vax" error....
On Sunday, September 2, 2018 at 12:20 PM, Johnny Billquist wrote: > On 2018-09-02 20:09, Mark Pizzolato wrote: > > On Saturday, September 1, 2018 at 7:31 PM, Mark Abene wrote: > >> Yes. Depending on context, one would use either of FNDELAY, > >> O_NDELAY, or O_NONBLOCK, for clarity. > >> In reality, they all mean the same thing. See > >> /usr/include/x86_64-linux-gnu/bits/fcntl-linux.h to see why > >> that is. In the case of android, try O_NONBLOCK, or try using > >> ioctl instead of fcntl (FNDELAY doesn't exist on android, so use > >> one of the other names). > > > > Thanks for that pointer. Implied there is that the FNDELAY comes > > from some desire for BSD compatibility which it seems reasonable > > for Android not to be too worried about. > > Not only that, FNDELAY is supposed to be kernel internal only. > Apparently there was some version who accidentally exposed it, and to be > compatible, it's been defined/exposed since, but no code should really > ever use this. There was a difference section of code in sim_console.c which explicitly is #ifdef'd for BSD using fcntl and ioctls instead of the termios that is used in Linux. The BSD code goes back to 2001. > Linux seems to think it should be mapped to O_NDELAY, while looking at > NetBSD, it is mapped to O_NONBLOCK. On Linux (at least for Intel), FNDELAY, O_NDELAY and O_NONBLOCK are all the same value (0x800). On NetBSD 7.0 and OS X they are all the same value (4) . > I think it's wise to totally remove any reference to FNDELAY. It is > never the correct value. > > One could then argue what the different is between O_NDELAY and > O_NONBLOCK, but that's a different story. > > > The recent change (adding FNDELAY) was added to accommodate > > a different Linux platform which didn't honor the termio setting of > > VMIN=0 and VTIME=0 settings which define non blocking I/O. > > How about instead using O_* macros, which are the ones intended to be > used here... > You must have dug around some to even find FNDELAY... Well, I saw the BSD code and just copied the fcntl() logic and it worked (i.e. had no negative effects on the Ubuntu Linux I tried) and the resulting binary worked on the Ubuntu Linux and in the 'other Linux' platform. The 'other Linux' platform was WSL (Windows Subsystem for Linux). This is a Windows facility which can run Linux user mode code binaries directly with an internal implementation of many/most/all system calls. Now that I've looked closer at the definitions of O_NDELAY and O_NONBLOCK, using O_NONBLOCK seems most appropriate since the code that calls read() a expects -1 return when read doesn't return anything. It has now been change to O_NONBLOCK in both the BSD specific and Linux code, and for the BSD code, if O_NONBLOCK isn't defined it defines O_NONBLOCK as FNDELAY which is potentially the right thing for any older BSD that might not define O_NONBLOCK. Additionally, the status return checks now only look for 1 indicating a successful read, so either 0 or -1 means no data read. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] ANDROID 7.0 .... simh "make vax" error....
On Sunday, September 2, 2018 at 3:51 PM, iZurak wrote: > For what it may be worth: > > I have tried several other hardware platforms – Android (6, 7, ?), viz; > > O Xiaomi M3 result: make vax works fine. Even tried to boot > vax – failed but that was because I have not figured out how to get the > VMS.iso > in the environment > > O Oukitel result: in discussion > > O Samsung result: same as Oukitel In all cases, if you get the >>> prompt, things are running fine. As for getting your ISO file into your phone... Use wget, curl or some other network access method. - Mark > On 3/9/18, 4:10 am, "Simh on behalf of Mark Pizzolato" boun...@trailing-edge.com on behalf of m...@infocomm.com> wrote: > > On Saturday, September 1, 2018 at 7:31 PM, Mark Abene wrote: > > Yes. Depending on context, one would use either of FNDELAY, > > O_NDELAY, or O_NONBLOCK, for clarity. > > In reality, they all mean the same thing. See > > /usr/include/x86_64-linux-gnu/bits/fcntl-linux.h to see why > > that is. In the case of android, try O_NONBLOCK, or try using > > ioctl instead of fcntl (FNDELAY doesn't exist on android, so use > > one of the other names). > > Thanks for that pointer. Implied there is that the FNDELAY comes > from some desire for BSD compatibility which it seems reasonable > for Android not to be too worried about. > > I was surprised that Android's termios sys calls didn't support > TCSAFLUSH, so we had to switch to TCSANOW on Android. > > The recent change (adding FNDELAY) was added to accommodate > a different Linux platform which didn't honor the termio setting of > VMIN=0 and VTIME=0 settings which define non blocking I/O. > > > I can't see the surrounding code, so there may be a bit more > > work involved. > > Nope. The name change was all that was needed. > > -Mark > > > > > On Sat, Sep 1, 2018 at 6:38 PM, vince wrote: > > > > > > can anybody help here ? . V > > ___ > 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] SCSI-Interface for simh-vax?
> On Sep 1, 2018, at 2:38 PM, Zane Healy wrote: > > Create a virtual disk in SIMH the size of the CD-R blank. Prep the disk, > then burn it to CD-R. This is how I created my bootable CD’s for RT-11 and > RSX-11M+. I’ve then used those CD’s to do installs on my PDP-11/73. I > wasn’t able to figure out how to make it work in RSTS/E. I could create the > CD-R, but not boot and install RSTS/E from it. > > Zane Could you describe how you built the RSTS/E CD? It should be possible. If nothing else, with the -merge switch in FLX 2.6 -- which creates a hybrid structure that looks both like a CD file system and a RSTS file system, boot block and all. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SCSI-Interface for simh-vax?
> On Sep 2, 2018, at 5:55 AM, Johnny Billquist wrote: > > ... >>> I wasn’t able to figure out how to make it work in RSTS/E. >> To be bootable, a CD needs an appropriate boot block (LBN 0). For VMS, >> it's written by 'writeboot' - not initialize. I don't remember the >> details for RSTS - look at SAVRES->RESTORE and BACKUP for >> possibilities.Or wait for Paul K to fill that in. > > Paul needs to chime in here. But in the back of my head, there is a warning > bell about RSTS/E expecting/require the boot device to always be writeable, > which could be a serious problem for a CD. No, that's fine, provided the file system flags mark the file system as read-only. In that case, RSTS will treat the disk as an installation disk, and when booted go automatically to the installation actions as opposed to prompting for a regular startup. You can't start such a disk, that is true. But you can boot it, invoke the disk initializer to initiaze your intended system disk, and copy the minimal files from the CD to that disk after which it is booted. The block size could be a consideration; RSTS expects 512 byte blocks and I don't know how one would work around that on a CD. Also, what interface would you use? MSCP, I suppose; does that do the necessary magic to make it look like a 512-byte sector size device? paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SCSI-Interface for simh-vax?
> On Sep 2, 2018, at 2:01 PM, Tim Shoppa wrote: > > Paul, I have never made a bootable RSTS/E CD, but I might suspect that it is > picky about being booted from read-only disk media. > > (I remember last version of RSTS/E bootable install tape wouldn't boot unless > the write ring was on! That's one of the reasons I put this in the "picky" > bucket!) Other way around. If you're booting a magtape, it requires the ring to be absent. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SCSI-Interface for simh-vax?
On 2018-09-02 20:05, Paul Koning wrote: On Sep 2, 2018, at 5:55 AM, Johnny Billquist wrote: ... I wasn’t able to figure out how to make it work in RSTS/E. To be bootable, a CD needs an appropriate boot block (LBN 0). For VMS, it's written by 'writeboot' - not initialize. I don't remember the details for RSTS - look at SAVRES->RESTORE and BACKUP for possibilities.Or wait for Paul K to fill that in. Paul needs to chime in here. But in the back of my head, there is a warning bell about RSTS/E expecting/require the boot device to always be writeable, which could be a serious problem for a CD. No, that's fine, provided the file system flags mark the file system as read-only. In that case, RSTS will treat the disk as an installation disk, and when booted go automatically to the installation actions as opposed to prompting for a regular startup. You can't start such a disk, that is true. But you can boot it, invoke the disk initializer to initiaze your intended system disk, and copy the minimal files from the CD to that disk after which it is booted. Ok. Definitely sounds like it should work then. The block size could be a consideration; RSTS expects 512 byte blocks and I don't know how one would work around that on a CD. Also, what interface would you use? MSCP, I suppose; does that do the necessary magic to make it look like a 512-byte sector size device? This is the same issues/conditions as you face with RSX, which the OP did get to work. Yes, you'd normally hook the CD to a SCSI controller which appears as an MSCP disk to the PDP-11 side. I've done that often enough myself as well. You do need a CD which can deal with 512 byte blocks. But from there on, it looks just like any other disk to the PDP-11. A VAX have the same issues/requirements, as do SUN. Not all CD drives can deal with 512 byte sectors, so you have to look for that. Johnny -- 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
Re: [Simh] ANDROID 7.0 .... simh "make vax" error....
On 2018-09-02 20:09, Mark Pizzolato wrote: On Saturday, September 1, 2018 at 7:31 PM, Mark Abene wrote: Yes. Depending on context, one would use either of FNDELAY, O_NDELAY, or O_NONBLOCK, for clarity. In reality, they all mean the same thing. See /usr/include/x86_64-linux-gnu/bits/fcntl-linux.h to see why that is. In the case of android, try O_NONBLOCK, or try using ioctl instead of fcntl (FNDELAY doesn't exist on android, so use one of the other names). Thanks for that pointer. Implied there is that the FNDELAY comes from some desire for BSD compatibility which it seems reasonable for Android not to be too worried about. Not only that, FNDELAY is supposed to be kernel internal only. Apparently there was some version who accidentally exposed it, and to be compatible, it's been defined/exposed since, but no code should really ever use this. Linux seems to think it should be mapped to O_NDELAY, while looking at NetBSD, it is mapped to O_NONBLOCK. I think it's wise to totally remove any reference to FNDELAY. It is never the correct value. One could then argue what the different is between O_NDELAY and O_NONBLOCK, but that's a different story. The recent change (adding FNDELAY) was added to accommodate a different Linux platform which didn't honor the termio setting of VMIN=0 and VTIME=0 settings which define non blocking I/O. How about instead using O_* macros, which are the ones intended to be used here... You must have dug around some to even find FNDELAY... Johnny -- 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
Re: [Simh] SCSI-Interface for simh-vax?
> On Sep 1, 2018, at 4:18 PM, Timothe Litt wrote: > >> ... > >> I wasn’t able to figure out how to make it work in RSTS/E. > > To be bootable, a CD needs an appropriate boot block (LBN 0). For VMS, > it's written by 'writeboot' - not initialize. I don't remember the > details for RSTS - look at SAVRES->RESTORE and BACKUP for > possibilities.Or wait for Paul K to fill that in. > > Also note that dual format CDROMs are possible - 9660 reserves the first > 16 sectors for this; thus it's possible to write a disk that is readable > as both FILES-11 and & 9660 (with file data being in the same sectors; > only the metadata differs.) Such disks were actually created. More details for RSTS. Right, when you initialize a RSTS disk it isn't bootable. You get a dummy boot (one that prints "please boot from the system disk") instead. Bootable disks are created in one of several ways. SAVRES does, but that isn't helpful here. The other is the HOOK utility, which should be on the RSTS kit. The way that works: first make sure INIT.SYS has been copied into [0,1] on the destination device. Then run HOOK and tell it: dev:[0,1] and that should be all you need. (This is for disk; tape is different and I don't have the details handy.) BACKUP doesn't create bootable devices. Note that a bootable tape, and a bootable disk whose file system flags say it's read-only, are considered installation media. Read/write bootable disks are considered a system disk. Finally, yes, I remember working with Fred Knight on dual format RSTS/E CDROM. The intent was to create a single disk with all RSTS/E DEC software on it. I don't know if that ever happened; I never saw the results. But to make this possible I added a mode to FLX to create a dual mode disk, ISO 9660 plus RSTS/E file system. Look in the FLX 2.6 documentation, the "-merge" switch. Note that I removed it from the FLX 3 code (Python based FLX), though it could be brought back easily enough. paul ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
