18 Oct
2015
18 Oct
'15
7:43 p.m.
On 2015-10-19 03:04, Rick Murphy wrote:
No, you are wrong.
Yes, the IOTs just "needs to be implemented". That is the easy part. The
memory mapping is not. However, the mode in the FPP-8A that restricts
the FPP code to only allow access within the current field will then
trap out if the code tries to access anything outside, and the addresses
are still 15 bits. This means that the OS can then handle this as a page
fault (field fault?), and swap in the correct field, and then resume
FPP-8 execution. However, like I said, I have not tried actually
implementing anything like this, since I don't even have the hardware.
And I suspect it might be a headache since I guess addresses are still
absolute, meaning and field relocations done by the OS needs to somehow
be done for the FPP-8 code as well. Not sure how you'd do that, but I
think people with enough creativity could maybe come up with some
solution. I would have to re-read the documentation to see how well I
remember this stuff...
At 08:37 AM 10/18/2015, Johnny Billquist wrote:
Yes, it does. Not that this really is the important point I was making,
but anyway...
The point I was making was that FRTS detects if it is running in the
background of RTS-8, and patches itself to not use the interrupt system
in this case. And MULTOS-8 made sure to cause FRTS to think that it is
running in the background of RTS-8, so that the patches are applied,
thus making it also able to run under MULTOS-8.
Memory requirements and availability is a different story, but yes,
ADVENT will require the full 32K, as far as I remember.
I decided to look into this a couple of days ago,
since the basic
workings of FRTS includes using interrupts, which is not possible if
running under time sharing. That would also imply that it would not be
possible to use F4 under RTS-8, which I had some memory of that it
actually is possible.
To sum things up: The FPP-8 can usually not be used when in
timesharing. First of all, you use IOTs to control the FPP, and all
IOTs are trapped when in user mode. Second, as you note, the FPP-8
uses 15-bit addresses, which would make it impossible to use with
virtual memory.
Also, the interrupt system is not available when in user mode.
However, FRTS actually have code to detect if it is running under
RTS-8, and do not use the interrupt system in that case, but adopts.
Also, since the FPP-8 IOTs are caught by RTS-8, and do not do
anything, FRTS actually believes you are on a system without an FPP-8,
even if you actually have one. So, FRTS will always use the FPP-8
emulator in this situation.
MULTOS-8 hook in to the same functionality, making FRTS believe it is
running under RTS-8, which means that F4 programs will actually work
under MULTOS-8, including ADVENT. I don't know if ETOS also implements
the bits needed to make it look like OS/8 programs are actually under
RTS-8. If it does, ADVENT should be possible to run under ETOS as
well. Otherwise not.
Sounds like it's possible, if MULTOS-8 can give a user a full 32k to
work with. Finally, as I
noted, the FPP-8 is not that possible to use in user
mode, both because of the IOT instructions being caught, and the
15-bit addressing. However, the FPP-8A have a mode where it only
allows memory accesses within the same field, and will trap out if any
memory reference goes to another field. With some work, and code, I
think it could be possible to actually have access to the FPP-8 from
user mode, if you have an FPP-8A, but I have never tried this, as I
lack the hardware.
That's not going to help anything using Fortran-IV, of course. The
library and user code assumes that "virtual" addresses are the same as
physical ones. And IOTs aren't "not possible" - they just need to be
trapped and emulated by the OS. It wouldn't be all that hard to add support for a
FPP to a timesharing
system as a UUO that knows how to map the user's field to something the
FPP could use, then locking that field in core, as the FPP will continue
to DMA from it while executing FPP instructions.
That would prevent more than one user using the FPP-8, though. Doable,
but not really that useful if you want a timesharing system for more
than one user.
To support even this simple FPP mode would require the
underlying OS to
handle the housekeeping, as the FPP startup needs to know the physical
field of the active parameter table, which a timeshared user wouldn't know.
Not to mention you'd have to figure out how to manage if the FPP wants
to run in field 0, which the OS needs for its own use...
Seems like a lot of work given the number of FPPs in
the wild.
Agreed.
Also, not just FPP8-A has that feature. The "same
field as the APT" bit
is also implemented by the FPP-12. This makes me wonder what application
there was for this.
I didn't know the FPP-12 had that. Interesting. Yes, I wonder if
anything ever used it.
Of course, you don't need the hardware to
experiment with this. The SIMH
FPP-8A implementation is as compatible to the hardware as I could make
it - everything but the maintenance mode IOTs are implemented.
Hmm. Good point. Last I looked at this, simh hardly even existed. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol