11 Feb
2014
11 Feb
'14
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.