Thanks for the response. I guess not to many people have messed around with Multos8 or ETOS. I haven't played much with it this week. It's a fascinating system. The manuals aren't half bad either. I'm trying to add an OS/8 disk pack so I can mess around with the timesharing on two terminals. Cheers, Joe

.DIR HELP ADVNT !DARN THING DON"T TIME SHARE!

Funny, that was my original mission, to get ADVENT running on timeshare. Great minds think alike! Multos8 won't timeshare it either.

At 02:43 PM 10/16/2015, Joe wrote: That would be quite impressive it it actually worked. Does ETOS support FORTRAN programs, with the FRTS handling interrupts et al? That would be pretty amazing stack of emulators: SIMH emulating a PDP-8, running ETOS emulating OS/8, running FRTS emulating a FPP-12, executing FPP code to finally run Adventure. :) I don't think that's ever going to work. :) -Rick

On Fri, Oct 16, 2015 at 11:03:51PM -0400, Rick Murphy wrote: It appears to have limited (to the point of probably not being useful) support. System users guide pg 4-10. Fortran IV. Real time functions and floating point processor functions are not currently supported. The internal device handlers for high speed reader/punch and card reader are not supported. Device independent I/O must be used to access these devices. I don't know if that means the floating point instrutions won't work but the software emulator fallback will or any attempt to use floating point will fail.

On 2015-10-18 12:37, Rick Murphy wrote: 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. 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. 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

On 2015-10-19 03:04, Rick Murphy 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. 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... 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. 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... Agreed. I didn't know the FPP-12 had that. Interesting. Yes, I wonder if anything ever used it. 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

On 2015-10-19 04:58, ben wrote: That would be interesting to check out. You know where I could find it? 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

At 11:08 PM 10/18/2015, Johnny Billquist wrote: Not significantly. Small enough to be much less likely to run out of memory even with multiple 2-page handlers installed, but certainly not small enough to allow it to run in 16K, for example. The loader map says: 70000 = 1ST FREE LOCATION That means that it uses up all of 28K (with FRTS) without any device drivers installed. If it was possible to bum another couple of pages it might be possible to get it to work with 28K, but currently it won't. 32K is required for it to work. As always with trying to make code more compact, the more times you go back to try to shrink things the harder it gets. I haven't tried for several years, however. http://www.rickmurphy.net/adventure.html -Rick

On 2015-10-19 13:03, Johnny Billquist wrote: (And to clarify myself, by dynamically I mean that you could just allocate random memory somewhere, and load a device driver in there. They have to be in field 0, and you need to more carefully manage memory in field 0 for that, and other reasons.) By the way, could you describe how you managed to squeeze some memory like it would be possible to run in 28K. 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

On Mon, 19 Oct 2015, Johnny Billquist wrote: Yes. For normal device assignment, you use the command decoder to assign unit numbers to files, which loads the handlers for same. Adventure uses the USR routines written by Robert Phelps, which allows it to dynamically load a driver into memory and open a file at run time. Space for those handlers is allocated just above the FRTS allocation. -Rick

At 01:10 PM 10/19/2015, ben wrote: I don't think there's any way to re-purpose the memory used by the FPP emulator. And, to be honest, when running under SIMH you can just say that there's 32K of memory - why would FPP and 28K be any better? (Running with the FPP enabled under SIMH does significantly improve the performance, so it's good to use that in any case.) -Rick

On Fri, Oct 16, 2015 at 12:41:56PM -0600, Joe wrote: Its on my site also http://www.pdp8online.com/pdp8cgi/query_docs/query.pl?Search=etos