• Please review our updated Terms and Rules here

Four-Phase Systems IV/90

I can honestly say that I know absolutely nothing about the IV90.

In the donation with this tape was also a CDC disc pack, (If I remember correctly a 762), and the only label on it said something like "not to be used until checked by philips"

If Philips Data Systems was the European agent for Four Phase Systems, I guess there is a faint possibility that disc pack might contain relevant software.

We have a father&son team in Datamuseum.dk who spent most of 2023 recovering data from 762 disc-packs from a Christian Rovsing CR80 computer:

Danish Wiki (try google translate): https://datamuseum.dk/wiki/Projekter/CDC_9762_CR80_disk_packs

Github Project (in english): https://github.com/Datamuseum-DK/pico-smd-controller

I know there has been talk about a "pico-smd-drive" as well, but I do not know if it is a plan or if it is just talk.

I'll give that discpack a closer look next time I'm in, and if it looks well and sound, I can try to persuade them to read it, but it probably wont happen until some time in autumn, we're all volunteers, so not much activity during summer.
 
There is a tiny amount of information regarding how Four-Phase distributed systems in Europe and Philips was indeed selling units under their name and from the one photo known to exist with a blue theme rather than brown/gold.
Apparently the University of Amsterdam has (had? The main page has not been updated since 2017) a small computer museum. Their catalog lists a Four-Phase system as a Philips X1160. https://ub.fnwi.uva.nl/computermuseum/X1160.html
If you have recently been working on dumping CDC packs I'm interested in the results. At my point I have the interface and the ability to make cabling but the lack of a drive (even if my system was currently functional) really restricts my ability to look at any packs right now. I did a blind grab on a slightly newer SMD over the weekend and discovered the later drives don't really have much backwards compatibility with early SMD controllers and this particular drive I was assured by someone else while pointing at a stack of identical drives that the have a very high failure rate. Emulated drives are absolutely something I have to keep an eye on in the future, both for SMD and the older Diablo interafce.
 
We have sort of resigned ourselves that the CDC drives cannot be kept alive for any amount of time, and are working hard to evacuate all data we can.

