

This disk image is from a real VME10 with Unix SYSV/68 r2v1.0 installed

the disk has two errors on it...

inode 79 is file ./core        on /dev/rdsk/wd_0s0 
inode  7 is file ./adm/errfile on /dev/rdsk/wd_0s1

these show as POSSIBLE FILE SIZE ERROR during FSCK

it had been used for quite awhile, back in the 80's ... it has sat in my garage for the last 30 years.... and may be modified incorrectly..

it was imaged by using the TENBUG IOP command to read 0x1000 LSNs (or 0x800) to memory at 180000-27ffff (or 0x200000 to 0x27ffff)

then i used the TENBUG DU (DUMP S-RECS) command to dump 0x1000 LSNs at a time from memory at 180000-27ffff while capturing the S-rec to a file on a PC. 

the PS shutdown with an overload during the dump of LSNs starting at 0x20000, so i removed a MVME202 512k board and did the rest, reading 0x800 LSNs into memory at 0x200000 (the PS later started to work again ????.. might have been a bug  (a real bug..like insect or arachnid) )

after acquiring all data as S-recs , i then loaded them into the VME10 emulator, and then wrote them to a disk image using the Get/Put BOOT feature..

this process of dumping and capturing LSNs took several days.. each 0x1000 LSNs took about 50 minutes. 

after Booting on the emulator, i removed the ROOT password...


the process can be reversed, if you want to put onto a real VME10...

use TENBUG's IOP to read the disk into memory that exists on your real vme10, then  dump s-recs to the printer, with the printer set to write to a file(not screen) (still takes quite a while)

FORMAT the real HD with alternate sector capability

then using the LO command, tranfer each s-rec file to the real vme10 (via serial port on MVME400) and use IOP to write to the disk


this system was sent to me from toronto canada. it had been used for various things at a motorola sales office.. 

i do not remember modifying it, but it appears that i added a user for me and set it up to use my Hazeltine 1510 on a MVME400 port... i am not a unix guru, so my changes may or may not be proper...

the system boots and reports a missing MVME370  ... seems to run OK though... probably best to regen without it...there's an old kernel but i have not booted it to see what it is...

DO NOT MIX r1v2.8 HDs and r2v1.0 HDs....they have different partitoning... NEVER BOOT a r1v2.8 unix on a system with a hard disk that is NOT blank (or at least has the same swap area as the fixed swap area defined in the kernel)... the swap area is active and at a fixed location...
