There is another reason we might need to be able to re-build IS-DOS: EXDOS 3 and FAT16 support in CP/M apps.

EXDOS 3 has to use an extra byte in the "reserved" area of the FISH FCB structure (for flags which were previously held in the top 4 bits of a FAT12 cluster number). The question that has been in my mind recently is: when IS-DOS converts FISH FCBs to CP/M FCBs, and back again, is this byte also copied? Probably not but I haven't been able to try it yet Looking at the source now, definitely not .

I cannot remember from 30+ years ago if there is an unused / reserved byte in CP/M FCBs that can be used; if there are, it should be an easy fix but if there are not, it will need more thought...

There is another reason we might need to be able to re-build IS-DOS: EXDOS 3 and FAT16 support in CP/M apps.

I cannot remember from 30+ years ago if there is an unused / reserved byte in CP/M FCBs that can be used; if there are, it should be an easy fix but if there are not, it will need more thought...

One of the things that I'd love to import from other versions of CP/M 2.2, if it isn't already used in IS-DOS, is the otherwise-undefined LAST RECORD BYTE COUNT, that CP/M 3 uses to define exact file sizes.

https://www.seasip.info/Cpm/bytelen.html

Maybe, once the code sorted, you can compare it with the EXDOS+ISDOS Rom we manage. As far as I know the two Roms were packed on Hungary, not by Intelligent Software. But I don't know if in this case the Rom is only a container to load in Ram the ISDOS extension.

The "ROM ISDOS" just copy (decompress) the IS-DOS.SYS file to 100h and start is, simulate the original 05h type file start.
And only a little modification: when the IS-DOS reload itself, modified it for copy it again from ROM instead from loading from disk.

Just in case anyone else is trying: using M80 with XCPM when I was working on EXDOS, I found that it could not produce .PRN files. Might just be the Linux version...

Under Windows is working!

Here is the SJASM version of the sources of IS-DOS 1.0, it is ugly, because i changed all TAB's to spaces, but i started it and it is working, it seems our original ISDOS.SYS was dumped from the memory, because there are 2 bigger areas and a 2 byte and a 4 byte space which contain data, compiled source contains 00h-s, and filled up after start.

Cool, thanks!

Yes, the only thing that makes sense to me is that source was built on a computer that had used MOVECPM to make a 48KB CP/M system (with 40KB TPA), and leave the top 16KB free for linking programs directly into the Page3 ($C000-$FFFF) region.

The two numbers printed when you assemble START.MAC are the addresses needed for the L80 "/P" options that put IS-DOS into the correct area of memory.

Then the development batch file would just save out the memory (using the numbers printed), and the ISSQUASH program mentioned in START.MAC is then used to process the memory dump and insert the missing checksum data, and the serial# data, into the final IS-DOS.SYS image.

That is kinda cool, and it certainly helps to explain (to me) how the programmers at IS managed to develop the Enterprise ROMs with rather primitive M80/L80 programs that were available back then.

IIRC, there were a number of CP/M add-in boards for the IBM PC back then that would have allowed for this kind of workflow.

I've kept on working (for the moment) with the original source files that Zozo kindly posted earlier, and his build scripts only need a few changes to compile a good version of IS-DOS ...

Change MAKECOM.ASM ...
  defpage 0
  page 0

  output IS-DOS.NEW
 
  org 00f0h
  incbin ISDOS.BIN,008Ch

PEND: equ $
  end   

Change L.BAT ...
DEL OS.REL 2> nul
XCPM LIB80.COM OS=CODES,EXCODES,BOOT0/E 2> nul
REN OS.LIB OS.REL
XCPM L80.COM OS,/P:C9E4,START,VID,CLI,CMD,FNINIT,CLIV,/P:E100,FIX,CLIO,CLIF,REBOOT,FNVAR,FUNC,CPM,CHAR,BUFDEV,VIDEV,END,ISDOS.BIN/N/Y/E <nnnn 2> nul
SJASM4 MAKECOM.ASM


To explain ... the L80 command line is too long if you add in all of the filenames and the "/P" commands, so I used LIB80 to create an OS.REL library from the first three assembled files, so that it can be used to shorten the command line.

This is than complicated because XCPM doesn't seem to support LIB80 renaming the output file from OS.LIB to OS.REL, so I had to specifically add that to the L.BAT file.


When L80 links a file to the top of memory like this, it adds a 128-byte header onto the file to move the data into place when the .COM file is run, so I had to modify MAKECOM.ASM to strip off the extra bytes from the front of the file.


When that is all built, you basically get a file called "IS-DOS.NEW" that is almost-identical to the shipped version of IS-DOS.SYS.

There are a few differences, but the only one that actually matters is that the "Duplicate Definition" of "ORM" that L80 reports is something that MUST be fixed.

Attached is a file showing the differences between IS-DOS.SYS and ISDOS.NEW, where they come from, and why they are expected and don't matter.

Anyway, the point of this is to confirm that the original source files from 1985 really do correspond to the shipped version of IS-DOS that we all know and love.

the L80 command line is too long if you add in all of the filenames and the "/P" commands

The .REL files do not have to have the same base name as the source files, and back in the day (and still for EXDOS 3) we would assemble the sensibly-named .MAC source files to a less-sensibly-named two letter .REL file, for example START.MAC would assemble to ST.REL, REBOOT.MAC would assemble to RE.REL etc to shorten the L80 command line length!

XCPM doesn't seem to support LIB80 renaming the output file from OS.LIB to OS.REL.

I am not surprised, XCPM is very hacked together by lgb and he did warn us that not all functions are supported!

Anyway, the point of this is to confirm that the original source files from 1985 really do correspond to the shipped version of IS-DOS that we all know and love.

This is very good news!

So... M80 or SJASM?

Good work both, choice is good!