RE: Wanted: HP7970 hub mech

[CuriousMarc via cctalk]

I didn't even know there was such a thing as a twist to tighten on the HP7970. 
On the 7970A maybe?
Marc

-Original Message-
From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck Guzis 
via cctalk
Sent: Sunday, November 19, 2017 7:32 PM
To: CCtalk
Subject: Wanted: HP7970 hub mech

This is a pretty far-fetched request, but here goes.

The quick-release levers on the HP 7970 tape drive are plastic.
They're starting to get brittle.  I've got one that's showing cracks, so I 
swapped it the the one on the takeup reel, as that one doesn't see as much 
action as the one on the supply reel.

What I'd really like to find is the older twist-to-tighten mechanisms on the 
7970.  I suppose I can get busy in my shop and make some, but I'm wondering if 
there are any lurking in someone's hell box.

Thanks for reading!
Chuck

Re: Ideas for a simple, but somewhat extendable computer bus

[alan--- via cctalk]

If you ever look at how interrupts are implemented on STD bus, you'll 
run in fear.  There are only two options, chain the slot to slot 
interrupt line (assuming all slots are filled downstream of the CPU) and 
share the one request signal - implementing any CPU-specific interrupt 
requirements like an vector placement for x86 - or you can home run IRQ 
lines independently of the STD bus signals.  Most cards did the later or 
just put all peripherals that will ever need IRQs on the CPU card 
itself.


STD bus is pretty antiquated.

-Alan


On 2017-11-20 00:54, Chuck Guzis via cctalk wrote:

On 11/19/2017 08:11 PM, Ken Seefried via cctalk wrote:


More importantly, the vast number of compatible I/O cards that were
produced.  Much alternative history to be pondered.


So we agree on parallel standard buses, that STD bus is a strong
contender with varied processor base.

There *is* STD32, but it's a bit of an abomination, like EISA.  It
extends the bus to 32 bits and retains compatibility with 8-bit STD.
But there's a price to be paid--special connectors (like EISA) and more
complex interfacing logic (to accommodate the older STD).

Finally, it's pretty much a sole-source standard--Ziatech came out with
it, and to the best of my knowledge, is the only firm that ever 
produced

STD32 cards.

--Chuck

Re: Ideas for a simple, but somewhat extendable computer bus

[Chuck Guzis via cctalk]

On 11/19/2017 08:11 PM, Ken Seefried via cctalk wrote:

> More importantly, the vast number of compatible I/O cards that were
> produced.  Much alternative history to be pondered.

So we agree on parallel standard buses, that STD bus is a strong
contender with varied processor base.

There *is* STD32, but it's a bit of an abomination, like EISA.  It
extends the bus to 32 bits and retains compatibility with 8-bit STD.
But there's a price to be paid--special connectors (like EISA) and more
complex interfacing logic (to accommodate the older STD).

Finally, it's pretty much a sole-source standard--Ziatech came out with
it, and to the best of my knowledge, is the only firm that ever produced
STD32 cards.

--Chuck

Re: Ideas for a simple, but somewhat extendable computer bus

[Ken Seefried via cctalk]

I've always thought STD-Bus missed a real opportunity here.  Small
enough to be cost effective (relative to the size of, say, S-100
(bonus, no stupid power supply issues)), sane, flexible enough bus
structure that I believe there are at least CPU cards using:

- 4004/4040 (pre-standard?)
- 8080/8085/Z-80 and the myriad of variants
- 8088/8086/80188/10186 through at least 80486, including variants and
second sources
- 8048/8051 and the vast numbers of variants
- 8096/8097 and variants
- 6800 and variants
- 68HC11 and variants
- 6809/6309
- 6502 and variants
- 68xxx and variants up to at least the 68040 and 68332
- TMS9900/9995
- RCA 1802
- Signetics 2650
- Novix Forth

More importantly, the vast number of compatible I/O cards that were
produced.  Much alternative history to be pondered.

KJ

