Saturday, October 8, 2016

Locating a section within a disk raw dump

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

OK. That was sort of interesting and fun.

Here's the process I went through to track it down. 

1. The decimal displacement [off  the area targeted] is 8808512. That's a byte displacement into the DRIVE. 

2. Convert that to a word displacement == 4404256

3. Divide by 256 to == 17204 block displacement into the drive (drop fraction)

4. Convert to octal == Sector 41464 (8) in the drive
The question is, where is that sector relative to the logical units.

5. Examine CONFIG to see how the drive is broken up (there can be multiple LU's)
See for info on deciphering CONFIG table.

# DSP 
D1400 (and immediate escape to stop the listing) 
( we get this )

1400:    77037   51424   51303       5   77000       0       0      24
1410:        0       0      30       0    7741       0       0     124
1420:        0      24      30       0   76576       0       0     140
1430:        0     150      30       0   76563       0       0     140
1440:    40000       0      30       0   76550       0       0     110
1450:    40000     140      30       0  177777   77377   77377   77377 

That tells me LU0 is 24 (8) cylinders. LU1 begins on Cyl 24 (8) and has 124 (8) cylinders. 

6. Review the characteristics of a Century 114 Drive. There are 14 (8) sectors per track, 24 (8) tracks per cylinder, 360 (8) sectors per cylinder. 

7. How many sectors are in LU 0 ? == 360 (8)  blocks per cyl times  24 (8)  cylinders ==> 11300 (8) sectors on LU0. 

8. Since our target block is 41464, it cannot be in LU0. Subtracting 41464 - 11300  gives us  30164 blocks beyond LU 0. 

9. How many sectors are in LU 1 ? == 360 blocks per cyl times 124 cylinders === > 47300. Since 47300 > 30164, our target block is RDA 30164 on LU 1. 

10. INSTALL 0.1 to get access to LU1 

11. If our block is in a continuous file, that would be the easiest to locate, so let's try:
 # LIBR 1/@ *C 
to display all continuous files. 
Guess what shows up?

C  ROLODEX         0   $0.00  1001    0, 2  6114   137    32   1  30025

The file begins on 30025 (8) and consists of 1001 (dec) blocks.
That's our file.


If you do the following command it will tell you everything it knows about the file



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

Wednesday, September 28, 2016

IRIS with Device 033 and 027, DKP and DZP

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


On this SimH Migration page, David says 

"Very few drivers existed on IRIS for standard DG controllers using Device 33"

I asked David to expand the thought by stating what Device # most Point 4 IRIS systems had a tendency to use.  was it 027?

I remember wrestling with this issue before I met David

The first I ever heard of it was when Bruce Ray analyzed the first file I ever pulled off of these tapes, which I quote in Minicom Disk To Tape Utility tells a story...

"The utility assumes two devices exist: a tape controller using device code <022> and a disk controller using device code <027>. The tape controller may or may not perform QIC to DG-style file handling emulation since the original tape is not available to me.

The disk controller appears to use the standard DG "Zebra" controller (Model 6060/6061/6067) programming model. However, it assumes a non-standard disk geometry of 16 cylinders, 5 heads, and 32 sectors."

Device 027 wasn't an option in SimH, nor was it in the Bruce Ray's reNOVAte Demo Version 4.0B.06, only in his later, full-function versions, which I never accessed.

By then I was facing the whole DKP vs DZP thing, with device # issues when I was wrestling with Wild Hare's reNOVAte Demo Version 4.0B.06


In answer to the dev. 33 question, it seemed that most IRIS users opted for 3rd party controllers. My guess is that cost was a major factor. Controllers in those days were incredibly expensive, and DG probably charged more than they needed to, which made a market for other engineers to step in and offer their stuff for less.

For whatever reason, they seemed to gravitate more to device 27. So EDS / Point4 either wrote the drivers or got them from the controller manufacturers and distributed them freely in the CONFIG file.

Monday, September 26, 2016

Running SimH (Point 4 IRIS) on different Apple MAC Versions

Received from one of the gurus at SimH:


1)      Install the Max OS X compiler environment (XCode) from the App Store

