Differences between Intel ISIS and Tandberg OS

[Frode M]

I have gotten some more versions of Tandberg OS (v1.5 and v1.6, in addition to v1.7 that I had from before), and am in the works of disassembling everything to learn more about how things work and changed over the range of versions I have. In the process I have found a few differences from Intel ISIS. Sorry for the wall of text, but here we go:

As mentioned in the older thread, the user-interface (down to the debugger monitor level), file system, and use of Intel Absolute Binary format for executable commands is very much taken from Intel ISIS. The general look and feel is much the same, but that's about where it ends. The system APIs, both in ROM and in the OS are completely different, as well as the memory layout, but I will mostly focus on the user-experience here.

First of all, one thing to note is that TOS always has a dual command-line parameter in the form of CMD [TOS args]$[command args]. This first set of arguments always goes to TOS and only TOS, where the second set is the only args the program sees. The TOS args are typically used to assign some standard file control blocks that provides a layer of abstraction to the program to be run.

What I mean by standard-files, is that instead of setting up and opening every file locally in the program, it gets a set of prepared and open FCBs from TOS instead on entry. In particular, CI and CO for console in and output, SI SL and SO for primary file input, line-polling device, and output, and likewise AI AL and AO for auxiliary file actions. What to do with these abstract files is a little up to the program itself, but it enables a unified way of dealing with ordinary data-flow in and out of a program.

Take for instance the MOVE command. MOVE SI=:F0:MYFILE.BIN, SO=:F0:MYCOPY.BIN simply copies a file. However, MOVE CO=:XM:, SI=:F0:MYFILE.BIN, SO=:LP:$H will print a hexadecimal listing of MYFILE.BIN to the printer port, while sending console output to the serial port. In this example, the MOVE program only gets the H argument (for its hexadecimal listing mode), and the already-prepared and opened CI, CO, SI and SO file control blocks. What's more, is that there's a linked file control block type, so you can set up things like SO=(:LP:,:F0:MYFILE.TXT) to get the output hex listing both on the printer port and a copy of that to MYFILE.TXT. This serves much the purpose of file-piping in UNIX, but this is declarative tree-branched piping system and not just the regular proximity-based piping we are used to. I am surprised how powerful this is, and there are actual use-cases on modern systems where I would wish for this functionality.

The next thing I note, is that support for the IBM 3740 file system is built into TOS (but not through the XMON routines in ROM). Both disks of ASCII and EBCDIC varieties, being assigned devices :A0: to :A3: and :I0: to :I3: respectively. While MOVE won't set the additional verbose metadata of an IBM file, there's a tool called ALLOC that will let you do this.

There's also more attributes, most notably the "Alias" attribute. This attribute lets you create aliases of a file, or basically it lets you address the same file using several filenames. Think along the lines of a UNIX symlink.

Of the programs that ships on a system disk, here is a complete list:

• File system standard operations:
  • ALIAS (Create aliases)
  • ATTRIB (Set attribute of file)
  • DELETE (Delete file or alias)
  • DIR (Directory listing)
  • MOVE (Copy files and/or move data)
  • RENAME (Rename file)

• File system advanced operations:
  • DIRPAC (Prune deleted file entries)
  • DROP (Reserve freestanding sectors in ISIS.MAP)
  • REMAP (Reset ISIS.MAP based on directory entries)
  • RESCUE (Undelete)

• System:
  • ASSIGN (Set up standard files for consecutive commands)
  • EXEC (Same as ASSIGN, but for the domain of CI=<batch file>)
  • RELEAS (Release standard file-assignment by ASSIGN)
  • SYS (Set TOS system behaviour variable)
  • SYSTEM (Tandberg OS itself, automatically loaded and run on boot)

• Storage devices init:
  • DGEN (Copy all files from one floppy to another)
  • FORMAT (Formats new floppy or tape)
  • INIT (Initialize file-system on newly formatted floppy)
  • TPGEN (Copy all files from one floppy to tape)

