Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.dec > #218 > unrolled thread
| Started by | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| First post | 2011-04-04 09:12 -0400 |
| Last post | 2011-05-25 14:05 -0400 |
| Articles | 20 on this page of 143 — 22 participants |
Back to article view | Back to comp.sys.dec
Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-04-04 09:12 -0400
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-04-30 22:27 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-01 10:01 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-01 10:27 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-01 20:53 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-01 21:16 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-01 20:54 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-01 21:07 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-02 09:37 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-02 08:39 -0700
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-02 05:15 +0000
Re: Y3K for PDP-11 Operating Systems jjh <jjhudak@gmail.com> - 2011-05-02 18:20 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 08:18 -0500
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 12:51 -0400
VAXTREK koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 12:50 -0500
Re: Y3K for PDP-11 Operating Systems Henry Crun <mike@rechtman.com> - 2011-05-03 21:39 +0300
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 15:56 -0400
Re: Y3K for PDP-11 Operating Systems onedbguru <onedbguru@yahoo.com> - 2011-05-03 15:52 -0700
Re: Y3K for PDP-11 Operating Systems billig999@cs.uofs.edu (Bill Gunshannon) - 2011-05-04 00:07 +0000
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-04 01:16 -0400
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-04 13:01 +0000
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-04 10:19 -0400
Re: Y3K for PDP-11 Operating Systems kludge@panix.com (Scott Dorsey) - 2011-05-04 10:58 -0400
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-04 16:33 +0000
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-04 21:51 -0400
Re: Y3K for PDP-11 Operating Systems G Cornelius <cornelius@eisner.decus.org> - 2011-05-06 13:08 -0500
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-06 14:47 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@update.uu.se> - 2011-05-06 16:13 -0600
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-07 21:00 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-07 19:51 -0600
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-08 07:19 -0400
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-09 17:32 -0400
Re: Y3K for PDP-11 Operating Systems Rob Brown <mylastname@gmcl.com> - 2011-05-09 09:40 -0600
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 09:43 -0600
Re: Y3K for PDP-11 Operating Systems vandys@vsta.org - 2011-05-09 21:47 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 16:05 -0600
Re: Y3K for PDP-11 Operating Systems vandys@vsta.org - 2011-05-09 23:05 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 17:20 -0600
Re: Y3K for PDP-11 Operating Systems vandys@vsta.org - 2011-05-10 00:12 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 19:36 -0600
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-10 02:01 +0000
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 08:31 -0500
Re: Y3K for PDP-11 Operating Systems John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-10 09:56 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 12:50 -0500
Re: Y3K for PDP-11 Operating Systems G Cornelius <cornelius@eisner.decus.org> - 2011-05-11 11:04 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-04 10:02 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-04 12:20 -0500
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-04 18:10 +0000
Re: Y3K for PDP-11 Operating Systems John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-04 12:21 -0700
Re: Y3K for PDP-11 Operating Systems MetaEd <metaed@gmail.com> - 2011-05-04 15:06 -0700
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-04 20:17 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 08:20 -0500
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 08:29 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-10 09:29 -0600
Re: Y3K for PDP-11 Operating Systems G Cornelius <cornelius@eisner.decus.org> - 2011-05-10 12:16 -0500
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 12:45 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-10 15:34 -0600
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 12:58 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-10 15:36 -0600
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 12:38 -0400
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-03 11:28 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 12:09 -0400
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-23 03:41 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-22 21:51 -0700
Re: Y3K for PDP-11 Operating Systems jjh <jjhudak@gmail.com> - 2011-05-23 07:47 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-23 15:04 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 15:52 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 00:16 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 17:40 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 12:58 +0000
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-24 14:02 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 07:36 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 16:42 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 11:17 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 20:07 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-24 21:07 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 03:34 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-25 15:46 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 16:00 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 17:50 +0200
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 09:53 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 22:20 +0200
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-28 18:01 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-25 20:58 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-26 01:23 +0000
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-26 08:01 -0500
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-27 00:54 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-26 16:15 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-26 23:56 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-27 14:37 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-27 00:02 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 20:17 -0700
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-27 14:51 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-27 12:48 -0700
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-27 14:35 -0400
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 21:14 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-26 01:32 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-26 16:39 -0400
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 17:50 +0200
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-24 21:01 -0400
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-26 07:53 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 09:59 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 10:03 +0200
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-26 14:21 +0000
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-26 18:50 +0000
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-27 11:58 +0000
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-27 17:23 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 10:04 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-27 03:30 +0200
Re: Y3K for PDP-11 Operating Systems kludge@panix.com (Scott Dorsey) - 2011-05-26 22:17 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 20:26 -0700
Re: Y3K for PDP-11 Operating Systems John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-30 14:09 -0700
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-30 18:15 -0700
Re: Y3K for PDP-11 Operating Systems jjh <jjhudak@gmail.com> - 2011-05-31 11:02 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-31 15:54 -0500
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-31 21:37 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-24 22:59 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 03:51 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 08:36 -0400
Re: Y3K for PDP-11 Operating Systems "Tom Lake" <tlake@twcny.rr.com> - 2011-05-25 13:25 -0400
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 14:01 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 11:44 -0700
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-25 21:20 -0400
Re: Y3K for PDP-11 Operating Systems Rob Brown <mylastname@gmcl.com> - 2011-05-26 10:53 -0600
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-26 16:27 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 20:27 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-26 16:38 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 21:44 -0700
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-24 12:02 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-23 10:48 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 15:46 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 00:19 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 17:43 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 14:41 -0400
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-24 02:54 +0000
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 13:03 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 07:39 -0700
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-24 15:10 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 08:48 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 16:54 +0000
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-24 14:42 +0000
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 16:56 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 14:05 -0400
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | koehler@eisner.nospam.encompasserve.org (Bob Koehler) |
|---|---|
| Date | 2011-05-26 07:53 -0500 |
| Message-ID | <EzQ$PTkTHczB@eisner.encompasserve.org> |
| In reply to | #481 |
billg999@cs.uofs.edu (Bill Gunshannon) writes: > OK, I guess that is another point of view thing. While i agree that disks > tend to be blocked they do deliver the raw data when asked and the actual > sectoring never makes it off the disk. As for tape and ethernet, even > the blocking data is just other byte values. Now, card, there is the > anomaly. But I guess in the long run regardless of what the card looked > like the date was delivered as single characters. (I really wish I > could get a card reader for my collection!!) I've worked with bocked and unblocked tapes, and I know 8mm drives have to do things to make them look blocked, but on 9-track tape the blocking data is not a byte value. A data block on a 9 track tape starts with a physical sync pattern, then the data, ends with a sync pattern, and is followed by erased space before the next block. Larger blocks on tape are done by writing physically longer collections of bits between the sync patterns. How this is done got more sophisticated over the years, with 6250 BPI tapes actually recorded at about 9000 bits per inch, using the extra bits to provide the redundancy to recover from errors expected at that high a dentity.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-26 09:59 -0700 |
| Message-ID | <irm0ti$s2n$2@Iltempo.Update.UU.SE> |
| In reply to | #502 |
On 2011-05-26 05.53, Bob Koehler wrote: > billg999@cs.uofs.edu (Bill Gunshannon) writes: > >> OK, I guess that is another point of view thing. While i agree that disks >> tend to be blocked they do deliver the raw data when asked and the actual >> sectoring never makes it off the disk. As for tape and ethernet, even >> the blocking data is just other byte values. Now, card, there is the >> anomaly. But I guess in the long run regardless of what the card looked >> like the date was delivered as single characters. (I really wish I >> could get a card reader for my collection!!) > > I've worked with bocked and unblocked tapes, and I know 8mm drives > have to do things to make them look blocked, but on 9-track tape the > blocking data is not a byte value. Right. But even more than that, 8mm tape drives behave exactly the same way as older 1/2" tapes from the user point of view. You read/write blocks. You can skip forward/backward by block and file. You have the tape marks, and so on. It might be that the actual encoding on the tape looks different (it probably do), but from the interface point of view, there are no differences. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> |
|---|---|
| Date | 2011-05-26 10:03 +0200 |
| Message-ID | <ca153e9bfef326a996baaf84b7c84d6f@msgid.frell.theremailer.net> |
| In reply to | #478 |
billg999@cs.uofs.edu (Bill Gunshannon) wrote: > I guess the problem with that would be which Unix? :-) > And even among similar OSes that doesn't always work. BSD has > "Linux Compatability" but I have seen more programs that didn't > work under it than did. That doesn't make sense. As far as I know it works 100%. > Oh well, as I said, it is all really academic as: > 1. I don't expect the source to RSTS or RSX to be released. > 2. Even if I am wrong about 1. above it is likely to be done > under a license that is not commercially friendly. > 3. Given 1. above it is unlikely that any attempt to re-write > RSTS or RSX is ever likely to happen. That is counter-intuitive. Given that RSTS or RSX aren't released in source, isn't that the perfect reason to re (write) them? > 4. Even if I am wrong about 3. above it would probably end out > being something as stupid as FreeVMS which in the long run will > be nothing but a DCLish shell running on top of Linux which is > not and never could be any kind of VMS. I wouldn't be so sure. Look at the hardware emulators people have written for things like z/Arch and x86 and even PDP-11 etc. If they can write that, they can write an OS that works like an existing OS. It's not any harder. In the case of UNIX it was easier to write the OS than write an emulator. In the case of z/Arch it was easier to write the emulator than the OS. But you can do anything if you have enough time, money, and good people. Oh yeah, and demand. Or somebody just crazy enough to do it.
[toc] | [prev] | [next] | [standalone]
| From | paramucho@hotmail.com (paramucho) |
|---|---|
| Date | 2011-05-26 14:21 +0000 |
| Message-ID | <4dde5d3f.2187617@news.optusnet.com.au> |
| In reply to | #501 |
On Thu, 26 May 2011 10:03:27 +0200, Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> wrote: >billg999@cs.uofs.edu (Bill Gunshannon) wrote: > >> I guess the problem with that would be which Unix? :-) >> And even among similar OSes that doesn't always work. BSD has >> "Linux Compatability" but I have seen more programs that didn't >> work under it than did. > >That doesn't make sense. As far as I know it works 100%. > >> Oh well, as I said, it is all really academic as: >> 1. I don't expect the source to RSTS or RSX to be released. >> 2. Even if I am wrong about 1. above it is likely to be done >> under a license that is not commercially friendly. >> 3. Given 1. above it is unlikely that any attempt to re-write >> RSTS or RSX is ever likely to happen. > >That is counter-intuitive. Given that RSTS or RSX aren't released in source, >isn't that the perfect reason to re (write) them? Precisely. It's quite possible that none of the DEC sources for their major systems will ever be officially placed in the public domain. >> 4. Even if I am wrong about 3. above it would probably end out >> being something as stupid as FreeVMS which in the long run will >> be nothing but a DCLish shell running on top of Linux which is >> not and never could be any kind of VMS. > >I wouldn't be so sure. Look at the hardware emulators people have written >for things like z/Arch and x86 and even PDP-11 etc. If they can write that, >they can write an OS that works like an existing OS. It's not any harder. In >the case of UNIX it was easier to write the OS than write an emulator. In >the case of z/Arch it was easier to write the emulator than the OS. It's often the libraries that are the killers. > But you >can do anything if you have enough time, money, and good people. Oh yeah, >and demand. Or somebody just crazy enough to do it. Well, there's no demand, so I guess it must be the latter that explains why I spend on average two months a year rewriting and extending my versions of DEC O/S's. I find the exercise relaxing--it's like fixing up and polishing an old car to make it roadworthy again. A few days ago I went back to my half-completed rewrites of PATCH, DUMP and SEARCH and took them to the next stage of completion. These were in fact re-rewrites! Today finished off the first version of a library module for stand-alone apps to decode DCL-style commands. At present I'm staring into space trying, yet again, to solve an old problem: how do you rewrite MACRO and LINK in a high-level language and still find enough space for the symbol tables while remaining compatible with the smaller systems and I think I've finally made a choice. What better way could I possibly find to occupy my time? Ian
[toc] | [prev] | [next] | [standalone]
| From | billy@MIX.COM |
|---|---|
| Date | 2011-05-26 18:50 +0000 |
| Message-ID | <irm7ed$l6n$1@reader1.panix.com> |
| In reply to | #504 |
In vmsnet.pdp-11 paramucho <paramucho@hotmail.com> wrote, quoting
Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net>:
> It's often the libraries that are the killers.
Yes, that's for sure.
> > But you can do anything if you have enough time, money, and
> > good people. Oh yeah, and demand. Or somebody just crazy enough
> > to do it.
>
> Well, there's no demand, so I guess it must be the latter that
> explains why I spend on average two months a year rewriting and
> extending my versions of DEC O/S's. I find the exercise relaxing--it's
> like fixing up and polishing an old car to make it roadworthy again.
I started work on Kermit because I needed it, but in the end it
became making an old car roadworthy again. Polishing in my case
included trying to provide a good example of how I think PDP-11
assembly language should be used, as at the time it was still
being taught to college students starting to study programming.
That was definitely more fun than most of what I do now. Heh.
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
[toc] | [prev] | [next] | [standalone]
| From | paramucho@hotmail.com (paramucho) |
|---|---|
| Date | 2011-05-27 11:58 +0000 |
| Message-ID | <4de08f1c.7375774@news.optusnet.com.au> |
| In reply to | #511 |
On Thu, 26 May 2011 18:50:54 +0000 (UTC), billy@MIX.COM wrote: >In vmsnet.pdp-11 paramucho <paramucho@hotmail.com> wrote, quoting >Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net>: > >> It's often the libraries that are the killers. > >Yes, that's for sure. > >> > But you can do anything if you have enough time, money, and >> > good people. Oh yeah, and demand. Or somebody just crazy enough >> > to do it. >> >> Well, there's no demand, so I guess it must be the latter that >> explains why I spend on average two months a year rewriting and >> extending my versions of DEC O/S's. I find the exercise relaxing--it's >> like fixing up and polishing an old car to make it roadworthy again. > >I started work on Kermit because I needed it, but in the end it >became making an old car roadworthy again. Polishing in my case >included trying to provide a good example of how I think PDP-11 >assembly language should be used, as at the time it was still >being taught to college students starting to study programming. One day, about a decade ago, I looked at my box of a thousand floppies and had the thought that the original work on all the disks would have cost in the millions. I figured that if I had an old car that was worth that much then I probably would keep it polished. BTW: I notice that after 30 years Columbia at putting THE KERMIT PROJECT, the world's first real open source project, into cold storage as of July 1. I was thinking today of a mad Swiss programmer, "Hanse", who did some work on RT-11 Kermit back in the mid 1980s--in a one-week visit to my company in a small German village he more of the locals than I did in a decade He worked all day and then hit the local pubs. Ian
[toc] | [prev] | [next] | [standalone]
| From | billy@MIX.COM |
|---|---|
| Date | 2011-05-27 17:23 +0000 |
| Message-ID | <iromna$hdb$1@reader1.panix.com> |
| In reply to | #526 |
In vmsnet.pdp-11 paramucho <paramucho@hotmail.com> wrote:
> BTW: I notice that after 30 years Columbia at putting THE KERMIT
> PROJECT, the world's first real open source project, into cold storage
> as of July 1.
Wow. I just looked... Thanks for letting me know.
> I was thinking today of a mad Swiss programmer, "Hanse", who did some
> work on RT-11 Kermit back in the mid 1980s--in a one-week visit to my
> company in a small German village he more of the locals than I did in
> a decade He worked all day and then hit the local pubs.
Some of his work was very helpful to me, and is in the Kermit I maintain.
In particular the modem handler (KM). I'd call him a Babe Ruth (famous
American baseball player) of software - drink 12+ beers the night before
a world series game, then play incredibly well...
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-26 10:04 -0700 |
| Message-ID | <irm17p$s8g$1@Iltempo.Update.UU.SE> |
| In reply to | #501 |
On 2011-05-26 01.03, Fritz Wuehler wrote: > billg999@cs.uofs.edu (Bill Gunshannon) wrote: > >> I guess the problem with that would be which Unix? :-) >> And even among similar OSes that doesn't always work. BSD has >> "Linux Compatability" but I have seen more programs that didn't >> work under it than did. > > That doesn't make sense. As far as I know it works 100%. Oh, believe me, it does not. I can easily give you a list of Linux programs you can not run on a BSD system, with Linux compatibility. Not all system calls are emulated perfectly, and sometimes programs have additional tricks going on out in the system, which is even harder to emulate. >> Oh well, as I said, it is all really academic as: >> 1. I don't expect the source to RSTS or RSX to be released. >> 2. Even if I am wrong about 1. above it is likely to be done >> under a license that is not commercially friendly. >> 3. Given 1. above it is unlikely that any attempt to re-write >> RSTS or RSX is ever likely to happen. > > That is counter-intuitive. Given that RSTS or RSX aren't released in source, > isn't that the perfect reason to re (write) them? I agree. If the goal is a rewrite, then the status of the current code seems irrelevant. >> 4. Even if I am wrong about 3. above it would probably end out >> being something as stupid as FreeVMS which in the long run will >> be nothing but a DCLish shell running on top of Linux which is >> not and never could be any kind of VMS. > > I wouldn't be so sure. Look at the hardware emulators people have written > for things like z/Arch and x86 and even PDP-11 etc. If they can write that, > they can write an OS that works like an existing OS. It's not any harder. In > the case of UNIX it was easier to write the OS than write an emulator. In > the case of z/Arch it was easier to write the emulator than the OS. But you > can do anything if you have enough time, money, and good people. Oh yeah, > and demand. Or somebody just crazy enough to do it. It's two different things. And one does not imply the other. Implementing VMS as a library/program on top of Linux is a whole different ballpark than writing a CPU emulator on top of Linux. The requirements for the emulator of the CPU is that you need to perform the rather well defined, and limited set of operations that the CPU perform. The OS on the other hand have a very rich set of functions and features. Mostly well documented, admittedly, but some of those functions can be much harder to implement on a OS that have a different paradigm. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> |
|---|---|
| Date | 2011-05-27 03:30 +0200 |
| Message-ID | <982e99c70332e762155dff3bb558fd4b@msgid.frell.theremailer.net> |
| In reply to | #510 |
Johnny Billquist <bqt@softjar.se> wrote: > On 2011-05-26 01.03, Fritz Wuehler wrote: > > billg999@cs.uofs.edu (Bill Gunshannon) wrote: > > > >> I guess the problem with that would be which Unix? :-) > >> And even among similar OSes that doesn't always work. BSD has > >> "Linux Compatability" but I have seen more programs that didn't > >> work under it than did. > > > > That doesn't make sense. As far as I know it works 100%. > > Oh, believe me, it does not. I can easily give you a list of Linux > programs you can not run on a BSD system, with Linux compatibility. > Not all system calls are emulated perfectly, and sometimes programs have > additional tricks going on out in the system, which is even harder to > emulate. I only have experience with Linux emulation under NetBSD but in two years of using it with several programs I never saw anything break. I try to avoid it though and now I am much more careful not to build anything with Linux dependencies on BSD systems. I really don't like the bloat and RH libs. I guess bottom line is for maybe a hardcore user you can find stuff that doesn't work. I don't think a normal desktop user who uses Linux emulation will run into problems. Maybe I am wrong but at least the solution is easy. > It's two different things. And one does not imply the other. > Implementing VMS as a library/program on top of Linux is a whole > different ballpark than writing a CPU emulator on top of Linux. I didn't read in the thread anybody was crazy enough to implement VMS on top of Linux. I wouldn't wish that on my worst enemy. Ok, maybe I would. The emulators I know aren't Linux-specific anyway. If you are going to really rewrite VMS or any OS I don't know of any reason except trying to be el-cheapo like an accountant to do it on top of an existing (broken, since we agree all the modern choices suck) OS. Write it to run on the metal. There are enough guys around who can still write x86 assembly who should be able to make it happen. I hate x86 but there aren't much choices. I dread having to code on a PC since nothing I like runs on one. I am very happy with my work machines (z/OS). Maybe ARM or some other RISC chip will come back now that Intel is moving away from desktop and we can actually have a good processor to code on again. > The requirements for the emulator of the CPU is that you need to perform > the rather well defined, and limited set of operations that the CPU > perform. That's not true. I can think of at least two major architectures where although the ISA is defined, many things are implementation specific. Sparc and System Z fall into those categories. If you think it's a simple matter of just hard work to write a Z emulator like they did (Hercules390.org) then look at the IBM manual called z Architecture Principles of Operation. I think it's about 1600 pages. That's just the description of the ISA and CPU environment. Nothing about the OS is included. Even pure x86 emulation today would be extremely difficult, the instruction set is huge. > The OS on the other hand have a very rich set of functions and features. > Mostly well documented, admittedly, but some of those functions can be > much harder to implement on a OS that have a different paradigm. Right, so do it on the metal. The whole point is making the OS you want. Why cripple it from the start by tying it to a system you don't want? Interesting what Palm did in their last versions. All Palm was M68K until the last models, they started to use ARM cores. They built a hardware emulation layer of M68K on the ARM so 68K or ARM code would run. If you want to approach the VMS project in a similar way you could begin by writing a VMS emulation layer on x86 and then writing your OS on top of the VMS architecture as if there were no x86 issues. Having the emulation layer separated from the OS will make everything nice and clean. It will also give you the capability to run the same OS on FPGA if you code your emulation layer, you won't have dependency on the metal. You will only have an architectural dependency, and it will be safe and sound back here in 1955 all over again. Main point I think is to break up the project into creating emulated VAX machine and new VMS OS. That is what I would do. If you can live with the old OS and you can obtain copies then all you have to do is write the hardware emulation and you don't even need to write the OS. I don't know VMS but in general this approach sounds good and doable with any OS rewrite IF the OS you want to rewrite was targeted for a different architecture. Some OS are more or less hardware centric and what I suggest is for those that are very hardware centric because z/OS for example is very much like that. As we know, Linux and UNIX are much less so. It all depends on how the OS and hardware work together and were designed.
[toc] | [prev] | [next] | [standalone]
| From | kludge@panix.com (Scott Dorsey) |
|---|---|
| Date | 2011-05-26 22:17 -0400 |
| Message-ID | <irn1j1$3$1@panix2.panix.com> |
| In reply to | #520 |
Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> wrote: > >I only have experience with Linux emulation under NetBSD but in two years of >using it with several programs I never saw anything break. I try to avoid it >though and now I am much more careful not to build anything with Linux >dependencies on BSD systems. I really don't like the bloat and RH libs. I >guess bottom line is for maybe a hardcore user you can find stuff that >doesn't work. I don't think a normal desktop user who uses Linux emulation >will run into problems. Maybe I am wrong but at least the solution is easy. The solution is to write good, clean, portable, non-bloated code. I used to think this was easy but I am frequently amazed at how difficult people seem to find it. As more and more folks move to a smaller and smaller set of operating systems, convincing people that portability and cleanliness is important becomes more difficult. --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis."
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-26 20:26 -0700 |
| Message-ID | <irn5lg$8dp$1@Iltempo.Update.UU.SE> |
| In reply to | #520 |
On 2011-05-26 18.30, Fritz Wuehler wrote:
> Johnny Billquist<bqt@softjar.se> wrote:
>
>> On 2011-05-26 01.03, Fritz Wuehler wrote:
>>> billg999@cs.uofs.edu (Bill Gunshannon) wrote:
>>>
>>>> I guess the problem with that would be which Unix? :-)
>>>> And even among similar OSes that doesn't always work. BSD has
>>>> "Linux Compatability" but I have seen more programs that didn't
>>>> work under it than did.
>>>
>>> That doesn't make sense. As far as I know it works 100%.
>>
>> Oh, believe me, it does not. I can easily give you a list of Linux
>> programs you can not run on a BSD system, with Linux compatibility.
>> Not all system calls are emulated perfectly, and sometimes programs have
>> additional tricks going on out in the system, which is even harder to
>> emulate.
>
> I only have experience with Linux emulation under NetBSD but in two years of
> using it with several programs I never saw anything break. I try to avoid it
> though and now I am much more careful not to build anything with Linux
> dependencies on BSD systems. I really don't like the bloat and RH libs. I
> guess bottom line is for maybe a hardcore user you can find stuff that
> doesn't work. I don't think a normal desktop user who uses Linux emulation
> will run into problems. Maybe I am wrong but at least the solution is easy.
If you just use the programs that are in the NetBSD package system, then
you will never discover the software that don't work, since it will not
be in the package system. :-)
But read the NetBSD-current mailing list, and you'll find discussions
that regularly pop up about people having problems with Linux programs
in NetBSD (I dabble some in NetBSD kernel development from time to time,
so I see those mails.)
>> It's two different things. And one does not imply the other.
>> Implementing VMS as a library/program on top of Linux is a whole
>> different ballpark than writing a CPU emulator on top of Linux.
>
> I didn't read in the thread anybody was crazy enough to implement VMS on top
> of Linux. I wouldn't wish that on my worst enemy. Ok, maybe I would. The
> emulators I know aren't Linux-specific anyway.
Well, the quote above was:
"4. Even if I am wrong about 3. above it would probably end out
being something as stupid as FreeVMS which in the long run will
be nothing but a DCLish shell running on top of Linux which is
not and never could be any kind of VMS."
So, the claim was/is that FreeVMS is basically an attempt at
implementing something VMS-like (or atleast DCL-like) on top of Linux.
Anyway, I think we agree that you don't want to do this, and it's better
to implement for the bare metal.
Johnny
[toc] | [prev] | [next] | [standalone]
| From | John Wallace <johnwallace4@yahoo.co.uk> |
|---|---|
| Date | 2011-05-30 14:09 -0700 |
| Message-ID | <be89deff-922f-47b3-b3c6-6be21ed86322@a26g2000vbo.googlegroups.com> |
| In reply to | #520 |
On May 27, 2:30 am, Fritz Wuehler <fr...@spamexpire-201105.rodent.frell.theremailer.net> wrote: > Johnny Billquist <b...@softjar.se> wrote: > > On 2011-05-26 01.03, Fritz Wuehler wrote: > > > billg...@cs.uofs.edu (Bill Gunshannon) wrote: > > > >> I guess the problem with that would be which Unix? :-) > > >> And even among similar OSes that doesn't always work. BSD has > > >> "Linux Compatability" but I have seen more programs that didn't > > >> work under it than did. > > > > That doesn't make sense. As far as I know it works 100%. > > > Oh, believe me, it does not. I can easily give you a list of Linux > > programs you can not run on a BSD system, with Linux compatibility. > > Not all system calls are emulated perfectly, and sometimes programs have > > additional tricks going on out in the system, which is even harder to > > emulate. > > I only have experience with Linux emulation under NetBSD but in two years of > using it with several programs I never saw anything break. I try to avoid it > though and now I am much more careful not to build anything with Linux > dependencies on BSD systems. I really don't like the bloat and RH libs. I > guess bottom line is for maybe a hardcore user you can find stuff that > doesn't work. I don't think a normal desktop user who uses Linux emulation > will run into problems. Maybe I am wrong but at least the solution is easy. > > > It's two different things. And one does not imply the other. > > Implementing VMS as a library/program on top of Linux is a whole > > different ballpark than writing a CPU emulator on top of Linux. > > I didn't read in the thread anybody was crazy enough to implement VMS on top > of Linux. I wouldn't wish that on my worst enemy. Ok, maybe I would. The > emulators I know aren't Linux-specific anyway. > > If you are going to really rewrite VMS or any OS I don't know of any reason > except trying to be el-cheapo like an accountant to do it on top of an > existing (broken, since we agree all the modern choices suck) OS. Write it > to run on the metal. There are enough guys around who can still write x86 > assembly who should be able to make it happen. I hate x86 but there aren't > much choices. I dread having to code on a PC since nothing I like runs on > one. I am very happy with my work machines (z/OS). Maybe ARM or some other > RISC chip will come back now that Intel is moving away from desktop and we > can actually have a good processor to code on again. > > > The requirements for the emulator of the CPU is that you need to perform > > the rather well defined, and limited set of operations that the CPU > > perform. > > That's not true. I can think of at least two major architectures where > although the ISA is defined, many things are implementation specific. Sparc > and System Z fall into those categories. If you think it's a simple matter > of just hard work to write a Z emulator like they did (Hercules390.org) then > look at the IBM manual called z Architecture Principles of Operation. I > think it's about 1600 pages. That's just the description of the ISA and CPU > environment. Nothing about the OS is included. Even pure x86 emulation today > would be extremely difficult, the instruction set is huge. > > > The OS on the other hand have a very rich set of functions and features. > > Mostly well documented, admittedly, but some of those functions can be > > much harder to implement on a OS that have a different paradigm. > > Right, so do it on the metal. The whole point is making the OS you want. Why > cripple it from the start by tying it to a system you don't want? > > Interesting what Palm did in their last versions. All Palm was M68K until > the last models, they started to use ARM cores. They built a hardware > emulation layer of M68K on the ARM so 68K or ARM code would run. > > If you want to approach the VMS project in a similar way you could begin by > writing a VMS emulation layer on x86 and then writing your OS on top of the > VMS architecture as if there were no x86 issues. Having the emulation layer > separated from the OS will make everything nice and clean. It will also give > you the capability to run the same OS on FPGA if you code your emulation > layer, you won't have dependency on the metal. You will only have an > architectural dependency, and it will be safe and sound back here in 1955 > all over again. Main point I think is to break up the project into creating > emulated VAX machine and new VMS OS. That is what I would do. If you can > live with the old OS and you can obtain copies then all you have to do is > write the hardware emulation and you don't even need to write the OS. > > I don't know VMS but in general this approach sounds good and doable with > any OS rewrite IF the OS you want to rewrite was targeted for a different > architecture. Some OS are more or less hardware centric and what I suggest > is for those that are very hardware centric because z/OS for example is very > much like that. As we know, Linux and UNIX are much less so. It all depends > on how the OS and hardware work together and were designed. "Even pure x86 emulation today would be extremely difficult, the instruction set is huge. " If I've understood you right, you've not seen the PC emulator written in JavaScript that's floating around the Internerd of late? It emulates not just the x86 CPU core but also enough PC IO to (in the distributed demo) get a small Linux booted; there's no obvious technical reason why it wouldn't do any other x86-based OS. It was written by a rather smart chap called Fabrice Bellard (he also did ffmpeg and QEMU) and I wouldn't like to do it myself but since it's already available it's no longer extremely difficult, and the source code isn't *that* huge.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-30 18:15 -0700 |
| Message-ID | <is1feu$ts4$1@Iltempo.Update.UU.SE> |
| In reply to | #542 |
On 2011-05-30 14.09, John Wallace wrote: > On May 27, 2:30 am, Fritz Wuehler > <fr...@spamexpire-201105.rodent.frell.theremailer.net> wrote: > "Even pure x86 emulation today would be extremely difficult, the > instruction set is huge. " > > If I've understood you right, you've not seen the PC emulator written > in JavaScript that's floating around the Internerd of late? It > emulates not just the x86 CPU core but also enough PC IO to (in the > distributed demo) get a small Linux booted; there's no obvious > technical reason why it wouldn't do any other x86-based OS. > > It was written by a rather smart chap called Fabrice Bellard (he also > did ffmpeg and QEMU) and I wouldn't like to do it myself but since > it's already available it's no longer extremely difficult, and the > source code isn't *that* huge. CPU emulation really isn't that difficult. I don't know why he claimed that. Emulating all of I/O subsystems, graphics, and so on, can be a little more work, but still not really any magic. And yes, I've seen the x86 emulator in JavaScript. (I haven't tried it, though.) Johnny
[toc] | [prev] | [next] | [standalone]
| From | jjh <jjhudak@gmail.com> |
|---|---|
| Date | 2011-05-31 11:02 -0700 |
| Message-ID | <aaa2ed58-b094-4584-9b7f-311743605e48@b1g2000yql.googlegroups.com> |
| In reply to | #542 |
On May 30, 5:09 pm, John Wallace <johnwalla...@yahoo.co.uk> wrote: > On May 27, 2:30 am, Fritz Wuehler > > > > > > <fr...@spamexpire-201105.rodent.frell.theremailer.net> wrote: > > Johnny Billquist <b...@softjar.se> wrote: > > > On 2011-05-26 01.03, Fritz Wuehler wrote: > > > > billg...@cs.uofs.edu (Bill Gunshannon) wrote: > > > > >> I guess the problem with that would be which Unix? :-) > > > >> And even among similar OSes that doesn't always work. BSD has > > > >> "Linux Compatability" but I have seen more programs that didn't > > > >> work under it than did. > > > > > That doesn't make sense. As far as I know it works 100%. > > > > Oh, believe me, it does not. I can easily give you a list of Linux > > > programs you can not run on a BSD system, with Linux compatibility. > > > Not all system calls are emulated perfectly, and sometimes programs have > > > additional tricks going on out in the system, which is even harder to > > > emulate. > > > I only have experience with Linux emulation under NetBSD but in two years of > > using it with several programs I never saw anything break. I try to avoid it > > though and now I am much more careful not to build anything with Linux > > dependencies on BSD systems. I really don't like the bloat and RH libs. I > > guess bottom line is for maybe a hardcore user you can find stuff that > > doesn't work. I don't think a normal desktop user who uses Linux emulation > > will run into problems. Maybe I am wrong but at least the solution is easy. > > > > It's two different things. And one does not imply the other. > > > Implementing VMS as a library/program on top of Linux is a whole > > > different ballpark than writing a CPU emulator on top of Linux. > > > I didn't read in the thread anybody was crazy enough to implement VMS on top > > of Linux. I wouldn't wish that on my worst enemy. Ok, maybe I would. The > > emulators I know aren't Linux-specific anyway. > > > If you are going to really rewrite VMS or any OS I don't know of any reason > > except trying to be el-cheapo like an accountant to do it on top of an > > existing (broken, since we agree all the modern choices suck) OS. Write it > > to run on the metal. There are enough guys around who can still write x86 > > assembly who should be able to make it happen. I hate x86 but there aren't > > much choices. I dread having to code on a PC since nothing I like runs on > > one. I am very happy with my work machines (z/OS). Maybe ARM or some other > > RISC chip will come back now that Intel is moving away from desktop and we > > can actually have a good processor to code on again. > > > > The requirements for the emulator of the CPU is that you need to perform > > > the rather well defined, and limited set of operations that the CPU > > > perform. > > > That's not true. I can think of at least two major architectures where > > although the ISA is defined, many things are implementation specific. Sparc > > and System Z fall into those categories. If you think it's a simple matter > > of just hard work to write a Z emulator like they did (Hercules390.org) then > > look at the IBM manual called z Architecture Principles of Operation. I > > think it's about 1600 pages. That's just the description of the ISA and CPU > > environment. Nothing about the OS is included. Even pure x86 emulation today > > would be extremely difficult, the instruction set is huge. > > > > The OS on the other hand have a very rich set of functions and features. > > > Mostly well documented, admittedly, but some of those functions can be > > > much harder to implement on a OS that have a different paradigm. > > > Right, so do it on the metal. The whole point is making the OS you want. Why > > cripple it from the start by tying it to a system you don't want? > > > Interesting what Palm did in their last versions. All Palm was M68K until > > the last models, they started to use ARM cores. They built a hardware > > emulation layer of M68K on the ARM so 68K or ARM code would run. > > > If you want to approach the VMS project in a similar way you could begin by > > writing a VMS emulation layer on x86 and then writing your OS on top of the > > VMS architecture as if there were no x86 issues. Having the emulation layer > > separated from the OS will make everything nice and clean. It will also give > > you the capability to run the same OS on FPGA if you code your emulation > > layer, you won't have dependency on the metal. You will only have an > > architectural dependency, and it will be safe and sound back here in 1955 > > all over again. Main point I think is to break up the project into creating > > emulated VAX machine and new VMS OS. That is what I would do. If you can > > live with the old OS and you can obtain copies then all you have to do is > > write the hardware emulation and you don't even need to write the OS. > > > I don't know VMS but in general this approach sounds good and doable with > > any OS rewrite IF the OS you want to rewrite was targeted for a different > > architecture. Some OS are more or less hardware centric and what I suggest > > is for those that are very hardware centric because z/OS for example is very > > much like that. As we know, Linux and UNIX are much less so. It all depends > > on how the OS and hardware work together and were designed. > > "Even pure x86 emulation today would be extremely difficult, the > instruction set is huge. " > > If I've understood you right, you've not seen the PC emulator written > in JavaScript that's floating around the Internerd of late? It > emulates not just the x86 CPU core but also enough PC IO to (in the > distributed demo) get a small Linux booted; there's no obvious > technical reason why it wouldn't do any other x86-based OS. > > It was written by a rather smart chap called Fabrice Bellard (he also > did ffmpeg and QEMU) and I wouldn't like to do it myself but since > it's already available it's no longer extremely difficult, and the > source code isn't *that* huge.- Hide quoted text - > > - Show quoted text - while I agree that software emulation has some benefits, it seems a more reasonable approach is to cast the hw archtecture in an FPGA. I was recently doing this exercise and came across a few implementations of the PDP11 archtecture, and the VAX, that fit on a Xilinx Virtex FPGA. The one design included MMU and unibus emulation, as well as one or two 'standard' DEC peripherals. There are some full blown x86 ip cores around as well. To make the FPGA implementations more 'universal,' the hardware templates for the buses and their associated state machines would have to be done for whatever machine the FPGA board would plug into. Alternatively, if the peripherials would be implemented on the same FPGA, only the interfaces of interest would need to be brought out of the FPGA board, i.e. serial lines, pata or sata disk interface, etc. If native bus compatability is not mandantory, then a lot of the developer boards by various FPGA manufactures could be used. My point is, a lot of the older processor archtectures have close to or 100% compliant IP cores. There is even one for the Apollo 11 Lunar Landar flight computer that runs release B of the lander code. So why struggle with a sw emulation? (aside from the fact that it can easiliy run on a PC). -John
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.encompasserve.org (Bob Koehler) |
|---|---|
| Date | 2011-05-31 15:54 -0500 |
| Message-ID | <pgdbNEOyQBYa@eisner.encompasserve.org> |
| In reply to | #551 |
In article <aaa2ed58-b094-4584-9b7f-311743605e48@b1g2000yql.googlegroups.com>, jjh <jjhudak@gmail.com> writes: > > My point is, a lot of the older processor archtectures have close to > or 100% compliant IP cores. There is even one for the Apollo 11 Lunar > Landar flight computer that runs release B of the lander code. > So why struggle with a sw emulation? (aside from the fact that it can > easiliy run on a PC). Exactly. There are a hell of a lot of software folks and end users who can download another piece of software and get it to run, but haven't got the foggiest of how to burn an FPGA, don't have an FPGA burner, and don't want one.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-05-31 21:37 +0000 |
| Message-ID | <is3n2q$9eg$2@dont-email.me> |
| In reply to | #552 |
In vmsnet.pdp-11 Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote: (snip) > Exactly. There are a hell of a lot of software folks and end users > who can download another piece of software and get it to run, but > haven't got the foggiest of how to burn an FPGA, don't have an FPGA > burner, and don't want one. Conveniently, the usual FPGAs don't burn at all. They use SRAM cells to store configuration bits, which then go away on power-down. -- glen
[toc] | [prev] | [next] | [standalone]
| From | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-05-24 22:59 -0400 |
| Message-ID | <4ddc7062$0$314$14726298@news.sunsite.dk> |
| In reply to | #473 |
[Multipart message — attachments visible in raw view] — view raw
Can Johnny fill out the RSX-11 values and someone else the RSTS/E values? Also, add operating system features which are felt to be important. There has been some discussion as to the reasons for the migration to faster hardware with larger disk drives. Since Ersatz-11 and SIMH have been available for more than 10 years, a number of commercial users have continued to run using the PDP-11 architecture. However, I expect that these few examples were more the exception than the rule. With limited Y2K support that was sometimes available only a couple of years before the deadline, many users gave up on DEC with some justification. One aspect that I find confusing is the size of a device as opposed to the size of a file. As far as I understand, the maximum size of a file under RSTS/E is still 65536 blocks or 32 MB. While I agree that RT-11 also limits the device size to 32 MB, if RSTS/E supports files only up to 32 MB, how does that make RSTS/E any better than RT-11 in respect of the size of files if the size limits are the same? Like many others who have been reading and writing to this thread, it has been a source of much information. However, in reference to the hardware limitations of the PDP-11 under various operating systems, I only have direct experience with RT-11, TSX-Plus and a bit of RSTS/E. In order to understand some of the problems of why migration to 32 and 64 bit hardware took place, perhaps a table could be filled in. Note that my very rough benchmarks running RT-11 under Ersatz-11 under Windows XP on a core 2 duo system at 2.63 GHz and 4 GB of physical memory provide a speed greater than 100 times a PDP-11/93 for the CPU. Disk I/O throughput is greater than 200 times a SCSI hard drive on a CQD 220/TM host adapter when SATA II 1 TB 3.5" hard drives are used to copy and compare 32 MB files on different physical hard drives. For example, it takes less than 1 second to copy a 32 MB file under Ersatz-11 vs about 240 seconds on a real PDP-11/93. Maximum RT-11 TSX-Plus RSX-11 RSTS/E ---------- ------- ---------- -------- --------- Instructions: 64 KB 64 KB Data (No I/D) INCL INCL Data (I/D) 64 KB 64KB Data (Ersatz-11)* >1 GB >1 GB?? Maximum Jobs: 8 32 Scheduling: Job# Complex Device:(Hard Disk) 65536 65536 File:(FS Hard Disk) 65528 65528 Max Files: 255 255 Synchronous I/O Yes Yes File Sharing No Yes All Hard Disk sizes are specified in blocks of 512 bytes. *Ersatz-11 provides EMEM.DLL which has been tested with Windows 98 SE and Windows XP. With a physical memory of 768 MB, Windows 98 SE supports >600 MB of access to PC memory under RT-11. With a physical memory of 4 GB, Windows XP supports >1280 MB of access to PC memory under RT-11. Fast access to PC memory is best done via current USER access to the IOPAGE registers, however fast access is also possible with previous USER access to the IOPAGE registers using the MFPS and MTPS instructions. Benchmarks in respect of access time show that it takes about three times as long to access a 16 bit word of PC memory vs a normal access of a 16 bit word. FORTRAN IV and 77 functions and subroutines are available which provide the user with a convenient, user friendly access to the PC memory. Note that under TSX-Plus, only fully tested programs should be allowed access and probably additional functions must be provided if sharing of PC memory among multiple programs is to be provided.
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-25 03:51 -0700 |
| Message-ID | <irin0j$phk$1@Iltempo.Update.UU.SE> |
| In reply to | #485 |
On 2011-05-24 19.59, Jerome H. Fine wrote: > Can Johnny fill out the RSX-11 values and someone else the > RSTS/E values? Also, add operating system features which > are felt to be important. Not really sure what you want me to fill in, but I'll try to make comments on your table. > Maximum RT-11 TSX-Plus RSX-11 RSTS/E > ---------- ------- ---------- -------- --------- > > Instructions: 64 KB 64 KB What is this? Addressable virtual address space? > Data (No I/D) INCL INCL > Data (I/D) 64 KB 64KB I guess we're talking about directly addressable virtual address space. This is not OS dependent. It is a function of the architecture, and will be the same on all OSes running on a PDP-11, with the following caveats: If MMU is not enabled, then you have different rules. If the OS don't support split I/D-space, then you cannot use it, even if the hardware supports it. I'm not sure if it is relevant to talk about memory spaces in other ways. Like, in RSX, you can create big memory areas which you can map into and out of your virtual address space. It's sortof like mmap() in Unix, except different. But it gives an understanding about what it is to talk about mmap here. > Data (Ersatz-11)* >1 GB >1 GB?? That is a silly piece of information. We're just talking about a device here. The limits have nothing to do with anything else than the implemented device. It's not related to the OS, nor to anything else about a PDP-11. > Maximum Jobs: 8 32 Maximum jobs for RSX is not fixed. It's basically a question of when you run out of system pool. > Scheduling: Job# Complex For RSX, the scheduling is basically a strict priority scheduler. The task with the highest priority that wants to run gets the CPU. Within a specific priority level, tasks are scheduled in a simple round-robin fashion. There are 250 priority levels. And then you also have swapping, which then deals with swapping priorities, which schedules when/how a task is brought back into memory again when it wants to run, if it is swapped out. > Device:(Hard Disk) 65536 65536 Hard disks themself don't have a limit. It's just a question of the controller and disk. For SCSI disks and controllers, the current disks are reaching into the terabyte range. > File:(FS Hard Disk) 65528 65528 The RSX file system by default limits disks to 8 GB. In disk blocks we're talking about 2^24 blocks. > Max Files: 255 255 Max number of files in an RSX system is 65500 files. But then again, you can create virtual disks inside a disk, and each of those can have 65500 files as well, which means that you can go to very many files on a physical disk, by just nesting virtual disks inside it. > Synchronous I/O Yes Yes What does this mean? Can RSX do synchronous I/O? Yes, of course. It can also do asynchronous I/O. > File Sharing No Yes What do you put into the concept of file sharing? RSX can allow concurrent read-only access to files. It can allow one writer with many readers, and it can also allow multiple writers to a file. It also have disk block locking to control concurrent access to a file, so that you can have a controlled consistent view of the contents of a file. Programs also have control over what access they want to allow other programs to have to a file. Johnny
[toc] | [prev] | [next] | [standalone]
| From | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-05-25 08:36 -0400 |
| Message-ID | <4ddcf78e$0$313$14726298@news.sunsite.dk> |
| In reply to | #487 |
>Johnny Billquist wrote: > >On 2011-05-24 19.59, Jerome H. Fine wrote: > >> Can Johnny fill out the RSX-11 values and someone else the >> RSTS/E values? Also, add operating system features which >> are felt to be important. > > Not really sure what you want me to fill in, but I'll try to make > comments on your table. Thank you. I am already aware of some of the values. But others are beyond my knowledge. I will attempt to update the table from your comments. >> Maximum RT-11 TSX-Plus RSX-11 RSTS/E >> ---------- ------- ---------- -------- --------- >> >> Instructions: 64 KB 64 KB > > What is this? Addressable virtual address space? Yes - I assume that RSX-11S (without an MMU) is less than 64 KB, but when the MMU is available and execution is in USER space, 64 KB are available. RT-11 is the same. Under RT11FB (and RT11SJ), only about 32 KB are available. Under RT11XM and using VBGEXE to initiate a virtual job, 64 KB are available. Under the RT-11 RTS under RSTS/E, I have found that a bit less than 56 KB are available. Does anyone who knows RSTS/E well know if a full 64 KB are available if a RTS is not in use? >> Data (No I/D) INCL INCL >> Data (I/D) 64 KB 64KB > > I guess we're talking about directly addressable virtual address space. > This is not OS dependent. It is a function of the architecture, and > will be the same on all OSes running on a PDP-11, with the following > caveats: > If MMU is not enabled, then you have different rules. Obviously. I presume that RSX-11S and RT-11 with RT11SJ are examples. I know that TSX-Plus allows only virtual jobs which can be allowed the full 64 KB. I presume that RSTS/E also allows only virtual jobs. Can anyone confirm? > If the OS don't support split I/D-space, then you cannot use it, even > if the hardware supports it. Also true. Under RT-11, this became available in V05.06 using the RT11ZM monitor. It is probably used very little under RT-11. I know of no applications which have been written to take advantage of I/D space for RT-11. > I'm not sure if it is relevant to talk about memory spaces in other > ways. Like, in RSX, you can create big memory areas which you can map > into and out of your virtual address space. It's sortof like mmap() in > Unix, except different. But it gives an understanding about what it is > to talk about mmap here. The same concept can be used in RT-11 under RT11ZM. However, under the PDP-11 architecture, the maximum data space at any one time will always be 64 KB. However, under RT-11, the MMU can be used directly to access all 4 MB of memory (with only a small overhead of changing the MMU each time a different page of memory is to be accessed). Probably only the RT-11 operating system does this 99% of the time since it should be done only in KERNAL mode and most of the time with interrupts disabled. However, in my personal (and probably limited) experience, whenever I required more than 32 KB of data, I usually needed orders of magnitude more to be really useful. I note that one exception seems to be the MACRO-11 assembler. For most programs of reasonable size, 32 KB of data is more than sufficient and the work space does not need to be read or written. Only the very large programs such as the RT-11 Resident Monitor / KMON (which are assembled at the same time) need a work space greater than 32 KB. But when I attempt to sieve Prime Numbers, the larger the work space the better and a GB is not too large. Which leads to the next reference ... >> Data (Ersatz-11)* >1 GB >1 GB?? > > That is a silly piece of information. We're just talking about a > device here. The limits have nothing to do with anything else than the > implemented device. It's not related to the OS, nor to anything else > about a PDP-11. Well, I just added it in case anyone else is interested. With memory now so inexpensive, it would probably be reasonable to build such a device for a board (Qbus or Unibus) on a real PDP-11 and make IOPAGE registers available just as Ersatz-11 does. Image a real PDP-11 that had a device which supported 4 GB of memory so that VIRTUAL arrays in FORTRAN did not need to use PDP-11 memory. Or having a VIRTUAL disk which also did not need to use PDP-11 memory. In fact, both could be on the same board with the VIRTUAL disk being of any size and looking as if it was any type of hard disk drive, but having even better response time than with the current VIRTUAL disks using PDP-11 memory if all the MMU interaction was not required. Since a single PC stick of memory now has 4 GB, it would be easy to have a dual module for a real PDP-11. I don't know enough about hardware to design such a board, but it could not be that difficult. >> Maximum Jobs: 8 32 > > Maximum jobs for RSX is not fixed. It's basically a question of when > you run out of system pool. For TSX-Plus, I think the limit is a bit more than 32, but again memory is the problem. >> Scheduling: Job# Complex > > For RSX, the scheduling is basically a strict priority scheduler. The > task with the highest priority that wants to run gets the CPU. Same with TSX-Plus. However, the priorities are raised and lowered (within limits) depending on what the job is doing. > Within a specific priority level, tasks are scheduled in a simple > round-robin fashion. > There are 250 priority levels. > And then you also have swapping, which then deals with swapping > priorities, which schedules when/how a task is brought back into > memory again when it wants to run, if it is swapped out. I think that TSX-Plus has something similar. Can anyone please comment on RSTS/E scheduling? >> Device:(Hard Disk) 65536 65536 > > Hard disks themself don't have a limit. It's just a question of the > controller and disk. For SCSI disks and controllers, the current disks > are reaching into the terabyte range. Amazing!!!!!!!! I remember when I first purchased a MAXTOR XT8760E at $ 1 / MB at an EOL sale probably around 1995. RT-11 also supports large disk drives, just not easily. In addition, when DEC wrote the DU(X).SYS device drivers, the unit numbers up to 65535 were allowed even though every host adapter for the PDP-11 needs a maximum of about 16 units. Far better would have been to use unit numbers up to 255 and allow the RT-11 partitions up to 65535 instead. That is one of the enhancements that needs to be made to RT-11. >> File:(FS Hard Disk) 65528 65528 > > The RSX file system by default limits disks to 8 GB. In disk blocks > we're talking about 2^24 blocks. The same with RT-11 at present for the normal MSCP access. Partition numbers up to 255 are supported. HOWEVER, my actual question was the size of each individual file. Is the maximum block number 65535? Namely, is the standard block number a 16 bit word (as in RT-11) or does RSX-11 support a 32 bit block number for a file? RT-11 does have special code that supports a 32 bit block number, but it is not as convenient as normal file access. >> Max Files: 255 255 > > Max number of files in an RSX system is 65500 files. But then again, > you can create virtual disks inside a disk, and each of those can have > 65500 files as well, which means that you can go to very many files on > a physical disk, by just nesting virtual disks inside it. I was actually asking about the maximum number of OPEN files at any one time. However, your answer about the file system is also important. RT-11 allows a maximum of 2232 files in any directory. However, since every file can be regarded as a device, there is no actual limit. Naturally, any file used as a device (subset under RT-11 or logical disk - LD.SYS is used) is still limited to 65528 blocks, but with only a maximum of 2232 files in any directory, splitting a large (for RT-11 of course) device of 65536 blocks into a few smaller files which have their own directories solves many RT-11 problems. TSX-Plus is identical since the same directory structure is used. >> Synchronous I/O Yes Yes > > What does this mean? Can RSX do synchronous I/O? Yes, of course. It > can also do asynchronous I/O. Just asking. I always assumed that most operating systems allowed both types of I/O. I understand that Windows supports only synchronous I/O. What about RSTS/E? >> File Sharing No Yes > > What do you put into the concept of file sharing? RSX can allow > concurrent read-only access to files. It can allow one writer with > many readers, and it can also allow multiple writers to a file. It > also have disk block locking to control concurrent access to a file, > so that you can have a controlled consistent view of the contents of a > file. > Programs also have control over what access they want to allow other > programs to have to a file. I understand that RSTS/E also supports file sharing? Can anyone please confirm? TSX-Plus has the same sort of capability. RT-11 does not. Thank you again, Johnny. Can anyone with RSTS/E information please respond? Jerome Fine
[toc] | [prev] | [next] | [standalone]
| From | "Tom Lake" <tlake@twcny.rr.com> |
|---|---|
| Date | 2011-05-25 13:25 -0400 |
| Message-ID | <irje24$hd6$1@speranza.aioe.org> |
| In reply to | #488 |
The same concept can be used in RT-11 under RT11ZM. However, under the PDP-11 architecture, the maximum data space at any one time will always be 64 KB. However, under RT-11, the MMU can be used directly to access all 4 MB of memory (with only a small overhead of changing the MMU each time a different page of memory is to be accessed). Probably only the RT-11 operating system does this 99% of the time since it should be done only in KERNAL mode and most of the time with interrupts disabled. Do you happen to know if BASIC can take advantage of the paged memory directly (the SIZE command shows the extra) Tom Lake
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.sys.dec
csiph-web