2)      Start a terminal window

3)      Download and unzip the source (or use git to directly clone the repo)

4)      Build  a the nova or other simulator:

                   $ make nova
The source can be found here:

Use the green button on the right that says 'clone or download' to get the source.
It contains the make file and everything, so the above process should work.
If you have trouble, I would email Mark at: 

Mark Pizzolato <>

Hope that helps.


The above instructions assumes you know how to start Terminal, and cd your way to the directory of the SimH files, which are in the simh-master folder, and then run the $ make nova

BUT, what if you're running an older version of Mac OS, like 10.6 or 10.5.8?  The most current XCode won't install, or run the right "make" command.

Sunday, September 25, 2016

The Point 4/System House Partnership - Mini-Micro Systems Ad

This ad is from the November 1980 issue of Mini-Micro Systems.  It is the only Point 4 advertisement that I've ever seen:

Monday, September 19, 2016

"Sanitizing" a Point 4 IRIS system

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


One solution is to boot up your configuration and then do the following:


Each time you will be asked if you really want to clear the LU (Y/N).
And then it will ask what you want the new LU# to be. Just enter the same LU# (1,2,3,4).
This command creates an empty LU, with a new INDEX and ACCOUNTS file. 

However, this usually limits MANAGER to a couple thousand blocks on the extra LU's.
You can use the UTILITY program to modify the account settings on each LU.
You might even want to delete extra accounts from LU0.
Unfortunately, the UTILITY program is not very intuitive. If you need help figuring it out let me know.

Also, if you are still concerned that some one might know how to recover the data sitting on the drive, you can write a program to wipe it out.
For example (once MANAGER has enough blocks allocated to it)

Tuesday, July 5, 2016

VT-100 with SimH. Hope for Starwriter?

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


See the most updated version of this topic at:


I finally figured out how to connect the telnet session to the nova.exe,
setup the VT100 emulation, and all the cursor addressing, etc, is working great.

However ..... Starwriter seems to have its own ideas about this, and probably has some debug info displaying as well, so it seems impossible to make it work right.
I gave up on it and poked around in the DOC.00000 files long enough to figure out how they are formatting their text there (ok, I have about 80% of if figured out).
Looks like they gave the user the ability to set different text characteristics, like underline, bold, dim, etc.
By stripping all that out, I can glean the basic text and display most of what was intended.

Also noticed that the document numbers are unique by LU. So both LU1 and LU2 can have a DOC.00012.

I have attached an updated Drive 0 for the CC system, which contains some new stuff on LU0.
You should replace your existing Drive 0 with this one.
If you have added any new files to your LU0 or LU1 you should copy them to LU4 before swapping drives so you can recover them later.

Added a new driver to LU0.
$LPT.SIM allows you to export data from the nova emulator to Windows. The steps are:

1. escape to sim> and ATTACH LPT <newfilename>
2. resume nova ( CONT )
3. run a BASIC program that prints to a printer
    i.e.  10 OPEN #0,"$LPT.SIM"
           20 PRINT #0; "My name is Bob"
          30 CLOSE #0
4. escape to sim> and DETACH LPT

The 'newfilename' now contains the printer output and is treated like any Windows text file.
Always DETACH the file before trying to use it in Windows.

Attached are two text files as well.
DOC.LISTING is a complete list of all DOC files on LU's 1-2-3.
It was created by a new program 0/ DOC.LIST

DOCS is a sample of 3 documents, created by new program 0/ DOC.READ

DOC.READ allows you to display documents on the screen or print them to $LPT.SIM

You will be prompted for an LU and then a DOC #.
For the doc, only enter the 5 digits.
The program will open the file, display the doc, and ask you if you want to print it.
If you just hit <return> at DOC., it will go back and ask for LU again.

You can print multiple docs to the printer file before you DETACH it.


What Chuck Harriger recently said on Star*Writer now seems relevant:

