Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Odd RX50 driver behavior on P/OS 3.2
27 views
Skip to first unread message
Lee Gleason
Dec 26, 2012, 6:20:07 PM12/26/12
to
I'm writing some programs to read and write RX50s to and from disk images
on my PRO-380, running P/OS 3.2.
The program to write a floppy works fine - reads blocks from a disk image
file using FCS, writes to the floppy using QIO IO.WLB. Program ends on end
of the input file, which, for a proper RX50 disk image is after 800 blocks.
The program to read a floppy and write a disk image file was working
really...funny. It was producing disk image files that were 801 blocks
long. I wrote it to read from the floppy using QIOW IO.RLB, watching for a
status of IE.BLK to tell me that I had read all of the blocks. Investigation
showed that it was allowing an 801st read to succeed, When I did this, it
was reading 801 blocks before getting IE.BLK. The 801st block was a
duplicate of the 1st block.
I wrote some test code and discovered that something similar occurs for
writing - it will allow writes to an 801st block - which writes onto the
first block of the floppy.
Anyone recall if this was noticed and documented back in the day?
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.g...@comcast.net
on my PRO-380, running P/OS 3.2.
The program to write a floppy works fine - reads blocks from a disk image
file using FCS, writes to the floppy using QIO IO.WLB. Program ends on end
of the input file, which, for a proper RX50 disk image is after 800 blocks.
The program to read a floppy and write a disk image file was working
really...funny. It was producing disk image files that were 801 blocks
long. I wrote it to read from the floppy using QIOW IO.RLB, watching for a
status of IE.BLK to tell me that I had read all of the blocks. Investigation
showed that it was allowing an 801st read to succeed, When I did this, it
was reading 801 blocks before getting IE.BLK. The 801st block was a
duplicate of the 1st block.
I wrote some test code and discovered that something similar occurs for
writing - it will allow writes to an 801st block - which writes onto the
first block of the floppy.
Anyone recall if this was noticed and documented back in the day?
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.g...@comcast.net
glen herrmannsfeldt
Dec 26, 2012, 7:22:35 PM12/26/12
to
Lee Gleason <lee.g...@comcast.net> wrote:
> I'm writing some programs to read and write RX50s to and from disk images
> on my PRO-380, running P/OS 3.2.
> The program to write a floppy works fine - reads blocks from a disk image
> file using FCS, writes to the floppy using QIO IO.WLB. Program ends on end
> of the input file, which, for a proper RX50 disk image is after 800 blocks.
> The program to read a floppy and write a disk image file was working
> really...funny. It was producing disk image files that were 801 blocks
> long. I wrote it to read from the floppy using QIOW IO.RLB, watching for a
> status of IE.BLK to tell me that I had read all of the blocks. Investigation
> showed that it was allowing an 801st read to succeed, When I did this, it
> was reading 801 blocks before getting IE.BLK. The 801st block was a
> duplicate of the 1st block.
Reminds me of the difference between the C and Pascal I/O model.
> I'm writing some programs to read and write RX50s to and from disk images
> on my PRO-380, running P/OS 3.2.
> The program to write a floppy works fine - reads blocks from a disk image
> file using FCS, writes to the floppy using QIO IO.WLB. Program ends on end
> of the input file, which, for a proper RX50 disk image is after 800 blocks.
> The program to read a floppy and write a disk image file was working
> really...funny. It was producing disk image files that were 801 blocks
> long. I wrote it to read from the floppy using QIOW IO.RLB, watching for a
> status of IE.BLK to tell me that I had read all of the blocks. Investigation
> showed that it was allowing an 801st read to succeed, When I did this, it
> was reading 801 blocks before getting IE.BLK. The 801st block was a
> duplicate of the 1st block.
In Pascal, one must test that one hasn't reached the end of file
before doing any file access. In C, the test only works after a read
(or write) has failed.
The latter allows for a nice simple:
while(fgets(buf,sizeof(buf),stdin))
loop.
Converting from one to the other, without correcting for the difference,
tends to give off-by-one results. (And newgroup posts asking why the
results are wrong.)
Otherwise, it looks like the system takes the block number modulo the
device size. Not too unusual.
-- glen
Johnny Billquist
Dec 27, 2012, 4:08:53 PM12/27/12
to
floppies? Maybe check the code in there? (Just a thought.)
Johnny
Lee Gleason
Dec 28, 2012, 5:54:34 PM12/28/12
to
"Johnny Billquist" wrote in message
news:kbidbl$djl$1...@Iltempo.Update.UU.SE...
>I can't recall seeing anything about that, but didn't TPC deal with RX50
>floppies? Maybe check the code in there? (Just a thought.)
>Johnny
to 800 and stops, rather than hitting the end to know when to stop. That's
what my code does now too (it works, but it's less general than going to the
end).
I was going to post a code snippet that demonstrates the issue (again, on
the remote chance anyone else in the world is still interested in P/OS), but
realized the bug can be demonstrated with DUMP.
If you mount a floppy foreign in DZ2: and
DUMP/BL:800. DZ2:
Which would be the 801st block, since they start at 0, you will see the
contents of block 0, and then an error as it tries to advance to the 802nd
block.
DUMP/BL:0 DZ2: shows the same contents as above.
DUMP/BL:799 correctly shows the contents of the last block on the diskette.
Johnny Billquist
Dec 28, 2012, 7:36:49 PM12/28/12
to
with the build files for it all. Then I could do P/OS 4.0, with all the
improvements that have happened since, as well as utilize the J-11
properly in the PRO-380... But I suspect that will never happen. :-)
Johnny
Bill Gunshannon
Dec 29, 2012, 10:46:30 AM12/29/12
to
In article <kbldtn$p1m$1...@iltempo.update.uu.se>,
And now you know how I feel. :-(
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Johnny Billquist
Dec 29, 2012, 12:22:15 PM12/29/12
to
I just wonder if any copy of the PRO-specific bits have even survived...
The situation for the "current" PDP-11 OSes are much better, but P/OS
was terminated by DEC quite a long time ago... In addition to be a
rather obscure branch even when it still was alive.
Johnny
Bill Gunshannon
Dec 29, 2012, 1:21:23 PM12/29/12
to
In article <kbn8s7$avt$1...@iltempo.update.uu.se>,
P/OS was a flavor of RSX, wasn't it? Would it be included in the regular
RSX build with compiler/assembler directives to control its inclussion?
If not, couldn't the sources for VENIX be used to fill in the needed
hardware bits to reconstruct it from RSX sources? Oh wait, that is
assuming VENIX sources for the PRO exist, too. I don't know that is
the case either. Sigh... The PDP-11 world gets more depressing every
day. maybe it really is time to pack it all i n and just go fishing.
In any event, have a very happy and safe new year.
RSX build with compiler/assembler directives to control its inclussion?
If not, couldn't the sources for VENIX be used to fill in the needed
hardware bits to reconstruct it from RSX sources? Oh wait, that is
assuming VENIX sources for the PRO exist, too. I don't know that is
the case either. Sigh... The PDP-11 world gets more depressing every
day. maybe it really is time to pack it all i n and just go fishing.
In any event, have a very happy and safe new year.
Johnny Billquist
Dec 29, 2012, 2:06:27 PM12/29/12
to
On 2012-12-29 19:21, Bill Gunshannon wrote:
> In article <kbn8s7$avt$1...@iltempo.update.uu.se>,
> Johnny Billquist <b...@softjar.se> writes:
>> On 2012-12-29 16:46, Bill Gunshannon wrote:
>>> In article <kbldtn$p1m$1...@iltempo.update.uu.se>,
>>> Johnny Billquist <b...@softjar.se> writes:
>>>> Oh how I wish I had the sources to the device drivers for P/OS, along
>>>> with the build files for it all. Then I could do P/OS 4.0, with all the
>>>> improvements that have happened since, as well as utilize the J-11
>>>> properly in the PRO-380... But I suspect that will never happen. :-)
>>>>
>>>
>>> And now you know how I feel. :-(
>>
>> This is not a new feeling...
>> I just wonder if any copy of the PRO-specific bits have even survived...
>> The situation for the "current" PDP-11 OSes are much better, but P/OS
>> was terminated by DEC quite a long time ago... In addition to be a
>> rather obscure branch even when it still was alive.
>>
>
> P/OS was a flavor of RSX, wasn't it? Would it be included in the regular
> RSX build with compiler/assembler directives to control its inclussion?
Yes, P/OS is based on RSX. Pretty much all of the standard RSX code is
> In article <kbn8s7$avt$1...@iltempo.update.uu.se>,
> Johnny Billquist <b...@softjar.se> writes:
>> On 2012-12-29 16:46, Bill Gunshannon wrote:
>>> In article <kbldtn$p1m$1...@iltempo.update.uu.se>,
>>> Johnny Billquist <b...@softjar.se> writes:
>>>> Oh how I wish I had the sources to the device drivers for P/OS, along
>>>> with the build files for it all. Then I could do P/OS 4.0, with all the
>>>> improvements that have happened since, as well as utilize the J-11
>>>> properly in the PRO-380... But I suspect that will never happen. :-)
>>>>
>>>
>>> And now you know how I feel. :-(
>>
>> This is not a new feeling...
>> I just wonder if any copy of the PRO-specific bits have even survived...
>> The situation for the "current" PDP-11 OSes are much better, but P/OS
>> was terminated by DEC quite a long time ago... In addition to be a
>> rather obscure branch even when it still was alive.
>>
>
> P/OS was a flavor of RSX, wasn't it? Would it be included in the regular
> RSX build with compiler/assembler directives to control its inclussion?
used in P/OS, and there are conditionals for P/OS specific bits and pieces.
However, the device drivers are totally their own, as they have a rather
different design for interrupt handling and address assignments for
peripherials.
And all those bits and pieces are not around anymore, that I can find.
> If not, couldn't the sources for VENIX be used to fill in the needed
> hardware bits to reconstruct it from RSX sources? Oh wait, that is
> assuming VENIX sources for the PRO exist, too. I don't know that is
> the case either. Sigh... The PDP-11 world gets more depressing every
> day. maybe it really is time to pack it all i n and just go fishing.
Also, chances are that the P/OS device drivers might work differently
enough from Venix that we wouldn't get enough help from there.
> In any event, have a very happy and safe new year.
Johnny
0 new messages