tandberg OS like ISIS-II?

[roger arrick]

Ran across this posting today on FB and thought yall'd find it interesting

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

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

It could well have been derived from ISIS and the executable format may be that used in ISIS 1, which is the same as the binary format used for ISIS.BIN. 

Regards

Mark Ogden

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of roger arrick <ro...@arrick.com>
Sent: Thursday, September 7, 2023 10:57:39 PM
To: intel-...@googlegroups.com <intel-...@googlegroups.com>
Subject: intel-devsys tandberg OS like ISIS-II?

 

Ran across this posting today on FB and thought yall'd find it interesting

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

--
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 on the web visit https://groups.google.com/d/msgid/intel-devsys/DM6PR14MB3449960AA38BCFC9317A46E0D8EEA%40DM6PR14MB3449.namprd14.prod.outlook.com.

[Frode M]

Hi, I am the owner of this machine. I talked a bit with Herbert J. about it, and he gave me some good pointers and suggested me checking out this place.

I did some more investigation on this topic based on what I learnt from Herbert. Based on what I see in the ISIS-1.1 image on Mark's Github, I can confirm that files there indeed has the same executable format as is used by Tandberg OS. However, about the system tools, it can be worth noting that the implementation in TOS is written directly in assembly instead of being compiled from higher-level languages (as seems to be the case with most system tools in ISIS).

When it comes to the ROM, Kernel and Monitor, things start to diverge more. The Monitor has much the same commands, syntax and functionality as the Intellec monitor, but the similarities stop at that level. The kernel is located in completely different parts of memory, and the API calls are very different as well.

To me it seems like this was done in a way to make it possible to do the meat of your development using an Intel machine, and whenever something needed to be tested on actual hardware it would first be pinned to a RAM address with hex2bin in ISIS, then run directly on a TDV-2114 booted with TOS. Since the disk and bin format is the same, there would be no need to do anything else than just swapping the disk between the machines. The similarities in the Monitor would make it so that debugging follow pretty much the same workflow as well. In effect letting a developer work with both systems at the same time, without having to relate to different working-environments. I can only speculate if this was done for their own sake when developing TOS in the first place, or if they assumed their customers would be most familiar with the Intel development machines at the time.

-Frode

[Frode M]

Small correction, I meant to say "pinned to a RAM address with OBJHEX in ISIS and then made runnable with HEXBIN". If your release of ISIS did not come with a HEXBIN, TOS has its own version of this tool.

-Frode

[Herbert Johnson]

I had some email discussions with Frode. At some point I'll add them to
my ISIS Web pages. Without looking at early ISIS 1.1 and these Tanberg
OS files myself, I'll suggest a simple analysis.

Tandberg simply chose not to license ISIS from Intel. So they created
similar-functioning code. They chose to save memory space (maybe another
license) by writing in assembler instead of PL/M-80. Tandberg simply
followed where ISIS led, out of convenience. Replicating the ISIS file
system was convenient for moving disks between the two systems as Frode
suggests. It's a little surprising, that Tandberg did not follow the
ISIS API scheme in detail. Reasons may be apparent with code
comparisons, or it may be for arbitrary (or deliberate) reasons.

This is interesting, by contrast with CP/M-80, which was replicated
multiple times, down to the API (including with MS-DOS). But CP/M had a
large (later a huge) customer base; ISIS did not. Some of this history
is a matter of timing, depending when Tandberg did their development
work. Apparently it was early, if they followed the ISIS 1.1 schemes.

> the meat of your development

Which development? There's development of the OS and its tools; and then
there's applications development, to run programs for purpose. If the
Tandberg OS has the tools needed to run and develop applications - as
you suggest - that's enough for Tandberg customers.

For those who compare the ISIS/Tandberg codes, let me know if my guesses
are provably wrong. Also It would be good to "date" the Tandberg code,
usually there's date fragments in binaries. I don't know when or if I'll
get to doing that analysis.

Mark Ogden, I'll be glad to point on my ISIS Web page, to the Facebook
content you referenced, if you provide whatever FB has as a Web link.

Regards Herb

