11 Feb
2014
11 Feb
'14
11:24 a.m.
At 08:57 PM 2/9/2014, Kyle Owen wrote:
- The OS/8 system handlers use some PDP-8/E and later
instructions. If
someone wants to help go back through and track these down, we can see
if a
more compliant version will still fit in the allotted space.
I had a quick look at the code and it's not going to be particularly
hard to get rid of the BSW instructions.
I got distracted trying to remember where the three-instruction BSW
subroutine is found. In TSS/8 somewhere IIRC.
- There's definitely an issue present. Running
BASIC with a simple test
program halts the computer after 10206. I've not had a chance to further
investigate why.
That's not good. How about Fortran? That's another good test as it runs
with interrupts enabled.
- The server does its best to check that a disk write
will not go outside
the boundaries of the disk.
- The server does its best to verify that a disk read will not overwrite
the system handler
OS/8 handlers generally haven't bothered with this. Some of them are
pretty horrid.
Also, if an OS/8 guru can help me out, I'd
appreciate it. Will a
read/write
from SYS: on an RK05 past block 3248 (decimal) succeed? That is, can a
read
or write carry over from one side of the platter to the other? After
looking at the RK8E system handler, I would say this is a yes. It looks
like a call to SYS: with a block number of 6260 (octal) is the same as a
jump to the second entry point. However, is this behavior desirable or
needed? I would have expected the two sides to be logically separated in
the handler. My server attempts to do just that by essentially
chopping the
.rk05 image in half. If a transfer goes past the end of either half, an
error occurs. However, if this is not what should happen, I can change
that.
Yes, if you give the handler a block greater than the size of the disk,
it'll overflow into the other half. As above, the OS/8 handlers assume
that you know what you're doing.
I wouldn't much bother about reproducing that behavior, however. It's
remotely possible that something somewhere takes advantage of it, but
I'd be really surprised if that was the case.
It's not "sides" actually - the blocks alternate sides. You read all 16
sectors on the top, flip to the bottom, read all those, then flip back
to the top. There's a CJL (Charles J. Lasner) rant about the fact that
the OS/8 system handler does it wrong, causing a full rotation when the
side is switched so a full-disk read on OS/8 is far slower than it
needs to be.
-Rick
11 Feb
11 Feb
5:30 p.m.
On Tue, Feb 11, 2014 at 5:24 AM, Rick Murphy <rick at rickmurphy.net> wrote:
Good to know. Since all of this added functionality is in the server, not
the handler itself, I certainly don't mind keeping it around. Having to
constantly swap the handler out for a new one is a pain, but I did make a
utility to do just that. Still, it's not as easy as just recompiling the
server code.
Kyle
- There's definitely an issue present. Running BASIC with a simple test
Interrupts! I hadn't even considered those...oops! I don't have enough
space in my system handler to 1) check if interrupts are enabled, 2)
disable them, and 3) re-enable them if necessary. Just to see if it would
do something different, I disabled interrupts altogether in my subroutine.
Sure enough, it completely broke the functionality of the system. I guess I
can safely assume that programs don't disable interrupts prior to entering
a handler.
Any ideas? If I get caught up in an interrupt halfway through a disk
transfer, I'm screwed. The buffer will overrun, and all will be lost. I'm
going to play around with the KIE instruction to see if that's all it
needs. Perhaps my choice of using the aux TTY ports was a bad idea. I guess
it's possible that other programs might need to rely on that for some
reason. Another possible solution is just implement reader run control.
I'll have to make sure that my output buffer on the server end won't
overrun though.
Also, if an OS/8 guru can help me out, I'd appreciate it. Will a read/write
program halts the computer after 10206. I've
not had a chance to further
investigate why.
That's not good. How about Fortran? That's another good test as it runs
with interrupts enabled. from SYS: on
an RK05 past block 3248 (decimal) succeed? That is, can a
read
or write carry over from one side of the platter to the other? After
looking at the RK8E system handler, I would say this is a yes. It looks
like a call to SYS: with a block number of 6260 (octal) is the same as a
jump to the second entry point. However, is this behavior desirable or
needed? I would have expected the two sides to be logically separated in
the handler. My server attempts to do just that by essentially chopping
the
.rk05 image in half. If a transfer goes past the end of either half, an
error occurs. However, if this is not what should happen, I can change
that.
Yes, if you give the handler a block greater than the size of the disk,
it'll overflow into the other half. As above, the OS/8 handlers assume that
you know what you're doing.
I wouldn't much bother about reproducing that behavior, however. It's
remotely possible that something somewhere takes advantage of it, but I'd
be really surprised if that was the case.
It's not "sides" actually - the blocks alternate sides. You read all 16
sectors on the top, flip to the bottom, read all those, then flip back to
the top. There's a CJL (Charles J. Lasner) rant about the fact that the
OS/8 system handler does it wrong, causing a full rotation when the side is
switched so a full-disk read on OS/8 is far slower than it needs to be. 
7:22 p.m.
From: Kyle Owen: Tuesday, February 11, 2014 9:30 AM
Interrupts! I hadn't even considered those...oops!
I don't have enough
space in my system handler to 1) check if interrupts are enabled, 2)
disable them, and 3) re-enable them if necessary. Just to see if it would
do something different, I disabled interrupts altogether in my subroutine.
Sure enough, it completely broke the functionality of the system. I guess I
can safely assume that programs don't disable interrupts prior to entering
a handler.
No OS/8 device driver, to my knowledge, is prepared to handle interrupts,
so I wouldn't sweat that. The application should turn off interrupts before
requesting OS/8 services.
Vince
12 Feb
12 Feb
3:02 a.m.
At 02:22 PM 2/11/2014, Vincent Slyngstad wrote:
No OS/8 device driver, to my knowledge, is prepared to
handle
interrupts, so I wouldn't sweat that. The application should turn off
interrupts before requesting OS/8 services.
That's correct. F4 runs with interrupts enabled, but disables them
whenever the OS (such as it is) is called.
-Rick
11 Feb
11 Feb
11:58 p.m.
On 02/11/2014 12:30 PM, Kyle Owen wrote:
On Tue, Feb 11, 2014 at 5:24 AM, Rick Murphy <rick
at rickmurphy.net> wrote:
Two ways usualy the OS block interrupts for critical parts or the driver
can
get the interrupt state, turn them off, and restore on exit.
- There's definitely an issue present.
Running BASIC with a simple test
Interrupts! I hadn't even considered those...oops! I don't have enough
space in my system handler to 1) check if interrupts are enabled, 2)
disable them, and 3) re-enable them if necessary. Just to see if it would
do something different, I disabled interrupts altogether in my subroutine.
Sure enough, it completely broke the functionality of the system. I guess I
can safely assume that programs don't disable interrupts prior to entering
a handler. program halts the computer after 10206. I've
not had a chance to further
investigate why.
That's not good. How about Fortran? That's another good test as it runs
with interrupts enabled. Any ideas? If I get caught up in an interrupt halfway
through a disk
transfer, I'm screwed. The buffer will overrun, and all will be lost. I'm
going to play around with the KIE instruction to see if that's all it
needs. Perhaps my choice of using the aux TTY ports was a bad idea. I guess
it's possible that other programs might need to rely on that for some
reason. Another possible solution is just implement reader run control.
I'll have to make sure that my output buffer on the server end won't
overrun though.
I've solved a similar problem for my 8F, no disks but two
serial cards.
I modded
one to get TTL levels for TX data, Rxdata, RXbufferfull (its there on
the 8555).
I used RXbufferfull to jam the TX (CTS clear to send) on the host (not a
pc!).
Ramped th data rate up and the host will send bytes at whatever rate the
PDP-8F can take. My "disk" is a program running on a CP/M machine
and has a partition or three on a big hard disk (aka CF).
I mostly stumbled through getting a driver for the 8F working as a HSR
(high speed reader/punch) device. Never did one for OS/8. Next project.
Allison
12 Feb
12 Feb
12:09 a.m.
On 02/11/2014 06:24 AM, Rick Murphy wrote:
At 08:57 PM 2/9/2014, Kyle Owen wrote:
CLL RTL ; clear link rotate two left, iterated three times.
CLL RTL
CLL RTL
Least that what memory says.
Allison
- The OS/8 system handlers use some PDP-8/E and
later instructions. If
someone wants to help go back through and track these down, we can
see if a
more compliant version will still fit in the allotted space.
I had a quick look at the code and it's not going to be particularly
hard to get rid of the BSW instructions.
I got distracted trying to remember where the three-instruction BSW
subroutine is found. In TSS/8 somewhere IIRC.
12:53 a.m.
From: allison: Tuesday, February 11, 2014 4:09 PM
On 02/11/2014 06:24 AM, Rick Murphy wrote:
I'm pretty sure you need RTR, not RTL. Otherwise you're clearing
the bits you want to rotate in, and you'll need to rotate one more
to count the Link. The CLL stuff is probably optional anyway:
/ L 012 345 678 9ab
RTR / a bL0 123 456 789
RTR / 8 9ab L01 234 567
RTR / 6 789 abL 012 345
This assumes the objective is to get 6 bits of "high byte" to
the lsb so they can be used for 8 bit I/O. Your version is
more suitable to a "pack" operation that gets the least
significant 6 bits to the high side of a word, so it can be
merged with another 6 bit "byte" for storage.
Vince
I had a quick look at the code and it's not
going to be particularly
hard to get rid of the BSW instructions.
I got distracted trying to remember where the three-instruction BSW
subroutine is found. In TSS/8 somewhere IIRC.
CLL RTL ; clear link rotate two left, iterated three times.
CLL RTL
CLL RTL
11:08 a.m.
On 02/11/2014 07:53 PM, Vincent Slyngstad wrote:
From: allison: Tuesday, February 11, 2014 4:09 PM
The CLL is was often used. RTR and RTL are symetric. Same operation in
opposing directions.
Its a Rotate not a Shift.
On 02/11/2014 06:24 AM, Rick Murphy wrote:
I'm pretty sure you need RTR, not RTL. Otherwise you're clearing the
bits you want to rotate in, and you'll need to rotate one more to
count the Link. The CLL stuff is probably optional anyway:
I had a quick look at the code and it's not
going to be particularly
hard to get rid of the BSW instructions.
I got distracted trying to remember where the three-instruction BSW
subroutine is found. In TSS/8 somewhere IIRC.
CLL RTL ; clear link rotate two left, iterated three times.
CLL RTL
CLL RTL / L 012 345 678 9ab
RTR / a bL0 123 456 789
RTR / 8 9ab L01 234 567
RTR / 6 789 abL 012 345
This assumes the objective is to get 6 bits of "high byte" to the lsb
so they can be used for 8 bit I/O. Your version is more suitable to a
"pack" operation that gets the least significant 6 bits to the high
side of a word, so it can be merged with another 6 bit "byte" for
storage.
Maybe...
It might also be to get 6buts to the low half word.
Allison
3:23 a.m.
At 07:09 PM 2/11/2014, allison wrote:
On 02/11/2014 06:24 AM, Rick Murphy wrote:
CLL after the first iteration will drop bits if I'm not mistaken.
It's actually
CLL RTL
RTL
RTL
-Rick
At 08:57 PM 2/9/2014, Kyle Owen wrote:
CLL RTL ; clear link rotate two left, iterated three times.
CLL RTL
CLL RTL
Least that what memory says. - The OS/8 system handlers use some PDP-8/E and
later instructions. If
someone wants to help go back through and track these down, we can
see if a
more compliant version will still fit in the allotted space.
I had a quick look at the code and it's not going to be particularly
hard to get rid of the BSW instructions.
I got distracted trying to remember where the three-instruction BSW
subroutine is found. In TSS/8 somewhere IIRC.
6:05 a.m.
Alright, I continue to experiment with OS/8 and have found that I can
reproduce my issue on Bernhard Baehr's OS X emulator.
I've downloaded a fresh image from here (
http://www.pdp8online.com/images/convert_mac.shtml/diag-games-kermit.rk05?l…)
and can run BASIC.BA no problem. Loads, lists, runs, all as expected.
I then use the OS/8 System Disk that comes with the Version 1.5
distribution of the emulator. I mount that disk as SYS: (drive 0) and the
previous image for drive 1. If I run BASIC and load BASIC.BA, it loads and
lists fine. But when I run it, it thinks a little before halting at 10206.
This behavior is identical to what I've experienced with my physical
hardware, which is somewhat reassuring that it's repeatable.
The OS/8 version on diag-games-kermit.rk05 is KBM V3Q, CCL V1F. The OS/8
System Disk from the Mac world is KBM V3R, CCLX V1F(CM39).
The reason I've been using OS/8 System Disk is that it comes with BUILD,
which of course is highly useful for installing my drivers.
diag-games-kermit.rk05 does not come with BUILD.
I've FOTP'ed BUILD to diag-games-kermit.rk05, but after I reconfigure the
system and type BOOT, it hangs up until I press return one more time. Then
it prints out "BMS?"
I assume BUILD's version is different and that's why it's not working.
Any other things to try?
Kyle
13 Feb
13 Feb
2:54 a.m.
On Wed, Feb 12, 2014 at 12:05:57AM -0600, Kyle Owen wrote:
I've FOTP'ed BUILD to diag-games-kermit.rk05, but after I reconfigure the
system and type BOOT, it hangs up until I press return one more time. Then
it prints out "BMS?"
I assume BUILD's version is different and that's why it's not working.
diagpack2.rk05 has build.
diag-games-kermit may have some subtle problems. It was corrupted when
I got it and its possible its still not quite right. The diagpack2 and
other build I have tried have updated the system head but when you have them
they won't run. I remember I also had a problem with saving where some
low memory locations wouldn't get written properly.
You also need to set sys noinit to turn off the startup message to be
able to try to save build after bo.
14 Feb
14 Feb
11:29 a.m.
At 09:54 PM 2/12/2014, David Gesswein wrote:
diag-games-kermit may have some subtle problems. It was
corrupted when
I got it and its possible its still not quite right.
For that pack, I re-compiled BUILD from source in order to get it to
work when building a RL02 image.
It's definitely not working properly, probably ..
You also need to set sys noinit to turn off the startup
message to be
able to try to save build after bo.
due to not doing that.
-Rick
4:26 p.m.
On Fri, Feb 14, 2014 at 5:29 AM, Rick Murphy <rick at rickmurphy.net> wrote:
For that pack, I re-compiled BUILD from source in order to get it to work
when building a RL02 image.
Did you use BUILD.PA available from here?
http://www.ibiblio.org/pub/academic/computer-science/history/pdp-8/os8/os8.…
I tried using palbart to assemble it and got numerous errors. Haven't tried
it with PAL8 yet.
On a related note, what's the easiest way to transfer a large swath of
text, like BUILD.PA, to OS/8 through the console TTY? I thought about
coming up with a simple program to send files to EDIT (which would require
sending until a page feed, saving the buffer to disk, killing the buffer,
appending to the buffer, and continuing on, correct?) but have neglected
doing so since most of my assembly programs are less than the buffer's
length.
Kyle
3749
days inactive
3752
days old
12 comments
5 participants
participants (5)
-
ajp166＠verizon.net -
djg＠pdp8online.com -
kylevowen＠gmail.com -
rick＠rickmurphy.net -
vrs＠msn.com