Obviously there has been a fair amount of 11/34a traffic today
what with the descriptions of the cache/fpu and CPU boards and
interconnects.
Armed with this info, I searched the documentation I got in the
haul and found an 11/34a printset. I also did find 1) the
FP11 floating point, 2) the cache, and 3) the two over-the-board
connectors which would allow me to connect them to the CPU.
First step was cleaning the BA box. I removed all backplanes with
the exception of the primary DD11-PK backplane. The other backplanes
were the VT11 without a power harness, and an RH11 backplane.
I removed all the boards from the primary backplane (noting where
they went). I then vacuumed the backplane, removing all sorts of
dust and particulate matter, including what appeared to be
degraded foam padding, which fell apart if I tried to pick it up.
With the backplane as clean as I could make it, I checked the
wiring harness and the backplane pins, sighting along the rows and
columns looking for any bent pins. Fortunately I didn't find any.
So the next step was to apply some power. The power controller in
the bottom of the rack did not have a normal 115vac plug on it, so
I plugged the BA box into the unswitched side of the power controller
I have in the bottom of my 11/10. I tried the front panel switch...
nothing... Whoops, forgot the circuit breakers in the back of the
BA box. I switched those on, turned the front panel switch and I
got DC OK light, and the power supply fans ran (I'd forgotten how
noisy they are with the skins off the box).
Power off... next step was adding the boards to the backplane,
one at a time. With each board, I lengthened the amount of time
I left the unit on doing the smoke test... (checking for any
whisps of the magic smoke which makes electrical things work :-)
I finally had the CPU (two boards), memory (MS11-LD, 128kw, 256kb)
the programmers console interface, a serial line, the boot board
and a bus terminator in the backplane. With power applied, I
finally had the programmer's console displaying something. But
when I tried to do stuff, the bus appeared hung. I turned the
machine off and thought about it... 'oh yeah, I forgot the
bus grant cards"...
With bus grant cards in, it powered up just fine and I entered a
few simple code fragments (actually single instructions) just to
see if it would work.
First test was a simple branch to self:
1000/777
started it, and it ran.
Next, a memory clearing routine...
0/15740
15740/0
R0/160000
start at 0, it ran briefly and halted with 000002 in the display.
Just as expected... memory was clear...
At this point I got a little daring and moved boards around so
that I could install the FPU, the cache, and the FPU and cache
in successive attempts. Unfortunately it didn't work with any
of those two boards in it, so I restored it to the working
configuration.
Slot 1 - 11/34a data paths (ABCDEF)
Slot 2 - 11/34a control module (ABCDEF)
Slot 3 - boot board (EF), KY11LB console interface (ABCD)
Slot 4 - DL11-W (ABCD)
Slots 5-9 bus grant cards (D)
Slot 9 - Bus terminator (EF)
I then checked the address for the console interface, hoping that
the serial line unit (DL11-W) that I put in it was actually at
the console address, and it appears it was.
I then checked the amount of memory and found 124kw (248kb) as
expected.
So, bottom line is that the first day of real work was quite
successful. Next step will be to find the cable I need to attach
a terminal to see what sort of boot code is available. Then
I'll have to try putting the RUX50 in it, attach that to an
RX50 in a leprechaun box, use one of my qbus machines to build
an RT-11 bootable RX50, and actually try to boot this thing.
Megan Gentry
Former RT-11 Developer
+--------------------------------+-------------------------------------+
| Megan Gentry, EMT/B, PP-ASEL | Internet (work): gentry!zk3.dec.com |
| Unix Support Engineering Group | (home): mbg!world.std.com |
| Compaq Computer Corporation | addresses need '@' in place of '!' |
| 110 Spitbrook Rd. ZK03-2/T43 | URL: http://world.std.com/~mbg/ |
| Nashua, NH 03062 | "pdp-11 programmer - some assembler |
| (603) 884 1055 | required." - mbg |
+--------------------------------+-------------------------------------+
<It was always somewhat of a nuissance dealing with the Z-80 because of the
<way it presented its interrupt acknowledge, which was a combined I/O and M
<cycle, as long as the I/O cycle, but with M1. That meant, in my case, tha
All instuction fetch cycles were short, INTA cycle had an extry cycle added
for interrupt resolution in the supporting chips.
To get around the short M1 cucles I'd use a tiny bit of logit to stutter
the clock to the chip (slip a cycle) for M1 only. This results it running
generally faster and still using slower memory.
<This same protocol made it unwise to try to use memory mapped I/O, since th
<cycle length of an I/O cycle differed from that of a memory cycle.
I used to do it all the time and like I posted earlier the NS* disk system
used MM-IO very effectively.
Allison
<I said 'ROM' because on a number of machines, it was just a few TTL chips
<that gated C3, lobyte, hibyte onto the data bus on the first 3 fetches
<after reset.
Most used a mux and jumpers to fake a 3byte rom with the first byte
hardwired as C3h (jmp in 8080/8085/z80) and it was jammed on the bus for
boot and only then. another approach was to on power up map rom to loc 000
and also F800h and then disable the mapping after the code was running up
high. Plenty of tricks to fake that.
Allison
Anyone have a spare IBM 4869 floppy drive? Power supply died in mine.
I'm also looking for an external floppy from a TRS-80 (w/PS). Doesn't need
to have a drive.
--
-Jason Willgruber
(roblwill(a)usaor.net)
ICQ#: 1730318
<http://members.tripod.com/general_1>
<I guess it's fortunate there was only one DMA process going on at the time
<else it might have been real sticky figuring out what had been overwritten
<already.. If you were doing a read in order to do a write, using DMA, you
<might actually get tangled up. Fortunately that showed up while the vendo
<was debugging his code, so I didn't have to deal with that.
Multiple DMA streams are doable too though hard to apply usefully.
<That's quite so. Fortunately one wasn't required to load data at the
<granule size, but rather at the sector size, so you could get by with a rea
<of a 1K sector. Of course you had to read it before you could write it, s
<you had to wait for the next revolution of the disk. All this went by so
<fast, and, since I didn't run big databases requiring sorts to and from
<disk, I didn't perceive much delay, as it only takes a few revolutions to
<load up a program. So each drive had six logical drives on it.
I have. Running a pair of drives and using ramdisk and my own smartdisk
system. That was the speed order as well, the smartdisk system was fasest
as it hard its own CPU and DMA channel to processor ram using hidden cycle
stealing plus caching to 4x physical track size. That and a 6MHz z80 and
dust flew.
<This all sounds like it could be fun if, for example, you're running it al
<on classic and unmodified hardware. I'm not sure I'd want to try to earn m
<living that way, though.
it's more fun on current hardware like 33mhz Z180s and it's still in use
in odd pockets here and there. I don't (never did) make a living off it.
Allison
Please see comments imbedded below.
Dick
-----Original Message-----
From: Arfon Gryffydd <arfonrg(a)texas.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, March 30, 1999 11:59 AM
Subject: Re: Computer busses....
>>You've hit most of the important signals. One I'd add, however, is a data
>>bus disable, and perhaps an address bus disable as well. This would allow
a
>>front panel or other bus mastering device to steal cycles under certain
>>circumstances.
>
>Why wouldn't BUS REQUEST work?
>
It would only work if BUS REQUEST were not a request for negotiation. If
you do have a bus negotiation handshake, then it might not work simply to
asser BUS REQUEST because you may want to "jam" data in to certain locations
while the processor is doing most of the work. CPU places addresses on the
bus, you, by means of your front panel, want to put different data there.
You float his data bus, and drive it yourself while he creates the strobes
in his normal timing. Likewise, you might want to redirect his data flow,
hence you float his address bus, driving it yourself, while the CPU
generates normally timed transaction control signals. It's an obscure point
but I've seen it done for whatever reason on several occasions.
>
>>What would you do with the HALT signal, and how would you implement it?
>
>WAIT sould act as a "pause and hold the bus in it's current condition"
>signal. Halt should mean "Stop what you are doing, release the control of
>the bus and wait until the HALT signal is removed". IMHO
>
Now this one seems like it could be accomplished with the BUS REQUEST
signal. I suppose it's arguable, but if you want control of the bus, and
want the processor to more or less disconnect himself from it, it would
require a signal to each processor/master on the bus. If the FP wants to
control the bus, it doesn't have to HALT the processor does it? It just
needs to seize the bus. Whether that stops the processor(s) would depend on
what's on the CPU card. It depends, of course, on whether you have multiple
master candidates on the bus. If not, it's moot, but if so, then you might
not want to halt them, but merely seize the bus for a moment.
>
>>There's some debate about how one should signal the beginning of a new bus
>>cycle. This should be at the earliest moment at which addresses are
stabile.
>
>I guess the RD/WR signals should be seperate and only applied AFTER all
>signals on the bus are stable.
>
As I mentioned before, it's quite critical to the operation of the bus, how
you time the WRITE signal. Many processors following the MOTOROLA model,
i.e. with a regular 2-phase clock, with one clock per bus cycle, tell you
when the cycle begins by asserting the "E" clock in the MOT case. If R/W is
true at the beginning, it's a read cycle, else R/W must be low, meaning it's
a write. Most of the older processors of this sort assert the WRITE state,
i.e. R/W LOW quite some time before the E clock (or phase 2) becomes true.
Nevertheless, the data is only held valid for a minimal time after the
falling edge of E, hence some steps have to be taken to hold the data for
some time after end of E so that the data will persist beyond the rising
edge of the nWR signal. On a 6800 or 6502, this is quite straightforward.
The CPU is fed a single phase clock, sometimes called phase 0. It produces
(in the case of the 6502) a pair of non-overlapping complementary clocks,
phase 1 and phase 2. The 6800 required you use a clock generator to produce
those and feed them to the CPU. You could still gate them with R/W to
create nRd and nWr signals, but the results were slightly different.
More recent processors don't give you the two clocks, so you don't have as
many options. Some give you both an address strobe and a data strobe, from
which you can derive appropriately timed nRD and nWR strobes. These often
are needlessly short, however, leaving valuable bus bandwidth unused.
I think a less conservative though still correct approach would be to limit
your statement to signals other than data. Most peripherals require only
that the data be stabile on the trailing edge of the write command. It's
likewise with memories, so I think that's a safe approach. There are
exceptions, though, but I hope they're dead forever.
Dick
>
>----------------------------------------
> Tired of Micro$oft???
>
> Move up to a REAL OS...
>######__ __ ____ __ __ _ __ #
>#####/ / / / / __ | / / / / | |/ /##
>####/ / / / / / / / / / / / | /###
>###/ /__ / / / / / / / /_/ / / |####
>##/____/ /_/ /_/ /_/ /_____/ /_/|_|####
># ######
> ("LINUX" for those of you
> without fixed-width fonts)
>----------------------------------------
>Be a Slacker! http://www.slackware.com
>
>Slackware Mailing List:
>http://www.digitalslackers.net/linux/list.html
By all means if you can get a shot at it do it, get them all.
I would be interested in a complete set of each:)
Francois
>Having said that, I did see a good amount of Model 100s and their
>accessories (disk drives, manuals) and a couple of other Tandy things
>(cassette recorders). Is any of this especially rare? Some machines might
>be model 102s, since I saw the 102 tecnical manual. It would be a fair
>amount of effort to get everything; I might be able to convince the surplus
>people to make the Tandy stuff their own lot, but I'm not optimistic about
>that.
>
>-- Derek
>
You've hit most of the important signals. One I'd add, however, is a data
bus disable, and perhaps an address bus disable as well. This would allow a
front panel or other bus mastering device to steal cycles under certain
circumstances.
What would you do with the HALT signal, and how would you implement it?
There's some debate about how one should signal the beginning of a new bus
cycle. This should be at the earliest moment at which addresses are
stabile.
If you have separate strobes for memory and I/O, then either of them could
do it, or if you generate separate strobes for read and write, that could
work as well. The question comes up, however, of how to generate the write
strobe, which is often shorter than the read signal from the processor, if
there is a separate read strobe at all. On a read, it's generally desirable
to time the read strobe so the strobe at the processor goes away, signalling
that the data has been sampled, before the memory or I/O device is disabled,
making the data go away. Likewise, it's desirable to make the write strobe
during processor write cycle go away before its data becomes invalid at the
target. What's more, some peripherals don't like having data change once a
write cycle begins, so it's necessary to have valid data before signalling a
write. This is complicated by the fact that some processors initiate a
write cycle before the data is valid, while others do not. Many schemes for
generating these signals end up making the processor operate relatively
slowly with respect to the memory bandwidth in order to satisfy these
conditions. Circuits which latch the data or otherwise fiddle with the
cycle length in order to avoid slowing the processor down will increase the
parts count and complicate the timing, while those that accomplish this fit
by using faster memories and peripherals will cost more due to the higher
and not as effectively used bus bandwidth.
If you'll start with the model you've suggested, consider the types of
devices you anticipate attaching to the bus, and decide how each can be
accomodated, you'll eventually settle on a good approach.
Dick
-----Original Message-----
From: Arfon Gryffydd <arfonrg(a)texas.net>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, March 30, 1999 9:49 AM
Subject: Computer busses....
>Anyone have any idea what was/is the best bus design?
>
>I'm thinking a stripped down Z-bus (without the M1 signal and etc). What
>else should be on a bus besides:
>
>ADDRESS
>DATA
>RD/WR
>MEM/IO
>BUS REQ
>BUS ACK
>INT
>INT ACK
>WAIT
>HALT
>RESET
>CLOCK
>
>
>----------------------------------------
> Tired of Micro$oft???
>
> Move up to a REAL OS...
>######__ __ ____ __ __ _ __ #
>#####/ / / / / __ | / / / / | |/ /##
>####/ / / / / / / / / / / / | /###
>###/ /__ / / / / / / / /_/ / / |####
>##/____/ /_/ /_/ /_/ /_____/ /_/|_|####
># ######
> ("LINUX" for those of you
> without fixed-width fonts)
>----------------------------------------
>Be a Slacker! http://www.slackware.com
>
>Slackware Mailing List:
>http://www.digitalslackers.net/linux/list.html
It was always somewhat of a nuissance dealing with the Z-80 because of the
way it presented its interrupt acknowledge, which was a combined I/O and M1
cycle, as long as the I/O cycle, but with M1. That meant, in my case, that
I had to insert a wait state in the M1 cycle in order to avoid having to use
much faster RAM, since the M1 signal appeared before either the IORQ or the
MEMRQ signals. By either synchronizing the resulting signal with the clock,
thereby eliminating the glitch, or by waiting for either of these two
steering signals, the resulting cycle was too short. By that I mean that it
was almost an entire clock period shorter than the normal M1 cycle would
have been, had I been able to ignore the IACK protocol in the Z-80
peripheral devices. I was stuck with them as a result of decisions already
made. <sigh>
This same protocol made it unwise to try to use memory mapped I/O, since the
cycle length of an I/O cycle differed from that of a memory cycle.
Dick
-----Original Message-----
From: Tony Duell <ard(a)p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp(a)u.washington.edu>
Date: Tuesday, March 30, 1999 2:20 PM
Subject: Re: Rebirth of IMSAI
>> >One of the problems with the S100 bus is that it is _very_ dependant on
>> >the 8080 signals. Even using a Z80 is a bit of work - things like PINTE
>> >(which indicates if interrupts are enabled) and SSTACK (address lines
>> >contain the value of the stack pointer) don't exist as external signals
>> >on the Z80.
>> >
>> Of course if you wire your own Z-80, you can ignore most of the weird
>> signals if you are using static ram. Just use a memory write signal for
>> writes, and another to gate read data onto the buss.
>
>True, until you find you have some strange (commercial) card that depends
>on one of these signals for some strange reason. I know that many
>commercial Z80 CPU boards did have extra logic at least for PINTE.
>
>> There is nothing in the Z-80, etc. to prevent you from using memory
mapped
>
>-tony
>