• Storage devices bulk:
  • ANALYZ (Check floppy for errors)
  • DCONVA (Convert floppy from EBCDIC to ASCII)
  • DCOPY (Make sector-copy of floppy to floppy)
  • DDUMC (Dump sector-image from floppy to tape)
  • DRSTC (Restore sector-image from tape to floppy)
  • MDUP (Make record-copy of tape to tape)

• Applications,  text:
  • EDIT (Fully-featured text editor)
  • SEDIT (Line-editor)
  • TTY (Behave like a TDV-2115L dumb-terminal)
  • TXW (Text-writer)

• Applications, assembler:
  • ASM (Control-center for assembler suite)
  • DEBUG (Enable XMON debugger on RST0)
  • HEXBIN (Convert from HEX file to Intel Absolute Binary file)
  • LINK (Link relocatable modules)
  • RASM (The assembler itself)
  • XREF (Generates cross-reference list)

• Miscellaneous:
  • ALLOC (Create or edit IBM 3740 file entry)
  • MYLOAD (Run a program from a Mycron MYCRO-1 formatted floppy)
  • PROM (Interface with a BNPF-based chip programmer)

With best regards.

-Frode

[Herbert Johnson]

On 12/19/2024 9:32 AM, Frode M wrote:
> I have gotten some more versions of Tandberg OS (v1.5 and v1.6, in
> addition to v1.7 that I had from before), and am in the works of
> disassembling everything to learn more about how things work and changed
> over the range of versions I have. In the process I have found a few
> differences from Intel ISIS. Sorry for the wall of text, but here we go:

https://www.retrotechnology.com/restore/isis.html#tandberg

I've added your post to my accumulated notes from you Frode, about your
work with the Tandberg OS vs "ISIS". Thanks from me for your update today.

Pardon an elementary question. What version of ISIS are you comparing
TOS to, now that you've made this comparison?

Given your apparent 1976 release date for the first Tandberg 8080 based
system (see my Web page), the ISIS available to Siemens at the time may
have been ISIS V1.something, from roughly the same or earlier date. That
ISIS was only recovered in the last several years, and is not very well
known today. That ran only on the very earliest Intel development systems.

Whereas "ISIS-II" is Intel's actual brand-name of its later OS. It's the
more commonly known and available (as recovered) version, to the point
where that version was/is commonly called "ISIS". Therefore the question.

Regards Herb

--
Herbert R. Johnson, New Jersey USA
https://www.retrotechnology.com OR .net
preserve, recover, restore 1970's computing
email: hjohnson AT retrotechnology DOT com
or try later herbjohnson AT comcast DOT net

--
Herb Johnson, New Jersey USA
http://www.retrotechnology.com or .net
preserve and restore 1970's personal computing
email: hjohnson @ retrotechnology dot com
or try later at herbjohnson @ comcast dot net

[Frode M]

I don't know exactly when the software was done, the people over at technikum29.de scanned some early hardware design documents that dates from late 1975. Most of the scanned schematics are dated around 1976 and early 77, but the dates on those may be related to revision and not the first design. The oldest actual physical part I have myself is from 1977 (the keyboard from my machine). Whether the TDV-2114 was available for sale already in 1976 or 1977 is as such not entirely clear. I recently tried to get hold of some Tandberg-newsletters from the right time to give more clear details on it, but I lost that auction.

Given Tandberg OS uses the dollar-sign to delimiter the OS-specific arguments and program-specific arguments, and the heavy reliance on the absolute binary format instead of the relocatable format from ISIS-II, I would make an educated guess that Tandberg were mainly having ISIS-1.x in mind when making their design decisions.

-Frode

[William Beech]

Herb and Frode,

Is the Tandberg OS a precursor to the ISIS 1.1?  Was Intel's work not completely original?

Thanks!

