>> file as a logical device, then FORMAT or INIT it, or do a COPY/DEV
>> to it...
>
>Use PIP to do a absolute block addressed copy. I think it's :n or :I
>and your can then move known clear blocks to anywhere on the disk.
I think you're talking about RT-11, Allison, but I may be wrong because
the utility name you specify and the options you're talking about make
no sense under RT-11. Are you maybe talking about some other OS?
Under RT-11, it's not PIP, it's DUP, and the option is /G:n.
The CCL equivalent is COPY/FILE/DEVICE/START:n.
>If you have to do that alot under RT-11 make up a disk with files that
>contain nothingg (fresh disk) but use the entire surface and then image
>copy it.
Or, even easier, just do an FORMAT/VERIFY:ONLY. To be really thorough,
do a FORMAT/VERIFY:ONLY/PATT:7777 to write 12 different patterns over
the disk.
--
Tim Shoppa Email: shoppa(a)trailing-edge.com
Trailing Edge Technology WWW: http://www.trailing-edge.com/
7328 Bradley Blvd Voice: 301-767-5917
Bethesda, MD, USA 20817 Fax: 301-767-5927
Are there any users of the old Multibus-I out there? I'm having difficulty
identifying a board that is so "busy" that there was no room on which to put
an identifier in the silkscreen. It's a FD/HD controller with a '186 and an
8042 on it. Sound familiar?
Dick
-----Original Message-----
From: Richard Erlacher <edick(a)idcomm.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Thursday, May 27, 1999 11:16 PM
Subject: Re: Re[4]: Bringing up a CPM
>Yes, '81 was pretty late . . . CP/M-86 came out then, as did PC-DOS.
>Within a few years, nobody wanted to be limited by the same systems they
>coveted only a few years earlier. By '81, the Apple][ could be equipped
>with a Z80 board, a "real" FDC (Sorrento Valley Associates ?) an 80x24
>display, and a hard disk if you could afford it. I recently sold the
>prototype of the original Apple HDC I made up in the spring of '81 together
>with my first ST-506.
>
>Those were the days . . . <sigh>
>
>Today I can still run CP/M but at an effective clock rate of 83MHz on my
>notebook . . . designing hardware involves thousands of lines of HDL, weeks
>in front of a simulation, and when it's done, I can't even hook up an
>instrument small and fast enough to inspect it because even our government
>can't afford one. One has to design circuits with 25% overhead so they can
>be inspected. Oh, well . . .
>
>Dick
>-----Original Message-----
>From: Allison J Parent <allisonp(a)world.std.com>
>To: Discussion re-collecting of classic computers
><classiccmp(a)u.washington.edu>
>Date: Thursday, May 27, 1999 8:54 PM
>Subject: Re: Re[4]: Bringing up a CPM
>
>
>><If you're writing your own, it might be well to keep in mind that the
BIOS
>><used in several late-generation CP/M systems used device drivers which
>coul
>>
>>It was late generation in 1981! I started doing it then. CPM had a
formal
>>product called CP/M+ (CP/M3.0) to extend that idea.
>>
>><California Computer Systems (CCS) had a pretty nice boot process in which
>><they loaded a skeletal BIOS in a 32K CP/M, since 32K was the smallest
>memor
>><in which they claimed they could run. It wrote that to the boot blocks,
>>
>>Actualy it was 20k for cpm2.2, as it was distributed as a 20k system that
>>you would run movcpm on to get the xxK version you wanted.
>>
>><then, under the control of that skeletal system, they loaded a
"full-size"
>><(you get to define that!) CP/M and transfer control to it. It's pretty
>><solid and makes the preparation of a bootable disk a straightforward if
no
>><a quick process.
>>
>>Yes and they were doing it a long time back, Compupro too. Kaypro was one
>>of the few "boxed" system that had the rom mapped to get a large TPA.
>>
>><IIRC, the XEROX 820 used a swapped-in BIOS which lived in PROM and was
>><mapped into the TPA during file transfers, or something on that order.
If
>>
>>Classic.
>>
>><your machine can handle that, it saves on BIOS size, especially tables,
>etc
>><and, generally speaking, if the READ operations from the TPA are from
>><temprorarily mapped-in PROMs, you can overwrite the TPA in the event
you'r
>><loading overlays, with complete impunity. That way your
>blocking/deblockin
>><buffer space can still reside in high memory.
>>
>>An IMSAI can neither handle that nor not handle that. The basic design
>>had no rom! To do that you need a prom card with a little bit of hardware
>>to map it with an IO port.
>>
>>The key here is to get a working system in whatever space... Why, it's the
>>development platfrom for itself. Once you have it running and can poke
and
>>understand it the improvements will come.
>>
>>Allison
>>
>>
>
Hi Chuck,
Check the config file first, if your kernel looks for a DHV11 anyway ...
cheers,
emanuel
-----Original Message-----
From: Chuck McManis <cmcmanis(a)freegate.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Thursday, May 27, 1999 10:58 AM
Subject: "default" DHV11 CSR?
>Does anyone know the "default" CSR for the first DHV-11? (8x serial mux)
>I'm trying to get one recognized in my uVax III with NetBSD and it's not
>seeing it.
>--Chuck
>
>
>
I found this card in a pile of scrap boards. The IC on the top right corner
is broken. Can anyone tell me what it's supposed to be? It's marked U 16
and is a 16 pin SSI DIP. Does anyone have any docs for this card?
Joe
<I'm sure that lawyers are the worst because they know that if you did
<anything with the information or even made it public knowledge that you ha
<the information they would successfully sue you for everything you own.
It's a foolish practice. Running Norton's diskwipe is a good thing but at
least delete and better yet do a format.
They are at risk for malpractice for mishandeling possibly confifential
info. Their risk is much greater due to that confidence.
Generally, wipe them. If the disk has a possibly useful OS then clean it.
Whatever you do respect privacy!
I work as a MIS/Sysadmin, in short that means everything in the company
can or is seen by me. That also means I have a responsability to keep it
to myself where it is known.
Since I've been doing this for quite a while and often so I have usable
disks! MY standard thing is to let the former owners if known that I
will be trying to use the disk and if there is any data found it will be
destroyed or at their option copied if possible and returned to them.
More often than not the drive is LLF'd as the controller I'm using doesn't
like their format. If I plan to pass on the disks I will try to wipe
them first or at least make sure nothing grossly dangerous to the former
owner is on them. That is assuming I have hardware to do that.
Allison
Hello,
I recently acquired a VAXstation 3100 from a local pharmaceutical
company that was trashing it. Being a sucker for old computers, and
having always been intrigued by VMS, i've messed around with it.
I know incredibly little about VMS, and have never encountered it
before yesterday, but what I have been able to figure out is that it's
running VAX/VMS 5.4, it has 16Mb of RAM, (2) 212Mb hard drives, and an
RX23 disk drive. Does anyone have any references or links that would
be helpful in setting this thing up? Any information would be greatly
appreciated.
Thanks in advance.
-paul
--
paul(a)paul.dragontear.org [a paradigm of a paramount failure]
So... having found some time to have a look at these beasties, I find that
overall I'm still as puzzled as before.
And one of these cases where documentation can be TOO old... My one
vintage HP catalog predates these CPUs by a couple of years. The catalog
only lists the HP2116.
I wandered through the card cages in both machines (fairly diverse
configurations) and the designations look like this:
Machine 1 Front card cage Rear card cage
DCPC 13037 Intf
Memory Protect Grd True In/Out
M.E.M. Grd True In/Out
64k HSM 12747H Microcircuit
64k HSM 12747H BACI 12966A
64k HSM 12747H 7970 Mag Tape 2
64k HSM 12747H 7970 Mag Tape 1
64k HSM 12747H Line Printer
64k HSM 12747H Time Base Gen
Mem Contr 2102E F.E.M.
Main Logic? (under chassis)
Machine 2 Front card cage Rear card cage
DCPC Jumper
Memory Protect I/O Buffer
M.E.M. 8 Chan Mux
Standard Memories Bus I/O
(256k memory) 1
Standard Memories 2
(256k memory) Disc Intf 2
256kw 12749H Disc Intf 1
256kw 12749H 3
Mem Contr 2102E 4
BACI 12966H
12821A Disc Intf
Time Base Gen
F.E.M.
Main Logic? (under chassis)
(pictures are on the MiniComputers page at The Computer Garage)
Some of the cards are fairly obvious as to function, (memory, time base
gen, etc...) but some of the designations are a bit vague, and in any case
I still need to find docs on this critter and the cards.
The cards designated as 1,2,3, & 4 are all identical, and look like
multi-channel serial I/O cards. The only obvious designation are etched on
the card and read 5180-1953 and 668298. They are HP cards...
Any information on these critters would be greatly appreciated!
After the usual pre-launch checks, all of the (apparently) optional cards
were removed from the card cages and the units were powered up. Curiously,
they both act identically in that they seem to have some front panel
function, but the CPUs seem to be hung pretty hard.
No odd sounds or loss of magic smoke, so an initial suspicion is a
configuration error common to both units. The card cages only have
specific card notations on a couple of slots, so there is the obvious
question of proper card positioning. (no idea if the cages are a parallel
bus or not)
Help???
Thanks;
-jim
---
jimw(a)computergarage.org
The Computer Garage - http://www.computergarage.org
Computer Garage Fax - (503) 646-0174
<If you're writing your own, it might be well to keep in mind that the BIOS
<used in several late-generation CP/M systems used device drivers which coul
It was late generation in 1981! I started doing it then. CPM had a formal
product called CP/M+ (CP/M3.0) to extend that idea.
<California Computer Systems (CCS) had a pretty nice boot process in which
<they loaded a skeletal BIOS in a 32K CP/M, since 32K was the smallest memor
<in which they claimed they could run. It wrote that to the boot blocks,
Actualy it was 20k for cpm2.2, as it was distributed as a 20k system that
you would run movcpm on to get the xxK version you wanted.
<then, under the control of that skeletal system, they loaded a "full-size"
<(you get to define that!) CP/M and transfer control to it. It's pretty
<solid and makes the preparation of a bootable disk a straightforward if no
<a quick process.
Yes and they were doing it a long time back, Compupro too. Kaypro was one
of the few "boxed" system that had the rom mapped to get a large TPA.
<IIRC, the XEROX 820 used a swapped-in BIOS which lived in PROM and was
<mapped into the TPA during file transfers, or something on that order. If
Classic.
<your machine can handle that, it saves on BIOS size, especially tables, etc
<and, generally speaking, if the READ operations from the TPA are from
<temprorarily mapped-in PROMs, you can overwrite the TPA in the event you'r
<loading overlays, with complete impunity. That way your blocking/deblockin
<buffer space can still reside in high memory.
An IMSAI can neither handle that nor not handle that. The basic design
had no rom! To do that you need a prom card with a little bit of hardware
to map it with an IO port.
The key here is to get a working system in whatever space... Why, it's the
development platfrom for itself. Once you have it running and can poke and
understand it the improvements will come.
Allison
If you're writing your own, it might be well to keep in mind that the BIOS
used in several late-generation CP/M systems used device drivers which could
be swapped in and out of PROM. This seems like a decent idea in view of the
way in which some compilers handled their TPA usage. You could end up with
a pretty big BIOS if you make it any sort of fancy at all , and that could
mean you can't run some compiled programs.
California Computer Systems (CCS) had a pretty nice boot process in which
they loaded a skeletal BIOS in a 32K CP/M, since 32K was the smallest memory
in which they claimed they could run. It wrote that to the boot blocks,
then, under the control of that skeletal system, they loaded a "full-size"
(you get to define that!) CP/M and transfer control to it. It's pretty
solid and makes the preparation of a bootable disk a straightforward if not
a quick process.
IIRC, the XEROX 820 used a swapped-in BIOS which lived in PROM and was
mapped into the TPA during file transfers, or something on that order. If
your machine can handle that, it saves on BIOS size, especially tables, etc,
and, generally speaking, if the READ operations from the TPA are from
temprorarily mapped-in PROMs, you can overwrite the TPA in the event you're
loading overlays, with complete impunity. That way your blocking/deblocking
buffer space can still reside in high memory.
Just a thought . . .
Dick
-----Original Message-----
From: Dwight Elvey <elvey(a)hal.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Thursday, May 27, 1999 3:25 PM
Subject: Re[4]: Bringing up a CPM
>allisonp(a)world.std.com wrote:
>> > I guess the issue is that the additional space is the BIOS and
>> > since I'll be replacing this with my own BIOS, and I write efficient
>> > code, I don't have to worry about it until I run out of space?
>> > Dwight
>> >
>> ???HUH??? Figure this if your running a SSSD 8" to be compatable with
>> media out there the system has two tracks to use for the CCP, BDOS and
>> bios. Thats 52 sectors!
>>
>> The first sector DOES NOT HAVE TO BE THE BOOT.
>
>Hi
> It does on my system unless I toggle in a loader or have
>EPROMs to do it. I'd like to not have any EPROMs if I don't
>need it. The controller automatically loads track 0 sector 1.
>I start executing at address zero and it boot loads the
>CPM system. The boot loader then jumps to the start of
>the CPM and it over writes info at address zero with what
>it requires there. As far as I know, I am following the examples
>for a non-MDS800 type system and following exactly what is
>shown on 6-14/6-15 of the CPM manual that I got from the
>unofficial site. The mapping shows that the first sector
>is a cold start loader and the CPM ( CCP ) part doesn't start until
>the second sector.
> It would seem that there was additional BOIS info loaded that
>didn't fit into the 51 sectors. It sounds like I can ignore
>this because I'll be replacing it anyway.
> Let me say, no EPROM's, boots from disk.
>Dwight
>
Woohoo! I got my vs3100 running with the hobbiest CD! Installed it on the
big hard disk too! Now I just have to find where I printed out the licence
before my PC ate itself.
--
Jim Strickland
jim(a)DIESPAMMERSCUMcalico.litterbox.com
-----------------------------------------------------------------------
Vote Meadocrat! Bill and Opus in 2000 - Who ELSE is there?
-----------------------------------------------------------------------
