Ran across this posting today on FB and thought yall'd find it interesting - Roger Arrick [Facebook post by Frode about Tandberg system] Mark Ogden, Sept 8 2023 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 Frode, Dec 15 2023 post in intel_devsys: ---------------------------------------- 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. - Frode] 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, in intel_devsys, Dec 15 2023 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 Frode responds, intel_devsys, Dec 15 2023 ------------------------------------------ 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 [of this document:] 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