Bill

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/cfca3a2e-1a98-4894-b8bd-63c5392872b4n%40googlegroups.com.

[Frode M]

The fact that Tandberg OS retains an ISIS.DIR, ISIS.MAP, and ISIS.LAB, it's pretty clear that ISIS came first. However, Tandberg must not have been far behind. However, calling TOS a clone of ISIS is misleading as under the hood the two are quite different beasts. I would rather say TOS is much inspired by ISIS v1. The only things borrowed is the look-and-feel, development workflow (having a quite Intel-like debugger in ROM), as well as the disk format and executable file formats.

-Frode

[roger arrick]

Interview with Ken Burgette about ISIS development:

https://www.rogerarrick.com/kenburgett/

--  Roger Arrick -- Tyler, Texas, USA -- Ro...@Arrick.com --

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of William Beech <nj...@nj7p.info>
Sent: Thursday, December 19, 2024 1:47 PM
To: intel-...@googlegroups.com <intel-...@googlegroups.com>
Subject: Re: intel-devsys Differences between Intel ISIS and Tandberg OS

 

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/105ea09c-fa6c-4a79-915b-a0e279f1ce2d%40nj7p.info.

[Frode M]

Ok, I am now got quite the progress on going through the various tools and accessories. I won't disassemble the last couple of programs, because they are huge and serve more of a supplementary role, and currently I am focusing on looking on the system executable itself. The attached file is pretty much a "manual" for the majority of commands included with TOS.

-Frode

[Herbert Johnson]

Thanks for sharing all your TOS work. Let me/us know when and where
you've established an online archive for the TOS disk images/files and
any disassembly and descriptions such as you summary feature/revision
document. You have a github for the Tandberg terminal; and I think you
will have some archive on Bill Beech's moderated Google Drive of
Intel-related content.

Frode, with all your examination of versions of TOS codes and documents,
you are the TOS expert. Can you state definitively, that TOS was not
source-code or binary-disassembly copied from some ISIS V1.1 codes? Can
you make any claims about differences or similarities in the
early-version TOS and ISIS V1.1 "API" (system calls)? (You already said
the file systems are different I believe.) Can you examine ISIS V1.1
binaries and reconstructed PL/M sources and documents, sufficiently to
be reasonably confident (if you wish to go to that trouble)?

I ask explicitly, to avoid a later controversy. I considered explaining
the MS-DOS vs CP/M-80 (non) controversy, but that's just distracting.
Suffice it to say, I'd like to head off any confusion in the future. If
you can make clear statements at some point, I can add them to my Web
page on TOS and you can add to your archives. Thank you.

regards Herb Johnson

On 1/6/2025 4:31 AM, Frode M wrote:
> Ok, I am now got quite the progress on going through the various tools
> and accessories. I won't disassemble the last couple of programs,
> because they are huge and serve more of a supplementary role, and
> currently I am focusing on looking on the system executable itself. The
> attached file is pretty much a "manual" for the majority of commands
> included with TOS.
>
> -Frode

[Frode M]

I don't have access to any disassembly of ISIS 1.1. I do however have some listings of TOS v1.4 and XMON/D v1, but those files are too big. If anyone who has access to ISIS-1.1 disassembly are interested in comparing, I can send the listings directly.

In the mean time, I have added my own notes on the system API as a reference here. Not too many details, but in general for TOS system calls you point to a FCB and a buffer before you make the call (or eventually, use the A register for single char operations). In TOS v1.5 and more recent, there's also a PHYSINT call that generates a FCB for you in a system buffer, based on a file handle you provide. Most of the accessory programs however were not adapted to take use of this and retain their locally defined FCB data-structures.

-Frode

[Herbert Johnson]

MOre information is always better, thank Frode for adding to your
documents in progress.

The Ogden repositories for ISIS V1.1 are:

https://github.com/ogdenpm/intel80tools/blob/master/src/isis_1.1/isis_1.1_all.src