On 12/15/2023 12:15 PM, Frode M wrote:
> Hi, I am the owner of this machine. I talked a bit with Herbert J.
> about it, and he gave me some good pointers and suggested me
> checking out this place.
>
> I did some more investigation on this topic based on what I learnt
> from Herbert. Based on what I see in the ISIS-1.1 image on Mark's
> Github, I can confirm that files there indeed has the same
> executable format as is used by Tandberg OS. However, about the
> system tools, it can be worth noting that the implementation in TOS
> is written directly in assembly instead of being compiled from
> higher-level languages (as seems to be the case with most system
> tools in ISIS).
>
> When it comes to the ROM, Kernel and Monitor, things start to
> diverge more. The Monitor has much the same commands, syntax and
> functionality as the Intellec monitor, but the similarities stop at
> that level. The kernel is located in completely different parts of
> memory, and the API calls are very different as well.
>
> To me it seems like this was done in a way to make it possible to do
> the meat of your development using an Intel machine, and whenever
> something needed to be tested on actual hardware it would first be
> pinned to a RAM address with hex2bin in ISIS, then run directly on a
> TDV-2114 booted with TOS. Since the disk and bin format is the same,
> there would be no need to do anything else than just swapping the
> disk between the machines.

>> Small correction, I meant to say "pinned to a RAM address with OBJHEX in
>> ISIS and then made runnable with HEXBIN". If your release of ISIS did
>> not come with a HEXBIN, TOS has its own version of this tool.
>>

> The similarities in the Monitor would
> make it so that debugging follow pretty much the same workflow as
> well. In effect letting a developer work with both systems at the
> same time, without having to relate to different
> working-environments. I can only speculate if this was done for
> their own sake when developing TOS in the first place, or if they
> assumed their customers would be most familiar with the Intel
> development machines at the time.
>
> -Frode

--
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]

Date:
In a company newsletter from the early 80's, Tandberg mentions that "the TDV-2114 has been around since 1976". This goes well with that the keyboard to my machine have parts from early 1977 although the rest of my machine was put together around 1982. I don't know if this means it was developed in 1976, or if it was in full-scale production at that time. See page 6: http://heim.bitraf.no/tingo/files/other/Tandberg_Data_Newsletter_volume_5_no_1_june_1982.pdf

Documentation:

Manuals for the Siemens-OEM version of the TDV-2114 exists, and have been scanned by someone in Germany. The hardware and software is identical, except for some cosmetic differences (translated strings, outer casing): https://www.technikum29.de/de/geraete/Siemens_6610/Siemens_6610_PDFs/

ROMs:

These can be found on my GitHub, with firmware from a few different machines. My own machine, a dump done by a TDV-2114 owner in Germany, and a dump I made from a loose CPU card I got from Mattis Lind at Dalby Datormuseum in Sweden. I am currently working on disassembling these. ROMs can in the mean time be found here: https://github.com/Frodevan/Tandberg/tree/main/TDV-2100/ROM-Files

Software:

I have not shared too much myself here, but Mattis do host the image of a TOS disk (v1.81, latest version before the version-2 overhaul) on the Datormuseum webpage. When he uploaded it back in the day, he mistook it as an ISIS disk: http://www.datormuseum.se/documentation-software/isis-ii-floppy-disks.html

I do have a disk with TOS v2.3, but where version 1.x is simplistic like ISIS, version 2 was expanded a lot. Syntax is the same, but there's a lot more going on under the hood, and most tools are a lot more refined. As such I am not sure if it will contribute much to the initial development of this machine. Check out the link for the documentation above for a manual (in German) describing TOS version 2 and what arguments were available for the different tools. Since this manual is for the OEM machine, the OS is of course in German and also rebranded as "BS1MP", but everything else is still the same.

In short: The main architectural differences is that the TDV-2114 has its kernel ROM permanently at address 0x0000 to 0x1FFF, with a dedicated RAM working-area from 0x2000 to 0x27FF. Both of these are located on the CPU module, are permanently present, and cannot be moved or masked. To use an operating system, additional RAM modules needs to be installed in the machine, filling up 0x3000 to 0xFFFF for early machines, and eventually 0x2800 to 0xFFFF for later machines. The ROM kernel API uses a jump-table at ROM address 0x0040 to 0x008D, where some versions of the kernel has a bigger jump-table if extra functionality is supported (f.ex. stuff like a tape-drive or the double-density floppy-disk drive). There are also pre-defined parameter variables in the ROM Kernel work RAM, and these will be used by various programs too. Likewise, the TOS API also uses two jump-tables, but at address 0xFD00 and 0xFD40 respectively. Most programs for TOS version 1.x will use both the Kernel API and the TOS API, while most programs I have seen for TOS version 2.x use the API for TOS exclusively for everything.

-Frode

[Frode M]

