IRIS Date / Time

This page is a part of the "Understanding IRIS" collection.  Many thanks to David Takle, for figuring this out, and sharing this with us:

------------------------------------------------

AUG 19, 1986  11:58:33 is the date that the IRIS OS gives when booted.

Where do you think that date might have come from?  

I'm wondering if it was the time that the original machine had as its current time from when this backup was made.  The date is close to what I would have expected.

------------------------------------------------

That date would most likely be the backup date.
During shutdown, the system date is stored somewhere, probably in CONFIG, and picked up again during SIR (System Initialization Routine).

An interesting thing about IRIS dates .... The system has a base data somewhere, and then an hour counter from midnight on that date. Turns out the 65535 hours is about 7 and one half years, and then something needs to happen. In the original IRIS 4 that I worked with, we got a TRAP, and the date reset 7 years, or something like that. Maybe they fixed it later. But there is still a single 16-bit word holding hours since a base date. Not quite sure where we are right now.

You may have noticed that the clock is also FROZEN. The time never changes.
That's because we don't have any RTC -- real time clock -- running. There is one on LU0, but I have not tested it.
Incidentally, the frozen clock might be why we have not seen any Pico-N crashes! It might be waiting for some random number of minutes before doing its thing, and the time never comes.


~David

This page is a part of the "Understanding IRIS" collection.  

SimH IRIS "v2" with fewer crashes

This page is a part of the "Understanding IRIS" collection.  Many thanks to David Takle, for figuring this out, and sharing this with us:

NOTE:  See also this page, which contains the foundational resources and our "first-attempt" parameters and sources that we used before making the below discovery.  

------------------------------------------------------------------

Found the crash problem !! 

The crashes I have been experiencing, so far do NOT seem to be related to Pico-N issues.
What happened is that I inadvertently set the wrong status for the CPU in the startup fie.

What I had in there was:
SET CPU 64K

You would think that might work, and there is no real clue in the docs that it won't, but apparently only in some limited fashion. Words above 077777 octal were not addressable, and simply dropped the top bit in addressing.  So while IRIS thought my partition was at 160000, when it tried to copy my Swap-File header into the partition, it landed at 60000, which wiped out a big chunk of the $DEC driver.
Which meant that any application requiring $DEC, such as LIBR or QUERY to display decimal numbers would crash when it got to that part of the driver.

The correct setup is

SET CPU EXT64KW

It's a lot more fun now!

Here's the updated nova-iris.simh (renamed nova-iris.v2.simh)  You may need to right-click and save as.

How To Use DSP

This page is a part of the "Understanding IRIS" collection.  Many thanks to David Takle, for figuring this out, and sharing this with us:

------------------------------------------------------------------

More good news.

See attached configuration guide, on how to use DSP. 
This was the single most powerful tool on IRIS for system's work.

Looks like DSP works quite well without crashing.
The trick is getting into it, because you have to type
DSP <control-E>X
followed by return.

Problem is that the simulator uses control-E to interrupt the Nova and go back to the simH console.
So add the following line to your nova-iris.simh
SET CONSOLE WRU=6

That will change the simH interrupt from Control-E to Control-F, so you can use DSP.

Be aware that the system runs way too fast to see the display go by when you use some commands like "D" (dump) or "L" (list).
Two ways to deal with this.
1. Start earlier than what you want, and then use Control-S / Control-Q to stop and start the display at will.
2. Log all your console I/O to a file. You can do this with "SET CONSOLE LOG=<filename>" either directly in the simH console or as a standard measure in the .simh file. I have not tried this yet, but it might be possible to have the file open in Notebook++ or something like that to see what's going on.

SimH Boot-able IRIS !!

This page is a part of the "Understanding IRIS" collection.  Many thanks to David Takle, for figuring this out, and sharing this with us:

NOTE:  See also SimH IRIS "v2" with fewer crashes, which contains a much better running setup.  We will keep this page here, however, because it contains foundational information and our original process on how we got to the next step.  Resources on this page will still be needed to try this yourself.

------------------------------------------------------------------

You would not believe all the undocumented weird stuff I ran into today. 
But I tracked down enough bugs to have some fun.