https://github.com/ogdenpm/intel80tools/tree/master/itools/isis/1.1

for some reconstructed PL/M ISIS V1.1 sources, and the V1.1 binaries
(binaries as extracted from a found disk) respectively. My brief visual
inspection of isis.bin suggests it may be an unintended mix of binary
and left-over assembly hex-records - but it may not be for all I know. I
call that to Mark Ogden's attention. The .IMG (disk binary image) of the
originating diskette is in the archive.

I'm in over my head, so any further analysis I'd give may be incorrect.
My point is simply to get the two experts on TOS and ISIS V1.1 (Frode
and Mark Ogden) to correspond sufficiently, so that one or both of you
could draw supportable conclusions about any code-level or other
relationships between the two OS's.

Again - it's hard to prove a negative, that there's NOT a relationship
at the code level; you can't prove, TOS developers did NOT have access
to ISIS sources, etc. But if the codes are "obviously" different for
reasons others can reconstruct, that's about as definitive as one can
get without a review of original source-code listings.

The immediate and obvious comparisons (edges of my knowledge) would be
disassembly to disassembly. However wasn't ISIS V1.1 initially written
in PL/M and then rewritten in more compact assembly? Frode apparently
has some TOS V1.4 sources (are they a mix of PL/M and assembly?)

The differences in TOS vs ISIS V1.1 OS calls, and the different API
details (passing arguments) will be informative; once someone states the
ISIS V1.1 API features. (I don't know casually if ISIS-II API was
different from ISIS V1.1). API similarities was, as I noted, used in the
era before to assert incorrectly that "code was copied" between two OS's.

regards Herb

On 1/7/2025 5:26 AM, Frode M wrote:
> I don't have access to any disassembly of ISIS 1.1. I do however have
> some listings of TOS v1.4 and XMON/D v1, but those files are too big. If
> anyone who has access to ISIS-1.1 disassembly are interested in
> comparing, I can send the listings directly.
>
> In the mean time, I have added my own notes on the system API as a
> reference here. Not too many details, but in general for TOS system
> calls you point to a FCB and a buffer before you make the call (or
> eventually, use the A register for single char operations). In TOS v1.5
> and more recent, there's also a PHYSINT call that generates a FCB for
> you in a system buffer, based on a file handle you provide. Most of the
> accessory programs however were not adapted to take use of this and
> retain their locally defined FCB data-structures.
>
> -Frode
>

> Jan 6 2025 20:23:52 UTC+1 Herbert Johnson:

>
> Frode, with all your examination of versions of TOS codes and
> documents,
> you are the TOS expert. Can you state definitively, that TOS was not
> source-code or binary-disassembly copied from some ISIS V1.1 codes?

[Frode M]

The source code for TOS is in assembly, and only assembly. It can broadly be divided into a few parts:

• Command line interpreter
  • User interface
  • Program loading
  • Error reporting
  • Batch-file execution
• I/O API-module
  • Functions for FCB-based data I/O
  • Line- or binary file modes available
• Block-device FCB drivers
  • One table with entry-points for each driver
  • Driver for Intel ISIS formatted media
  • Driver for IBM 3740 formatted media
  • Driver for Tandberg tape media
• Data/misc API-module
  • Dynamically creating and releasing data buffers
  • Converting between ASCII and binary
  • Assigning and releasing blocks on Intel ISIS disks
  • System timer
• API page
  • Jump-table for TOS API
  • Jump-table (alias) for XMON API
  • Pointers to block-device driver tables
  • Pointers to some system device FCBs
  • Pointers to standard file FCBs
  • A few system constants
• Assignment interpreter for standard files
  • Called by command line interpreter, not exposed
  • Parses TOS-specific command line arguments
  • Static FCBs for system devices, accessible by name
  • Dynamically generates FCBs for block-devices (files)

