> <healyzh at avanthar.com> wrote:
In this the weakest link would appear to be the SD Card. As such it seems to me that the best solution would be to have 2 or more SCSI2SD?s in the device. I?m not sure what benefit would be achieved by using a single board to present multiple devices. Unless of course you had a drive size limitation, or you?re trying to emulate something like 2GB or 4GB drives. As an example, that would be handy for VAXen with a 1GB Boot Drive limitation.
-Zane
Zane,
I am using SCSI2SD cards in a VAXstation 4000/90a, and in a MV3100-80 as well as
an Alpha DS10.
In the two VAXes, I use two SCSI2SD cards, configured identically with a system drive and a
user drive on class 10 16GB microSD cards. So each microSD card has both the system drive
and the user drive.
Thus I can use VMS backup from one microSD card to another so that if one microSD card fails I can
easily recover from it. So far I have not had hardware failures, but being able to recover from a
bad software installation which has been VERY helpful.
Mark
Hello,
Is there anyone with a VT100 (or any VT1xx, if so please specify which)
that can make a photo displaying text in reverse video? I'm making a
detailed simulation of the VT100 hardware, and I'd like to see what, if
any, effect dot streching has. I searched the "VT100 Technical Manual",
but as far as I can see it doesn't say.
A good sample text would be:
ESC [ 7 m b d h x CR LF
ESC [ 0 m b d h x CR LF
I am looking for the manual for the following Omnibus board:
M8652 KL8F Double-buffered asynch terminal control
Is there a scanned copy of the manual and/or schematic or any other
information for this board somewhere?
Thanks and best regards
Tom Hunter
I've just finished processing a bunch of RX01 and RX02 RT11A disks.
The files on the RX01 floppies are of type .DPA and those on the RX02
ones, DPY. No files of any other type in the whole collection.
I have no other information, but I suspect that these are plotter files.
Both types seem to start with the same prefix bytes, for example:
06 00 f0 00 40 00 00 01 00 1e ff ff 00 00 00 00
Does anyone have a guide to how these files are structured?
Thanks,
Chuck
Is there any recommended method for cleaning up melted ?rubber? feet on a plastic case?
I?m trying to determine if I can revive the VAXstation 4000/90 I received from a list member, back around 1998 (it?s never worked). When I pulled it out, I discovered that its feet have melted, and I?m assuming probably made a mess on the disk enclosure for my VAXstation 3100 that it was on top of.
Zane
Hi All,
I lent my Sun 3/80 out to someone and it came back pretty damaged. Does
anyone by chance have an old 3/80 carcass laying around that has a good
rear plastic bezel P/N 600-2209-02? If not, does anyone have any plastic
repair suggestions? Also one of the rear feet (narrower rear one) opposite
the PSU was missing...
-Kurt
THanks Lee!! Much appreciated - confirmed my decaying memory, and
pointed out the the almost mythical DECNA!!
bb
On Wed, May 19, 2021 at 1:38 PM <cctalk-request at classiccmp.org> wrote:
>
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. DECNet for Pro 300 series boxes (Lee Gleason)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 18 May 2021 12:20:34 -0500
> From: Lee Gleason <lee.gleason at comcast.net>
> To: cctalk at classiccmp.org
> Subject: DECNet for Pro 300 series boxes
> Message-ID: <db66b12f-e0a4-94b4-d9e9-efa88a84851e at comcast.net>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
>
> ? DECnet for Pro350/380 was donated to DECUS, available as? DECUS
> package PRO175. A quick Goog found the floppy disk images for it at
> http://www.os2site.com/sw/DEC/pro/pro175/index.html. If that site
> doesn't work out, or you don't like them in LHARC format, let me know -
> I have them as normal dsk files. DECnet on the PRO's was end node only,
> you could run it DDCMP on an asynch line, or on the rare, elusive, DECNA
> ethernet card - but not both at once.
>
> --
> Lee K. Gleason N5ZMR
> Control-G Consultants
> lee.gleason at comcast.net
>
>
> End of cctalk Digest, Vol 80, Issue 17
> **************************************
? DECnet for Pro350/380 was donated to DECUS, available as? DECUS
package PRO175. A quick Goog found the floppy disk images for it at
http://www.os2site.com/sw/DEC/pro/pro175/index.html. If that site
doesn't work out, or you don't like them in LHARC format, let me know -
I have them as normal dsk files. DECnet on the PRO's was end node only,
you could run it DDCMP on an asynch line, or on the rare, elusive, DECNA
ethernet card - but not both at once.
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
(I had accidentally sent my reply below only to Antonio. I'm resending
it to the list.)
> On 10/05/2021 10:05, Malte Dehling wrote:
> > Thanks a lot, Antonio, these are very valuable to have!
> I've only checked a couple of them under SIMH, so it would be helpful to
> know if I need to check my workflow or not.
> > I think uploading them to archive.org would be a good long-term
> > solution. I can take care of it if you don't have an account.
>
> Please do. Thanks.
Will do. I'll let you know.
> In other news, I polished the MAR-1989 CONOLD, which looked very bad, to
> start with. Amazingly it buffed up quite nicely and then read surprisingly
> well:
>
> [
>
> $ ddrescue -r5 -v /dev/sr1 CDROM-AG-NC67A-RE-1989-03-VMS-CONOLD.iso
> CDROM-AG-NC67A-RE-1989-03-VMS-CONOLD.map
> GNU ddrescue 1.23
> About to copy 205199 kBytes from '/dev/sr1' to
> 'CDROM-AG-NC67A-RE-1989-03-VMS-CONOLD.iso'
> ??? Starting positions: infile = 0 B,? outfile = 0 B
> ??? Copy block size: 128 sectors?????? Initial skip size: 128 sectors
> Sector size: 512 Bytes
>
> Press Ctrl-C to interrupt
> ???? ipos:? 205198 kB, non-trimmed:??????? 0 B,? current rate:?????? 0 B/s
> ???? opos:? 205198 kB, non-scraped:??????? 0 B,? average rate: 637 kB/s
> non-tried:??????? 0 B,? bad-sector:???? 2048 B,??? error rate: 170 B/s
> ? rescued:? 205197 kB,?? bad areas:??????? 1,??????? run time:????? 5m 22s
> pct rescued:?? 99.99%, read errors:?????? 25,? remaining time:???????? n/a
> ????????????????????????????? time since last successful read:????? 2m? 1s
> Finished
> ]
>
>
> So I went ahead and tried the CONDIST from MAY-1989. That too now can be
> read, although it is proving a somewhat tougher nut to crack:
>
> [
>
> $ ddrescue -r5 -v /dev/sr1 CDROM-AG-MN36D-RE-1989-05-VMS-CONDIST.iso
> CDROM-AG-MN36D-RE-1989-05-VMS-CONDIST.map
> GNU ddrescue 1.23
> About to copy 623247 kBytes from '/dev/sr1' to
> 'CDROM-AG-MN36D-RE-1989-05-VMS-CONDIST.iso'
> ??? Starting positions: infile = 0 B,? outfile = 0 B
> ??? Copy block size: 128 sectors?????? Initial skip size: 128 sectors
> Sector size: 512 Bytes
>
> Press Ctrl-C to interrupt
> ???? ipos:??? 5919 kB, non-trimmed:??????? 0 B,? current rate:?????? 0 B/s
> ???? opos:??? 5919 kB, non-scraped:?? 11127 kB,? average rate: 14694 B/s
> non-tried:??????? 0 B,? bad-sector:??? 2843 kB,??? error rate:????? 85 B/s
> ? rescued:? 609276 kB,?? bad areas:????? 445,??????? run time: 11h 31m? 2s
> pct rescued:?? 97.75%, read errors:???? 5884,? remaining time:? 5d 23h 43m
> ????????????????????????????? time since last successful read:????? 2m 45s
> Scraping failed blocks... (forwards)??? ]
>
>
> On the plus side, that's 97.75% more data than I had before :-) but the
> "remaining time" looks like it could be the rest of the week (it varies
> quite a bit).
>
>
> I think, from reading the manual, that I can use CTRL-C and restart this
> again later and it will pick up where it left off using the map file. Is
> this right?
Very nice, this worked much better than I had expected! And you're
right, you can simply CTRL-C and restart ddrescue with the same command
(i.e., with the iso and map file; different options should work.) I would
make a copy of the files before restarting, just in case.
> Are there any other options I should consider trying?
Can you try with "-b 2048 -d" for direct disc access and maybe once more
with "-R" for reverse?
> Another thought is that perhaps a shade more polishing might help. If I
> polish the CDROM a little more and then resume the ddrescue, I think I won't
> be any worse off than I am now, i.e. all existing data will still be there
> and all I'll be risking is data that maybe would have eventually read before
> but now may not read at all. Is that right? Successful reads are now ~20m
> apart, so I suspect that the remaining data will be quite difficult to
> recover.
After trying the various options on the disk in its current state, I see
no harm in trying this approach. With the map file, ddrescue should
never overwrite already-read data. Again, I would make a copy to be
safe.
Cheers,
Malte
--
Malte Dehling
<mdehling at gmail.com>