Re: Ideas for a simple, but somewhat extendable computer bus

[Eric Smith via cctalk]

On Nov 19, 2017 7:18 PM, "allison via cctalk"  wrote:

The rest is the specific implementation.  What happens if the CPU is
1802 or something else that does not match the 6500 or 8080z80 models.


There is nothing that prevents either the serial or parallel arbitration
schemes from working with other processors.

In the case of the 1802, it would work easily for interrupts, but would
need some additional circuitry for DMA, because the 1802 doesn't include
any feature whereby another bus master can request that the 1802 surrender
control of the bus. Instead, the 1802 has a built-in single-channel DMA
controller.

That 1802 bus master problem exists for interfacing _any_ sort of bus
master to any 1802, and is totally independent of what kind of DMA
arbitration is chosen.

Re: Ideas for a simple, but somewhat extendable computer bus

[allison via cctalk]

On 11/19/2017 08:54 AM, Noel Chiappa via cctalk wrote:
> > From: Allison
>
> > simple 16 data, 24 address likely 6 lines for basic control plus others
> > your up to 50+ lines
>
> I would seriously consider shared data/address lines, like on the QBUS. It
> doesn't add _that_ much complexity to share the lines (I did a slave device
> using only 74xxx parts, and it was dead simple - probably a goal of the
> designers), and it will really drop the pin count. The speed impact is not
> too bad - on reads, where the address and data naturally happen at different
> times, it can be none.
>
>   Noel
QBUS is wrapped around a subset of PDP11 and the unique processors made
to fit it.
The problem is carries is every card has to demux the bus that has
hardware cost on
every card. if the CPU doesn't initially multiplex the CPU card carries
the weight of
creating that muxed bus.    Dec had a full set of unique devices to do this.
I may add that things like PDP-11 with read before write adding its own
special set
of issues for peripherals.

The problem with multiplexed buses is speed cost.  You have to use fast
parts that are
compatible with the bus levels and the bus may have to be artfully
constructed to avoid
issues that occur when operating at high speed.   The other is how do
you multiplex
for example look and devices like 8085, 8088, z80 and 6502 the timing
overheard  is different
and the bus could even contradict something like the 8085/8088 which is
already multiplexed.

The bottom line is for every bus you have to get on and off with devices
to buffer and
possibly latch signals.  The more you  use the less card there is for
other things
and likely the mode complex the card and its related timings will be.

Its s solution when pins and their cost is more important that logic. 

The old saw Speed, quality, price pick any two applies.  Added complexity
will add cost or slow development and maybe even add bugs.


Allison

Wanted: HP7970 hub mech

[Chuck Guzis via cctalk]

This is a pretty far-fetched request, but here goes.

The quick-release levers on the HP 7970 tape drive are plastic.
They're starting to get brittle.  I've got one that's showing cracks, so
I swapped it the the one on the takeup reel, as that one doesn't see as
much action as the one on the supply reel.

What I'd really like to find is the older twist-to-tighten mechanisms on
the 7970.  I suppose I can get busy in my shop and make some, but I'm
wondering if there are any lurking in someone's hell box.

Thanks for reading!
Chuck

Re: Ideas for a simple, but somewhat extendable computer bus

[allison via cctalk]