"Part of the magic of Star*Writer and Star*Calc was the dumb terminals that we added a circuit board to which added 2 pages (screens ) and native word processing capabilities. Recreating the software does not give you Star*Writer or Star*Calc since the program acted as a server to the word processing terminal."


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

Sunday, June 12, 2016

Converting LU Disc Drivers for SimH Nova

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


Turns out that I now that with a few minor changes, we can create an IRIS driver for any of the disk drives supported by simH.
So whenever it is possible to match up the driver being used by IRIS with a supporting drive that uses the same number of sectors per track and has at least as many tracks per cylinder, that means we can migrate the system without moving or expanding DMAP, which is the biggest problem in the whole thing.

Turns out that the 6103 drive is a perfect replacement for the IRIS on your CC tapes.
It could be configured with 16 sectors per track, and 16 tracks per cylinder.

By overlaying the driver in IRIS in the REX file and in the boot sector, it ought to be possible to boot without hardly any other IRIS modifications.
And given that we already have a running IRIS system with which to manipulate another drive, it might not be too strenuous at all.

How the Point 4 IRIS Boots

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


The following is a conversation between Tom & his colleague Alan, who used to work with Point 4 IRIS systems.


Since you actually used to look at and handle Point-4 computers, here is

a question for you.

How do they boot up?  I mean if you shove a tape in, how do you make it

boot from tape?
What insights do you have about how this 256 word loader would get loaded?
Why does the first bit of real code seem to be at address 0x50, does
that ring any
bells with you?

I would expect this thing to get loaded into address zero and the PC get

set to 0 to run,
but if execution started at address 0, it would run a bunch of docp
instructions, then
at address 0x40 hit a jump back to zero, hence running some endless
unwrapped loop
of just docp instructions.   It is odd that the value 0x7eff appears
like padding at the
start and end of this file or block or record or whatever you want to
call it.

The end of the block may have a clue.  It ends with an indirect jump

through 0x00fe
which would take it to the loop I found at address 0x0050.  Is this some
defined Nova
behavior?  Load a 256 word block and then set the PC to run the
instruction in the
last word?  In that case, why would it not just be a jump to 0050 itself?

Examining The Anatomy of a Logical Unit (LU)

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 used an octal file reader, rather than a hex one, since I am more familiar with how IRIS looks in octal formats.

This octal file reader is actually a PHP program I wrote and run on my pc. (I use WAMP for a local server).
( I could not find a good octal program to download)

another approach:
If you have access to a website that you can upload to, you can upload the PHP program and your binary file and use it that way.
They just need to be on the same file system, since PHP runs as a process on the server, not in the browser. And nearly every web server supports PHP.

To begin, I examined block 0 of the LU3.bin file.

IRIS User Privelages

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


Whoever designed this application created multiple accounts like ACCOUNTING, APGL (presumably accounts payable and general ledger), and so on.

The problem is they gave them all privilege level 2 on their account status. Which means they can create files that the MANAGER account cannot get access to. They won't even show up on a LIBR listing!
This should never have been the case.
Since no one is allowed to log on to the SYSTEM account (it is reserved for critical files like INDEX, DMAP, REX),
the MANAGER must be the person who maintains the operating system. No one should be able to lock out the manager from examining a file.

Which means the proper IRIS priv system is as follows:

3 = System
2 = Manager
1 = high level user
0 = low level user

Consequently, I will be dropping all user accounts from Priv 2 to Priv 1 and updating all files that were created with priv 2 by those users to reflect the new protection.
That way I can have access to them.


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

Thursday, June 2, 2016

LU Index Dissection

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


using David's Disassembly program, here is the anatomy of an LU Index:

; this is what normal index looks like
; each entry is 010 words long  (here 010 is octal for 8 in decimal)
; words 0-6 are the name ( if shorter, fill with 0's )
; word 7 is the Header block addr

001400: 153256  V.  ADDOR# 2,2,SEZ
001401: 141720  CP  INCZS 2,0
001402: 127264  .4  ADDCR 1,1,SZR
001403: 130267  07  COMCR 1,2,SBN
001404: 130662  12  NEGCR 1,2,SZC
001405:      0  ..  JMP 0
001406:      0  ..  JMP 0
001407:  23250  &(  LDA 0,@-130,2

001410: 152724  UT  SUBZS 2,2,SZR
001411: 127303  .C  ADDS 1,1,SNC
001412: 147715  OM  ANDS# 2,1,SNR
001413: 146400  M.  SUB 2,1
001414:      0  ..  JMP 0
001415:      0  ..  JMP 0
001416:      0  ..  JMP 0
001417:  23272  &:  LDA 0,@-106,2

001420: 153256  V.  ADDOR# 2,2,SEZ
001421: 144322  HR  COMZS 2,1,SZC
001422: 127263  .3  ADDCR 1,1,SNC
001423: 130661  11  NEGCR 1,2,SKP
001424: 130262  02  COMCR 1,2,SZC
001425:      0  ..  JMP 0
001426:      0  ..  JMP 0
001427:  23304  &D  LDA 0,@-74,2

001430:      0  ..  JMP 0
001431: 141720  CP  INCZS 2,0
001432: 127264  .4  ADDCR 1,1,SZR
001433: 130261  01  COMCR 1,2,SKP
001434: 131267  27  MOVCR 1,2,SBN
001435:      0  ..  JMP 0
001436:      0  ..  JMP 0
001437:  15263  .3  DSZ -115,2

                    ^^^^^^^^ ignore this part (just comes with my conv program)
                ^^ ascii equiv
         ^^^^^ octal value
^^^^^^ relative to start of index file

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

Tuesday, May 31, 2016

IRIS Assembly Language (Part 2)

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


Our first page on IRIS Disassembly can be found here.

Please consider this page an additional chapter into the disassembly and deeper study of the Point 4 IRIS assembly language, and various example programs.

To start with, Tom has documented well a high-level of the assembly language of this system, in his web page:

The Data General Nova

I will try to repeat very little of what is here, only to add details as I learn them along the way, and possibly to re-iterate items from Tom's page on this topic, in a different way, which helped me grasp these concepts and details.

Thursday, May 26, 2016

System 1 Disc Architecture & Driver

I have been poking around the C-CC system to try and figure out what drive it was on.
Looks like all the LU's resided on a single 32MB drive that was partitioned into 5 spaces.

See the PDF for a layout of the drive.

The driver is incredibly complex. My guess is that the controller was fairly simple, which required a lot more work to be done by the software driver.

( I remember the first CDC drives we attached --- They found this dirt cheep controller and asked me to write the driver.When reading a block of data, I even had to read the preamble to the sector and verify the drive was in the right place before passing the data on to the system !! )

Anyway, this driver is going to be a bugger to reverse engineer. There are a ton of obscure data instructions which make no sense without documentation. But I have not been able to track down any similar drive layout anywhere on the net, so I don't know what we are dealing with.
So writing C code to support these I/O commands is going to be really tricky.

Sunday, May 22, 2016

Future Dimensions

The original owner of these systems has informed us that they were serviced (and even sold) by a local company called:

(213) 841-9450

Their programmer/service contact was named Bruce, (initials BAM) but we don't have a last name.

There were two guys who ran this Future Dimensions (one of them might have been named Jess), but they were a couple of middle-aged sales types who were latching onto the computer thing as their next play while Bruce was the "nerd."

It is also possible that he later had some connection with Compuware around the same timeframe.

Google is giving me exactly nothing relevant (at least not the way I'm searching it).

Has anyone ever heard of this early 1980s local Burbank servicer or reseller of computers?

Saturday, May 21, 2016


Don't know if you guys have been having the same irritation I have.

IRIS has been ignoring my backspace key. I finally figured out that my keyboard sends a rubout, not a control-H.

It can be fixed by adding the following line to your .sim file


After that, IRIS sees a 010 when I press backspace.



Ah, the joys of the model 33 Teletype that IRIS expects as the master terminal.

Which is also why DSP lists the lines so fast. It thinks the output speed is 10 CPS.

Of course you might find an old Teletype somewhere....  ;-}