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
