31 Oct
2010
31 Oct
'10
2:52 p.m.
Hi,
Please let me know any outcome of this project, I also have some stacks, 8/L
and 8/e of unknown condition and would be some day in the situation to start
repair.
Thanks a lot, and much success!!
With best regards
Gerhard
-----Urspr?ngliche Nachricht-----
Von: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] Im
Auftrag von cctalk-request at classiccmp.org
Gesendet: Sonntag, 31. Oktober 2010 19:37
An: cctalk at classiccmp.org
Betreff: cctalk Digest, Vol 86, Issue 71
Send cctalk mailing list submissions to
cctalk at classiccmp.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.classiccmp.org/mailman/listinfo/cctalk
or, via email, send a message with subject or body 'help' to
cctalk-request at classiccmp.org
You can reach the person managing the list at
cctalk-owner at classiccmp.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cctalk digest..."
Today's Topics:
1. Re: Need to find parts 82S23 / 74S188 (Chuck Guzis)
2. Re: [OT]? Sun Ultra 60 (Zane H. Healy)
3. Re: Large geometry MFM drive testing (Chuck Guzis)
4. Re: [OT]? Sun Ultra 60 (Dave McGuire)
5. Re: [OT]? Sun Ultra 60 (Zane H. Healy)
6. Re: [OT]? Sun Ultra 60 (Alexandre Souza - Listas)
7. Re: [OT]? Sun Ultra 60 (Alexandre Souza - Listas)
8. Re: Need to find parts 82S23 / 74S188 (Alexandre Souza - Listas)
9. Re: CDC STAR was: Happy Birthday VAX 11/780 (influence of)
(Chuck Guzis)
10. Re: Need to find parts 82S23 / 74S188 (Eric Smith)
11. Re: cctalk Digest, Vol 86, Issue 68 (MikeS)
12. Re: Virtual memory (Johnny Billquist)
13. Re: Memory mapped I/O (Johnny Billquist)
14. Re: Repairing core memories.... (O. Sharp)
----------------------------------------------------------------------
Message: 1
Date: Sun, 31 Oct 2010 10:11:39 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: Need to find parts 82S23 / 74S188
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <4CCD40DB.19611.F4760 at cclist.sydex.com>
Content-Type: text/plain; charset=ISO-8859-1
On 31 Oct 2010 at 8:28, Glen Slick wrote:
Agreed!
math.
One comment, the older the OS the better, and OpenBSD is an option.
Cool! In the mean time plug in a serial terminal. The Ultra 60 is
one of the few Suns I've ever used a keyboard and mouse on, though I
typically used a PS/2 keyboard an mouse on mine. I have a Sun
adapter that allows that, and it works with a KVM. I've not gotten
any of my Sun HW set back up since we bought our house.
Sun HW and a couple SGI O2's are the only real exceptions to my rule
about not collecting UNIX HW. I used the Suns a lot as general
purpose workstations and servers at home. Either running Solaris, or
OpenBSD.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Photographer |
+----------------------------------+----------------------------+
| My flickr Photostream |
| http://www.flickr.com/photos/33848088 at N03/ |
------------------------------
Message: 3
Date: Sun, 31 Oct 2010 10:15:01 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: Large geometry MFM drive testing
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <4CCD41A5.8728.125D5A at cclist.sydex.com>
Content-Type: text/plain; charset=US-ASCII
On 30 Oct 2010 at 15:06, Steven Hirsch wrote:
Some of us would debate that. I personally think the Ultra 2 and the
Ultra 60 as two of Sun's greatest machines. They're practical to own,
and take processors that will make them fairly useful.
I agree that they're two of their best designs. I just think that
machines which are still pretty common in production environments, built
around a modern architecture, are hardly "classic computers". That's all.
One comment, the older the OS the better, and OpenBSD is an option.
...unless you want to use it for real work of course. (referencing
"older", not OpenBSD)
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------
Message: 5
Date: Sun, 31 Oct 2010 10:24:16 -0700
From: "Zane H. Healy" <healyzh at aracnet.com>
Subject: Re: [OT]? Sun Ultra 60
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>, General Discussion:
Message-ID: <p0624080bc8f35668b1fd(a)[192.168.1.157]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 1:19 PM -0400 10/31/10, Dave McGuire wrote:
We have a production system still running Solaris 2.6 at work. I was
thinking along the lines of the older the OS, the less cruft, and the
better on the older hardware. For the past few years I've typically
run Solaris 8 at home, though I have Solaris 10 on the SunBlade 1000.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Photographer |
+----------------------------------+----------------------------+
| My flickr Photostream |
| http://www.flickr.com/photos/33848088 at N03/ |
------------------------------
Message: 6
Date: Sun, 31 Oct 2010 15:32:37 -0200
From: "Alexandre Souza - Listas" <pu1bzz.listas at gmail.com>
Subject: Re: [OT]? Sun Ultra 60
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <053701cb7924$22bebc20$6600a8c0 at portajara>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=response
Sorry you all :o(
I always wanted to run solaris, now I have a chance :oD Internet
navigation in a BIG computer :oD
W00T! :oD Thanks a lot, Dave! :oD
Since it is SO offtopic, I'll direct my other questions directly to you
------------------------------
Message: 7
Date: Sun, 31 Oct 2010 15:34:28 -0200
From: "Alexandre Souza - Listas" <pu1bzz.listas at gmail.com>
Subject: Re: [OT]? Sun Ultra 60
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <053801cb7924$2451b830$6600a8c0 at portajara>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=response
This might very well be totally wrong, but I remember hearing about it
at the time, that Sun (who I believe was the ones to first implement
mmap()) bascially took the whole TOPS-20 concept and translated it to
Unix. A bit surprised no TOPS-20 hackers have spoken up yet... This was
around for a long time on the PDP-10 before this.
Not sure how it correlates timewise to CDC and the STAR though.
But no matter if Unix took it from TOPS-20 or not, there is no denying
that TOPS-20 had this a long time before it came to Unix.
Memory mapped files are kindof neat, but it's not I/O at all in one way.
After all, all you do is just leave the actual I/O to the virtual memory
system instead of doing it yourself. So it's not that the I/O is done in
any different way, it's just initiated by someone else.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
------------------------------
Message: 14
Date: Sun, 31 Oct 2010 14:22:35 -0400 (EDT)
From: "O. Sharp" <ohh at panix.com>
Subject: Re: Repairing core memories....
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <Pine.NEB.4.64.1010311349420.17597 at panix3.panix.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
On Sun, 31 Oct 2010, Jos Dreesen wrote:
On Sat, Oct 30, 2010 at 2:40 PM, Chuck Guzis
<cclist at sydex.com> wrote:
I have the Nat Semi DM74LS471 on the device list of my programmer, but
not the SN74S471. Any chance the programming algorithms are the same?
They probably are. Somewhere in the history of TI part numbers, they
changed some of the bipolar memories from the SN74xxx part number to
TBPxxx. I can't recall which way my parts are labeled, but they're
471s under the hood.
--Chuck
------------------------------
Message: 2
Date: Sun, 31 Oct 2010 10:12:31 -0700
From: "Zane H. Healy" <healyzh at aracnet.com>
Subject: Re: [OT]? Sun Ultra 60
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>, General Discussion:
Message-ID: <p06240808c8f34f3401a1(a)[192.168.1.157]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
At 12:06 PM -0400 10/31/10, Dave McGuire wrote:
The
bigger problem for me would be finding a programmer for these
things. ?I've got
a mess of SN74S471s and no way to program them. > On 10/31/10 6:35 AM, Alexandre Souza - Listas wrote:
Some of us would debate that. I personally think the Ultra 2 and the
Ultra 60 as two of Sun's greatest machines. They're practical to
own, and take processors that will make them fairly useful. I'm also
pretty fond of Sparc 20's.
My Ultra 60 has dual 450Mhz CPU's, it's far more practical than my
SunBlade 1000 (to much electricity used, and heat generated). My
only problem is I've never gotten a Copper GigE card.
Hmmm, is an Ultra 60 offtopic? :o)
WAY off-topic. Just got one
(eee!!!),
Cool! now what to do
with that?
Just about anything you can think of, except lots of floating point I could use a
keyboard and mouse from Sun, since I have none :(
Problem solved; I'll put a set in the box I'm packing up for you. All,
I'm trying to evaluate a pile of large MFM hard drives for
functionality. I'm attaching them to a WD-1006V-MM2 controller and
running Sprinrite 4 under DOS 6.0 (using a 486 EISA motherboard).
This works fine for drives with < 1024 cylinders, but I cannot seem to
remember (or figure out) how to surface-test drives with more
cylinders (e.g. Priam V185 with 1166).
The convention when the cylinder field overflows 10 bits is to use
the two high-order bits of the head field (that's why MFM, and for
that matter, IDE drives max out at 64 heads when non-LBA geometry is
used.).
--Chuck
------------------------------
Message: 4
Date: Sun, 31 Oct 2010 13:19:35 -0400
From: Dave McGuire <mcguire at neurotica.com>
Subject: Re: [OT]? Sun Ultra 60
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CCDA527.1050903 at neurotica.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/31/10 1:12 PM, Zane H. Healy wrote:
Hmmm, is an Ultra 60 offtopic? :o)
WAY off-topic. I'm also pretty fond of Sparc 20's.
As am I.
now what to do with that?
Just about anything you can think of, except lots of floating point math. One comment,
the older the OS the better, and OpenBSD is an option.
...unless you want to use it for real work of course.
(referencing "older", not OpenBSD) Hmmm, is an
Ultra 60 offtopic? :o)
WAY off-topic. now what to do
with that?
Just about anything you can think of, except lots of floating point
math. I could use a
keyboard and mouse from Sun, since I have none :(
Problem solved; I'll put a
set in the box I'm packing up for you. Sun HW and a couple SGI O2's are the only real
exceptions to my rule about
not collecting UNIX HW. I used the Suns a lot as
general purpose
workstations and servers at home. Either running Solaris, or OpenBSD.
My impossible dream is to get a SGI machine. Any of them. There is an
Ozone (or something like) in a surplus seller I know, but he asks just too
much money for it. Someday I'll get one :oD It is a pride and joy for me to
have a SGI machine on my desk :oD
------------------------------
Message: 8
Date: Sun, 31 Oct 2010 15:37:08 -0200
From: "Alexandre Souza - Listas" <pu1bzz.listas at gmail.com>
Subject: Re: Need to find parts 82S23 / 74S188
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <053901cb7924$25794840$6600a8c0 at portajara>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
I have the Nat Semi DM74LS471 on the device list of my
programmer, but
not the SN74S471. Any chance the programming algorithms are the same?
AFAIK the algorithm is the same, the only difference is in speed/fan out
------------------------------
Message: 9
Date: Sun, 31 Oct 2010 10:54:08 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: CDC STAR was: Happy Birthday VAX 11/780 (influence of)
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <4CCD4AD0.28674.362B3F at cclist.sydex.com>
Content-Type: text/plain; charset=US-ASCII
On 31 Oct 2010 at 8:21, Jerome H. Fine wrote:
Interesting!! I worked for CDC in Toronto from around
1972 to 1977 on
the local PL-50 program. IIRC, the PL-50 was a much slower version of
the STAR-100, but with the same instruction set. Initially, the goal
was to write an operating system.
I was part of the Sunnyvale mafia and worked with quite a number of
your Canadian co-workers. Anil and I later partnered up on the
FORTRAN compiler for the ETA-10. You probably remember that the PL-
50/STAR-65 met an unfortunate fate at the hands of the corporate
"leave nothing behind" people. I witnessed firsthand, the
destruction of the two STAR-1B systems a couple of years later. It
wasn't pretty--a dumpster, bolt cutters and large hammers. I saved a
heatsink from the power supply--there wasn't much else left intact.
I begged to be allowed to take the ROS stack from one system, but no
such luck. The stations were removed and sent back to Arden Hills.
--
I'm going from memory on this one, but there's some STAR literature
on bitsavers if you want to check my facts.
256 registers of 64 bits; if halfword mode was selected, the lower
128 were doubled and the upper 128 were inaccessible. Many registers
had special meanings, including program status, cycle timer and a few
others.
Internally, memory was fetched 512 bits ("Super word" or "sword";
really 544 bits with ECC included) and the vector pipes were 128 bits
wide (2 single-precision results per cycle).
An odd machine in that scalar operations were most decidedly RISC in
attitude. For example, there were only load and store register-
memory operations and one had to use 2 instructions (EX and ELEN) to
enter a full 64-bit immediate constant into a register. No stack or
auto-increment/decremet per se; subroutine linkage was done with a
sort of S/360-style LM-STM combo "swap" instruction that
simultaneously stored and loaded any number of registers. The
machine architecture itself was basically 3-address, so instructions
were either 32 bits or 64 bits in length.
Before an ECO ("Rev. R") was installed on all systems, all registers
could also be addressed as the lower 256 words of user memory address
space. This hugely complicated instruction scheduling and so it was
determined that it wasn't needed.
I know you guys used the RED OS, but we had to use STAR-OS from LLL
as our base in Sunnyvale. It was basically a message-passing OS with
a controller started by the job scheduler, which could have as many
controllees as desired. You could send a message up the chain, one
level, or to the top or broadcast to all controllees. I recall that
the termination message content was the characters "ALL DONE".
Regarding paging, I saw my share of DEADBEEF codes (was the STAR OS
the first to use this failure code?). At some point we went from a
demand-paging algorithm to a working-set one, but the stuff that the
pager had to keep track of made the code a nightmare. Jim Smith
suffered a lot on that thing. It didn't help that we had to scavenge
time on the customer systems at LLL or hop the "noon balloon" out of
San Jose to use the system at ADL.
One thing that I never got to try on the 100 was seeing how long a
maximum-length packed BCD divide would take. Given that the byte
instruction field lengths were 16 bits, it meant either 65K or 131K
digits...
One memory I have is being sent to Arden Hills in January during the
OPEC oil embargo and settling in for the night in the machine room at
ADL because it was warmer than my room at the Ramada.
I"d love to find someone who spent time on the TI ASC to compare
notes...
--Chuck
------------------------------
Message: 10
Date: Sun, 31 Oct 2010 11:07:43 -0700
From: Eric Smith <eric at brouhaha.com>
Subject: Re: Need to find parts 82S23 / 74S188
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CCDB06F.9090905 at brouhaha.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/31/2010 10:11 AM, Chuck Guzis wrote:
On 31 Oct 2010 at 8:28, Glen Slick wrote:
True, but it has absolutely *nothing* to do with whether a National
Semiconductor DM74LS471 uses the same programming algorithm and
electrical parameters as the SN74S471. They might, but it was not
uncommon for different vendors to have parts that did NOT program in the
same way. They often did their own designs, with different types of
fuses and materials, requiring different programming parameters.
Eric
------------------------------
Message: 11
Date: Sun, 31 Oct 2010 12:47:06 -0500
From: "MikeS" <dm561 at torfree.net>
Subject: Re: cctalk Digest, Vol 86, Issue 68
To: <cctalk at classiccmp.org>
Message-ID: <8021827792C6419AB1C1B7613E954423 at vl420mt>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
----- Original Message -----
From: <cctalk-request at classiccmp.org>
To: <cctalk at classiccmp.org>
Sent: Saturday, October 30, 2010 4:18 PM
Subject: cctalk Digest, Vol 86, Issue 68
On Sat, Oct 30, 2010 at 2:40 PM, Chuck
Guzis<cclist at sydex.com> wrote:
I have the Nat Semi DM74LS471 on the device list of my programmer, but
not the SN74S471. Any chance the programming algorithms are the same?
They probably are. Somewhere in the history of TI part numbers, they
changed some of the bipolar memories from the SN74xxx part number to
TBPxxx. I can't recall which way my parts are labeled, but they're
471s under the hood.
The
bigger problem for me would be finding a programmer for these
things. I've got a mess of SN74S471s and no way to program
them.>
Send cctalk mailing list submissions to
cctalk at classiccmp.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.classiccmp.org/mailman/listinfo/cctalk
or, via email, send a message with subject or body 'help' to
cctalk-request at classiccmp.org
You can reach the person managing the list at
cctalk-owner at classiccmp.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cctalk digest..."
Today's Topics:
1. Re: Happy Birthday VAX 11/780 (influence of) (Chuck Guzis)
2. Re: TTL HEX LED driver chip (Chuck Guzis)
3. Re: TRS-80 Model II Manuals (Fred Jan Kraan)
4. Re: DiscFerret: First working hardware, firmware and
microcode! (Philip Pemberton)
5. Re: TRS-80 Model II Manuals (Tony Duell)
6. Re: TRS-80 Model II Manuals (Chuck Guzis)
7. Re: DiscFerret: First working hardware, firmware and
microcode! (Dave McGuire)
8. Re: Happy Birthday VAX 11/780 (influence of) (Dave McGuire)
9. Re: DiscFerret: First working hardware, firmware and
microcode! (Philip Pemberton)
10. Re: TTL HEX LED driver chip (Brent Hilpert)
11. Re: Happy Birthday VAX 11/780 (influence of) (Brent Hilpert)
12. Fall cleaning, some small machines for free (Bob Rosenbloom)
13. Re: DiscFerret: First working hardware, firmware and
microcode! (Chuck Guzis)
14. Need to find parts 82S23 / 74S188 (alan canning)
15. Re: Happy Birthday VAX 11/780 (influence of) (Chuck Guzis)
16. Re: DiscFerret: First working hardware, firmware and
microcode! (Philip Pemberton)
17. Re: TTL HEX LED driver chip (Tony Duell)
18. Re: Nuclear Data ND 6600 (Tony Duell)
19. Re: TRS-80 Model II Manuals (Tony Duell)
20. Re: TTL HEX LED driver chip (Tony Duell)
21. Re: TTL HEX LED driver chip (Tony Duell)
22. Re: Wanted : Monitor Capable of TTL RGB (Tony Duell)
23. Re: I/O models (was RE: Happy Birthday VAX 11/780 (influence
of)) (Tony Duell)
24. Re: Fall cleaning, some small machines for free (Brent Hilpert)
25. Re: Need to find parts 82S23 / 74S188 (ben)
26. Re: TRS-80 Model II Manuals (Geoffrey Reed)
27. Re: Need to find parts 82S23 / 74S188 (Tony Duell)
28. Re: Need to find parts 82S23 / 74S188 (Chuck Guzis)
----------------------------------------------------------------------
Message: 1
Date: Sat, 30 Oct 2010 10:08:19 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: Happy Birthday VAX 11/780 (influence of)
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <4CCBEE93.7369.1A49AC at cclist.sydex.com>
Content-Type: text/plain; charset=US-ASCII
On 29 Oct 2010 at 21:14, Johnny Billquist wrote:
http://electrickery.xs4all.nl/comp/mirror/trs-80_archives/Manuals/Hardware/M
odel_II_Technical_Reference_Manual_(1980)(Radio_Shack)(pdf).zip.
If your program vrites data to address 0, and
reads it back, and get
the same data back, and another program on the same machine, at
roughly the same time, write to address 0, and reads the same data
back, and that data is different than the first programs data, then
I'd say you have virtual memory.
So, your definition ties virtual memory into multi-user access?
That's not the way I learned it.
Consider (again folks, I'm sorry for the reference) the CDC 6600
(circa 1964). Every user is given a relocation address (called RA)
and field length (FL) as a way of partitioning main memory. Each
user's memory addressing space is kept isolated from every other's
and this fits your definiton because one user's location X was
different from every other user's location X and there was no way for
a user to tell what his RA was; i.e. each user was safely "boxed in".
That's not virtual memory by any stretch of the definition. Over-
committing memory meant writing/reading the entire FL of a user to
disk ("rollout" and "rollin").
Now consider the STAR-100 (I think it would qualify as the first
virtual memory machine of CDC), circa 1969. Every user got an
addressing space of 48 bits, but the machine itself had only
512Kwords (64 bit) of physical storage. For production use, most of
the time the system was run in single-user mode (kept thrashing down
with large data sets). That fits my definition of VM because the
user was fooled into thinking that there was more physical memory
than there really was.
Aside from expanding program storage, the large addressing space was
used to map file space (another type of "memory-mapped I/O"), so file
access was actually performed through the paging hardware/software.
That was kind of cool, as the STAR was a memory-to-memory vector
machine, so you could use vector instructions on entire files, rather
than have to issue reads and writes for pieces of a file.
So I think we differ considerably in our definitions.
--Chuck
------------------------------
Message: 2
Date: Sat, 30 Oct 2010 10:21:07 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: TTL HEX LED driver chip
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <4CCBF193.19364.2603DF at cclist.sydex.com>
Content-Type: text/plain; charset=US-ASCII
On the same topic here, can anyone interpret the "state table" on the
second page of the National DM74LS447 7-segment decoder datasheet?
http://pdf1.alldatasheet.com/datasheet-
pdf/view/149198/NSC/DM74LS447N.html
I tend to think of state diagrams as belonging to things such as
counters and don't have a clue as to what to make of the one
furnished.
--Chuck
------------------------------
Message: 3
Date: Sat, 30 Oct 2010 20:05:06 +0200
From: Fred Jan Kraan <fjkraan at xs4all.nl>
Subject: Re: TRS-80 Model II Manuals
To: cctech at classiccmp.org
Message-ID: <4CCC5E52.9000802 at xs4all.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Thanks to the ever-useful JP Hindin, I've obtained a set of TRS-DOS
disks and other application disks for my TRS-80
Model II system, which
is the entire setup pictured here, plus a bit more:
http://oldcomputers.net/pics/TRS-80-II_table.JPG
It's been sitting, covered, pretty much since I obtained it, but now I
can try reviving it and actually seeing what it can do. I'm going to
tear into it and clean the drives and so forth, document what it has,
etc. and then boot 'er up and see what we can see.
I'm looking for a copy of the Technical Ref manual for it; despite
finding scans of the covers and so forth online, I'm unable to actually
locate one. In addition to that, if someone has a Shugart 8" Service
Manual, that might come in damned handy for making sure those are up to
speed as well.
See
The Shugart stuff should be included.
Essential this is from a modified copy of the files that were available
from http://www.trs-80.com/ (copied without permission).
Many thanks,
Nathan
Success,
Fred Jan
P.S. My own adventures with the Model II:
http://www.xs4all.nl/~fjkraan/comp/trs80m2/
------------------------------
Message: 4
Date: Sat, 30 Oct 2010 19:35:32 +0100
From: Philip Pemberton <classiccmp at philpem.me.uk>
Subject: Re: DiscFerret: First working hardware, firmware and
microcode!
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CCC6574.8010103 at philpem.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 30/10/10 17:26, Al Kossow wrote:
If it's going to be an adapter, could you add
holes for SA1000-style 8"
drives (50pin/20pin cabling)?
I almost mistook that for a floppy drive until I looked it up on
Bitsavers...!
I can't see any real reason why SA1000 support couldn't be added to the
bridge-board. Looks like the only changes required would be:
- An oscillator to generate the 3.6866us +/- 0.1% timing clock
(270982 to 271524Hz, nominal 271253Hz). Although I have no idea what
standard crystal frequencies could be used to generate that signal. The
FPGA's PLL might be persuaded to do it, though, I'll have to check.
- Two jumpers to disconnect the Timing Clock from the ST412/506 Data
connector when these are not in use (or maybe just a second connector?)
- A 50-pin connector for the SA1000 control cable
The extra cost probably isn't worth worrying about... though I might
have to restrict drive selection to Drive 0 only in order to get enough
I/O pins for head selection.
Thanks,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
------------------------------
Message: 5
Date: Sat, 30 Oct 2010 19:47:54 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: TRS-80 Model II Manuals
To: cctalk at classiccmp.org
Message-ID: <m1PCGTE-000J3xC at p850ug1>
Content-Type: text/plain
locate one. In addition to that, if someone has
a Shugart 8" Service
Manual, that might come in damned handy for making sure those are up to
speed as well.
...And if they;'re not, it's most likelyto be the drive belt. Yes I know
'up to speed' wasn't meant to be taken literally, but that seemed too
good to miss :-)
More seriously, what model of Shugart8" drive? Are there not manuals for
them on bitsavers?
-tony
------------------------------
Message: 6
Date: Sat, 30 Oct 2010 11:55:03 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: TRS-80 Model II Manuals
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <4CCC0797.19723.7C011E at cclist.sydex.com>
Content-Type: text/plain; charset=US-ASCII
On 30 Oct 2010 at 19:47, Tony Duell wrote:
...And if they;'re not, it's most
likelyto be the drive belt. Yes I
know 'up to speed' wasn't meant to be taken literally, but that seemed
too good to miss :-)
Well, he could have a 220V 50Hz model and be running it on 120V 60Hz
(the motor will develop sufficient torque to spin the disk). I've
made that mistake once. The results from the reverse would be
"interesting"...
--Chuck
------------------------------
Message: 7
Date: Sat, 30 Oct 2010 15:29:06 -0400
From: Dave McGuire <mcguire at neurotica.com>
Subject: Re: DiscFerret: First working hardware, firmware and
microcode!
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CCC7202.6050705 at neurotica.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 10/30/10 2:35 PM, Philip Pemberton wrote:
I can't see any real reason why SA1000
support couldn't be added to the
bridge-board. Looks like the only changes required would be:
- An oscillator to generate the 3.6866us +/- 0.1% timing clock (270982
to 271524Hz, nominal 271253Hz). Although I have no idea what standard
crystal frequencies could be used to generate that signal. The FPGA's
PLL might be persuaded to do it, though, I'll have to check.
You could stick a little AD9833 (or similar) DDS chip on there. It's
overkill, but they're pretty cheap now, and you'll get the desired
frequency spot-on.
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------
Message: 8
Date: Sat, 30 Oct 2010 15:34:25 -0400
From: Dave McGuire <mcguire at neurotica.com>
Subject: Re: Happy Birthday VAX 11/780 (influence of)
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CCC7341.1090704 at neurotica.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10/30/10 1:08 PM, Chuck Guzis wrote:
Aside from expanding program storage, the large
addressing space was
used to map file space (another type of "memory-mapped I/O"), so file
access was actually performed through the paging hardware/software.
That was kind of cool, as the STAR was a memory-to-memory vector
machine, so you could use vector instructions on entire files, rather
than have to issue reads and writes for pieces of a file.
That functionality is in use all over the place today as mmap(),
accessing files as if they were memory, pushing the read/write burden
out into the VM system. It's extremely effective.
I'd not consider it to be "memory-mapped I/O" at all, though, in the
context of "a processor reading and writing I/O ports". Sure, file I/O
is a sort of I/O, and mmap() and similar techniques map that file I/O
into the address space, but the context of this discussion...and indeed,
most, it not all use of the term "memory-mapped I/O" doesn't refer to
this sort of thing.
-Dave
--
Dave McGuire
Port Charlotte, FL
------------------------------
Message: 9
Date: Sat, 30 Oct 2010 20:58:46 +0100
From: Philip Pemberton <classiccmp at philpem.me.uk>
Subject: Re: DiscFerret: First working hardware, firmware and
microcode!
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CCC78F6.9040004 at philpem.me.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 30/10/10 20:29, Dave McGuire wrote:
You could stick a little AD9833 (or similar) DDS
chip on there. It's
overkill, but they're pretty cheap now, and you'll get the desired
frequency spot-on.
?8.25 each with no quantity discount is *not* cheap. The FPGA only costs
a few quid more than that.
Digikey have them for ?5.86, but that's still more than a crystal. I
wonder how the host adapters for the SA1000s generated this clock
frequency... it does seem somewhat odd.
The other thing is, I'd be concerned about releasing hardware with
SA1000 support without testing it on an actual drive. I'm willing to bet
the chances of me finding a working SA1000 in 230V/50Hz configuration
are somewhere between 'slim' and 'nil'.
I'll guarantee ST506 support though, given that I've got an ST277R RLL
drive and controller here. Just need an MFM controller for it, or the
RLL code tables for the Seagate ST21R or ST22R controller (which IIRC
uses an Adaptec AIC010 chip)...
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
------------------------------
Message: 10
Date: Sat, 30 Oct 2010 13:23:00 -0700
From: Brent Hilpert <hilpert at cs.ubc.ca>
Subject: Re: TTL HEX LED driver chip
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <8534ab06c8e0281a7fcfc54d6a70efa5 at cs.ubc.ca>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On 2010 Oct 30, at 10:21 AM, Chuck Guzis wrote:
On the same topic here, can anyone interpret the
"state table" on the
second page of the National DM74LS447 7-segment decoder datasheet?
http://pdf1.alldatasheet.com/datasheet-
pdf/view/149198/NSC/DM74LS447N.html
I tend to think of state diagrams as belonging to things such as
counters and don't have a clue as to what to make of the one
furnished.
It's obviously a state diagram for a decade counter, my guess is
someone just screwed up making the datasheet and included the state
diagram from some other device.
------------------------------
Message: 11
Date: Sat, 30 Oct 2010 13:36:50 -0700
From: Brent Hilpert <hilpert at cs.ubc.ca>
Subject: Re: Happy Birthday VAX 11/780 (influence of)
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <d40186fd9ded72a101d654d9516da0f5 at cs.ubc.ca>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On 2010 Oct 30, at 12:34 PM, Dave McGuire wrote:
On 10/30/10 1:08 PM, Chuck Guzis wrote:
I remember in the 80's (programming primarily on BSD (and VMS))
thinking it would nice to have that functionality, how easy it would
make a lot of file-access programming, and that it would be easy to add
on a VM system. Of course, I was in ignorance of the prior histories
such as the STAR that Chuck mentions. A few years later a friend would
tell me about the new mmap function in unix.
Aside from expanding program storage, the large
addressing space was
used to map file space (another type of "memory-mapped I/O"), so file
access was actually performed through the paging hardware/software.
That was kind of cool, as the STAR was a memory-to-memory vector
machine, so you could use vector instructions on entire files, rather
than have to issue reads and writes for pieces of a file.
That functionality is in use all over the place today as mmap(),
accessing files as if they were memory, pushing the read/write burden
out into the VM system. It's extremely effective. I'd not consider it to be
"memory-mapped I/O" at all, though, in the
context of "a processor reading and writing I/O ports". Sure, file
I/O is a sort of I/O, and mmap() and similar techniques map that file
I/O into the address space, but the context of this discussion...and
indeed, most, it not all use of the term "memory-mapped I/O" doesn't
refer to this sort of thing.
Well, Chuck did say "a type of". If files are a form of abstracted disk
I/O, then mmap is a form of abstracted memory-mapped I/O.
------------------------------
Message: 12
Date: Sat, 30 Oct 2010 13:36:53 -0700 (PDT)
From: Bob Rosenbloom <bobalan at sbcglobal.net>
Subject: Fall cleaning, some small machines for free
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <960487.42595.qm at web80502.mail.mud.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Fall cleaning!
I have a bunch of old computers and some peripherals. Most are not tested
and I expect they may need some work to become operational, though some
may work correctly as-is. Anyway, I'm hoping to find people interested in
restoring these systems.
There are three Burroughs B25 systems, each has a processor box, disk box, monitor, keyboard, and power supply. There is one box
of docs and
diskettes and one, very dirty, printer.
http://www.anifur.com/clist/misc-b1.jpg
http://www.anifur.com/clist/misc-b2.jpg
http://www.anifur.com/clist/misc-b3.jpg
http://www.anifur.com/clist/misc-b4.jpg
IBM convertible, an early laptop type system.
A Computer Products portable, thermal, serial terminal.
http://www.anifur.com/clist/misc-ptr.jpg
A Radio Shack TRS-80 model I with expansion chassis and monitor. I believe
this has a bad power supply.
http://www.anifur.com/clist/misc-rs.jpg
A NEC Spinwriter terminal. This is like a Diablo daisywheel terminal
except the print element is a cylinder. I know this one needs work but
does power up.
http://www.anifur.com/clist/misc-spin.jpg
Some kind of cartridge tape system. I think it's SCSI interfaced. I don't
believe this has ever been used.
http://www.anifur.com/clist/misc-tape.jpg
A large flatbed scanner that I also believe is unused. It's SCSI
interfaced. UMAX 3000.
http://www.anifur.com/clist/misc-scanner.jpg
Digitech RS-232 analyzer with manuals. This runs CP/M 86 but I don't have
the boot disc for it. Does power up.
http://www.anifur.com/clist/misc-anal.jpg
Kaypro 2, powers up and ask for a system disk.
http://www.anifur.com/clist/kaypro1.jpg
Hitachi pen plotter. This has a parallel interface. It powers up and works
from the front panel. Light weight.
http://www.anifur.com/clist/hitachi1.jpg
Panasonic NV-A960 VCR editing unit.
http://www.anifur.com/clist/a960-1.jpg
Nicolet Zeta 8A pen plotter. 8 pens. Also powers up and works from the
front panel. Serial interface.
All of these are located in the Santa Cruz, CA mountains, near the Bonny
Doon airport. I can possibly bring something into Santa Clara where I
work. Best to come visit and check them out here. I really don't want to
ship anything as I just don't have the time or energy.
Please rescue these before I scrap them, I really need the space and these
are now outside, but covered under a Quonset hut.
Bob
------------------------------
Message: 13
Date: Sat, 30 Oct 2010 13:39:13 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: DiscFerret: First working hardware, firmware and
microcode!
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <4CCC2001.27472.DB6112 at cclist.sydex.com>
Content-Type: text/plain; charset=US-ASCII
On 30 Oct 2010 at 15:29, Dave McGuire wrote:
------------------------------
Message: 12
Date: Sun, 31 Oct 2010 11:37:47 +0100
From: Johnny Billquist <bqt at softjar.se>
Subject: Re: Virtual memory
To: cctalk at classiccmp.org
Message-ID: <4CCD46FB.6070304 at softjar.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2010-10-30 23:18, "Chuck Guzis"<cclist at sydex.com> wrote:
On 10/30/10 2:35 PM, Philip Pemberton wrote:
Also, aren't the read/write data signals on the SA1000 differential?
Or do I have them confused with the ST506 interface?
--Chuck
------------------------------
Message: 14
Date: Sat, 30 Oct 2010 13:52:12 -0700
From: alan canning <scanning.cc at gmail.com>
Subject: Need to find parts 82S23 / 74S188
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID:
<AANLkTinzHd-NW1yL2LFuNG1=1q7s3hKOdxe2VLr7uXLH at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've tried
all
the usual suspects ( Ebay, local parts houses, Digikey, etc. ) with no
joy.
I believe this part was used on old S100 boards.
Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30 and
Harris 7602. Need this part to fix an old computer controlled RF Power
amplifier.
Thanks for any and all help.
Best regards, Steven
------------------------------
Message: 15
Date: Sat, 30 Oct 2010 13:54:40 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: Happy Birthday VAX 11/780 (influence of)
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <4CCC23A0.9876.E985BD at cclist.sydex.com>
Content-Type: text/plain; charset=ISO-8859-1
On 30 Oct 2010 at 15:34, Dave McGuire wrote:
I can't see any real reason why SA1000
support couldn't be added to
the bridge-board. Looks like the only changes required would be: -
An oscillator to generate the 3.6866us +/- 0.1% timing clock (270982
to 271524Hz, nominal 271253Hz). Although I have no idea what
standard crystal frequencies could be used to generate that signal.
The FPGA's PLL might be persuaded to do it, though, I'll have to
check.
You could stick a little AD9833 (or similar) DDS chip on there.
It's
overkill, but they're pretty cheap now, and you'll get the desired
frequency spot-on. I'd not consider it to be
"memory-mapped I/O" at all, though, in
the
context of "a processor reading and writing I/O ports". Sure, file
I/O is a sort of I/O, and mmap() and similar techniques map that file
I/O into the address space, but the context of this discussion...and
indeed, most, it not all use of the term "memory-mapped I/O" doesn't
refer to this sort of thing.
I'm sure and I'd never seriously call it "memory-mapped I/O"--but
sometimes our world seems akin to that of Humpty-Dumpty: "When I use
a word it means just what I choose it to mean--neither more nor less"
Uh-oh, here comes another story...
After I left CDC and the STAR project in 1977, my past came back to
haunt me in the form of doing an optimizing FORTRAN for the ETA-10 in
about 1983. We got a leased-line linkup to ETA in St. Paul and I
asked what text editor they were using.
Much to my surprise, it turned out to be the same editor I'd written
for a lark around 1975 when the STAR had lots of really interesting
byte string instructions and I could exploit file-mapped I/O to use
them. Mind you, this was in the day of 16-line 1200 bps terminals.
But the ETA-10 had none of those instructions, essentially having
evolved out of the "everything but the kitchen sink CISC" state of
mind of the original architecture. Some programmer had been detailed
off to replace all of those cool vector instructions with their
scalar equivalents!
I was stunned and opined that with that way of thinking, the software
end of the ETA project was doomed.
--Chuck
------------------------------
Message: 16
Date: Sat, 30 Oct 2010 21:58:20 +0100
From: Philip Pemberton <classiccmp at philpem.me.uk>
Subject: Re: DiscFerret: First working hardware, firmware and
microcode!
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CCC86EC.8040906 at philpem.me.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 30/10/10 21:39, Chuck Guzis wrote:
Also, aren't the read/write data signals on
the SA1000 differential?
Or do I have them confused with the ST506 interface?
They're both differential. It's just that the SA1000 expects you to feed
it a reference clock signal. It doesn't have to be locked against
write-data, it just has to be there, and be accurate to 0.1%...
Assuming the OEM manual is accurate, of course.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
------------------------------
Message: 17
Date: Sat, 30 Oct 2010 21:23:40 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: TTL HEX LED driver chip
To: cctalk at classiccmp.org
Message-ID: <m1PCHxn-000J3xC at p850ug1>
Content-Type: text/plain
On 29 Oct 2010 at 22:10, Tony Duell wrote:
Yes, I should have remembered that...
Anyother thought I had is to use a 7447 for the
lower 8 or 10
patterns (as it's designed to do!) and add logic for the higher ones.
I don't know if that saves chips.
The 7447 has a problem in that the "6" doesn't have the top crossbar,
so that it's indistinguishable from a "b". The '247 does include the
top segment when displaying '6', which is why I mentioned the 247 and
not 47.
This brings to mind an ancient "fix" for the 47 "6" display--a
pulldown diode connected between segment "e" and segment "a"--in the
Been there, done that :-)
display of 0-9 there is no time when segment
"e" is active that
segment "a" isn't also active. The converse, however isn't true--and
this "fix" will mess up your display of "b" if you use the method
described previously to display 0-F.
Of course. For 'b' you mmed the 'e' segment without the 'a'
segment.
That's what distinguishes it from '6'
But if you allow diodes, then there's no reason not to use a 4-to-16
demux and a mess of diodes to do the decoding for 0-F, is there?
while my original question didn't preclude the use of discrete
components, and while I happly ageee that the odd diodes, pull-up
resisotrs, etc can lead to interesting solutions, I do feel that such a
diode matrix is outisde the spirit of the problem. After all, you could
say it can be solved with no ICs at all, just lots of discrete
transistors, etc. :-)
-tony
------------------------------
Message: 18
Date: Sat, 30 Oct 2010 21:27:54 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: Nuclear Data ND 6600
To: cctalk at classiccmp.org
Message-ID: <m1PCI1t-000J3yC at p850ug1>
Content-Type: text/plain
eons ago at a TRW a friend bought a nice box that
looked much like an
ADM3a with nice case, integrated CRT and keyboard, and gleefully gave
the guy selling it about $40 for it. This was in the day of $700
terminals new prices.
It was a Vector graphics console. Unfortunately he had not looked at
the back, or thru the cracks, but it was a plastic case with a keyboard
and CRT inside, no PS, electronics or anything else. I suspect when he
I am suprised there wasn't the standard driver circuits for the CRT (from
composite vidoe, say). My guess is that there should have been, and they
were msising.
moved east some years ago it got dumpstered, but
it was about the same
sort of thing, no brains in the "terminal" but in the box.
ICL did something similar. They had 'terminals' that consisted of encoded
keyboards and composite monitors. The case was painted a horrible orange
colour ... I think I still have one of the keyboards somewhere, but I
mangaged to give the monitor away some years ago (thankfully...)
-tony
------------------------------
Message: 19
Date: Sat, 30 Oct 2010 22:07:02 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: TRS-80 Model II Manuals
To: cctalk at classiccmp.org
Message-ID: <m1PCIdm-000J4HC at p850ug1>
Content-Type: text/plain
On 30 Oct 2010 at 19:47, Tony Duell wrote:
Actaully, a lot of the 8" drives I have have 120V motors, but of course
the right pulleys for 50Hz mains. They are run from an
(auto)transformer, often the primary winding of the syatem mains
transformer.
So I suppose he could have something like that :-)
-tony
------------------------------
Message: 20
Date: Sat, 30 Oct 2010 21:41:27 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: TTL HEX LED driver chip
To: cctalk at classiccmp.org
Message-ID: <m1PCIF1-000J48C at p850ug1>
Content-Type: text/plain
...And if they;'re not, it's most
likelyto be the drive belt. Yes I
know 'up to speed' wasn't meant to be taken literally, but that seemed
too good to miss :-)
Well, he could have a 220V 50Hz model and be running it on 120V 60Hz
(the motor will develop sufficient torque to spin the disk). I've
made that mistake once. The results from the reverse would be
"interesting"...
On 2010 Oct 29, at 2:10 PM, Tony Duell wrote:
Err, no. That's what the extra inverter is for.
You know hos to use a 2^n input mux to make an arbitrary combinartorial
function of n signals. Feed the n signals to the select inputs of the
multiplexer and wire the 'data' inputs high or low as the truth table
requires.
But you can also yuse a 2^(n-1) input mux and maybe a single inverte, you
connect n-1 of the input lines to the select inputs of the mux. And then
for each of those combinations you consider the 2 truth table lines that
apply (the last input, the one you've not used yet, of course
distinguishes between the 2 lines in each pair). There are 4 possibilites
:
a) The output of the function is 0 in both cases (it doesn't depend on
the last input at all) --> wire that input of thr mux to ground
b) It's 1 in both cases -> wire the input to Vcc
c) It's 0, 1 , it follows the last input in this case -> Wire that last
input signal to the appropraite input of the multiplexer
d) It's 1,0, it's the opposite of the last input. This is when you need
that inverter. Invert the last input signal and wire the appropriate
multiplexer input to the ouptu of the inverter.
If oyu requre several functions of the same inputs (as here), you only
need 1 ivnerter (assumeing there are no fan-out problems), since it's
always thge same singal (say the 2^0 data input) you need to invert.
Son yes, you can use 8 input multiplexers here (and 4 input ones if you
only want to generate 6 or 8 patterns).
Now, another silly aside...
If you want to use a 2^(n-2) mux, you may need any or all of the 16
possible functions of the last 2 inputs (you split up the truth table
into sets of 4 lines, and see which function of the last 2 inputs gives
the right paattern, of course). This makes it less useful :-). But it's
made me think pof a chip that AFAIK never existed... If you think of those
16 possible functions of 2 inputs, then 4 of them are 'trivial' in the
sense that you can produce them with no logic at all. Namely 'always 0',
'always 1', 'equal to the A input' and 'equal to the B input'.
Which
leaves 12 non-rtrivial ones/ Now that means there could have been a 16
pin IC with 2 power pins, 2 inputs and 12 outputs, the 12 non-trivial
functions of the 2 inputs. Use that witha 74150 for an arbitrary fucntion
of 6 inputs...
-tony
------------------------------
Message: 21
Date: Sat, 30 Oct 2010 21:44:22 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: TTL HEX LED driver chip
To: cctalk at classiccmp.org
Message-ID: <m1PCIHq-000J49C at p850ug1>
Content-Type: text/plain
For those who are wondeirng, the 'trivial' solution I mentioned uses 7
off 74150 16-input multiplexers, one for each segment. You tie the
inputs
high low to determine if that segment is on or off for a given set fo 4
input bits.
After posing that, I thought of other solutions that make no
assumptions
about the segment patterns -- they always work. For example 7 off
74151 8
input muxes and a single inverter (1/6 of a 7404) That has the
advantage
of automatically providing actrive high and active low outputs.
That only gives you 8 patterns, not 16 .. ?
On 29 Oct 2010 at 16:13, Brent Hilpert wrote:
Absolutely. Of cousre I've kept all my old paper databooks, and still
read them from time to tieme.
Yes, it's very useful being able to get data on just about any standard
IC over the internet. But it's useful in a different way being able to
flip through a data book, see what's available, etc. I've yet to find a
manufacturer's site that lets me browse in the same way.
-tony
------------------------------
Message: 22
Date: Sat, 30 Oct 2010 21:48:01 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: Wanted : Monitor Capable of TTL RGB
To: cctalk at classiccmp.org
Message-ID: <m1PCILO-000J4AC at p850ug1>
Content-Type: text/plain
I too realised that halfway thru the exercise and
went scrambling back
to the databook to check on the 247.
Another reason to lament the passing of the hardcopy databook. I
used to sit and read them cover-to-cover. Not really possible in
On 30/10/10 03:08, Dan Williams wrote:
Is CM8833 a TTL-input monitor? I think it was available as an option,
but most of them take analogue RGB on the SCART socket.
Most of the time the SCART inputs, for all they're supposed to be 1V will
stand TTL (the CM8833 ones certainly will). Or since they're terminated
to ground through a 75 ohm resistor, connect a 300 Ohm (or so) resistor
in series with each TTL signal. Done that many times :-)
Is there any reason a TV with a SCART socket isn't suitable? Most, if not
all, LCD and plasma TVs should haev RGB inputs on the SCART socket, for
example.
-tony
------------------------------
Message: 23
Date: Sat, 30 Oct 2010 21:52:09 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: I/O models (was RE: Happy Birthday VAX 11/780 (influence
of))
To: cctalk at classiccmp.org
Message-ID: <m1PCIPM-000J4BC at p850ug1>
Content-Type: text/plain
I am on the lookout for a monitor something
similar to a Phillips
cm3388 does anyone near London have one they would like to sell or
trade, or know of anywhere I could get one.
Surely you mean the CM8833?
Those were fairly extensively re-badged -- Acorn, for instance, sold a=20
variant of the CM8833 Mk.II as the AKF17.
OK, it's fair to say that there's nothing that precludes memory-mapped
I/O =
in any machine (except perhaps physical memory architecture, although I
can=
't think of an example). But port-mapped I/O machines had specific
instruc=
The obvious problem would be if the memroy map is already totally full.
If you've got a Z80 systme with 64K of memory, it would be perverse to
try memory mapped I/O (you could have some kind of MMU, but why...).
Similarky trying to emmeroy map any kind of I/O on a 2MByte PERQ would be
an 'interesting' exercise...
-tony
------------------------------
Message: 24
Date: Sat, 30 Oct 2010 14:09:44 -0700
From: Brent Hilpert <hilpert at cs.ubc.ca>
Subject: Re: Fall cleaning, some small machines for free
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <981998b8f30737dece941bd3fc38a0c1 at cs.ubc.ca>
Content-Type: text/plain; charset=US-ASCII; format=flowed
On 2010 Oct 30, at 1:36 PM, Bob Rosenbloom wrote:
Panasonic NV-A960 VCR editing unit.
http://www.anifur.com/clist/a960-1.jpg
I dismantled one of these a few years ago, it contained an
(NEC-branded) 8080, a whack of NEC 8255's (PIO), half-a dozen ceramic
Fujitsu MB8516's (2K*8 EPROMS, 2716-like), all socketed, for anyone
that might take an interest in such stuff.
All of these are located in the Santa Cruz, CA
mountains, near the
Bonny Doon airport. I can possibly bring something into Santa Clara
where I work. Best to come visit and check them out here. I really
don't want to
ship anything as I just don't have the time or energy.
Please rescue these before I scrap them, I really need the space and
these are now outside, but covered under a Quonset hut.
Bob
------------------------------
Message: 25
Date: Sat, 30 Oct 2010 15:11:06 -0600
From: ben <bfranchuk at jetnet.ab.ca>
Subject: Re: Need to find parts 82S23 / 74S188
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Message-ID: <4CCC89EA.1000405 at jetnet.ab.ca>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
looks for 74S188 with google
http://www.futurlec.com/Memory/74S188pr.shtml
------------------------------
Message: 26
Date: Sat, 30 Oct 2010 14:17:16 -0700
From: Geoffrey Reed <geoffr at zipcon.net>
Subject: Re: TRS-80 Model II Manuals
To: cctalk <cctalk at classiccmp.org>
Message-ID: <C8F1D96C.2E65E%geoffr at zipcon.net>
Content-Type: text/plain; charset="US-ASCII"
Y'all are making me miss my tandy model 16 and 6000.
------------------------------
Message: 27
Date: Sat, 30 Oct 2010 22:21:08 +0100 (BST)
From: ard at p850ug1.demon.co.uk (Tony Duell)
Subject: Re: Need to find parts 82S23 / 74S188
To: cctalk at classiccmp.org
Message-ID: <m1PCIrQ-000J3xC at p850ug1>
Content-Type: text/plain
Anybody no where to score some Sig 82S23 / Nat 74S188 parts ? I've tried
all
the usual suspects ( Ebay, local parts houses, Digikey, etc. ) with no
joy.
I believe this part was used on old S100 boards.
Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30 and
Harris 7602. Need this part to fix an old computer controlled RF Power
amplifier.
IIRC, this is a PROM, 32*8 I think. Do you have a copy of the data to
program into it? A blank chip is not a lot of use to you otherwise...
Also while all the derives you've mentioned are I think compatible when
being read (that is, as they are normally used in the circuit), the
programming algorithms are different for differnet manufacturers. You need
to get one that your programmer can handle
-tony
------------------------------
Message: 28
Date: Sat, 30 Oct 2010 14:18:38 -0700
From: "Chuck Guzis" <cclist at sydex.com>
Subject: Re: Need to find parts 82S23 / 74S188
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Message-ID: <4CCC293E.2099.FF7864 at cclist.sydex.com>
Content-Type: text/plain; charset=US-ASCII
On 30 Oct 2010 at 13:52, alan canning wrote:
Anybody no where to score some Sig 82S23 / Nat
74S188 parts ? I've
tried all the usual suspects ( Ebay, local parts houses, Digikey, etc.
) with no joy. I believe this part was used on old S100 boards.
Part also known as ( a.k.a. ) Fu 7111, AMD 27S18, MMI 6330, TI 18SA30
and Harris 7602. Need this part to fix an old computer controlled RF
Power amplifier.
If you'd like something a bit closer to home, you might try ACP--
they're listing some IM5603s on eBay for $7.95 the each.
--Chuck
End of cctalk Digest, Vol 86, Issue 68
**************************************
On 29 Oct 2010 at 21:14, Johnny Billquist wrote:
No no no. You miss my point. It don't directory tie in to multiuser
access. It's about presenting to you a memory which in reality does not
exist as you perceive it. As a follow on benefit of this is the fact
that you can have multiple instances at the same time. But that is not
the definition.
The definition is that you appear to have a linear space of memory that
maps the whole virtual address range, and that this memory is yours
alone. It is your own private memory. Just as a virtual machine is your
own private machine. No matter the fact that in reality, this is not the
case, and your memory (or machine) is just something running under the
control of an underlying operating system, which gives you this service.
> If your program vrites data to address 0,
and reads it back, and get
> the same data back, and another program on the same machine, at
> roughly the same time, write to address 0, and reads the same data
> back, and that data is different than the first programs data, then
> I'd say you have virtual memory.
So, your definition ties virtual memory
into multi-user access?
That's not the way I learned it. Consider (again folks, I'm sorry for the
reference) the CDC 6600
(circa 1964). Every user is given a relocation address (called RA)
and field length (FL) as a way of partitioning main memory. Each
user's memory addressing space is kept isolated from every other's
and this fits your definiton because one user's location X was
different from every other user's location X and there was no way for
a user to tell what his RA was; i.e. each user was safely "boxed in".
The important question here - are the programs aware of the RA register,
and can they change it? And can they address the full range of memory
addresses as perceived by the program.
That's not virtual memory by any stretch of the
definition. Over-
committing memory meant writing/reading the entire FL of a user to
disk ("rollout" and "rollin").
Another word for swapping in and out?
Anyway, I'm not sure if this would qualify as virtual memory or not
without knowing a few more details. But it might very well be virtual
memory, as far as I can tell.
Now consider the STAR-100 (I think it would qualify as
the first
virtual memory machine of CDC), circa 1969.
Defined by whom? CDC? Or you guys? ;-)
Every user got an
addressing space of 48 bits, but the machine itself had only
512Kwords (64 bit) of physical storage. For production use, most of
the time the system was run in single-user mode (kept thrashing down
with large data sets). That fits my definition of VM because the
user was fooled into thinking that there was more physical memory
than there really was.
You know, my definition and yours don't necessarily disagree on all
points. Both would define the VAX as having virtual memory (well, except
for the fact that yours might not, if you have a VAX with enough
physical memory). We just disagree about what when there is more
physical memory than you have virtual memory space. For you, that means
it can't be virtual memory. but for me it can.
For me, what is relevant is whether the program is presented with his
own private memory space, which contains all addresses he can address,
and where all those addresses are valid and working. A memory space
which he don't have to share with anyone else. That's what virtual
memory is, as opposed to physical memory, which you can point at, and
which all running code on a computer needs to live on. And that means
that the OS is always there. And possibly other processes as well. Using
the same addresses you are. If that means that you cannot have your own
memory for a specific address, then it's not virtual memory. But then
you probably aren't talking about virtual memory either, but physical
memory.
Aside from expanding program storage, the large
addressing space was
used to map file space (another type of "memory-mapped I/O"), so file
access was actually performed through the paging hardware/software.
That was kind of cool, as the STAR was a memory-to-memory vector
machine, so you could use vector instructions on entire files, rather
than have to issue reads and writes for pieces of a file.
So I think we differ considerably in our definitions.
On some parts, yes. So, do the VAX not have virtual memory? After all, I
can fill a VAX with more physical memory than you can address virtually.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
------------------------------
Message: 13
Date: Sun, 31 Oct 2010 11:47:53 +0100
From: Johnny Billquist <bqt at softjar.se>
Subject: Re: Memory mapped I/O
To: cctalk at classiccmp.org
Message-ID: <4CCD4959.8040105 at softjar.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2010-10-30 23:18, Brent Hilpert<hilpert at cs.ubc.ca> wrote:
On 2010 Oct 30, at 12:34 PM, Dave McGuire wrote:
> > On 10/30/10 1:08 PM, Chuck Guzis wrote:
>> >> Aside from expanding program storage, the large addressing space was
>> >> used to map file space (another type of "memory-mapped I/O"),
so
file
>> >> access was actually performed
through the paging hardware/software.
>> >> That was kind of cool, as the STAR was a memory-to-memory vector
>> >> machine, so you could use vector instructions on entire files,
rather
> >>
than have to issue reads and writes for pieces of a file.
>
> That functionality is in use all over the place today as mmap(),
> accessing files as if they were memory, pushing the read/write burden
> out into the VM system. It's extremely effective.
I remember in the
80's (programming primarily on BSD (and VMS))
thinking it would nice to have that functionality, how easy it would
make a lot of file-access programming, and that it would be easy to add
on a VM system. Of course, I was in ignorance of the prior histories
such as the STAR that Chuck mentions. A few years later a friend would
tell me about the new mmap function in unix. > > I'd not consider it to be
"memory-mapped I/O" at all, though, in
the
> context
of "a processor reading and writing I/O ports". Sure, file
> I/O is a sort of I/O, and mmap() and similar techniques map that file
> I/O into the address space, but the context of this discussion...and
> indeed, most, it not all use of the term "memory-mapped I/O" doesn't
> refer to this sort of thing.
Well, Chuck did say "a type of". If
files are a form of abstracted disk
I/O, then mmap is a form of abstracted memory-mapped I/O. So I have these 2 PDP-8/L core stacks I am trying to
recover:
One would be perfect, if bit 3 @ adr 0 would be alive...
Although this is 99.99% OK, it is of course not good enough.
Just to mke sure I'm hearing you right: Are you saying one individual core
is 100% dead, and everything else is 100% okay? If so - if it's one
single, individual core which is broken - I'd suspect this is pretty much
irrepairable. The options would be to A) try to form/mold/create a new
ferrite core around the wires, which would be insanely difficult assuming
it could be done at all, or B) to unwire that plane of the core stack,
replace the broken ferrite core with a new one, and then rethread/rewire
it. That's extremely nontrivial work, I have to believe. But they were
originally threaded by hand, albeit by people with microscopes and _very_
good eye-hand coordination and sewing skills, so it's within the realm of
possibility.
If I've read you wrong, though, and the whole thing is working except
address 0 bit 3 is working _some_ of the time, that would be really good
news. :) You could try scoping out the sense amps and inhibit drivers
for bit 3 and see if they were just borderline to specifications,
something which might be just tweaky enough to affect one bit.
The other stack seems to be a total loss :
2 sense wires are open circuit, more than 20 select diodes shorted. Of
course the further quality of the cores is unknown.
Oddly enough, this one might be easier to deal with. Have you tracked down
where the sense wires go open-circuit? If they're failing at a
solder-joint near an outer edge, you could potentially repair them without
having to open up the whole damn stack. The diode replacement would likely
mean partially disassembling the stack assembly to gain access to both
sides of the diode PCB, but at least you're only having to dig in one
level.
O'course making those repairs might simply reveal more problems at the
core level. But you've gotta start somewhere, I s'pose. :)
Is there any realistic way of getting one fully
functional stack out of
these
?
Removing a single core from the really bad stack to the almost OK stack
would
seems almost feasible to me, since address 0 is bound
to be on a edge of a
core mat.
I suspect I'm not the only one on the list who:
-thinks opening up a core-stack and repairing it is
theoretically possible;
-also thinks it would be a hell of a daunting project;
-is somewhat amazed at the dexterity and patience of the people
who originally hand-wired them at manufacture; and
-thinks pulling off a repair of a core-plane by rewiring it by
hand would give significant bragging rights. :)
-O.-
End of cctalk Digest, Vol 86, Issue 71
**************************************
5166
days inactive
5166
days old
0 comments
1 participants
participants (1)
-
gerhard.kreuzer＠liftoff.at