cctalk Digest, Vol 86, Issue 68

MikeS dm561 at torfree.net
Sun Oct 31 12:47:06 CDT 2010


----- 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


> 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:
>
>> 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
> http://electrickery.xs4all.nl/comp/mirror/trs-80_archives/Manuals/Hardware/Model_II_Technical_Reference_Manual_(1980)(Radio_Shack)(pdf).zip.
> 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:
>>> 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.
>
>
>
> ------------------------------
>
> 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:
>
>> 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.
>
> 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'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:
>>
>> > 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.
>
> Yes, I should have remembered that...
>
>
>>
>> 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:
>>
>> > ...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"...
>
> 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
>
>>
>> On 2010 Oct 29, at 2:10 PM, Tony Duell wrote:
>> >
>> > 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 .. ?
>
> 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
>
>>
>> On 29 Oct 2010 at 16:13, Brent Hilpert wrote:
>>
>> > 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
>
> 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
>
>>
>> On 30/10/10 03:08, Dan Williams wrote:
>> > 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.
>
> 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
>
>>
>> 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
> ************************************** 




More information about the cctalk mailing list