We can now BOOT the r7.5 IRIS on a Diablo 31 drive.
It seems quite buggy, and will crash without much warning. But at least it comes up and acts like a system.

Please see the attached files.

iris75.dkp --- this is the working Diablo LU0
nova-iris.simh --- this is like a .bat file for the simulator. It contains recommended commands in plain text.
nova.exe --- I assume you have one of these.

To bring up the system:
1. run nova.exe to get the simulator running.
2. at the prompt type "do nova-iris.simh" to run the simulator commands

It should boot, go past the date and time prompt, and leave the cursor hanging.
If you remember, you need to hit 'ESC' to get the ACCOUNT prompt.
Enter "MANAGER" IN CAPS for the account, and you should get a "# system prompt.
You probably need to type "CTL-P" to disable the parity checking.

After that you can play around until it crashes.
To continue after that, just reboot and start again.
BOOT DKP

Have fun!
~David


p.s. So far I have not seen any evidence of Pico-N problems.

StarCalc, James Flavin and Chuck Harriger

We found James' name listed as a program author in some of our recovered system LU files:

All rights reserved..V 
Copyright C 1982, Star Computer Group, Inc..V 
This document may not be reproduced without the.V 
prior written permission of Star Computer Group, Inc..V -.V 

STARCALC:VERSION 1,RELEASE 1,PATCH 0,AUGUST 10, 1982..V -.V.V 

STARCALC.06.V.V 

JAMES FLAVIN..V.V 

CALC MODE EXIT..V -.Y.s|..wq.s3wq.s.wq.s|...wq.s.wb.Y.s|.Ewq.s  


We also see the name CHUCK HARRIGER, whom we have recently contacted on LinkedIn.

All rights reserved..V 
Copyright C 1982, Star Computer Group, Inc..V 
This document may not be reproduced without the.V 
prior written permission of Star Computer Group, Inc..V -.V -.V 

MENU..V 
11/19/82..V 
CHUCK HARRIGER..V.V 

MENU SELECTOR.V.V -.Y.s| wbY.s|..wbPAXm.{ y.b\}.}pbV -.V CLOSE ALL CHANNELS..L_.cV.S.m.d.b.F..bT.b.L_.cIi.bV -.V SET ACCOUNTS..W.s.wm}..v..b 

STAR TECHNOLOGIES, INC..W.s.wm.bW.s.wm.bW.s.wm.bW.s.wm.bV.V.V.V.V.W.s|..wm.bV -.V SET PROGRAMS..W.sAr.vwmi1/STARWRTR.DEMO.b.W.sAr.vwmi.bW.sAr.vwmi.b

We've been in contact with James, and here is what he has to say:

Rebuilding Boot Sector Zero with the Diablo 31 Driver (DEV.33)

This page is a part of the "Understanding IRIS" collection.  Many thanks to David Takle, for figuring this out, and sharing this with us:

------------------------------------------------------------------

A lot has been happening.

1.  I managed to rebuild boot sector zero with the Diablo 31 driver (dev.33). Took about 3 hours to get it right, and that was after I tracked down all the relevant info and figured out what I needed to do.

2. I overwrote the REX driver with the good Diablo 31 driver. Only about an hour for that one.

That brought me to the point of testing the Boot.

3. When I boot this modified LU0, it actually prints "Please Wait ..." and then provides a TRAP #5 and dies.

That's great progress !!

The Point 4 PICO-N Device

In this 2006 thread on the newsgroup alt.folklore.computers, the "Arargh.com" contributor tells us about the "PICO":

"Also, in order for it to run, there is a
license device, called a 'PICO', that has to be fastened to the
backplane.  And they are version specific.  The same kind of thing as
used on the parallel port for software protection for PC's."  (Click here for this exact post)

Also, The MTCopy User Manual Rev 2a also mentions the PICO-N on the top of page 18 (PDF page 28).

"A software protection device, commonly called a PICO-N, is
used to protect against unauthorized duplication or use of DTR
BUSINESS SYSTEMS' software. This device is designed to fit on
the backplane of a POINT 4 or compatible CPU chassis. The device
will have one or more Chips on the board, which will indicate
which DTR BUSINESS SYSTEMS software packages are authorized with
this device."