For the hardware/realtime aspect of SMD interface, you want to talk to Anders (https://github.com/sqaxomonophonen) who did all that stuff, I've only be involved in decoding the FM data once he got it off the platters.

Philips being the distributor certainly increases the chances that the discpack we received is Four Phase relevant, I'll try to get it read.

I'll also check in with one of our volunteers who used to work for Philips and who have done a great job on the Philips P800 stuff in our collection, he may know something.

And we would love to have a Diablo emulator as well, a Pi Pico and some 5V buffers should do the job.

(...said the software guy: I prefer to simulate hardware in software (as in software simulation of the 5000 TTL chips in this beast: https://datamuseum.dk/wiki/Rational/R1000s400 :)
 
Hi NeXT and bsdphk!

I wrote the code for the RPi Pico SMD controller that phk mentioned. It's currently tailored to read CR80/CR8044 disk packs. This is because the data stream from the drive tends to get corrupted when the head passes over a point on the disk where a write stream originally started. But when we instead signal the drive to start reading at the same point (plus/minus a few microseconds) we can get flawless reads; with one disk pack we managed to dump all sectors (~130k) without even a single checksum error, but without precise timings we could only reach 50-80%.

To dump disk packs written by another controller we'd probably start by doing a dump without precise timings. That should reveal the timing requirements when we analyze the data. Then we'd implement these timings in the code and try again.

That's assuming the disk pack wasn't written using the "ADDRESS MARK" feature of the drive and SMD-0 protocol, in which case we might have to go even further back to the drawing board (it is one of two ways that the protocol can signal a start-of-sector, and the CR8044 controller that wrote our disk packs uses the other one, so we have no support for, or experience with "ADDRESS MARK").

Regarding an SMD emulator, it's not something I've thought about a lot. We've been unable to convince our CR80 to work with our drive (which is also one of the reasons we ended up making our own disk controller), but I'm unaware if this is because the drive is partly broken (we get seek errors for seeking distances larger than 1 cylinder) or if the CR8044 controller is broken. Or even if the CR80 is not properly configured. We should probably figure this out before proceeding with a drive emulator.

With that said, I think the Pi Pico may be just about powerful enough to handle the task. It handles being a controller just fine. I'm assuming there's enough time to stream in new cylinders from the host over USB while "seeking" without the controller getting "impatient" since there's only enough room for 1-2 cylinders in RAM.
 
anderskaare said:
With that said, I think the Pi Pico may be just about powerful enough to handle the task. It handles being a controller just fine. I'm assuming there's enough time to stream in new cylinders from the host over USB while "seeking" without the controller getting "impatient" since there's only enough room for 1-2 cylinders in RAM.
Click to expand...

Wouldn't it be possible to fit some kind of serial flash to the Pico, or have you maxed out the pins already ?
 
Just more casually analyzing that image.

Code: 
]"CTRL-C" WHEN DISC IS READY TO BE BOOTED; HIT "CTRL-A" TO ABORT SOFT BOOT.


 QUEST UNDER MFE   ADVENT UNDER IDOS

MFE = MVE/IV.
Multifunction Executive (MFE/IV) enables multiple FourPhase software packages to operate concurrently and independently on a System IV /60, /65, or /90. These packages include DATA IV, VISION, ForeWord, PWS, and COBOL, making the following distributed processing functions available with a single processor: data entry, word processing, program development, on-line inquiry and retrieval, batch communications, local processing, and report generation. A single station can switch from one function to another easily. MFE/IV supports up to 24 1920-character screens, 270 million bytes of disk storage, and up to 384K bytes of memory.
Click to expand...

IDOS = Interrupt Disk Operating System
IDOS is a disk-oriented operating system oriented toward executing programs which IDOS provides for the cataloging and updating of source, relocatable, absolute files and command run parameter strings (job streams). The latter permits a single entry from the console to initiate sequential operation of a series of programs. The Code Assembler and Relocatable Loader, COBOL with DISAM, the Sort Package, and the System Relocatable Library are among the programs provided with IDOS. Two types of disk files are available under IDOS and DOS: contiguous (chained) and sequential
(linked files).

IDOS Utilities is also provided and includes a sort/merge, symbolic editor, relocatable loader, and various media conversion programs. The symbolic editor allows for insertion, deletion, replacement, and inter-record corrections of
symbolic text. Media conversion programs include card-to tape, tape-to-printer, and memory save/restore on disk or
magnetic tape.
Click to expand...

Remember, this is a tape image, so the disk-ism's and the fact IDOS has media conversion utilities implies (if the 2.4mb image size wasn't enough of an indication) that this is a backup of a disk pack, presumably a Diablo.

Code: 
DTUX UTILITY --09 APR 80
Without a list of known utilities, DTUX appears to be a utility that copies the contents of a disk to tape.
Code: 
FLOPPY DISC HAS NOT YET BEEN IMPLEMENTED
.....and it didn't yet support floppy drives at this point.

Code: 
IS DECK  1  READIED WITH NEXT TAPE? (Y OR N) READY DECK  0  SET SWITCH 0 UP TO RETRY; DOWN TO IGNORE  ENTER MESSAGE TO START
This seems to imply that DTUX identifies tape transports as "decks".
Code: 
DTUX RUN ABORTED BEFORE OUTPUT TAPE WRITTEN TO.
It's also quite verbose.

Code: 
P7458
P8121
P8131
P8135
PACKIN
PAUSE
PAUSEK
PRINT
QHELP
QLHRDS
QLIB
QLIBSV
QUEST
SCREEN
SIMED
SNEDIT
SPOOL
SYSTEM
TPMON
WINDOW
X1452
ADSAVE
HEINO
MFEXXX
HGHSEC
DTUX
EJECT
FMTX
GENCTR
IDOSGN
JOB
KEYBRD
L00
LIST
LISTIO
MFE
MFEBDC
MFEDMP
MFEFIG
MFELIB
MFESYS
NEW
NOPRNT
NPBMPE
NPDTUX
NPFMTX
NPLGI
NPMOVE
NPTBMT
NPTFX1
NPTFX2
NPWRT
OLD
P7415
P7425
P7453
$COMM
$BATCH
$COMMI
$DIR
COMM
A92AMB
A92AMC
A92AMF
ABOOT
ACM
ADCOPY
ADNEW
ADVENT
ADVIRT
ALMCLM
ALMCLX
ALMCLZ
ALMFMD
ALMMP4
APOSTB
ASGDEV
BOJ
COPY
COPY01
CRTDMP
DAMHUS
DATE
DIRDMP
DIRMOD
DIRSRT
DIRVID

Okay this is really interesting. This looks like a a Table of Contents for when the disk was backed up to tape. We can see that MFE and IDOS coexist on the disk as well as what looks to be a number of NP-80 specific commands? Lots of other handy utilities by the sound of it there are generation tools for IDOS and MFE so you can copy your system over to other disks. Later on we also see commands that seem to imply the disk can have a directory structure but none of the files have a name exceeding six characters.

Code: 
MCODE IOL BUG PREVENTS LOAD
Hmm, hardware implemented bugs that the software team knew about...

Code: 
IDOS-AD33   // ASGDEV
SERIES IV INTERRUPT DISC OPERATING SYSTEM         S-AD33   D
0 7175  @0                                      
SYSOUT = NOPRNT   SYSIN  = KYBRD  1 7175  @1                                 
P7000 MOD 30   SINGLE
SCREENS = 16 24 by 81
$RCODE     0   $ACERR     0                                                  
LAST PROGRAM:  FMTX

Code: 
IDOS-AD33   // ASGDEV           SERIES IV INTERRUPT DISC OPERATING SYSTEM         S-AD33   D
FRI. MAR 13,  1981   14:23:31     0 8260  @0
SYSOUT = NOPRNT   SYSIN  = KYBRD
IV/90 MOD II   SINGLE
SCREENS = 16 24 by 81                                                        
$RCODE     0   $ACERR     0
LAST PROGRAM:  SCREEN

This looks to be the system this IDOS build was generated for. Philips P7000, Model 30 which in reality was a Four-Phase IV/90 machine with an NP-80 cabinet and an 8260 Diablo controller. That tracks.

P-7000

The P7000 system installed 32 terminals stand alone online. He had the ability to operate simultaneously with different programs in languages such as DATA V4 , COBOL , EDITOR ... But mostly highlighted its communication capacity, both in interactive mode as batch .
This power coupled with a specific software, MAESTRO, Softlab company allowed its entry into large firms, mainly the banking sector, to download the big computers around the work of writing programs, check them, maintaining versions and achievement of results as you work in real mode. At a lower level, was sold in hotels, bingo halls, and several companies that required storage capacity and processing speed.
- https://myjourneywiththelinuxoperatingsystem.blogspot.com/2012/01/philips-data-systems_7363.html
Click to expand...

I'm going to continue to scroll through the contents of the image but this so far is REALLY exciting! :D

Edited:
Code: 
*** I REFUSE TO DESTROY YOUR DOS PACK ***
Heh.

Code: 
***********************************************************************    
* D*    
* THIS IS A SPECIAL VERSION OF 'IDOSGN' TO BE *    
* USED TO CREATE THE IDOS AREA OF A DIAGNOSTIC PACK
*    
* THIS SHOULD NOT BE USED FOR CUSTOMER APPLICATIONS
*    
* D*    
* THE REASON FOR A SPECIAL VERSION IS THAT A NORMAL
*    
* 8230 PACK CANNOT SUPPORT A TOTAL IDOS SYSTEM *    
* AND THE DIAGNOSTIC SYSTEM AT THE SAME TIME *    
* D*    
***********************************************************************    
// DIRMOD CLEAR THE PROTECT FLAGS FROM THE SYSTEM
/I= $COMM @1, Q. @
 P
/I= $BATCH @1, Q. ?
 P
/I= $DIR @1, Q. A
 P
/I= $COMMI @1, Q. ?
 P
/I= %COMM @1, Q. @
// N
* O
* CLEAR THE OLD FILES OFF THE TARGET PACK "
* O
///  ¸ð GENCTR G
/O= TEMPXX, E= $$$, D= !I(D. 4
// DIRMOD G
/I = \ @ 1, O = TEMP @ 1. 7
 P
// N
$$$ M
// TEMPXX G
* O
* PUT A NEW BOOT AND DIRECTORY ON TARGET PACK
* O
// PACKIN G
/I=@0,O=@1. E
// N
* O
* RECLAIM SPACE <
* O
// JOB J
// N
* O
// BOJ J
/D=1. K
// N
* O
* COPY THE NEW FILES TO THE TARGET PACK $
* O
// GENCTR G
/O= TEMPYY, E= $$$, D= !I(D. 4
// COPY I
/I = \ , O = @ 1. ?
 P
// N
$$$ M
// TEMPYY G
* O
* PUT A DIAGNOSTIC COMM REGION ON TARGET DISC
* O
// DIRMOD G
/I= $COMM @ 1, Q. ?
 P
/I= $COMM @ 1, O= TEMP@1. 7
// N
// JOB J
/D=1. K
// N
// COPY I
/I= %COMM, O= $COMM @ 1. 8
// N
* O
* PROTECT THE SYSTEM (MAY NOT NEED TO BUT DO IT ANYWAY)
* O
// DIRMOD G
/I= $COMM @ 1, P. ?
 P

/I= $BATCH @ 1, P. >
 P
/I= $DIR @ 1, P. @
 P
/I= $COMMI @ 1, P. >
// N
* O
* RECOVER ANY SPACE AND MAKE SURE THERE ARE NO ERRORS
* O
// JOB J
// N
* O
// BOJ J
/D=1. K
// N
* END OF GEN PROCEDURE

Okay yeah, there's some seriously interesting stuff on here.

Edited: I keep seeing references to something called "COLT". I can't tell if it's an application, a hardware platform or an internal codename.
 
Last edited:
bsdphk said:
Wouldn't it be possible to fit some kind of serial flash to the Pico, or have you maxed out the pins already ?
Click to expand...

The Pico has 26 GPIO pins. SPI flash or a SD card slot both requires 4 pins it seems?

My rough idea for a design would emulate these 26 pins on the SMD-0 protocol:
  • UNIT SELECT TAG
  • TAG 1-3
  • BIT 0-9
  • INDEX
  • SECTOR
  • ON CYLINDER
  • UNIT READY
  • ADDRESS MARK
  • SERVO CLOCK
  • READ DATA
  • READ CLOCK
  • WRITE DATA
  • WRITE CLOCK
  • UNIT SELECTED
  • SEEK END
We could probably save 1 pin by "fusing" on-cylinder and seek-end because they go high at the same time under normal conditions (no seek errors) if I remember correctly.

It might also be possible to "fuse" unit-ready and unit-selected because they also should have the same value when no fault exists.

If writing data back to the emulator is not required we can cut write data/clock (2 pins).

If address mark is not used by any of our "clients" then we can cut that too (1 pin).

I've already sacrificed UNIT SELECT BIT 0-3, FAULT and SEEK ERROR (and some even less important ones). I hope controllers don't deliberately try to raise errors :) (a controller could do that by seeking to a too high cylinder). I'm a bit more nervous about cutting the select bits because it might confuse a controller that attempts to auto-discover units on the bus.
 
Okay so I've now spent the last three hours or so going through the image and that I can tell:

-It's a backup of an 8261 pack
-I can't tell if it's a bootable tape or if you require DTUX to dump the tape back to disk
-It has flavors of MFE/IV and IDOS
-IDOS has a mode to generate a bootable disk for diagnostic purposes
--I can't tell if that's just for disk or additional routines such as memory or I/O testing
-It has extra packages for NP-80 support and seems to imply it also has the software load to "boot" the NP-80, with many verbose responses for various errors.
-It has extra packages for IV/90 Model II processor support
-There is support for time and date
-It has Philips OEM bits and pieces scattered around, but anything stored in plaintext appears to be in English.
-"QUEST" Ver. 1 seems to be a ported version of Adventure/Colossal Cave Adventure with a build date of 7 Jun, 1978
-QUEST is a multi-user port. Multiple users can play the game and take turns using multiple terminals. It does seem to internally know the current date and time.
-The latter half of the image is just duplicates of the game but not the QUEST database. There's fragments from previous people playing.

YOU ARE IN AN ANTEROOM LEADING TO A LARGE PASSAGE TO THE EAST. SMALL PASSAGES GO WEST AND UP. THE REMNANTS OF RECENT DIGGING ARE EVIDENT. A SIGN IN MIDAIR HERE SAYS 'CAVE UNDER CONSTRUCTION BEYOND THIS POINT. PROCEED AT OWN RISK. (WITT CONSTRUCTION COMPANY)'
THERE ARE A FEW RECENT ISSUES OF 'SPELUNKER TODAY' MAGAZINE HERE.
Click to expand...

This is useful. This is incredibly useful. Thank you very much for the effort to dump that tape. If you ever get that other pack read I'd love to see what's in there.
 
I have examined the disc-pack that came in the same donation as the tape.

It is a CDC type 9877 disc-pack and (as a minimum) the bottom surface suffered a head-crash.

It may still be possible to recover some data from this disc-pack, but it will take much more time.

I have a faint recollection that the bottom surface contain the servo-tracks, if so it becomes even more challenging, but it would also mean that it might be possible to recover all the data.

There is also a Diablo type cartridge in the donation, the only informative markings say that it is "philips 8 sector" and that it has also suffered a head-crash.

I want to stress that we have no idea what these disc-packs contain, the only thing which links them to the tape is the word "philips" and the box it all came in, but that box also contained artifacts from other manufacturers than IV/philips.

If, from a (lack of) software availability point of view, reading these disc-packs should be attempted, I see two options:

A) Motivate @anderskaare and his father to spend the time. (Ask him yourself :)

or

B) Have datamuseum.dk pass them on to somebody who is motivated. (I dont decide this, but I would support such a request.)

