Hi Derek, ISIS is a VERY primitive system IMO. It only has six commands total (IIRC) and the file systems is truely STRANGE. I've been wondering about the system calls too. My manuals mention them but don't provide ANY details and I have a pretty complete set of manuals. What system are you running it on? I currently have a 800, an 880 and 235 plus another 235 that I'm storing for someone else. BTW I finally picked up a hard drive for mine after 7 or 8 years of searching. :-) Joe At 03:41 AM 6/24/02 -0700, you wrote: _______________________________________________ cctech mailing list cctech(a)classiccmp.org http://www.classiccmp.org/mailman/listinfo/cctech

Ok, I'll give this the first shot. Anyone else familiar with ISIS feel free to chime in. Derek Peschel wrote: ICE80 is the software that uses a two-board set of Multibus boards. The boards were hosted in the MDS and the software then controlled program execution on them. There was an umbilico that went to the target system and replaced the 8080 chip. From that point you could execute the target code, either from memory that resided on the target system or The IDISK command (ISIS's version of format) would physically format the diskettes and then write the appropriate system files. If the diskette was to be bootable then more was written for that purpose. True that you can't change a non-bootable to a bootable diskette without re-IDISKing. On the other hand, though, there was no unused space on a non-bootable diskette like there was in CP/M. The non-bootable diskette in CP/M just had empty space where the boot code went. You could remove the "F"ormat attribute from the ISIS.* files and the system would not have any problems. I don't remember exactly why it was there, other than it served as a read-only function. As I recall, and this is fuzzy for me, the starting address for ISIS programs was generally the same on all systems, but it was ABOVE the operating system which loaded in low memory. There was a default for the number of file buffers that was assumed by the LOCATE program unless overridden. You could then use anything above your starting address up to the limit of physical RAM. Now since these machines were relatively expensive, most of them had the full complement of 64k. You are correct in that you didn't have to tell the OS when you changed diskettes. This was done automatically by ISIS by reading one of the ISIS.* files. ISIS.BIN I think. That was a bitmap of the free sectors on the disk. Not at all, since Intel supplied as an option a double density controller board set that was not compatible with the 3740 disk geometry. But you would have had to take ISIS apart to find the disk I/O routines. Intel never published that information and I have only heard of one other person (he's on this list I believe) who put ISIS onto non-Intel development system hardware. I'm assuming you mean on the MDS-800 family of development systems. It switched in and out of memory map a rom that controlled bootstrapping code. On later system models (the Series II and on) that was handled automatically. Intel supplied an editor as a separate product called CREDIT (CRt EDIT). It was screen oriented and was a vast improvement over the TECO editor that was standard on ISIS. However I knew a few who liked the TECO editor enough that they preferred it over CREDIT. Later Intel offered one called ALTER. It was _much_ nicer. Due to a copyright dispute Intel had to change the name of that editor to AEDIT. They also released a 16-bit version for the Series-III and later systems. AEDIT-86 was written to use a UDI (Universal Development Interface) to hook to the operating system. In that way Intel could release AEDIT to work with any system as long as there was a UDI for that system. Their RMX-86 operating system could use AEDIT and Intel also wrote a UDI for MS-DOS. I use AEDIT today on my PC for simple text editing. It is a very easy to use and powerful text editor and is about 32k in size. Not that I know of. There are those who have taken the system apart. I have a good article from Dr. Dobbs that documents a lot of the innards. If you like I can e-mail a scan of it to you. Whew, that wasn't so bad. Next? -- Dave Mabry dmabry(a)mich.com Dossin Museum Underwater Research Team NACD #2093

On Mon, Jun 24, 2002 at 08:11:43PM +0000, Joe wrote: ISIS takes up 12K not including the CLI. I read that the first versions of CP/M took up 8K (which I guess would include the CCP). Later versions reduced that by bank-switching the BIOS. ISIS also requires extra buffers for various reasons (line-edited files vs. not, disk files vs. not, files used by system calls). Each buffer is 128 bytes. I remember CP/M FCBs as being smaller but I could be wrong. Admittedly ISIS machines have at least 32K, maybe 64K, so a 32K ISIS system would have more free memory (20K or so) than a 16K CP/M system (8K or so). -- Derek