On 11/19/2017 03:43 PM, Eric Smith via cctalk wrote:
> On Sat, Nov 18, 2017 at 10:48 PM, Jim Brain via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> Looking at the schematic for the ECB, I cannot find any description of the
>> signals BAI, BAO, IEI, and IEO.  Can anyone shed some light on the function
>> of these signals?
>>
> Bus Acknowledge In and Out, Interrupt Enable In and Out, used for serial
> arbitration of the bus request and interrupt.  These signals are
> daisy-chained rather than bused.
>
> If a any card is requesting the bus by asserting the bus request, at some
> point the CPU will acknowledge that by asserting its bus acknowledge
> output, which is wired to the BAI signal of the first bus slot. The BAO of
> each slot is wired to the BAI of the next slot.  Since more than one card
> can request the bus, it is necessary for there to be some arbitration
> scheme to determine which card gets the bus grant. In the serial
> arbitration scheme, the highest priority goes to the card that is earliest
> in the daisy chain (closest to the CPU).  If a particular card is NOT
> requesting the bus, it passes the BAI signal on to BAO to make the
> acknowledge available to the next card. If it is requesting the bus, it
> does not pass BAI to BAO, but instead sets BAO inactive, so that no
> lower-priority card will see the bus acknowledge.
>
> Similarly for how the card deals with interrupts, but using the IEI and IEO
> as the daisy chain.
>
> This is a common technique since the 1960s, and for microcomputers was used
> by Intel Multibus in 1975, and by Zilog Z80 family peripherals in 1976.
>
> The drawback is that if there are a lot of cards, there can be a long
> propagation delay of the interrupt acknowledge from the CPU to the last
> card of the bus, particularly if routing the IEI/IEO chain through NMOS Z80
> peripherals. 
That asumes z80 and a default bus master...  What if the CPU  is 6502 or
still other.


> That can cause no device to respond to the interrupt
> acknowledge with a vector by the time the CPU needs it.  This can be solved
> by adding wait states to the interrupt vector read, or by using a parallel
> arbitration scheme instead of serial.
It also assumes and interrupt vector read.  Not al cpus do that or it
can be
very implementation dependent.

Its not a what bus us better its what bus suits the system and matching CPU.

> Parallel arbitration can be done with the same slot pin assignments, but
> instead of busing the request and daisy-chaining the acknowledge, the
> requests are each separately fed into a priority encoder.  The "any" output
> of the encoder goes to the request input of the CPU.  The acknowledge from
> the CPU goes into the enable of a decoder, and the select inputs of the
> decoder come from the priority encoder, so that each slot gets its own
> decoded acknowledge signal to its BAI input.  In this case the backplane
> doesn't connect the BAO output of a slot to anything.   This parallel
> arbitration scheme can be used for bus request and/or interrupt request.
The rest is the specific implementation.  What happens if the CPU is
1802 or something else that does not match the 6500 or 8080z80 models.

Buses and systems are not software abstractions they are hardware
implementation
and often driven by the host CPU as well as over all system needs.  If
this wasn't true
why do so many different buses exist?

Allison

> Eric

Re: Looking for Silent 700 model 787 manual

[Chris Elmquist via cctalk]

On Sunday (11/19/2017 at 05:46PM -0800), Fred Cisin via cctalk wrote:
> On Sun, 19 Nov 2017, Chris Elmquist via cctalk wrote:
> >I recently acquired a TI Silent 700 model 787 terminal.  This cc 1980
> >unit is an interesting member of the Silent 700 family as it is capable
> >of 120 chars/sec printing and has an internal 300/1200 baud direct connect
> >modem that does Bell 103, Bell 212A and Vadic modulation in both originate
> >and answer modes.
> >It's a got a DB25 on the back for directly connecting serial but I don't
> >have any documentation on how to choose the internal modem vs the DB25
> >for comms or any pinouts for this DB25 outside the usual expectations
> >of RS232 on a DB25.
> 
> Some models of Silent 700 had a connector (I seem to remember it as maybe
> being DA-15?, instead of DB-25?) that permitted it to connect to external
> modem, AND permitted external devices to connect to the Silent 700 internal
> modem, or a loop back (defaulted to jumpered to that internally)
> ofconnecting the terminal to its modem.

Yes indeed.  I have several of those, model 745 as one example, and it
is a DA15 for which I have the pinout and made a cable for hooking to
various old micros here.

This 787 is a later generation with some noticable differences in the
connectoring, switches, LEDs, etc.   It is for sure a DB25 female and
below that, behind a flip-up cover, is an RJ11/13 (six pin) telephone
jack for the modem.

The unit is also taller/thicker than the 745 generation.  It's roughly
another inch thick with the extra bulk on the bottom.  At first I thought
it might be a model with bubble memory but it is not.  Instead, it's the
"go faster" model with 120cps rather than 30cps printing.