Sorry...

Poul-Henning
 
I do still appreciate looking into it anyways. There was still enough recovered from the one pack that in theory not only can a bootable pack be made but one with a multiuser game no less!
 
Let me know when we can play :)

We chatted informally about these three artifacts yesterday: If we get a reasonable adoption request, we will almost certainly pass them on to a better home.

If you are interested, send an email to info@datamuseum.dk.

Since our accountant is also on that alias, I expect "will pay for shipping" to be an obligatory component of "reasonable" :)

Otherwise we put them in the collection, where they will survive, at least until something more important needs the space.
 
I appreciate the offer but unfortunately crashed packs are at this time still somewhat of an unrecoverable media and I'm not sure what I'd be able to do with them beyond display them with my other crashed packs.
I'm seeing a bit of a trend here. Most packs from that era were recycled but a lot of crashed packs survived because security wise they are somewhat unrecoverable, especially in the crash region.
 
Yeah, I'm not sure I would spend several hundred dollars myself either :)

Having read many hundred data media into our "BitArchive" at Datamuseum.dk, I see a clear pattern where the "defect" media have archæologically more interesting content, because they hold a frozen snapshot of the work process, whereas carefully curated "archive" media have been polished to perfection to remove all signs of it.

Or as a "real" archæologist said it: "A single lost ring can reveal more than a buried treasure."
 
You must log in or register to reply here.
Back
Top