Help from one of the original IRIS Designers, Dan Paymar

This page is a part of the "Understanding IRIS" collection:

We had the privilege of meeting Dan Paymar in person last October, and we had a very nice discussion about his history and memories with Point 4, and computers of his interest prior to this.  Dan wrote the entire BASIC interpreter for IRIS, and wrote most of the time-sharing systems for IRIS.

We just contacted Dan to allow him the opportunity to see our progress here, and give us any comments on the documentation we've compiled on these pages so far.  Here was his response.  On this page, Dan's words will be in italics:

---------------------------------------------------------------------

One of the things [David] mentions is block zero. It was indeed the boot up block, but it was called BZUP (Block Zero Utility Program). It was a simple debugging program that could be used in an emergency if the system wouldn't boot. I think the commands were similar to one on the PDP-8.

If you're using one of the later versions of IRIS then BASIC won't run on a non-Point 4 computer because it depends on the floating point decimal arithmetic routines that were micro coded into the computer.

Dan

Modifying the 'C' in SimH to run a Point 4

This page is a part of the "Understanding IRIS" collection.  Many thanks to David Takle, for figuring this out, and sharing this with us:

------------------------------------------------------------------

If you know how to read the 'c' language, it could help move us forward. I can barely make sense of it myself.

I am attaching one of the texts that was used to compile the NOVA adaptation for SimH. It's purpose is to convert Nova Assembler commands into something that SimH can recognize as DKP commands. (hope that makes sense).

The Nova instructions can potentially include the following I/O commands

DOA, DIA, DOB, DIB, DOC, DIC 

as well as 3 possible control lines ( P for pulse, C for clear, S for start ).
If you remember, the control lines can be set with any of the I/O commands or with NIO. So possible combinations might be

NIOC / DOCS / DOBP and so on.

Documenting the connection between Nova assembly and the requirements of SimH DKP drives could help us write the new drivers.

For example, I think the DOB command is what is used to set the memory address for the block transfer. So our new driver has to use that I/O command to tell SimH where in memory we want to read or write a block of data.

The goal is to figure out how to communicate with SimH using Nova commands. Let me know if you figure out any of the attached c program.

LU0 "Work"

This page is a part of the "Understanding IRIS" collection.  Many thanks to David Takle, for figuring this out, and sharing this with us:

------------------------------------------------------------------

Just wanted to update you on how far I've gotten.