There is a flip-card instruction manual inside the paper door which does
reveal some keyboard commands to change the baud rate (up to 9600 bps)
and the modem modulation and answer vs originate but there are no clues
about how to select modem or serial port or other more hardware specific
things.

Will be on the hunt for a service manual now.  I have such for both my
1st (model 725) and 2nd (model 745) generation units so might as well
get one for this beast too.

Chris
-- 
Chris Elmquist

Re: Looking for Silent 700 model 787 manual

[Fred Cisin via cctalk]

On Sun, 19 Nov 2017, Chris Elmquist via cctalk wrote:

I recently acquired a TI Silent 700 model 787 terminal.  This cc 1980
unit is an interesting member of the Silent 700 family as it is capable
of 120 chars/sec printing and has an internal 300/1200 baud direct connect
modem that does Bell 103, Bell 212A and Vadic modulation in both originate
and answer modes.
It's a got a DB25 on the back for directly connecting serial but I don't
have any documentation on how to choose the internal modem vs the DB25
for comms or any pinouts for this DB25 outside the usual expectations
of RS232 on a DB25.


Some models of Silent 700 had a connector (I seem to remember it as maybe 
being DA-15?, instead of DB-25?) that permitted it to connect to external 
modem, AND permitted external devices to connect to the Silent 700 
internal modem, or a loop back (defaulted to jumpered to that internally) 
ofconnecting the terminal to its modem.

Looking for Silent 700 model 787 manual

[Chris Elmquist via cctalk]

I recently acquired a TI Silent 700 model 787 terminal.  This cc 1980
unit is an interesting member of the Silent 700 family as it is capable
of 120 chars/sec printing and has an internal 300/1200 baud direct connect
modem that does Bell 103, Bell 212A and Vadic modulation in both originate
and answer modes.

It's a got a DB25 on the back for directly connecting serial but I don't
have any documentation on how to choose the internal modem vs the DB25
for comms or any pinouts for this DB25 outside the usual expectations
of RS232 on a DB25.

Seeking any documentation that might be around.  Happy to cover copying
costs or purchase a manual if it is excess to someone's needs.

Chris
-- 
Chris Elmquist

Re: LA30 parts and question

[Fritz Mueller via cctalk]

Hi all, an update on the sourcing questions below:

> On Nov 11, 2017, at 5:53 PM, Fritz Mueller  wrote:
> 
> I noticed that a few of the thin steel ribbon springs in the paper path are 
> missing or broken on my unit, and some of the rubber bushings have hardened 
> and deteriorated.  Long shot ask, but wondering if anybody out there has 
> spares of:
> 
>74-08648   (Spring, paper drag)
>12-10357-3 (Bushing, rubber mount)
>12-10358-3 (Ring, rubber mount)
> 
> Also, the maintenance manual recommends Molykote B2KR for lubrication in a 
> few places, but I can't seem to find specs on what this was.  Can anybody 
> recommend an equivalent modern alternative grease?

For the paper drag springs, I ended up just fashioning some replacements from 
some .002 steel shim stock (easy enough; just some 1/2” x 3” strips with holes.)

For the bushing and rings, these have the right dimensions and look very close 
to the original parts:

http://www.vibrationmounts.com/RFQ/VM07003.htm

I’ll probably order some of these up to replace the decaying mounts for the 
carriage assembly. I ended up just using some inexpensive 3/8” chassis grommets 
for the more straightforward end stop bumpers.

For the grease, which is called out for the carriage loading cams and a couple 
of linkage pins/pivots, I opted for Molykote BR2 Plus, though I suppose any 
decent lithium grease would work okay here?

Overall, I have been pretty amazed by the sheer number of machined parts, 
castings, high quality bearings, etc. within this beast.  Lots of stainless 
steel throughout.  Sure wouldn’t find anything built this way these days!  What 
a tank.

