Re: [Simh] Regarding Cutler THE father of VMS myth
On Sun, Mar 8, 2015 at 8:23 AM, Sergey Oboguev obog...@yahoo.com wrote: If so, he may have a claim to inventing (a hint at) a microkernel concept. ;-) Dykstra invented the ukernel -- its the THE kernel: https://en.wikipedia.org/wiki/THE_multiprogramming_system The paper itself is http://uosis.mif.vu.lt/~liutauras/books/Dijkstra%20-%20The%20structure%20of%20the%20THE%20multiprogramming%20system.pdf And all kernel hacker should read it some time. It where the idea of semaphores are defined and the idea of up and down - (aka P/V). Clem ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] DEC floppy disk interleave questions
Hello Mark, I attached the patch, it is against SIMH v3.7 from around 2008. If you want me to clean it up and get it working against the latest SIMH, let me know. I probably won't be able to get to it for a couple months, so I'm attaching the patch in case someone else wants to take a stab at it. Looking briefly at the patch, it seems that I put most of the changes under #USE_IMD. Since sim_imd.* has been promoted and is part of the main SIMH distribution now, those #ifdefs can probably be removed as long as the functionality is ok. -Howard -Original Message- From: Mark Pizzolato - Info Comm [mailto:m...@infocomm.com] Sent: Sunday, March 8, 2015 4:42 AM To: Howard M. Harte; 'Alan Frisbie'; SIMH@trailing-edge.com Subject: RE: [Simh] DEC floppy disk interleave questions On Saturday, March 7, 2015 at 6:15 PM, Howard M. Harte wrote: Dave Dunfield's ImageDisk (.IMD) format can preserve the floppy disk metadata. He has some DEC disk images in this format on his site: http://www.classiccmp.org/dunfield/img/index.htm When I implemented several floppy disk controllers for the SIMH/AltairZ80 simulator several years ago, I wrote a module for SIMH called sim_imd which can utilize the ImageDisk format within SIMH. At that time, I had a patch to make it work as an alternate to the flat file format that is normally used for SIMH for the pdp_rx disk controller. I tested sim_imd with the PDP-11 RT11 disk image from Dave's site, and it worked fine. The sim_ind.c module has since been used by several other simulators beyond the AltairZ80. sim_imd.c sim_imd.h are now located in the top level of the simh github repository. I've never seen any patch for the pdp11_rx.c device but would be happy to consider it. Please see if you can dig it up and pass it along. Thanks. - Mark pdp11_rx_imd.patch Description: Binary data ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] DEC floppy disk interleave questions
Thanks Christian, very interesting. I just ordered one. From: Christian Brunschen [mailto:christ...@brunschen.com] Sent: Sunday, March 8, 2015 3:14 AM To: Howard M. Harte Cc: Alan Frisbie; SIMH@trailing-edge.com Subject: Re: [Simh] DEC floppy disk interleave questions Potentially interesting for reading floppy disks at a low level: Kryoflyx http://kryoflux.com/ . // Christian On 8 March 2015 at 02:14, Howard M. Harte hha...@hartetechnologies.com mailto:hha...@hartetechnologies.com wrote: Dave Dunfield's ImageDisk (.IMD) format can preserve the floppy disk metadata. He has some DEC disk images in this format on his site: http://www.classiccmp.org/dunfield/img/index.htm When I implemented several floppy disk controllers for the SIMH/AltairZ80 simulator several years ago, I wrote a module for SIMH called sim_imd which can utilize the ImageDisk format within SIMH. At that time, I had a patch to make it work as an alternate to the flat file format that is normally used for SIMH for the pdp_rx disk controller. I tested sim_imd with the PDP-11 RT11 disk image from Dave's site, and it worked fine. I may be incorrect, but if I remember correctly, the RX02 disks have the sector header in single-density and the data field in double-density. In that case, I don't think ImageDisk will be able to handle it. If you hook up an 8 floppy drive to a semi-modern PC motherboard with the right disk controller, then you may be able to read at least RX01 disks with ImageDisk. Last time I tried this was around 2008, and I believe I used an Intel Desktop Board with Pentium 4 CPU and Shugart 800 drives. Only certain PC floppy controllers can read single-density, and even fewer can write it. Preserving the sector headers is fairly important in my opinion. It allows the image to be written back to a physical disk and used on real hardware. That said, just getting the data off the disk in a flat file is still very useful for most purposes. -Howard -Original Message- From: Simh [mailto:simh-boun...@trailing-edge.com mailto:simh-boun...@trailing-edge.com ] On Behalf Of Johnny Billquist Sent: Saturday, March 7, 2015 4:52 PM To: Alan Frisbie; SIMH@trailing-edge.com mailto:SIMH@trailing-edge.com Subject: Re: [Simh] DEC floppy disk interleave questions Hi, Alan. On 2015-03-08 00:47, Alan Frisbie wrote: I have a large quantity of disks that I wish to copy to files that can be directly used by the SIMH PDP-11 emulator and by the E11 emulator. They include 8 floppies (both RX01 and RX02), RL01, and RL02. The issue is that the disks have sector sizes that differ from the usual 512 bytes, as well as having interesting interleave and stagger factors. RX50 (and RX33?) disks have (I think) 512-byte sectors, but some odd track usage. I also believe that RX02 disks have the first track in single-density mode, just to complicate things, but it isn't used by most DEC O/S software. RL01 and RL02 disks also have bad-block sectors at the end of the disk. I am assuming that SIMH and E11 emulate the device faithfully enough that programs which are aware of the interleaving and small sector sizes will work properly. If this assumption is wrong, please enlighten me. If my assumption is correct, what is the best way to copy the raw disks (which are in a variety of O/S formats) to files which the emulators will be happy with. I can bring up a real PDP-11 with RX02, but will probably be using a microVAX-II with an Andromeda FDC11-B controller and Shugart 800 drives. I don't mind writing my own code with QIOs. I have a bunch more questions related to this, but this will do for now. :-) All of this is related to cleaning out my storage units and de-cluttering my life. Hmm, I believe this is not absolutely straight forward. The problem is that simh (or E11) do not emulate the physical layer, but the logical one. As such, the image files of disks are assumed to always be containing sequential blocks, and no block headers are in the image file. So, it will work, in that, if you can dump out an image from a disk, where block #1 is block #1 on the image file, then things will just work fine. If you dump out the physical blocks raw, including block headers, then they are not usable by the emulators. Logical rearranging of blocks will work fine, though. So, the trick you normally see with RX01/RX02, where they remap block numbers to other blocks numbers in the device driver, is just fine. You just want the actual physical blocks, in the order they are on the disk. )As indicated by the disk block headers.) The actual layout, as created when formatting the disk, will not carry over, but it is also not important. (I hope I'm making sense here, I feel I might be overcomplicating my text...) Bad blocks, as described by the RL01/RL02 bad block tables, are totally under the device drivers and system software, so that is just fine. Systems will avoid those
Re: [Simh] DEC floppy disk interleave questions
Potentially interesting for reading floppy disks at a low level: Kryoflyx http://kryoflux.com/. // Christian On 8 March 2015 at 02:14, Howard M. Harte hha...@hartetechnologies.com wrote: Dave Dunfield's ImageDisk (.IMD) format can preserve the floppy disk metadata. He has some DEC disk images in this format on his site: http://www.classiccmp.org/dunfield/img/index.htm When I implemented several floppy disk controllers for the SIMH/AltairZ80 simulator several years ago, I wrote a module for SIMH called sim_imd which can utilize the ImageDisk format within SIMH. At that time, I had a patch to make it work as an alternate to the flat file format that is normally used for SIMH for the pdp_rx disk controller. I tested sim_imd with the PDP-11 RT11 disk image from Dave's site, and it worked fine. I may be incorrect, but if I remember correctly, the RX02 disks have the sector header in single-density and the data field in double-density. In that case, I don't think ImageDisk will be able to handle it. If you hook up an 8 floppy drive to a semi-modern PC motherboard with the right disk controller, then you may be able to read at least RX01 disks with ImageDisk. Last time I tried this was around 2008, and I believe I used an Intel Desktop Board with Pentium 4 CPU and Shugart 800 drives. Only certain PC floppy controllers can read single-density, and even fewer can write it. Preserving the sector headers is fairly important in my opinion. It allows the image to be written back to a physical disk and used on real hardware. That said, just getting the data off the disk in a flat file is still very useful for most purposes. -Howard -Original Message- From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Johnny Billquist Sent: Saturday, March 7, 2015 4:52 PM To: Alan Frisbie; SIMH@trailing-edge.com Subject: Re: [Simh] DEC floppy disk interleave questions Hi, Alan. On 2015-03-08 00:47, Alan Frisbie wrote: I have a large quantity of disks that I wish to copy to files that can be directly used by the SIMH PDP-11 emulator and by the E11 emulator. They include 8 floppies (both RX01 and RX02), RL01, and RL02. The issue is that the disks have sector sizes that differ from the usual 512 bytes, as well as having interesting interleave and stagger factors. RX50 (and RX33?) disks have (I think) 512-byte sectors, but some odd track usage. I also believe that RX02 disks have the first track in single-density mode, just to complicate things, but it isn't used by most DEC O/S software. RL01 and RL02 disks also have bad-block sectors at the end of the disk. I am assuming that SIMH and E11 emulate the device faithfully enough that programs which are aware of the interleaving and small sector sizes will work properly. If this assumption is wrong, please enlighten me. If my assumption is correct, what is the best way to copy the raw disks (which are in a variety of O/S formats) to files which the emulators will be happy with. I can bring up a real PDP-11 with RX02, but will probably be using a microVAX-II with an Andromeda FDC11-B controller and Shugart 800 drives. I don't mind writing my own code with QIOs. I have a bunch more questions related to this, but this will do for now. :-) All of this is related to cleaning out my storage units and de-cluttering my life. Hmm, I believe this is not absolutely straight forward. The problem is that simh (or E11) do not emulate the physical layer, but the logical one. As such, the image files of disks are assumed to always be containing sequential blocks, and no block headers are in the image file. So, it will work, in that, if you can dump out an image from a disk, where block #1 is block #1 on the image file, then things will just work fine. If you dump out the physical blocks raw, including block headers, then they are not usable by the emulators. Logical rearranging of blocks will work fine, though. So, the trick you normally see with RX01/RX02, where they remap block numbers to other blocks numbers in the device driver, is just fine. You just want the actual physical blocks, in the order they are on the disk. )As indicated by the disk block headers.) The actual layout, as created when formatting the disk, will not carry over, but it is also not important. (I hope I'm making sense here, I feel I might be overcomplicating my text...) Bad blocks, as described by the RL01/RL02 bad block tables, are totally under the device drivers and system software, so that is just fine. Systems will avoid those blocks, even on a dumped image of the disk, assuming you copy all blocks, including the bad block list. Johnny -- Johnny Billquist || I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! ||
Re: [Simh] Issue with MOP booting SIMH instance from AlphaVM
Mark I'm using the pre-built V3.9-0 executables with networking support built by your kind self, downloaded from github. The AlphaVM box has MOP characteristics defined as shown. The box has a separate drive pointed to by logical ALPEPHSYSTEM$ that contains an ODS-2 OpenVMS VAX 7.3 installation. This boots OK using a real VAXstation 4000/VLC. Same results regardless of idle flag. Host system is Windows Server 2012 R2. Network configuration is as follows: the box has two inbuilt ethernet ports and a 4 gigabit port card. The AlphaVM instance and SIMH instance are attached to different ethernet ports. All ports are connected to a 24 port HP Gbit switch. Thanks for the help, Mark. On 8 March 2015 at 23:44, Mark Pizzolato - Info Comm m...@infocomm.com wrote: Hi Mark, That another system actually can boot from the AlphaVM system is good info. Meanwhile several questions come up: 1) What version of simh are you running on that SIMH instance? 2) How did you configure the SIMH instance to boot from the AlphaVM system (what was done on the AlphaVM box)? 3) Do you get the same results with SET CPU IDLE vs SET CPU NOIDLE in effect? 4) What host system are you running on? 5) What is your network configuration/topology? - Mark *From:* Simh [mailto:simh-boun...@trailing-edge.com] *On Behalf Of *Mark Wickens *Sent:* Sunday, March 08, 2015 4:38 PM *To:* simh@trailing-edge.com *Subject:* [Simh] Issue with MOP booting SIMH instance from AlphaVM Sorry, I should add that the actual VAXstation 4000/VLC box that the SIMH instance is emulating does MOP boot sucessfully off the AlphaVM instance. Regards, Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] Issue with MOP booting SIMH instance from AlphaVM
I suggest leaving each virtual system on a separate NIC. It makes networking easier. You likely have a network issue with the VAX system. Make it standalone bootable and then make sure its network is functioning correctly. Once you know the configuration works, then try to remote boot it. Bruce C. Migration Specialties ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Issue with MOP booting SIMH instance from AlphaVM
On Mar 8, 2015 7:41 PM, MSI m...@earthlink.net wrote: I suggest leaving each virtual system on a separate NIC. It makes networking easier. My suggestion (sharing the NIC which is trivial on a Windows Host) let's his test be performed without requiring any fancy behavior from the switch. The point where his boot test is failing is right around when the simulated has its MAC address changed from the hardware MAC address to the DECnet address. You likely have a network issue with the VAX system. Make it standalone bootable and then make sure its network is functioning correctly. Once you know the configuration works, then try to remote boot it. This may be true and is a reasonable suggestion, but may illuminate a solution. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Regarding Cutler THE father of VMS myth
Johnny Billquist b...@softjar.se wrote: One thing Cutler did, which you do not find in the predecessors are ACPs. If so, he may have a claim to inventing (a hint at) a microkernel concept. ;-) Ironically, while ACPs made a lot of sense in a PDP-11 world due to the constraints in address space and kernel memory size, but rolling ACP idea over to VMS was much less productive (since these constraints were gone), and eventually F11 ACP was replaced with in-process XQP. I am wondering though if FUSE developers ever heard of ACPs or reinvented the concept from scratch. At least http://en.wikipedia.org/wiki/Filesystem_in_Userspace claims that The idea of a filesystem driver living in userspace was originally developed in 1995. It is also curious that ACPs (whether in traditional form or XQP form) allowed to do one thing that Unix/Linux interface still does not -- opening files as an asynchronous operation -- but ironically the chief utility of this capability is mainly for web servers which were not invented back then yet. P.S. To come think of it, my very first project as a salaried software developer (more akin to commercial enterprise of Tom Sawyer in fence painting business) at ca. 1984 involved writing an ACP-like structure... not for a file system, but for a graphics card, on RSX. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] Issue with MOP booting SIMH instance from AlphaVM
Hi Mark, First, Please use the latest binaries for the latest codebase: https://github.com/simh/Win32-Development-Binaries Second, please attach the simh instance to the same network interface that the AlphaVM is connected to. Let me know. -Mark From: Mark Wickens [mailto:m...@wickensonline.co.uk] Sent: Sunday, March 8, 2015 5:07 PM To: Mark Pizzolato - Info Comm Cc: simh@trailing-edge.com Subject: Re: [Simh] Issue with MOP booting SIMH instance from AlphaVM Mark I'm using the pre-built V3.9-0 executables with networking support built by your kind self, downloaded from github. The AlphaVM box has MOP characteristics defined as shown. The box has a separate drive pointed to by logical ALPEPHSYSTEM$ that contains an ODS-2 OpenVMS VAX 7.3 installation. This boots OK using a real VAXstation 4000/VLC. Same results regardless of idle flag. Host system is Windows Server 2012 R2. Network configuration is as follows: the box has two inbuilt ethernet ports and a 4 gigabit port card. The AlphaVM instance and SIMH instance are attached to different ethernet ports. All ports are connected to a 24 port HP Gbit switch. Thanks for the help, Mark. On 8 March 2015 at 23:44, Mark Pizzolato - Info Comm m...@infocomm.commailto:m...@infocomm.com wrote: Hi Mark, That another system actually can boot from the AlphaVM system is good info. Meanwhile several questions come up: 1) What version of simh are you running on that SIMH instance? 2) How did you configure the SIMH instance to boot from the AlphaVM system (what was done on the AlphaVM box)? 3) Do you get the same results with SET CPU IDLE vs SET CPU NOIDLE in effect? 4) What host system are you running on? 5) What is your network configuration/topology? - Mark From: Simh [mailto:simh-boun...@trailing-edge.commailto:simh-boun...@trailing-edge.com] On Behalf Of Mark Wickens Sent: Sunday, March 08, 2015 4:38 PM To: simh@trailing-edge.commailto:simh@trailing-edge.com Subject: [Simh] Issue with MOP booting SIMH instance from AlphaVM Sorry, I should add that the actual VAXstation 4000/VLC box that the SIMH instance is emulating does MOP boot sucessfully off the AlphaVM instance. Regards, Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