1. I stripped off the utility from the front of a .bin that contained LU0 (can't remember which file that was right now). Creating a file I called LU0x.bin, which was a pure LU0 in SimH DKP format.

2. when I tried to attach LU0x.bin to SimH, it turned out to have the wrong byte order (endian problem).

3. So I converted LU0x.bin to LU0x.dkp (see convert program below) with the correct endian order.

4. I can now attach LU0x.dkp to SimH and BOOT. It reads block zero in, copies it up to 24000 octal, and then hangs trying to read in REX because the disk driver is all wrong.

I've attached LU0x.dkp for your amusement. It's IRIS v. 7.5, based on the PZ and DEFS I've taken from it.

If we can rewrite the disk drivers, we will have a running system!

PZ and DEFS, and loading REX into memory

This page is a part of the "Understanding IRIS" collection.  Many thanks to David Takle, for figuring this out, and sharing this with us:

"I'm fairly certain at this point we can isolate an LU0, and create a pseudo disk drive out of it as it. Because SimH Nova disk drives are just continuous blocks of data 512 bytes each, no formatting ( at least I think so at this point ).

The problem is that SimH Nova only recognizes one approach to writing a disk driver, and only one device code = 33.

There's a chance I could reverse engineer the requirements for writing a SimH compatible disk driver, at least the read portion, which I could then fat finger into the boot sector. That would get REX (Real Time Executive) loaded into memory during the boot process, but that would be the end of it. because writing a disk driver for REX is a lot harder and has strict rules for which I can no longer find any documentation.

We need two critical text files, PZ and DEFS which normally reside on LU0.  Without them it will be almost impossible to write a system level driver.

I found PZ and DEFS on LU0.

These are very important for reverse engineering any part of IRIS."

Converting our QIC-extracted files to SimH Tape Format: Minicom Utility

This page is a part of the "Understanding IRIS" collection.  Many thanks to David Takle, for figuring this out, and sharing this with us:

-----------------------------------------------------------

A few days ago I found the reason why you are getting "invalid magtape record length, PC: 00377 (JMP 377)".
I succeeded in getting file01.bin to load into simH.
The trick is in the format of the binary file.

SimH requires actual tape image in the bin file. That means each "record" has to have a header and sometimes a trailer, depending on which format tape you use.  The default is SIMH format. But the .bin files you extracted are just the data from the tape, not a tape image with its extra stuff.

In SimH you can change formats using "SET MTA0 FORMAT=<format>" where <format> is one of several options. See SIMH docs.

So I wrote a PHP script that read the file01.bin file, created a SIMH format header and trailer (Little Endian format), and wrote a new file "file01.mta". I think I also had to convert the binary from big endian to little endian in the process.

When I did the attach command "ATT MTA0 file01.mta" and "BOOT MTA" it loaded and bootstrapped itself to higher memory.

IRIS Disassembly

This page is a part of the "Understanding IRIS" collection.  Many thanks to David Takle, for figuring this out, and sharing this with us:

-----------------------------------------------------------

I got a bit curious about the QIC tapes that you have managed to read. Not sure what you have deciphered about what is on them, so I wrote a little script to translate the binary into something that looks like a DSP listing.

[DART Utility Disassembly]

file01

file02

Attached you will see 'file01' and 'file02' which correspond to the first 2 files in the zip file you had on line which contained 24 files.  Based on what I'm seeing there, it looks like that tape was primarily for diagnostics. 'file01' is like a boot program that reads in 'file02' which acts more like a menu system to the rest of the tape. If you scan down file02 you will see ASCII that gives the names of the various utilities on the tape.

[IRIS Disk Image Disassembly]

file-iris

I also translated the first 256 blocks on the big IRIS tape I found on your site. It appears to be a mirror image of an IRIS disk, block by block. 

Great help from an "old IRIS programmer"

This page is a part of the "Understanding IRIS" collection.  

David Takle wrote an old [SimH] group message that caught my attention, so I reached out to him, and he responded.

[Simh] help with binaries on NOVA 

NOVA emulation --- I have RDOS running nicely and am trying to get used to
it, reading all the docs I can find (I'm an old IRIS programmer). But I keep
hitting a roadblock. I cannot get any binaries to run, either as a program
under RDOS or as a standalone program that would be booted by the RDOS
"program?" prompt. My guess is that there are some conventions that I am
missing regarding how an assembly program must be structured, and/or some
particular parameters that are required by the Assembler and Relocatable
Binary Loader.

I would greatly appreciate it If anyone can supply a step-by-step plan for
writing a compatible Assembly program along with the correct ASM and RLDR
parameters to create (a) a runnable SAVE program (examp.sv) and (b) and
standalone bootable program.

Thanks!

David

The thread ends with Paco Linux quoting Bruce Ray

So, we reached out to him via email.  We got a fast reply, and what follows are the chronicles of the journey that ensued:

Kennedy Backup Disc Utility - POINT 4 DISK SUBSYSTEM UTILITY..VERSION 1.4

Archive (brand) 8000 BPI Data Cartridge MODEL 09C (which appears to be a rebranded "Scotch" brand of the day), is hand-written "KENNEDY BACKUP DISC UTILITY  9/29/82"

Once we baked it & replaced the band, The tape is clearly in Kennedy 6450 format.  However, the first VERY strange thing about it is that it doesn't have a preamble!  So, we had to do some really fancy footwork to extract what we have of it.  However, it would be difficult (more so than what we've done so far) to reliably use the CRC to correct it, because we have NO idea how long the data block is supposed to be.  This data block is LONGER than we've ever seen before.  Previously, we've seen 4096 & 8192 byte blocks.  This one is AT LEAST 13,488 bytes (which is an odd length?), possibly more.  Since the preamble is missing, who really knows what or how much goes in front of what we have been able to restore.