Well . . . If I were in your position, and I am, sort-of, I'd have my 'scope
out and be looking at the bus cycles and the memory cycles. If the DMAC on
the FDC generates cycles similar to those generated by the CPU, then you're
in good shape, since you then have only to make the DRAM board work with one
and it will probably work with both.
It's been a long time since I looked at S-100 hardware and I'm just now
starting to put some boxes up in order to verify functionality of some of
the dozens and dozens of boards sitting around. Since I have several of
each, in many cases, I just need to figure out an appropriate way to test
each one and then go through the set. For debug purposes, I may generate a
PROM for each debug function I need. Firs, however, I have to haul that big
Integrand box with the 8" Winchester out onto the patio and set a terninal
on top of it.
Even if you don't intend to use PROMs in your final device, I'd certainly
recommend you build a few PROMS which make the processor do rudimentary
things and perhaps which make the DMAC do the same things. You then have
simple tools with which to troubleshoot your memory interfaces.
After reading about the problems you're having, I think I'll fetch the 1240
LA out onto the patio as well.
Dick
-----Original Message-----
From: Dwight Elvey <elvey(a)hal.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, June 01, 1999 6:43 PM
Subject: Re[4]: More Bringing up a CPM
>"Richard Erlacher" <edick(a)idcomm.com> wrote:
>> Is there a monitor that can be run to do things like run a software loop
>> to
>> write to, and subsequently, read from a block of SRAM? Does that work?
>> If
>> you're having doubts about the memory, it might be a good idea to leave
>> the
>> DMA out of things for a while, at least until your confidence in your
>> memories, of whichever type you decide to use, gets to where you have
>> some.
>
> Hi
> Leaving out the DMA isn't an option for doing CPM on this
>setup. It is the only disk access the mechine has.
>
> I will do some RAM testing tonight. This may be the problem.
>Like I said, I'll most likely do a March C since it is
>fast and I can include a larger address than would be
>practical with GALPAT.
>Thanks
>Dwight
>
Well, the DRAM circuit may work with one and not the other.
I remember going through this process once with DRAMs in a ZENITH PC/AT
clone. Their boards worked but my employer's didn't. I had to find a fix .
. .
Dick
-----Original Message-----
From: Dwight Elvey <elvey(a)hal.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, June 01, 1999 6:27 PM
Subject: Re[2]: More Bringing up a CPM
>allisonp(a)world.std.com (Allison J Parent) wrote:
>>
>> See if the controller set is generating Mwrite/?
>
> I'll need to look. It normally works with the front
>panel on the IMSAI. I just don't recall whether it
>used mwrite\ or pwr\.
>
>>
>> So, failures are to be expected and ones they've run a while you will
have
>> cooked out the soft parts.
>
> I hate that when it happens. I'd sure love to put in tried
>and true boards.
>
>>
>> Why would that be a problem if it has regulators? Assumeing of course
they
>> arent fried.
>
> They might be fried and the other boards weren't sensitive
>enough to it. All regulators do is control the terminator
>voltage. I may be that even fried, other boards get enough
>swing but not the DRAM boards. I suspect that it is more
>likely a design issue though.
>Dwight
>
of all those SRAM boards, there must be one which you believe is pretty
solid. IF the bus drivers on your DRAM board are socketed, so you can
remove them, perhaps you could put that board in the system as well, in
parallel with a "reliable" SRAM board, and, using a monitor or some other
means, toggle in a program which just does a jump to itself, followed by a
single write cycle. A little imagination will yield an appropriately short
loop. This should generate activity on the DRAM control lines which will
enable you to observe their interaction under control of the processor.
Make note of the duration of each of the control signals. Don't worry , for
now about the fact that there's no refresh if there isn't any, and verify
that the strobes overlap as they should and last as long as they should for
the memories on the board. If there's a refresh circuit, you should be able
to observe its operation while your loop isn't running.
The remarks made earlier about 8080's and DRAMs are probably quite correct.
Lots of DRAM boards rely on the processor to refresh the memories. Not all
processors do this. In fact, not even all Z-80 processor cards do this
correctly. Hence, DRAMs before '83-84 were somewhat iffy on the S-100. By
then, of course, the S-100 was, more or less, history. One of the things
you'll be able to do, as a consequence of this effort, is determine whether
making your IMSAI work with THIS particular DRAM board is a lost cause. It
may be, but DRAMs are not as difficult or fussy as a lot of people have
said. I've designed literally dozens of different DRAM circuits which in
almost all cases had to "look" as though they were static because no special
provision for nRAS precharge or refresh could be made. If you want to use
DRAMs, there's a way to make it happen. This particular board may not be
the easiest way, however.
You need refresh, for sure, and if this board doesn't generate it, there's a
pretty easy way, by scabbing on one 16-pin DIP packaged tristate 8-bit
counter or, worst-case, a PAL and maybe by swapping tri-state multiplexors
for the totem pole types in the circuit (if that is what they used) that
non-local accesses to either I/O or PROM can be sensed from the bus
interface so you can do cycle-stealing refresh which will be completely
hidden. Otherwise, you have to build a refresh timer in addition to some of
this other stuff. In that case, I'd recommend another solution.
DMA was popular for early FDC's in the mid '70's because 8080 processors
were too slow to get around the loop fast enough to transfer data from
successive sectors of the diskette. Some were too slow to transfer the data
in real time at all. The DMAC was able to keep up with either. Many such
DMAC's assumed some things about the system properties which were not
warranted. The may have assumed the system clock to be slower than it was,
or they may have assumed that there was no need for inter-cycle idle time.
SRAMS didn't need such luxuries, but DRAMs generally didn't tolerate being
accessed at a greater than 50% duty cycle. If you find that the DMAC is
forcing data into memory in bursts which stroke the RAM with little time
between access cycles, particularly if it causes the time high on nRAS to be
substantially less than the time low, the circuit may not work. There is a
FIX, however, which involves swapping low and high address nybbles. This
will cause successive byte reads or writes to occur in separate banks of
DRAM, which will, then, hopefully and depending on how the circuit is
designed, make the short cycle problem go away. . . not completely of
course, but sort-of.
Let me know how this goes. I'm really quite happy to help with this sort of
debugging.
Dick
-----Original Message-----
From: Dwight Elvey <elvey(a)hal.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, June 01, 1999 6:02 PM
Subject: Re[4]: More Bringing up a CPM
>"Richard Erlacher" <edick(a)idcomm.com> wrote:
>--snip--
>> Have you examined the nRAS nWE and nCAS signals to the DRAM
>> with your 'scope?
>
> Thanks Richard, this sounds like a good place to look.
>
>> Where does this DMA live? Is this an i8257 on the
>> controller?
>
> The DMA controller is all TTL, with no special controller
>chip. Like I said, it is an early unit made about '77 or
>so. The entire sequence is completely controlled by 2
>bipolar PROMs that are part of the controllers sequencer
>and a few flip-flops to deal with the DMA acknowledge sequence.
>It has been fun figuring this out to understand how to
>setup data for formatting ( different than read/write ).
>I'll have to look more at what and when the various
>signals are generated on the bus relative to the DRAM's
>signals.
> I'm just not sure which direction to go from here. Should
>I debug the DRAMs or look for the problem in my static
>RAMs. Since I need a full boat of 64K and I have no more
>static boards to put into it, I'll need to deal with what
>I have.
> I still have other issues to fix, like bad
>select signals going to the drive ( I can only hook up
>one right now ) and flaky RAMs. I have so far replaced
>4 IC's and one capacitor to get this far.
>Dwight
>
Is there a monitor that can be run to do things like run a software loop to
write to, and subsequently, read from a block of SRAM? Does that work? If
you're having doubts about the memory, it might be a good idea to leave the
DMA out of things for a while, at least until your confidence in your
memories, of whichever type you decide to use, gets to where you have some.
I have seen no evidence of any confidence testing in your RAMs, whatever
they are, and until you have at least 4K in which you have confidence, you
really can't do much, can you?
If you do have confidence in the processor being able to read/write the
DRAMs, then why not look at the access waveform timing on pins 3,4,and 15.
IIRC, those are nRAS, nWE, and nCAS, and they're the ones which have to work
correctly. If the processor works these devices correctly and the DMA
controller doesn't, the relative timing of these strobes will be the reason.
The DMAC itself may not, in fact, be causing your timing problem, in the
event that's the finding, but the bus interface logic may be incompatible.
I've seen some memory cards which decode sMEMWR and pDBOUT but don't use
pWR, which occurs once the data is valid. If that's not the case, you may
have to get out your XACTO knife, to make sure the memory isn't WRITTEN with
data that's not valid. It's also possible, as old as those boards are, that
they may have been designed in a way which causes incorrect bus acquisition
by the DMAC. The DMAC may, therefore, be fighting with some other player on
the bus. DRAM boards on a multi-card system are always difficult to debug
if there isn't a program running in them because there's no really frequent
cycle to use as a trigger for your 'scope. If your system can allow you to
load and run a little monitor program in the DRAM board, you'll have plenty
of cycles you can trigger on.
Dick
-----Original Message-----
From: CLASSICCMP(a)trailing-edge.com <CLASSICCMP(a)trailing-edge.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, June 01, 1999 2:44 PM
Subject: RE: Re[2]: More Bringing up a CPM
>> I have some DRAM boards that I've used with my Poly88.
>>These are 64K boards and I thought I'd use them but the disk's
>>DMA doesn't seem to write to them. I'm able to read and write
>>from the front toggles, just not from the DMA to the RAM.
>>
>> Does anyone know what the problem is here? Is there some
>>timing or pin out issue with DRAMs that would cause this
>>to happen in a standard IMSAI 8080? I'd really like to use
>>this DRAM because I trust it more than the statics in the
>>system, at least until I get things fully functional.
>
>Welcome to the world of S-100, where DRAM boards often didn't
>support DMA controllers properly. In some cases, you can rejumper
>them so that the DMA vs refresh timing conflict isn't such a problem.
>But many of us just went to pure static RAM systems where DMA
>was being done.
>
>What disk controller are you using, BTW? In some cases the problem
>isn't so much the memory, but it's the disk controller.
>
>> In any case, I think just getting to the A> prompt is
>>a major mile stone. I had to completely write a boot loader,
>>CBIOS, disk formatter and serial data transfer to get this far.
>
>It certainly is a major milestone. Congratulations!
>
>--
> 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
>
<refresh isn't the issue. Since the data isn't modified at
<all by the DMA, I'd think it was a missing WR strobe or
<not getting the address there at the right time.
See if the controller set is generating Mwrite/?
< I tend to agree here but in this case, I have 4 ea 8K, 4 ea 4K
<and one 16K static cards. I can replace this with one 64K card
<if I get the DMA write and read to work correctly. As I said,
<these cards are old and I've already had failures with less than
<20 hours of trying to bring it back up.
So, failures are to be expected and ones they've run a while you will have
cooked out the soft parts.
< It has a terminator card in it. Since this also has voltage
<regulators on it, it might even be a source of problems as well.
<I'll loke at it as well.
Why would that be a problem if it has regulators? Assumeing of course they
arent fried.
Allison
Do you know what the nature of the problem is? Does the DMA simply fail to
write to the DRAMM because it doesn't write to RAM at all, or is it a DRAM
timing failure? Have you examined the nRAS nWE and nCAS signals to the DRAM
with your 'scope? Where does this DMA live? Is this an i8257 on the
controller?
If you can take a look at a repetitive read waveform set on the DRAM chips
themselves, you'll easily see whether the timing is correct. The critical
things are the relationships between nCAS and valid data and nCAS and nWE.
nWE must end before nCAS. If the DMA will work on the SRAMs and not the
DRAMs, it's probably a bus timing issue. Perhaps you have to slow down.
Dick
-----Original Message-----
From: Dwight Elvey <elvey(a)hal.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, June 01, 1999 2:34 PM
Subject: Re[2]: More Bringing up a CPM
>Don Maslin <donm(a)cts.com> wrote:
>> On Fri, 28 May 1999, Dwight Elvey wrote:
>>
>> Dwight,
>>
>> > My next question is, could someone send me an image of a
>> > directory that I could use to build my disk?
>> --snip--
>
>> Here is an image of a 2.2 directory from an 8"SSSD disk. Hope it proves
>> useful. (It is not Imsai.)
>
>Hi Don
> Thanks a lot. As it was, I didn't need to do anything to start
>the directory. If it had the original E5's in it, CPM thinks
>it is an empty disk. Clever of DR, wasn't it! I'm learning
>more about CPM than most people know anyway.
> I was able to get a the system to the "A>" late Monday
>night. I then transfered some files by my simple serial
>downloader into the memory and used the SAVE command
>to write them to files. I did this for the DUMP, ED,
>STAT and ASM commands. DUMP and STAT seem to work
>OK but I'm having troubles with ED and haven't tried
>ASM yet.
> The ED command has some serious troubles. It allows me to
>do "I" and "T" commands but won't do a "L" or "E" commands correctly.
>Saving text to a file is one of the most useful parts of
>an editor but being able to move around is number 2 or 3.
>Since DUMP works, I'll use that to read back what the file
>has in it. If not that, I'll make an image file for CCP, BDOS
>and CBIOS. I'll then be able to tell where the problem
>lies.
> I've had some issues with RAM loosing data but I not sure
>where the problem is yet. This may be my problem. The
>RAM boards I have are some older 4K, 8K and one 16K
>static RAM boards that make up the needed 64K ( actually
>62K ) by the CPM.SYS file I have.
> I have some DRAM boards that I've used with my Poly88.
>These are 64K boards and I thought I'd use them but the disk's
>DMA doesn't seem to write to them. I'm able to read and write
>from the front toggles, just not from the DMA to the RAM.
>
> Does anyone know what the problem is here? Is there some
>timing or pin out issue with DRAMs that would cause this
>to happen in a standard IMSAI 8080? I'd really like to use
>this DRAM because I trust it more than the statics in the
>system, at least until I get things fully functional.
>
> In any case, I think just getting to the A> prompt is
>a major mile stone. I had to completely write a boot loader,
>CBIOS, disk formatter and serial data transfer to get this far.
>My longest to trouble shot problem was the difference
>between JNC and JC used with SUB.
>Dwight
>
>That little bit of experiment also required me to change my
>password - again. Is there any way to kill the calendar expiration of
>passwords? For my usage, I'd be happy if it didn't even look for one!
$ mcr authorize
UAF> help modify /expiration
MODIFY
/EXPIRATION
/EXPIRATION=time (default)
/NOEXPIRATION
Specifies the expiration date and time of the account. The
/NOEXPIRATION qualifier removes the expiration date on the
account or resets the expiration time for expired accounts.
The default expiration time period is 90 days for nonprivileged
users.
Does this help?
--
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
Bluoval wrote:
> I wasn't following this thread but here's my opinion.
> A buy a house and everything it contains. There just happenes to be a
treasure
> map in there leading me to a pot of gold. who owns the gold? ME.
Hang on. Says who? Taking the case of real estate - where the laws tend to be
different from other cases - if you buy some property, you own everything on the
property that was legitimately there (not stolen goods, for example) on the date
that ownership is transferred. So if the gold is on your property, it's yours,
whether or not there's a map. If the gold is not on the real estate you bought,
ownership hasn't passed with the property, even if you did find the treasure
map.
I know that the analogy doesn't really stretch that far, but just because you
have the data (map) doesn't mean you have a right to publish or otherwise make
use of it (dig up gold).
> Tony Duell wrote:
>
>> There's the first difference. In most cases you're _not_ buying a computer
>> and all the data on the hard drive.
>
> If I buy a computer w/ a hard drive, what ever data it might contain is mine
also.
> The seller is/was responsable for the data on there, not the buyer. the
seller
> should've deleted what he thought was sensitive information. Unless the data
is
> copyrighted, I have every right to do as i please with it, which would most
likely be
> erasure.
This way lies major legal tangles. Copyright law in the US tends to be
different from the rest of the world, but over here AFAIK if you put your name
and the date on it, it is your copyright unless someone can prove that they had
their name and a genuine earlier date on it. So any data you find, which will
presumably have been date stamped by the filing system, and may be user stamped
as well (or identified as the user's in some other way) is arguably
automatically copyrighted.
As far as publication is concerned, if you publish sensitive information about a
person, there may be an action for defamation or some similar offence even if it
is true. If it ain't true, there is an action for libel. Did you check truth
before you published?....
> I wasn't talking about morals. I'd probably find the previous owner and give
it to
> them, if they wanted it. otherwise I'd trash it. I have no use for old
letters and
> bank statements....
So you weren't talking about morals. Maybe you should have been thinking about
them, though. If someone makes a mistake and you discover it, what should you
(morally) do? Exploit it for financial gain? Or help them put it right?
> There have been many books published from people's personal data... diaries,
love
> letters, ect.. especially items found on/around important dates and events.
> Letters/ pictures/diaries from the Revolutionary War, Civil War, WW, WWII,
ect...
> sketches and drawings for some wacky invention..... all of these things
were , at
> one time by someone, considered personal data. many times we learn from them.
Do
> you think these people would have wanted their data published by some person
who just
> happened to find it in an attic, in a house he just bought? probably not, but
> historically they're priceless.
There have indeed. Generally after copyright has expired, which in most
countries now happens 50 or 70 years after the death of the writer. In the case
of war diaries and the like, these are usually published with the permission, if
not the active co-operation, of the author. This is a useful guide for when
personal data ceases to be sensitive - 50 to 70 years after the death of the
person concerned.
For me, the bottom line is more like: If you find sensitive data on a hard
disk, there _may_ be legal loopholes that allow you to use it. But they are
fewer than you might think. And (a) should you morally do so? And (b) do you
want to bring classic computer collectors into disrepute by doing so?
Philip.
<The drive is growing errors... Each pass through the formatter
<finds additional bad sectors, so I want to disable it and install/
It's crashed. Pull it. Swap the other into the box as they are
interchangeable. Just match the external RD54s jumpers to the defunct
internal one.
<run Ultrix from the external drive (if it is easy) until I get
<around to pulling the internal drive and replacing it. Otherwise,
<I have to disassemble both boxes to swap the drives, which I would
<prefer to avoid (because I'm lazy :)
You'll look longer for the cables and if the VS2000 box does not have the
cable adaptor section where will you plug it? A lot of the VS2000s didn't
have the adaptor (2" bottom addotion), I know I have three that didn't
so doing external cables/drives is a PITA.
Allison
<timing failure? Have you examined the nRAS nWE and nCAS signals to the DRA
<with your 'scope? Where does this DMA live? Is this an i8257 on the
<controller?
I'll bet not. Ramtiming is not half the problem on s100 as the general
design of the board. Some of the Dram cards use the inactive bus state of
the 8080/z80 to do hidden refresh, some do it after every nth read or
16us which ever come first, a few try to hide it as part of a read or
write. Most all do not have any arbitration to resolve a DMA request.
generally DMA and S100 before 1980or later was at best an iffy situation
and only likely to work if a whole cardset of a given vendor was used.
The reason for the latter was the interpretation of s100 was not stable
till 79ish or later (actually even after the 696 spec was published).
Anyhow, do to timing vaiations, arbitration problems and many poor DRAM
designs most people prefered static and avoided DMA.
The only two systems I know of that DMA is Compupro and Ithica Intersystems.
There are a few slaves (JADE, IMSAI (8080/372based) but, most used the main
cpu in a tight loop doing PIO.
Oh, yes, that reminds me. Some of the DRAM cards really hated the Floppy
cards that would do a wait/data stall by pulling PWAIT to keep the CPU
in sync without testing a port bit (northstar, MDC, others).
Allison
Hello, I have a Sun SparcII (RHL 4.2) that has a date problem-- no, he has
plenty of girls, ;) but the time and date keep getting reset on every
boot.. there have also been problems with getting it to boot (kernel shits
itself) and takes 15 or so tries before it boots correctly.. then
sometimes crashes at that point. Any ideas?
Also, I have a Sun 3/60 that I would like to put SunOS or BSD on to use as
my mail server or just to have running.. I need a keyboard, monitor, tape,
external hard disk, and probably media unless I can write to the tapes
>from my SparcII.
Thanks,
Kevin
-------------------------------------------------------------------------------
"It's you isn't it? THE BASTARD OPERATOR FROM HELL!"
"In the flesh, on the phone and in your account..."
-- BOFH #3
I spotted several of them this morning. What are they? They have a
separate keyboard and the CRT on the left side of the unit and a 5 1/4" HH
floppy disk drive mounted vertically on the RH side. They're about 18" deep
and 13" tall and 14" wide. The front of the unit hangs out over the front
feet the same way that a Apple Lisa does.
Joe
-----Original Message-----
From: Richard Erlacher <edick(a)idcomm.com>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, June 01, 1999 3:15 PM
Subject: Re: Re[2]: More Bringing up a CPM
>I've determined that I'm missing the doc's supporting my SMS/OMTI Series-10
>SCSI/SASI (probably SASI) 8" hard disk bridge adapter. Anything detailed
>would be very helpful, I think.
>
>For years the manual was sandwiched between the drive's logic board and the
>Series-10 controller, but now that I need it, it's missing . . .
>
>Oh, well . . .
>
>Dick
>
>
>
Don Maslin <donm(a)cts.com> wrote:
> On Fri, 28 May 1999, Dwight Elvey wrote:
>
> Dwight,
>
> > My next question is, could someone send me an image of a
> > directory that I could use to build my disk?
> --snip--
> Here is an image of a 2.2 directory from an 8"SSSD disk. Hope it proves
> useful. (It is not Imsai.)
Hi Don
Thanks a lot. As it was, I didn't need to do anything to start
the directory. If it had the original E5's in it, CPM thinks
it is an empty disk. Clever of DR, wasn't it! I'm learning
more about CPM than most people know anyway.
I was able to get a the system to the "A>" late Monday
night. I then transfered some files by my simple serial
downloader into the memory and used the SAVE command
to write them to files. I did this for the DUMP, ED,
STAT and ASM commands. DUMP and STAT seem to work
OK but I'm having troubles with ED and haven't tried
ASM yet.
The ED command has some serious troubles. It allows me to
do "I" and "T" commands but won't do a "L" or "E" commands correctly.
Saving text to a file is one of the most useful parts of
an editor but being able to move around is number 2 or 3.
Since DUMP works, I'll use that to read back what the file
has in it. If not that, I'll make an image file for CCP, BDOS
and CBIOS. I'll then be able to tell where the problem
lies.
I've had some issues with RAM loosing data but I not sure
where the problem is yet. This may be my problem. The
RAM boards I have are some older 4K, 8K and one 16K
static RAM boards that make up the needed 64K ( actually
62K ) by the CPM.SYS file I have.
I have some DRAM boards that I've used with my Poly88.
These are 64K boards and I thought I'd use them but the disk's
DMA doesn't seem to write to them. I'm able to read and write
>from the front toggles, just not from the DMA to the RAM.
Does anyone know what the problem is here? Is there some
timing or pin out issue with DRAMs that would cause this
to happen in a standard IMSAI 8080? I'd really like to use
this DRAM because I trust it more than the statics in the
system, at least until I get things fully functional.
In any case, I think just getting to the A> prompt is
a major mile stone. I had to completely write a boot loader,
CBIOS, disk formatter and serial data transfer to get this far.
My longest to trouble shot problem was the difference
between JNC and JC used with SUB.
Dwight
I've determined that I'm missing the doc's supporting my SMS/OMTI Series-10
SCSI/SASI (probably SASI) 8" hard disk bridge adapter. Anything detailed
would be very helpful, I think.
For years the manual was sandwiched between the drive's logic board and the
Series-10 controller, but now that I need it, it's missing . . .
Oh, well . . .
Dick
Title pretty much says it all.
Over the long weekend (where did it go?) I finally got time to check out
and power up the HP 9000/20 (aka: 9000/520) that recently joined the
collection.
It woke up without incident (tho there is still something rattling around
in the monitor that I have not been able to find yet), but now needs
something to run. You can only look at the "Looking for System" prompt
for so long...
So... (since I know there are at least one or two of these things in this
group) What runs on this critter? And can someone provide copies of some
disks? Diagnostics perhaps? Or dare I think it... Docs??? B^}
I already suspect that I'm going to have to find a hard drive to go along
with the unit to make it really happy, yes?
Obvious by now that I've never worked with this particular unit before?
Thanks!
-jim
---
jimw(a)computergarage.org
The Computer Garage - http://www.computergarage.org
Computer Garage Fax - (503) 646-0174
>>> Coming soon to www.computergarage.org - the CBBS/NW on-line archives
>>> Coming to VCF III (2-3 October 1999) - CBBS/NW live!
At 09:35 PM 5/17/99 -0700, you wrote:
>On Mon, 17 May 1999, David Williams wrote:
>
>> I suspect it will take more than an LLF. I've now notice that
>> sometimes when I power it on, it fails the startup tests and never
>> reaches a ready state. Of course maybe an LLF would fix that but
>> I don't know. I haven't been able to get it to access the catalog on
>> the drive though formatting under ProDOS now always claims to
>> work where it would fail before. The clicking sound it makes is
>> pretty loud and annoying and I'm sure a LLF won't help that. Does
>> anyone know if you used the same Apple II interface card for the 5
>> meg and 10 meg ProFILEs?
>
>Sounds like its dying. Might be time for a little home clean room to
>repair it. Go back and find the dicussion from several months back that
>talked about building a clean box.
Ok, going out on a limb here (not my first time)...
The infamous 'low level format' may indeed address the problem, but it's
not nearly as easy to do in this case as one might expect...
First: a couple of data points about the 'ProFile' drive subsystems.
1) The interface is just an over-glorified bi-directional parallel port!
(witness that to use it with a LISA, you run a straight-thru cable from the
ProFile to the parallel port on the LISA)
2) the drive in the ProFile is a 5 or 10 meg Shugart 4XX series mechanism,
but with an Apple custom logic board installed. So forget just about
everything you know about formatting hard drives...
3) you never directly address the drive in a ProFile, you issue commands to
the logic board in the ProFile, and it talks to the drive...
4) IIRC: one of the power up tests that the ProFile does (it has been a
while since I went thru Apple training on this critter) is a read test on
selected tracks on the drive. If this test fails (due to mechanical
failure or bit-rot) the drive will never come 'ready'
5) There is no inherent 'format' command in the ProFile controller logic.
To enable formatting capability you have to install a special chip
(according to rumour: a Z-80 with a piggyback EPROM) into a vacant socket
on the ProFile logic board, power up the unit and issue a special command.
(I doubt it matters what machine it is connected to at the time)
6) Running the 'format' command from ProDos (LISA office, etc...) does
little more than initialize the directory tracks in a form that ProDos (or
whatever) expects. It does no actual 'formatting' of the drive proper...
(man, where have we heard of THIS strategy before?)
Now, having said that...
It's quite possible that the problem may be little more than bit-rot due to
the degredation of the magnetic domains on the drive platters. (or it
really could be busted, but let's think good thots here) Also, power
failures during writes could honk up the drive real easily...
The real trick here however is coming up with the little format enabler
chip and the proper incantation to mumble at it!
There have been stories of people who have opened up their ProFiles and
found the previously mentioned socket occupied by the magic module, but
last time I looked in mine I was not one of the fortunate (?) ones...
The real downer in this, is that we are all likely to be impacted by this
somewhere along the way...
-jim
---
jimw(a)computergarage.org
The Computer Garage - http://www.computergarage.org
Computer Garage Fax - (503) 646-0174
Since I have two 2117F's at home, I'll answer this one...
You wrote...
>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.
Your machines are F series, the very last of the 1000 line I believe. The
2116 is one of the first. You've got both ends of the spectrum there ;)
Bear this in mind, memory related cards go in the front card cage, i/o
related cards in the rear card cage. There is no relationship between slot1
in front and slot1 in back. In the front card cage, the top three slots must
be used for a specific card in each slot, in the remaining slots order isn't
important (there are a few exceptions to this). In the rear, order isn't
important except the slot number (octal select code) determines the
interrupt priority of the board. Some OS's in the 1000 line expect certain
cards to be in certain slots. In addition, the OS on your disks was likely
genned to expect a certain card in every slot. I'm at work at the moment, so
if there's any of the following notes I'm not sure of, email me over the
weekend when I'm at home and I can clarify.
> DCPC
Dual Channel Port Controller this is basically a card that provides two
independent DMA channels for any I/o cards in the rear panel. Must go in top
slot, front card cage. Attach ribbon cable.
> 13037 intf
The 13037 is a disk controller for 7900A, 7905, 7906, 7920, and possibly
7925 drives. Different models of the 13037 could also support HP-IB as well
as direct connect style drives. This card should go to a 5 inch tall rack
mount box which contains a microprocessor board and several interface
boards. Cables from the 13037 rack mount box then go to the drives.
> Memory Protect
This is an optional memory protect card. ISTR it has to do with handling
parity errors instead of just halting the cpu. This must go in the front
cage, second slot from the top.
> Grd true in/out
Grd true in/out is an I/o card used for line level interfacing (process
control, etc.)
> M.E.M.
This is a Memory Expansion Module. It was necessary if the machine contained
more that 64k of ram. Bear in mind that it is only usefull if the ROM's that
go with it are in the Firmware accessory board. The firmware accessory board
usually attached to the bottom cpu card and hung underneath it on the back
right. The firmware roms provided some extra instructions for memory
management (ie. setting up paging). This must go in the front cage, third
slot from the top.
> Grd true in/out
Same as above.
> 64k HSM
64k ram card.
> 12747H Microcircuit
The microcircuit interface ISTR is a 40 bit card to interface to external
TTL levels. I'll have to look this up. Might also have been used to connect
an I/O extender box, don't recall at the moment.
> 64k HSM
64k ram card.
>12747H BACI 12966A
The 12966A baci card (buffered async control interface) is an RS232 port for
you. One of the better models, actually.
> 64k HSM 12747H
another 64k ram card.
> 7970 Mag Tape 2
The 7970 mag tape 2 card isn't for a second tape drive, it's the 2nd card in
a two controller set for the 7970 tape drive.
> 64k HSM 12747H
another 64k ram card.
> 7970 Mag Tape 1
The 7970 mag tape 1 is part of a 2 card set for a 7970 1/2 tape drive. the
real number is 13181 or 13183 depending on the model 7970 it went to.
> 64k HSM
another 64k ram card.
> Line Printer
Dunno about the line printer designation, but it should be obvious. probably
gpib interface.
> 64k HSM 12747H
another 64k ram card.
> Time Base Gen
The time base generator is a card used to provide various timing circuits.
It does more than just act as a system clock, but that's the best way to
describe it. Whether a TBG card is needed depends on the OS you load and the
software features (modules) you use with it.
> Mem Contr 2102E F.E.M.
This is the main memory controller for all those 64k ram cards. there is a
ribbon cable to attach it to each 64k ram card.
> Main Logic? (under chassis)
This is the cpu card itself. Look for the firmware accessory board attached
underneath the cpu card in the back right. It holds instruction set
additions typically.
>Machine 2 Front card cage Rear card cage
>
> DCPC
same as above
> Jumper
This was used in the I/o card cage if a card was not present. It just
preserved the interrupt priority chain; normally empty non-adjacent slots
are not allowed (unless you're doing all polling mode without need for
arming the interrupts).
> Memory Protect
> I/O Buffer
> M.E.M.
all same as above
> 8 Chan Mux
I would need a part number, but sounds similar to the 12920/12921 mux
controller. Multiple serial ports for terminals, printers, etc.
> Standard Memories Bus I/O
> (256k memory)
> Standard Memories
> (256k memory)
Not familiar with these, they sound 3rd partyish to me, probably memory...
> Disc Intf 2
the second controller of a two controller set, likely a 13210. This was used
ONLY for 7900A disk drives.
> 256kw 12749H
256kw ram.
> Disc Intf 1
the first controller of a two controller set, likely a 13210. only 7900a
again.
> 256kw 12749H
256kw ram
> Mem Contr 2102E
same as above system
> BACI 12966H
same as above system
> 12821A Disc Intf
I don't recall for sure, but I *THINK* this might be for fixed head disks
(earlier than the 7900A's). 2313 I think? Ahhh.. bad memory in my brain :)
> Time Base Gen
same as above
> F.E.M.
FEM or MEM? in a card cage, I would expect it to be MEM, same as above.
Otherwise, an educated guess would be some type of firmware board.
> Main Logic? (under chassis)
same as above.
>1, 2, 3, 4
Need to look up the part number for those. Possibly PSI's (programmable
serial interface), used to hook up graphics terminals (one DB25 for
keyboard, one DB25 for display).
>I still need to find docs on this critter and the cards.
I have a virtually complete documentation set for the above, sans a few of
the cards.
>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.
The front panel on the 21mx line is pretty straigforward. A&B are registers,
M is the memory location you want to look at, T is the contents of that
location, P is the program counter, and S is a general purpose status
register. The only thing not intuitive is that only when the T register is
displayed and you press the store switch, the M register is automatically
incremented for you (any other time you use the INC M button). Initially I
found this annoying, but it is handy. Note that the A and B registers are
memory locations 0 and 1 respectively - so they should be the same. As a
test, try clearing register a, set a bit pattern, then press store. Then set
the M register to zero, store, then look at T. It should be the same pattern
you stored in A.
Other important notes for a checkout - upon powerup, look at the very bottom
row of lights (a/b/m/t/p/s). Only one should be lit. If more of them are
lit, it indicates several different problems, the most likely of which is
memory configuration/parity error. If the machine has the power fail option,
deadness upon powerup can mean that the batteries are no longer sustaining
memory. The system disables some functions to alert you of this. There is a
way to clear this condition, but I need to check the manual when I get home.
Another thing you can try is selecting the S register, clearing all bits,
store, then set bits 6 through 11 to octal 13 (doesn't matter if there's a
card in slot 13). Press preset, then IBL. If the overflow light comes on,
nothing was loaded from ROM and you have a real problem. Otherwise... Then
point the M register to 37777 and look at the T register. Instead of the
zeros normally present on power up, you should see the contents of boot rom
loader 00 are present (hit INC M to step up). The changing pattern will tell
you it was able to load the boot loader. The 37777 memory location moves
depending on how much ram is in the system.
Finally, the 2117F should go through a powerup POST type test. Depending on
battery charge (if the power fail option is present) sometimes it can take
20 seconds sometimes 30 minutes or so, but eventually if the system is 100%
you should see the leftmost 5 bits or so on the display counting up as it
checks memory.
Since I'm at work and not at home, I'm reciting all this from memory. I
could have easily left something out or said something wrong. Feel free to
email me over the weekend on anything you have questions about.
>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)
The machines in question are using HSM type memory, which had a slightly
strange setup compared to the memory subsystems in the other HP systems I
also have (2113B 2109B) and work with more often. There are some real
specifics related to slots and ribbon cables in the front card cage. When I
get home I'll check how my 2117F's (which are running fine) are configured.
Jay West
> I think I have mentioned this before, but at work I have been told that I
> cannot have a disused tape _drive_ decause it has been used to back up
> payroll data. I realise that this is just the over exagerrated paranoia of
Ouch! I wasn't refused the tape drive on these grounds, but I was refused the
tapes. In vain did I try and point out that this drive was never used for
recording computer data - it was a very nice analogue machine used for recording
machine vibrations etc. for later analysis back at the lab...
Philip.
--- PG Manney <manney(a)hmcltd.net> wrote:
>
> >At 02:27 AM 5/31/99 -0400, PG Manney wrote:
> >>I have a friend (Yes, Virginia, I have two friends) who's been a DEC
> >>repairman for many years. He now wants to get rid of the accumulated a lot
> >>of stuff in his barn, and has asked me to help get rid of it.
> >
> >Obvious first question: Where is this barn?
>
>
> Behind his house. Where else? <g> (couldn't resist that!)
>
> In Northern Ohio, about halfway between Cleveland and Toledo. 44846 ZIP.
> Tiny place called Milan.
Woo Hoo! Close enough for a Road Trip! (Columbus is 2 hours south of
Cleveland)
I already put my requests in. The only outstanding question is how long
ago did this guy start picking stuff up. I have an abundance of 1980's
QBus stuff; I'm more interested in the odder stuff.
-ethan
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Thank you for the great response. We'll be getting together soon to go over
the stuff, and we'll be contacting people directly. You all have done me
many favors over the past couple 'a years, and I want to channel at least
SOME stuff into the hands of the people who will appreciate it.
Please feel free to keep emailing wants.
oh, yeah -- I'll consider trades. Photo or modern PC equipment... Ferrarris
also considered.
P Manney
>I have a friend (Yes, Virginia, I have two friends) who's been a DEC
>repairman for many years. He now wants to get rid of the accumulated a lot
>of stuff in his barn, and has asked me to help get rid of it.
>
>I'm not sure I have the time to make a complete catalogue of all his stuff.
>Anyway, I know squat about big iron, and therefore don't know what's
>valuable to people.
>
>Please, therefore, email me with your wants -- anything from, "I'll take
>anything" to "keep an eye out for this widget". I have no idea what he
wants
>for all of this, bit I doubt he's out to gouge.
>
>manney(a)hmcltd.net
>pgphoto(a)ragemail.com
>
>P Manney
>"Y1K caused the Dark Ages."
>Thousands of discounted photo items at http://www.hmcltd.net/pgphoto
>-----Original Message-----
>From: Colan Mitchell <cdrmool(a)interlog.com>
>To: Discussion re-collecting of classic computers
><classiccmp(a)u.washington.edu>
>Date: Wednesday, May 26, 1999 4:37 PM
>Subject: confidential info on old harddrives.
>
>
>>
>>If this is a ? thats been dealt with before I joined the list my
>>apologies.
>> I repeatedly come across personal and confidential information on
>>discarded computers. I sit and shake my head in shock. Lawyers seem to
>>be the worst. I have considered contacting the original owners and
>>educating them about practicing safe hex but, especially in the case of
>>lawyers and women, don't want to have them freak out and think I'm being
>>weird and calling the police. On the other hand I feel that I should do
>>something. In the end I just format the drives and forget about it.
>> Has anyone experienced contacting an original owner? What was the
>>response. This is something that I've not read about in the media as Y2K
>>and Hackers get all the press but I suspect this is a bigger potential
>>problem.
>>
>>
>>Colan
>>
>>
>>
>>
>>
>
>
>At 02:27 AM 5/31/99 -0400, PG Manney wrote:
>>I have a friend (Yes, Virginia, I have two friends) who's been a DEC
>>repairman for many years. He now wants to get rid of the accumulated a lot
>>of stuff in his barn, and has asked me to help get rid of it.
>
>Obvious first question: Where is this barn?
Behind his house. Where else? <g> (couldn't resist that!)
In Northern Ohio, about halfway between Cleveland and Toledo. 44846 ZIP.
Tiny place called Milan.
<> Today I bought a SC/MP wirewrapped board. Does anyone know of a site with
<> data sheet? My search came up with what is known as "SC/MP II", including
I do have a massive amount of dat for the sc/mp Pmos part.
Allison
On May 30, 12:24, Allison J Parent wrote:
> Subject: Re: National SC/MP data
> <Hi all,
> <Today I bought a SC/MP wirewrapped board. Does anyone know of a site
with
> <data sheet? My search came up with what is known as "SC/MP II",
including
> <description of a "MK14" project in Practical Electronics mag. In
> <particular, the chip on my board requires an unknown neg. voltage on pin
> <40, instead of +5 Volts on the later NMOS versions. The actual part No.
is
> <ISP-8A/500D
A while ago, I found a website dealing with MK14 things at
http://members.aol.com/mk14emu/
It includes a copy of of the PE review.
> I have a working example of the inexpensive board national sold with that
> chip, 256bytes of ram and a monitor.
>
> I'd doubt there is a site with a data sheet unless someone got permission
> form National Semi to scan one.
The Introkit and the MK14 are very similar. The site I mentioned above has
part of the SC/MP data sheet, the MK14 circuit diagram and parts lists, and
programing information. Now all I need is the SC/MP chip.
Related topic: has anyone here come across a small micro called a Scrumpi,
based ob the SC/MP?
--
Pete Peter Turnbull
Dept. of Computer Science
University of York
