Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Image with unknown version of Intel ISIS

35 views
Skip to first unread message

Frode M

unread,
Apr 16, 2025, 12:24:17 PMApr 16
to intel-devsys
I recently archived a stash of 8" disks, and among them I found a disk with Intel ISIS, of unknown version. Comparing it to known versions, I see that the start of ISIS.BIN has most similarities with v2.2, but it's not an exact match and it diverges a bit a little into the binary.

So my guess is that this is another subversion of v2, but I don't know the reference documentation well enough to say where to find the subversion.

You can find the image attached, hope it can be of help.

This disk was found in a box of various disks that seems to have come directly from Tandberg at some point, mostly containing test-programs for the TDV-2114. Possibly from very early in the machine's lifecycle.
Intel isis 2.x image.zip

Al Kossow

unread,
Apr 16, 2025, 12:32:52 PMApr 16
to intel-...@googlegroups.com
On 4/16/25 9:24 AM, Frode M wrote:

> This disk was found in a box of various disks that seems to have come directly from Tandberg at some point, mostly containing test-programs
> for the TDV-2114. Possibly from very early in the machine's lifecycle.
>

have you come across any source disks for their tape products?

Frode M

unread,
Apr 16, 2025, 3:06:38 PMApr 16
to intel-devsys
Any particular tape products you were curious about?

I did see a disk with a PROM test for the TDV-2100 series Cartridge Controller MkII. That controller is for a bare set of TDC-3000 tape drives without built-in formatter and interface. For my own case I do have a physical example of this card, and at some point I intend to do a full reverse-engineering of it (like I did with the DSDD floppy controller card). That should reveal the full command-set and interface API from the 8080 CPU's perspective.

I have also been able to get my hands on an actual TDC-3000 that had a built-in formatter and serial-port interface option. No source-code, but I got all ROMs dumped there too and I started looking a little at some disassembly of the firmware to verify that it's a good dump. The formatter/serial interface is however very low on the priority-list to reverse engineer, since it's not to be used together with the TDV-2100 series cartridge controller.

Another thing I have is the TDV-2114 cartridge controller API option ROM. This has 8080-code for interfacing with the mentioned cartridge controller, and that can also help a bit with my plans to reverse engineer the cartridge controller hardware. I do have a brief reference to what the different API calls does already.

--------

But back to the topic. One thing I think is pretty fair to assume, is that Tandberg were using Intel development-machines to write the initial code for the TDV-2114. In that case the disk I mentioned above would have been used on one of those development-machines.

With best regards
-Frode

mark.p...@btinternet.com

unread,
Apr 17, 2025, 3:51:57 AMApr 17
to intel-...@googlegroups.com

Frode

Looking at the disk, the files are all ISIS.BIN files, putting it in the V1, category. The version and edit fields at 0x3e and 0x3f, suggest this is ISIS v1.2 which I haven’t seen before.

Like V1.1, the PL/M source was compiled with the Fortran based cross compiler.

 

Note my unidsk tool can be used to extract all the files if required.

Mark

--
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/65d7b58e-ec7e-48d6-8aa9-509beb3fa7d5n%40googlegroups.com.

mark.p...@btinternet.com

unread,
Apr 17, 2025, 11:36:58 AMApr 17
to intel-...@googlegroups.com

I would also note that the disk contains

asm80 - ISIS 8080 Macro Assembler V1.1

edit – v1.3

upm – v1.1

ice80 – v2.0

 

Note the disk found with ISIS 1.1 (16k) came with

as80 – V1.0 of the 16K ISIS 8080 Assembler

edit – V1.2

 

Mark

mark.p...@btinternet.com

unread,
Apr 17, 2025, 1:59:32 PMApr 17
to intel-...@googlegroups.com
All
Preliminary disassembly of the Isis.bin suggests it may have been written in pl/m (Fortran version) and includes the sys calls omitted in the 16k Isis v1.1. Given that the v1.1 was in assembler and looked like it was hand optimised from pl/m code, my suspicion is that there was a full v1.1 written in pl/m which was cut down to run in 16k. 
Over the coming week or so I will look to get the v1.2 Isis decompiled as I have done for the other versions. I will also decompile some of the utilities. The work will be published on my GitHub site
Mark

Regards
Mark Ogden
From: mark.pm.ogden via intel-devsys <intel-...@googlegroups.com>
Sent: Thursday, April 17, 2025 4:36:55 PM
To: intel-...@googlegroups.com <intel-...@googlegroups.com>