cheers,
  --FritzM.

  

Re: Ideas for a simple, but somewhat extendable computer bus

[ben via cctalk]

On 11/18/2017 5:57 PM, Eric Christopherson via cctalk wrote:

On Fri, Nov 17, 2017, ben via cctalk wrote:

On 11/17/2017 6:59 PM, Chuck Guzis via cctalk wrote:

On 11/17/2017 05:34 PM, Jim Brain via cctalk wrote:


It does not have to be fast.  I rather thought, "what is the simplest
multi-cpu shared bus that could be easily understood by folks and allow
them to focus on multi-processing education, not bus understanding"


How about a serial bus?  Physically simple and not too awful logically
today.  Say, I2C or SPI...

--Chuck


Say USB-version 101101100 :)


Sorry to be dense, but are you referring to some actual USB version? Or
did you mean something like "one of the many USB versions, some not yet
released"? (101101100 is 364 in binary, but I don't see the significance
of that.)

As FOGHORN LEGHORN once said.
“That’s a joke, I say that’s a joke son”

Re: Slightly OT: Computer internals book recommendations

[ben via cctalk]

On 11/19/2017 12:29 AM, Huw Davies via cctalk wrote:




On 19 Nov 2017, at 10:57, Eric Christopherson via cctalk 
 wrote:

Basically, I'm looking for a certain book (although really any book in
the same vein would satisfy), which was on computer system architecture,
organization, etc.; it talked about the usual boolean logic, assembly
programming in some fictitious instruction set, an overview of two
actual architectures (I think at that time they were 32-bit x86 and
64-bit POWER). The other thing I remember very specifically was there
was a place near the back (probably an appendix) that talked about
one or more specific buses (I think at least PCI was there), with timing
diagrams to tell you what was actually going back and forth between the
bus and CPU.



Sounds like either

Computer Architecture: A Quantitative Approach by David Patterson and John 
Hennessy

Computer Organization and Design: the Hardware/Software Interface by David 
Patterson and John Hennessy

I see there’s a MIPS edition of the second book. My copy of the second book has 
Hennessy as the first author.

Time for a re-read - it’s been a while since I read both of them.

Huw Davies   | e-mail: huw.dav...@kerberos.davies.net.au
Melbourne| "If soccer was meant to be played in the
Australia| air, the sky would be painted green"


Is the first editon of the second book not MIPS? I want to read a book 
on stuff when the book was written, not the latest FAD or current 
marketing GIMMIC.

Ben.

Re: Ideas for a simple, but somewhat extendable computer bus

[Jim Brain via cctalk]

On 11/19/2017 2:43 PM, Eric Smith wrote:


Similarly for how the card deals with interrupts, but using the IEI 
and IEO as the daisy chain.
Thanks for the context.  I think the fact that !BUSAK is present on A31 
threw me


https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=boards:ecb:backplane-3:backplane.pdf

and the fact that I don't see that the ECB routes BUSAK from the CPU 
card to BAI of the first slot




Parallel arbitration can be done with the same slot pin assignments, 
but instead of busing the request and daisy-chaining the acknowledge, 
the requests are each separately fed into a priority encoder.  The 
"any" output of the encoder goes to the request input of the CPU.  The 
acknowledge from the CPU goes into the enable of a decoder, and the 
select inputs of the decoder come from the priority encoder, so that 
each slot gets its own decoded acknowledge signal to its BAI input.  
In this case the backplane doesn't connect the BAO output of a slot to 
anything.   This parallel arbitration scheme can be used for bus 
request and/or interrupt request.
I like this idea better.  Is there any implementation docs you might 
suggest? (I have the Bus Handbook on order, but it has not arrived)


I also am unclear on how ECB handles dual CPUs, if it does at all.

Jim


Eric



--
Jim Brain
br...@jbrain.com
www.jbrain.com

Re: Ideas for a simple, but somewhat extendable computer bus

[Eric Smith via cctalk]