It can be noted that this is also very roughly the order of which these parts appear in the source code. I have also been able to get user-manuals for TOS version 1.2 and 1.4, and it seems like Tape was fully added by v1.2 while IBM 3740 format was fully added with v1.4 (there's also a mention that v1.3 was only a pre-release release for v1.4). From looking at the disassembly, I can see that batch files were added in v1.5, as well as line-oriented block devices (for easier IBM 3740 data handling).

With best regards

-Frode

[roger arrick]

Out of curiosity, are there character I/O device drivers callable through the OS?

Is that what FCB-based I/O is?  Is that File Control Block?  Has that been generalized for file and device I/O?

--  Roger Arrick -- Tyler, Texas, USA -- Ro...@Arrick.com --

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of Frode M <fvdm...@gmail.com>
Sent: Monday, January 13, 2025 1:50 PM
To: intel-devsys <intel-...@googlegroups.com>

Subject: Re: intel-devsys Differences between Intel ISIS and Tandberg OS

--
You received this message because you are subscribed to the Google Groups "intel-devsys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to intel-devsys...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/5d6f6c79-4a8c-4268-b06f-34d252e3f815n%40googlegroups.com.

[Frode M]

Yes, there are six types of FCBs, and the generalized API works with most of them:

1. Interrupt-driven character device
2. Polling-driven character device
3. Echo device (combination of one input and one output FCB, input is automatically echoed to the output)
4. Buffered device (combination of one FCB and a buffer that is filled in bulk)
5. Block device (files, buffered, contains pointer for OPEN/CLOSE/READ/WRITE functions, which point to the respective drivers)
6. Double FCB (for chained files, when the first FCB is marked EOF, data is taken from the second FCB

Of course, there's some API calls that does not work with all types of FCB, but for the most part most of these are generalized to the point that you don't have to care about what type of FCB the data comes from and to what type of FCB it is going.

-Frode

[Frode M]

To be more clear, most FCB types are handled with their intended behaviour directly in the API function calls. Only block-device FCBs points to a particular driver in the driver section of TOS. Polling-driven character devices also points to READ/WRITE functions, but those are usually pointed directly to the XMON API in ROM.

-Frode

[mark.p...@btinternet.com]

Frode

I would be happy to include the disassembly you have of TOS in my GitHub repo, if you have no objections.

I am also happy to add build makefiles if required.

Mark

 

 

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of Frode M
Sent: 13 January 2025 20:15
To: intel-devsys <intel-...@googlegroups.com>
Subject: Re: intel-devsys Differences between Intel ISIS and Tandberg OS

 

To be more clear, most FCB types are handled with their intended behaviour directly in the API function calls. Only block-device FCBs points to a particular driver.

 

-Frode

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/93debcad-d102-4ad1-b98c-5c19c98d262an%40googlegroups.com.

[Frode M]

I'm just halfways with the dissasembly of TOS system file itself, but I can link to the original listings:

https://drive.google.com/file/d/1zs2LQcjKZEdbmBsIQ7HGq_y5kccGIKR9/view?usp=drive_link 
https://drive.google.com/file/d/18kb-NlFkZOIPV99Hbxj6PtKZQzLA0GSi/view?usp=drive_link

One is for TOS 1.4, the other is for XMON/SD revision 1. The labels here are kinda short and less-than-descriptive, which is why I am doing the work getting more explanatory label names in there.

-Frode

[mark.p...@btinternet.com]

Frodo

I have been able to align most of the TOS listing with the later version I have, the main exception is PHYSINT which appears to have undergone a major rewrite. 

Regards

Mark Ogden

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of Frode M <fvdm...@gmail.com>

Sent: Monday, January 13, 2025 8:50:00 PM

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/a181e9fa-306b-4a1a-8f34-e0536dab54abn%40googlegroups.com.

[mark.p...@btinternet.com]

Frode

Sorry for the auto correction of your name

Mark 

Regards

Mark Ogden

---

From: 'mark.p...@btinternet.com' via intel-devsys <intel-...@googlegroups.com>
Sent: Tuesday, January 14, 2025 7:23:20 PM
To: intel-...@googlegroups.com <intel-...@googlegroups.com>

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/AM0PR05MB440411ED479C797571A7DDE6FC182%40AM0PR05MB4404.eurprd05.prod.outlook.com.

[Frode M]

Yes, PHYSINT was first exposed through the API in v1.5, which is the version just after the version in the listing I posted.

The old function from v1.4 named PHYSX, is purely internal, and has all the bells and whistles needed to parse file descriptors as they appear in the command line input to the assignment interpreter. Some of this functionality does not make sense in an exposed API function, so it's split into two parts in v1.5. PHYSINT does the main lifting, but there's still the PHYSX wrapper that takes care of the parts exclusive to the command line assignment-interpreter argument syntax (like, for instance, stuff like linebreak-continuation, $ ending the argument, etc..). I haven't looked too closely on PHYSINT to see in what ways they extended it over the similar functionality of the old PHYSX yet, but I guess there's some improvements. v1.5 also added :Bn: and :Jn: type files, which are variants of the :An: and :In: device types used for files on IBM 3740-format disks, and that's for sure something that must be reflected in PHYSINT.

-Frode

[mark.p...@btinternet.com]

Frode

I have now fully disassembled TOS 2.1 v 1.18 into the individual modules and it now builds a SYSTEM file that will load into memory as per the original.

Unfortunately,  I was not able to create an identical copy of SYSTEM, as I use the Intel toolset which creates an OMF file in address order. When I convert to bin format it retains this order.

The original, loads the sections out of order, especially around the module CTAB, which contains some absolute address orgs.

If I convert the original SYSTEM file to OMF using my abstool, then the files match, so when loaded into memory they are the same.

 

The code is now in my Intel80Tools repository

https://github.com/ogdenpm/intel80tools

If you clone the repository and install perl, then from in the src/tos2.1_1.18 subdirectory then the command

                ..\..\make verify

Should build and verify the code.

 

Notes:

• I haven’t yet added the limited comments from the original listing, although I have added some for PHYSINT and BUFALLOC
• Because I use my ported asm80 tool, the label names can be upto 32 characters and contain underbar, so it may help in adding sensible names.
• The code is stored in a single file and auto extracted. I do this to allow simple global edits. If you want the basic files run make and copy them as required

To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/0e8ec842-a26e-4dff-a94a-fb9ae25e5c5bn%40googlegroups.com.

[Frode M]

Thanks!

I am mostly working my way using the Ghidra dissasembler, I got quite a few versions between v1.4 and v1.81, including v1.5, v1.6, slimmed down v1.6 without tape or IBM drivers (same system size as v1.4), v1.7, v1.8 and v1.81. My project is to go through all of them in turn, first documenting the code to a point where I understand the logic of what is going on, then comparing consecutive releases to get an overview of what features changed and which bugs were fixed.

For example, the list of changes between v1.4 and v1.5 is getting quite extensive already, currently at the end of the IBM driver this far.. About 3/4 through the whole codebase:

1.4:

• Bug where line-buffered file control block is expected to have an OPEN-routine pointer at offset 0C, instead of propagating the opening operation to linked FCB
• Bug where line-buffered file does not verify that the linked file control block is an echo-file before echoing a tab ASCII control character input on a READ
• Bug where if an Intel output file is closed with it's last linking-block (out of several) being empty, it will keep the empty linking-block as well
• Bug where the binary file mode flag is used in place of the detect-EOF file mode flag for IBM files
• Bug where the file mode byte is used instead of the format flag for determining ASCII or EBCDIC for write-operations of IBM files
• Bug where IBM EOE and EOD sector numbers are treated as inclusive, not exclusive as per the format definition

1.5:

• Fixes Intel empty linking-block bug from v1.4
• Fixes IBM EOF flag bug from v1.4
• Fixes IBM ASCII/EBCDIC flag bug from v1.4
• Fixes IBM EOE/EOD sector off-by-one bug from v1.4
• Batch-file support added by having the program EXEC assign the CI file and set a special TOS internal flag
• Will not display the TOS command line prompt for each command when a batch-file is running
• Will try to close standard files, and flush CI if CI is a line-oriented file, is not empty, and the command line prompt is initiated through the TOS API call
• Blockline format flag added for block devices: The INCHAR API call generates an END OF BLOCK status message between each block being read from a block device, in Binary mode when the Blockline format flag is active.
• INCHAR will now recognize a zero-byte as end-of-line for block-devices, as an alternative to the usual ASCII newline control-character
• New PHYSINT API-call for creating FCB from file handle
• System API call added for clean restart of TOS
• Small optimization in the RELN routine, removal of unnecessary memory-fetches
• Clears and blanks IBM sector buffer after WRITEs and OPENs
• Checks for IBM end-of-file on OPEN, in case of empty file
• EOE is automatically increased by one when an IBM file is opened for output

1.61:

• Fixes line-buffered file OPEN-routine bug from v1.4

-Frode

[mark.p...@btinternet.com]

Frode

Some observations about 1.18

• There are no boundary checks on command line processing  (PHYSX). It is possible to exceed 130 chars and overwrite other memory
• From what I can tell, the filename is stored in originally specified case internally. Device names are mapped to upper case.
• The OS appears to support two name formats 6.3 (ISIS) and 8.1. Unfortunately, the check done for an invalid ISIS name with extent only, also means that the 8.1 name format fails if 2 characters only have been specified before the dot.
• BUFALLOC has no boundary checks, so could keep on going downward in memory.
• The design of the buffer management means that released buffers don’t free memory until all those following it in the buffer chain are released; until then the memory used by freed buffers cannot be reused.

 

 

As a general observation, TOS is very different from ISIS and does not appear to share architecture or code. The only common feature is that TOS supports  ISIS format disks. This may have been to support cross development on ISIS e.g. using PL/M.

.
To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/8656dde9-1043-4ca7-94a7-a8edf87b110fn%40googlegroups.com.

[Frode M]

A little clarification: The 8.1 filename support is actually just 8 with no extension, and only invoked for IBM 3740 format block devices. The routine will in fact always raise an error if you try to add any file extension to IBM files.

About the buffers, they are intended to use the space between the running program and TOS itself. A running program will be able to check how far into memory the buffers go, by the means of a BUFLIM variable that has been exposed, and can then do the necessary calculations if there's room to allocate more. Typically a program in need of more advanced memory handling would have it's own buffer management, and just assume it owns all RAM between the start of user-RAM and BUFLIM. The fragmentation issue is otherwise not that much of a problem, since TOS internally will only use the buffers for standard-file assignment dynamically allocated file control blocks, and those live for the whole duration of the running program they have been prepared for anyways.

-Frode

[Frode M]

I managed to get in touch with some of the young engineers who had worked on the Tandberg TDV-2114 back in the day, and in particular two names were mentioned. Arne Solesvik was the main responsible of the hardware architecture, and he also apparently had ties to Mycron (1975 microcomputer-company founded by Lars Monrad-Krohn, of Norsk Data fame). Software and TOS was mainly done by Bjørn Myrhaug, who had earlier done a lot of work making the heap-allocator and garbage-collector of the SIMULA-67 programming language (the very first object-oriented language). Unfortunely none of the two are still alive from what I have been told.

You received this message because you are subscribed to a topic in the Google Groups "intel-devsys" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/intel-devsys/UzblmyS-5hw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to intel-devsys...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/intel-devsys/7645e721-fc7a-4d0d-b658-d4d1d0861b82n%40googlegroups.com.