William Beech

unread,
Apr 17, 2025, 4:06:02 PMApr 17
to intel-...@googlegroups.com
Frode/Mark,

Good work.  Another version recovered.  Is the 16K V1.1 the V1.1 we had earlier? 

Thanks!

Bill

mark.p...@btinternet.com

unread,
Apr 18, 2025, 4:38:32 AMApr 18
to intel-...@googlegroups.com

Bill

Yes the 16K V1.1 is the V1.1 we had earlier, hence my speculation there may have been a full v1.1 at some point

mark.p...@btinternet.com

unread,
Apr 19, 2025, 11:05:32 AMApr 19
to intel-...@googlegroups.com

All

I have now fully decompiled the V1.2 ISIS.BIN and ISIS.T0 files which are fortunately only slightly change from V1.1/V2.2. I will share once I have decompiled some of the utilities.

Some key observations

  1. The code is written in PL/M compiled with the Fortran cross compiler
  2. It supports up to two SD disks, F0 & F1. Note without the same hack I used for V1.1, you cannot use DD drive controllers to read SD disks
  3. Unlike later versions, parameters passed e.g. file names, must be in upper case. Later versions allowed lower case
  4. The standard set of SYSCALLS as used in V2 are supported but not PATH which was introduced in V3.
    The 16k ISIS V1.1, excluded SEEK, CONSOL and WHOCON
  5. The above noted LOAD uses the old BIN format not OMF as used in V2 onwards
  6. The undocumented SYSCALL ‘D’ is different, in that the param2 is checked for ‘SK’ i.e. CALL ISIS(‘D’, ‘SK’, …)
  7. If you convert the BIN files to OMF format, I suspect most would run on later versions of ISIS, unless they make use of LOAD or the ‘D’ syscall
    If you want to experiment, using binobj or my abstool will help you to convert the files.

Mark

 

From: mark.p...@btinternet.com <mark.p...@btinternet.com>
Sent: 18 April 2025 09:38
To: 'intel-...@googlegroups.com' <intel-...@googlegroups.com>
Subject: RE: intel-devsys Image with unknown version of Intel ISIS

 

Bill

Yes the 16K V1.1 is the V1.1 we had earlier, hence my speculation there may have been a full v1.1 at some point

Mark

 

 

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of William Beech


Sent: 17 April 2025 21:05
To: intel-...@googlegroups.com

William Beech

unread,
Apr 19, 2025, 7:11:01 PMApr 19
to intel-...@googlegroups.com
Mark,

Thanks!  And good work on the decompilation work.

Bill

mark.p...@btinternet.com

unread,
Apr 21, 2025, 10:40:33 AMApr 21
to intel-...@googlegroups.com

All

I have now published the reconstructed source on my github site, specifically as part of https://github.com/ogdenpm/intel80tools

I have updated some of the support tools contained in the tools directory to support some special requirements for the build and also fix some bugs I found in my tools

 

The original V1.2 disk contents are under itools/isis/1.2/

The decompiled files are under src/isis_1.2

Currently I have decompiled

Asmb, asmb12, attrib, batch, copy, delete, dir, edit, format, hexbin, isis.bin, isis.cli, isis.t0, load, rename and type

 

I may decompile asm80 at some point, but currently do not intend to decompile ice80, prom or upm.

 

For those new to my github site, if you clone the repository under windows and install perl, then you can build the files by changing to the src/isis_1.2 directory and entering the command

..\..\make

 

or

..\..\make verify              (to build and verify)

 

If you want to build everything, then change to the src/ directory and enter the command

..\make -j

Again verify can be added

Note the -j allow parallel build so is faster but it is not necessary

 

There are also some cpm files, which can be built by changing to the cpmsrc/ directory and entering the command

..\make

Again -j and verify can be added.

To only build a specific tool, change to it’s directory and enter the command

..\..\make

 

Mark

 

From: mark.p...@btinternet.com <mark.p...@btinternet.com>
Sent: 19 April 2025 16:06
To: 'intel-...@googlegroups.com' <intel-...@googlegroups.com>
Subject: RE: intel-devsys Image with unknown version of Intel ISIS

 

All

I have now fully decompiled the V1.2 ISIS.BIN and ISIS.T0 files which are fortunately only slightly change from V1.1/V2.2. I will share once I have decompiled some of the utilities.