On Sat, Nov 18, 2017 at 10:48 PM, Jim Brain via cctalk <
cctalk@classiccmp.org> wrote:

> Looking at the schematic for the ECB, I cannot find any description of the
> signals BAI, BAO, IEI, and IEO.  Can anyone shed some light on the function
> of these signals?
>

Bus Acknowledge In and Out, Interrupt Enable In and Out, used for serial
arbitration of the bus request and interrupt.  These signals are
daisy-chained rather than bused.

If a any card is requesting the bus by asserting the bus request, at some
point the CPU will acknowledge that by asserting its bus acknowledge
output, which is wired to the BAI signal of the first bus slot. The BAO of
each slot is wired to the BAI of the next slot.  Since more than one card
can request the bus, it is necessary for there to be some arbitration
scheme to determine which card gets the bus grant. In the serial
arbitration scheme, the highest priority goes to the card that is earliest
in the daisy chain (closest to the CPU).  If a particular card is NOT
requesting the bus, it passes the BAI signal on to BAO to make the
acknowledge available to the next card. If it is requesting the bus, it
does not pass BAI to BAO, but instead sets BAO inactive, so that no
lower-priority card will see the bus acknowledge.

Similarly for how the card deals with interrupts, but using the IEI and IEO
as the daisy chain.

This is a common technique since the 1960s, and for microcomputers was used
by Intel Multibus in 1975, and by Zilog Z80 family peripherals in 1976.

The drawback is that if there are a lot of cards, there can be a long
propagation delay of the interrupt acknowledge from the CPU to the last
card of the bus, particularly if routing the IEI/IEO chain through NMOS Z80
peripherals.  That can cause no device to respond to the interrupt
acknowledge with a vector by the time the CPU needs it.  This can be solved
by adding wait states to the interrupt vector read, or by using a parallel
arbitration scheme instead of serial.

Parallel arbitration can be done with the same slot pin assignments, but
instead of busing the request and daisy-chaining the acknowledge, the
requests are each separately fed into a priority encoder.  The "any" output
of the encoder goes to the request input of the CPU.  The acknowledge from
the CPU goes into the enable of a decoder, and the select inputs of the
decoder come from the priority encoder, so that each slot gets its own
decoded acknowledge signal to its BAI input.  In this case the backplane
doesn't connect the BAO output of a slot to anything.   This parallel
arbitration scheme can be used for bus request and/or interrupt request.

Eric

Re: Sync on Green RGB video

[Marco Rauhut via cctalk]

I have the same problem with a cheap 19" LCD VGA Screen. What i made is 
to seperate the required sync signal with an LM1881 Video Sync 
Seperator. I used the standard application from the TI datasheet.The 
only difference is that i used an viariable resistor on pin 6 to adjust 
to the Sync Frequency. That is running with my Vax Station 4000 / 60.


Marco Rauhut


Am 19.11.2017 um 04:57 schrieb Douglas Taylor via cctech:

On 11/18/2017 6:44 PM, william degnan wrote:



On Nov 18, 2017 4:09 PM, "Douglas Taylor via cctech" 
> wrote:

>
> I have a couple of vaxes that output 'unique' video, Alpha 3000 
300, Alpha 3000 400, Vax 4000 VLC, and Vax Station 3100 M76.

>
> The Alpha and VLC each have a 3W3 type of connector and the 3100 
has a 15 pin DEC designed connector.

>
> What does it take to connect these to inexpensive, modern VGA light 
weight monitors?

>
> Doug
>

I have played around with that problem.  If you have a converter to 
get into a VGA port a newer high-end vga display will be able to 
adjust, but not a cheap one.  Because I use my vice vga/digital 
display for mode stuff, I use a huge SGI color display for all of my 
3w3 outputting systems and I just switch the cable around.  If you 
could imagine 5 or 6 systems clustered around the one display.


I am sure someone here has a technical explanation, but in a nutshell 
the 3W3 world signal isn't the same as a standard vga and cheap vga 
displays can't handle the refresh rate.  Someone will prob. refine my 
answer but that's why you can't just stick an adapter on there.


