Does anyone know when seven segment displays first appeared on the scene?
Presumably the first ones were VF, and LED came later?
(I was just looking at a museum's mock-up of the Apollo mission control
console, and the fake readout is made to look like a 7-seg display; I'm just
surprised that the digital readouts weren't all Nixie-based back then)
cheers
Jules
I have an identical item. I need a 720kb floppy LIF formatted floppy disk, mine is shot. If you would care to make a copy of the HP 1651A OS on your machine I would be glad to pay for it. For now I'm dead in the water. I have tried to create a OS disk but I have LOTS of gaps in my machine language understanding. Also any help in this direction would be GREATLY appreciated.
Best Regards,
Chris Wolters
It used to be you could go to Radio Shack and pick up a couple of 74ls02
chips as needed. Now it seems there isn?t a source for someone who wants to
purchase a handful of 74xx ttl chips. I have a ?brand new? s100 SIO card
that is just missing the 14 logic chips to go in the sockets, but I am not
finding a convenient source for them.
Anyone know where I can go to find them in very small quantities?
Jeff Erwin
I recently bought another HP Integral on E-bay, and after the normal
cleanup on the floppy drive it works fine. The expansion slots both
cotnained boards, one was a 512K RAM board, the other an RS232 oard
(which is the main reason I watned this machine!).
Anyway, the RAM board was clearly identical to the 1M board, just with
only have the RAM chips fitted and the links set differently. Having got
a lot of 41256 chips on old PC memory boards, I spent the afternoon
upgrading it to 1M.
BAsically :
1) Remove the bracket and cover from the PCB (torx screws)
2) Clean out the holes fro the RAM and their decoupling capacitors using
a soldering iron and solder sucker. Test the board at this point, if it
doesn't work, find the solder bridge between traces in the RAM area...
3) Fit 16 off 16 pin turned-pin sockets to the RAM space. Test again
4) Fit 16 off 0.1uF capacitors. I found the exact part at Farnell.
They've been discontinued (They're not lead-free...) but they still had
stock. Test again
5) Plug in the RAMs and test again
6) Removce the link 'W2' on the board (this is the bank select line to
the RAM controller), link the end that's common with W1 and W3 to +5V
(e.g. the end of the decoupling capacitor right next to that point). Test
again. You're now using the new RAM chips only, as a 512K oard.
7) If it works, set all the links as for a 1M board, trst again
8) Finally put the cover and bracket back on.
Now for the curiousity. One one of the standard disks supplied with the
Inegral is a program called 'status'. And one of the things it displays
is the amount of free memory.
In my machine, wioth no RAM boards fitted. there's 264K free. With the
512K board, it reports 764K free. And with the 1M board, 1264K free.
My question is what's happening to the other 12K of each half-meg? Or
deos 'status' have an odd definition of a kilobyte?
-tony
>DigiKey or Unicorn Electronics.
>Both want $25 on the order or a handling fee applies.
>Grant
>At 09:03 AM 2/29/2008, you wrote:
>It used to be you could go to Radio Shack and pick up a couple of
74ls02
>chips as needed. Now it seems there isn?t a source for someone who
wants to
>purchase a handful of 74xx ttl chips. I have a ?brand new? s100 SIO
card
>that is just missing the 14 logic chips to go in the sockets, but I am
not
>finding a convenient source for them.
>
>Anyone know where I can go to find them in very small quantities?
>
>Jeff Erwin
The Digikey "Handling fee" used to be $5 . . .
If you're buying 14 TTL's, you may already be at the $25 minimum. . .
I don't usually start with Digikey, though.
Try checking out MOUSER . . . MCM electronics, or JAMECO.
All can be reached at their .com websites. . .
(Jameco still has NOS 4164's and 41256's and decent prices.)
T
> Date: Sat, 1 Mar 2008 00:06:39 +0000 (GMT)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Subject: Re:
> To: cctalk at classiccmp.org
> Message-ID: <m1JVFFS-000J3jC at p850ug1>
> Content-Type: text/plain
>
> > I/O - but I have to say I was extremely impressed by the upgrade -
> > almost exciting reading!
>
> I assume thats saracsm. It's a very simple upgrade -- it was
> obvious what
> the extra chipos should be, it was also obvious what most of
> the links
> did. And I do have a 'factory' 1M board in my other Integral
> (although I
> could have worked it out without that).
>
Tony:
No sarcasm intended - what's simple to you is an adventure to others.
For me it was a very educational read - and if it was really that
simple, you wouldn't need to post the steps, would you? Thanks for the
tour!
-W
Yeah, same here; the trouble is that a lot of things that I deemed
uninteresting and tossed out in the past turned out after the fact to be
very interesting indeed for some other folks, as I discovered when I joined
this list. And despite the general disdain for newer stuff and especially
PC stuff, in 20 years that may also be interesting; now I don't dare
throw anything out.
Anyway, looks like they've found a new home and I hope that any
interesting ones will be scanned & made available on the Web.
Coincidentally and related to another recent thread on here, the first
brochure I happened to pick up was from Techtran, who had a line of
standalone and rack-mount RS-232 cassette and diskette units
(Interacters); turns out I even have the remnants of one of their
units in my junk pile.
Think I'll keep the Russian (Cyrillic) Cromemco brochure though...
mike
******************************************************************************
Date: Sat, 01 Mar 2008 08:35:11 -0800
From: Marvin Johnston <marvin at west.net>
Subject: Re: Sales brochures, price lists etc.
That is the same problem I have/had. I extablished a cutoff date recycled
anything I didn't consider interesting after that. The sales brochures I
generally kept, but for other stuff, I just put a cutoff date of sometime in the
early 1980s for anything I considered common or not interesting.
> From: M H Stein <dm561 at torfree.net>
>
> Time to finally clean out some file cabinets; what should I do with
> sales brochures, price lists, etc. from the 80s? Nothing exciting,
> not very informative, but hate to just toss 'em into the recycle bin.
>
> m
>
>Subject: Re: Q-bus to CF [was: IOmega]
> From: woodelf <bfranchuk at jetnet.ab.ca>
> Date: Sat, 01 Mar 2008 10:58:34 -0700
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>der Mouse wrote:
>>>> Some time back (years), someone was working on an IDE interface for
>>>> a Qbus MicroVAX and I was doing the driver. [...]
>>
>>>> We never got it working, and it is not clear to me, now, why not.
>>>> [...] what memory I have indicates that there were hardware issues,
>>
>>> the likely reason is PDP-11 and VAX does read before write and IDE
>>> does not like that.
>>
>> Huh? The only sense I can think of in which the PDP-1 and VAX could be
>> said to do read before write is in the bus transaction sense, and
>> anything that could be called "IDE" was insulated from bus
FYI in the bus transaction sense is what counts as the device in this
case the IDE disks sees that. The fix is simple isolate reads and
writes. When I say bus I'm talking physical hardware interface not
the "software" interface or other hardware abstactions.
In the VAX case the Qbus or Ubus behaves the same as PDP11 even if
the read is thrown away.
>> transactions. While the card didn't have much smarts, it did have that
>> much; it looked enough like a wdc that I did the driver as an "attach
>> wdc at uba with wdc_uba" attachment layer, rather than a completely new
>> driver. I find I still have my copy of the dev directory, including a
>> boot-time console log:
Doesnt need smarts. It only has to look like an SL! you have a series
of about 8 registers, some read, some write and some are read/write
for example the data register. Any incidental reads or writes to the
data register during a transfer is unexpected and messes with the
IDE (DISK) internal smarts. So the logic has to make that bunch or
registers look like distinct read and write addresses that do not
overlap. Thats why the serial line interfaces for U and Q buses
need 4 addresses, Control write, Data write, Status read and Data read.
>Well if my SBC6120 ( PDP 8 Clone) can have a IDE interface
>why not some other PDP. We are not looking for high speed
>just hardware in this case.
Right, however it has to be done right or it doesn't work. Bob
understands that designed accordingly.
The read before write problem is important to status and data registers
becuase if you touch them at the wrong time (like an incidental read
when you mena to write) the devices internal logic is slightly messed up.
The fix and even DEC does things for DL devices (and others) is that
the write is gated to one set of addresses and the read is to another.
Adds a little logic but nothing complex.
Allison
That is the same problem I have/had. I extablished a cutoff date recycled
anything I didn't consider interesting after that. The sales brochures I
generally kept, but for other stuff, I just put a cutoff date of sometime in the
early 1980s for anything I considered common or not interesting.
> From: M H Stein <dm561 at torfree.net>
>
> Time to finally clean out some file cabinets; what should I do with
> sales brochures, price lists, etc. from the 80s? Nothing exciting,
> not very informative, but hate to just toss 'em into the recycle bin.
>
> m
Hi,
I have both Panasonic Hand Held Computer RLH1400 & Printer/Rom Extender
RL-P1005. Both items are in a case and look in great shape. Does have 3 chips
(new) along with owners manual. Some paper in printer. What is all this worth ?
Will you direct me to anyone interested in purchasing all of the above ?
Thank You,
Leo
> -----Original Message-----
> From: cctalk-bounces at classiccmp.org
> [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Josef Chessor
> Sent: Friday, February 29, 2008 11:53 AM
> To: General Discussion: On-Topic and Off-Topic Posts
> Subject: Re: front panel display for a modern PC
>
[snip]
>
> I do dabble in PIC programming, and I've got at couple of 40-pin PICs
> that would probably fit the bill with a minimum of other electronics
> (or use smaller PICs with more support electronics). Heck, a
> sufficiently simple microcomputer emulator could probably be
> implemented on said PIC, at some point. (Those are ideas I've been
> rolling around in my head for quite some time.)
>
[snip]
Hi,
I do not have much PIC programming experience but based on a little bit of
study and a small project, I cannot help but wonder a similar thing.
Recently I built a PIC 16F628 serial to parallel converter to change my
spare KayPro II serial keyboard to parallel output with the application
being to attach it to a Vector Graphic FlashWriter II video/keyboard card.
So far, I have gotten the program to run and can convert the serial stream
to light up 8 LEDs and a strobe LED but haven't attached it to the VG FWII
yet.
While working on this rather simple project, it kept occurring to me that
the PIC is practicaly begging to be made into a general purpose low chip
count computer. Add some address and data bus latches, static memory, an
EPROM, maybe a peripheral or two. The parallel and serial ports are
practically built in already. Yes, the PIC doesn't have your traditional
data and address bus but with a small 40 pin PIC protoboard like this, it
doesn't seem like it'd be all that hard to interface one to a small SRAM
like a 6264.
http://cgi.ebay.com/Microchip-PIC-Prototyping-Board-40-Terminal-PIC_W0QQitem
Z360012737667
The idea keeps kicking around in my head. It sounds like fun.
Thanks!
Andrew Lynch
I stopped holding my breath for creation of a Q-Bus IDE
controller a long time ago. While I like to think that I
do a reasonable job troubleshooting some problems,
I'm definitely not a hardware/software engineer.
It would have been nice, but it makes more sense
these days to go Q-Bus to SATA. I would imagine
that it would be alot less hassle, and certainly alot less
real estate on the board, with the smaller connectors,
and fewer traces.
At any rate, back to the topic, Q-Bus to Compact Flash.
If you can do Q-bus to Compact Flash, then you can do
Q-bus to IDE, because CF *is* an IDE interface.
Those wonderful CF to IDE adapter boards generally don't
have any circuitry on-board, except to drive status LED's.
Right now, I have Compact flash / IDE on my Q-bus,
albeit in a round-about way.
I have older CMD SCSI controllers (CQD-200's).
Attached to those are ACard 7720U SCSI <> IDE adapters.
http://www.acard.com
The CMD controllers don't have any problems with them,
and it seems to be happy with older IDE drives that I've tried.
And finally, I have ACS IDE <> Compact Flash adpaters.
http://www.acscontrol.com
You can use any IDE <> CF adapter you want,
and you can certainly get them alot cheaper elsewhere.
I chose the ACS unit, since they were one of the few
that I could find that offered it in a 3.5" drive frame.
They also offer them in a 5.25" form factor, but I think
they're just using a readily available 3.5" to 5.25" frame.
I use a SCSI removeable chassis, so I had to modify my
Acard 7720U in order to fit everything into the tray.
There is at least one vendor that offers a direct
SCSI to CF adapter, but they were a bit pricy
compared to my homebrew version.
I have tested my configuration with CF cards
ranging from 4MB up through 2GB, and find
that it works adequately for my needs.
I could see no discernable speed increase between
using real SCSI drives, and the IDE <> CF adapter,
although I wasn't trying to do any significant benchmarking.
(The CQD-200's are kind of poky controllers anyway,
so this didn't really surprise me.)
Now, if I only I could use PUTR to dump a disk image
onto a RAW IDE device, I'd be a happy camper. . . ;-)
T
Time to finally clean out some file cabinets; what should I do with
sales brochures, price lists, etc. from the 80s? Nothing exciting,
not very informative, but hate to just toss 'em into the recycle bin.
m
>
>>Subject: Re: Qbus to CF / IDE
>> From: Doc Shipley <doc at mdrconsult.com>
>> Date: Fri, 29 Feb 2008 19:09:12 -0600
>> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>>
>>tiggerlasv at aim.com wrote:
>>>
>>>
>>>> You could have, for example, four RL02s each capable of being
>>>> assigned a "pack" from the card.
>>>
>>>> What were the biggest non-MSCP-attached drives?
>>>> How hard would they be to emulate?
>>>
>>>
>>> While RL02's would probably be easy to emulate,
>>> at 10MB a pop, you don't get alot of bang for your buck.
>>
>> Forgive me if this is a silly question, but is 10MB a limitation of
>>the firmware and drivers, or of the disk technology?
>
>None of the above. There is a limit of 32mb for RT11 disks because
>because the sector pointer is only 16bits and sector size is 512bytes
>(65536*512=32mb).
>
>The real problem is few people know how to write a driver and if they
>do it's only for one OS and the list of OSs [UnixVn, RT11, RSTS,
>RSX11, VMS, Ultrix, other?] means a driver for each. Once you have
>a working driver a booter is possible.
>
>The RL driver cant be used as it's dependent on DMA and a simple IDE
>interface will not likely include that. So the model for the driver
>is more likely DD[tu58], DX [rx01], DY[rx02] or maybe some other but
>with the dimension table altered as they used PIO for the transfer.
>
>
>Allison
>
>
>>
>> Doc
>
>--m21CTBEw048667.1204374551/keith.ezwind.net--
anyone do or know of anyone doing repairs on vaxstations?
is this a lost art, and I should just buy another one off ebay or what?
I'd love to find someone who did hardware repairs/engineering for dec or still knows the stuff.
Thanks,
Dan.
_________________________________________________________________
I know, I know; I should have kept the contents and thrown out
the binders. What can I say...
Anyway, if anyone wants some binders with the Burroughs logo,
some generic and some machine-specific (L series, B80, B800)
enough to pay postage, let me know.
mike
There has been alot of discussion, as well as some good
(and not-so-good suggestions) with regards to the construction
of a Q-bus to IDE interface.
No doubt a good portion of it is from people in the field
with the knowlege and experience to take on such a project.
Being an end-user, I tend to look at things more from
the standpoint of convenience, practicality, and feasability.
We don't really need to know if it CAN be done,
because we already know the answer.
The REAL challenge is to design something that can be readily assembled
without the need for very specialized or high-end equipment,
and doesn't rely on obsolete or hard to find parts.
After all, what is the point of designing something really cool,
if it can't be easily reproduced by the average person, without
spending tons of money? At that point, it's cheaper and easier
to buy something that is already made.
With that said, here are some things that would be important to me,
when considering the design of such a device.
I've heard on more than one occasion that MSCP isn't convenient
to implement because of it's bad block replacement scheme,
and that it would be easier to use an older emulation.
For practicality purposes, that narrows it down to either
MASSBUS (RM/RP), RK05/RK07, or RL01/RL02 emulation.
To that end, my questions and suggestions are based on that premise.
Note that some of these things are "easier said than done",
but are nonetheless "something to think about".
1.) Construction
Can it be easily assembled by someone with a
modicum of technical skill, and resources?
Some examples would be -
Will the layout be relatively simple? i.e,
can it be constructed on a a single or double-sided
circuit board, rather than a multi-layer board?
Can it be constructed with readily available parts?
i.e., parts that aren't 20 years old, or hard to find?
Will components be standard DIPS, or SMT?
How easy will it be to get the firmware onto the prom?
2.) Ease of use
How will you tell it what it needs to emulate?
Obviously, a fixed emulation would be the easiest
to implement. RM05, RP06, or whatever.
One capacity, one prom.
However, I don't think it's that much of a stretch
to create selectable emulations via dip switches.
Obviously NVRAM is nicer, but may add to the overall
cost and complexity.
3.) Compatability
Whatever the design, I'm sure most of us will agree that it
should use STANDARD, unmodified DEC drivers for operation.
From what I hear, RT11 drivers are a snap to create,
but I personally dread the thought of trying to
add an unproven driver into an operating system
such as RSTS/E or RSX. I think from a compatability
standpoint, we're better off trying to "pretend to be"
something that is already supported across multiple platforms,
and the source code for those drivers are readily available.
Going further down the non-MSCP route,
I had some thoughts on some of the basic implementation -
A relatively SIMPLE design would yield something like this:
Basic functions could be driven by a bank of seven dip switches.
You'd have to pick ONE capacity, and stick with it.
Three switches would be used to select the number of drives
being emulated by the controller. (1 through 8)
Four switches would be used to select the drive emulation.
RM02/RM03/RM04/RM05
RP02/RP03/RP04/RP06/RP07
RK05/RK07
RL01/RL02
The controller would be forced as the first (primary controller)
of it's type. Address and vectoring would be tied directly to
the emulation switches, and it would set itself to the primary
address and vectors automatically. Starting LUN is always ZERO.
Are we an RL01? Then set our address to 17774400, vector 160.
(And ignore bit 3 for the number of drives on the controller !)
A more advanced approach would involve using NVRAM instead of switches.
(Storing the parameters ON the drive could be used as well, as long as
there was some sort of redundancy and recovery feature involved,
in the event of a bad sector popping up in the parameters area.)
If NVRAM or disk-based parameters were used, you could select
your address and vectors manually.
Additionally, this would allow you to mix-and-match
some of the drive capacities, effectively allowing you
to emulate two RM02's, and 3 RM05's, for example.
Of course, you'd still have to stay within the same
general emulation.
Flexible drive sizes could cause problems down the road though,
particularly if you want to change the size of a drive,
when there are other emulations already on the disk.
To get around this problem, a fixed partitioning scheme
could be implemented, based on the maximum size drive
for each emulation.
Let's say you wanted RM emulation.
An RM05 is the largest, at ~256MB.
The firmware could be set to create 8 partitions of 256MB each.
(Requiring a minimum of a 2.1GB drive).
Each emulated drive would start at a fixed position on the disk,
regardless of size, on 256MB boundaries.
Then you could change/set the capacity of any of the units
without affecting the others. In this instance, the drive type
doesn't determine the starting position, only the amount of
space
being used by a particular unit. Later, if you decide you want
drive #2 to be am RM03, you simply change it in NVRAM,
and format it from your operating system. The space between
the end of the RM03, and the 256MB boundary is simply ignored.
A mixed RL01/RL02 emulation would work the same way;
taking up ~40MB of space, regardless of drive type selected.
Some other ideas:
40-pin header, and a CF card slot on the front edge of the
board !
It might be trivial to implement RAID 1 (mirroring)
on a 2nd (identical) hard drive set to "slave",
particularly if we're looking at blind writes to disk.
Any thoughts or suggestions?
T
Hello all,
just a question out of couriosity:
Does anybody of you have experience regarding a conversion of a
s/390 coupling facility into a fully usable s/390 server system?
I got a coupling facility Generation 3. The difference between such facilities and
a fully usable server configuration is that it can only use a single type
of interconnections, no ESCON adapters etc.
I think that such a coupling facility is defined by the software installed on
the front-end system (and IBM Thinkpad) and I heard that IBM can perform
a conversion. Can a hobbyist do the same?
And hints or advises are appreciated!
Have a nice weekend and thanks alot in advance for your answers.
Kind regards,
Pierre
_________________________________________________________________________
In 5 Schritten zur eigenen Homepage. Jetzt Domain sichern und gestalten!
Nur 3,99 EUR/Monat! http://www.maildomain.web.de/?mc=021114
Ok, so this barely qualifies for the "10-year rule" but I'm asking it
anyway because you guys are so forgiving of these things :).
Picked up a "Total PowerSMP" PCI card made by "Total Impact" in the
mid-90s. (I think around '96?). From the very limited information I've
found on the 'net (mostly echoed info from press releases) this thing
has four PPC 604e CPUs on it. (233Mhz, if I'm reading the chip
correctly). This is about all the information I've been able to find on
the board.
Anyone have any documentation or software for this thing? Total Impact
seems to have disappeared off the face of the planet.
Thanks,
Josh
I just picked up an IBM Correcting Selectric III, but now I've run
into a little problem. The guy said he had it cleaned/checked out just
before he stopped using it 10 years ago, but of course a lot can
happen over 10 years in storage.
I rolled in a piece of paper to give it a test, worked great, but
after a couple paragraphs it has hit a problem. Basically, the
ribbon/ball head seems to no longer do newlines properly. It will
advance the paper but not return the head to the left margin. If I try
typing anything after hitting Return, the keys are in the stiff state,
like when the machine is off. If I Backspace all the way back to the
left margin, the keys seem to unlock, until I hit Return again.
Any Selectric Grand Masters around that can help me figure out what's
gone wrong? The machine seems to be in really great shape, EXCEPT for
this problem.
Thanks
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
A Sharp HC-4500A hand held pc, unable to test it as no ac adapter was with
it. Also picked up a TurboGrafx 16 CD system card. Not tested yet either.
John
>
>Subject: Re: VAXstation/MicroVAX 2000 CPU/FPU overheating?
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Date: Sat, 01 Mar 2008 00:46:23 +0000 (GMT)
> To: cctalk at classiccmp.org
>
>>
>> At 9:26 -0600 2/29/08, Dave wrote:
>> >Yes, I'm wondering if it's something like that, however how likely is it
>> >that both devices would experience the same fairly-uncommon failure mode
>> >at the same time?
>>
>> I'm chiming in very late and probably not very helpfully, but is
>> there any way a decoupling cap in the vicinity of the FPU/CPU could
>> either load them or generate heat itself by beginning to short to
>> ground? My only VAX (4000VLC) had a fault like that in the reset
>
>Interesting idea.... I've worked with chips that had connectiosn for
>decoupling capacitors for particualr secitons in the chip (the most
>ovious being the Transputer which needs a 1uF capacitor between 2 of its
>pins to decouple the clock multiplier PLL). In general, these components
>are not conencted to a power line or ground other than through the chip.
>
>I have no idea if the VAX 2000 chips are like this, but if they are, then
>a leak in one of those cpacitors would certainly cause thigns to run hot.
The 78032 chip is 1986 surface mount (gull wing) tech. No cap on the
chip, same for the FPU. At the time it was pushing the limit for NMOS
for power and density, they plain just run hot.
If you don't like them that hot adding another set of fins to radiate
that heat helps.
Allison
>-tony
> You could have, for example, four RL02s each capable of being
> assigned a "pack" from the card.
> What were the biggest non-MSCP-attached drives?
> How hard would they be to emulate?
While RL02's would probably be easy to emulate,
at 10MB a pop, you don't get alot of bang for your buck.
Note that some operating systems only support 4 drives
per controller, so that will need to be a consideration
as well, when drives are being partitioned.
Note: The capacities mentioned below are approximations.
The largest non-MSCP drive that I'm aware of is the RP20, at 929 MB.
However, I think that was only supported on the KL10. ;-)
For the rest of the world, you'll be looking at MASSBUS devices -
The RP07 is next in line at 504MB, but not supported by all operating
systems.
The RM05, at 256MB . . . definitely supported by RSTS/E;
not sure about smaller operating systems like RT11 though.
I think the RP06 was something like 176MB, although you're still into
MASSBUS.
Once you move below the MASSBUSS level, I think you're looking at an
RK07,
which is what? 25 or 26MB ?
I'm sure someone may chime in with more. . .
T
