Actually there was also an Interdata cross assembler which ran on an
IBM OS/360 and produced punched 'load decks'. I believe the
'assembler' was little more than the OS/360 assembler with a bunch of
macros.
When I was in high school I had access to an Interdata 7/32 and
Interdata 70 (16-bit) up at the local university.
the 7/32 did not run OS/32 but a locally written OS called WTS
(Western Terminal System) - they attached about 16 or
to terminals to a 7/32 with about 128K of memory (each terminal I
believe had a huge 8K partition). It was used for
CAI (Computer Assisted Instruction), programming and administration.
Ran an interpreted basic (also locally written but pretty good), and
abbreviated version of PL/1 (called WPL) and one of the systems ran
sort of a batch FORTRAN. But a version of PILOT was used for CAI.
That is how I learned FORTRAN - a CAI program call FORBUS written in
Pilot.
However the Interdata 70 was fun - it was 16 bit with about 64K
memory. Ran an Interdata OS called BOSS which was real basic - to
assign a disk file you would specify a range of sectors in hex and the
disk 'catalog' was a physical piece of paper with file names and
sector ranges on it. (I believe this was _way_ before OS/32)
Me and another guy (a student there) would work (read: play with) an
Interdata OS called DOS (Disk Operating System) which featured, among
other things, blocking of multiple records on a disk sector and a real
disk catalog. Interdata also had an real time OS called RTOS - I
never got into that - perhaps that was an ancestor to OS/16 and OS/32.
I never really got to work with OS/32 but I see some vestages of the
old BOSS and DOS commands reflected in OS/32 - ALlocate and ASsign for
example).
What we would do is take the DOS source code (on punched cards) and
run them over on the OS/360 IBM with the
cross-assembler the assembler would produce a 'load deck' which was
then punched on 80-column cards (in binary). As I recall the
BOSS/DOS load deck record size was something like 108 bytes. Anyway
we would get this load deck and put it in a card reader on the
Interdata 70 preceeded by a 'boot' card (containing a binary program
which would load the rest of the cards). Key in (or verify) a program
at location '50' via the switches. Press EXE and it would load, in
effect, boot from the card reader. Editing was by inserting and
replacing cards in the OS punched Deck (about a box - 2,000 cards).
The main use of the 70 was students running simulations (I don't
exactly recall the name of the simulation package - simulac or
something like that?), graphics, and land use management. It had a
Tektronics 1410 storage tube graphics terminal, a card reader, a
thermal printer for the 1410, a regular ASCII terminal (I wrote a
PASLA driver for it), and I believe a digitizer.
Anyway - that's my story :).
-- Greg
Quoting [email protected]:
Thanks for the very interesting info! I have not come across this machine
or software and did not know anything about it.
On Thu, 18 Feb 2016 21:16:32 -0500
Davis Johnson <[email protected]> wrote:
I'm pretty sure the resemblance was intentional so as to be an easier
sell to customers familiar with 360 assembler.
There was a rumor that they had originally hoped to sell low-cost
training machines to schools when real computers were expensive.
There is some architectural resemblance if you throw out most of the
address modes, base registers, have fewer condition code bits... You end
up with 16 two's complement registers, uniform size 8-bit op codes, RX,
RR, and RI addressing modes (with a few variants).
A 16 bit quantity on the 16 bit machines was always, from the beginning,
a "HALF WORD".
The assembler, "CAL" (Common Assembly Language) would assemble 16 or 32
bit source.
With care it was possible to write source code that could be assembled
to either 16 or 32 bit object. Don's example uses some of the features,
A(...) specifies an "address length" constant, 16 or 32 bit as
appropriate. There was a whole set of opcode mnemonics that would
assemble appropriately depending on the target. The BASIC interpreter
was a key example, and was actually distributed in source form. I'd love
to find a copy.
If you were really careful you could create a binary that would actually
run on 16 or 32 bit machines without modification. Some of the hardware
diagnostics are this way. Look for COMMON in the diagnostic title.
For a 32 bit target a different kind of careful would let you write
position independent code.
On 02/16/2016 05:16 AM, [email protected] wrote:
> Fascinating and very similar in syntax to the assembler for IBM OS/360
> and later. Does anybody know the history behind this?
>
> On Mon, 15 Feb 2016 13:58:26 -0500 (EST)
> [email protected] (Don Stalkowski) wrote:
>
>> *L EDIT32
>> TSKID = EDIT32
>> *ST
>> *13:19:38 EDIT32:PERKIN-ELMER OS/32 EDIT 03-145 R04-01
>> *EDIT32>GET HELLO.CAL
>> *EDIT32>T 1-12
>> *13:19:48 EDIT32: 1 SVC 1,SAY
>> *13:19:48 EDIT32: 2 SVC 3,0
>> *13:19:48 EDIT32: 3 ALIGN ADC
>> *13:19:48 EDIT32: 4 SAY DB X'28'
>> *13:19:48 EDIT32: 5 DB X'00'
>> *13:19:48 EDIT32: 6 DS 2
>> *13:19:48 EDIT32: 7 DC A(SAY1)
>> *13:19:48 EDIT32: 8 DC A(SAY2)
>> *13:19:48 EDIT32: 9 DAS 2
>> *13:19:48 EDIT32: 10 SAY1 DC C'HELLO WORLD '
>> *13:19:48 EDIT32: 11 SAY2 EQU *-1
>> *13:19:48 EDIT32: 12 END
>> *EDIT32>END
> _______________________________________________
> Simh mailing list
> [email protected]
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
>
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