Some key observations

  1. The code is written in PL/M compiled with the Fortran cross compiler
  2. It supports up to two SD disks, F0 & F1. Note without the same hack I used for V1.1, you cannot use DD drive controllers to read SD disks
  3. Unlike later versions, parameters passed e.g. file names, must be in upper case. Later versions allowed lower case
  4. The standard set of SYSCALLS as used in V2 are supported but not PATH which was introduced in V3.
    The 16k ISIS V1.1, excluded SEEK, CONSOL and WHOCON
  5. The above noted LOAD uses the old BIN format not OMF as used in V2 onwards
  6. The undocumented SYSCALL ‘D’ is different, in that the param2 is checked for ‘SK’ i.e. CALL ISIS(‘D’, ‘SK’, …)
  7. If you convert the BIN files to OMF format, I suspect most would run on later versions of ISIS, unless they make use of LOAD or the ‘D’ syscall
    If you want to experiment, using binobj or my abstool will help you to convert the files.

Mark

 

Sent: 18 April 2025 09:38

To: 'intel-...@googlegroups.com' <intel-...@googlegroups.com>
Subject: RE: intel-devsys Image with unknown version of Intel ISIS

 

Bill

Yes the 16K V1.1 is the V1.1 we had earlier, hence my speculation there may have been a full v1.1 at some point

Mark

 

 

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of William Beech


Sent: 17 April 2025 21:05
To: intel-...@googlegroups.com

mark.p...@btinternet.com

unread,
Apr 24, 2025, 5:58:21 AMApr 24
to intel-...@googlegroups.com

All

I have now added the decompilation of asm80 V1.1 to my github site.

The macro assembler only supports MACRO and ENDM and not the full set of features supported by the latest ISIS assembler.

 

Additional changes

  1. asmb.asm and asmb12.asm have been updated to reflect that they patch the page size for asm80
  2. An updated version of plm82.exe has been added. The decompilation of asm80 revealed a bug in my port of the Fortran program which would cause it to crash.

 

 

Some additional notes

  • Whilst the code compiles and produces byte level match, I cannot vouch that the variable names are always sensible, hopefully most are.
  • For several of the apps I took other versions as a starting point, this means that comments and variable/procedure names may not be the most appropriate for these versions
  • ISIS.T0, is a binary image. The associated patch file inserts appropriate data in the uninitialised data areas so that the final files match
  • ISIS.BIN has a 0 start address which is what the V2 Fortran cross compiler would generate. My port is modelled on the V4 compiler which generates a start address of 3BH as expected.
    I modified my abstool so that the patch file can force a start address, although it does issue a warning.
    Note, the start is address is never used in ISIS.BIN as its code is invoked by ISIS syscalls, including EXIT which loads ISIS.CLI

 

Mark

 

 

Sent: 19 April 2025 16:06

To: 'intel-...@googlegroups.com' <intel-...@googlegroups.com>
Subject: RE: intel-devsys Image with unknown version of Intel ISIS

 

All

I have now fully decompiled the V1.2 ISIS.BIN and ISIS.T0 files which are fortunately only slightly change from V1.1/V2.2. I will share once I have decompiled some of the utilities.

Some key observations

  1. The code is written in PL/M compiled with the Fortran cross compiler
  2. It supports up to two SD disks, F0 & F1. Note without the same hack I used for V1.1, you cannot use DD drive controllers to read SD disks
  3. Unlike later versions, parameters passed e.g. file names, must be in upper case. Later versions allowed lower case
  4. The standard set of SYSCALLS as used in V2 are supported but not PATH which was introduced in V3.
    The 16k ISIS V1.1, excluded SEEK, CONSOL and WHOCON
  5. The above noted LOAD uses the old BIN format not OMF as used in V2 onwards
  6. The undocumented SYSCALL ‘D’ is different, in that the param2 is checked for ‘SK’ i.e. CALL ISIS(‘D’, ‘SK’, …)
  7. If you convert the BIN files to OMF format, I suspect most would run on later versions of ISIS, unless they make use of LOAD or the ‘D’ syscall
    If you want to experiment, using binobj or my abstool will help you to convert the files.

Mark

 

Sent: 18 April 2025 09:38


Subject: RE: intel-devsys Image with unknown version of Intel ISIS

 

Bill

Yes the 16K V1.1 is the V1.1 we had earlier, hence my speculation there may have been a full v1.1 at some point

Mark

 

 

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of William Beech


Sent: 17 April 2025 21:05
To:

mark.p...@btinternet.com

unread,
Apr 28, 2025, 9:11:56 AMApr 28
to intel-...@googlegroups.com

