A very generous list member just gave me a SPARCStation 20 with SunOS
4.1.4 on it. I thought the first thing I would do would be to image
its hard drive in my Linux PC, in case I ever wanted to start fresh.
I assume that if I make a bitwise copy of it, I can later write those
same bits out. But now I'm wondering what would happen if the disk
developed marked bad sectors; would that make an exact image
impossible to write onto it?
I have a disc image of that release, but unfortunately no SCSI CD-ROM.
It occurs to me that I could perhaps make a SunOS filesystem on Linux
and untar things from either the install CD or the image of the
original HD into it, but I don't know if that would produce something
actually bootable. I'm hoping there would be some way within Linux to
capture the actual format of the filesystem to use as a skeleton.
Does anyone know if this is possible (viz. creating a valid, bootable
filesystem and untarring files into it)? Or should I just invest in a
CD-ROM drive?
--
Eric Christopherson
On December 29 08:35 Brent Hilpert wrote:
> In 1985 I was setting up our new email system at CERN, and the email
> system had a security flaw that allowed the users' mail access
> passwords to be seen.
> This in of itself wasn't too big deal as there was little a hacker
> could do with it (only get access to mail pickup, and you'd need a
> system that talked X.400, which weren't prevalent).
> What made it a big security problem, of course, was that users tended
> to use their login password for their mail password, so once the
> hackers uncovered the mail password they ipso-facto often got a login
> password.
> The hacking was noticed and I was told they were networking in from
> Germany.
>
> Given the commonalities: time proximity (85-86), hacker source
> (Germany) and hacking targets (HEP/nuclear/research community), I
> wonder now if it was the same group of hackers.
Check https://www.youtube.com/watch?v=QR9HVZ8qHHo
Fast forward to 5:26 for a '87 sitelist mentioning CERN.
They sold some units of the c64x. I think there are still some on our local austin craigslist but like most folks said hardware isn't really interesting enough to me to justify the cost. ?
I cant remember where or who also produced a small (eepc? Or mini asus laptop running linux but badges with the commodore logo.?
The latest relicense grab I'm aware of is only available in Europe but is a phone calling itself the commodore pet?http://commodoresmart.com/ i imagine they're probably trying to work out the legal purchase from commodore usa to use the logo if they care for a US release.?
The first cut at a microcode disassembler for the CP16xx/WD21xx
chipsets, written in Python 3, is now on github:
https://github.com/brouhaha/cp16dis
The disassembler uses hexadecimal, in C notation, rather than octal as
used by DEC. Branch targets are labeled as L with the three-digit hex
address. The disassembler doesn't know about branch targets only
reached from the control chip translation PLA.
The disassembler probably needs a lot of work to be truly usable. It
does not even attempt to produce code that could be assembled by DEC's
"MICRO" microassembler that is in the KUV11 writable control store
support software, or any other assembler or microassembler. (I don't
have the KUV11 support software, but would *really* like to obtain a
copy!)
The register names decoded are specific to the LSI-11 microcode. I
don't yet know what the Pascal Microengine registers are used for, so
I don't have suitable names for them.
Here's an excerpt from the LSI-11 microcode at address 0x018 where you
can see one of the techniques for a computed jump, with entry occuring
at 0x20:
L018: jmp L101 ;018: 000101
jmp L161 ;019: 000161
jmp L192 ;01a: 000192
jmp L0f5 ;01b: 0000f5
jmp L0a5 ;01c: 0000a5
jmp L19e ;01d: 00019e
jmp L192 ;01e: 000192
jmp L192 ;01f: 000192
mi RIRL,RIRH ;020: 00ec89
jmp L018 ;021: 000018
This is used by an implicit jump caused by the translation array in
the control chip to location 0x20. The mi instruction causes the
instruction register (RIRH) to be OR'd into both bytes of the next
microinstruction, which is a jump to L018. Presumably before jumping
to the mi, all of the bits of the instruction register have been
masked off, except for the least significant three. It's also possible
that it's been shifted before masking. Also possible, not all of the
bits might be masked off, and there might be more of the jump table
elsewhere, depending on those bits. Note that if the most significant
five bits are not masked off, this could even change the jump
instruction at 0x21 to a different kind of instruction.
Eric
I have a MINC-23 that I am in the process of restoring. On the hardware side, I modified the BDV11 ROMs with some help from Malcolm Macleod on the boot eprom images so that I could boot a DU device directly from a 11/23 (not plus).
It boots an Emulex UC07 and a SCSI2SD so I can load various images on to the microSD card. I found a microSD to normal SD adapter which I plan to mount through one of the MINC blank front panels (with a blinking drive activity LED of course), so that changing disks is convenient. Currently, the SCSI2SD is formatted as four RD54 drives which are a convenient size to load individual images with the dd command on Linux or Mac OSX. Currently, I can boot both RT-11 or RSX11M with either 11/23 or 11/73 CPUs (limited to 256KB by the MINC Q18 bus).
The software I am looking for are the MINC software packages FEP (Fortran Enhancement Package) V2.1 and FRP (Fortran Real_time Package) V1.0. Also SSP V1.3 (Scientific Subroutines Package) and LSP V1.2 (Laboratory Subroutines Package) would be great to find as well. These all run under RT-11 and I understand that there was also a version (V1.1) of FEP and V1.0 of FRP that ran under RSX11M which would be fantastic to find as I am more interested in RSX11M. This is based on documents in the MINC folder in the bitsavers online archives.
Please contact me if you have any of these packages or would just like to compare notes on the MINC hardware. I am still gathering diagnostics and documentation to check out the analog to digital, programable clock, digital to analog, and digital I/O cards. Someone mentioned earlier the "Minicomputer in the Laboratory" book by James Cooper and I have found it to be very helpful as well.
Thanks and Happy New Year!
Mark
I have resolved that to get my H7874 PSU working better I am going to have
to bite the bullet and replace some electrolytic capacitors which cannot be
desoldered from below, at least not without some significant surgery on the
board (there are components soldered to the underside of the board and
attached to a large heatsink, all those components would have to be
desoldered so that the heatsink can be removed to get access to the
underside of the board).
I have had the suggestion to pull the old ones out from above, and then
solder in the new ones from above. These are relatively small radial types
(330uF, 25V).
I am sure the pins will just pull out of the bodies of the capacitors,
leaving me to desolder the pins from above, which should be OK. But, I am
worried about doing damage to the board by just pulling them "cold". Are
they really just going to pull out of the capacitor body, or does anyone
have any tips for doing this in the least damaging way possible?
Thanks
Rob
looks good Todd!
wall art is good to have!
Ed#
In a message dated 12/28/2015 10:54:47 A.M. US Mountain Standard Tim,
tsg at bonedaddy.net writes:
For what it's worth, I bought myself a Christmas present of:
http://www.ebay.com/itm/151918395795
Which is a print of a PDP-1 system (well, part of one anyway) on canvas.
It's not inexpensive but the ePay auction has a %-off "sale" going on
and the web site has coupons available to reduce the list price.
If you don't want to deal with ePay then you can check out their web
site at http://www.greatbigcanvas.com.
No connection and I can certainly understand that people might want to
spend the not inconsiderable amount on real hardware but I was pleased
with the result when it arrived today.
Todd
is this Evan?
if
In a message dated 12/28/2015 11:33:10 A.M. US Mountain Standard Tim,
cctalk at snarc.net writes:
> or who ever was supposed to get it done!
> Ed#
I don't know what "plaque dedication" you're talking about.
Email me privately / off-list.