Bill Degnan
twitter: billdeg
vintagecomputer.net 

I ran into a similar comment somewhere on the internet somewhere (it's 
a big place) that you had to make sure that the LCD monitor supported 
the H,V rates put out by the DEC video frame buffer.

Re: Sync on Green RGB video

[Douglas Taylor via cctalk]

On 11/18/2017 6:44 PM, william degnan wrote:



On Nov 18, 2017 4:09 PM, "Douglas Taylor via cctech" 
> wrote:

>
> I have a couple of vaxes that output 'unique' video, Alpha 3000 300, 
Alpha 3000 400, Vax 4000 VLC, and Vax Station 3100 M76.

>
> The Alpha and VLC each have a 3W3 type of connector and the 3100 has 
a 15 pin DEC designed connector.

>
> What does it take to connect these to inexpensive, modern VGA light 
weight monitors?

>
> Doug
>

I have played around with that problem.  If you have a converter to 
get into a VGA port a newer high-end vga display will be able to 
adjust, but not a cheap one.  Because I use my vice vga/digital 
display for mode stuff, I use a huge SGI color display for all of my 
3w3 outputting systems and I just switch the cable around.  If you 
could imagine 5 or 6 systems clustered around the one display.


I am sure someone here has a technical explanation, but in a nutshell 
the 3W3 world signal isn't the same as a standard vga and cheap vga 
displays can't handle the refresh rate.  Someone will prob. refine my 
answer but that's why you can't just stick an adapter on there.


Bill Degnan
twitter: billdeg
vintagecomputer.net 

I ran into a similar comment somewhere on the internet somewhere (it's a 
big place) that you had to make sure that the LCD monitor supported the 
H,V rates put out by the DEC video frame buffer.

Re: Ideas for a simple, but somewhat extendable computer bus

[Jim Brain via cctalk]

On 11/19/2017 9:08 AM, emanuel stiebler wrote:

On 2017-11-18 23:48, Jim Brain wrote:

> Looking at the schematic for the ECB, I cannot find any description of
> the signals BAI, BAO, IEI, and IEO.  Can anyone shed some light on the
> function of these signals?

Here again:

https://en.wikipedia.org/wiki/Europe_Card_Bus