All

I finally got around to refreshing the Intel repository on my website at https://mark-ogden.uk/files/intel/. The key changes are

  1. publications - Several new documents have been added and some have bookmarks added to aid navigation
  2. additional files have been added, including isis 1.2.
  3. the prebuilt tools for mkidsk and unidsk now support ISIS 1.2. The tool source is available on my Github disktools repository
  4. unirmx has been added which is similar to unidsk but works better for ISIS IV and iRMX files, however it currently only supports binary images.
  5. additional Intel tools and applications have been added under irmx, isis_iv, xenix, msdos and cpm.

 

The latest copy of the repository, excluding cpm and the publications can be downloaded using the file repository-20250428.7z.

I no longer intend to support the download of the whole publications repository as a couple of 7zip files or as a set of updates, as it now occupies ~13Gb.
The publications can be filtered in the web view.

 

Regards

Mark

 

mark.p...@btinternet.com

unread,
May 3, 2025, 6:50:06 PMMay 3
to intel-...@googlegroups.com

All

Despite previous comments that I didn’t intend to decompile upm, I have done so and added to the ISIS 1.2 source code now posted on github.

Part way through I did partially regret starting as the decompiled source code is over 1900 lines long.

There were a number of challenges I had to work around due to differences in the compilers used

  1. In several places I had to put dummy labels in so that the compiler did not optimise lxi h,xxyy to mvi l,yy. It appears V4 detects the value of hl a little better than V2.
  2. One location the compiler I used created an explicit entry for an empty case statement, whilst the original code had optimised it away.
    I was able to simulate this by commenting out the null statement and putting inline DATA after the case statement to enter the optimised vector. If you are modifying the code, it would be better to remove this “hack” rather than modifying it.
  3. I haven’t created sensible names for many of the procedures and variables; however I have tried to be consistent where I have generated names from the original locations, specifically

Sxxxx    for procedure at xxxx

Bxxxx    for simple byte variable at xxxx

Wxxxx  for simple address/word variable at xxxx

BAxxxx  for byte array at xxxx

                WAxxxx for word array at xxxx

                Pxxxx (padding) or Uxxxx (unused) for unused variable at xxxx

  1. There were many cases where I had to re-write decompiled code to generate code that matched the original, even when there was no semantic difference.

 

Given that decompiling the code generated by the Fortran cross compiler has a number of specific issues especially

  1. Address optimisation
  2. Passing of more than 2 parameters
  3. Forcing word variables onto even boundary, which interacts with the address optimisation
  4. Register spill locations, which are implicit rather than declared variables

When I get an opportunity, I will update my notes on decompiling (doc/misc.pdf) to include the additional techniques I use along with additional refinements that I now use.

 

Mark

 

 

From: mark.p...@btinternet.com <mark.p...@btinternet.com>
Sent: 24 April 2025 10:58
To: 'intel-...@googlegroups.com' <intel-...@googlegroups.com>
Subject: RE: intel-devsys Image with unknown version of Intel ISIS

 

All

I have now added the decompilation of asm80 V1.1 to my github site.

The macro assembler only supports MACRO and ENDM and not the full set of features supported by the latest ISIS assembler.

 

Additional changes

  1. asmb.asm and asmb12.asm have been updated to reflect that they patch the page size for asm80
  2. An updated version of plm82.exe has been added. The decompilation of asm80 revealed a bug in my port of the Fortran program which would cause it to crash.

 

 

Some additional notes

  • Whilst the code compiles and produces byte level match, I cannot vouch that the variable names are always sensible, hopefully most are.
  • For several of the apps I took other versions as a starting point, this means that comments and variable/procedure names may not be the most appropriate for these versions
  • ISIS.T0, is a binary image. The associated patch file inserts appropriate data in the uninitialised data areas so that the final files match
  • ISIS.BIN has a 0 start address which is what the V2 Fortran cross compiler would generate. My port is modelled on the V4 compiler which generates a start address of 3BH as expected.
    I modified my abstool so that the patch file can force a start address, although it does issue a warning.
    Note, the start is address is never used in ISIS.BIN as its code is invoked by ISIS syscalls, including EXIT which loads ISIS.CLI

 

Mark

 

 

Sent: 19 April 2025 16:06

To: 'intel-...@googlegroups.com' <intel-...@googlegroups.com>
Subject: RE: intel-devsys Image with unknown version of Intel ISIS

 

All

