From: On Behalf Of Frode M Sent: 16 April 2025 17:24 To: intel-devsys Subject: intel-devsys Image with unknown version of Intel ISIS 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. From: mark.pm.ogden via intel-devsys Sent: 17 April 2025 08:52 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 From: mark.pm.ogden via intel-devsys Sent: Thursday, April 17, 2025 4:36:55 PM 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 On 4/17/2025 10:59 AM, Mark Ogden via intel-devsys wrote: 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 Regards Mark Ogden From: intel-devsys@googlegroups.com On Behalf Of William Beech Sent: 17 April 2025 21:05 Frode/Mark: Good work. Another version recovered. Is the 16K V1.1 the V1.1 we had earlier? Thanks! - Bill From: Mark Ogden Sent: 18 April 2025 09:38 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: Mark Ogden Sent: 19 April 2025 16:06 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 The code is written in PL/M compiled with the Fortran cross compiler 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 Unlike later versions, parameters passed e.g. file names, must be in upper case. Later versions allowed lower case 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 The above noted LOAD uses the old BIN format not OMF as used in V2 onwards The undocumented SYSCALL ‘D’ is different, in that the param2 is checked for ‘SK’ i.e. CALL ISIS(‘D’, ‘SK’, …) 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 Ogden date Apr 21, 2025, 10:40:33 AM T: 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 Ogden Sent: 24 April 2025 10:58 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 asmb.asm and asmb12.asm have been updated to reflect that they patch the page size for asm80 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 From: Mark Ogden Sent: May 3 2025 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 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. 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. 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 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 Address optimisation Passing of more than 2 parameters Forcing word variables onto even boundary, which interacts with the address optimisation 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: Herb Johnson Date: May 4 2025 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. From: Mark Ogden Date: May 4 2025 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 [serial] 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. Regards Mark Ogden