[CCTECH] any ISIS info out there?

From: Dave Mabry <dmabry_at_mich.com>
Date: Mon Jun 24 17:49:23 2002

Ok, I'll give this the first shot. Anyone else familiar with ISIS feel
free to chime in.

Derek Peschel wrote:
>
> > I used ISIS-II extensively in its heyday. Today I have a few Intel MDS
> > (Microcomputer Development Systems) that run ISIS-II along with the
> > ICE80 (In-Circuit Emulator...quite a bit more powerful than a
> > simulator), UPM, PL/M-80, and all the other development
>
> Does ICE80 interface with a real ICE, then? I thought it might have been
> marketing-speak similar to SoftICE.

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
from RAM in the MDS that was "mapped" to the target.
>
> > BTW, I'm not sure why you say that diskette formatting was more
> > complicated. ISIS-II used a different file structure than CP/M, but it
> > wasn't all that much more complicated, as I recall. The formats for
>
> I was talking about the procedure to format disks, not the design of
> the disk format. You can't format a nonsystem disk and then turn it
> into a system disk later. The procedure for a one-drive system is
> especially complicated.
>
> BTW I like the idea of the "magic files" (ISIS.DIR and its relatives)
> but I don't see why they have a special "format" attribute in the directory.
> Doesn't the kernel recognize them by name already?

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.

>
> > files was more structured with object module files having identifiers
> > embedded in them rather than just being a stream of binary that was
> > assumed to be loaded at 100H and contiguous from there. You see, Intel
>
> That relates to one of the flaws in CP/M that I mentioned. DRI assumed
> you would be doing your own assembly and would know your own memory size,
> so there's no portable way (that I know of) to find the locations of the
> CCP, BIOS, and BDOS.
>
> With the MDS you can find the size of the first contiguous block of RAM.
> Unfortunately (I didn't realize this until I read the user guide) the
> _starting_ address of your program could vary if the number of buffers
> is different, so finding the end of free memory isn't as useful as it
> could be. I suppose you could reLOCATE your program though.
>
> The other flaw in CP/M is that the "change disk" and "reboot" functions
> are inseparable. ISIS doesn't need to be told when a disk changes but
> it does seem to have the same reliance on rebooting.

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.

>
> > the MDS's and all their programming tools. If you have some specific
> > questions, maybe I can help. Also, you have a wealth of other sources
> > here in Tony Duell and Joe Rigdon, and others I'm sure.
>
> OK, you asked for it...
>
> Do you know how much ISIS was tied to the IBM 3740 disk geometry?

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.

>
> What exactly is the purpose of all that switch-flipping at boot time?

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.

>
> Did anyone ever replace the text editor with a CRT-oriented one?

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.

>
> Did Intel publish the source code to any part of the system?

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.

>
> -- Derek

Whew, that wasn't so bad. Next?

-- 
Dave Mabry             dmabry_at_mich.com
Dossin Museum Underwater Research Team
NACD #2093
Received on Mon Jun 24 2002 - 17:49:23 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:35:07 BST