I have now fully decompiled the V1.2 ISIS.BIN and ISIS.T0 files which are fortunately only slightly change from V1.1/V2.2. I will share once I have decompiled some of the utilities.

Some key observations

  1. The code is written in PL/M compiled with the Fortran cross compiler
  2. It supports up to two SD disks, F0 & F1. Note without the same hack I used for V1.1, you cannot use DD drive controllers to read SD disks
  3. Unlike later versions, parameters passed e.g. file names, must be in upper case. Later versions allowed lower case
  4. The standard set of SYSCALLS as used in V2 are supported but not PATH which was introduced in V3.
    The 16k ISIS V1.1, excluded SEEK, CONSOL and WHOCON
  5. The above noted LOAD uses the old BIN format not OMF as used in V2 onwards
  6. The undocumented SYSCALL ‘D’ is different, in that the param2 is checked for ‘SK’ i.e. CALL ISIS(‘D’, ‘SK’, …)
  7. If you convert the BIN files to OMF format, I suspect most would run on later versions of ISIS, unless they make use of LOAD or the ‘D’ syscall
    If you want to experiment, using binobj or my abstool will help you to convert the files.

Mark

 

Sent: 18 April 2025 09:38


Subject: RE: intel-devsys Image with unknown version of Intel ISIS

 

Bill

Yes the 16K V1.1 is the V1.1 we had earlier, hence my speculation there may have been a full v1.1 at some point

Mark

 

 

From: intel-...@googlegroups.com <intel-...@googlegroups.com> On Behalf Of William Beech


Sent: 17 April 2025 21:05
To:

Herbert Johnson

unread,
May 4, 2025, 11:41:45 AMMay 4
to intel-...@googlegroups.com
Mark, one of the virtues of disassembly or in your case decompliation,
is that one learns a lot about coding and related things. Where original
codes get tricky (or lucky), one learns those tricks (or gets insight).
Your remarks on UPM decompliation makes that case. So challenges are
also opportunities, that's an old saying.

UPM operates the UPP, the Universal PROM Programmer 4040 dedicated
system from Intel in the early intellec (lower case i) systems. I've
maintained a Web page on those units for some time.

https://www.retrotechnology.com/restore/int_upp.html

As a side hustle, I've kept track of Intel's 4001 mask-ROMS slash I/O
devices, because 1) so many of the UPP's cards used those 4001's and 2)
so many of those ROMS were *pulled* from as-sold-today cards: as
trophies for chip collectors. Like ivory hunters and elephants, the
boards are killed when the ROMs are removed. So my list provides some
trail back, if someone wants to restore a board. That's an unlikely
event for the UPP but more likely for other products which used the 4001.

https://www.retrotechnology.com/restore/upp_4001.txt

I think it's good to reconstruct UPM code, to preserve the operation of
the UPP with the intellec 8/80. I don't recall if the UPM code worked
with the later Intel MDS development systems? Does your work with the
code (or other's use of UPM) suggest it will operate on later 8080 Intel
systems? And UPM source will likely help in constructing operating code
for even later Intel (or non-Intel/ISIS) systems to run the UPP and its
modules. So those are the immediate benefits as I see them.

Regards Herb

On 5/3/2025 6:50 PM, mark.pm.ogden via intel-devsys wrote:
> All
>
> Despite previous comments that I didn’t intend to decompile upm, I have
> done so and added to the ISIS 1.2 source code now posted on github.
>
> Part way through I did partially regret starting as the decompiled
> source code is over 1900 lines long.
>
> There were a number of challenges I had to work around due to
> differences in the compilers used...

> When I get an opportunity, I will update my notes on decompiling
> (doc/misc.pdf) to include the additional techniques I use along with
> additional refinements that I now use.
>
> Mark
--
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

mark.p...@btinternet.com

unread,
May 4, 2025, 12:19:24 PMMay 4
to intel-...@googlegroups.com
Herb
With some minor changes to compile with the more modern PLM compiler and relocation to a higher base address for later versions of ISIS the code has nothing particularly unusual. It would require the I/O port to be at the same location. 
A minor issue which shouldn’t be a major problem is that some of the syscall return values only reserve a byte. This is easily fixed although probably not necessary as locations overwritten appear to be out of scope when the syscalls are made. 
As to none ISIS systems a small number of changes would be needed around the file I/O but nothing major. 
Mark

Regards
Mark Ogden

Subject: Re: intel-devsys Image with unknown version of Intel ISIS
--
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.
Reply all
Reply to author
Forward
0 new messages