🚀 go-pugleaf

John Levine <jo...@taugh.com> writes:
> I've read the manuals too.  The card version of BOS was called BPS,
> and none of BOS, DOS, or TOS, could do multiprogramming until much
> later versions of DOS.  It looks to me like the disk management was
> even more primitive than DOS, with sets of disk tracks explicitly
> assigned to files, and it didn't work with more than 32K which
> suggests they used direct addressing and 16 bit adcons.

re:
http://www.garlic.com/~lynn/2018e.html#66 something like a 360, was PDP 11/40 system manual

There was something like 80-100 card stand-alone BPS loader. It was used
by CP/67 kernel.
https://en.wikipedia.org/wiki/IBM_Basic_Programming_Support

BPS was developed by IBM's General Products Division in Endicott, New
York. The package included "assemblers, IOCS, compilers, sorts, and
utilities but no governing control program." BPS components were
introduced in a series of product announcements between 1964 and
1965.[1]:pp.319-321

BPS came in two versions -- a strictly card system and a tape based
system which, contrary to the stated goals, kept a small supervisor
permanently resident.[2]:p.14

Programming languages available were Assembler, RPG, and FORTRAN IV
(subset). Tape FORTRAN required 16 KiB of memory.[2]:p.5 There were also
two versions of the BPS assembler, with the tape version having enhanced
capabilities.

BPS also had a "disk" counterpart called BOS. It also required 8 KiB of
memory and supported disks such as the IBM 2311.

The group responsible for BPS/BOS went on to develop DOS/360 and TOS/360
as a supposed "interim" solution when it became evident that OS/360
would be too large to run on 16 KiB systems.

... snip ...

references BPS/BOS documents
http://bitsavers.org/pdf/ibm/360/bos_bps/

When CP/67 was installed at univ. jan1968, all the source was on
os/360. Assemble updates/changes on os/360 ... generating TXT deck for
each source. Default was do diagnal stripe across top of each TXT deck
with module identifier. TXT Cards were kept in card tray ... slightly
over box of cards. BPS loader at the front, followed by PSA (page zero
storage definition, interrupt handlers, and misc. other code). Last TXT
deck was CPINIT ... default BPS behavior was transfer to the last
module/program loaded (or entry specified by LDT loader control
card). That entry would write memory image to disk which would have IPL
restart into CPINIT address that would reverse the process and start
CP/67.

In summer of 1967, I made several (lower-used) CP/67 kernel routines
"pageable" ... broken into 4k segments, but would execute non-virtual
... so couldn't cross page boundary and had to use SVC call interrupt
that would handle translating original address to its new page location
(and if required, first bring the page into storage). Objective was
to reduce CP67 fixed kernel requirements, especially for running
on 256kbyte 360/67 (getting fixed kernel down to almost 60kbyte).

CP/67 console routine was something over 20k bytes, command would be
decoded and then transfer to the specific command function. I broke the
command functions into 4k segments with external entry for each command
... that could be called by the kernel command decoder.

Turns out BPS loader had limit of 255 external entry symbols ... and
breaking up console went over the limit. I then had to do hack that
there was single entry for each 4k page group of console commands with
internal branch routine to the specific command.

Next distribution of CP67 (spring 1968) had (finally) moved all the
source to CMS ... and made update/changes much simpler.

After graduating and transfer to science center ... past posts
http://www.garlic.com/~lynn/subtopic.html#545tech 

I found a copy of BPS source in card file cabinent in the storage area
in the storage area that occupied part of the top floor of 545 tech sq.
I updated the source to handle more than 255 entries. I also found
out that BPS loader passed address of its table of enternal entries.
I then modified CPINIT to copy the BPS external entry table to the
end of pageable area ... so it was saved on the disk along with
the rest of kernel image.

None of this was included in CP67 customer product distribution, but
VM370 did adopt a subset of the pageable functions for its first
release.

mentionin CP67 pageable kernel support, some older posts
http://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2002b.html#44 PDP-10 Archive migration plan
http://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
http://www.garlic.com/~lynn/2002p.html#56 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2002p.html#64 cost of crossing kernel/user boundary
http://www.garlic.com/~lynn/2003f.html#12 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#14 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#23 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#26 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#30 Alpha performance, why?
http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story
http://www.garlic.com/~lynn/2004b.html#26 determining memory size
http://www.garlic.com/~lynn/2004g.html#45 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#10 Where should the type information be: in tags and descriptors
http://www.garlic.com/~lynn/2005f.html#16 Where should the type information be: in tags and descriptors

-- 
virtualization experience starting Jan1968, online at home since Mar1970