I have recently gotten complete disks with Tandberg OS v1.5, v1.6 and v1.7, and am in the middle of dissasembling all of them to put together some sort of  extensive changelog for the accessories and tools. One thing I do note, though..

While TOS is very much based on the Intel ISIS disk format and the Intel Absolue Binary file format, it does in fact have device types for IBM 3740 file system floppies built in natively. There's also extra tools to set the file parameters of these, since this file format is a lot more verbose than what you can get in through the typical Intel ISIS style file transfer commands.

There's also more file attributes in TOS, for instance an "alias" attribute that basically lets you create symlinks of files on the same disk.

-Frode

[Frode M]

I have gotten some more versions of Tandberg OS, and am in the works of disassembling everything to learn more about how things work. In the process I have found a few differences from Intel ISIS. Sorry for the wall of text, but here we go:

First of all, one thing to note is that TOS has a dual CLI parameter in the form of CMD [TOS args]$[command args]. This first set of arguments always goes to TOS and only TOS, and 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 this, is that instead of setting up every file-control block locally the program gets a set of FCBs from TOS. In particular, CI and CO for console in and output, SI SL and SO for primary file input, line-polling, 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

fredag 15. desember 2023 kl. 21:23:59 UTC+1 skrev Frode M:

[roger arrick]

I hope this information about Tandberg OS is collected and posted permanently on a website for preservation purposes.
I don't have the knowledge of it or the time to do the write up but I can offer to host the info on my website and archive along with other early intel dev system info.
No, I don't sell ads.

Someone just provide me a giant .txt or .pdf with a 1 paragraph description.

https://www.rogerarrick.com/computers/

RogerArrick.com Roger Arrick Computer Hardware and Software Percom was a tech company founded by Harold Mauch and wife Lucy in Garland Texas in 1976. Percom built cassette interfaces and disk drives for early computers including TRS-80, SWTPC, Atari, IBM, SS50 bus, S100 bus, etc. www.rogerarrick.com

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

---

From: intel-...@googlegroups.com <intel-...@googlegroups.com> on behalf of Frode M <fvdm...@gmail.com>
Sent: Thursday, December 19, 2024 8:23 AM
To: intel-devsys <intel-...@googlegroups.com>
Subject: Re: intel-devsys Re: tandberg OS like ISIS-II?

 

--
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/aaa02b45-1953-4190-9d52-1c4cac2a3bc0n%40googlegroups.com.

[Herbert Johnson]

Roger, what I've done on my site, is reference Frode's information and
provide some interim descriptions and progress reports. I've encouraged
people like Frode accordingly. But I'm not an archive site, I'm a
restoration and recovery site. I point to archives often.

Generally I don't intend to provide tens of gigabytes of storage for
archiving a lot of content. Other people have those interests and means
of doing so. I appreciate their efforts. So, it's thoughtful for Roger
to note the need for archiving and accessing this content, *and* to
offer his resources accordingly.

I'm reluctant to discuss mechanics of how archives work and are used,
and how they sustain themselves. That could be another thread, if people
are so inclined.

Meanwhile this thread is about Frode's work in gathering Tandberg
information and relating it to the ISIS V1.X interests here. Presumably
others with ISIS 1.X knowledge will make the connections with Tandberg
TOS, and then provide their own analysis and link it to Rrode's and to
their own ISIS resources; as I've linked and content-added Tandberg TOS
to my ISIS 1.X content.

Regards Herb

On 12/20/2024 10:52 AM, roger arrick wrote:
> I hope this information about Tandberg OS is collected and posted
> permanently on a website for preservation purposes.
> I don't have the knowledge of it or the time to do the write up but I
> can offer to host the info on my website and archive along with other
> early intel dev system info.
> No, I don't sell ads.
>
> Someone just provide me a giant .txt or .pdf with a 1 paragraph description.
>
> https://www.rogerarrick.com/computers/
>

> ------------------------------------------------------------------------
> *From:* intel-...@googlegroups.com <intel-...@googlegroups.com> on

> behalf of Frode M <fvdm...@gmail.com>

> *Sent:* Thursday, December 19, 2024 8:23 AM
> *To:* intel-devsys <intel-...@googlegroups.com>
> *Subject:* Re: intel-devsys Re: tandberg OS like ISIS-II?

>
> I have gotten some more versions of Tandberg OS, and am in the works of
> disassembling everything to learn more about how things work. In the
> process I have found a few differences from Intel ISIS. Sorry for the
> wall of text, but here we go: