https://drive.google.com/drive/folders/1epSVN8QK_dSuGPwj4cP4gmWRlHbecZlq?usp=sharing
Hunting for Microtech DART-family & M1 Series Desktop Computer Systems, including the M1/10, M1/34, and M1/68. These were built between 1981-1983, by Microtech Business Systems in Costa Mesa, CA.
Sunday, April 5, 2020
Tuesday, December 11, 2018
MARK 3-CPU, Point 4 Data corporation, rare vintage motherboard, year 1981
So, we just bought this. Now, how to do something with it without the rest of the chassis or machine...this will be interesting.
..."pulled from a working Compaq server years ago" Really? How does that work? Hopefully that is a misprint in this auction. I can't imagine how that would work.
MARK 3-CPU, Point 4 Data corporation, rare vintage motherboard, year 1981
-for collection, TOP condition
-used, untested, but pulled from a working Compaq server years ago
So, I messaged the seller, and he has confirmed:
Hi Sir,
I
am sorry it is wrong description, it was dismounted from terminal from
an research lab many years ago...these were working ago....and when they
decided to cancel and demolish these building I have saved some stuff.
I will keep all of you posted here.
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 http://nova-iris.net/architecture/config-structure/ for info on deciphering CONFIG table.
# DSP
FCONFIG
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
# QUERY ROLODEX
------------------------------------------------------------------
This page is a part of the "Understanding IRIS" collection.
------------------------------------------------------------------
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 http://nova-iris.net/architecture/config-structure/ for info on deciphering CONFIG table.
# DSP
FCONFIG
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
# QUERY ROLODEX
------------------------------------------------------------------
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.
------------------------------------------------------------------
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:
https://github.com/simh/simh
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 <Mark@infocomm.com>
Hope that helps.
-----------------------------------------------------
------------------------------
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:
https://github.com/simh/simh
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 <Mark@infocomm.com>
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:
# INSTALL AND CLEAR 0.1
# INSTALL AND CLEAR 0.2
# INSTALL AND CLEAR 0.3
# INSTALL AND CLEAR 0.4
# INSTALL AND CLEAR 0.1
# INSTALL AND CLEAR 0.2
# INSTALL AND CLEAR 0.3
# INSTALL AND CLEAR 0.4
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:
http://nova-iris.net/simh-simulator/running-vt100/
------------------------------------------------------------------
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.
------------------------------------------------------------------
See the most updated version of this topic at:
http://nova-iris.net/simh-simulator/running-vt100/
------------------------------------------------------------------
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.
-----------------------------------------------------------
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.
Tom:
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?
------------------------------------------------------------------
The following is a conversation between Tom & his colleague Alan, who used to work with Point 4 IRIS systems.
Tom:
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.
------------------------------------------------
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.
-------------------------------------------------------
-------------------------------------------------------
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.
-------------------------------------------------------
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
------------------------------------------------
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
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.
------------------------------------------------------------------
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
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.
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.
Subscribe to:
Posts (Atom)