I have some ECB documentation "somewhere", but I'm moving so it is in 
one of the 100s boxes somewhere :(


But the guys on the retrobrewcomputers can help you for sure.

And yes, I like ECB, it was small & simple, you still can get boards 
for it, and the DIN conectors I still use ...


I went there already, but the descriptions:


*BAI 1; BAO 1:* Bus Priority In; Bus Priority Out.

*IEI; IEO:* Interrupt Enable In; Interrupt Enable Out.


does not give much clue as to usage, especially as I see that the pins 
are unwired on the backplanes, and require ones to add jumpers to 
connect them.  I understand that they are used to "chain" boards 
toghether in some order, but how and why is left as an exercise for the 
reader.


I looked at each of the backplane schematics for guidance, as well as 
looking at various ECB cards (the interrupt card I thought would have 
more detail, but alas, not)


Jim


--
Jim Brain
br...@jbrain.com
www.jbrain.com

Re: Slightly OT: Computer internals book recommendations

[Sophie Haskins via cctalk]

I have the second edition (there appears to now be a third out!) but
re-reading the preface and "what's changed since the first edition" doesn't
seem to say what I remembered re: buses (namely, it says nothing at all).
It is possibly my professors were referring to a much earlier
course/textbook (or that I dreamed the whole thing!). CS: APP is still a
pretty useful book, but...not on this topic, it would seem.

(in the second edition, the only reference to buses is on a page where they
note that as of its publishing, buses are much more complicated and much
less exposed to programmers than they once were)

- Sophie

On Sun, Nov 19, 2017 at 1:10 PM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > From: Sophie Haskins
>
> > earlier editions of "Computer Systems: A Programmers Perspective"
> had a
> > bunch of discussions of buses etc .. but the edition I have
> explicitly
> > calls out that they felt like it wasn't important to have chapters on
> > anymore :(
>
> Well, that might not be the wrong call, _iff_ keeping them in would have
> increase the cost of the text-book for (poor) student...
>
> And for the rest of us, there's ABE for the earlier editions! :-) Which
> edition do you have, may I ask? Thanks!
>
> Noel
>

Re: Slightly OT: Computer internals book recommendations

[Noel Chiappa via cctalk]

> From: Sophie Haskins

> earlier editions of "Computer Systems: A Programmers Perspective" had a
> bunch of discussions of buses etc .. but the edition I have explicitly
> calls out that they felt like it wasn't important to have chapters on
> anymore :(

Well, that might not be the wrong call, _iff_ keeping them in would have
increase the cost of the text-book for (poor) student...

And for the rest of us, there's ABE for the earlier editions! :-) Which
edition do you have, may I ask? Thanks!

Noel

Re: Slightly OT: Computer internals book recommendations

[Sophie Haskins via cctalk]

I want to say that earlier editions of “Computer Systems: A Programmers 
Perspective” had a bunch of discussions of buses etc in addition to assembly, 
compilers, linking, etc. but the edition I have explicitly calls out that they 
felt like it wasn’t important to have chapters on anymore :(

> On Nov 19, 2017, at 2:29 AM, Huw Davies via cctalk  
> wrote:
> 
> 
> 
>> On 19 Nov 2017, at 10:57, Eric Christopherson via cctalk 
>>  wrote:
>> 
>> Basically, I'm looking for a certain book (although really any book in
>> the same vein would satisfy), which was on computer system architecture,
>> organization, etc.; it talked about the usual boolean logic, assembly
>> programming in some fictitious instruction set, an overview of two
>> actual architectures (I think at that time they were 32-bit x86 and
>> 64-bit POWER). The other thing I remember very specifically was there
>> was a place near the back (probably an appendix) that talked about
>> one or more specific buses (I think at least PCI was there), with timing
>> diagrams to tell you what was actually going back and forth between the
>> bus and CPU.
>> 
> 
> Sounds like either 
> 
> Computer Architecture: A Quantitative Approach by David Patterson and John 
> Hennessy
> 
> Computer Organization and Design: the Hardware/Software Interface by David 
> Patterson and John Hennessy
> 
> I see there’s a MIPS edition of the second book. My copy of the second book 
> has Hennessy as the first author.
> 
> Time for a re-read - it’s been a while since I read both of them.
> 
> Huw Davies   | e-mail: huw.dav...@kerberos.davies.net.au
> Melbourne| "If soccer was meant to be played in the
> Australia| air, the sky would be painted green" 
> 

Re: Ideas for a simple, but somewhat extendable computer bus

[emanuel stiebler via cctalk]

On 2017-11-18 23:48, Jim Brain wrote:

> Looking at the schematic for the ECB, I cannot find any description of
> the signals BAI, BAO, IEI, and IEO.  Can anyone shed some light on the
> function of these signals?

Here again:

https://en.wikipedia.org/wiki/Europe_Card_Bus

I have some ECB documentation "somewhere", but I'm moving so it is in 
one of the 100s boxes somewhere :(


But the guys on the retrobrewcomputers can help you for sure.

And yes, I like ECB, it was small & simple, you still can get boards for 
it, and the DIN conectors I still use ...

Re: Ideas for a simple, but somewhat extendable computer bus

[Noel Chiappa via cctalk]

> From: Allison

> simple 16 data, 24 address likely 6 lines for basic control plus others
> your up to 50+ lines

I would seriously consider shared data/address lines, like on the QBUS. It
doesn't add _that_ much complexity to share the lines (I did a slave device
using only 74xxx parts, and it was dead simple - probably a goal of the
designers), and it will really drop the pin count. The speed impact is not
too bad - on reads, where the address and data naturally happen at different
times, it can be none.

Noel